Не работает playerprefs android

milolga 30 июл 2018, 13:36

yield return new WaitForSeconds ( 0.5f ) ;
PlayerPrefs. Save ( ) ;

>
public void OnApplicationQuit ( )
<
PlayerPrefs. Save ( ) ;

public void OnApplicationPause ( bool pause )
<
if ( pause )
<
PlayerPrefs. Save ( ) ;
>
>

не помогает!(((
У меня много файлов с PlayerPrefs, везде прописала, а также сделала отдельный файл, тоже не помогает.
Примерный кусок:

void sob_ymen_vodi ( )
<
if ( PlayerPrefs. GetInt ( «k1_voda» ) > 0 )
<
PlayerPrefs. SetInt ( «k1_voda» , PlayerPrefs. GetInt ( «k1_voda» ) — 5 ) ;
PlayerPrefs. Save ( ) ;
>
else
<
PlayerPrefs. SetInt ( «k1_voda» , 0 ) ;
PlayerPrefs. Save ( ) ;
>

if ( ! PlayerPrefs. HasKey ( «money_coins» ) )
<
PlayerPrefs. SetInt ( «money_coins» , 101 ) ;
>
if ( ! PlayerPrefs. HasKey ( «money_dol» ) )
<
PlayerPrefs. SetInt ( «money_dol» , 1 ) ;
>
if ( ! PlayerPrefs. HasKey ( «kol_korov» ) )
<
PlayerPrefs. SetInt ( «kol_korov» , 0 ) ;
>
else
<
PlayerPrefs. SetInt ( «kol_korov» , PlayerPrefs. GetInt ( «inv_korova» ) — PlayerPrefs. GetInt ( «kol_kor_napole» ) ) ;
>
.

PlayerPrefs . SetInt ( «kol_korov» , PlayerPrefs. GetInt ( «inv_korova» ) — PlayerPrefs. GetInt ( «kol_kor_napole» ) ) ;
PlayerPrefs. SetInt ( «kolvo_telyat» , PlayerPrefs. GetInt ( «inv_telyat» ) — PlayerPrefs. GetInt ( «tel_na_pole» ) ) ;
PlayerPrefs. SetInt ( «kol_bik» , PlayerPrefs. GetInt ( «inv_bik» ) — PlayerPrefs. GetInt ( «kol_bik_napole» ) ) ;

k1_gizni = PlayerPrefs. GetFloat ( «k1_gizni» ) ;
k2_gizni = PlayerPrefs. GetFloat ( «k2_gizni» ) ;
k3_gizni = PlayerPrefs. GetFloat ( «k3_gizni» ) ;
k4_gizni = PlayerPrefs. GetFloat ( «k4_gizni» ) ;
k5_gizni = PlayerPrefs. GetFloat ( «k5_gizni» ) ;
k6_gizni = PlayerPrefs. GetFloat ( «k6_gizni» ) ;
k7_gizni = PlayerPrefs. GetFloat ( «k7_gizni» ) ;
k8_gizni = PlayerPrefs. GetFloat ( «k8_gizni» ) ;
k9_gizni = PlayerPrefs. GetFloat ( «k9_gizni» ) ;
k10_gizni = PlayerPrefs. GetFloat ( «k10_gizni» ) ;

yield return new WaitForSeconds ( 5f ) ;
PlayerPrefs. Save ( ) ;

public void OnApplicationQuit ( )
<
PlayerPrefs. Save ( ) ;

public void OnApplicationPause ( bool pause )
<
if ( pause )
<
PlayerPrefs. Save ( ) ;
>
>
>

В чем может быть проблема?
Я читала, что PlayerPrefs сохраняет данные на андроиде в xml файле, но в этом у меня тоже проблема, до PlayerPrefs я пыталась сохранить все в xml файле, файлы xml на андроиде тоже не видит.
Может у меня что в коде не правильно? Или может надо где-то, что-то прописать в конфигурациях?
Помогите, пожалуйста. Моя фантазия уже заканчивается (не знаю где искать ошибку), и честно заново переписывать скрипты с сохранением другими вариантами уже не хочется)))

