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 package с 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 игроках — управляемо.
Синхронизация физических объектов
Подбираемые предметы, бросаемые объекты, двери — всё это физические риджидбоди. Фундаментальная проблема: у двух игроков физика симулируется независимо, и результаты расходятся. Один игрок кинул кубик в стену — у него он отскочил вправо, у второго — влево.
Подход 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, кроссплатформа).