Нет HUD’а без добра: HUD в игровых интерфейсах

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

В играх существует огромное количество интерфейсов: инвентарь, диалоги, меню крафта и торговли, лобби, карта, деревья прокачки персонажа и его экипировки и многие другие. Все они позволяют игрокам взаимодействовать с представленными через интерфейс механиками, которые создатели игры заложили в свой продукт. И в этой статье мы подробно разберем один из самых важных элементов игрового UI: HUD (heads-up display).

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

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

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

Snowrunner: выделенная зона задания, спидометр и тахометр на приборной панели — тоже часть игрового интерфейса, относящаяся к HUD
Snowrunner: выделенная зона задания, спидометр и тахометр на приборной панели — тоже часть игрового интерфейса, относящаяся к HUD

Почему же HUD, на мой взгляд, если не важнее всех остальных интерфейсов, то стоит примерно в первой тройке?

  1. Это наиболее часто используемый интерфейс, с которым игрок сталкивается каждую игровую сессию. Да что уж там — практически каждую секунду чистого геймплея.

  2. HUD должен справляться с задачей передачи игроку нужной и зачастую критически важной информации в конкретный момент игры для решения тех или иных игровых ситуаций.

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

  4. Через реакцию игрока на интерфейс игровой AI также получает обратную связь от него и может планировать те самые игровые ситуации.

  5. Через HUD мы, как дизайнеры, можем влиять на внешний вид, работу и ощущения от игры в рамках ее восприятия игроком. Это достигается через общий стиль и согласованность элементов, правильный отклик и поведение HUD в различных игровых ситуациях, выбор отображаемых элементов и т.д.

Так что же такое HUD? Существует множество определений, но для себя я вывел следующее :

Heads Up Display — это набор графических интерфейсов и декоративных элементов, расположенных на переднем плане и/или в игровом мире, которые призваны явно и быстро доносить до игрока необходимую информацию от игры в определенный момент времени, не мешая получению игрового опыта.

Основные моменты в этом определении:

  1. HUD передает необходимую информацию, а именно — ту, которую мы по каким-либо причинам не можем или не хотим передавать через геймплей. Это важно, ведь зачастую интерфейс используют там, где он не нужен и где можно было передать информацию геймплейным способом: через поведение персонажа игрока или его окружение и т. д. (хромать/замедляться, когда ранили, получать неодобрение со стороны NPC, если низкий рейтинг, и т.д.).

  2. HUD не мешает получению игрового опыта: если ваш интерфейс отображается не в самый удачный момент, не в самом удачном месте, не в самое подходящее время. Если он забирает часть внимания игрока на себя, не принося ему при этом никакой пользы в текущей игровой ситуации. Представьте, что вы играете в насыщенный и быстрый шутер. И в то время как вы пытаетесь попасть по «мансящему» врагу, поверх вашего прицела выскочит какое-нибудь сообщение (например о прибытии поддержки с воздуха). Явно игровой опыт от этого лучше не станет.

Типы интерфейсов HUD

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

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

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

  • Диегетические — когда, например, скорость автомобиля передается через спидометр, находящийся в кабине грузовика. Интерфейс, который видит и с которым может взаимодействовать персонаж игрока. Он позволяет получить более нарративный опыт в рамках игрового мира;

  • Мета — например, капли крови и воды на «визоре». По сути — постпроцессы, позволяющие трансформировать опыт персонажа в опыт игрока через еще один слой взаимодействия;

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

  • Недиегетические — тот же расходомер/спидометр и показатели целостности грузовика — по сути виджеты, расположенные поверх геймплея. Позволяет просто и быстро считывать информацию, но ломает нарратив и очень редко объясняется через игровую историю.

Для HUD это деление более актуально, т. к. в остальных интерфейсах игры используется в основном недиегетический тип интерфейса. При этом именно HUD может активно использовать 3-4 типа одновременно.

