Современное хранение игрового прогресса в контексте Unity

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

Часто начинающие разработчики мыслят слишком конкретно и решают конкретные задачи, пытаясь затем из частных случаев собрать что-то общее. И это не всегда оборачивается успехом.
Более опытные коллеги оперируют абстракциями, на которые наращивают уже те решения, которые потребует от них ситуация. Они стремятся не к универсальности, а к возможности быстро что-то поменять в своих решениях. Задача сохранения прогресса как раз из тех, где это очень кстати.

Я хочу структурировать накопленную информацию для себя и попробовать простым языком ответить на ряд вопросов по сохранению прогресса, учитывая современные реалии:

В процессе ответов должно получиться решение, которое можно было бы использовать в качестве отправной точки для реализации системы сохранений на разнообразных проектах. Замечу, что речь не про какое-то универсальное решение. Скорее про набросок для дальнейшего развития.

⚠ Дисклеймер: ⚠

Следить за выходом новых статей и другого контента можно в моём блоге на VK / Telegram / Dtf.

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

В процессе игры происходят различные вычисления, которые порождают внутриигровые данные. Эти данные хранятся в оперативной памяти, как и все прочие программные структуры: позиции игровых объектов, текущее количество здоровья у персонажа, количество полученного и нанесённого урона, и др.

Закрывая игру, ОС освобождает выделенную под игру оперативную память, чтобы перераспределить ресурсы другим приложениям. Т.е. всё, что игра хранила в оперативной памяти, очищается.

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

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

Основные задачи:

Вытекающие возможности:

1. Мульти-устройство:

У многих пользователей сейчас множество разнообразных гаджетов, с которых можно играть. Наличием нескольких личных смартфонов уже вряд ли кого-то можно удивить. Но вот тому, что на разных телефонах в одной и той же игре будет разный прогресс, пользователь может неприятно удивиться. А пользователя удивлять лучше только приятно.

2. Кросс-платформа:

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

3. Бэкап:

Раньше о сохранности своих сохранений приходилось заботиться самому. Сейчас игры или площадки, на которых эти игры находятся, помогают не потерять данные, если игра была удалена или устройство, с которого игрок играл, было потеряно/сломано/и т.д. Войди под своим аккаунтом и продолжай играть в любимую игру.

4. Интернет:

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

5. Версионность:

Сервисная и F2P модели очень популярны и требуют долгого цикла поддержки с постоянным добавлением нового контента и фичей. Новые версии выходят регулярно и достаточно часто. Также этим процессам свойственно A/B-тестирование. В игре с каждой новой версией могут происходить изменения в данных для сохранений. Не все игроки обновляют игру последовательно, поэтому они могут пропустить несколько версий. Вне зависимости от того, как пользователь обновляет игру, он не должен терять свой прогресс. Для этого необходима поддержка совместимости между версиями и возможность актуализации сохранений.

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

Поэтому игровой проект можно условно представить в виде трёх слоёв:

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

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

В одном проекте систем сохранений может быть несколько. Одна система (самая важная) может отвечать за данные внутриигрового прогресса. Вторая – за настройки игры. Третья – за что-нибудь ещё.Например, она может сохранять какие-нибудь визуальные данные по типу "игрок открыл вкладку N раз", которые не влияют на геймплей, но важны для отрисовки.

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

Непосредственно система сохранений выполняет всего две операции:

Триггеры для вызова операции сохранения:

Триггеры для вызова операции загрузки:

Каждая операция является последовательностью определённых этапов:

1. Сохранение:

2. Загрузка:

Выполнение каждого этапа можно делегировать отдельному модулю системы сохранений:

То, как именно будут реализованы эти модули, зависит от требований проекта и предпочтений разработчика. Однако сама система сохранений включает в себя 2 операции и 4 модуля.

Реализуя систему в очередном проекте, необходимо ответить на вопросы:

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

В чём заключается гибкость:
Игра может работать в разных режимах: продуктовый, для внутреннего тестирования, для внешнего тестирования, для работы в редакторе и т.д. Для каждого из этих режимов ответы на вышепоставленные вопросы могут быть разными. Поэтому в зависимости от режима может потребоваться подключение различных реализаций описанных модулей.

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

Далее рассмотрим каждый модуль более подробно и попробуем их собрать в одну систему.

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

Учитывая это, имеем следующую абстракцию:

Учитывая описанные ранее процессы, реализуем черновик системы:

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

Это могут быть:

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

В оперативной памяти данные существуют как некоторые программные структуры. Их количество и наполнение определяется непосредственно разработчиком:

