Мультиплеєр та мережева архітектура
Ми бачили десятки проєктів, які застрягали на півроку, коли справа доходила до розробки мультиплеєра. Ви збудували гру для одного гравця, білд стабільний, і раптом приходить завдання — додати мережеву гру. Саме тут більшість команд серйозно недооцінюють обсяг робіт. Мультиплеєр — це не «додати синхронізацію», це переосмислення ігрової логіки, вибір мережевої архітектури та побудова серверної інфраструктури з нуля. Наш досвід — понад 8 років на ринку, 40+ релізів для PC, консолей і мобілок — каже: помилка в архітектурі на старті коштує втричі більше, ніж виправлення на етапі прототипу.
Як обрати архітектуру мультиплеєра для вашої гри?
Це перше і найважливіше архітектурне рішення. Від нього залежить усе: вартість інфраструктури, захист від читерства, складність розробки та затримки для гравців.
Relay-архітектура (P2P з ретрансляцією)
У relay-схемі клієнти не з'єднуються безпосередньо. Замість цього вони обмінюються даними через проміжний сервер, який просто пересилає пакети. Сервер не виконує ніякої ігрової логіки — це чиста маршрутизація трафіку.
Коли це доречно:
- Кооперативні ігри з низьким рівнем конкуренції (спільне проходження, стратегії в реальному часі з малою кількістю гравців)
- Прототипи та ранні версії
- Маленькі студії без серверної експертизи
Конкретні інструменти:
- Photon Relay — найпопулярніший вибір для Unity. Швидкий старт, готові SDK, зрозуміла тарифікація на основі CCU.
- Unity Gaming Services Relay — вбудований в екосистему UGS, працює разом із Lobby та Netcode for GameObjects.
Проблема: читерство. Якщо клієнт є джерелом істини, він може відправляти будь-які дані. Для конкурентних жанрів (шутери, файтинги, спортивні симулятори) relay-архітектура неприйнятна.
Авторитетний сервер
Вся ігрова логіка виконується на сервері. Клієнти відправляють тільки введення (натискання кнопок, напрямок руху); сервер обчислює фізику, колізії, шкоду — і розсилає результати клієнтам. Це стандарт для будь-якого конкурентного жанру. Авторитетний сервер зменшує кількість читерів на 95% порівняно з relay.
Стек для Unity:
| Інструмент | Тип | Переваги | Обмеження |
|---|---|---|---|
| Netcode for GameObjects (NGO) | Офіційне рішення Unity | NetworkVariable, NetworkObject, RPC з коробки; активно розвивається | Відносно молодий, менше готових прикладів |
| Mirror | Форк uNet | Зрілий, величезна база прикладів, підтримка KCP/WebSocket/Telepathy | Застарілий API, менше інтеграцій з UGS |
| Nakama | Open-source бекенд | Серверна логіка на Lua/TypeScript/Go, матчмейкинг, лідерборди, профілі | Вимагає окремого серверного хостингу |
Стек для Unreal: вбудована мережева система на основі авторитетного сервера. Dedicated Server, репліка акторів, RPC — все це частина движка. Для більшості жанрів достатньо нативних інструментів.
Чому компенсація затримки критична для шутерів?
Це найбільш технічно цікавий аспект мережевого коду в конкурентних іграх. Розберімо детально — саме тут більшість команд робить критичні помилки, які роблять шутери та файтинги «неправильними на відчуття».
Проблема
Гравець бачить ворога і натискає кнопку пострілу. Між моментом натиснення та моментом, коли сервер отримує пакет, проходить час — RTT/2 (половина круглої затримки). За цей час ворог міг змінити положення. Якщо сервер перевіряє влучання по поточному положенню ворога замість того, яке бачив стрілець — гравець відчуває «кулі не влучають».
Клієнтське передбачення (Client-Side Prediction)
Клієнт не чекає на підтвердження від сервера. Він одразу застосовує свої дії локально — рух, анімації, звуки. Коли приходить відповідь сервера, клієнт порівнює свій стан із серверним. Якщо вони збігаються — все добре. Якщо ні, відбувається узгодження: клієнт повертається до серверного стану і «переграє» всі непідтверджені введення.
Це вимагає зберігання історії введення на клієнті та швидкого перерахунку стану. У NGO це реалізується вручну через NetworkBehaviour з користувацькою логікою передбачення. Mirror пропонує NetworkTransformReliable з базовим вбудованим передбаченням.
Серверна перемотка (Server-Side Rewind)
Коли сервер отримує команду «постріл» від клієнта A, він бере мітку часу з пакета та «перемотує» світовий стан — назад до того моменту, який бачив клієнт A. Перевіряє влучання в цьому «старому» положенні ворога. Якщо влучив — влучання зараховується.
Реалізація вимагає:
- Зберігання історії станів (положень усіх об’єктів) протягом останніх 200–500 мс (виходячи з максимально допустимого пінгу)
- Ефективної інтерполяції станів за міткою часу
- Обмеження глибини перемотки, щоб не давати переваги гравцям із дуже високим пінгом
Без цього механізму в шутерах гравці з пінгом 100+ мс постійно «промахуються» по ворогах. З ним гра відчувається справедливою для всіх.
Інтерполяція vs. екстраполяція на клієнті
Віддалені об’єкти (вороги) клієнт не передбачає — він їх інтерполює між двома найновішими відомими станами. Це створює невелике відставання на екрані (зазвичай 1–3 мережевих тики), але рух виглядає плавним. Екстраполяція (передбачення руху ворога) дає менше зорової затримки, але при зміні напрямку створює різкі «стрибки». Ми рекомендуємо інтерполяцію для більшості жанрів.
Серверна інфраструктура
Матчмейкинг та лобі
- Nakama — включає матчмейкинг з коробки, напишіть користувацькі правила підбору в TypeScript/Go.
- PlayFab (Microsoft) — повнофункціональний ігровий бекенд. Матчмейкинг, інвентар, хмарні збереження, аналітика. Добре інтегрується з Azure.
- Unity Gaming Services Lobby — простий, але достатній для більшості інді-проєктів.
Виділені сервери
Авторитетний мультиплеєр вимагає виділених серверів. Варіанти розміщення:
| Підхід | Плюси | Мінуси |
|---|---|---|
| Самостійний хостинг (VPS/bare metal) | Повний контроль, дешевше при високому навантаженні | Потрібна DevOps-експертиза, ручне масштабування |
| Multiplay (Unity) | Автоматичне масштабування, інтеграція з UGS | Дорого, vendor lock-in |
| Agones (Kubernetes) | Open-source, гнучкість, автоматичне масштабування | Високий поріг входу |
| AWS GameLift | Зріла платформа, глобальне розміщення | Складна настройка, дорого при малих обсягах |
Транспортний протокол
- UDP — стандарт для ігор у реальному часі. Низька затримка, можливі втрати пакетів. Більшість ігрових движків та бібліотек працюють поверх UDP з користувацькою логікою надійності.
- WebSocket — необхідний, якщо цільова платформа WebGL. Працює через TCP, що дає трохи більшу затримку, але прийнятно для казуальних жанрів. Photon та Mirror підтримують WebSocket-транспорт.
- KCP — UDP-протокол з елементами надійності. Використовується в Mirror як компроміс між швидкістю та надійністю.
Соціальні функції
Мультиплеєр — це не лише технічна синхронізація. Гравцям потрібні інструменти для взаємодії.
Типові функції:
- Друзі та запрошення — через API платформ (Steam Friends, Game Center, Google Play Games) або користувацький сервіс у Nakama/PlayFab
- Голосовий чат — Vivox (стандарт для ПК/консолей, інтеграція через Unity Gaming Services), Agora (крос-платформа включно з мобайлом)
- Текстовий чат — важливо модерувати контент. Готові рішення: PlayFab Chat, користувацький WebSocket-канал з модерацією
- Лідерборди — Nakama, PlayFab, GameSparks. Важливо розділяти глобальні та лідерборди на основі друзів
- Система кланів — нестандартна функція, вимагає окремої розробки. Для більшості проєктів достатньо групування в Nakama
Автентифікація
Ніколи не придумуйте власну систему авторизації. Використовуйте встановлені провайдери:
- PlayFab — підтримує анонімний вхід, Steam, Google, Apple, користувацький ID
- Nakama — аналогічно, плюс email/пароль з коробки
- Firebase Auth — добре підходить для мобільних ігор, глибока інтеграція з Firebase Analytics та Remote Config
Для конкурентних ігор захист облікових записів критичний: двофакторна автентифікація, виявлення підозрілих входів, швидке блокування скомпрометованих облікових записів.
Що входить у нашу роботу
Ми надаємо повний цикл розробки мультиплеєра:
- Аналіз вимог — визначаємо жанр, кількість гравців, цільові платформи, очікуваний CCU
- Проектування архітектури — вибір між relay та авторитетним сервером, транспортний протокол, стек
- Реалізація мережевого коду — синхронізація, лаг-компенсація, клієнтське передбачення, серверна логіка
- Серверна інфраструктура — налаштування виділених серверів, матчмейкінг, балансування
- Інтеграція соціальних функцій — авторизація, друзі, чат, лідерборди, голосовий зв’язок
- Тестування та оптимізація — профілювання мережі, стрес-тести до 1000+ CCU, виправлення stutter та пакет-лосс
- Супровід після релізу — моніторинг, масштабування, оновлення протоколів
Якщо ви плануєте додавати мультиплеєр у свою гру, зв'яжіться з нами — ми допоможемо обрати архітектуру та уникнути поширених помилок.
Що потрібно зафіксувати перед початком розробки
- Жанр та рівень конкуренції — визначає вибір між relay та авторитетним сервером
- Максимальна кількість гравців на сесію — 2–4 гравці та 64 гравці — принципово різні завдання
- Цільові платформи — WebGL вимагає WebSocket, консолі вимагають сертифікацію мережевого коду
- Очікуваний піковий CCU — впливає на вибір інфраструктури та план масштабування
- Вимоги до античиту — потрібна серверна авторитет, інтеграція EasyAntiCheat або BattlEye
Строки: від 4 тижнів для базового мультиплеєра до 6+ місяців для конкурентної AAA-гри з повним стеком. Вартість розраховується індивідуально після аналізу вашого проєкту. Замовте консультацію — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення під ключ. З нами працюють студії з України, Європи та США; наші сертифіковані спеціалісти гарантують якість мережевого коду на рівні топових релізів.