Игроки возвращаются к следующему эпизоду с уже выбранными маршрутами, открытыми сценами и вложенным временем. Относитесь к совместимости сохранений как к функции, которую нужно поддерживать в каждом выпуске. Переименование элементов состояния, удаление сцен или изменение сериализованных объектов может нарушить работу старых сохранений, даже если новое прохождение работает правильно.
Системы сохранений в разных движках устроены по-разному. Обратитесь к документации именно вашей версии движка и зафиксируйте все задействованные версии. Используйте это руководство, чтобы определить свои обязательства по совместимости и проверить их выполнение; не рассчитывайте, что универсальный скрипт миграции обеспечит совместимость при любом обновлении движка.
Определите контракт совместимости
Решите, какие выпущенные версии будет поддерживать следующая сборка, прежде чем менять сохраняемое ею состояние. Установите отдельные четкие правила для обычных сохранений, постоянно сохраняемых разблокировок, настроек и сохранений, экспортированных из браузера: для них могут потребоваться разные подходы. Заранее сообщайте игрокам, когда может понадобиться начать игру заново.
Храните идентификатор выпуска и, если вы контролируете формат сохранений, версию схемы. Отделяйте прогресс в контенте от настроек отображения и производных данных. Перед изменением постоянно сохраняемого поля зафиксируйте его смысл и значение по умолчанию.
Используйте стабильные идентификаторы
Присвойте маршрутам и сценам стабильные идентификаторы, которые сохраняются при переработке и переводе. Не меняйте их, пока обещаете совместимость. Если идентификатор необходимо изменить, спланируйте миграцию или четко обозначьте границу, за которой старые сохранения больше не поддерживаются.
Если вы управляете собственным форматом сохранений, храните простые данные, документируйте схему и проверяйте входящие данные перед использованием. Встроенные сохранения движка могут подчиняться другим правилам сериализации. Следуйте рекомендациям движка, прежде чем заменять надежную систему сохранений самодельным сериализатором.
Планируйте миграцию до изменения состояния
Составьте план миграции до изменения поля: старое поле, новое поле, правило преобразования и запасной вариант на случай отсутствующих или неожиданных данных. Если формат позволяет, делайте миграции детерминированными и пригодными для повторного выполнения. Отсутствие постороннего поля никогда не должно засчитывать прогресс.
Для Ren'Py следуйте рекомендациям по сохранению и откату, а также примечаниям о совместимости, относящимся к вашим версиям. Для SugarCube проверьте точную версию формата и API сохранений. Для собственного состояния в Godot реализуйте и протестируйте схему, которой управляете. Правило, работающее в одной системе, может не подходить для другой.
Храните библиотеку репрезентативных сохранений
Соберите библиотеку сохранений, охватывающую начало игры, моменты непосредственно перед важными выборами, каждый основной маршрут и этап приближения к финалу. Включите разные разблокировки, настройки и старые версии, которые вы еще поддерживаете. Используйте обезличенные состояния из процесса разработки и не собирайте ненужные вам данные игроков.
Тестируйте копии, оставляя оригиналы нетронутыми. Запишите, из какого выпуска получено каждое сохранение и какое состояние ожидается после загрузки. Загрузка без исключения — лишь первая проверка: сохранение все еще может отправить игрока на неправильный маршрут, продублировать награду или потерять настройку.
Проверьте настоящее обновление
Протестируйте упакованную сборку по тому пути обновления, которым действительно будут пользоваться игроки: установите ее или разместите для доступа через сервер, в зависимости от ситуации. Загрузите старое сохранение, пройдите содержательную сцену, снова сохранитесь и загрузите сохранение. Отдельно проверьте постоянно сохраняемый прогресс и настройки.
В браузерных сборках проверьте источник (origin), поведение хранилища и контекст размещения игры при встраивании. Изменение URL или контекста хранилища может повлиять на доступ к существующим данным, даже если логика игры не менялась. Если вы предлагаете экспорт и импорт, проверьте этот способ восстановления и объясните его ограничения.
Опубликуйте понятные сведения о восстановлении
Разместите описание поддерживаемого пути обновления, способа резервного копирования и известных ограничений совместимости там, где игроки смогут их найти. Добавьте в форму сообщения об ошибке запрос полезных сведений о версиях. Если выпуск не может безопасно сохранить определенную категорию сохранений, объясните эту границу до того, как игрок перезапишет свою последнюю рабочую копию.
Архивируйте протестированную сборку, примечания к схеме и матрицу сохранений вместе с каждым выпуском. Сохраняйте связь решений о миграции с ревизиями исходного кода. Регулярные проверки совместимости облегчают поддержку и позволяют обнаружить сбои раньше игроков.
Ключевые решения
- Укажите поддерживаемые выпуски и установите правила для каждой категории сохранений.
- Сохраняйте стабильные ID и документируйте смысл и значение по умолчанию каждого поля.
- После миграции проверьте прогресс, затем сохранитесь и загрузите сохранение.
- Берегите оригиналы сохранений и объясняйте игрокам, как их восстановить.
Файлы руководства
Матрица тестирования ↓Внешние сообщества, посвящённые моделям, и внешние сайты для публикаций могут содержать откровенные материалы. Ссылки на источники открываются в новой вкладке; это руководство не загружает их предпросмотры.
Источники и дополнительные материалы +
- Документация Ren'Py по сохранению и откату ↗
- Несовместимые изменения Ren'Py ↗
- Сохранение игр в Godot ↗
- Документация SugarCube ↗
Последняя проверка 5 октября 2026 г..