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.
Приклад реалізації client-side prediction на Unity
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 — ідеально. Для швидкозмінних даних (позиція кожен кадр) — надмірно.
| Підхід | Bandwidth | Надійність | Складність реалізації |
|---|---|---|---|
| State sync | Високий | Висока | Середня |
| Event-driven | Низький | Середня | Висока |
Що входить у розробку мережевого коду
Розробка мережевого коду під ключ включає кілька етапів:
- Аналіз гри — визначення жанру, кількості гравців (від 2 до 64), вимог до точності синхронізації та античит.
- Проектування архітектури — створення network diagram із зазначенням авторитетності кожного компонента.
- Вибір стеку — NGO з UGS Relay, Mirror з dedicated server, Photon Fusion, Nakama.
- Реалізація — написання коду з client-side prediction, lag compensation, state sync.
- Тестування — в NetworkSimulator із затримками 50/100/200 мс та втратами пакетів 1–5%.
- Оптимізація — зниження bandwidth на 30%, зменшення draw calls, налаштування LOD.
- Документація та навчання — передача коду, опис архітектури, навчання команди.
- Підтримка — супровід у 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%. Проблеми з синхронізацією проявляються лише за умов реальної мережі.
| Масштаб задачі | Орієнтовні терміни |
|---|---|
| Базова синхронізація позицій (2–8 гравців) | 2–4 тижні |
| Client-side prediction + lag compensation | 4–8 тижнів |
| Повна мережева архітектура з game state sync | 6–12 тижнів |
| Оптимізація існуючого мережевого коду | 2–4 тижні |
Вартість розраховується після аналізу жанру гри, кількості гравців та вимог до точності синхронізації.
За 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+ років досвіду.
Отримайте консультацію з вибору архітектури синхронізації для вашої гри — ми підготуємо детальний план та оцінку робіт. Замовте аудит існуючого мережевого коду, щоб виявити вузькі місця до релізу.