Реалізація синхронізації стану мобільної гри під ключ
Синхронізація стану — фундамент будь-якого мультиплеєрного досвіду. Суть проблеми: два пристрої повинні бачити однакову картину ігрового світу в один момент часу, незважаючи на затримку мережі, втрату пакетів і різну обчислювальну потужність. Рішень декілька, і вибір залежить від жанру. Ми впроваджуємо синхронізацію під ключ: від вибору протоколу до тестування під мілісекундною затримкою. Наприклад, для шутера критичні низька затримка та плавність, тому використовуємо 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 — упаковка декількох малих значень в один байт.
Як працює desync detection на практиці?
Ми реалізуємо state hash comparison з частотою 1 раз на секунду. При виявленні desync сервер надсилає повний снэпшот для всіх клієнтів, і вони синхронізуються. Додатково використовуємо checksums для кожного пакета, щоб виявляти бітові помилки.Що входить у роботу
| Етап | Результат | Тривалість (орієнтовно) |
|---|---|---|
| Аналітика | Протокол синхронізації, оцінка трафіку | 3-7 днів |
| Проектування | Специфікація архітектури, вибір стеку | 5-10 днів |
| Розробка | Реалізація синхронізації, client prediction, reconciliation | 30-60 днів |
| Тестування | Навантажувальне тестування, desync-симуляція | 7-14 днів |
| Деплой | Інтеграція з CDN/бекендом, моніторинг | 5-10 днів |
Вартість розраховується індивідуально залежно від складності. Замовте консультацію — ми оцінимо ваш проект за 1-2 дні. Пишіть — розповімо, як зменшити затримки та трафік.
Строки
Snapshot-синхронізація з interpolation для 4-10 гравців: 2-3 тижні. Client prediction, reconciliation, delta compression, desync detection: 1.5-3 місяці. Детермінована симуляція з fixed-point математикою: додає 3-6 тижнів. Зв'яжіться з нами — підберемо оптимальне рішення під ваш бюджет.
Порівняння підходів:
| Підхід | Трафік | Затримка | Складність |
|---|---|---|---|
| Snapshot | Високий | Середня | Низька |
| Delta compression | Низький | Низька | Середня |
| Event sourcing | Середній | Висока | Висока |
Delta compression у 3-10 разів ефективніший за snapshot по трафіку, а event sourcing дозволяє обійтися без серверного авторитету ціною складності.