Мы специализируемся на разработке мультиплеера реального времени для мобильных игр. Это не просто 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 системах.