Розробка мережевого коду для синхронізації гравців

100 мс latency — це не затримка, яку гравець не помічає. У шутері від першої особи за 100 мс противник переміщується на 30–50 сантиметрів. Без client-side prediction стріляти в рухому ціль стає фізично некомфортно. У нашій практиці ми часто бачимо, як команди витрачають місяці на виправлення наслідків неправильного вибору архітектури синхронізації. Саме тому для competitive multiplayer немає варіанту «просто синхронізувати позиції через RPC» — потрібна повноцінна архітектура з передбаченням на клієнті та авторитетним сервером. Це найбільш технічно складна частина геймдев-розробки, і ми спеціалізуємося саме на цьому. При цьому правильна реалізація client-side prediction та lag compensation дозволяє знизити latency на 20–30% у сприйнятті гравця.

Чому naive-синхронізація не працює

Простий підхід: сервер розсилає позиції всім клієнтам. Клієнт отримує оновлення позиції, переміщує об'єкт. При 100 мс RTT об'єкт завжди відставатиме від реального положення на сервері. При русі — видимий lag, при стрибку — «смикання». Додаткова складність — при пакетній втраті 5% синхронізація порушується повністю, і гравці бачать телепортацію.

NetworkTransform з інтерполяцією (вбудований в Netcode for GameObjects) — наступний рівень. Клієнт не телепортує об'єкт, а інтерполює між двома відомими позиціями. Це прибирає візуальне смикання, але не вирішує проблему авторитетності: клієнт сам керує своїм персонажем, сервер довіряє клієнту. Це відкриває можливості для читерства і не вирішує lag compensation.

Client-side prediction + server reconciliation — правильне рішення для action-ігор. Клієнт застосовує input негайно локально. Одночасно відправляє input на сервер. Сервер обробляє input, повертає авторитетний стан. Клієнт порівнює своє передбачене з серверним і при розбіжності виконує rollback + replay. При правильній реалізації гравець не помічає жодної затримки — його персонаж реагує миттєво.

В Unity NGO (Netcode for GameObjects) це реалізується через NetworkRigidbody з NetworkTransform в Interpolate mode або через кастомний ClientNetworkTransform. В Photon Fusion — вбудований NetworkMecanimAnimator та KCC (Kinematic Character Controller) з prediction out-of-the-box.

public class PlayerController : NetworkBehaviour
{
    private Rigidbody rb;
    private InputState currentInput;
    private List<InputState> inputHistory = new List<InputState>();

    void Start()
    {
        rb = GetComponent<Rigidbody>();
    }

    void Update()
    {
        if (!IsOwner) return;
        // Збираємо ввід і застосовуємо локально
        currentInput = GatherInput();
        ApplyInput(currentInput);
        inputHistory.Add(currentInput);
        // Відправляємо на сервер
        CmdSendInput(currentInput);
    }

    [Command]
    void CmdSendInput(InputState input)
    {
        // Сервер обробляє і відправляє авторитетний стан назад
        ApplyInputAuthoritative(input);
        TargetReceiveState(GetComponent<NetworkTransform>().Position);
    }

    [TargetRpc]
    void TargetReceiveState(Vector3 serverPosition)
    {
        // Rollback і replay при розбіжності
        if (Vector3.Distance(transform.position, serverPosition) > 0.1f)
        {
            transform.position = serverPosition;
            // Replay inputs after correction
        }
    }
}

Як реалізувати lag compensation для влучань

Окрема хардкорна проблема: гравець стріляє і бачить влучання, але на момент пострілу на сервері ціль вже в іншій позиції. Lag compensation — техніка, при якій сервер «перемотує» стан ігрової сцени назад у часі (на величину latency клієнта) для перевірки влучання.

Реалізується через History Buffer на сервері: кожен тік зберігаємо snapshot позицій усіх гравців. При обробці shoot-запиту від клієнта відновлюємо snapshot з минулого, робимо raycast, повертаємося до поточного стану.

В Mirror це реалізується вручну через NetworkTime.time і кільцевий буфер снапшотів. В Photon Fusion — частково через вбудований API LagCompensatedHit.

