Синхронізація ігрового стану мобільної гри під ключ

Реалізація синхронізації стану мобільної гри під ключ

Синхронізація стану — фундамент будь-якого мультиплеєрного досвіду. Суть проблеми: два пристрої повинні бачити однакову картину ігрового світу в один момент часу, незважаючи на затримку мережі, втрату пакетів і різну обчислювальну потужність. Рішень декілька, і вибір залежить від жанру. Ми впроваджуємо синхронізацію під ключ: від вибору протоколу до тестування під мілісекундною затримкою. Наприклад, для шутера критичні низька затримка та плавність, тому використовуємо client prediction та delta-стиснення. Для покрокової стратегії достатньо event sourcing з fixed-point математикою. У будь-якому випадку, без правильної архітектури гравці зіткнуться з лагами, розсинхроном та втратою прогресу.

Що таке синхронізація стану в мобільних іграх?

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

Snapshot vs State delta vs Event sourcing

Три основні підходи до розподілу стану:

Full snapshot: сервер кожні N мс надсилає повний стан світу. Просто, але марнотратно. При 20 сутностях по 50 байт кожна, 20 Hz — 20 КБ/с на клієнта. При 10 клієнтах сервер розсилає 200 КБ/с. Підходить для невеликих ігор.

Delta compression: надсилаємо лише зміни від попереднього підтвердженого снэпшота. Клієнт підтверджує ack: last_received_tick, сервер обчислює delta. Скорочує трафік у 3-10 разів на динамічних сценах. Реалізація ускладнюється: потрібно зберігати історію станів для обчислення delta, обробляти втрату пакета з delta (без базового снэпшота delta не застосувати).

Event sourcing: сервер розсилає події (PlayerMoved, BulletFired, EntityDied), клієнт відтворює їх поверх базового стану. Добре для детермінованих ігор: шахи, карткові, стратегії. Погано для фізичних симуляцій: будь-якої float-похибки достатньо, щоб стани розійшлися через 30 секунд.

Як детермінізм впливає на синхронізацію?

Для event sourcing критично: обидві платформи (iOS ARM64, Android ARM64/x86) повинні давати однаковий результат одних і тих же обчислень. Стандартний float у C# — детермінований на одній платформі, але може давати різні результати на різних CPU. Рішення — fixed-point математика: замість float 1.5f використовуємо FixedPoint 15000 (масштаб 1/10000). Додавання та множення цілих чисел детерміновані всюди. Бібліотека FixedMath.Net для Unity, libfixmath для нативного C++. Godot використовує детерміновану фізику через _physics_process — усі кроки фіксовані. Unity Physics (DOTS) підтримує детермінізм при однаковому порядку обробки об'єктів. Classic Unity PhysX — не детермінований між платформами.

Чому fixed-point математика краща за float для синхронізації?

Float може давати різні результати на різних архітектурах через відмінності в округленні. Fixed-point гарантує детермінізм, що критично для event sourcing. Крім того, fixed-point операції швидші на деяких процесорах, оскільки не потребують апаратного FPU. Однак точність нижча: при масштабі 1/10000 максимальна помилка — 0.0001, що прийнятно для позицій, але може бути недостатньо для фізики високих швидкостей. Ми допомагаємо вибрати оптимальний формат під вашу гру.

Client-side prediction і reconciliation

Детальний розбір патерну для real-time ігор:

Client tick 100: застосовую введення локально, надсилаю InputPayload{tick:100, input} Client tick 101-110: продовжую передбачати локально Server: отримує InputPayload{tick:100}, симулює, відповідає StatePayload{tick:100, pos, vel} Client tick 112: отримую відповідь сервера для тіка 100 → Порівнюю передбачений стан на тік 100 із серверним → Якщо розбіжність > threshold: відкат до серверного стану тіка 100 → Повторно застосовую буфер введень 101-112 

Буфер введень — circular array фіксованого розміру (зазвичай 64-128 тіків). Кожен елемент: { tick, inputData, predictedState }. При reconciliation — ітерація по буферу з повторним застосуванням. Threshold для reconciliation: не нуль. Якщо 0.001 юніта розбіжності — відкат → клієнт постійно сіпається. Типовий поріг: 0.1-0.5 юніта залежно від швидкості персонажа.

Коли потрібна interpolation для інших гравців?

Власний персонаж — client prediction. Інші гравці — interpolation: Клієнт зберігає буфер снэпшотів із серверними мітками часу:

[{time: 1000ms, pos: (10,0,5)}, {time: 1050ms, pos: (10.5,0,5)}, ...] 

Рендер відбувається із затримкою interpolation_delay (зазвичай 2-3 снэпшоти = 100-150 мс при 20 Hz). У момент рендера знаходимо два найближчі снэпшоти та лінійно інтерполюємо позицію:

float t = (renderTime - fromState.time) / (toState.time - fromState.time); renderPosition = Vector3.Lerp(fromState.position, toState.position, t); 

Для ротації — Quaternion.Slerp. Для швидкості — потрібна Hermite interpolation або Catmull-Rom по декількох точках — плавніше при зміні напрямку.

Як client prediction знижує затримку?

Без prediction гравець бачить затримку, що дорівнює RTT/2 (час до сервера і назад). З prediction введення застосовується миттєво, а сервер лише коригує. Це знижує сприйману затримку у 2-5 разів. Для шутерів це критично: навіть 50 мс затримки відчутні.

Проблема розходження (desync)

У детермінованих іграх розходження проявляється не одразу. Стандартна діагностика — state hash comparison: кожні N тіків усі клієнти надсилають hash поточного стану на сервер. Якщо хеші не збігаються — desync, сервер розсилає повний снэпшот для синхронізації. Hash обчислюється від критичних полів стану (позиції, hp, статуси) — не від усього, щоб не включати несуттєві відмінності (анімаційні ваги, UI стани).

Як мобільний інтернет впливає на синхронізацію?

Мобільний інтернет нестабільний. Проектуйте під найгірший сценарій: 150 мс RTT, 5% packet loss, бюджет трафіку 50 КБ/с на гравця. Практичні заходи:

• Позиції: int16 замість float32 з масштабуванням (економія 50%)
• Ротація: quaternion → два кути int8 (економія 75%)
• Entities поза зоною видимості: не розсилати або знизити частоту оновлень
• Priority-based updates: швидко рухомі об'єкти оновлюються частіше

BitPacking бібліотеки: NetStack (C#), LiteNetLib BitWriter — упаковка декількох малих значень в один байт.

Що входить у роботу

Вартість розраховується індивідуально залежно від складності. Замовте консультацію — ми оцінимо ваш проект за 1-2 дні. Пишіть — розповімо, як зменшити затримки та трафік.

Строки

Snapshot-синхронізація з interpolation для 4-10 гравців: 2-3 тижні. Client prediction, reconciliation, delta compression, desync detection: 1.5-3 місяці. Детермінована симуляція з fixed-point математикою: додає 3-6 тижнів. Зв'яжіться з нами — підберемо оптимальне рішення під ваш бюджет.

Порівняння підходів:

Delta compression у 3-10 разів ефективніший за snapshot по трафіку, а event sourcing дозволяє обійтися без серверного авторитету ціною складності.