Pull to refresh

Создание VR-игры от третьего лица

Reading time6 min
Views6.4K
Original author: Marco Mortillaro

1. Введение


Forge Reply — это миланская игровая студия. Нашим наиболее важным проектом на сей день является гибрид игры-книги/JRPG Joe Dever's Lone Wolf. Игра в четырёх актах была выпущена на мобильных устройствах в 2013-2014 годах. Потом её портировали на другие платформы (PC, PlayStation 4 и Xbox One).

Joe Dever's Lone Wolf создана на заре высококачественных мобильных игр, но после её выпуска игровая отрасль совершила ещё один серьёзный переход. Начали возникать игры в виртуальной реальности, и мы тоже захотели в этом участвовать.

Theseus — это наша первая VR-игра, в которой мы столкнулись с совершенно новыми вопросами. В этом посте я расскажу о проблемах, с которыми мы встретились при создании дизайна игры и UI.





Создание игрового процесса от третьего лица в VR


Как мы подошли к VR и почему вид от третьего лица?

При создании видения Theseus как игры в виртуальной реальности, разумеется, первое, что нам пришло в голову — вид от первого лица. Однако, когда мы изготовили первые прототипы, мы осознали, что для воплощения нужной нам алхимии перспектива от первого лица будет не лучшим выбором.

Поэтому мы рассмотрели разные варианты и решили перейти к игре от третьего лица. Мы воспринимали её почти как внетелесный опыт (или ощущения Лакиту с камерой в Super Mario 64). Нашими основными отправными источниками были такие старые шедевры survival horror, как Resident Evil и Alone in the Dark. В этих играх камера фиксирована и её положение изменяется в зависимости от движения игрока (обычно при смене комнаты или зоны).



Но игра Theseus должна была стать и эмоциональным, и кинематографическим опытом. Как передать эти чувства с помощью только фиксированных камер? Это невозможно, поэтому мы решили добавить ещё одну систему следующих за персонажем камер, скопированную из более современных игр (например, из The Last of Us), но адаптировать её под VR.

Вот так мы создали нашу смешанную систему камер (Mixed-Camera System), которая позволяет нам переходить от фиксированных к следящим камерам и наоборот, в зависимости от игрового процесса. Более того, переключение происходит без каких-либо проблем с укачиванием. Если взять для примера недавние VR-игры, то можно описать эту систему как переключение между камерами Chronos и Edge of Nowhere.



3. Система камер


Как мы перешли к разработке системы камер

Смешанная система камер обеспечила нам большую гибкость, что позволило дизайнерам уровней выбирать наилучший вариант камеры в зависимости от геймплейной ситуации.

Камеры слежения, например, оказались наилучшим выбором для всех ситуаций, в которых мы хотели усилить ощущение погружения в игру и увеличить напряжение. С другой стороны, фиксированные камеры, лучше подходили к боям или к ситуациям, в которых игрок мог испытывать укачивание от VR.

Фиксированные камеры
Более широкий угол обзора фиксированной камеры даёт в сражениях более полное понимание структуры поля боя, помогает игроку правильно перемещать Тесея в трёхмерном окружении. В результате становится проще предсказывать и избегать вражеских атак. С другой стороны, фиксированная камера усиливает ощущение грандиозности архитектуры, позволяющее нам создавать впечатляющие, уникальные ракурсы лабиринта.



Пока наши дизайнеры уровней намечали уровни, мы осознали, что расположение этих фиксированных камер должно удовлетворять гораздо более строгим требованиям по сравнению с традиционными играми, в которых камера всегда следует за игроком (например, с Resident Evil). В играх в виртуальной реальности игрок управляет камерой поворотами головы, поэтому невозможно «принудительно» сделать резкий переход от одной комнаты к другой. Наоборот, было необходимо создать «поток» комнат, структурированный с помощью обратных планов, и всегда учитывать вращение головы игрока (см. примеры).

Правильный дизайн


Правильное расположение камеры. При переключении от A к B и наоборот камера учитывает положение головы игрока.

Результат в игре



Неправильный дизайн


Неправильное расположение камеры. При переключении от A к C игрок не может видеть персонажа.

