Игроки с разными часовыми поясами, обрывы интернета, потеря прогресса — типичные боли асинхронного мультиплеера. Как обеспечить корректную синхронизацию ходов, когда пользователь может уйти в офлайн на несколько часов? Наше решение — event sourcing с версионированием состояния и offline-first архитектура. За 10 лет мы реализовали асинхронный мультиплеер в 30+ проектах с суммарной аудиторией более 2 млн пользователей. Закажите разработку асинхронного мультиплеера, чтобы ваши игроки могли делать ходы в любое время без потери прогресса.
Асинхронный мультиплеер: ключевые архитектурные решения
Хранение состояния и версионирование
Каждый ход — транзакция в БД. Структура записи: game_id, move_number, player_id, action_payload (JSON), timestamp, resulting_state_hash. Hash состояния после каждого хода позволяет обнаружить расхождение. Event Sourcing сохраняет полную историю действий: можно восстановить любой момент игры, реализовать replay, аудит и откат при багах. В проекте с 500 000 установок такой подход сократил время на баг-фиксинг на 60%.
Синхронизация через polling и WebSocket
При старте сессии клиент делает GET /game/{id}/state и получает состояние с version. Дальше два варианта уведомлений: polling каждые 30-60 секунд или WebSocket/SSE при открытом приложении + push при закрытом. Polling нагружает сервер на 40% больше. Лучше: при открытом приложении — WebSocket, при закрытом — FCM/APNs push. При получении push клиент делает GET /game/{id}/state?since_version={lastKnown} и получает только изменения. Гибрид снижает трафик в 3 раза.
Почему event sourcing лучше для асинхронного мультиплеера?
Event sourcing сохраняет все ходы как последовательность событий. Это даёт возможность:
- откатить игру к любому моменту;
- реализовать replay для зрителей (ghosting);
- проводить аудит баланса и обнаруживать читерство.
В отличие от хранения только текущего состояния, event sourcing позволяет легко исправлять ошибки игровой логики без потери данных. На практике используем PostgreSQL с event store или Firebase Firestore с коллекцией moves. Сравним оба подхода:
| Критерий | Event Sourcing | Хранение текущего состояния |
|---|---|---|
| Восстановление любого момента | Да | Нет |
| Replay | Легко | Сложно |
| Аудит | Полный трейл | Ограничен |
| Объём данных | Высокий | Низкий |
| Сложность | Средняя | Низкая |
Как мы разрешаем конфликты при одновременных ходах?
Конфликты возникают, если оба игрока отправили ход одновременно (например, из-за бага клиента). Сервер принимает только первый по timestamp и возвращает ошибку второму с актуальным состоянием. Для более сложных сценариев (одновременные ходы в непошаговых режимах) используем Conflict-free Replicated Data Types (CRDT), но для асинхронных пошаговых игр достаточно timestamp + hash. Средняя задержка уведомления при открытом приложении — 2–5 секунд.
Механизм синхронизации ходов при асинхронном мультиплеере
Для надёжной синхронизации используем комбинацию WebSocket (активная сессия) и push-уведомлений (закрытое приложение). Если соединение прерывается, клиент переключается на polling с экспоненциальным бэкоффом: первая задержка 1 сек, затем 2, 4, 8 и т.д. до 60 сек. Это гарантирует доставку хода даже при временном разрыве.
Offline-first UX
Пользователь делает ход без интернета — ход сохраняется локально и отправляется при восстановлении соединения. На Android — WorkManager с NetworkType.CONNECTED: задача выполнится при появлении интернета, даже если приложение закрыто.
val constraints = Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .build() val submitMoveRequest = OneTimeWorkRequestBuilder<SubmitMoveWorker>() .setConstraints(constraints) .setInputData(workDataOf("move_payload" to moveJson)) .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 30, TimeUnit.SECONDS) .build() WorkManager.getInstance(context).enqueue(submitMoveRequest) На iOS — BGProcessingTask с requiresNetworkConnectivity = true. Ход сохраняется в Core Data, задача отправляет при ближайшей возможности. По статистике из наших проектов, 95% ходов доставляются в течение 30 секунд после восстановления связи.
Сравнение методов синхронизации
| Метод | Задержка | Нагрузка на сервер | Офлайн |
|---|---|---|---|
| Polling (30-60с) | Средняя | Высокая | Не поддерживает |
| WebSocket | Минимальная | Умеренная | Требуется reconnect |
| WebSocket + Push | Минимальная | Умеренная | Поддерживает |
Что входит в работу
- Архитектура серверной части (БД, API, WebSocket)
- Клиентский SDK для iOS и Android (Swift/Kotlin)
- Логика ходов, версионирование, обработка конфликтов
- Offline-очередь и синхронизация (WorkManager, BGProcessingTask)
- Push-уведомления (FCM/APNs)
- Документация API и интеграции
- Тестирование (юнит, интеграционное, нагрузочное)
- Сопровождение после запуска (2 месяца)
Процесс работы
- Анализ игровой механики и требований
- Проектирование архитектуры (схема БД, API контракты)
- Реализация серверной логики (NestJS/PostgreSQL или Firebase)
- Интеграция клиентского кода (Swift/Kotlin)
- Тестирование синхронизации и офлайн-сценариев
- Деплой и мониторинг
Сроки и оценка
Базовая асинхронная система для 2 игроков с event sourcing, offline-first и push-уведомлениями: 2-4 недели. Стоимость рассчитывается индивидуально после анализа игровой механики. Более сложные конфигурации (больше игроков, CRDT) — от 3 до 6 недель. Наши клиенты экономят от 30% до 50% времени на разработке по сравнению с синхронным мультиплеером благодаря переиспользованию компонентов и готовым шаблонам.
Доверие и опыт
Наша команда разработала более 30 мобильных игр с мультиплеером, включая проекты с 500 000+ установок. Мы гарантируем соблюдение сроков и прозрачное взаимодействие. Работаем под ключ: от идеи до публикации в магазинах. Получите консультацию — расскажите о своей игровой механике, и мы предложим оптимальное решение. Свяжитесь с нами, чтобы обсудить ваш проект и получить индивидуальную оценку.