Как добавить облачные сохранения и аккаунты без сервера

Облачному сохранению нужны три вещи: способ отличать игроков друг от друга, хранилище, которое переживёт устройство, и правило, решающее, что делать, когда два устройства не согласны. Ничто из этого не требует сервера, который пришлось бы держать вам. Если игра выходит в Steam, Google Play или App Store, все три задачи уже ведёт платформа — ваша работа сводится к настройке и нескольким вызовам API. Если игра живёт в браузере, или один и тот же игрок вечером сидит за ПК, а утром едет в автобусе с телефоном, обвязку берут у сервиса, а не строят сами. Свой бэкенд — третий маршрут, и для большинства инди-игр это самый дорогой способ получить фичу, которая и так входила в комплект стора.

Запрос регулярно всплывает в читках сообщества, которые мы проводим: игра работает, игроки спрашивают, переедет ли прогресс на новый телефон или второй компьютер, и разработчик со вздохом садится «учить бэкенд» ради того, что по праву должно быть страницей настроек. Ниже — маршруты, существующие прямо сейчас: что каждый даёт, во что обходится, где ломается, и та часть, которую никто не показывает в демо, — разрешение конфликтов. Вторая половина задачи, что именно сохранять и в каком формате, разобрана в руководстве по системе сохранений; эта статья — про синхронизацию. Сразу оговорюсь, что блог принадлежит Egmatic, no-code 2D-редактору в pre-alpha; где аккаунты и сохранения стоят в наших собственных планах, станет ясно ближе к концу.

Короткий ответ#

Решающий вопрос тот же, что сортировал маршруты лидербордов: где ваши игроки входят в аккаунт? Сохранение переносимо ровно настолько, насколько переносима личность, к которой оно прикреплено. Сторовые сборки наследуют систему аккаунтов в первый же день; веб-билд начинается с анонимных гостей, пока вы не дадите им вход. Выбирайте маршрут, которому уже принадлежат личности ваших игроков, — хранилище подтянется следом.

Что облачному сохранению действительно нужно#

Если разложить фичу на работы, а не на продукты, перед вами четыре решения — и каждый маршрут ниже по-своему отвечает на вопрос, кто их выполняет.

1. Личность игрока. У каждого сохранения есть владелец. Сторы закрывают вопрос аккаунтом, который у игрока уже есть, — потому сторовые маршруты и ощущаются почти бесплатными. Веб-игре нужны ники, идентификаторы устройства или вход, и от этого выбора зависит, чего сохранение стоит: прогресс, у которого нет владельца, вернуть нельзя.
2. Хранилище, которое переживёт устройство. Сохранению нужен дом, который выживет, даже если телефон утонет в озере. Это единственная часть, похожая на «бэкенд», и на любом маршруте это один вызов записи.
3. Правило синхронизации. Когда ноутбук и телефон по-разному помнят вчерашний вечер, кто-то должен решить, чья версия правда. Платформы отдают вам конфликт и крючок для его разрешения; сервисы — примитивы вроде версионированных записей. Само правило проектируете вы, и сделать это до релиза — разница между абзацем кода и очередью в поддержку.
4. Целостность. Всё, что пишет клиент, клиент может подделать: восстановление скопированного файла, кошелёк, правленный в hex-редакторе. Для одиночного сохранения прогресса это почти не имеет значения; как только сохранения касаются чего-то ценного, запись переезжает на серверную сторону — любого из маршрутов.

Заодно снимем миф, будто «без бэкенда» означает «серверов нет». Все маршруты этой статьи живут на серверах; вопрос — чьих, и кого разбудят, когда они лягут.

Маршрут 1: стор, в котором вы публикуетесь, уже всё держит#

Steam Cloud#

Steam Cloud — файловое хранилище, встроенное в клиент. На странице Steam Cloud в App Admin вы задаёте квоту в байтах и число файлов на пользователя, и файлы, которые пишет игра, после выхода реплицируются на серверы Steam. Когда игрок переезжает на другой компьютер, они скачиваются до запуска — локальный код просто читает диск как обычно.

Маршрут, важный для no-code-разработчика, — Auto-Cloud: Steam Cloud без единой строчки кода и без изменений в игре. Вы перечисляете группы файлов, которые должны переживать сессию, и Steam синхронизирует их при запуске и выходе приложения. Две практические заметки из той же документации: не тащите в синхронизацию настройки конкретной машины вроде качества графики — они будут драться между компьютерами, — и проверяйте всё через встроенный режим, открывающий облако только аккаунтам с лицензией разработчика, прежде чем отдавать его всем игрокам. Если нужен явный контроль, API ISteamRemoteStorage умеет перечислять, читать, писать и удалять облачные файлы прямо из кода.

