Розробка real-time мультиплеєра для мобільних ігор
Real-time мультиплеєр в мобільній грі—це не просто WebSocket та відправка координат. Це управління затримкою 50-200 мс, компенсація втрати пакетів, синхронізація фізики та робота з ненадійним 4G. Мобільні клієнти втрачають пакети частіше, ніж десктоп: WiFi→LTE, тунелі, фоновий режим—все це ламає наївну реалізацію на перших тестах.
Архітектура: авторитарний сервер та передбачення на клієнті
Перша помилка—довіра клієнту. Клієнт надсилає «я переміщений сюди», сервер застосовує. Через тиждень читери телепортуються по карті.
Правильна архітектура: authoritative server. Клієнт надсилає вхід (натиснуті кнопки, вектор руху), сервер симулює фізику, розсилає результуючі стани. Клієнт застосовує ті ж обчислення локально—client-side prediction. Коли приходить відповідь сервера, клієнт порівнює: якщо відхилення перевищує поріг, застосувати reconciliation—відкат до останнього підтвердженого стану та повторне застосування буфера неперевірених входів.
У Unity через Netcode for GameObjects або Mirror, але архітектурний паттерн однаковий. Кожний тик гри (типово 20-60 Hz для мобільних):
- Клієнт надсилає
InputPayload { tick, moveDirection, shootPressed } - Сервер застосовує вхід, обчислює
StatePayload { tick, position, health, ... } - Сервер розсилає снимок всім клієнтам (зазвичай не кожен тик—delta compression)
- Клієнт отримує снимок, порівнює з передбаченим станом, коригує
Delta compression критична для мобільного: замість повного стану світу (300 байт) розсилати тільки зміни (10-30 байт). При 20 Hz на 10 гравців: повний стан = 60 КБ/с vs delta = 6 КБ/с.
Транспортний шар: UDP vs TCP
TCP гарантує доставку та порядок пакетів через retransmit при втраті. У real-time грі втрачений пакет з позицією гравця з 200 мс назад непотрібен—потрібна поточна позиція. TCP чекатиме і переотправлятиме застарілі дані, поки нові чекають у черзі. Це додає 100-400 мс видимої затримки на поганих каналах.
UDP—надсилай і забув. Втрати обробляються на рівні застосунку: позиційні оновлення не потребують надійності (новіший пакет перекриває старший), критичні події (урон, смерть) потребують підтвердження—реалізується через просту ACK-схему поверх UDP.
На мобільних платформах raw UDP доступний через System.Net.Sockets.UdpClient у Unity або NWConnection з .udp на iOS. Android використовує DatagramSocket через Java/Kotlin.
На практиці: Photon Realtime використовує власний протокол поверх UDP з вбудованою надійною доставкою для критичних повідомлень. LiteNetLib—open-source альтернатива з аналогічними можливостями.
Lag compensation та інтерполяція
На клієнті об'єкти інших гравців не рухаються безпосередньо за снимками—це викликає ризикованість на нестабільному з'єднанні. Interpolation: клієнт зберігає буфер останніх 2-3 снимків та рендерить стан з затримкою 50-100 мс, інтерполюючи між ними. Рух стає плавним за ціною штучної затримки.
Lag compensation на сервері: коли гравець A стріляє у гравця B, сервер «перемотує» стан світу на RTT/2 назад і перевіряє колізію, де B був з точки зору A. Без цього влучити у швидкого суперника при високому пінгу фізично неможливо.
Мобільні особливості
iOS фоновий режим (через 5-10 сек UIApplicationWillResignActiveNotification) розриває сокет. Потрібен BGTaskScheduler для фонового reconnect або graceful disconnect з збереженням сесії на сервері.
Android: WakeLock та WifiLock для утримання з'єднання під час матчу. Без WifiLock.WIFI_MODE_FULL_HIGH_PERF WiFi-модуль переходить у режим енергозбереження та додає 30-80 мс до затримки.
WiFi→мобільний переклад—ConnectivityManager.NetworkCallback на Android, NWPathMonitor на iOS. При зміні мережі—швидкий reconnect без втрати ігрової сесії.
Стек та інструменти
| Компонент | Варіанти |
|---|---|
| Мережевий фреймворк | Photon Realtime, Mirror, NGO, LiteNetLib |
| Транспорт | UDP, Photon Cloud, WebSocket (fallback) |
| Сервер | Photon Server, Nakama, custom Node.js/Go |
| Синхронізація | Snapshot interpolation + client prediction |
| Профілювання | Unity Profiler, Photon Dashboard, Wireshark |
Графік
Аудит вимог (жанр, кількість гравців, платформи) → вибір фреймворку → прототип базової синхронізації → client prediction та reconciliation → lag compensation на сервері → нагрузочне тестування → мобільна оптимізація.
Прототип для 2-4 гравців: 3-4 тижні. Повнофункціональна real-time система для 10-20 гравців з lag compensation та мобільною оптимізацією: 2-4 місяці. Вартість розраховується індивідуально.