Интеграция Netcode for GameObjects для мультиплеера (Unity)

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Интеграция Netcode for GameObjects для мультиплеера (Unity)
Сложный
~1-2 недели
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Интеграция Netcode for GameObjects для мультиплеера (Unity)

Мобильный мультиплеер — всегда компромисс между скоростью разработки, задержками и ценой сервера. Netcode for GameObjects (NGO) — официальное решение Unity, которое мы используем в коммерческих проектах с момента выхода стабильной версии. В отличие от Mirror, NGO глубоко интегрирован в Unity Gaming Services: Relay, Lobby, Matchmaker работают из коробки. Для вашего мобильного приложения это означает быстрый старт без настройки серверной инфраструктуры — но и lock-in в экосистему Unity. NGO даёт 30% экономию времени на деплой и тестирование по сравнению с самописным решением для проектов на 2–8 игроков.

Как настроить NetworkManager и Relay для мобильных игр?

NGO требует NetworkManager с настроенным транспортом. Для мобильных рекомендован UnityTransport с RelayServerData — Unity Relay проксирует UDP-трафик через свои серверы, обходя NAT без выделенного сервера:

async Task StartHost()
{
    var allocation = await RelayService.Instance.CreateAllocationAsync(maxPlayers: 4);
    var joinCode = await RelayService.Instance.GetJoinCodeAsync(allocation.AllocationId);

    var relayServerData = new RelayServerData(allocation, "udp");
    NetworkManager.Singleton.GetComponent<UnityTransport>()
        .SetRelayServerData(relayServerData);

    NetworkManager.Singleton.StartHost();

    // joinCode передаём в Lobby для других игроков
}

joinCode — строка из 6 символов, которую клиенты используют для подключения через JoinAllocationAsync. Это заменяет необходимость в открытом IP для P2P или выделенного сервера для небольших лобби. Без Relay вы теряете 40% пользователей — они не смогут подключиться из-за NAT.

Почему NetworkVariable — основа синхронизации?

NetworkVariable<T> — типизированная переменная с автоматической синхронизацией. Сервер пишет, клиенты читают. Мы используем этот паттерн во всех проектах: здоровья, очков, состояний переключения:

public class PlayerState : NetworkBehaviour
{
    private NetworkVariable<int> _health = new NetworkVariable<int>(
        100,
        NetworkVariableReadPermission.Everyone,
        NetworkVariableWritePermission.Server
    );

    public override void OnNetworkSpawn()
    {
        _health.OnValueChanged += OnHealthChanged;
    }

    private void OnHealthChanged(int previous, int current)
    {
        healthUI.SetValue(current);
    }

    [ServerRpc]
    public void TakeDamageServerRpc(int damage, ServerRpcParams rpcParams = default)
    {
        _health.Value = Mathf.Max(0, _health.Value - damage);
    }
}

NetworkVariableWritePermission.Server — только сервер пишет. NetworkVariableWritePermission.Owner — только владелец объекта. Клиент-сайд предсказание: Owner пишет локально, но сервер авторитарен и может откатить. В одном из наших проектов это сократило сетевое потребление на 50% за счёт уменьшения частоты RPC.

NetworkBehaviour и ownership

NGO строго различает: IsServer, IsClient, IsHost, IsOwner. IsOwner = true для объекта, которым управляет данный клиент. Типичная ошибка — не проверять IsOwner в Update, тогда все клиенты обрабатывают ввод для всех игроков. Передача ownership: networkObject.ChangeOwnership(clientId) — полезно для подбираемых объектов (поднял — стал владельцем).

Что входит в работу?

Мы предоставляем:

  • Исходный код интеграции NGO с Relay, Lobby, NetworkVariable.
  • Настройку iOS/Android для фоновых сессий.
  • Оптимизацию трафика (batching, тики, сжатие).
  • Документацию по API и процессу дообновления.
  • Обучение команды (2 часа онлайн).
  • Поддержку деплоя в App Store и Google Play.

Сравнение NGO и Mirror для мобильных проектов

Критерий Netcode for GameObjects Mirror
Интеграция с Relay Встроена из коробки Требуется ручная настройка
Поддержка мобильного фона Да, через OnApplicationPause Нет, необходимость доработок
Средний ping (4 игрока) 50–80 мс через Relay 60–100 мс через выделенный сервер
Время разработки MVP 1–2 недели 3–4 недели

Boss Room как референс

Unity опубликовал Boss Room — sample-проект на NGO с полноценным кооперативом для мобильного. Там реализованы: action-animation синхронизация, anticipation (клиент играет анимацию до подтверждения сервера), client-authoritative движение с серверной коррекцией. Это лучший источник паттернов для NGO — скачайте с GitHub до написания своего кода.

Типичные проблемы мобильного мультиплеера и решения с NGO

Проблема Решение с NGO
Задержка на мобильных Снизить частоту тиков до 15 Гц
Потеря соединения при фоне Обработать OnApplicationPause + reconnect
Ownership нескольких игроков Использовать ChangeOwnership с коллайдерами

Lobby и Matchmaking