Google Play Games Services#

На Android сервис Saved Games (API Snapshots) даёт каждому игроку облачное хранилище, привязанное к его личности в Play Games. Цифры для 2D-игры щедрые: файл сохранения ограничен 3 МБ, картинка-обложка — 800 КБ, за хранение денег не берут. Когда данные на устройстве и в облаке расходятся, игра получает обе версии и обязана разрешить спор политикой, которую придумали вы, — обычно выбор оставляют игроку. Офлайн работает: записи копятся локально и синхронизируются, когда связь возвращается. Одна ловушка: игроки в гостевом режиме привязаны к одному устройству, их прогресс не сохраняется и не восстанавливается больше нигде.

В Android есть и второй механизм, который легко принять за этот. Auto Backup выгружает до 25 МБ файловых данных приложения в Google Drive игрока на Android 6.0 и новее, включён по умолчанию и срабатывает, когда система планирует фоновые задачи, — примерно раз в несколько часов. Это фича жизненного цикла устройства, а не игры: она восстанавливает данные при переустановке и смене телефона, но об игровом входе ничего не знает. Оставить включённым — нормально, строить на ней — ошибка.

iCloud#

На платформах Apple NSUbiquitousKeyValueStore — маленький синхронный вариант: хранилище ключей и значений, расходящееся по всем устройствам человека с одним аккаунтом Apple, с жёсткими потолками в 1 024 ключа и 1 МБ на все значения сразу. Сохранение, влезающее в мегабайт, — а большинство 2D-сохранений влезает, — синхронизируется словарным API без серверного кода. Дальше по размеру идёт CloudKit — структурированная база со своими квотами. Личность и лидерборды даёт Game Center, но как общее хранилище сохранений он не годится, поэтому нужная пара — аккаунты Game Center плюс данные в iCloud.

Ограничение, общее для всех трёх сторов, досталось им от их же силы: это замкнутые миры. Сохранение из Steam никогда не встретится с сохранением из Google Play, потому что не встречаются личности, стоящие за ними. Если игра выходит в нескольких сторах и прогресс должен переезжать между ними — это маршрут 2.

Маршрут 2: сервис, чей продукт — ровно это#

Управляемый бэкенд — сервис, чей продукт и есть те четыре работы выше, в упаковке для игр и приложений. Для веб-билдов это ответ по умолчанию: itch.io раздаёт HTML5-игру как статические файлы и серверной стороны, которую можно позвать, не предлагает.

Две строки таблицы заслуживают пристального взгляда. Версионированные записи Nakama — обнаружение конфликтов в виде примитива: у каждого объекта есть версия, запись с устаревшей версией отклоняется, и проигравшая сторона узнаёт, что проиграла. Это ровно тот механизм, который на голой базе данных пришлось бы собирать самому. Уровни доверия PlayFab кодируют решение о целостности: состояние, которое игроку видно, но пишет только сервер, живёт в read-only-данных, а всему экономическому, чего клиент касаться не должен, достаётся уровень, запись в котором для клиента закрыта.

Честная рамка этого маршрута: перед вами бэкенды. Вы их не эксплуатируете — в этом и весь смысл. Первый маршрут — настройка, второй — интеграция, самопис — инженерия.

Маршрут для no-code: движок уже умеет#

Если вы собираете игру в GDevelop, обе половины фичи существуют без кода. Player Authentication встроен: окно аутентификации, баннер, выражения вроде PlayerAuthentication::Username() и PlayerAuthentication::UserID() — последнее документировано как стабильное между сессиями и устройствами для одного аккаунта, а это ровно та ручка, которая облачному сохранению нужна. Половина с данными закрыта официальными расширениями Firebase — для аутентификации, Cloud Firestore и Realtime Database, — так что сохранение задаётся документированным действием, а не самодельным REST-клиентом. Где эти сервисы стоят в общей картине, пока вы выбираете инструмент, разобрано в обзоре no-code 2D-движков.

У остальных no-code-движков аккаунтов игроков нет. У Construct нет собственного сервиса, но его события пишутся на JavaScript и умеют звать любой REST API, так что маршрут 2 применяется напрямую. Пользователи Godot берут фирменные клиенты Nakama или те же REST-вызовы. Везде форма работы одна: войти игроком, прочитать при запуске, записать в контрольных точках, разрешить конфликты, когда о них сообщают.

