Настройка серверной части и бэкенда для игр
Мы интегрируем и настраиваем игровой backend под конкретный жанр и бюджет. Игровой сервер в реальном времени обрабатывает 20–60 тиков в секунду от каждого из 16 одновременных игроков — требования к latency, throughput и uptime принципиально отличаются от привычного веб-бэкенда. Ошибка в выборе между managed game backend и собственным dedicated server обнаруживается при первом нагрузочном тесте.
Как выбрать между managed backend и dedicated server?
Для turn-based и casual игр (карточные, головоломки, party games) достаточно managed backend: PlayFab (Microsoft) или Nakama Cloud (Heroic Labs). Они закрывают авторизацию, экономику, таблицы лидеров, chat и matchmaking без написания серверного кода. Для real-time action (шутеры, файтинги, гонки) нужен dedicated game server — процесс, который запускает Unity или Unreal в headless-режиме и авторитетно обрабатывает физику, AI и логику игры.
Архитектура dedicated game server
Unity Dedicated Server build — отдельный build target без графики, доступный в последних LTS-версиях. Server-side код помечается #if UNITY_SERVER. Логика физики, коллизий, AI и расчёт урона выполняется исключительно на сервере. Клиент отправляет только input и получает state updates.
Варианты хостинга для dedicated server
- Unity Gaming Services Multiplay: managed, auto-scaling, pay-per-hour.
- AWS GameLift: зрелое решение с флотилиями серверов, auto-scaling и FlexMatch matchmaking.
- Собственные VPS через Docker + orchestrator: дешевле, но требует DevOps-компетенций.
GameLift FlexMatch собирает игроков по skill, latency и региону, запускает сервер под сессию и выдаёт клиентам connection info. Интеграция в Unity через AWS SDK.
Nakama как game backend
Nakama — open source game server, закрывающий 80% потребностей мобильного и PC мультиплеера без написания собственного backend-кода. Функциональность из коробки: real-time multiplayer (WebSocket), matchmaking, chat, leaderboards, tournaments, player profiles, virtual economy, push-уведомления.
Разворачивается через Docker Compose за несколько часов. Unity SDK официальный и документированный. Кастомная логика — через Server-side modules на TypeScript или Go (Lua deprecated). TypeScript-модули компилируются и деплоятся без перезапуска сервера.
Реальный кейс: мобильная карточная игра PvP 1v1. Требования: matchmaking, ELO-рейтинг, хранение replay, anti-cheat через validation action. Выбрали Nakama self-hosted на VPS (для 500 MAU) + кастомный TypeScript-модуль для валидации ходов и расчёта ELO. Время разработки серверной части — 3 недели вместо оценки в 8 недель при custom backend. Пиковая нагрузка в 500 одновременных юзеров с latency до 50ms подтвердила стабильность. Более 5 лет опыта нашей команды в игровом backend подтверждают: Nakama — оптимальный выбор для инди и мидкор проектов.
PlayFab для casual и mobile игр
PlayFab (Microsoft) — managed game backend с богатой функциональностью: Player Profiles, Cloud Scripts (Azure Functions), Economy V2 (валюта, каталог, инвентарь), Leaderboards, Segments для push и A/B тестов, Matchmaking.
Ценовая модель: первые 1000 MAU бесплатно, далее по MAU. Для гипер-казуального проекта с 100k MAU cost может быть значительным, но для мидкора с монетизацией обычно оправдан.
Важно: Cloud Scripts выполняются server-side, что позволяет безопасно проводить операции с валютой, проверять IAP receipts и применять промокоды. Как пишет Microsoft в документации: Cloud Scripts выполняются server-side — никогда не доверяем клиенту операции с экономикой, только через Cloud Script.
Когда выбирать Nakama, а когда PlayFab?
| Функция |
Nakama |
PlayFab |
| Real-time multiplayer |
WebSocket |
Photon / Direct |
| Matchmaking |
Встроенный |
FlexMatch (GameLift) |
| Экономика |
Virtual economy |
Economy V2 |
| Cloud-функции |
TypeScript |
Azure Functions |
| Ценообразование |
Self-hosted / Cloud |
pay-per-MAU |
Nakama подходит для инди-проектов с жёстким контролем данных и кастомной логикой. PlayFab — для быстрой интеграции в экосистему Microsoft и managed-инфраструктуры.
Структура backend для типичного мобильного мультиплеера
Client (Unity)
↕ WebSocket (real-time game data)
Game Server (Unity Headless / Custom)
↕ REST/gRPC
Game Backend (Nakama / PlayFab)
↓
Database (PostgreSQL / CockroachDB)
Game Server — авторитетная игровая логика, живёт пока длится матч, затем умирает. Game Backend — постоянный: профили, экономика, таблицы, авторизация. Разделение обязательно: game server не должен знать о монетизации, backend не должен содержать игровую физику.
Процесс работы
- Аналитика: определяем жанр, целевое количество игроков, требования к real-time, бюджет инфраструктуры.
- Проектирование: выбираем стек (Nakama/PlayFab/dedicated server), проектируем схему данных и API.
- Реализация: настройка backend, интеграция с Unity/Unreal, разработка кастомных модулей.
- Тестирование: load testing с k6 или Locust, симуляция пиковой нагрузки, проверка latency и stability.
- Деплой: разворачиваем стейджинг, идентичный продуктиву (Docker Compose/Kubernetes). Производственная среда отличается только scale — не конфигурацией.
Ориентировочные сроки
| Масштаб задачи |
Сроки |
| Nakama self-hosted + базовая интеграция в Unity |
1–2 недели |
| PlayFab integration (auth + economy + leaderboards) |
2–3 недели |
| Dedicated game server (Unity headless) + hosting |
3–6 недель |
| Полный backend для multiplayer (server + meta-layer) |
6–12 недель |
Что входит в работу
- Документация: схема API, описание эндпоинтов, инструкция по деплою.
- Доступы: репозиторий с кодом, credentials к стейджингу и продуктиву.
- Обучение: проведём сессию для команды по работе с backend.
- Поддержка: гарантийная поддержка 1 месяц после сдачи.
Стоимость рассчитывается индивидуально после анализа требований и инфраструктурного бюджета. Получите консультацию по выбору стека — свяжитесь с нами.
Мультиплеер и сетевое взаимодействие
Мы знаем ситуацию: игра уже стабильно работает в одиночном режиме, и вдруг приходит задача — добавить мультиплеер. Именно здесь команды часто недооценивают масштаб работы. Мультиплеер — это не «добавить синхронизацию», а переосмысление игровой логики, выбор сетевой модели и выстраивание серверной инфраструктуры с нуля. Наш опыт разработки сетевого кода для шутеров и стратегий показывает, что правильная архитектура экономит до 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 дня. Закажите разработку мультиплеера под ключ: мы проанализируем игру и предложим оптимальную архитектуру.
