Миграция схем сохранений и восстанавливаемая запись

Сохранение — долговечный интерфейс

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

Формат не означает совместимость

Руководство Godot показывает явную сериализацию игрового состояния и ограничения типов JSON. [1] Protocol Buffers описывает совместимость, включая сохранение идентичности номеров полей и резервирование удалённых. [2] Формат помогает представить данные; игровой смысл, значения по умолчанию, миграции и диапазон версий остаются проектными обязанностями.

Разобранный пример

Условное сохранение версии 1 содержит coins: 125. Версия 2 заменяет поле на wallet: {gold: 125}. Версия 3 добавляет difficulty, используя normal только при миграции старого сохранения без этого поля.

Реализуйте преобразования 1 → 2 и 2 → 3 над декодированными данными. После первого шага проверьте, что валюта остаётся 125; после второго проверьте умолчание и сохраните весь остальной прогресс. Повышайте записанную версию только после успеха соответствующего преобразования. Сохранение версии 3 не должно получать дополнительное начисление лишь из-за повторной загрузки.

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

Миграция и восстановление

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

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

Фиксация и границы отказа

Для SQLite фиксируйте данные и версию схемы одной транзакцией; документация атомарной фиксации описывает механизм и предположения о хранении. [3] Для файлов подготовьте полную замену и используйте поддерживаемые платформой операции атомарной замены и долговечности. Одно переименование не гарантирует устойчивость к любому отключению питания.

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

Источники

[1] Сохранение игр — Документация Godot Engine.

[2] Руководство proto3 — Документация Protocol Buffers.

[3] Атомарная фиксация — Разработчики SQLite.