Мультиплеєр та мережева архітектура
Ви побудували гру для одного гравця, білд стабільний, і раптом приходить завдання — додати мультиплеєр. Саме тут більшість команд серйозно недооцінюють обсяг робіт. Мультиплеєр — це не «додати синхронізацію», це переосмислення ігрової логіки, вибір мережевої архітектури та побудова серверної інфраструктури з нуля.
Вибір архітектури: авторитетний сервер 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)
Клієнт не чекає на підтвердження від сервера. Він одразу застосовує свої дії локально — рух, анімації, звуки. Коли приходить відповідь сервера, клієнт порівнює свій стан із серверним. Якщо вони збігаються — все добре. Якщо ні, відбувається узгодження: клієнт повертається до серверного стану і «переграє» всі непідтверджені введення.
Це вимагає зберігання історії введення на клієнті та швидкого пересчету стану. У 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 — простий, але достатній для більшості інді-проектів.
Виділені сервери
Авторитетний мультиплеєр вимагає виділених серверів. Варіанти розміщення:
| Підхід | Плюси | Мінуси |
|---|---|---|
| Самостійний хостинг (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
Для конкурентних ігор захист облікових записів критичний: двофакторна автентифікація, виявлення підозрілих входів, швидка блокування скомпрометованих облікових записів.
Що потрібно зафіксувати перед початком розробки
- Жанр та рівень конкуренції — визначає вибір між relay та авторитетним сервером
- Максимальна кількість гравців на сесію — 2-4 гравці та 64 гравці — принципово різні завдання
- Цільові платформи — WebGL вимагає WebSocket, консолі вимагають сертифікацію мережевого коду
- Очікуваний піковий CCU — впливає на вибір інфраструктури та план масштабування
- Вимоги до античиту — потрібна серверна авторитет, потрібна інтеграція EasyAntiCheat або BattlEye