Часть, которую не показывают в демо: конфликты#

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

• Побеждает свежее. Сравнить метки времени и оставить одну. Просто и коварно: часы устройств расходятся, и «свежим» может оказаться забег, где прогресса меньше. Когда маршрут позволяет, берите метку, которую ставит сервер, а не представление клиента о текущем моменте.
• Решает игрок. Показать оба состояния и дать выбрать — паттерн, который рекомендует Play Games Services. Цена — диалог и немного смирения, а по умолчанию он правильнее всего там, где выбор между «5 часами и замком» и «40 минутами и пещерой» — настоящий.
• Слияние по полям. Объединить изменения поле за полем. Окупается, только когда состояние игры чётко делится на независимые части — настройки, прогресс, коллекции, — и каждое слитое поле придётся отдельно версионировать и тестировать.

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

Сколько на самом деле стоит самопис#

Лёгкий путь соблазняет: одна таблица, один эндпоинт, JSON туда и обратно, сорок строк на бесплатном тарифе. Потом игра выходит — и вместе с ней приезжает настоящий продукт:

• аутентификация с реальными последствиями: сбросы паролей, восстановление аккаунтов и почтовый ящик, которому игроки верят;
• атомарные записи и бэкапы, потому что база сохранений собирает все истории порчи, какие бывают у файлов сохранений;
• логика конфликтов и миграций, которую вы только что прочитали, — теперь без помощи платформы;
• обязанности по защите данных: запросы на выгрузку и удаление достаются вам лично, а не команде комплаенса поставщика;
• лимиты запросов, мониторинг и план на день, когда кончится бесплатный тариф или мигнёт регион.

Ничто из этого не сложно по отдельности; всё вместе — это внимание. Правило из статьи о лидербордах остаётся в силе: пишите сервер сами, когда сервер — часть игры, которую вы делаете; во всех остальных случаях берите маршрут 1 или 2.

Практикум: облачные сохранения за неделю#

1. Составьте список того, что синхронизируется. Состояние игрока и открытые вещи переезжают; производные данные и настройки в основном нет — правило «состояние против пересчитываемого» важнее вдвойне, когда байты покидают устройство.
2. Выбирайте маршрут по месту входа игроков. Сторовые сборки — маршрут 1; веб — маршрут 2 или сервисы движка; игра во многих сторах — маршрут 2 с арендованной личностью.
3. Версионируйте формат до первой выгрузки. Первый контентный патч после релиза — классический момент, когда неверсионированное сохранение ломается.
4. Запишите политику конфликтов одним предложением — до кода. «Выбирает игрок» — законченная политика. Незаписанная политика — баг, который вы обнаружите уже после релиза.
5. Тестируйте как игрок, а не как разработчик. Два устройства, переустановка, отрезок без сети, сохранение двух версий назад. Переустановка — кейс, который ловит ошибки сторового маршрута.
6. Измерьте, сработало ли. Облачные сохранения — ставка на удержание, и руководство по аналитике для инди разбирает числа D1 и D7, по которым видно, сыграла ли ставка.

Частые ошибки#

• localStorage как система сохранений. Это кэш одного браузера, который игрок чистит двумя кликами; постройте на нём — и каждая уборка данных сайта будет читаться как «ваша игра удалила мой прогресс».
• Нет версии формата в полезной нагрузке. Первое обновление после релиза ломает все сохранения разом — ровно в момент, когда ваши самые преданные игроки играют.
• Нет политики конфликтов. Не выбрать — значит выбрать «побеждает последняя запись» с клиентскими часами, худшую версию самого дешёвого правила.
• Доверие клиенту там, где есть цена. Валюта, открытия, привязанные к покупкам, прогресс по соседству с лидербордами: если это важно, запись должна жить на сервере — для того и существует read-only-уровень PlayFab.
• Путать Auto Backup с облачными сохранениями. Auto Backup восстанавливает устройство, а не игрока; постройте на нём — и на взятом напрокат телефоне прогресса не окажется, а исправления у вас не будет.
• Тестировать только на чистых установках. Чистые установки не конфликтуют никогда. Два устройства с историей — вот где начинается настоящий дизайн.
• Строить аккаунты раньше, чем они нужны игре. Вход перед сырой игрой никого не конвертирует; руководство по первой мобильной игре и плейбук сообщества до релиза — рычаги, которые вообще приводят игроков к вашей системе сохранений.
• Игнорировать лидерборд по соседству. Игроки читают аккаунты, сохранения и таблицы рекордов как одну фичу — «мои вещи»; спроектируйте личность один раз, чтобы всё это держалось на ней.

