Мультиплеер и сетевое взаимодействие
Мы знаем ситуацию: игра уже стабильно работает в одиночном режиме, и вдруг приходит задача — добавить мультиплеер. Именно здесь команды часто недооценивают масштаб работы. Мультиплеер — это не «добавить синхронизацию», а переосмысление игровой логики, выбор сетевой модели и выстраивание серверной инфраструктуры с нуля. Наш опыт разработки сетевого кода для шутеров и стратегий показывает, что правильная архитектура экономит до 40% бюджета на инфраструктуре.
Как выбрать между relay и авторитативным сервером?
Это первое и самое важное архитектурное решение. От него зависит всё: стоимость инфраструктуры, защита от читов, сложность разработки, задержки для игроков. Подробнее о клиент-серверной архитектуре можно прочитать в Wikipedia.
Relay-архитектура (P2P с ретрансляцией)
В relay-схеме клиенты не соединяются напрямую, а обмениваются данными через промежуточный сервер, который просто пересылает пакеты без игровой логики. Такое решение подходит для кооперативных игр с низкой конкуренцией, прототипов и небольших студий без серверной экспертизы.
Инструменты: Photon Relay — быстрый старт, готовые SDK, тарификация по CCU; Unity Gaming Services Relay — встроен в UGS, работает с Lobby и Netcode for GameObjects.
Проблема relay — читерство. Клиент как источник истины может отправлять любые данные. В конкурентных жанрах (шутеры, файтинги, спортивные симуляторы) relay неприемлем.
Авторитативный сервер
Вся игровая логика выполняется на сервере. Клиент отправляет только инпут, а сервер считает физику, коллизии, урон и рассылает результаты. Читер может отправить фиктивный инпут, но сервер его проверит или проигнорирует.
Стек под Unity:
- Netcode for GameObjects (NGO) — официальное решение для авторитативного мультиплеера. Поверх Unity Transport: NetworkVariable, NetworkObject, RPC-вызовы. Активно развивается.
- Mirror — форк uNet, зрелый и документированный. Множество транспортов (KCP, Telepathy, WebSockets). Проще в освоении для тех, кто работал с uNet.
- Nakama — open-source игровой бэкенд с авторитативной логикой на Lua/TypeScript/Go. Подходит, когда нужен матчмейкинг, профили, инвентарь, лидерборды.
Стек под Unreal — встроенная сетевая система на основе авторитативного сервера (Dedicated Server, репликация, RPC). Для большинства жанров хватает нативных инструментов.
Unity documentation: «Netcode for GameObjects is a high-level networking library that simplifies adding multiplayer to Unity projects»
Почему важна компенсация задержки?
Это самый технически интересный аспект сетевого кода в конкурентных играх. Именно здесь команды часто делают ошибки, которые делают шутер или файтинг «ощущающимся неправильно».
Проблема
Игрок видит врага и нажимает выстрел. Между моментом нажатия и получением пакета сервером проходит время — RTT/2. Враг мог сместиться. Если сервер проверяет попадание по текущей позиции, игрок чувствует, что «пули не попадают».
Клиентское предсказание (Client-Side Prediction)
Клиент не ждёт подтверждения от сервера — сразу применяет свои действия локально (движение, анимации, звуки). Когда приходит ответ, клиент сверяет состояние. Если не совпадает — делает reconciliation: откатывается к серверному состоянию и «переигрывает» непотверждённые инпуты.
Требуется хранить историю инпутов и уметь быстро пересчитывать состояние. В NGO реализуется вручную через NetworkBehaviour с кастомной логикой. В Mirror есть NetworkTransformReliable с базовым предсказанием.
Пример кода клиентского предсказания на C#
```csharp public class ClientPrediction : NetworkBehaviour { [ClientRpc] void ApplyInput(InputData input) { transform.position += input.direction * speed * Time.deltaTime; } } ```Серверная перемотка (Server-Side Rewind)
Когда сервер получает команду «выстрел», он берёт временную метку пакета и «перематывает» мировое состояние назад — к моменту, который видел клиент. Проверяет попадание в той «старой» позиции врага. Если попал — засчитывает хит.
Реализация требует:
- хранить историю состояний всех объектов за последние 200–500 мс;
- эффективно интерполировать состояния по временной метке;
- ограничивать глубину перемотки, чтобы не давать преимущество игрокам с высоким пингом.
Без этого механизма игроки с пингом 100+ мс постоянно «промахиваются» по врагам. С ним игра ощущается честной для 95% участников.
Интерполяция vs. экстраполяция на клиенте
Удалённые объекты (враги) клиент не предсказывает — он их интерполирует между двумя последними известными состояниями. Это создаёт визуальное отставание на 1–3 фрейма, но движение плавное. Экстраполяция даёт меньшую задержку, но при изменении направления — резкие «скачки». Большинство шутеров используют интерполяцию.
Серверная инфраструктура
Матчмейкинг и лобби
- Nakama — матчмейкинг из коробки с кастомными правилами на TypeScript/Go.
- PlayFab (Microsoft) — бэкенд с инвентарём, облачными сохранениями, аналитикой. Интегрируется с Azure.
- Unity Gaming Services Lobby — простой для инди-проектов.
Dedicated Servers
Для авторитативного мультиплеера нужны выделенные серверы. Выбор между четырьмя подходами зависит от масштаба и экспертизы. Самостоятельный VPS даёт полный контроль и низкую стоимость при высокой нагрузке, но требует DevOps. Multiplay (Unity) автоматически масштабируется, но дороже и вызывает vendor lock-in. Agones на Kubernetes — гибкий open-source, но сложен. AWS GameLift — зрелая платформа с глобальным размещением, но дорога для малых проектов.
Транспортный протокол
- UDP — стандарт для real-time игр. Низкая задержка, возможны потери. Большинство библиотек работают поверх UDP с кастомной надёжностью.
- WebSocket — нужен для WebGL. Работает через TCP, чуть большая задержка, но приемлемо для казуальных жанров. Photon и Mirror поддерживают.
- KCP — UDP-протокол с элементами надёжности, компромисс между скоростью и надёжностью (используется в Mirror).
Социальные функции
Мультиплеер — это не только технический синхрон. Игрокам нужны инструменты для взаимодействия. Что мы обычно реализуем:
- Друзья и инвайты — через платформенные API (Steam Friends, Game Center, Google Play Games) или кастомный сервис в Nakama/PlayFab.
- Голосовой чат — Vivox (стандарт для PC/консолей, интеграция через UGS), Agora (кроссплатформенно, включая мобайл).
- Текстовый чат — фильтрация контента: PlayFab Chat или кастомный WebSocket-канал с модерацией.
- Лидерборды — Nakama, PlayFab, GameSparks. Разделяем глобальные и друзей-based.
- Клановая система — нестандартная функция, для большинства проектов достаточно группировки в Nakama.
Аутентификация
Никогда не изобретайте свою систему авторизации. Используйте готовые провайдеры:
- PlayFab — анонимный вход, Steam, Google, Apple, кастомный ID.
- Nakama — аналогично, плюс email/пароль.
- Firebase Auth — хорошо для мобильных игр, глубокая интеграция с Analytics и Remote Config.
Для конкурентных игр важна защита аккаунтов: двухфакторная аутентификация, детектирование подозрительных входов, быстрая блокировка.
Что входит в разработку мультиплеера
Мы занимаемся геймдевом более 8 лет, реализовали 15+ проектов с мультиплеером, включая шутеры с 64 игроками на сервере. В рамках работы предоставляем:
- Архитектурное проектирование (выбор модели, протоколов, инструментов).
- Реализация сетевого кода (синхронизация, авторитет, компенсация задержки).
- Интеграция бэкенда (аутентификация, матчмейкинг, профили, чат).
- Тестирование с имитацией задержек и потерь пакетов.
- Документация и обучение команды.
Что мы фиксируем до старта
- Жанр и уровень конкуренции — от этого зависит выбор между relay и авторитативным сервером.
- Максимальное число игроков в сессии — 2–4 или 64 — принципиально разные задачи.
- Целевые платформы — WebGL требует WebSocket, консоли — сертификации.
- Ожидаемый пик CCU — влияет на выбор инфраструктуры.
- Требования к античиту — нужен ли серверный авторитет или интеграция с EasyAntiCheat/BattlEye.
Свяжитесь с нами для консультации — оценим ваш проект за 2 дня. Закажите разработку мультиплеера под ключ: мы проанализируем игру и предложим оптимальную архитектуру.