Что такое интерфейс в игре
Что такое интерфейс игры?
Интерфе́йс (англ. interface — поверхность раздела; граница раздела; поверхность контакта; стык, область контакта, взаимодействия; средство осуществления взаимного воздействия, взаимосвязи) — совокупность возможностей, способов и методов одновременного действия (в том числе посредством обмена информацией между ними) двух имеющих общее разграничение, то есть не связанных линейно, информационных систем, устройств или программ, определяемая их характеристиками, а также характеристиками соединения, сигналов обмена и т. п.
В информатике интерфейс рассматривается как общая граница двух отдельно существующих составных частей, посредством которой они обмениваются информацией в режиме одновременности. Этот обмен может быть, как двусторонним, так и односторонним.
Если одна из взаимодействующих систем — человек, чаще говорят лишь о второй системе, то есть об интерфейсе той системы, с которой человек взаимодействует в режиме одновременности.
элементы электронного аппарата (телевизора, автомагнитолы, часов и т. п.) — дисплей, набор кнопок и переключателей для настройки, плюс правила управления ими — интерфейс системы «человек — аппарат»;
клавиатура, мышь и пр. устройства ввода — элементы обеспечения соответствия в режиме одновременности в системе пользовательского интерфейса (в свою очередь, и сами клавиатура и мышь имеют свои средства сопряжения с компьютером, аппаратные и программные).
Этот термин применяется только в информатике, поскольку имеется в виду совокупность унифицированных технических и программных средств и правил (описаний, соглашений, протоколов), обеспечивающих одновременное взаимодействие устройств и/или программ в вычислительной системе или обеспечение соответс
Игровой интерфейс и с чем его едят
Всем привет! Данная статья — об игровых интерфейсах и порядку работы с ними. Она предназначена в первую очередь для тех, кто работает в игровой индустрии и в том или ином виде влияет на разработку интерфейса, но при этом сам не является UI/UX специалистом. Проект-менеджеры, продюсеры, геймдизайнеры, программисты, работающие с GUI, художники — я писал этот текст, думая о вас, ребята.
Вступительное слово. В своей практике я не раз сталкивался с тем, что разработкой и проектированием игровых интерфейсов занимаются люди, напрямую к этой области не относящиеся. Скажу больше, часто это люди, для которых обязанности, связанные с интерфейсом, являются дополнительным и нежелательным обременением. Чаще всего это связка геймдизайнер+художник, в которой геймдизайнер продумывает функционал и разметку экранов, а художник добросовестно старается “сделать красиво”. При этом зачастую ни тот, ни другой не имеют опыта работы с интерфейсами, не задумываются о юзабилити, пользовательских сценариях или единообразии элементов и в целом не понимают, как организовать процесс работы с интерфейсом, чтобы получить гарантированно хороший результат. И это происходит не по вине художников или геймдизайнеров, просто сама ниша игровых интерфейсов очень специфическая и узкая, информации по работе с ними очень мало, и людям банально негде набраться опыта, не с чего начать. Я хотел бы поделиться своим опытом и наблюдениями в этой сфере и предложить некую структуру, чек-лист, с которым можно сверяться при разработке игрового интерфейса на (вашем) проекте.
Пара слов о себе: работу в геймдеве я начал в 2011 году как flash- и web дизайнер. C 2013 работаю исключительно как дизайнер интерфейсов на игровых проектах, в основном мобильных. За это время я поработал в офисах как небольших стартапов, так и в крупных, устоявшихся компаниях; попробовал себя в качестве фрилансера-удаленщика и приходящего “эксперта”. Всего я поучаствовал в создании примерно двух десятков игр разного масштаба и качества, из которых около дюжины дожили до релиза и лежат в маркете. Если кому интересны конкретные тайтлы — пишите в личку.
И давайте договоримся сразу: то, что написано ниже — ни в коем случае не истина в последней инстанции. Мой опыт ограничен. Если вы считаете, что где-то я написал ерунду (или знаете, как сделать что-то лучше) — пожалуйста, свяжитесь со мной или опишите свое видение в комментариях.
Окей, теперь к сути. Давайте для начала окинем всю последовательность предлагаемых мною шагов разом, а затем я постараюсь объяснить, зачем нужен каждый из них и какие грабли вы рискуете собрать, пропустив или недооценив каждый из шагов.
1) Определение структуры и главных функциональных частей интерфейса.
2) Прототипирование ключевых экранов в виде схем.
3) Сброка и тестирование прототипа. Поиск стилистики и внешнего вида.
4) Отрисовка экранов, составление UI kit’а. Документация.
5) Внедрение в игровой движок, приемка и контроль качества.
6) Добавление интерфейсных анимаций.
7) Аналитика результатов.
Шаг первый. Определение структуры и главных функциональных частей интерфейса.
В процессе накидывания этих первичных мокапов будут материализовываться “правила”, по которым строится интерфейс на данном конкретном проекте. Как осуществляется навигация? Где будут располагаться кнопки? Сколько текста понадобится и какого примерно размера он будет? Нужны ли тултипы и иные всплывающие элементы и если да, то где и в каком формате?
На выходе вы должны получить генеральную схему экранов проекта, по возможности минимизировав при этом количество “белых пятен” на ней. Выглядит это как-то так:
На что тут следует обращать внимание:
Понятно, что в реальности продумать все заранее невозможно, и вы постоянно будете сталкиваться с ситуацией, когда надо “добавить сюда еще вот это и вон то”. Это абсолютно нормально, будьте готовы к таким ситуациям: заранее закладывайте возможность добавления в экран новых элементов, обговаривайте этот вопрос с гейм-дизайнерами или проект-менеджерами (“как думаешь, что еще может добавиться на этот экран в ближайшей перспективе?”) Надо понимать, что у каждого экрана есть свой предел прочности, по достижении которого понимаешь, что проще все удалить и сделать по-другому, чем продолжать попытки впихнуть невпихуемое.
Это, кстати, классическая и неизбежная проблема проектов-долгожителей, особенно мобильных и браузерных. Чем дольше живет игра, чем шире и разнообразнее становится ее функционал, тем безобразнее, замусореннее выглядит ее интерфейс.
Шаг второй. Сборка прототипа, поиск стилистики.
Итак, у нас на руках есть дизайн-документ, общая, более-менее цельная заглушечная схема экранов и связей между ними. Теперь мы уже более-менее понимаем, какой объем работы по части интерфейса предстоит сделать, понимаем количество экранов и примерный набор элементов на каждом из них. Это прекрасный момент для того, чтобы начать собирать на коленке уродливый прототип интерфейса из квадратиков и кружочков. Да, вы никогда не покажете его своим друзьям и маме, но он ответит на множество вопросов, в том числе интерфейсных:
Параллельно со сборкой прототипа интерфейса (что обычно занимает время), имеет смысл начинать работы по поиску его стилистики и визуализации.
Почему не раньше, спросите вы? До схем и, возможно, даже до дизайн-документа? Можно и раньше. Но в таком случае вы рискуете столкнуться с (очень возможной) ситуацией, когда картинка, нарисованная по абстрактному ТЗ, совершенно не впишется в реальные требования конкретно вашего проекта, и придется искать стилистику с начала.
Перед началом отрисовки экранов исполнителю (художнику или дизайнеру — короче, тому кто будет отрисовывать) необходимо прежде всего максимально дотошно расспросить заказчика о том, каким он видит интерфейс проекта. На что тот будет похож? Какие игры (по мнению заказчика) близки к вашему проекту визуально и атмосферно? А какие игры нравятся самому заказчику, во что он играет, какие проекты уважает? Здорово, если у вас на руках уже будут какие-то атмосферные концепты, отражающие стилистику будущей игры, или фейк-скрины, но чаще всего подобная роскошь на этом этапе недоступна.
Вообще, общение с заказчиком — это очень важная часть работы, которая может сэкономить (или потерять, в случае пропуска) всем в производственной цепочке кучу времени. К сожалению, большинство дизайнеров сложно назвать эталоном по части общения с клиентом (я тут, кстати, не исключение). Именно поэтому так важно сделать над собой психологическое усилие, а также объяснить (как себе, так и заказчику) смысл и важность происходящего. Приемка интерфейсов, как и приемка арта — дело сугубо субъективное, от этого никуда не денешься, и крутится оно вокруг личности и системы ценностей заказчика. В процессе работы вы можете давать рекомендации или советы, высказывать мнения и приводить примеры, но последнее слово всегда остается за заказчиком или его представителем, и это логично. А заказчики бывают очень разные: кто-то хорошо представляет, чего хочет, кто-то — нет. Одни могут сформулировать запрос в виде картинок (что просто прекрасно), другие готовы описать на словах (что тоже неплохо), третьим не хватает насмотренности или опыта (а иногда и желания, т.к. они считают, что выполняют тем самым чужую работу) и им требуется помощь с формулировкой мыслей. Вообще, это тема для отдельной статьи. В рамках этого материала мы на этом задерживаться не будем.
Заметка на полях: требования и пожелания от заказчика лучше фиксировать в письменном виде — таким образом ему сложнее потом “передумать” или “забыть” сказанное. И никогда не соглашайтесь на “ой, не знаю, вы там давайте рисуйте что-нибудь, а там разберемся”. Это мартышкин труд, который никому не нужен, в том числе заказчику.
Результаты работы с интерфейсом на втором этапе:
Во-первых, создан или ведется работа по сборке прототипа интерфейса, основанного на схемах и заглушечном визуале.
Во-вторых, собран набор референсов для чистового визуала, которые нравятся и одобрены заказчиком. Каждый реф может зацепить заказчика чем-то конкретным (цветовой гаммой, решение главного меню, системой навигации) или просто общим впечатлением от картинки. Храните эти рефы как зеницу ока — они станут краеугольным камнем для следующего этапа.
Заметка на полях: в первую очередь лучше набирать референсы из той же рыночной ниши, что и ваш проект. Дело в том, что если вы наберете отличные рефы из ААА игр для ПК, а сами занимаетесь разработкой мобильной игры, то согласовать-то их может быть будет и проще, а вот реализовать всю эту красоту в ограниченном мобильном формате будет практически невозможно. В результате на каком-то этапе вы столкнетесь с закономерным вопросом от заказчика: “Мы же подобрали такие крутые рефы, почему в результате получилось ВОТ ЭТО?”.
Еще одна заметка на полях: уделяйте на этом этапе побольше времени и сил изучению конкурентов. Смотрите скриншоты, читайте обзоры, проходите на ютубе, в конце концов. Чем больше будет ваша насмотренность, тем проще вам будет понять, что лучше работает (или не работает) в аналогичных проектах и тем легче аргументировать свое мнение. Не спешите изобретать велосипеды и не бойтесь простоты.
Шаг третий. Обкатка прототипа, отрисовка превью экранов.
Итак, у нас есть рабочий прототип, в котором реализован заглушечный интерфейс. Он, в целом, работает, выполняет свою функцию. А еще у нас есть визуальный ориентир для отрисовки экранов в виде набора референсов. Самое время их совместить: “одеть” несколько экранов в понравившуюся “шкурку”.
В процессе отбора рефов обычно становятся понятны основные направления для отрисовки первых экранов-превью: Скажем, если у вас sci-fi сеттинг, а в одобренных заказчиком рефах лежат Deus Ex и XCOM… ну, я бы сказал, что вам придется делать превью как минимум в двух вариациях:
А если в рефах лежат какие-то близкие по стилистике экраны (тот же XCOM и, скажем, Mass effect) а времени не очень много, то вполне можно обойтись и одним:
После того, как мы довели один экран-превью до состояния, которое нравится заказчику, имеет смысл отрисовать еще парочку в той же стилистике, выбирая их по принципу “максимально отличающихся”. К примеру, если первым был экран с небольшим количеством крупных элементов, то имеет смысл в дополнение к нему взять экран с большим количество маленьких элементов (например, инвентарь) и что-нибудь табличное (вроде таблицы рейтингов или статистики боя). Таким образом, вы уже на старте отработаете максимальное количество различных элементов и будете более-менее уверены в том, что выбранная “одежда” универсальна и будет достойно выглядеть на любом экране.
На этапе отрисовки превьюшек вполне можно пренебречь какими-то элементами или делать допущения в стиле “эту рамку потом придется подправить, иначе в движок ее не вставить” или «вот эти иконки надо будет подогнать под один размер». Здесь важно за минимальное количество времени получить максимально презентабельную, “продающую” картинку, которую уже не стыдно показывать инвесторам, использовать в презентациях и т.д.
Результат этого этапа: 3-4 отрисованных экрана “чистового” качества, одобренных заказчиком и обкатанная в прототипе схема интерфейса.
Шаг четвертый. Отрисовка экранов, составление UI kit’а, документация.
Это самый объемный этап работы с интерфейсом, занимающий примерно 70% всего рабочего времени. Причем для него у меня нет каких-то хитростей и лайф-хаков, только кропотливая работа и чугунный зад. Планомерно и постепенно, экран за экраном отрисовываются и внедряются в движок. Одновременно с этим обновляется их состав и функционал (потому что с момента рисовки схем обычно многое уже поменялось), а также составляется документация.
Пара слов о документации. Как показала практика, очень полезно описывать функционал экранов. Письменно. Для кого-то это прозвучит очевидным советом от кэпа, но вы удивитесь, как часто этот этап пропускают (особенно в небольших компаниях). Не в последнюю очередь это происходит потому что, во-первых, никто не любит бюрократии (у нас же тут геймдев и рок-н-ролл или что?), а во-вторых, потому что с документацией надо уметь работать. Это подразумевает как умение грамотно сформулировать описание со стороны ГД или UI/UX дизайнеров, так и умение и привычку использовать его при сборке экрана программистами. Ну и в-третьих, документацию ведь надо держать в свежем виде и регулярно обновлять. Это тоже требует времени, сил, желания и, главное, понимания, зачем оно всё нужно.
Без письменных описаний экранов вы рискуете столкнуться со всеми проблемами, связанными с человеческим фактором, забывчивостью и коммуникационными проблемами. Ваш UX-дизайнер внезапно увольняется и улетает на Бали. Программисты собирают экраны не так, как задумывалось, а так, как они считают правильным, апеллируя к тому, что “им про это не сказали”. Геймдизайнер или проект-менеджер забывает принятые решения, поскольку они не были зафиксированы, и всякий раз выдает новую версию.
Короче, приучайте себя к работе с документацией. Договоритесь внутри команды, как именно это делать: какая должна быть структура, какие инструменты использовать, на чем акцентировать внимание. А если вы уже вовсю пользуетесь документацией на проекте и сейчас только понимающе усмехаетесь, покручивая ус — берите печеньку, вы клёвые.
Дальше немного про GUI pack (или, как его еще называют, UI kit или design case). После отрисовки нескольких базовых экранов обычно становится понятен основной набор элементов, из которых будет состоять ваш интерфейс, а также правила их компановки. При дальнейшей работе с экранами будет примерно на 60-80% состоять из реюза уже готовых элементов по уже готовым правилам. Имеет смысл вынести этот “конструктор” с элементами и описаниями в отдельный, эталонный файл. Выглядит он примерно вот так:
Автор изображения — Johnny Waterman
С готовым UI KIT’ом все в команде (особенно это актуально для верстальщиков и программистов) будут знать, где содержатся самые последние, эталонные версии всех интерфейсных элементов. В то же время, в макетах конкретных экранов дизайнерам можно будет не держать десятки дублирующих слоев вроде всех состояний кнопок и переключателей.
Шаг пятый. Внедрение в игровой движок, контроль качества.
Этот этап выделен условно, т.к. сборка интерфейсов в движке обычно идет параллельно их разработке. Взяли экран со схемы, отрисовали, нарезали, отдали программистам, взялись за следующий. При этом вы “ведете” экран, находящийся в производстве, до победного конца. Только когда он собран в версии для целевых устройств (кстати, вы же не забыли про планшеты?), выглядит и работает на них так, как планировалось изначально, вы можете облегченно выдохнуть и мысленно поставить галочку в графе “сделано”. До следующей итерации.
Помните, что результат работы UX/UI специалистов — не статичная фотошопная картинка и не абстрактная схема, а красивый и, главное, функциональный интерфейс, с которым будет работать пользователь. То, насколько хорош финальный продукт, показывает, настолько хороши конкретно вы как специалист. Поэтому будьте строги и внимательны ко всем звеньям в производственной цепи, и в первую очередь к себе. Не закрывайте глаза на всякую лажу под предлогом того, что это “не моя ответственность”.
Шаг шестой. Полировка и добавление анимаций.
Это бонусный этап. Будем откровенны: при приближении даты релиза (обычно уже несколько раз перенесенной) у всех в команде начинают пылать различные части тела. Времени на полировку (а особенно полировку интерфейса, которому исторически отводят второстепенное значение) никогда не хватает. Поэтому важно изначально задумываться о том, что и когда вы будете доделывать, а также об интерфейсных анимациях. Есть возможность — добавляйте их сразу, еще при первой сборке экрана. Нет такой возможности — выделите на это отдельное, конкретное время в планах разработки. Жестко стойте на своем и не соглашайтесь отодвигать доделки и анимации на неопределенное “потом”, регулярно напоминайте про них.
Хороший игровой интерфейс “живет” и динамично реагирует на действия игроков. Интерфейсная анимация — как щепотка специй, способная преобразить вкус и ощущения от всего “блюда”. Она делает интерфейс более плавным, связанным, последовательным. Она сглаживает резкие переходы, привлекает внимание к нужным местам, развлекает — короче, улучшает игровой опыт пользователей в целом. При этом, как и в кулинарии, важно не переборщить и не поддаться искушению заанимировать всё подряд. Знайте меру.
Шаг седьмой. Аналитика интерфейсов.
Еще один условно-бонусный этап. В идеальном мире разработчики проверяют основные гипотезы (в т.ч. интерфейсные), привлекая для тестов реальных пользователей из своей ЦА, и принимают решения, исходя из полученных данных. При правильном подходе такой метод позволяет (в теории) отразить более-менее объективное положение дел и дать ответ на вопрос, что в интерфейсе действительно работает, а что нет.
В реальности такое встречается редко: не все могут позволить себе дорогостоящие плей-тесты, мало кто умеет с ними работать и понимает, зачем они нужны. Даже после софт-ланча часто анализируются только базовые показатели вроде DAU, WAU ROI и т.п., не касающиеся напрямую интерфейсов. Т.е. то, что какая-то кнопка никуда не ведет, на этапе софт-ланча заметят, а вот то, что игроки не догадываются вызвать всплывающую по тапу подсказку, уже нет.
В своей практике я, к своему сожалению и стыду, до сих пор еще не сталкивался с полноценным UX-тестированием и последующей аналитикой результатов. Основным методом принятия решений всегда была т.н. “экспертная” оценка. Это когда решения по теме принимает одно лицо (или небольшая группа лиц) которое, как считается, обладает необходимым опытом и компетенцией. Понятно, что это не самый точный и, мягко говоря, довольно субъективный метод.
Однако тот факт, что я лично не сталкивался в с UX-тестированием в геймдеве, не означает, что его не существует в природе. Насколько мне известно, отдельные игровые компании имеют возможность и желание проводить полноценные плей-тесты и активно ими пользуются. Мне очень интересно было бы узнать об их методиках и результатах, а также о том, как они к этому пришли к организации подобных мероприятий. Если вам есть что сказать на эту тему — пожалуйста, свяжитесь со мной или расскажите об этом опыте в комментариях или собственном материале.
На этом, пожалуй, всё. Несмотря на то, что многие вещи я обрисовал очень коротко или пропустил вовсе, статья вышла объемнее, чем рассчитывалась изначально. Спасибо, что были стойкими и дочитали ее до конца! Надеюсь, что вы нашли для себя что-то полезное и интересное. Будет вдвойне приятно, если что-то из прочитанного показалось вам достаточно интересным для того, чтобы опробовать это на практике.
Буду благодарен за любые комментарии, вопросы и замечания по сути, а также просто интересные истории из жизни, связанные с игровыми интерфейсами. Не стесняйтесь писать на почту.
Дизайн игрового интефейса. Теория диегезиса.
Дизайн пользовательского интерфейса (UI — User Interface) часто является одним из наиболее сложных аспектов разработки игры. Потому что информации, которую нужно донести до игрока порядочно, а места, чтобы это все разместить на экране очень мало. Когда интерфейс плохо разработан, то даже отличная игровая концепция может быть сведена к удручающему пользователя куску неинтересного игрового кода.
Есть несколько теорий, которые могут быть использованы дизайнерами для анализа пользовательского интерфейса и помощи в выборе нужного решения. Мы будем рассматривать теорию диегезиса. Это адаптированная теория диегезиса, используемая в литературе, кино и театре. Диегезис относится к миру, в котором происходит рассказываемая история, и, следовательно, она фокусируется на играх, как на рассказах. Другими словами диегезис — это все, что является истинным в игре, это реальность внутри игрового мира: персонажи, артефакты, события, общение, слухи, законы природы и прочее. Все, что находится в рамках диегезиса, называют диегетичным, все, что находится снаружи — недиегетичным.
Есть два основных понятия этой теории: нарратив (повествование ) и четвертая стена.
Нарратив — это посыл, который передает игроку сведения о действии, возникновении или развитии событий в игровом мире. Проще говоря, это та история, которую дизайнер хочет передать; будь то история блоков, падающих с неба, которые нужно приземлить в землю в нужном месте (Tetris) или путешествие по чужой земле (Machinarium).
Не все элементы игры являются частью повествования. Например, меню игры и HUD (Heads-Up Display), потому что персонажи игры не в курсе этих элементов. Это не означает, что эти компоненты не поддерживают нарратив игры. Например, футуристическая игра обычно имеет элементы интерфейса, которые также выполнены в футуристическом стиле.
В театре, откуда и позаимствовано это выражение, четвёртой стеной называют невидимую стену из мыслей, ощущений и чувств, которая отделяет сцену от зрителей. Когда актёр обращается непосредственно к зрителям, он ломает воображаемую стену и как можно глубже вовлекает окружающих в представление. В играх всё сложнее: не только четвёртая, но и остальные три стены здесь под вопросом, да и качество шоу чаще зависит от сноровки игрока. Для того, чтобы игроку погрузиться в игровой мир, он должен пройти через четвертую стену. Легкость, с которой игрок перемещается между реальным миром и миром игровым зависит от того, как разработчик интерфейса обеспечивает подачу информации для игрока.
Теперь давайте зададим себе два вопроса о каждом компоненте интерфейса:
-Это составная часть игровой истории? (Это часть повествования?)
-Это составная часть игрового пространства? (Это за четвертой стеной?)
В зависимости от ответов, мы можем классифицировать компонент интерфейса в один из четырех классов: диегетический, недиегетический, пространственный или мета.
На рисунке ниже показано, как вопросы относятся к классам.
Для диегетических компонентов мы должны ответить на наши два вопроса следующим образом:
-Элемент является компонентом в игровой истории? ДА
-Элемент является компонентом в игровом пространстве? ДА
Диегетические элементы пользовательского интерфейса существуют в игровом мире, поэтому персонаж игрока может взаимодействовать с ними через визуальные, звуковые или тактильные средства. Диегетические элементы UI повышают нарративный опыт игрока, не отвлекая при этом от повествования в мире и обеспечивая более захватывающий, комплексный и кинематографический опыт.
Так, например, в Far Cry 2 была попытка сделать игровой опыт максимально диегетическим — в игре, как мы помним, не было никакого HUD’а. Использование многочисленных гаджетов и предметов в игре (например, использование настоящего компаса, чтобы ориентироваться в игровом мире) позволяет игроку получить информацию, не обращаясь к элементам за пределами игрового мира.
Dead Space является еще одним хорошим примером полностью диегетического интерфейса. В отличие от большинства игр, разработчики Dead Space сразу взяли курс на то, что все элементы интерфейса должны быть «в игровом мире».
Интерфейс использует довольно традиционную систему HUD с одной большой особенностью: он представлен в игре в виде голограммы и представляет из себя практически хрестоматийный пример диегетического решения, где интерфейс существует в игровом мире и (теоретически) может быть виден игровым персонажам. UI объясняется как голограммы, созданные скафандром аватара, в котором также разместили индикатор здоровья и уровень стазиса. Это «оправдание» открывает возможность использования практически любого интерфейса, пока он представлен в виде голограмы.
Похожим путем пошли разработчики в Метро 2033. В игре для контроля времени пригодности фильтра для противогаза использовался диегетический UI без HUD элементов, чтобы помочь поддержать нарратив игры. Это было довольно рискованным решением, так как медленное время отклика такого UI может сорвать все планы игрока и откинуть его к последнему чекпоинту, но это является частью игровой механики.
Подобные приемы здорово помогают более глубоко погрузиться в мир игры, но если это сделано неправильно, это может иметь обратный эффект. Например, в Grim Fandango игрок за один раз вынужден искать в своем инвентаре только один предмет. Это немного расстраивает процесс погружения игрока в нарратив игры, и он невольно возвращается обратно в реальность.
В то же время попытки сделать мир более захватывающим и реалистичным могут сыграть с вами злую шутку и нарушить повествование истории.
В том же Grim Fandango, голова персонажа поворачивается к объектам, чтобы указать, что они являются интерактивными. Хотя это, пожалуй, более реалистичный способ передачи информации игроку, движение это неловко и неестественно. Это отвлекает и не так полезно, как более традиционные для приключенческих игр подсвеченные объекты и изменяющийся курсор мыши.
Но не стоит думать, что диегетические элементы интерфеса используются только в шутерах. В RTS играх, например, к ним можно отнести визуальные повреждения юнитов и зданий.
Для недиегетических компонентов мы должны ответить на наши два вопроса следующим образом:
-Элемент является компонентом в игровой истории? НЕТ
-Элемент является компонентом в игровом пространстве? НЕТ
HUD (как представитель недиегетического UI) в играх обосновался давно и все мы с удовольствием пользуемся им. Эта система обеспечивает нам доступ ключевой информации довольно простым способом. Если все сделано правильно, то игрок даже не замечает его.
Некоторые игры, такие как Gears of War, имеют минималистский подход, который ограничивает количество HUD элементов, в то время как другие, такие как World Of Warcraft, предоставляют более обширную информацию через пестрый и насыщенный HUD.
World Of Warcraft имеет сложный, но чрезвычайно гибкий и настраиваемый пользовательский интерфейс, который позволяет игрокам оптимизировать его для своих игровых потребностей. Они могут сами выбрать, как много будет “беспорядка” на экране в зависимости от их потребностей.
Хотя игру часто критикуют за ее сложной интерфейс (в основном указывая на то, что в игру будет проблемно играть без тонкой настройки), стоит помнить, что World Of Warcraft является достаточно сложной игрой, которая имеет множество различных типов игрового поведения. Сложность интерфейса является результатом сложности игры.
Наконец, Mass Effect 3 использует множество недиегетических элементов UI для того, чтобы информировать игрока среди прочего о выбранном оружии и силе персонажа. Учитывая футуристический сеттинг игры сложно представить как хотя бы часть этой информации может быть органично вписана в игровой мир, нарратив или даже оба эти понятия. При этом недиегетические элементы UI наследуют визуальный стиль игры и органично в него вписываются.
На самом деле не всегда ясно, к какому конкретно типу UI относится тот или иной элемент в игре. Например, является ли HUD спидометра в гоночной игре действительно недиегетическим компонентом? Спидометр, представляющий собой размещенный в кабине клон физического спидометра, безусловно, является диегетичным элементом, в то время как при выборе вида сверху и отображении спидометра в наложении носит явно недиегетичный характер.
Пример диегетического спидометра
Пример недиегетического спидометра
Для пространственных компонентов мы должны ответить на наши два вопроса следующим образом:
-Элемент является компонентом в игровой истории? НЕТ
-Элемент является компонентом в игровом пространстве? ДА
Эти компоненты, которые визуализируются в игровом мире, но не являются частью игрового мира. Персонажи игры также не подозревают о их существовании. Например, аура выбора юнита в стратегических играх. Они используются, чтобы обеспечить дополнительную информацию о компоненте в мире, хотя эта информация не является частью повествования. Информация предоставляется в месте, на котором сосредоточено внимание игрока, уменьшая беспорядок в HUD.
Хорошим примером этого являются ауры в Starcraft 2. Они указывают на тот или иной геймплейный эффект, который в настоящее время выбран и диапазон, в котором он будет осуществляться.
Другой пример — иконки, которые появляются над головами персонажей The Sims.
Аура выбора в Starcraft 2 сразу же дает понять над какими юнитами игрок имеет контроль, что делает выбор намного легче. Подумайте о том, как трудно было бы выбирать их из списка в HUD — было бы очень проблемно увидеть, какие единицы ближе всего к зоне действия в игровом мире.
Splinter Cell Conviction также использует пространственные элементы в виде проекций, которые иллюстрируют цели в игровом мире. Этот тип наложения в окружающей среде используются для передачи сообщений игроку, а не персонажу.
Fable 3 является еще одним примером, где пространственные элементы используются чтобы предоставить больше информации игроку и предотвратить его от переключений к экрану карты. Светящийся след почти идеально вписывается в фантастический мир и ведет игрока к следующей цели.
Пространственные элементы могут быть красивыми частями игрового мира, когда они работают с геометрией этого мира. Так, например, пространственные элементы из Forza 4 представляют собой простой и элегантный стиль, который удачно контрастирует с богатыми 3D качествами игры. Жирная иконография в сочетании со стильными типографическими элементами создает прекрасный UI для Forza 4
Для мета компонентов мы ответить на наши два вопроса следующим образом:
-Элемент является компонентом интерфейса в игре истории? ДА
-Элемент является компонентом в игровом пространстве? НЕТ
Мета компоненты представляют собой элементы, которые выражаются как часть повествования, но не как часть игрового мира. Потрескавшиеся стекло и брызги крови — наиболее распространенные примеры таких эффектов, которые взаимодействуют с четвертой стеной.
Эти компоненты стремятся вовлечь пользователя в реальность игры с применением сигналов на экране, как будто игра непосредственно взаимодействует с игроком.
Типичным примером такого мета элемента UI являются кровавые капли в качестве хелсбара в Call of Duty: Modern Warfare 2. Брызги крови на экране показывают игроку, что наш персонаж теряет здоровье.
Взаимодействие с телефоном в Grand Theft Auto 5 представляет собой интересный пример. Он имитирует взаимодействие как в реальном мире — вы слышите звонок телефона и есть некоторая задержка перед ответом на него персонажа и игрока. После этого элемент появляется на переднем плане, так что это не смотря на то, что на самом деле телефон представляет собой мета элемент начало взаимодействия с ним является диегетическим. Персонаж отвечает на телефон, но фактическая элемент пользовательского интерфейса находится в плоскости HUD’а так что только игрок видит его.
Методы физического взаимодействия и захватывающие технологии, такие как VR-гарнитуры, обещают оспорить дизайн игрового пользовательского интерфейса, что позволит одновременно создать более тесные связи между игроком и персонажем в то же время как и вовлекать обоих в непосредственное участие. Технология даст возможность взаимодействия на более глубоких уровнях с добавлением аудио и тактильных элементов. Это будет означать, меньшее использование недиегетических UI в играх.
Игровой UI имеет ключевое преимущество (или недостаток с другой точки зрения) в том, что игроки часто вовлекаются в нарратив и/или игровую механику на достаточном для них уровне чтобы выучить новые шаблоны взаимодействия, или простить плохие. В этом, вероятно, и есть причина почему так много игр имеют плохой интерфейс, так как тестирование чаще всего охватывает основное ядро игровой механики в то время как UI рассматривается как вторичная цель.