1. Все данные об игре хранятся в одной общей структуре и сохраняются вместе:

2. Все данные об игре сгруппированы в несколько независимых самостоятельных структур, которые сохраняются независимо друг от друга:

3. Каждый параметр игры является самостоятельной независимой от других структурой и сохраняется отдельно от других:

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

Чтобы в систему сохранений не попадало ничего лишнего, можно структуры, участвующие в процессе сохранения, маркировать специальным интерфейсом. Тогда контракт системы сохранений можно доработать с учётом ограничений:

Использование интерфейсов также позволяет добавить контракт на реализацию обязательных свойств у таких структур.

Например, я часто использую свойства:

Соответственно у модуля сериализации только две операции: сериализация и десериализация.Поскольку данных может быть много, а алгоритмы сериализации могут быть затратными, целесообразно считать эти операции асинхронными.Для записи в постоянную память чаще всего используется формат строки.

Учитывая эти условности, сформируем абстракцию для модуля:

Способов перевести структуру в строку довольно много. Наиболее популярные форматы сериализации:

Есть другие. И есть проприетарные in-house решения.

Для популярных форматов существуют разнообразные готовые библиотеки. У каждой есть свои требования к сериализуемым данным. Но наиболее общим является использование атрибута [System.Serializable] для сериализуемых структур (он же используется и для инспектора в Unity).

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

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

Пример реализации:

Этот формат сыскал наибольшую популярность. Он более эффективен и удобен для чтения, чем XML. И имеет больше готовых решений, чем YAML.

В Unity есть встроенный инструмент JsonUtility, который доступен сразу "из коробки". Однако он достаточно ограничен и использует те же правила сериализации, что сериализатор для ассетов внутри движка.
Т.е. он умеет сериализовывать ровно то, что можно отрисовать в инспекторе. А значит многие сложные структуры данных типа Dictionary не пройдут (но это можно решить через ISerializationCallbackReceiver).

Пример реализации:

Популярной альтернативой является библиотека Newtonsoft, которая предоставляет значительно больше возможностей. Unity даже какое-то время назад добавили её в UPM. Но сейчас я её уже там не нашёл, поэтому придётся добывать библиотеку из NuGet, как раньше. К счастью, никаких лишних зависимостей она за собой не тянет.

Пример реализации:

Шифрование сохранённых данных является популярной техникой для защиты данных от несанкционированного чтения или изменения.

Часто этот алгоритм используют как декоратор над другим сериализатором. Т.е. сначала перегоняем в JSON, а потом эти данные шифруем.

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

Само собой из-за дополнительных вычислительных издержек и нечитабельности этот трюк используют обычно только для продуктовых версий.

Пример зашифрованных сохранений:

Пример реализации:

Чтобы отличать одни данные от других, нужен некий идентификатор, он же ключ. В качестве такого ключа может выступать название файла с сохранениями, путь до него или какое-то другое уникальное обозначение.

По указанному ключу система сохранений сохраняет входящие данные. И по этому же ключу обратно их возвращает.

Самый простой способ указать ключ — это передавать его в качестве аргумента:

Это подойдёт, если есть необходимость сохранять несколько независимых однотипных структур, которые нужно как-то друг от друга отличать.
Например, нужно сохранить HealthData игрока и HealthData противника как отдельные структуры:

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

В примере выше можно тоже обойтись без явной передачи ключа. HealthData игрока не существует отдельно от самого игрока, у которого наверняка есть и другие параметры. Все эти параметры можно объединить в PlayerData.
HealthData противника тоже наверняка связана с неким EnemyData, который является частью WorldData.
WorldData и PlayerData, в обобщённом случае, существуют в единственном экземпляре. Поэтому можно их и сохранить:

Тогда сформировать ключ можно следующим образом:

С получением ключа из типа существует нюанс: если разработчик при рефакторинге случайно переименует тип, то у этих данных изменится ключ. А значит данные, сохранённые под старым ключом, не будут подхватываться новым. Т.е. ключу хорошо бы обеспечить неизменяемость, от греха подальше.

Неизменяемость обеспечивается за счёт соответствия некому явно заданному параметру: числу, строке и т.д. Нужно только определить, где этот параметр хранить.

1. Свойство:

В абстракцию ISaveData можно добавить свойство Key:

Тогда для получения ключа нужно иметь какой-то экземпляр структуры. А такой экземпляр есть только при сохранении (см. аргумент ISaveSystem.SaveAsync). На загрузке есть только ключ.

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

