Введение в XR в игровой разработке: чем VR, AR и MR отличаются на уровне проекта

У команды появилась идея: игрок собирает маленького робота из деталей и проверяет его работу. В обычной игре это можно сделать мышью на экране. В XR детали оказываются перед человеком, а способ взаимодействия зависит от выбранного устройства и отношения виртуального мира к реальному. Поэтому выбор VR, AR или MR меняет не только маркетинговое описание, но и устройство сцены, управление и план испытаний.

XR — общее обозначение, включающее виртуальную, дополненную и смешанную реальность. Границы между AR и MR не всегда одинаково проводят разные разработчики. В руководстве Unity они описаны как континуум; полезнее проверять требуемые возможности устройства, чем спорить о единственно правильной наклейке.

Три версии одной игровой идеи

Вариант	Наш авторский прототип с роботом	Что становится частью задания
VR	Полностью виртуальная мастерская вокруг игрока	Создать окружение, рабочее место и понятное взаимодействие внутри него
AR	Робот поверх изображения реального стола на экране телефона	Связать виртуальный объект с наблюдаемым реальным пространством
MR	Виртуальные детали и реальная комната используются в одном сценарии	Определить, как виртуальные объекты соотносятся с доступными данными об окружении

VR в этой классификации симулирует самостоятельное окружение. AR накладывает контент на вид реального мира. MR соединяет виртуальную среду с реальной и допускает их взаимодействие. Многие MR-гарнитуры показывают реальность через камеры — passthrough. Наличие видеопросмотра само по себе ещё не описывает весь набор пространственных возможностей конкретного устройства.

Например, задумка «деталь скрывается за настоящим монитором» требует отдельно проверить получение нужных данных и окклюзию. Не следует считать, что любая гарнитура с passthrough автоматически понимает все предметы комнаты. Для первого прототипа можно выбрать более узкую задачу: поставить одну виртуальную деталь на подготовленную поверхность и дать её выбрать.

Начинайте с действия игрока, а не со списка технологий

В нашем примере базовое действие — выбрать деталь, перенести её и установить на корпус. Запишите, что считается успехом: деталь находится в допустимом месте, визуально подтверждена установка, следующий шаг доступен. Пока это не определено, легко потратить время на красивую комнату, в которой непонятно, как собрать робота.

Затем выберите доступный ввод. Контроллер, отслеживаемая рука, взгляд и касание экрана требуют разных сигналов выбора и подтверждения. Это варианты проектирования, а не обещание поддержки каждого способа на любом XR-устройстве. Для прототипа зафиксируйте один обязательный способ ввода и отдельно опишите, что произойдёт, если его данные временно недоступны.

Авторское ограничение для первой итерации: одна сцена, одна деталь, одно место установки и кнопка сброса. Такое сужение не является отраслевым нормативом. Оно помогает проверить связь между физическим действием и реакцией игры до разработки каталога деталей и сложной системы заданий.

Движок, стандарт и runtime решают разные задачи

Unity предоставляет средства разработки XR-проектов, а подключаемые пакеты и выбранная платформа определяют конкретный набор возможностей. OpenXR — открытый стандарт общего API для XR-приложений, поддерживаемый Khronos. Его назначение — уменьшать зависимость приложения от отдельных платформенных API, а не рисовать игровую сцену вместо движка.

Слово OpenXR не означает, что один собранный проект без проверки одинаково работает на всех устройствах. Для проекта всё равно выбирают целевую платформу и доступную реализацию, проверяют требуемые возможности и применимость расширений. Переносимость — причина использовать стандарт, а не основание обещать полную идентичность поведения.

Практически полезно разделить три слоя: игровая логика знает, что означает «установить деталь»; слой взаимодействия переводит ввод в выбор и перемещение; платформенный слой предоставляет доступное отслеживание и XR-возможности. Это предложенная архитектура учебного проекта. Она позволяет обсуждать замену устройства, не переписывая смысл игрового задания.

Почему камера — не просто обычная камера сцены

В XR положение наблюдателя связано с отслеживаемым устройством. В Unity XR Origin объединяет объекты и компоненты, которые переводят данные отслеживания в мировое пространство сцены. Начальная точка физического отслеживания и желаемая стартовая точка игры не обязаны совпадать.

