Разработка мультиплеера мобильной игры (пошаговый)
Пошаговый мультиплеер проще real-time в части сетевой части, но сложнее в части UX и серверной логики. Игроки ходят по очереди, соединение не нужно держать постоянно — но нужно обеспечить корректный порядок ходов, валидацию на сервере, уведомления и восстановление сессии после выхода.
Серверная валидация ходов
Главная ошибка — доверять клиенту в валидации хода. Клиент проверил «ход допустим» и отправил на сервер. Читер перехватывает трафик и отправляет невалидный ход напрямую. Сервер применяет без проверки. Итог — сломанное игровое состояние.
Правильная схема: сервер хранит авторитарное состояние игры. Клиент отправляет намерение (moveFrom: e2, moveTo: e4 в шахматах), сервер проверяет допустимость по правилам, применяет, рассылает новое состояние всем участникам. Клиент только рендерит то, что пришло с сервера.
На практике это означает: логика правил игры живёт на сервере. Для Unity — отдельный серверный проект (headless build) или микросервис на Go/Node.js с портированной игровой логикой.
Управление сессией и push-уведомления
В пошаговом мультиплеере соединение не нужно держать постоянно. После хода игрок может закрыть приложение. Следующий ход противника должен прийти через push-уведомление: FCM на Android, APNs на iOS.
Серверная сторона хранит токен устройства, при смене очереди отправляет notification через FCM sendMulticast или APNs HTTP/2. Клиент по тапу на уведомление открывает конкретную сессию игры — нужен deep link с game_session_id.
Firebase Cloud Messaging на Android — FirebaseMessagingService, переопределяем onMessageReceived. На iOS — UNUserNotificationCenter + UNNotificationRequest. Важно: на iOS нужен content-available: 1 для фонового обновления состояния без показа баннера.
Восстановление состояния
Игрок выходит в середине матча. Сервер хранит полный лог ходов (event sourcing). При reconnect клиент получает GameStateSnapshot — текущее состояние — и рендерит без replay истории. История нужна только для отображения «журнала ходов».
Таймаут хода: сервер запускает таймер после смены очереди. Если игрок не ходит за N минут — авто-ход или поражение по timeout. Реализация через ScheduledExecutorService на JVM-бэкенде или setTimeout в Node.js с хранением jobId в Redis.
Matchmaking для пошаговых игр
Рейтинговый матчмейкинг по ELO: при старте поиска клиент отправляет findMatch с текущим рейтингом. Сервер ищет в очереди игрока с рейтингом ±150 очков. Если через 30 секунд не найден — расширяет диапазон до ±300. Через 60 секунд — предлагает играть с ботом.
Реализация очереди: Redis Sorted Set, где score = рейтинг игрока. Поиск в диапазоне через ZRANGEBYSCORE. Атомарность через Lua-скрипт или Redis транзакции — иначе два матчмейкера могут забрать одного игрока дважды.
Сроки
Пошаговый мультиплеер для 2 игроков с базовым матчмейкингом, push-уведомлениями и серверной валидацией: 3-6 недель. Поддержка комнат, наблюдателей, асинхронных матчей — добавляет 2-3 недели. Стоимость рассчитывается индивидуально.