Ми спеціалізуємося на розробці мультиплеєра реального часу для мобільних ігор. Це не просто WebSocket та відправка координат — це керування затримкою 50–200 мс, компенсація втрат, синхронізація фізики та робота з нестабільним 4G. Мобільний клієнт втрачає пакети частіше за десктоп: зміна WiFi на LTE, фоновий режим ОС — і наївна реалізація ламається вже на перших тестах. Втрати в 5% звичайні для мобільних мереж, а додаткові 100 мс затримки призводять до неприйнятного досвіду. Наша команда має 10+ років досвіду в розробці мобільних ігор та реалізувала понад 20 мультиплеєрних проєктів. Ми пропонуємо рішення під ключ, від архітектури до деплою, включаючи економію до 40% трафіку за рахунок дельта-компресії. У цій статті розберемо ключові технічні рішення: авторитарний сервер, client prediction, lag compensation та мобільні оптимізації.
Розробка мультиплеєра реального часу: ключові завдання
Перша помилка — довіряти клієнту. Клієнт надсилає «я перемістився сюди», сервер застосовує без перевірки. За тиждень чітери телепортуються по карті. Правильна архітектура: authoritative server. Клієнт надсилає введення (натиснуті кнопки, вектор руху), сервер симулює фізику та розсилає результуючі стани. Клієнт застосовує ті самі обчислення локально — це client-side prediction. Коли приходить відповідь сервера, клієнт виконує reconciliation — відкат до останнього підтвердженого стану та відтворення буфера непідтверджених введень. Як зазначено в документації Unity Netcode, такий підхід обов'язковий для competitive-ігор.
Як працює client-side prediction на практиці?
Кожен такт гри (зазвичай 20–60 Hz для мобільних):
- Клієнт надсилає
InputPayload { tick, moveDirection, shootPressed }. - Сервер застосовує введення, обчислює
StatePayload { tick, position, health, ... }. - Сервер розсилає снэпшот усім клієнтам (не кожен такт — застосовується delta compression).
- Клієнт отримує снэпшот, порівнює з передбаченим станом і коригує.
Delta compression критична для мобільного: замість повного стану світу (300 байт) розсилаються лише зміни (10–30 байт). При 20 Hz на 10 гравців різниця між повним станом та delta — трафік 60 КБ/с vs 6 КБ/с. Client-side prediction в 3 рази краще очікування підтвердження сервера за затримкою.
UDP чи TCP: що обрати для мобільного real-time?
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-модуль переходить у power-saving режим і додає 30–80 мс до latency. Перехід з 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 |
Порівняння фреймворків — розробка мультиплеєра мобільної гри
| Фреймворк | Протокол | Вартість | Мобільна підтримка |
|---|---|---|---|
| Photon Realtime | UDP + надійний | Безкоштовно до 20 CCU, далі платно | iOS, Android, Web |
| Mirror | UDP (LLAPI) | Безкоштовно | iOS, Android |
| Netcode for GO | UDP (Unity Transport) | Безкоштовно | iOS, Android |
| LiteNetLib | UDP | Безкоштовно | iOS, Android, Desktop |
Що входить у роботу
- Архітектурна документація: вибір протоколу, схема синхронізації, обробка помилок.
- Серверний код: authoritative server, lag compensation, дельта-компресія.
- Клієнтська інтеграція: client prediction, interpolation, reconnect.
- Тестування на реальних пристроях: 10+ моделей, різні версії ОС.
- Деплой: налаштування серверної інфраструктури, моніторинг.
- Навчання команди замовника: код-рев'ю, документація, супровід 1 місяць.
Етапи розробки мультиплеєра реального часу
Аудит вимог (жанр, кількість гравців, платформи) → вибір фреймворку → прототип з базовою синхронізацією позицій → реалізація client prediction та reconciliation → lag compensation на сервері → навантажувальне тестування → полірування під мобільні обмеження. Прототип з базовим мультиплеєром для 2–4 гравців: 3–4 тижні. Повноцінна real-time система на 10–20 гравців з lag compensation та мобільною оптимізацією: 2–4 місяці. Вартість розраховується індивідуально.
Зв'яжіться з нами для оцінки вашого проєкту. Замовте розробку прототипу за 3–4 тижні — ми проконсультуємо вас з архітектури та запропонуємо оптимальне рішення. Отримайте консультацію інженера, який спеціалізується на мобільних real-time системах.