tags: [vr-ar]
Розробка модулів мультиплеєра для спільного VR досвіду
Мультиплеєр у VR — це не просто синхронізація позицій та станів. Це синхронізація двох рук, голови, взгляду, захватів, фізичних об'єктів — все одночасно, з латентністю не більше 50–80 мс, інакше користувачі бачать «дергаючі» аватари та втрачають ощущення спільної присутності. При цьому все це має працювати на мобільному залізі Quest з обмеженою пропускною здатністю.
Готові мережеві рішення — Photon Fusion, Photon PUN2, Mirror, Netcode for GameObjects (NGO) — кожне має свої компромиси для VR. Вибір мережевого стеку на старті визначає архітектурні рішення на весь проект.
Photon Fusion та VR: чому Server Mode краще за Shared Mode
Photon Fusion підтримує два режими: Shared Mode (peer-to-peer з одним хостом) та Server Mode (виділений сервер Photon). Для VR бажано Server Mode, навіть якщо проект невеликий.
У Shared Mode один з гравців — хост, і через нього проходить весь трафік. У VR це означає: якщо хост рухає руки (а він робить це 72–90 разів на секунду), його власні дані обробляються локально, а інші гравці отримують їх з RTT хоста. При нестійкому з'єднанні хоста вся сесія страждає. У Server Mode немає однієї точки відмови — Photon Cloud бере на себе ретрансляцію та авторитетну обробку станів.
Конкретна настройка: NetworkRunner з GameMode.Server, FixedUpdateNetwork замість Update для детермінованої фізики. Для трансформів рук використовуємо NetworkTransform з InterpolationDataSource.Predicted — передбачення на стороні клієнта зменшує сприйнену латентність.
Синхронізація аватарів: IK та приховування власного тіла
Головна технічна проблема VR-аватарів у мультиплеєрі — у інших гравців є full body avatar з анімацією, у локального гравця його немає (він бачить тільки руки від першої особи). Синхронізувати потрібно позиції голови та двох кистей — і з цих трьох точок відновити позу тіла для інших гравців.
Рішення — Full Body IK з обмеженою кількістю контрольних точок. У Unity це пакет Animation Rigging з TwoBoneIKConstraint для рук та MultiParentConstraint для тулуба. Голова (HMD position) → тулуб через евристичне зміщення вниз (~0.3 м) → руки через IK до позицій контролерів. Не фізично точно, але переконливо виглядає при нормальних рухах.
Мережевий трафік: три трансформи (голова + 2 руки) × 7 floats (pos + rot) × 90 fps = ~7.5 KB/s на гравця без стиснення. З NetworkTransform та квантизацією у Photon Fusion — 1.5–2 KB/s. При 4–8 гравцях — керуємо.
Синхронізація фізичних об'єктів
Підбірні предмети, кидані об'єкти, двері — все це фізичні rigidbody. Фундаментальна проблема: у двох гравців фізика симулюється незалежно, і результати розходяться. Один гравець кинув кубик у стіну — у нього він відскочив вправо, у другого — вліво.
Підхід 1: авторитетна фізика на сервері. Всі Rigidbody симулюються тільки на StateAuthority (у термінах Photon Fusion — у того, хто захопив об'єкт). Інші гравці інтерполюють позицію. При захопленні об'єкт «передається» новому власнику через RequestStateAuthority. Мінус — при передачі видна невелика телепортація, якщо позиції розійшлися.
Підхід 2: клієнтська фізика з reconciliation. Кожен клієнт симулює фізику локально, сервер періодично розсилає авторитетний стан. При розходженні понад порог — м'яке зміщення до авторитетної позиції через Lerp. Краще виглядає, але складніше реалізувати без артефактів.
На практиці для VR-ігор з фізичними взаємодіями використовується підхід 1 з додаванням ghost об'єкту — тонкої напівпрозорої копії, яка показує авторитетну позицію, поки основний меш інтерполюється.
Процес розробки
Мультиплеєрний модуль — окрема задача, яку краще закладати на етапі архітектури, а не додавати до готової одиночної гри. Ретрофіт мультиплеєра до готової синглплеєрної VR-гри — звичайно +50–70% трудозатрат порівняно з розробкою з урахуванням мультиплеєра з початку.
Етапи: вибір мережевого стеку та архітектури → базова синхронізація трансформів → аватари з IK → синхронізація фізичних об'єктів → ігрова логіка (очки, стани, раунди) → тестування під навантаженням → оптимізація трафіку.
| Масштаб задачі | Орієнтовні строки |
|---|---|
| Базовий мультиплеєр (2–4 гравці, тільки трансформи) | 2–4 тижні |
| Повноцінні аватари з IK + фізика об'єктів | 6–10 тижнів |
| Масштабний мультиплеєр (8+ гравців, кастомна логіка) | 3–6 місяців |
Вартість розраховується після аналізу вимог: число гравців, тип взаємодій, вибір платформи (Quest standalone, PCVR, кросс-платформа).