Из плюсов — не удастся забыть указать ключ, ведь компилятор об этом тут же напомнит, т.к. это свойство требует интерфейс.

2. Константа:

Для каждой реализации ISaveData можно объявить внутреннюю константу:

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

В этой статье мы рассматриваем обобщённый случай, где тип узнаем динамически, во время выполнения. И здесь не удастся обойтись без рефлексии, а это не желательно для Runtime-кода игры.

Если такую константу забыть завести, то узнать об этом удастся только на этапе выполнения (если нет специализированного статического анализа кода), когда приложение выбросит исключение, что константа "Key" не найдена.

3. Атрибут:

Для каждой реализации ISaveData можно указать кастомный атрибут:

Выглядит прикольнее. Но по сути это примерно +- то же, что и константа. Только в этот раз рефлексия будет нужна всегда, даже в простых системах.

4. Провайдер:

Для получения ключа мне нравится использовать выделенный провайдер, который не требует использования рефлексии.

По началу такое решение может показаться оверинженирингом. Но в непосредственно использовании так не ощущается и даёт некоторый прирост в гибкости. Если в проекте про гибкость речи не идёт и рефлексия не внесёт импакта, то, конечно, можно обойтись и без этого.

Провайдер позволяет:

Одной из фич, которую позволяет реализовать провайдер ключей, является реализация поддержки нескольких пользователей.

Проблема этой фичи: необходимость сохранять одни и те же данные у разных пользователей, не перетирая друг друга.

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

Пример реализации декорированием префиксом:

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

Это непосредственно место, где данные хранятся между сессиями вне оперативной памяти. Оно бывает локальным и удалённым.

Локальные хранилища данных:

Удалённые хранилища данных:

Удалённые хранилища обеспечивают следующие преимущества:

Удалённые хранилища имеют некоторые особенности:

Базовый набор операций:

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

Операции с хранилищем данных, особенно удалённым, затратны по времени, поэтому их стоит делать асинхронными по умолчанию.

Учитывая всё это, получаем следующую абстракцию:

Разные платформы имеют разные ограничения и особенности, поэтому для разных платформ могут требоваться различные типы хранилища.
Для работы в редакторе часто не целесообразно использовать удалённое хранилище, особенно если его использование тарифицируется. Поэтому в этом режиме подключается только локальное.
Для продуктовых сборок используется комбинация из локального и удалённого.
А для тестовых, чтобы оперативно тестировать данные в удалённом хранилище, подключают только удалённые.

Возможность менять реализацию хранилища данных перед сборкой — очень полезное следствие гибкости.

Пример реализации:

Пример реализации:

Сильно упрощённый пример реализации:

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

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

Комбинированный подход позволяет сгладить недостатки каждого типа хранилища. От способа комбинации зависит то, какие недостатки и какие достоинства каждого из хранилищ проявят себя сильнее.

Часто под комбинацией имеется в виду подобная схема:

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

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

Накопление чего-то с целью последующей обработки одним большим пакетом — это батчинг. А сам пакет — батч.

Хранилище, основанное на комбинации подобного рода, будем называть BatchDataStorage. А базовую абстракцию с возможностью переопределения условия отправки батча можно представить в таком виде:

Соответственно из этого можно сделать вариант с накоплением батча за счёт некоторой задержки:

Или вариант с отправкой батча через N операций:

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

Мы рассмотрели все модули, которые участвовали в процессах сохранения и загрузки. Настало время в черновик системы на место разметочных методов расставить рассмотренные модули:

За счёт использования абстракций и принципа внедрения зависимостей есть возможность задавать различные варианты поведения, не меняя при этом саму систему, которая в целом сохранила свою простоту: в каждой операции по 3 действия с 3 модулями на 3 строчки.

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

Реализация какого-нибудь инструмента конфигурирования для системы позволяет наделать несколько пресетов зависимостей под различные режимы сборки и на этапе загрузки DI-фреймворком это всё собрать и запустить.

Приведённый вариант реализации — тепличный и демонстрационный. Можно ли его заиспользовать — можно. Но нужно ли?

Условия задачи построения системы сохранений на каждом проекте различаются. В зависимости от этих условий итоговая система может оказаться как сильно проще, так и сильно сложнее.
Может проекту и не нужны ни облака, ни гибкость, ни масштабируемость, и прямого использования PlayerPrefs хватает "за глаза". И это нормально, если условия позволяют. Простое решение — лучшее решение.

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

Важно, из каких элементов состоит создаваемая система, как они друг с другом взаимодействуют и как их можно использовать для удовлетворения условий. А условия уже сами продиктуют реализацию.

The end