Re: PlayerPrefs на android не сохраняет.

1max1 30 июл 2018, 14:04

загляни в директорию /data/data/com.company.appname/shared_prefs/ там должны быть твои сохранения

com.company.appname это то что ты в player setting устанавливала other settings — packcage name

Re: PlayerPrefs на android не сохраняет.

milolga 30 июл 2018, 14:28

Re: PlayerPrefs на android не сохраняет.

1max1 30 июл 2018, 14:51

Re: PlayerPrefs на android не сохраняет.

milolga 30 июл 2018, 18:47

Re: PlayerPrefs на android не сохраняет.

at0mGaming 24 ноя 2021, 08:09

Re: PlayerPrefs на android не сохраняет.

DbIMok 24 ноя 2021, 16:10

Re: PlayerPrefs на android не сохраняет.

at0mGaming 24 ноя 2021, 20:05

using System ;
using System.Collections ;
using System.Collections.Generic ;
using UnityEngine ;
using UnityEngine.UI ;

public class highScoreTable : MonoBehaviour <
private Transform entryContainer ;
private Transform entryTemplate ;
// private List hightScoreEntryList;
private List Transform > hightScoreEntryTransformList ;

public void Awake ( ) <
entryContainer = transform . Find ( «highScoreEntryContainer» ) ;
entryTemplate = entryContainer. Find ( «highScoreEntryTemplate» ) ;

entryTemplate. gameObject . SetActive ( false ) ;

string jsonString = PlayerPrefs. GetString ( «hightScoreTable» ) ; //инициализация
HightScore hightscore = JsonUtility. FromJson HightScore > ( jsonString ) ;

if ( hightscore. hightScoreEntryList . Count == 0 ) <
// если таблица пустая, записываем туда элемент
// одним из таких способов пробовал решить проблему, в Unity создаётся, но когда собираем build — нет
HightScoreEntry firstHightScore = new HightScoreEntry < score = 1 , name = "test" >;

string jsonString1 = PlayerPrefs. GetString ( «hightScoreTable» ) ;
HightScore hightscore1 = JsonUtility. FromJson HightScore > ( jsonString1 ) ;

hightscore1. hightScoreEntryList . Add ( firstHightScore ) ;

string json = JsonUtility. ToJson ( hightscore1 ) ;
PlayerPrefs. SetString ( «hightScoreTable» , json ) ;
PlayerPrefs. Save ( ) ;
>

for ( int i = 0 ; i hightscore. hightScoreEntryList . Count ; i ++ ) < // сортируем массива и его пересохранение
for ( int j = i + 1 ; j hightscore. hightScoreEntryList . Count ; j ++ ) <
if ( hightscore. hightScoreEntryList [ j ] . score > hightscore. hightScoreEntryList [ i ] . score ) <
HightScoreEntry tmp = hightscore. hightScoreEntryList [ i ] ;
hightscore. hightScoreEntryList [ i ] = hightscore. hightScoreEntryList [ j ] ;
hightscore. hightScoreEntryList [ j ] = tmp ;

string json = JsonUtility. ToJson ( hightscore ) ; // перезаписываем отсортированный массив
PlayerPrefs. SetString ( «hightScoreTable» , json ) ;
PlayerPrefs. Save ( ) ;
>
>
>
int n = 10 ; // цикл для удаления лишних элементов из List, а т.к он отсортирован в цикле выше, то удаляется просто наименьший 11ый результат
int k = hightscore. hightScoreEntryList . Count ; // цикл выполняется столько раз, сколько лишних элементов (>10) в List
for ( int i = 0 ; i ( hightscore. hightScoreEntryList . Count — n ) ; i ++ ) <
if ( hightscore. hightScoreEntryList . Count > n ) <
hightscore. hightScoreEntryList . RemoveAt ( k — 1 ) ;
string json = JsonUtility. ToJson ( hightscore ) ;
PlayerPrefs. SetString ( «hightScoreTable» , json ) ;
PlayerPrefs. Save ( ) ;
Debug. Log ( hightscore. hightScoreEntryList . Count ) ;
Debug. Log ( PlayerPrefs. GetString ( «hightScoreTable» ) ) ;
>
>

