Статус: Draft


Принцип

Сохранение привязано к хосту: файл сохранения хранится у него и синхронизируется через Steam Cloud (Auto-Cloud по маске файлов — путь сейвов фиксируется с самого начала).

Host migration (решение): бесшовная передача хоста в реальном времени не делается к фестивалю (это непросто в NGO) — отложена на post-release. Текущая модель: если хост выходит, сессия завершается, последний автосейв расшарен через Steam Cloud, и другой игрок перехостит и загрузит с последней точки. Опирается на частые автосейвы на границах ивентов (ниже).


Точки автосохранения

Сохранение происходит автоматически:

  1. В самом начале забега
  2. В начале ивента (бой, магазин, лагерь и т.д.) — перед его стартом
  3. Перед получением наград — после боя, перед открытием экрана наград

Формат хранения (решение)

  • Easy Save 3 для записи на диск / Steam Cloud (сериализация, шифрование, Unity-типы) — вместо ручного JSON.
  • Сохраняем рантайм-состояние через слой DTO (RunSaveData, UnitSaveData), а не объекты сцены.
  • Сущности (юниты, реликвии, эффекты) хранятся по строковым ID ("relic_flame_sword"), а не ссылками на ScriptableObject. SO — иммутабельные определения контента; в сейве на них ссылаемся по ID. Это переживает изменения ассетов и переносится между билдами/игроками.
  • Под рогалик сейв компактен: при необходимости можно дополнить снапшот сидом + логом команд для точной воспроизводимости — см. 3. Рандомизация забега (Seed).
  • Версионирование схемы: в каждом файле сейва — поле schemaVersion + миграции при изменении формата. Без этого апдейт игры ломает старые сейвы. Тот же принцип — для Workshop-UGC, см. 8. Steam Workshop и UGC.

Подробнее — 5. Технологический стек и архитектура.