Представьте, что виртуальная мастерская построена около координаты X=100, а устройство сообщает положение относительно своей стартовой точки. XR Origin размещают там, где игрок должен оказаться в сцене. Отслеживаемая камера находится в его иерархии, поэтому относительные движения устройства преобразуются в координаты игрового мира.

При обычном движении пользователя дочерние отслеживаемые объекты меняют положение относительно XR Origin; сам родитель не обязан идти за каждым шагом. Для виртуального перемещения, например телепортации, можно отдельно перемещать XR Origin. Путаница этих двух действий объясняет многие вопросы вида «почему переместил игрока, а камера снова вернулась».

В руководстве Unity также указано не держать в сцене более одного активного XR Origin. Доступные варианты его добавления зависят от установленных пакетов. Поэтому инструкция с точным пунктом меню из чужой версии не заменяет проверку состава вашего проекта и текущего руководства.

Окружение и масштаб входят в геймдизайн

В VR автор проектирует видимый мир вокруг человека. В AR и MR к нему добавляется непредсказуемая реальная обстановка: стол может быть занят, освещение отличаться, а выбранное место оказаться неудобным. Для нашего прототипа заранее определим, где игрок собирает робота и как перенести рабочую зону, если начальная позиция не подходит.

Не задавайте размер детали только по красивому виду в окне редактора. На целевом устройстве проверяют, можно ли её различить, выбрать и поставить, не закрывает ли она важные элементы и понятна ли глубина. Это вопросы приёмки конкретного приложения; универсальные численные размеры для любой руки и любого дисплея здесь не задаются.

Если захват не удался, интерфейс должен объяснить состояние: деталь ещё не выбрана, удерживается, подходит к гнезду или уже установлена. Разные состояния можно различать формой, подписью и другим доступным сигналом. Не стоит делать единственным признаком смену цвета, которую игрок может не заметить.

Бюджет кадра задаёт устройство

XR-сцена требует устойчивого времени кадра. Стереорендеринг формирует разные виды для глаз и увеличивает работу по сравнению с одним видом; single-pass/multiview помогает уменьшать дублирование, но не отменяет стоимость сцены. В руководстве Unity отдельно разобраны GPU- и CPU-ограничения, поэтому уменьшать только количество полигонов без измерений недостаточно.

Для условного дисплея 90 Гц интервал обновления равен 1/90 секунды, примерно 11,1 мс. Это арифметический пример для выбранной частоты, а не универсальное требование 90 FPS ко всем XR-проектам. Если кадр не подготовлен вовремя, поведение зависит от SDK: возможны повтор предыдущего кадра или репроекция. Не используйте эти механизмы как оправдание постоянно пропускаемых кадров.

В нашей мастерской измеряйте время CPU и GPU на целевом устройстве во время захвата детали, появления подсказки и загрузки нового объекта. Сравните простую сцену с рабочей, чтобы отделить базовые расходы от собственного контента. Эти замеры предлагаются для прототипа; фактические показатели конкретной гарнитуры здесь не приводятся.

Для автономных XR-устройств с URP Unity даёт отдельные рекомендации: проверять стоимость постобработки и промежуточных текстур, рассматривать управление разрешением и доступные режимы рендеринга. Применимость зависит от версии Unity, API, устройства и нужных эффектов. Не копируйте список отключений целиком: сначала найдите ограничение профилированием, измените один параметр и проверьте как время кадра, так и видимость деталей.

Что проверять на устройстве

Первое испытание нашего прототипа — полный цикл выбора и установки одной детали. Затем проверяем повторный захват, сброс, неудобное начальное положение, потерю доступного ввода и возвращение к задаче. Для AR/MR отдельно проверяем поведение в нескольких реальных местах, соответствующих замыслу игры. В редакторе можно отладить часть логики, но он не подтверждает свойства реального отслеживания и ввода.

Составьте таблицу «устройство — способ ввода — обязательная возможность — результат». Если сценарий зависит от функции, которая отсутствует на части целевых устройств, выберите альтернативу либо явно сузьте поддержку. Нельзя одновременно обещать универсальность и молча рассчитывать на возможность одной модели гарнитуры.

После прототипа решение становится конкретнее: нужна ли полностью виртуальная мастерская, достаточно ли наложения объекта на изображение или важна работа с реальным пространством. Дальше расширяйте игру вокруг подтверждённого действия, сохраняя разделение игровой логики, взаимодействия и платформенных возможностей. Так различия VR, AR и MR превращаются в проверяемые требования проекта.