Debug. Log ( PlayerPrefs. GetString ( «hightScoreTable» ) ) ;
hightScoreEntryTransformList = new List Transform > ( ) ;
foreach ( HightScoreEntry hightScoreEntry in hightscore. hightScoreEntryList ) < //отрисовка строк таблицы рекордов
createHightScoreEntryTransform ( hightScoreEntry, entryContainer, hightScoreEntryTransformList ) ;
>
>

public void createHightScoreEntryTransform ( HightScoreEntry hightScoreEntry, Transform container, List Transform > transformList ) <
float templateHight = 45f ;
Transform entryTransform = Instantiate ( entryTemplate, container ) ;
RectTransform entryRectTransform = entryTransform. GetComponent RectTransform > ( ) ;
entryRectTransform. anchoredPosition = new Vector2 ( 0, — templateHight * transformList. Count ) ;
entryTransform. gameObject . SetActive ( true ) ;

int rank = transformList. Count + 1 ;
string rankString ;
switch ( rank ) <
default :
rankString = rank + «» ; break ;
case 1 :
rankString = rank + «ый» ; break ;
case 2 :
rankString = rank + «ой» ; break ;
case 3 :
rankString = rank + «ий» ; break ;
>
entryTransform. Find ( «position (1)» ) . GetComponent Text > ( ) . text = rankString ;

int score = hightScoreEntry. score ;
entryTransform. Find ( «score (1)» ) . GetComponent Text > ( ) . text = score. ToString ( ) ;

string name = hightScoreEntry. name ;
entryTransform. Find ( «name (1)» ) . GetComponent Text > ( ) . text = name ;

transformList. Add ( entryTransform ) ;
>

public static void AddHightScoreEntry ( int score, string name ) < //метод для добавления новых данных
HightScoreEntry hightScoreEntry = new HightScoreEntry < score = score, name = name >;

string jsonString = PlayerPrefs. GetString ( «hightScoreTable» ) ;
HightScore hightscore = JsonUtility. FromJson HightScore > ( jsonString ) ;

hightscore. hightScoreEntryList . Add ( hightScoreEntry ) ;

string json = JsonUtility. ToJson ( hightscore ) ;
PlayerPrefs. SetString ( «hightScoreTable» , json ) ;
PlayerPrefs. Save ( ) ;
>

public class HightScore <
public List HightScoreEntry > hightScoreEntryList ;
>

[ System . Serializable ]
public class HightScoreEntry <
public int score ;
public string name ;
>
>

Источник

Что делать если PlayerPrefs обнуляются на телефоне?

Данные создаются, сохраняются и берутся у меня так

При тесте в юнити все работает отлично, купил, данные сохранились, открыл новый тест и переменная уже равна 1 так как уже купилась, все логично, все нормально.

Но вот я залил это уже в рабочую версию на гугл маркет, скачал ( там на другой телефон), установил, поигрался все норм, и вот сделал покупку, например как в этом примере отключил рекламу, деньги снялись, реклама отключена, все вроде ок. но когда я закрыл приложение и зашел заново в него, эта функция уже отключена, как будто и не покупалась, то есть получается что PlayerPrefs обнуляются что-ли, это проблема, и я бы сказал большая.
Как её решить и из-за чего такое может быть.
(покупки конечно в игре я приостановил)

Вопрос задан 21 февр.
53 просмотра

Не советую использовать ТОЛЬКО PlayerPrefs как способ сохранения покупки.
Если игрок покупает за реальные деньги в магазине, то у UnityIAP есть отличное свойство класса Product (товара) — . hasReceipt , которое работает с товарами типа Subscription и Non Costumable.

