Игра на двух устройствах: как сохранить прогресс, если облако предлагает старую версию

Игрок прошёл несколько уровней на телефоне без сети. Вечером открыл игру на планшете, получил награду и потратил часть монет. Когда телефон подключился, облачная копия оказалась «новее» по времени записи, но содержала другой прогресс. Простое правило последней записи уничтожит одну из ветвей, а сложение балансов способно выдать монеты дважды.

Дата записи не описывает происхождение прогресса

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

Если снимок B происходит от A, выбор B обычно означает продолжение той же ветви — после проверки его целостности и допустимости. Если B и C независимо происходят от A, сравнение времени не устраняет конфликт. Игра должна применить заранее спроектированную политику: предложить выбор, восстановить совместимые события или передать исключение на разбор.

Не все поля объединяются одинаково

Экран выбора должен объяснять последствия

Покажите узнаваемые признаки обеих копий: главу, игровое время, дату последней подтверждённой синхронизации и устройство, если оно известно. Не ограничивайтесь двумя техническими ID и кнопками «локальная / облачная». Игрок должен понимать, какой путь сохранится и что может быть потеряно.

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

Когда нужен журнал событий

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

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

Испытание ветвлением

1. Начните на двух устройствах с одного подтверждённого снимка.
2. Отключите сеть и выполните разные действия на каждом.
3. Синхронизируйте в обоих возможных порядках.
4. Проверьте, что выбор понятен, награды не удвоились, а отклонённая ветвь не исчезла до предусмотренного решения.

Ниже — модель происхождения снимков. Каждая строка задаёт «снимок;родитель», у корня родитель пуст. Инструмент покажет, является ли одна выбранная копия потомком другой или они разошлись. Он не читает игровые файлы и не объединяет баланс. Цикл, неизвестный родитель или ссылка на отсутствующий снимок считаются ошибкой данных, а не поводом случайно выбрать облако.