Если коротко:
В многопользовательском VR-тренажёре сервер должен хранить авторитетное состояние сценария, роли и критические события. Положение аватаров можно сглаживать, но решения, переключения оборудования и результаты нельзя определять отдельно на каждом устройстве.
Многопользовательский VR тренажер нужен, когда результат зависит от совместной работы: распределения ролей, связи, передачи объекта или общего решения. Простого отображения нескольких аватаров недостаточно — все участники должны видеть одно состояние оборудования и одинаково понимать этап сценария.
Разработка такого приложения начинается с правил: какой пользователь за что отвечает, как должен работать виртуальный объект и где реальность занятия требует вмешательства инструктора.
Авторитетное состояние
Критические события подтверждает сервер или другой единый авторитетный узел. Если пользователь нажал кнопку, система решает, допустимо ли действие, изменяет состояние и передаёт результат остальным. Иначе на разных гарнитурах может появиться разная версия эпизода.
Позу головы и рук отправляют часто и сглаживают на принимающей стороне. Небольшое расхождение здесь менее опасно, чем конфликт в логике. Состояние клапана, выбранный режим, результат проверки и завершение этапа передают надёжно и журналируют.
Роли и права
Роль определяет не только внешний вид, но и доступные действия и информацию. Участник видит своё задание, командир — статус группы, инструктор — общую картину и команды управления. Права проверяются в логике сценария, а не только скрытием кнопки.
До запуска команда должна понимать способ связи и подтверждения сообщений. Голосовой канал может быть общим, ролевым или локальным. Его архитектура разобрана в статье Voice chat multiplayer VR.
Синхронизация сценария
Полезно представить упражнение как последовательность состояний с допустимыми переходами. Новая вводная появляется для всех после подтверждённого события. Если участник подключился позже или восстановил связь, он получает снимок текущего состояния, а не проигрывает эпизод с начала локально.
При временном разрыве сети опасные действия блокируют либо переводят пользователя в явно ограниченный режим. Незаметно продолжать независимую симуляцию нельзя: после восстановления версии мира могут не совпасть.
Журнал и разбор
Единая временная шкала включает вход участников, изменение ролей, ключевые действия, сообщения системы и подсказки. Записывать каждое движение необязательно. Для обучения важнее восстановить решение: кто получил данные, кому передал и что произошло дальше.
NIOSH применяет многопользовательскую симуляцию и отдельные режимы директора, наблюдателя и дебрифинга для подготовки горноспасательных команд. Такой подход показывает, что инструмент инструктора и разбор нужно проектировать вместе с самой сценой.
Проверка перед занятием
Проведите тест с реальным числом пользователей, временным отключением одного устройства и повторным входом. Проверьте голос, смену ролей, паузу и завершение. Сценарий готов, если после каждого сбоя у команды остаётся одно понятное состояние. Методика командного занятия раскрыта в материале о подготовке аварийных бригад.