У меня в коде реализовано так: при покупке сохраняю в PlayerPrefs, а проверяю так: если есть интернет соединение — запрашиваю наличие чека с помощью . hasReceipt , иначе смотрю в PlayerPrefs.

PlayerPrefs могут очищаться пользователем, также и при обновлении или удалении приложения, а игрок то покупку оплатил — вот тебе и недовольный покупатель, и плохой отзыв

Источник

Сохранение игры в Unity3D

Если вы пишете не казуалку под веб и не беспощадный суровый рогалик, без сохранения данных на диск не обойтись.
Как это делается в Unity? Вариантов тут достаточно — есть класс PlayerPrefs в библиотеке, можно сериализовать объекты в XML или бинарники, сохранить в *SQL*, можно, в конце-концов, разработать собственный парсер и формат сохранения.
Рассмотрим поподробнее с первые два варианта, и заодно попробуем сделать меню загрузки-сохранения со скриншотами.

Будем считать, что читающий дальше базовыми навыками обращения с этим движком владеет. Но при этом можно не подозревать о сущестовании в его библиотеке PlayerPrefs, GUI, и ещё в принципе не знать о сериализации. С этим всем и разберёмся.
А чтобы эта заметка не стала слишком уж увлекательной и полезной, ориентирована она самый неактуальный в мобильно/планшетно/онлайновый век вариант — сборку под винду (хотя, конечно, более общих моментов достаточно).

Кстати, пару недель назад на Хабре была статья, где автор упомянул, что Unity3D проходят в курсе компьютерной графики на кафедре информатики питерского матмеха. Занятный факт, немало говорящий о популярности движка.
Хотя насколько это в целом хорошая идея — на мой взгляд, тема для дискуссии. Может быть, обсудить это было бы даже интереснее вопросов сериализации =)

Ещё небольшой дисклеймер — я не профи ни в одной из раскрываемых тем, так что если какие-то вещи можно сделать правильнее-проще-удобнее — исправления и дополнения очень приветствуются.

1. PlayerPrefs

Удобный встроенный класс. Работает с int, float и string. Довольно прозрачный, но мне всё равно встречались на форумах обороты в духе «не могу понять PlayerPrefs» или «надо бы как-нибудь разобраться с PlayerPrefs», так что посмотрим на него на простом примере.

1.1 Примитивное использование в рамках одной сцены: QuickSave & QuickLoad по хоткеям.

Быстрый пример использования. Допустим, у нас одна сцена и персонаж на ней. Скрипт SaveLoad.cs прикреплен к персонажу. Будем сохранять самое простейшее — его положение.

Конечно, тут применение PlayerPrefs довольно надумано — фактически против обычных переменных оно добавляет нам только возможность загрузки игру с места сохранения после выхода.

Зато весь основной интерфейс класса виден: для каждого из трех типов Get / Set по ключу, проверка вхождения по ключу, очистка. Нет смысла даже разбирать ScriptReference, всё очевидно по названиям функций: PlayerPrefs

Однако на одной всё же стоит остановиться подробнее, PlayerPrefs.Save. В описании говорится, что вообще дефолтно юнити пишет PlayerPrefs на диск только при закрытии приложения — в общем-то логично, учитывая, что класс ориентирован не на внутренний обмен данными, и на их сохранение между сеансами. Соответственно, Save() предполагается использовать только для периодических сохранений на случай крэша.

Возможно, в некоторых случаях это так и работает. Под Win PlayerPrefs пишутся в реестр, и, как можно легко убедиться, считываются и пишутся сразу.
Как-то так выглядит наш класс в реестре:

Ко всем ключам в конце добавлен их DJBX33X-хеш (Bernshtein hash with XOR).

UnityGraphicsQuality сохраняется всегда автоматически, и действительно при закрытии приложения. Это Quality level из Edit -> Project Settings Quality, оно же QualitySettings.SetQualityLevel .