В этом примере мы видим три типа интерфейса на одном экране, но на разных фичах (1 — недиегетический, 2 — диегетический, 3 — пространственный)
В этом примере мы видим три типа интерфейса на одном экране, но на разных фичах (1 — недиегетический, 2 — диегетический, 3 — пространственный)

Если типы, описанные выше, представить как слои, то получится примерно такая картинка:

Каждый слой предназначен для своего типа интерфейса. 1 — недиегетический, 2 — мета, 3 — диегетический и пространственный
Каждый слой предназначен для своего типа интерфейса. 1 — недиегетический, 2 — мета, 3 — диегетический и пространственный

Но не стоит воспринимать классификацию типов интерфейсов в формате «один тип-один интерфейс». Скорее это просто перечисление классифицированных визуальных средств, доступных дизайнерам пользовательского интерфейса для передачи информации игроку. Их мы можем изменять, объединять друг с другом и комбинировать с другими средствами выразительности (саунд-дизайн, вибрация для геймпадов).

Far Cry 5. Самый явный пример: получение урона с добавлением мета-интерфейса, шейком камеры, звуковым сопровождением и изменением недиегетического показателя брони и здоровья
Far Cry 5. Самый явный пример: получение урона с добавлением мета-интерфейса, шейком камеры, звуковым сопровождением и изменением недиегетического показателя брони и здоровья

Для понимания также разберем в качестве примера UI получения урона в Snowrunner.

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

Окей, но почему наш интерфейс повреждений грузовика расположен именно так?

Расположение элементов

Информация должна располагаться в доступности от точки/области основного фокуса внимания игрока во время игрового процесса. Для понимания — разобьем экран на базовые блоки HUD:

Базовые блоки в произвольном исполнении
Базовые блоки в произвольном исполнении

Здесь мы видим деление экрана на такие блоки:

  • Главную область фокуса (MFA) — область экрана с самой высокой видимостью для игрока, где в основном концентрируется его внимание во время игрового процесса. Центр этой области — это центр экрана, точка концентрации основного геймплея.

  • Области вокруг — с более низкой видимостью за счет своего отдаления от точки максимальной видимости, которые как раз таки чаще всего используются для отображения UI.

Главная область фокуса

Если вдруг вы играете во что-то более быстрое и когнитивно нагруженное, нежели Snowrunner, вам необходимо получать информацию как можно быстрее и удобнее, для того, чтобы быть успешным, например, в PvP/PvE шутерах. Именно поэтому такие элементы, как указатель направления атаки, появляются в момент попадания, находятся в главной области фокусировки и имеют достаточно крупный размер. И именно поэтому наши пространственные показатели нанесенного/наносимого урона грузовику из примера выше в основном находятся в главной области фокусировки внимания игрока.

Пример: индикатор видимости и направления атаки в Far Cry 5, расположенный в MFA
Пример: индикатор видимости и направления атаки в Far Cry 5, расположенный в MFA

Но это базовая информация с одним состоянием и небольшим количеством информации в достаточно медленном геймплее. Можно ли размещать в MFA сложные системы?

Можно. Разберемся на примере индикатора видимости Far Cry 5.

Исходя из поведения элемента, персонаж считается видимым, только если NPC накопил достаточное количество очков видимости. После этого недружественные NPC атакуют персонажа игрока. При этом, как можно заметить, игрок может наблюдать следующие состояния:

  1. «Спокойное» состояние, когда персонаж игрока никак не триггерит окружающий мир своими действиями, т. к. некому реагировать; 

  2. «Настороженное» состояние, когда игрок своими действиями каким-то образом привлек внимание NPC к персонажу, но они его не обнаружили; 

  3. «Видимое» состояние, когда персонаж игрока был обнаружен NPC; 

  4. «Угроза», когда NPC атакуют персонажа исходя из игровых условий.

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

  1. «Настороженное» состояние может как перейти в состояние «видимости» (если NPC обнаружат игрока), так и перейти в «спокойное» состояние (если персонаж игрока по итогу поиска не был обнаружен); 

  2. «Видимое» состояние может смениться «настороженным», если игрок спрятался, и NPC не могут его обнаружить достаточно долгий промежуток времени/если больше нет NPC, способных реагировать на действия игрока, или смениться на состояние «угрозы».

