Асинхронный мультиплеер без сервера: 5 рабочих схем

Асинхронному мультиплееру нужно общее хранилище, а не живой игровой сервер — и именно это различие позволяет соло-разработчику выпустить сетевую игру вообще. Пять схем закрывают почти всё, что нужно небольшим играм: партия по очереди на одном устройстве, ходы, которыми обмениваются как облачными документами, асинхронные очереди и почтовые ящики, клиентская idle-экономика с синхронизацией и гонки с записанными призраками. Ни одна не заставит вас поднимать сервер, патчить его и караулить по ночам.

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

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

Если игрокам не нужно действовать в одну и ту же секунду, игровой сервер вам не нужен. Нужны общее место, куда оба устройства могут и писать, и читать, и правило, решающее, чья запись побеждает:

Одна честная сноска: «без сервера» значит без сервера вашего. Управляемое хранилище вроде Firestore тоже живёт на серверах — просто на серверах Google. Исчезает не сервер, а операционная работа: нет процесса, который надо держать живым, нет патчей безопасности, нет звонков в три часа ночи. Для соло-разработчика эта разница решает всё.

Что на самом деле значит «асинхронный»#

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

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

Схема 1: партия на одном устройстве#

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

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

Схема 2: ходы как облачные документы#

Рабочая лошадка. Представьте партию одним документом — состояние доски, чья очередь ходить, пронумерованный журнал ходов — и положите его в управляемую базу документов вроде Firestore или Supabase. Ход игрока дописывается в журнал и переключает поле turn. Клиент соперника читает документ, проверяет ход против правил локально и рисует результат.

Основную работу тянут три вещи:

• Правила безопасности хранилища решают, кому можно писать: «игрок A дописывает ход, только когда turn == A» — это правило, а не сервер.
• Push-уведомления сообщают сопернику, что ход ждёт. Cloud Messaging в Firebase бесплатен.
• Бесплатного тарифа действительно хватает. Квоты Firestore без оплаты — 1 ГиБ хранения, 50 000 чтений и 20 000 записей в день — тянут партию по переписке на сотни активных игроков: каждый ход — одна маленькая запись и одно чтение.

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

Схема 3: очереди и почтовые ящики#

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

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

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

Схема 4: клиентская idle-экономика с синхронизацией#

В сообществах разработчиков, которые мы читаем, одна и та же сцена повторяется из раза в раз: соло-разработчик собирает idle-игру в жанре 4X, игроки заходят в разное время, и встаёт вопрос, где живёт общая экономика. Ответ без сервера: экономика живёт на клиенте и вычисляется из меток времени.

Idle-экономика — это функция, а не цикл симуляции. Получив state_at_last_sync и now, клиент вычисляет, сколько игрок заработал, — одинаково, оффлайн он был или онлайн. Синхронизация превращается в обмен запросами: «вот моя последняя точка синхронизации, начислите мне это окно». Единственная серверная часть, которую вы при этом пропускаете, — покадровая симуляция: пока никто не играет, ничего не должно работать.

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

Схема 5: призраки и гонки со сдвигом времени#

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

Как выбирать между схемами#

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

Конфликты без арбитра#

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

• Поля версий. Каждый документ носит версию, и запись обязана назвать версию, на которую опирается. Запись с устаревшей версией отклоняется — клиент перечитывает документ и пробует снова.
• Монотонные номера ходов. В журнале ход 14 не может прийти раньше хода 13. Порядок и есть сам номер.
• «Побеждает последняя запись» — только для косметики. Новейшей записи можно отдавать отображаемое имя и настройки; валюте, инвентарю и состоянию хода — никогда: «новейшая» здесь значит «у кого пакет пришёл последним».

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

Честная граница: когда асинхронного мультиплеера перестаёт хватать#

Три сигнала говорят, что вы вышли из территории «без сервера»:

1. Игроки действуют в одном состоянии в один и тот же момент. Кооператив в реальном времени, бой на рефлексах, общая физика — обмен документами не вывезет живую симуляцию.
2. У исходов появляются ставки, которые стоит защищать. Рейтинговые сезоны, торговые экономики, призовые фонды — числа, которым верит клиент, подделают, и снисходительность перестанет быть стратегией.
3. Незнакомцы должны встречаться в масштабе. Матчмейкинг, лобби и присутствие тысяч игроков одновременно — задача живых систем.

Выход за границу не значит писать сервер самому: проблему можно арендовать как продукт. Управляемые игровые бэкенды вроде PlayFab (оплата по факту использования, есть бесплатный тариф) и Epic Online Services (бесплатны) — готовые варианты; Nakama — открытый код под лицензией Apache-2 с самохостингом на любом облаке и Postgres-совместимой базой рядом, со встроенным пошаговым и реальным мультиплеером, а есть и управляемый вариант Heroic Cloud. Движковые API идут тем же течением: высокоуровневый мультиплеер Godot и плагин Multiplayer в Construct по-прежнему предполагают, что одна из машин служит авторитетным хостом. В этой точке вы не избавляетесь от сервера — вы выбираете, чей он, и наблюдаете за ним со стороны вместо того, чтобы обслуживать руками.

Роль Egmatic#

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

Если решения из этой статьи вы принимаете прямо сейчас, лист ожидания на egmatic.com — то место, где вы влияете на то, что слой публикации возьмёт на себя: сохранения, таблицы рекордов, асинхронные матчи. Ответ тогда строится в сам слой, а не прикручивается к игре потом.

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

• Проектировать реальное время там, где хватило бы асинхронной схемы. Спросите себя, переживёт ли игра минутную паузу между ходами. Большинство кооперативных и казуально-соревновательных дизайнов — да, и асинхронная версия выходит вдвое быстрее.
• Опрашивать вместо того, чтобы сообщать. Клиент, перечитывающий партию каждые три секунды, сжигает бесплатную квоту чтений и батарею. Push-уведомления в Firebase бесплатны — пусть они и говорят «ход ждёт».
• Хранить снимки вместо журнала ходов. Снимок доски на каждый ход нельзя ни проиграть, ни рассудить в споре; пронумерованный список ходов можно. Журнал — та схема, которая делает конфликты послушными.
• Верить числам клиента без ограничителей. Если клиент отчитывается о заработке, ограничьте его сверху. Абсурдная заявка должна быть видна сразу, а не всплывать на форуме через месяц.
• Отдавать победу последней записи в том, что имеет цену. Для отображаемого имени — приемлемое правило; для валюты, инвентаря и ходов — катастрофа.

Вывод#

Асинхронный мультиплеер — не урезанная версия реального времени. Это другое дизайнерское пространство почти без инфраструктуры, и большинство небольших игр живёт в нём с комфортом. Начните с самой свободной паузы, которую выдерживает игра. Представляйте каждый обмен как записи с явным порядком. И относитесь к переезду на настоящий бэкенд как к переходу на следующий класс: он случается не раньше, чем появятся основания — одновременность, ставки или масштаб. Выпустите асинхронную версию первой. Если игра заработает сервер, вы будете точно знать, зачем он ей.