Розробка мультиплеєра реального часу для мобільних ігор

Ми спеціалізуємося на розробці мультиплеєра реального часу для мобільних ігор. Це не просто 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 для мобільних):

1. Клієнт надсилає InputPayload { tick, moveDirection, shootPressed }.
2. Сервер застосовує введення, обчислює StatePayload { tick, position, health, ... }.
3. Сервер розсилає снэпшот усім клієнтам (не кожен такт — застосовується delta compression).
4. Клієнт отримує снэпшот, порівнює з передбаченим станом і коригує.

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 без втрати ігрової сесії.

Стек та інструменти

Порівняння фреймворків — розробка мультиплеєра мобільної гри

Що входить у роботу

• Архітектурна документація: вибір протоколу, схема синхронізації, обробка помилок.
• Серверний код: 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 системах.

Інтеграція API в мобільний додаток: з чого почати

Запит йде, відповідь не приходить, timeout — 30 секунд. Користувач дивиться на спінер. Мережі немає — мобільна карта в метро. Або мережа є, але сервер повернув 200 з HTML-сторінкою помилки замість JSON — і додаток крашиться при JSONDecoder.decode(). Ми бачимо такі кейси на кожному другому проєкті. Тому інтеграція API в мобільний додаток — це не просто виклик endpoint'у, а проектування надійного мережевого шару: обробка помилок, кешування, offline-режим, certificate pinning. Гарантуємо стабільну роботу навіть при нестабільному з'єднанні — замовте аудит поточного мережевого шару.

Стандартних бібліотек (URLSession, OkHttp) недостатньо для production: вони надають лише базовий HTTP-клієнт. Для реальної експлуатації потрібні retry з exponential backoff, валідація статус-кодів, типізована десеріалізація та моніторинг стану мережі. Без цього додаток втрачає дані та користувачів. Ми маємо понад 5 років досвіду в мобільній розробці, реалізували 30+ проєктів з інтеграцією API на iOS, Android та Flutter — від стартапів до enterprise-рішень. Сертифіковані iOS/Android розробники гарантують якість коду.

Як вибрати протокол для інтеграції API?

REST залишається стандартом для більшості проєктів. Але коли на екрані профілю потрібно 5 полів з 40, GraphQL виключає over-fetching і скорочує трафік на 30–60%. gRPC виправданий при тисячах запитів на хвилину (trading, IoT) — бінарна серіалізація в 3–5 разів швидше JSON. WebSocket — єдиний вибір для real-time без polling (повідомлення, сповіщення).

Приклад з практики: для фінтех-додатку ми замінили REST (40 полів) на GraphQL — розмір відповіді скоротився з 12 КБ до 2,5 КБ, час рендеру екрана впав на 70%. Економія трафіку була значною при 100 000 активних користувачів.

Як забезпечити надійність з'єднання та offline-first?

Користувачі втрачають мережу в метро, ліфті, тунелі. Мобільний додаток зобов'язаний працювати без інтернету — хоча б у read-only режимі. Ми впроваджуємо патерн offline-first:

1. При відкритті екрану спочатку показуємо дані з локального кешу (Core Data / Room).
2. Паралельно виконуємо мережевий запит, оновлюємо UI після відповіді.
3. Якщо мережа недоступна — показуємо кешовані дані та позначку «немає з'єднання».
4. При відновленні мережі автоматично синхронізуємо зміни.

Для кешування HTTP-відповідей використовуємо URLCache (iOS) та OkHttp Cache (Android) з підтримкою Cache-Control. Для структурованих даних — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback відстежують стан мережі та тригерять оновлення. Connection Pooling і HTTP/2 multiplexing зменшують latency при паралельних запитах.

REST та вибір клієнтської бібліотеки

Alamofire (iOS) — де-факто стандарт для Swift-проєктів. Поверх URLSession додає request chaining, response validation, automatic retry, certificate pinning через ServerTrustManager. AF.request() з .validate() повертає помилку для будь-якого статус-коду поза 200–299. Без .validate() Alamofire вважає 404 та 500 успішними відповідями. З Swift Concurrency — async-версія через serializingDecodable.

Retrofit (Android) — анотаційний HTTP-клієнт поверх OkHttp. Інтерфейс з анотаціями компілюється в реалізацію. @GET, @POST, @Path, @Query, @Body — декларативний опис API. OkHttp під капотом: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — логування в debug-збірці. Authenticator — автоматичний refresh токена при 401. Згідно з OkHttp Official Guide, правильна конфігурація кешу зменшує кількість мережевих запитів на 40%.

Ktor (KMM/Flutter) — мультиплатформний HTTP-клієнт. На iOS працює через Darwin engine (URLSession), на Android — через OkHttp. Єдиний код для обох платформ при KMM-архітектурі.

GraphQL: коли REST не справляється

REST повертає фіксовану структуру. Екран профілю вимагає name, avatar, email — сервер віддає 40 полів. Over-fetching. GraphQL вирішує це: клієнт запитує рівно потрібні поля. Це критично для мобайлу, де трафік і час парсингу — реальні обмеження. Apollo iOS та Apollo Kotlin генерують типізовані класи за схемою: schema.graphql + query-файли → строгі типи на етапі компіляції. Subscriptions через WebSocket — real-time без polling. Обмеження: GraphQL складніше кешувати на рівні HTTP. Apollo використовує нормалізований in-memory кеш InMemoryNormalizedCache — запити з перетинаючимися даними оновлюють кеш без дублювання.

WebSocket: real-time без зайвого трафіку

Polling (setInterval кожні 5 секунд) — витрата батареї та трафіку. WebSocket — постійне двоспрямоване з'єднання. iOS: URLSessionWebSocketTask (нативний, iOS 13+). Android: OkHttp WebSocket. Обов'язкова обробка reconnect: при onFailure — експоненційний backoff (1с → 2с → 4с → 8с → максимум 60с). Socket.IO — надбудова з автоматичним reconnect, але для нових проєктів краще нативний WebSocket (менше залежностей). TLS 1.3 забезпечує безпеку з'єднання.

Чому важливий certificate pinning?

Корпоративний проксі може перехопити HTTPS через підміну сертифіката. Certificate pinning запобігає цьому: додаток приймає тільки конкретний сертифікат або публічний ключ. Alamofire: ServerTrustManager з PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner з SHA-256 хешем. Операційна складність: при ротації сертифіката старі версії додатку перестають працювати. Рішення — pinning на публічний ключ CA або підтримка кількох пінів з grace period. Правильне впровадження pinning гарантує захист від MITM-атак.

Що входить у роботу

Ми передаємо: вихідний код мережевого шару, документацію по використовуваних бібліотеках, інструкцію з ротації сертифікатів, підтримку протягом 2 тижнів після здачі.

Терміни та вартість

Реалізація мережевого шару з REST, retry, кешуванням та offline-режимом — 1–2 тижні. Додавання GraphQL або WebSocket — ще 1–2 тижні. gRPC — 2–3 тижні, включаючи кодогенерацію. Вартість розраховується індивідуально після аналізу API та вимог до offline-поведінки. Оцінимо проєкт за 1 день — зв'яжіться з нами для консультації. Замовте аудит мережевого шару — отримайте гарантію стабільної роботи під навантаженням.