Из информации, которую мы передаем игроку, он может принимать решения:

  1. Прервать накопление видимости, спрятавшись от NPC;

  2. Сбросить накопленную видимость, выйдя из области взаимодействия с уже заметившим/атакующим его NPC или же прервать отображение индикатора видимости через уничтожение противника. Тут есть нюанс: при этом через анимацию элемента игра также подталкивает нас к тому, чтобы уничтожить цель.

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

В этом примере также хорошо прослеживается значение выбранного элемента: если заменить заполняющийся элемент (прогресс бар) на маленькую иконку или просто пост-процесс, то мы не сможем передавать информацию о накоплении видимости персонажа NPC/переходах системы из одного состояния в другое, и игрок не сможет реализовывать механику прерывания осознанно.

Вернемся к теме: также в MFA могут отображаться такие важные элементы, как указатели здоровья (например, в PvPvE шутерах), интеракт-триггеры, критические сообщения о геймплее, активация/завершение квестовых заданий, получение награды и т. д.

Главное: появление данных интерфейсов в области MFA должно быть оправдано и необходимо. Суть размещения в этой области — быстро перетягивать внимание игрока с геймплея на себя, чтобы, например, игра могла продолжаться (цель игровой сессии Warzone — оставаться в живых максимально долгое время), и игрок продолжал получать удовольствие от игры.

Области вокруг

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

Расположение вокруг MFA позволит игроку просто и быстро использовать отображаемую информацию, тратя на это небольшое количество времени и усилий. Однако стоит заметить, что видимость интерфейсов в областях вокруг MFA все-таки будет значительно снижена в сравнении с интерфейсами внутри MFA.

Снижение видимости интерфейса в зависимости от его удаления от точки концентрации внимания и размера описывается законом Фиттса

Время, необходимое для быстрого перемещения к целевой области (к областям вокруг MFA), является функцией отношения между расстоянием до цели (зрительный путь) и размером цели (целевого интерфейса). Если проще: чем дальше наш интерфейс находится от центра экрана, чем он меньше, тем менее заметным он становится для внимания игрока, а значит — он будет тратить больше когнитивных усилий на то, чтобы с ним взаимодействовать.

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

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

Получается, чтобы интерфейс не мешал геймплею:

  1. Следует приоритезировать информацию по критичности отображения;

  2. В Main Focus Area следует отображать только критически важную для игрока информацию в текущий момент времени;

  3. В областях вокруг MFA следует отображать остальную информацию, обернутую в UI, который при необходимости сможет сместить внимание пользователя на себя.

В заключение

Пробуйте, экспериментируйте. Не бойтесь использовать нестандартные решения, придумывайте классные интерфейсы и любите игры, над которыми вы работаете.

P. S. Если статья зайдет, в следующей мы разберем более детально несколько элементов HUD и поговорим о правилах и гайдлайнах их отображения на нем.

Источник: https://habr.com/ru/company/pixonic/blog/683400/


Интересные статьи

Интересные статьи

При работе с потоковым видео качество и скорость воспроизведения играют ключевую роль. Можно ли настроить многопоточную трансляцию без покупки дорогостоящего «железа»? Попробуем разобраться.Проблема. ...
Привет! Меня зовут Саша Шутай, я тимлид в AGIMA. В прошлой статье я рассказывал, что делать, если на проекте Bitrix сожительствует с Vue.js и поисковые боты не видят контента сайта. А в этой помогу ра...
У некоторых бизнес-тренеров в области е-коммерса и консультантов по увеличению интернет-продаж на многие вопросы часто можно слышать универсальную отмазку — «надо тестировать» или другую (чтобы не...
Но если для интернет-магазина, разработанного 3–4 года назад «современные» ошибки вполне простительны потому что перед разработчиками «в те далекие времена» не стояло таких задач, то в магазинах, сдел...
Мы публикуем видео с прошедшего мероприятия. Приятного просмотра.