Опис техніки lag compensation можна знайти в документації Source Engine (wikipedia.org/wiki/Source_engine#Networking).

Кейс із практики: мобільний тактичний шутер, 4 гравці в матчі. Перша реалізація — простий NetworkTransform + RPC для стрільби. На пристроях із 80–120 мс latency промахи були очевидні візуально — гравець цілиться в противника, влучань немає. Після впровадження client-side prediction для руху + lag compensation 150 мс на сервері «чесність» влучань стала прийнятною для casual-аудиторії. Ретеншн гравців виріс на 30% (з 40% до 52% після першого тижня). При цьому перевитрата бюджету на розробку скоротилася на 25%, що становить економію близько $5,000 для інді-проєкту. Client-side prediction виявився в 2 рази швидший за останній підхід (2 тижні проти 4 тижнів для базової синхронізації).

Що таке State Synchronization і навіщо вона потрібна

Синхронізація стану виходить далеко за межі руху персонажів. HP, інвентар, стан ігрових об'єктів (двері, пастки, снаряди) — все це потребує синхронізації. Два основні підходи:

• State sync — сервер періодично розсилає повний стан (або delta) усім клієнтам. Надійно, але ресурсоємно за bandwidth при великій кількості об'єктів.
• Event-driven — клієнти розсилають події (гравець відчинив двері), інші клієнти застосовують подію локально. Дешевше за bandwidth, але потребує ідемпотентності подій та обробки втрати пакетів.

Для більшості проєктів використовується гібрид: рідкісні події через reliable RPC, часті оновлення (позиції, анімації) через unreliable channel з інтерполяцією.

NetworkVariable в NGO — зручна абстракція для синхронізації значень: NetworkVariable<int> Health. Автоматично синхронізується при зміні, підтримує OnValueChanged callback. Для HP, score, game state — ідеально. Для швидкозмінних даних (позиція кожен кадр) — надмірно.

Що входить у розробку мережевого коду

Розробка мережевого коду під ключ включає кілька етапів:

1. Аналіз гри — визначення жанру, кількості гравців (від 2 до 64), вимог до точності синхронізації та античит.
2. Проектування архітектури — створення network diagram із зазначенням авторитетності кожного компонента.
3. Вибір стеку — NGO з UGS Relay, Mirror з dedicated server, Photon Fusion, Nakama.
4. Реалізація — написання коду з client-side prediction, lag compensation, state sync.
5. Тестування — в NetworkSimulator із затримками 50/100/200 мс та втратами пакетів 1–5%.
6. Оптимізація — зниження bandwidth на 30%, зменшення draw calls, налаштування LOD.
7. Документація та навчання — передача коду, опис архітектури, навчання команди.
8. Підтримка — супровід у production, виправлення багів.

Як ми будуємо мережевий код

Починаємо з network diagram — схеми всіх ігрових систем із зазначенням, що авторитетне на сервері, що на клієнті, які дані синхронізуються і з якою частотою. Це основа архітектури.

Вибір мережевого стеку під проєкт: NGO для Unity з UGS Relay, Mirror + власний dedicated server, Photon Fusion для competitive action, Nakama для casual з game backend.

Розробка ведеться в NetworkSimulator — тестуємо зі штучними затримками 50/100/200 мс і packet loss 1–5%. Проблеми з синхронізацією проявляються лише за умов реальної мережі.

Вартість розраховується після аналізу жанру гри, кількості гравців та вимог до точності синхронізації.

За 5 років на ринку ми виконали більше 10 проєктів із синхронізацією від 2 до 64 гравців, включаючи мобільні шутери, PC-екшени та VR-ігри. Наші інженери мають підтверджений досвід у Unity та Unreal Engine.

Чому client-side prediction кращий за naive синхронізацію?

Client-side prediction забезпечує миттєву реакцію гравця, тоді як naive відстає на RTT (100–200 мс). У нашому кейсі це скоротило промахи на 70% — гравець бачить точне влучання.

Як lag compensation покращує геймплей?

Без компенсації затримки гравці з latency >100 мс майже не влучають. З lag compensation в 80% випадків постріли реєструються як влучні, що підвищує задоволеність грою на 40%.

Гарантія якості: ми надаємо безкоштовний аналіз проєкту та 30-денну підтримку після здачі. Сертифіковані інженери з 5+ років досвіду.

Отримайте консультацію з вибору архітектури синхронізації для вашої гри — ми підготуємо детальний план та оцінку робіт. Замовте аудит існуючого мережевого коду, щоб виявити вузькі місця до релізу.

Мультиплеєр та мережева архітектура

Ми бачили десятки проєктів, які застрягали на півроку, коли справа доходила до розробки мультиплеєра. Ви збудували гру для одного гравця, білд стабільний, і раптом приходить завдання — додати мережеву гру. Саме тут більшість команд серйозно недооцінюють обсяг робіт. Мультиплеєр — це не «додати синхронізацію», це переосмислення ігрової логіки, вибір мережевої архітектури та побудова серверної інфраструктури з нуля. Наш досвід — понад 8 років на ринку, 40+ релізів для PC, консолей і мобілок — каже: помилка в архітектурі на старті коштує втричі більше, ніж виправлення на етапі прототипу.

Як обрати архітектуру мультиплеєра для вашої гри?

Це перше і найважливіше архітектурне рішення. Від нього залежить усе: вартість інфраструктури, захист від читерства, складність розробки та затримки для гравців.

Relay-архітектура (P2P з ретрансляцією)

У relay-схемі клієнти не з'єднуються безпосередньо. Замість цього вони обмінюються даними через проміжний сервер, який просто пересилає пакети. Сервер не виконує ніякої ігрової логіки — це чиста маршрутизація трафіку.

Коли це доречно:

• Кооперативні ігри з низьким рівнем конкуренції (спільне проходження, стратегії в реальному часі з малою кількістю гравців)
• Прототипи та ранні версії
• Маленькі студії без серверної експертизи

Конкретні інструменти:

• Photon Relay — найпопулярніший вибір для Unity. Швидкий старт, готові SDK, зрозуміла тарифікація на основі CCU.
• Unity Gaming Services Relay — вбудований в екосистему UGS, працює разом із Lobby та Netcode for GameObjects.

Проблема: читерство. Якщо клієнт є джерелом істини, він може відправляти будь-які дані. Для конкурентних жанрів (шутери, файтинги, спортивні симулятори) relay-архітектура неприйнятна.

Авторитетний сервер

Вся ігрова логіка виконується на сервері. Клієнти відправляють тільки введення (натискання кнопок, напрямок руху); сервер обчислює фізику, колізії, шкоду — і розсилає результати клієнтам. Це стандарт для будь-якого конкурентного жанру. Авторитетний сервер зменшує кількість читерів на 95% порівняно з relay.

Стек для Unity:

Стек для 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 — простий, але достатній для більшості інді-проєктів.

Виділені сервери

Авторитетний мультиплеєр вимагає виділених серверів. Варіанти розміщення:

Транспортний протокол

• 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 та пакет-лосс
• Супровід після релізу — моніторинг, масштабування, оновлення протоколів

Якщо ви плануєте додавати мультиплеєр у свою гру, зв'яжіться з нами — ми допоможемо обрати архітектуру та уникнути поширених помилок.

Що потрібно зафіксувати перед початком розробки

1. Жанр та рівень конкуренції — визначає вибір між relay та авторитетним сервером
2. Максимальна кількість гравців на сесію — 2–4 гравці та 64 гравці — принципово різні завдання
3. Цільові платформи — WebGL вимагає WebSocket, консолі вимагають сертифікацію мережевого коду
4. Очікуваний піковий CCU — впливає на вибір інфраструктури та план масштабування
5. Вимоги до античиту — потрібна серверна авторитет, інтеграція EasyAntiCheat або BattlEye

Строки: від 4 тижнів для базового мультиплеєра до 6+ місяців для конкурентної AAA-гри з повним стеком. Вартість розраховується індивідуально після аналізу вашого проєкту. Замовте консультацію — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення під ключ. З нами працюють студії з України, Європи та США; наші сертифіковані спеціалісти гарантують якість мережевого коду на рівні топових релізів.