Можно при запущенном приложении модифицировать сохранённое значение в реестре, потом затребовать его из программы — и мы увидим, что вернулся модифицированный вариант. Т.е. не стоит думать что во время работы программы PlayerPrefs — что-то вроде аналога глобальных переменных, а работа с диском не происходит.

2. Сериализация в XML

Говорим сериализация, подразумеваем бинарный код. Такое встречается, но на самом деле сериализовать можно в любой формат. По сути это перевод структуры данных или состояния объекта в хранимый/передаваемый формат. А десериализация, соответственно — восстановление объекта по сохраненным/полученным данным.

Вообще Mono умеет и бинарную сериализацию, и XML (System.Xml.Serialization), но есть один момент: большинство классов Unity не сериализуются напрямую. Невозможно просто взять и сериализовать GameObject, или класс, наследующий MonoBehavoir: придётся завести дополнительно внутренний сериализуемый класс, содержащий нужные данные, и работаеть, используя его. Но XmlSerializer хотя бы кушает автоматически Vector3, а BinarySerializer, afaik, даже этого не умеет.

2.1 Суть примера

Представьте, что вы пишете свой Portal, где герой проходит череду однотипных локаций — но на любую из них может впоследствии вернуться. Причём на каждую он мог оказать воздействие: какие-то ресурсы использовать, что-то сломать, что-то расшвырять. Хочется, эти изменения сохранять, но возвращение на локацию маловероятно и непрогнозируемо, и тащить за собой параметры всех комнат в оперативке нет особого смысла. Будем сериализовать локацию, покидая её — например, по триггеру на двери. А при загрузке локации генерировать либо дефолтную ситуацию, либо, если есть сохраненные данные, восстанавливать по ним.

2.2 Сериализуемые классы для данных

XmlSerializer умеет работать с классами, данные в которых состоят из других сериализуемых классов, простых типов, большинства элементов Collections[.Generic]. Обязательно наличие у класса пустого конструктора и public-доступ ко всем сериализуемым полям.
Некторые типы из библиотеки Юнити (вроде Vector3, содержащего всего три интовых поля) успешно проходят этот фейсконтроль, но большинство, особенно более сложных, его фейлят.

Допустим, в каждой комнате нам надо сохранять состояния некоторого произвольного набора GameObject’ов. Напрямую сделать этого мы не можем. Значит, нам потребуются дублирующие типы.

Создадим новый скрипт в Standard Assets:

В квадратных скобках идут атрибуты для управления XML-сериализацией. Тут они фактически влияют только на имена тегов в генерируемом *.xml, и строго говоря, необходимости в них нет. Но пусть будут, для наглядности 🙂 Если вам почему-то вдруг важно, как будет выглядеть xml-код, то возможности атрибутов, конечно шире.

Дальше там же добавим базовый класс для предметов из списка и сколько угодно наcледуемых от него. Хотя… для примера хватит и одного:

Итак, сериализуемые классы готовы. Сделаем теперь ещё класс для дополнительного упрощения сериализации созданного типа RoomState.

2.3 Непосредственно сериализация

Тоже в Standard Assets сделаем класс с парой статических методов, которыми будем в дальнейшем пользоваться:

Здесь XmlSerializer мы создаём через конструктор Constructor (Type, Type[])
FileStream открываем по адресу сохранения, передаваемого конкретной локацией.

Использование

Итак, все вспомогательные инструменты готовы, можно приступать к самой комнате. На объект комнаты вешаем:

Напоследок, сделаем вызов RoomGen.Dump(). Пусть, например, по триггерам на дверях, которые являются дочерними объектами относительно комнаты (объекта с компонентом RoomGen):

Вот и всё. Здесь опущено собственно взаимодействие с предметами и процесс изменения их состояния, но это несложно добавить. Для первоначального теста можно просто добавить в скрипт пару устанавливащих состояния функций по хоткеям, или ставить на паузу и двигать руками.

При первом запуску генерируется дефолтный вариант, при выходе изменения дампятся в файл, при возвращении последние состояние восстанавливается из файла, в том числе если приложение закрывалось. Works like a charm.

