Сохранение должно знать свою версию
Одна из самых полезных вещей, которую можно добавить в формат сохранения заранее, — номер версии данных.
Тогда при загрузке игра понимает не только содержимое файла, но и то, по каким правилам оно было создано.
Допустим, первая версия хранила инвентарь одним способом, во второй появилась новая структура предметов, а в третьей изменилась система прогрессии. Вместо попытки написать один универсальный loader можно последовательно преобразовывать старые данные в актуальный формат.
Так migration становится контролируемой цепочкой, а не набором исключений внутри загрузки.
Особенно важно не предполагать, что игрок обязательно запускал каждое обновление. Пользователь может вернуться через год и перейти сразу с версии 2 на версию 8. Значит, система должна уметь провести его сохранение через все необходимые изменения.
Проверяйте реальные старые данные
Главная ошибка миграции — тестировать её только на сохранениях, которые разработчик создал вчера.
Реальные игроки содержат намного больше нестандартных состояний: незавершённые задания, старые предметы, комбинации прогресса, которые новая версия уже не позволяет получить обычным способом.
Поэтому перед релизом полезно хранить набор сохранений из предыдущих версий и регулярно прогонять их через актуальный build.
Здесь QA и тестирование игры особенно важно строить вокруг upgrade path: пользователь должен загрузить старое состояние, продолжить игру, сохранить его уже в новом формате и затем снова корректно загрузиться.
Если миграция проверяется только через fresh install, один из наиболее рискованных пользовательских сценариев вообще остаётся за пределами тестирования.
Не удаляйте старое сразу
Когда новая система уже готова, хочется быстро убрать legacy-код.
Но безопаснее сначала выпустить версию, которая умеет читать старые данные, преобразовывать их и работать с новым форматом. И только когда команда уверена, что переход прошёл корректно, постепенно удалять больше не нужную совместимость.
Это особенно важно для live-проектов, где разные версии клиента некоторое время существуют одновременно. В материале про обновления LiveOps без downtime действует тот же принцип: backward compatibility часто приходится поддерживать некоторое время, чтобы rollout не требовал одномоментного переключения всей аудитории.
Миграция должна уметь пережить ошибку
Самый неприятный сценарий — не просто неудачная загрузка, а ситуация, когда migration частично изменила данные, после чего процесс завершился ошибкой.
Игрок может получить сохранение, которое уже не понимает ни старая версия, ни новая.
Поэтому изменение данных лучше проектировать так, чтобы исходное состояние не уничтожалось до успешного завершения операции. Для критичных проектов полезно иметь backup или возможность восстановить предыдущую версию данных.
Особенно осторожно нужно работать с облачными сохранениями: повреждённое состояние может очень быстро синхронизироваться между устройствами и заменить рабочую локальную копию.
Не переписывайте save system прямо перед релизом без необходимости
Старая система может быть неудобной, но если она много лет стабильно хранит данные пользователей, большая архитектурная переделка перед запуском создаёт серьёзный regression scope.
Это один из примеров того, почему технический долг особенно болезненно проявляется перед релизом. Иногда рефакторинг действительно необходим, но его стоимость нужно оценивать вместе с риском потерять или неправильно преобразовать пользовательские данные.
Если текущая архитектура уже мешает добавлять новые функции, сначала полезно провести технический аудит проекта и понять, можно ли изменить систему постепенно, не переписывая одновременно хранение, serialization и всю игровую логику.
Хорошая миграция для игрока незаметна
Пользователь не должен думать о версиях save format.
Он обновляет игру, запускает её и продолжает с того же места. Именно это является главным критерием качества миграции.
Внутри проекта при этом может существовать несколько шагов преобразования, validation старых данных, backup и дополнительный regression. Чем дольше живёт игра, тем важнее относиться к этим механизмам как к постоянной части архитектуры, а не разовой задаче очередного обновления.
Если система сохранений уже накопила несколько форматов, временные обходы или регулярно создаёт проблемы при выпуске новых версий, это хороший кандидат на улучшение существующей игры. Начинать здесь лучше не с полного переписывания, а с карты существующих данных и сценариев перехода.
Если проекту предстоит изменить формат сохранений, добавить новую прогрессию или перенести старых игроков на новую систему — пришлите описание текущего save format и планируемых изменений. Разберём migration path и определим, какие состояния нужно обязательно проверить до выпуска обновления.