Мы программируем событийную логику уровней для VR-игр. Это не просто скриптинг триггеров в OnTriggerEnter — это управление порядком нарратива, состоянием среды, реакциями NPC и обучающими подсказками в трёхмерном пространстве, где игрок может смотреть в любую сторону, стоять где угодно и взаимодействовать с объектами в произвольном порядке. Линейный скрипт здесь ломается на третьем шаге: игрок поднял предмет раньше, чем сработал диалог, — и система не знает, в каком она состоянии.
Почему простая событийная логика ломается в VR
Самая частая проблема — сериализация состояния через булевы флаги. bool doorOpened, bool npcGreeted, bool puzzleSolved в GameManager. При 15 флагах начинаются комбинаторные баги: флаг npcGreeted установлен, а doorOpened нет, а пользователь уже внутри — потому что прошёл сквозь стену при повторном заходе. Отладить это без явной модели состояний почти невозможно.
Второй кейс — конкурентные события. Игрок берёт ключ и одновременно наступает на триггер двери. Оба события срабатывают в одном фрейме, OnTriggerEnter и XRGrabInteractable.SelectEntered отрабатывают в неопределённом порядке. Если логика не обработана с учётом порядка — состояние рассинхронизируется.
Третья проблема специфична для VR-тренажёров: пропуск обязательных шагов. Инструктор разработал обязательный порядок действий, но в VR пользователь физически может выполнить шаг 5 раньше шага 2. Нужна система, которая либо мягко блокирует преждевременные действия, либо адаптирует сценарий под фактический порядок действий пользователя.
Как построить отказоустойчивую событийную систему
Основа — State Machine с явными состояниями и переходами. Не флаги, а enum LevelState { Introduction, PuzzleActive, DoorUnlocked, Completed } с методами TryTransition(LevelState target).
Для сложных нелинейных сценариев используем иерархический State Machine или Behavior Tree:
-
BehaviorDesignerили кастомный BT для NPC-реакций - Для общей логики уровня — собственный
LevelOrchestratorна основеIEnumerator-корутин илиUniTask
Event Bus — центральный брокер событий. Все компоненты уровня публикуют события в шину, не зная о друг друге: EventBus.Publish(new KeyPickedUpEvent(keyId)). LevelOrchestrator подписан на нужные события и обновляет State Machine. Это разрывает прямые зависимости между Trigger-компонентами и Orchestrator-ом.
Реализуем через event Action<T> или ScriptableObject-based EventChannel (паттерн из Unite Austin 2017): [CreateAssetMenu] KeyPickedUpEventChannel : EventChannelBase<KeyPickedUpEvent>. Каждый EventChannel — отдельный ассет, ссылки между компонентами через инспектор — не через Find().
Checkpoint система — для тренажёров критично: каждый завершённый шаг сериализуется в SessionData. При повторном прохождении или продолжении после паузы — состояние восстанавливается точно. Сохраняем не флаги, а снимок состояния State Machine + список завершённых событий с timestamps.
| Подход | Сложность реализации | Устойчивость к багам | Гибкость |
|---|---|---|---|
| Булевы флаги | Низкая | Низкая | Низкая |
| State Machine | Средняя | Высокая | Средняя |
| Behavior Tree + Event Bus | Высокая | Очень высокая | Высокая |
Специфика VR-нарратива
В VR игрок смотрит куда хочет, поэтому классическое «нарративное событие в центре экрана» не работает. Нужны механизмы мягкого направления взгляда:
Spatial Audio Cue: звук издаётся с точки интереса — игрок поворачивается естественно. Реализуется через AudioSource с 3D spatial blend + ReverbZone.
Peripheral Attention Trigger: яркий эффект (частицы, свет) в периферийном поле зрения — работает эффективнее, чем стрелка-указатель UI.
NPC Look At: NPC смотрит на игрока и начинает диалог только когда игрок смотрит на него (угол < 45°). Проверяется через Vector3.Dot(playerHeadForward, directionToNPC). Это предотвращает ситуацию, когда диалог начинается «в спину».
Из конкретного кейса: в VR-тренажёре по пожарной безопасности игрок должен выполнить 7 шагов эвакуации строго по порядку. Изначально логика была на флагах — при тестировании 40% пользователей находили способ «сломать» сценарий. После переписывания на явный State Machine с TryTransition() — валидация порядка стала частью архитектуры, а не набором if-проверок. Completion rate без ошибок вырос с 55% до 89%.
Отладка и инструменты
Кастомный Level State Viewer — Editor Window, показывающая текущее состояние State Machine в реальном времени во время Play Mode. Список активных событий, история переходов, pending events в очереди. Без этого инструмента отладка событийной логики — Debug.Log() в темноте.
Event Log: все события записываются с timestamp и stack trace в кольцевой буфер. При баге — мгновенный ответ на вопрос «что произошло до этого».
Что входит в работу
- Проектирование State Machine и диаграммы состояний
- Реализация Event Bus с подписками через ScriptableObject
- Интеграция с XR Interaction Toolkit, Unity Analytics
- Разработка отладочных инструментов (Level State Viewer, Event Log)
- Тестирование граничных случаев: параллельные события, пропуск шагов, повторное прохождение
- Документация сценария и API для расширения
Этапы работы
- Анализ сценария. Разбираем логику уровня, выявляем состояния, события, зависимости между ними.
- Проектирование State Machine. Диаграмма состояний и переходов перед кодом.
- Разработка. EventBus, Orchestrator, интеграция с VR-компонентами (XR Interaction Toolkit events).
- Отладочные инструменты. Level State Viewer, Event Log.
- Тестирование. Все граничные случаи: параллельные события, пропуск шагов, повторное прохождение.
| Масштаб уровня | Ориентировочные сроки |
|---|---|
| Линейный сценарий, 5–10 событий | 1–2 недели |
| Нелинейный уровень, 20–40 событий | 3–5 недель |
| Комплексный тренажёр с BT и checkpoint системой | 2–4 месяца |
Стоимость рассчитывается после разбора сценария и оценки сложности логики переходов. Свяжитесь с нами для оценки вашего проекта — работаем под ключ, гарантируем стабильность логики. Более 5 лет опыта в VR-разработке и свыше 15 реализованных проектов.






