Розробка пошагового мультиплеєра для мобільних ігор
Пошаговий мультиплеєр простіший ніж real-time щодо мережі, але складніший у UX та серверній логіці. Гравці ходять по черзі, з'єднання не потрібно тримати постійно—але потрібно забезпечити правильний порядок ходів, валідацію на сервері, сповіщення та відновлення сесії після виходу.
Серверна валідація ходів
Головна помилка—довіра до валідації клієнта. Клієнт перевірив «хід допустимий» та надіслав на сервер. Читер перехоплює трафік та надсилає невалідний хід безпосередньо. Сервер застосовує. Результат—зламаний ігровий стан.
Правильна схема: сервер зберігає авторитарне ігрове стан. Клієнт надсилає намір (moveFrom: e2, moveTo: e4 у шахматах), сервер перевіряє допустимість за правилами, застосовує, розсилає новий стан всім учасникам. Клієнт тільки рендерить те, що прийшло з сервера.
На практиці: логіка правил гри живе на сервері. Для Unity—окремий headless проект або мікросервіс на Go/Node.js з портованою ігровою логікою.
Управління сесією та push-сповіщення
Пошаговий не потребує постійного з'єднання. Після ходу гравець може закрити застосунок. Наступний хід опонента повинен прийти через push-сповіщення: FCM на Android, APNs на iOS.
Сервер зберігає токен пристрою, при зміні очереди надсилає сповіщення через 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 хвилин—авто-хід або поразка за таймаутом. Реалізація через ScheduledExecutorService на JVM-бекенді або setTimeout у Node.js з збереженням jobId у Redis.
Матчмейкинг для пошагових ігор
Рейтинговий матчмейкинг по ELO: при старте пошуку клієнт надсилає findMatch з поточним рейтингом. Сервер шукає в черзі гравця з рейтингом ±150 очків. Якщо через 30 секунд не знайден—розширює до ±300. Через 60 секунд—пропонує гру з ботом.
Реалізація черги: Redis Sorted Set, де score = рейтинг гравця. Пошук у діапазоні через ZRANGEBYSCORE. Атомарність критична: два матчмейкери не повинні одночасно забрати одного гравця. Lua-скрипт у Redis—єдина атомарна операція «знайди та видали»:
local candidates = redis.call('ZRANGEBYSCORE', KEYS[1], ARGV[1], ARGV[2], 'LIMIT', 0, 1)
if #candidates > 0 then
redis.call('ZREM', KEYS[1], candidates[1])
return candidates[1]
end
return nil
Без цього при горизонтальному масштабуванні матчмейкера один гравець потрапляє у два матчі одночасно.
Графік
Пошаговий мультиплеєр для 2 гравців з базовим матчмейкингом, push-сповіщеннями та серверною валідацією: 3-6 тижнів. Підтримка кімнат, спостерігачів, асинхронних матчів—додає 2-3 тижні. Вартість розраховується індивідуально.