Один из существенных недостатков XML — игрок может легко изменить данные. И если в данном случае мало кого заинтересует расположение раскиданных стульев, то при сохранении более существенных для игрока данных сериализации в XML лучше избегать. Да и в реестре поменять значения не сложно. В таких случаях уже лучше использовать бинарную сериализацию или свой формат.

3. Save/Load через меню

Наверное, актуальнее было бы реализовать вариант с выбором/созданием пользователя и внутренними автоматическими сохранениями. Если вашей игре требуется серьёзное меню Save/Load, то вряд ли вы сейчас читаете эту статейку для профанов.

Но я жду не дождусь новогодних праздников, когда можно будет наконец увидеться с сестрой и за пару вечеров добить классическую American McGee’s Alice, так что сделаем Save/Load почти как там. Со скриншотами. Заодно будет повод покопаться в GUI, текстурах и других увлекательных вещах.

3.1 Главное меню

Чтобы сделать загрузку и сохранение через меню, нам, как ни странно, понадобится меню. Конечно, можно сделать его самостоятельно через объекты на сцене, можно заюзать готовые решения ироде NGUI , но мы пока воспользуемся GUI из штатной библиотеки.

Scripting Reference

функция кнопки. Рисует её в рамках заданного прямоугольника, реагирует на нажатие, возвращая true. Конструкторов больше, но нам хватит этих.

Группировка элементов гуи, полезна в основном переопределением границ относительно которых вычисляется положение вложенных элементов (дефолтно это границы экрана, в данном случает — прямоугольник position).

Суть
Сделаем отдельную стартовую сцену, а на ней пустой объект, к которому и прикрепим скрипт для нашего меню. Т.о. меню будет путешествовать сквозь сцены (при загрузке очередной сцены не пересоздаётся, а просто переносится в неё), хэндлить нужные события (вроде кнопки вызова меню), при вызове рисоваться поверх экрана игры.

по коду с комментариями всё должно быть ясно:

Главное меню до и после начала игры

3.2 Рисуем меню загрузки / сохранения

Функция drawSaveLoadMenu() у нас уже вызывается при menutype>0, но пока не написана. Исправим это упущение. Пока просто научимся рисовать наши меню и вызывать собственно функции загрузки/сохранения.

Scripting Reference

Количество — исходя из размеров передаваемого массива. Вообще предназначен для использования как-то так:

Суть
Кажется, это не совсем то, что нам требуется — нам-то нужно выбрать один раз и сразу отреагировать. Но SelectionGrid спокойно ест грязный хак — индекс вне пределов реального массива. Т.е. мы всегда будем передавать, допустим, -1 и тогда сможем отслеживать собственно событие клика.

Меню Load на SelectionGrid — внешне ничем не отличается от соответствующего Save

Основное, что мне в этом решении не нравится, это что в меню загрузки не содержащие сохранений слоты остаются относительно активными — внешне отличаются только отсутствием текстуры, реагируют на наведение. Поэтому бонусом — сетка ручками, вместо неактивных слотов рисуем Box, для активных Button.
Заодно добавим резиновости: количество слотов в строке задаётся, размер слотов подстраивается под экран. Правда, тут они уже квадратные, но встроить произвольное соотношение сторон будет несложно 🙂 Ну и заодно min/max width/height из GUILayout и прочая обработка напильником.

Меню Load на Button и Box — теперь пустые слоты неактивны

3.3 Текстуры, скриншоты

Итак, с момента создания нашего объекта меню мы будем держать массив текстур. Памяти он занимает немного и нам гарантирован в ним мгновенный доступ. На самом деле, тут и альтернативы особой нет — не пихать же работу с диском в onGUI().

Как мы уже видели, при создании нашего меню создаём и массив:

Сохранять мы будем не только информацию сейвов, но и информацию о них, а точнее — какие именно слоты содержат сохранения. Как хранить — выбор каждого, можно по параметру 0/1 на каждый слот, можно строку из 0/1, но мы сделаем некрасиво 🙂 и возьмём битовый вектор в int. В какой момент и как он сохраняется, увидим позже, пока просто читаем.
Добавим в Start():

Ну и собственно главное в данном вопросе — как скрины сохранять? Напрашивается вариант Application.CaptureScreenshot , но тут сразу два подвоха. Во-первых, они сохраняются в полном размере, а поскольку в кончном итоге понадобятся нам только thumbnails, логичнее сразу сделать ресайз. Во-вторых, мы же держим массив текстур, придётся в него снова считывать с диска? Не очень-то здорово.

Функцию взятия и записи скриншота вызывать будем позже, а пока заранее выделим в Coroutine:

Неприятный нерешенный момент — текстура с текущей сессии и текстура, загруженная с диска, сильно различаются по качеству.
Ниже слева две текущих, справа — две с диска, от предыдущих сессий:

3.4 Собственно реализация сохранения загрузки

Итак, вроде бы с шелухой разобрались. Научились минимально работе с GUI, сделали простое главное меню, меню Save/Load, научились работать со скриншотами.

Как реализовать взаимодействие между объектами сцены, параметры которых мы будем сохранять и нашим меню?

1. Если мы будем записывать только состояние такого же создаваемого с первой сцены и неразрушаемого далее объекта (например, игрок, его параметры и инвентарь) — можно сразу держать прямую ссылку.

2. GameObject.Find и GameObject.FindWithTag тут использовать практически не стыдно — загрузка/сохранение — разовое событие. Можно искать напрямую, а поскольку сцены могут содержать разную информацию — то, как вариант, добавлять на каждую специальный объект с определенным тегом, к которому и будет прикручен скрипт сохранения/загрузки собственно данной сцены, тут уже можно держать прямые ссылки на требуемые объекты.

А пока рассмотрим такой простой вариант. Сохранять будем только сцену и положение игрока. Игрок в каждой сцене пересоздаётся, но всегда вид от первого лица, и соответственно к игроку прикреплена камера.
Через неё и будем получать доступ. В ниже представленной функции вся эта специфика — в двух строках помеченных //!, и её не сложно локально заменить, остальное привязано к уже написанному нами выше коду.

Если делать скриншот заранее, то он во-первых, может не пригодится, а во-вторых, нужно ещё успеть. А так, с учётом заблокированности камеры в режиме меню, результат примерно тот же.

С загрузкой ещё проще. Всё специфику мы снова полностью делегируем, причём даже не будем её напрямую вызывать. Просто загрузим нужный уровень, а дальше они как-нибудь сами 🙂

Сделаем теперь поведение, который будем вешать на камеры:

Надо заметить „дальше как-нибудь сами“ было определенной степенью лукавства: loadgame() меню и load() объекта определенно обменялись информацией, только вот через известное место — реестр. Сохранять туда откровенно временную переменную — ход не слишком красивый. Можно изменить на прямой вызов load(), а без изменения текущей общей структуры — держать переменную в меню, и в Start() загружаемого объекта добавить поиск объекта меню и получение нужной информации.

Дальше. От созданного базового поведения мы можем унаследовать разные варианты для разных сцен и объектов. Например, вариант с сохранением поворота:

Конечно, здесь данным уже пригодилась бы защита. Поскольку поскольку вся фактическая работа с PlayerPrefs тут выделена в отдельные функции save() / load(), заменить их содержательную часть будет не сложно. На что? Можно аналогично примеру из части 2 держать класс-рефлектор, и сериализовать его через BinarySerializer.
Другой неплохой вариант — прикрутить, например, SQLite. Правда, по слухам, на js с ней работать удобнее, чем на шарпе, но и на последнем всё в конечном итоге заводится. Кто хочет попробовать, начать можно отсюда.

Этот текст никогда бы не получился без:

и хабра. Спасибо им.
Надеюсь, всё это принесёт кому-нибудь пользу, и никому — вреда 🙂

Источник