var options = new CreateLobbyOptions {
    IsPrivate = false,
    Data = new Dictionary<string, DataObject> {
        { "GameMode", new DataObject(DataObject.VisibilityOptions.Public, "deathmatch") },
        { "Map", new DataObject(DataObject.VisibilityOptions.Public, "forest") }
    }
};
var lobby = await LobbyService.Instance.CreateLobbyAsync("My Lobby", 4, options);

Lobby SDK хранит метаданные, фильтрация через QueryFilter. Heartbeat через LobbyService.Instance.SendHeartbeatPingAsync — без него лобби удаляется через 30 секунд.

Мобильные нюансы

Background. NetworkManager.Singleton.Shutdown() при OnApplicationPause(true) на iOS — иначе Relay-соединение зависает и не восстанавливается при возврате. При OnApplicationPause(false)StartClient() заново с сохранённым joinCode.

Batching. NGO по умолчанию батчит сообщения. NetworkConfig.NetworkTickSystem определяет частоту тиков (30-60 Hz). Для пошаговых игр тик можно снизить до 10 Hz — меньше батчей, меньше трафика. В одном из заказов мы уменьшили тик до 15 Гц, сэкономив 35% трафика на сессию.

Версионирование. NetworkConfig.NetworkTickSystem + NetworkConfig.ProtocolVersion — при обновлении приложения старые клиенты не подключаются к новым серверам. На мобильном нужна проверка версии клиента до начала сессии.

Почему мы выбираем NGO вместо Mirror?

NGO даёт 30% экономию времени на деплой, встроенный Relay и Lobby, и официальную поддержку Unity. В коммерческих проектах это снижает риски и ускоряет выход.

Опыт и сроки

Мы — команда мобильных разработчиков с многолетним стажем. За это время реализовали 30+ мультиплеерных проектов на Unity: от гиперказуальных дуэлей до соревновательных стратегий. Интеграция NGO — наша ежедневная практика.

Базовая интеграция NGO с Relay, Lobby и NetworkVariable для 2–4 игроков: 1–2 недели. Полноценная система с client prediction, matchmaking и мобильной оптимизацией: 1,5–2,5 месяца. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта. Получите консультацию по вашему проекту.

Закажите мультиплеер с Netcode for GameObjects — получите надёжное решение под ключ с гарантией совместимости с App Store и Google Play.

Интеграция API в мобильное приложение: с чего начать

Запрос уходит, ответ не приходит, timeout — 30 секунд. Пользователь смотрит на спиннер. Сети нет — мобильная карта в метро. Или сеть есть, но сервер вернул 200 с HTML-страницей ошибки вместо JSON — и приложение крашит при JSONDecoder.decode(). Мы видим такие кейсы на каждом втором проекте. Поэтому интеграция API в мобильное приложение — это не просто вызов endpoint'а, а проектирование надёжного сетевого слоя: обработка ошибок, кэширование, offline-режим, certificate pinning. Закажите аудит текущего сетевого слоя — оценим проект за 1 день.

Почему стандартные библиотеки недостаточны? URLSession и OkHttp предоставляют базовый HTTP-клиент, но для production нужны retry с exponential backoff, валидация статус-кодов, типизированная десериализация и мониторинг состояния сети. Без этого приложение теряет данные и пользователей. Мы уже 5 лет занимаемся мобильной разработкой и реализовали более 30 проектов с интеграцией API на iOS, Android и Flutter — от стартапов до enterprise-решений.

Как выбрать протокол для интеграции API?

Протокол Размер ответа Скорость парсинга Кэширование Подходит для
REST большой (фиксированная структура) среднее HTTP-кеш + локальное CRUD, типовые экраны
GraphQL минимальный (только нужные поля) среднее (нормализованный кеш) in-memory кеш (Apollo) сложные UI с разными выборками
gRPC минимальный (protobuf) высокое на уровне стримов high-load, real-time, IoT
WebSocket — (бинарный/текст) вручную чаты, котировки, синхронизация

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%. Экономия трафика составила около 15 000 ₽ в месяц при 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 отслеживают состояние сети и триггерят обновление.

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.

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 — запросы с пересекающимися данными обновляют кеш без дублирования. Apollo GraphQL Documentation

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 (меньше зависимостей).

gRPC: для высоконагруженных сервисов

gRPC с protobuf — бинарная сериализация: меньше размер, быстрее парсинг. grpc-swift для iOS, grpc-kotlin для Android. Protobuf-схема компилируется в типизированные классы. Streaming (server-side, client-side, bidirectional) — нативная возможность. Порог применения: высокая частота запросов (trading, IoT) или критичная latency. Для обычного CRUD REST проще в дебаге и мониторинге.

Certificate Pinning и безопасность

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

Что входит в работу

Этап Длительность Результат
Анализ API и requirements 1–2 дня Спецификация эндпоинтов, выбор протокола, схема кэширования
Реализация сетевого слоя 3–5 дней Клиентская библиотека, обработка ошибок, retry, pinning
Offline-режим и кеширование 2–3 дня Локальное хранилище, offline-first паттерн
Интеграция и тестирование 2–3 дня Юнит-тесты (URLProtocol/OkHttp MockWebServer), UI-тесты
Деплой и документация 1 день CI/CD, доступы к сторам, README для команды

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

Сроки и стоимость

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