Где здесь Egmatic#

О стадии скажем прямо: Egmatic — no-code 2D-редактор и движок, построенный на ИИ, сейчас в pre-alpha. Статья вышла на нашем блоге не случайно: в читках сообщества, которые мы проводим, сохранения и аккаунты без бэкенда — один из самых повторяющихся запросов, сразу за лидербордами, и звучит он так же — как смирение с неизбежной серверной работой. Этот спрос стоит в нашем роадмапе внутри слоя публикации — стороны редактора, отвечающей за выпуск игры, — потому что сохранение прогресса — забота уровня публикации: игроки её ждут, а no-code-разработчик не должен собирать её из базы данных и туториала. Дату мы здесь не анонсируем: честность pre-alpha означает, что даты появляются, когда мы можем их сдержать.

Рамка, к которой мы идём, — та же, что и во всей статье: вы направляете игру, инструментарий исполняет обвязку, а результат — включая сохранения — принадлежит вам. Если вы ждёте 2D-редактор, чей слой публикации включает аккаунты, облачные сохранения и лидерборды, — смотрите, как он обретает форму, в листе ожидания на egmatic.com, и расскажите там, что должны уметь ваши сохранения: в pre-alpha запросы, приходящие сейчас, — те, что ведут разработку.

Заключение#

Маршрут выбирайте по месту, где ваши игроки входят в аккаунт: личность решает всё, что происходит дальше. В сторе облачные сохранения — это настройка: Auto-Cloud в Steam не требует ни строчки кода, Saved Games из Play Games даёт 3 МБ на сохранение и крючок для разрешения конфликтов, а хранилище iCloud синхронизирует мегабайт состояния между устройствами Apple. В вебе и между сторами обвязку арендуют: Firebase для мягкого старта, Nakama за открытый код и версионированные записи, PlayFab или LootLocker — когда важны входы через платформы и уровни доверия. Политику конфликтов записывайте до кода, версию формата — до первой выгрузки, и обращайтесь с данными игрока как с его собственностью: доверие, которое заработала система сохранений, — то тихое удержание, которое не купит ни одна страница в сторе.

Источники#

1. Документация Steamworks — Steam Cloud: Auto-Cloud без изменений кода, синхронизация групп файлов при запуске и выходе, квоты в байтах и числе файлов на пользователя в App Admin, режим проверки на аккаунтах с лицензией разработчика, API ISteamRemoteStorage
2. Android Developers — Play Games Services Saved Games: лимиты 3 МБ на файл сохранения и 800 КБ на обложку, хранение без оплаты, проектирование политики разрешения конфликтов, привязка гостевого режима к одному устройству, офлайн-записи с асинхронной синхронизацией
3. Android Developers — Back up user data: Auto Backup выгружает до 25 МБ файловых данных приложения в Google Drive, Android 6.0 и новее, включён по умолчанию, фоновые запуски раз в несколько часов
4. Apple Developer — NSUbiquitousKeyValueStore: не больше 1 024 ключей, 1 МБ на все значения, распространение на устройства одного аккаунта Apple
5. Firebase — Pricing: аутентификация без оплаты до 50 тысяч активных пользователей в месяц, бесплатный тариф Cloud Firestore — 1 ГиБ данных, 20 тысяч записей в день, 10 ГиБ исходящего трафика в месяц
6. Heroic Labs — Nakama Storage Engine: коллекции и объекты с JSON-содержимым, права по владельцу, условные записи с отклонением при провале проверки версии; GitHub — heroiclabs/nakama, лицензия Apache-2.0
7. Microsoft Learn — PlayFab Player Data: данные игрока парами ключ-значение с уровнями доверия read-only, publisher и internal
8. LootLocker — Pricing: триал 30 дней с потолком 1 000 активных игроков в месяц, бесплатная некоммерческая лицензия, $0,015 за дополнительного MAU; входы через платформы — по документации
9. GDevelop Wiki — Player Authentication: окно аутентификации и баннер, PlayerAuthentication::UserID() стабилен между сессиями и устройствами; расширения Firebase для аутентификации и баз данных