СЛЕДЯЩИЕ КАМЕРЫ

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

  1. Риск укачивания увеличивается, когда камера следует за движениями персонажа и персонаж движется слишком быстро. По этой причине в режиме следящей камеры мы постарались ограничить скорость игрока.
  2. Для уменьшения бокового движения, которое может привести к укачиванию, мы реализовали кривые движения для некоторых «нарративных моментов», в которых персонаж перемещается на очень большие расстояния. В этих ситуациях персонаж соединён с кривой и может только следовать по ней, управляемый аналоговым джойстиком.
  3. В качестве дополнительной меры мы решили ограничить или заблокировать движение персонажа, когда игрок смотрит в другую сторону. Мы приняли такое решение, потому что в игре много моментов, производящих сильное впечатление и игрок будет рассматривать окружения.

ПЕРЕХОДЫ КАМЕРЫ

Также наш дизайнер уровней позаботился о переключении между фиксированной и следящей камерами. Такой тип перехода на самом деле довольно критичен, и нам пришлось установить следующие правила:

  1. Мы пытались привязать любой переход к архитектурному элементу, например, к двери или входу в огромный коридор, чтобы пользователь «ожидал» переключения камеры.
  2. При выполнении переходов мы снижаем скорость персонажа, чтобы запретить быстрое движение персонажа в следящей камере.
  3. Перед переключением на следящую камеру мы создаём схему уровня таким образом, что игрок мотивирован двигать головой и возвращаться к нейтральному неподвижному положению (см. пример).

Правильный дизайн


A — фиксированная камера, B — следящая камера. A находится в правильном положении.


Результат в игре (переход от фиксированной к следящей камере)


Результат в игре (переход от следящей к фиксированной камере)

Неправильный дизайн


C — фиксированная камера, B — следящая камера. C находится в неправильном положении.



4. UI в пространстве мира



Ограничение превращается в возможность

С самого начала разработки Theseus мы решили, что рассказчик будет говорить на древнегреческом языке, и локализация затронет только субтитры. Мы считали, что от этого выиграет атмосфера игры, но, кроме того, были и значительные побочные эффекты экономии бюджета. В дополнение к этим строкам диалогов истории мы хотели использовать текст, чтобы оставлять «подсказки» там, где контекстных значков недостаточно.

Нам нужно было решить, как должны выглядеть эти тексты, потому что в VR есть два возможных варианта, и у каждого свои достоинства и недостатки:

  1. В «пространстве головы» — текст всегда находится перед игроком, даже когда он поворачивает голову;
  2. В «пространстве мира» — текст располагается в трёхмерном окружении.

На ранних этапах разработки мы в основном работали над UI в «пространстве головы». Мы не хотели перекрывать обзор игроку, поэтому пытались не располагать текст посередине экрана. В результате единственным логичным местом оказалась область прямо под полем зрения. Но когда игрок смотрел вниз, чтобы прочитать субтитры, головной дисплей тоже двигался, создавая своего рода «цикл использования». Оценив ситуацию, мы пришли к четырём важным выводам:

  • Нельзя одновременно отображать слишком много текста;
  • Чтение двух строк (одна под другой) может быть неудобным;
  • Необходимость смотреть на текст отвлекает игрока от других происходящих действий, что разрушает чувство погружения;
  • С другой стороны, игрок может запросто пропустить субтитры, если его внимание отвлечёт что-то другое.

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



Однако и тут есть свои тонкости: каждую строчку нужно размещать индивидуально в подходящее положение, что может быть довольно долгой операцией при большом количестве текста. Кроме того, размер шрифта должен быть достаточно большим, чтобы избежать появления артефактов. И последнее: нужно быть очень внимательными при локализации. Английский язык довольно «лаконичен», и предложения на других языках обычно занимают больше места.

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



5. Заключение


В заключение хочу сказать, что создание Theseus как игры в виртуальной реальности потребовало множества усилий, но и дало нам немало. Основной причиной стали проблемы, с которыми нам никогда не приходилось встречаться раньше, например, укачивание при движении или читаемость внутриигровых текстов. Виртуальная реальность заставила нас принимать нетривиальные решения.

Надеемся, этот пост поможет вам или вдохновит в процессе разработки для VR. Спасибо за чтение!

Если вам интересно увидеть предварительные результаты нашей работы, то посмотрите тизер игры.

Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
Total votes 7: ↑7 and ↓0+7
Comments6

Articles