Мультиплеер и сетевое взаимодействие
Типичная ситуация: игра уже работает в одиночном режиме, билд стабильный, и тут приходит задача — добавить мультиплеер. Именно здесь большинство команд недооценивают масштаб работы. Мультиплеер — это не «добавить синхронизацию», это переосмысление игровой логики, выбор сетевой модели и выстраивание серверной инфраструктуры с нуля.
Выбор архитектуры: авторитативный сервер vs. relay
Это первое и самое важное архитектурное решение. От него зависит всё остальное: стоимость инфраструктуры, защита от читов, сложность разработки и задержки для игроков.
Relay-архитектура (P2P с ретрансляцией)
В relay-схеме клиенты не соединяются напрямую, а обмениваются данными через промежуточный сервер, который просто пересылает пакеты. Никакой игровой логики на сервере нет — он тупо маршрутизирует трафик.
Когда это уместно:
- Кооперативные игры с низким уровнем конкуренции (совместное прохождение, стратегии в реальном времени с небольшим числом игроков)
- Прототипы и ранние версии
- Небольшие студии без серверной экспертизы
Конкретные инструменты:
- Photon Relay — самый распространённый выбор для Unity. Быстрый старт, готовые SDK, понятная тарификация по CCU.
- Unity Gaming Services Relay — встроен в экосистему UGS, работает в связке с Lobby и Netcode for GameObjects.
Проблема: читерство. Если клиент является источником истины, он может отправлять любые данные. В конкурентных жанрах (шутеры, файтинги, спортивные симуляторы) relay-схема неприемлема.
Авторитативный сервер
Вся игровая логика выполняется на сервере. Клиент отправляет только инпут (нажатые кнопки, направление движения), сервер считает физику, коллизии, урон — и рассылает результаты клиентам.
Это стандарт для любого конкурентного жанра. Читер может отправить фиктивный инпут, но сервер его проверит и либо проигнорирует, либо применит логику валидации.
Стек под Unity:
- Netcode for GameObjects (NGO) — официальное решение Unity для авторитативного мультиплеера. Работает поверх Unity Transport. Из коробки: NetworkVariable, NetworkObject, RPC-вызовы. Относительно молодой инструмент, но активно развивается.
- Mirror — форк uNet, зрелый и хорошо документированный. Огромная база примеров, поддержка множества транспортов (KCP, Telepathy, WebSockets). Если команда уже работала с uNet — Mirror проще в освоении.
- Nakama — open-source игровой бэкенд с авторитативной логикой на стороне сервера. Поддерживает Lua/TypeScript/Go для серверных модулей. Хорошо подходит, когда нужен не только матчмейкинг, но и профили, инвентарь, лидерборды.
Стек под Unreal:
- Unreal имеет встроенную сетевую систему на основе авторитативного сервера. Dedicated Server, репликация акторов, RPC — всё это часть движка. Для большинства жанров хватает нативных инструментов.
Компенсация задержки (Lag Compensation)
Это самый технически интересный аспект сетевого кода в конкурентных играх. Разберём подробно, потому что именно здесь большинство команд допускают грубые ошибки, которые делают шутер или файтинг «ощущающимся неправильно».
Проблема
Допустим, игрок видит врага и нажимает кнопку выстрела. Между моментом нажатия и моментом, когда сервер получает пакет, проходит время — RTT/2 (половина круговой задержки). За это время враг мог передвинуться. Если сервер проверяет попадание по текущей позиции врага, а не по той, которую видел стреляющий — у игрока будет ощущение, что «пули не попадают».
Клиентское предсказание (Client-Side Prediction)
Клиент не ждёт подтверждения от сервера. Он сразу применяет свои действия локально — движение, анимации, звуки. Когда приходит ответ сервера, клиент сверяет своё состояние с серверным. Если они совпадают — всё хорошо. Если нет — происходит reconciliation: клиент откатывается к серверному состоянию и «переигрывает» все непотверждённые инпуты.
Это требует хранить историю инпутов на клиенте и уметь быстро пересчитывать состояние. В NGO это реализуется вручную через NetworkBehaviour с кастомной логикой предсказания. В Mirror есть компонент NetworkTransformReliable с базовым предсказанием.
Серверная перемотка (Server-Side Rewind)
Когда сервер получает команду «выстрел» от клиента A, он берёт временну́ю метку из пакета и «перематывает» мировое состояние назад — к тому моменту, который видел клиент A. Проверяет попадание в той «старой» позиции врага. Если попал — засчитывает хит.
Реализация требует:
- Хранить историю состояний (позиции всех объектов) за последние N миллисекунд (обычно 200-500 мс, исходя из максимально допустимого пинга)
- Эффективно интерполировать состояния по временно́й метке
- Ограничивать глубину перемотки, чтобы не давать преимущество игрокам с очень высоким пингом
Без этого механизма в шутере игроки с пингом 100+ мс будут постоянно «промахиваться» по врагам. С ним — игра ощущается честной для всех.
Интерполяция vs. экстраполяция на клиенте
Удалённые объекты (враги) клиент не предсказывает — он их интерполирует между двумя последними известными состояниями. Это создаёт небольшое визуальное отставание (обычно 1-3 фрейма сетевого тика), зато движение выглядит плавным.
Экстраполяция (предсказание движения врага) даёт меньшую задержку визуально, но при изменении направления создаёт резкие «скачки». Большинство шутеров используют интерполяцию.
Серверная инфраструктура
Матчмейкинг и лобби
- Nakama — включает матчмейкинг из коробки, можно писать кастомные правила подбора на TypeScript/Go.
- PlayFab (Microsoft) — полноценный игровой бэкенд. Матчмейкинг, инвентарь, облачные сохранения, аналитика. Хорошо интегрируется с Azure.
- Unity Gaming Services Lobby — простой, но достаточный для большинства инди-проектов.
Dedicated Servers
Для авторитативного мультиплеера нужны выделенные серверы. Варианты размещения:
| Подход | Плюсы | Минусы |
|---|---|---|
| Самостоятельный хостинг (VPS/bare metal) | Полный контроль, дешевле при высокой нагрузке | Нужна DevOps-экспертиза, ручное масштабирование |
| Multiplay (Unity) | Автоматическое масштабирование, интеграция с UGS | Дороже, vendor lock-in |
| Agones (Kubernetes) | Open-source, гибкость, масштабирование | Высокий порог входа |
| AWS GameLift | Зрелая платформа, глобальное размещение | Сложная настройка, дорого при малых объёмах |
Транспортный протокол
- UDP — стандарт для real-time игр. Низкая задержка, возможны потери пакетов. Большинство игровых движков и библиотек работают поверх UDP с кастомной логикой надёжности.
- WebSocket — нужен, если целевая платформа WebGL. Работает через TCP, что даёт чуть большую задержку, но приемлемо для казуальных жанров. Photon и Mirror поддерживают WebSocket-транспорт.
- KCP — UDP-протокол с элементами надёжности. Используется в Mirror и ряде других решений как компромисс между скоростью и надёжностью.
Социальные функции
Мультиплеер — это не только технический синхрон. Игрокам нужны инструменты для взаимодействия.
Что обычно реализуем:
- Друзья и инвайты — через платформенные API (Steam Friends, Game Center, Google Play Games) или кастомный сервис в Nakama/PlayFab
- Голосовой чат — Vivox (стандарт для PC/консолей, интеграция через Unity Gaming Services), Agora (кроссплатформенно, включая мобайл)
- Текстовый чат — важно фильтровать контент. Готовые решения: PlayFab Chat, кастомный WebSocket-канал с модерацией
- Лидерборды — Nakama, PlayFab, GameSparks. Важно разделять глобальные и друзей-based борды
- Клановая система — нестандартная функция, требует отдельной разработки. Для большинства проектов достаточно группировки в Nakama
Аутентификация
Никогда не изобретайте свою систему авторизации. Используйте готовые провайдеры:
- PlayFab — поддерживает анонимный вход, Steam, Google, Apple, кастомный ID
- Nakama — аналогично, плюс email/пароль из коробки
- Firebase Auth — хорошо подходит для мобильных игр, глубокая интеграция с Firebase Analytics и Remote Config
Для конкурентных игр важна защита аккаунтов: двухфакторная аутентификация, детектирование подозрительных входов, быстрая блокировка скомпрометированных аккаунтов.
Что важно зафиксировать до старта разработки
- Жанр и уровень конкуренции — от этого зависит выбор между relay и авторитативным сервером
- Максимальное число игроков в сессии — 2-4 игрока и 64 игрока — принципиально разные задачи
- Целевые платформы — WebGL требует WebSocket, консоли требуют сертификации сетевого кода
- Ожидаемый пик CCU — влияет на выбор инфраструктуры и план масштабирования
- Требования к античиту — нужен ли серверный авторитет, нужна ли интеграция с EasyAntiCheat или BattlEye