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






