Согласно Исбистер и Шафферу [2008], чтобы сделать игру (или программу) удобной в использовании, нужно «учитывать ограничения человеческой памяти, восприятия и внимания, предвосхищать возможные ошибки и быть к ним готовым, знать ожидания и возможности будущих пользователей». Параметром «юзабилити» измеряется способность системы (точнее, ее образа – того, что пользователь видит и с чем взаимодействует) четко сообщать свое назначение и варианты взаимодействия. Поскольку в игры играют люди, разработчикам, если они хотят сделать свой продукт удобным, необходимо принимать в расчет человеческие ограничения и возможности. Это не значит, что игру нужно «отуплять», как утверждает одно из распространенных заблуждений о UX (см. главу 10). Речь о том, чтобы убирать лишние и незапланированные неудобства, которые могут возникнуть, если не учитывать человеческое восприятие, внимание и мотивацию.
Юзабилити – это первый шаг к созданию классного пользовательского опыта, ведь если игрок не понимает, как выполнять простейшие задачи, он вполне может бросить игру. В лучшем случае недостатки юзабилити будут вызывать раздражение и помешают игрокам получать удовольствие от тех или иных аспектов игры. В худшем – сделает даже очень интересную игру совершенно неиграбельной.
При наличии достаточного количества инноваций иногда можно закрыть глаза даже на серьезные проблемы с юзабилити. Если игра «выстрелила», игроки, вероятно, согласятся потерпеть некоторое неудобство. Повторюсь: вероятно. Я бы на это полагаться на стала. Например, Minecraft можно было простить ряд недостатков юзабилити, поскольку она давала уникальный креативный опыт, который не могла дать ни одна другая игра того времени. А вот у ее последовательниц, лишенных статуса первопроходца, такой роскоши не будет.
Юзабилити еще более критично для free-to-play игр, поскольку любое неудобство снижает и без того низкую начальную вовлеченность игроков, ведь те ничего не заплатили. Они не станут ждать и сразу удалят приложение. Также, если игроки не понимают, например, зачем и как покупать предметы во внутриигровом магазине, вы можете лишиться потенциальной прибыли. И напомню: речь не идет о трудностях, заложенных в геймплей намеренно. Я говорю только о непредвиденных проблемах вроде того, что игрок не понимает функции тех или иных иконок на экране, не знает, как дать персонажу оружие, или погибает, не понимая почему.
11.1. Эвристики юзабилити в разработке ПО и видеоигр
Удобный интерфейс, по словам UX-истов, – это интерфейс, которого пользователь «не замечает». Поэтому некоторые разработчики ошибочно считают, что для большего погружения следует убрать с экрана вообще все лишнее. Однако это может возыметь обратный эффект, поскольку весь смысл экранного интерфейса в том, чтобы игрокам не нужно было запоминать или постоянно искать важную информацию. Безусловно, следует избегать перегруженности и громоздкости (например, сделав интерфейс контекстуальным), но если убрать его совсем, то это приведет к росту неудобства и когнитивной нагрузки, что пагубно скажется на погружении, поскольку игрокам придется постоянно открывать меню для поиска нужной информации, отвлекаясь от игрового мира. Конечно, если вы можете наглядно и доступно предоставить им всю необходимую информацию непосредственно через игровое окружение, тем лучше!
Такой подход называется «диегетическим», и он зачастую дает наиболее иммерсивный[35] и элегантный результат. Однако реализовать диегетический интерфейс правильно очень непросто, ведь нужно сделать так, чтобы он вписывался в игровой мир, но при этом был читаемым и понятным. В пример чаще всего приводят элегантное решение для полоски здоровья в экшене от третьего лица Dead Space (Visceral Games). От большинства подобных игр она отличается тем, что здоровье отображается не в углу экрана и не над головой персонажа. Вместо этого индикатор встроен в саму модель персонажа (рис. 11.1). Игровое окружение довольно темное, и полоска здоровья хорошо выделяется на фоне из-за своей яркости. Дополнительное удобство также в том, что эта полоска расположена не на периферии взгляда, а недалеко от прицела, поскольку в экшен-игре очень важно смотреть в центр экрана.
Рис. 11.1. Dead Space (Visceral Games). © 2008 Electronic Arts. Публикуется с разрешения Electronic Arts
Еще один часто приводимый пример диегетического интерфейса – счетчик патронов, отображаемый прямо на модели оружия. Так делают во многих шутерах от первого лица, однако скорее в дополнение к счетчику патронов на экранном интерфейсе. Последний, во-первых, не двигается (в отличие от модели оружия), а во-вторых, может сообщать дополнительную важную информацию (количество оставшихся обойм, например).
Таким образом, сделать интерфейс «незаметным» вовсе не означает убрать его. Наоборот, речь о том, чтобы выдавать игроку нужные сведения – через меню, элементы интерфейса, игровое окружение, вообще что угодно – по мере необходимости, не перегружая и не запутывая его. Представьте, что вы берете напрокат машину незнакомой модели. Вы хотите на ней ездить (опыт), и вам нужно, чтобы приборная панель была наглядной, а элементы управления (замок зажигания, переключатель дворников и т. п.) были на своих местах. Интерфейс автомобиля будет «незаметным» только в том случае, если вам не придется мучиться с поиском и чтением нужной информации (скорость, уровень бензина и т. п.) или с управлением. Сам интерфейс никуда не девается; он просто не мешает взаимодействию. В этом-то и состоит суть «незаметности»: вы выполняете нужные вам действия, не задумываясь, как это сделать. А вот когда интерфейс путаный и неудобный, он сразу бросается в глаза. Вот почему, если вы хотите, чтобы игрок не испытывал лишних неудобств (т. е. трудностей) и ничто не мешало ему получать тот опыт, который вы хотите дать, необходимо позаботиться о юзабилити.
Естественно, пользователи часто не в состоянии распознать проблемы юзабилити. Они просто чувствуют дискомфорт от взаимодействия с системой, хоть и не могут точно назвать причину (или неверно ее определяют). Игроки не дизайнеры, они не обязаны описывать, в чем суть проблемы – например, когда жалуются на форумах. Более надежный способ выявить источник дискомфорта – проанализировать поведение игроков во время плейтестов, когда игровой процесс проходит в обстановке, приближенной к реальной, без непосредственного участия специалистов.
UX-тесты, оценка юзабилити специалистами по ЧМИ и пользовательские исследования в целом всегда будут играть ключевую роль в улучшении пользовательского опыта вашей игры (см. главу 14), потому что в конечном счете опыт складывается у конкретного пользователя. Поэтому вам нужно знать, что ощущают игроки, и анализировать возможные причины недовольства. Разработка итеративна по своей природе, поэтому от цикла «дизайн – реализация – тестирование» никуда не деться. Однако если начать разработку интерфейса и взаимодействий сразу с учетом принципов юзабилити, то это даст вам серьезную фору.
Юзабилити, как и эргономика, – это краеугольный камень взаимодействия между человеком и машиной. В 1990-х были описаны основополагающие принципы, помогающие оценить, что важно для удобства пользования онлайн-интерфейсами или программами. Эти принципы получили название «эвристик», или практических правил для оценки юзабилити продукта или программы. Они позволяют сэкономить время, избежать частотных проблем, предвосхитить и более эффективно исправить недостатки, поскольку благодаря эвристикам проще определить причину и понять комментарии UX-аналитиков по вашей игре. Хотя эвристики юзабилити отличаются от стандартов дизайна, так как используются именно для экспертной оценки, помнить о них все равно полезно. Они помогают понять, какие проблемы юзабилити встречаются в играх чаще всего.
Наиболее популярными эвристиками в разработке ПО и веб-дизайне были собраны экспертом по ЧМИ и консультантом по юзабилити Якобом Нильсеном [1994]. Изначально в 1990 году он вместе с Рольфом Моликом [Nielsen, Molich, 1990] разработал набор из десяти эвристик для интерактивного дизайна. Их можно изучить на сайте Nielsen Norman Group (https://www.nngroup.com/). Вот они вкратце.
1. Видимость состояния системы: система должна сообщать (посредством знаков) пользователям информацию о доступных действиях, а также немедленно давать обратную связь о принятых командах (если не было ошибок). Например, зайдя в лифт, вы видите перед собой кнопки с номерами этажей, куда можно поехать. Хорошей практикой с точки зрения юзабилити будет, если кнопка после нажатия сразу же загорится (обратная связь). Отсутствие обратной связи вызывает смятение и раздражение. Если сигнала нет, человек будет продолжать долбить по кнопке, не понимая, работает она или нет. Точно так же, после выбора пункта «начать игру» в главном меню игрок будет ожидать уведомления о загрузке.
2. Совпадение между системой и реальным миром: система должна оперировать языком и понятиями, знакомыми целевой аудитории, используя метафоры и аналогии с реальным миром. Например, пользователям легко понять, для чего нужны «папки» на компьютере, поскольку точно так же хранятся документы в жизни. В играх метафорой инвентаря может выступать, например, рюкзак.
3. Контроль и свобода пользователя: пользователь может ошибиться или передумать, например, совершая покупки онлайн. Возможность отменить заказ, изменить количество товаров в корзине или удалить ненужные позиции – все это примеры контроля и свободы. Точно так же разрешайте игрокам отменять действия и менять выбор, если это возможно.
4. Единство и стандартизация: соблюдать устоявшиеся стандарты платформы важно, поскольку знакомые слова, иконки и действия помогают пользователям понять, как работает система. Например, функция поиска традиционно обозначается увеличительным стеклом – условность, которая наверняка понятна большинству пользователей. Или, скажем, в западных странах кнопка О (круг) на контроллерах PlayStation 4 обычно используется для отмены или перехода в предыдущий пункт меню.
5. Предупреждение ошибок: система должна быть разработана таким образом, чтобы не допускать ошибок пользователей. Например, перед тем как выполнить потенциально опасное действие вроде закрытия файла без сохранения, система должна запросить подтверждение. Если игрок собирается утилизировать квестовый предмет (например, чтобы извлечь из него ингредиенты для крафта[36]), необходимо вывести предупреждение на случай, если действие выбрано по ошибке.
6. Узнавание, а не вспоминание: чтобы минимизировать нагрузку на память пользователя, важно делать видимыми все объекты, действия и варианты. Старайтесь не заставлять пользователя вспоминать в одном диалоге то, что он услышал в другом. Точно так же при переключении между меню у пользователя всегда должна быть возможность отследить свое местоположение на сайте или в приложении (так называемые «хлебные крошки»). А если вместо просто символа показывать картинку всего контроллера, выделяя кнопку, на которую нужно нажать в данном случае, то игроку не придется вспоминать, где какая кнопка находится.
7. Гибкость и удобство использования: давайте пользователям возможность настроить интерфейс под себя, добавляя или убирая те или иные функции. Например, в поисковых движках опытные пользователи могут включать фильтры. В играх возможность переназначать управление положительно сказывается на юзабилити и доступности.
8. Эстетика и минимализм: убирайте все отвлекающее и несущественное. Каждая лишняя единица информации добавляет шум, который пользователю необходимо отфильтровать, прежде чем выделить главное и на нем сосредоточиться. Стартовая страница поиска Google – прекрасный пример минималистичного дизайна. То же касается игр: постарайтесь убрать с экранного интерфейса и из меню, особенно главного, всю несущественную информацию.
9. Помощь в распознании, диагностике и исправлении ошибок: в сообщениях об ошибках должны быть доступно и четко описаны проблема и варианты решения. Например, вместо того чтобы сообщать пользователю, что при открытии нужной им страницы произошла «ошибка 404», лучше выдать нечто более осмысленное для большинства, скажем, «Простите, страницы, которую вы запрашиваете, не существует», – а затем предложить, что делать дальше. Если у игрока кончились патроны, не просто проигрывайте раздражающий звук, когда он пытается стрелять; добавляйте всплывающую подсказку вроде «Перезарядитесь».
10. Помощь и документация: хотя пользоваться системой должно быть возможно и без документации, важно, чтобы в случае необходимости можно было обратиться к удобной и понятной помощи, скажем, контекстуальной, которую часто обозначают знаком вопроса в кружочке. Держать под рукой мануал не должно быть обязательным для игры; хорошим тоном будет собирать все встреченные советы и подсказки в одном месте, чтобы игрок всегда мог их просмотреть, если что-то забыл.
Идея использовать эвристики для оценки игр была предложена еще в 1980 году [Malone, 1980], однако подлинного расцвета видеоигровые эвристики достигли только в нулевых [см., напр., Federoff, 2002; Desurvire и др., 2004; Schaffer, 2007; Laitinen, 2008]. Ниже несколько примеров игровых эвристик.
• Управление должно быть настраиваемым и соответствовать стандартам, принятым в индустрии [Federoff, 2002].
• Обратная связь должна быть мгновенной, чтобы игрок чувствовал контроль над происходящим на экране [Federoff, 2002].
• Игровой процесс должен быть спланирован таким образом, чтобы игрок с самого начала чувствовал вызов, но при этом не бессилие [Federoff, 2002].
• Цели должны быть четкими; глобальную цель следует давать как можно раньше, дополняя ее по мере игры промежуточными [(Desurvire и др., 2004].
• Игра должна давать награды, которые способствуют более глубокому погружению игрока, усиливая его способности и расширяя возможности [Desurvire и др., 2004].
• По ходу игры игрок должен узнавать историю [Desurvire и др., 2004].
• Больших текстовых блоков следует избегать [Schaffer 2007].
• Игрок должен чувствовать контроль; ему нужны время и информация, чтобы реагировать на угрозы и происходящие события [Schaffer, 2007].
• Нельзя делать так, чтобы игрок мог легко застрять или запутаться [Schaffer, 2007].
• И внутри игры, и между играми должно соблюдаться единообразие пользовательского интерфейса [Laitinen, 2008].
• Термины и язык в игре должны быть простыми для понимания [Laitinen, 2008].
• Дизайн пользовательского интерфейса должен исключать возможность совершать ошибки, не заложенные в геймплей [Laitinen, 2008].
Тем из вас, кто занимается или планирует заниматься UX, я настоятельно рекомендую изучить игровые эвристики, если вы о них еще не знаете. Однако они не помогут вам найти общий язык с разработчиками, и их нельзя использовать как простой чек-лист. Они скорее нужны UX-аналитикам, чтобы им было удобнее оценивать юзабилити игры. Поэтому в следующем разделе я приведу сокращенный набор «принципов юзабилити», описывающий эвристики в сочетании с принципами дизайна более привычным для разработчиков языком.
11.2. Семь принципов юзабилити в игровом UX
В этом разделе я опишу набор эвристик юзабилити и принципов дизайна, которые, по моему опыту, помогают обеспечить игре высокий уровень юзабилити. Во многом я опиралась на тренинги, где разработчики из Ubisoft рассказывали о некоторых составляющих юзабилити, что вдохновило меня на собственные размышления. Мой список, конечно, далеко не исчерпывающий, но даст вам достаточно информации, на что нужно обращать внимание. Отмечу только, что некоторые компоненты, традиционно ассоциируемые с юзабилити, например эмоции от взаимодействия с системой, будут рассмотрены в следующей главе, посвященной вовлекательности. И напомню: список этот в основном нужен для того, чтобы выработать общий язык внутри студии и наладить процесс, в котором каждый разработчик может внести свой вклад в улучшение игрового UX, если захочет.
11.2.1. Знаки и обратная связь
Этот принцип похож на эвристику «видимость состояния системы» Якоба Нильсена [1994], только никто из игровых разработчиков, с кем я работала, таким термином не пользовался. Вместо этого принято говорить о «подсказках», «знаках» и «обратной связи». Знаки в видеоиграх касаются всех визуальных, звуковых и тактильных подсказок, сообщающих игроку о том, что происходит (т. н. информирующие знаки), или подталкивающих его к какому-либо действию (т. н. побуждающие знаки). Все они передают игроку некую конкретную информацию, которую тот расшифровывает. В семиотике у знака есть форма (обозначающее) и смысл (обозначаемое), однако в геймдеве мы говорим о знаках (подсказках), чья форма связана с какой-либо функцией (см. далее принцип «функция определяет форму»). Обратная связь – это особый тип знаков, представляющий собой воспринимаемую игроком реакцию системы на его действия.
• Информирующие знаки
Эти знаки информируют игрока о состоянии системы: например, здоровье персонажа отражается зеленой полоской или красными сердечками на экране (или прямо на модели персонажа, если интерфейс диегетический).
Весь экранный интерфейс состоит из знаков, информирующих игрока, скажем, о запасе выносливости и патронов, экипированном оружии, текущем счете, местоположении на карте, доступных способностях, их перезарядке и так далее.
Информирующие знаки должны быть легко читаемыми, но ненавязчивыми, чтобы не отвлекать внимание игрока от происходящего на экране. Именно поэтому такие знаки расположены по краям экрана, на периферии зрения.
Внутриигровые меню тоже состоят из множества информирующих знаков. В основном это текстовые описания персонажей, предметов, навыков и тому подобного, что помогает игрокам разбираться в тонкостях игры и принимать решения (например, какой навык прокачивать следующим: А или Б?).
• Побуждающие знаки
Эти знаки призывают игроков совершать определенные действия. Например, желтый восклицательный знак над моделькой неигрового персонажа (он же NPC) побуждает игрока подойти и поговорить с ним. Эти знаки нужны для того, чтобы формировать и направлять поведение игрока. В большинстве случаев они должны привлекать внимание и, соответственно, должны выделяться на фоне игрового окружения. Исключением могут служить побуждающие знаки, которые намеренно незаметны, как в игре The Legend of Zelda: A Link to the Past (Nintendo), где стены, которые можно разбить, обозначены едва различимыми трещинами.
Информирующие знаки могут становиться побуждающими, когда состояние, которое они обозначают, требует немедленного вмешательства. Например, если у игрока осталось мало здоровья, полоска здоровья может стать красной и замигать, тем самым побуждая игрока подлечиться (применить аптечку либо спрятаться за укрытием, если здоровье восстанавливается автоматически).
• Обратная связь
Обратная связь – это особый вид знаков, сообщающий игроку о реакции системы на его действия. Анимация персонажа в ответ на наклон стика[37] – это пример обратной связи, точно так же как, скажем, число патронов на экране или модели оружия, уменьшающееся при стрельбе.
Все действия игрока должны иметь немедленную и подходящую обратную связь, сообщающую об исходе указанных действий. Например, в файтингах серии Tekken (Bandai Namco) обратной связью при нанесении удара по противнику становится визуальный эффект, который сообщает об эффективности удара: если вспышка ярко-оранжевая, то враг получил урон (см. рис. 11.2), а если белая, то удар был блокирован.
Рис. 11.2. TEKKEN™ 7 & ©2017 BANDAI NAMCO Entertainment Inc. Публикуется с разрешения BANDAI NAMCO Entertainment, Inc., Токио, Япония
Также важно давать обратную связь, если игрок пытается выполнить несуществующее действие, – например, нажимает на клавишу, которая ничего не делает. В этом случае стоит дать едва заметную обратную связь, допустим, короткий звуковой эффект, сообщающий, что действие невозможно, чтобы игрок больше на эту кнопку не нажимал. Или, скажем, игрок пытается воспользоваться способностью, которая в данный момент перезаряжается. В этом случае обратная связь должна быть более заметной и сообщать игроку, почему выполнить действие сейчас невозможно (например, иконка способности может вспыхнуть и/или под прицелом может возникнуть подсказка с текстом типа «Способность еще не готова!»).
Все механики и возможные взаимодействия в игре должны иметь собственные знаки и обратную связь. Поэтому очень важно продумать их сразу же, как только будет прописан геймплей, механики, поведение оружия, персонажей и так далее. Имея список всех необходимых знаков и обратной связи, дизайнеры интерфейса, художники и саунд-дизайнеры смогут как можно раньше подготовить соответствующие ассеты[38]. А UX-аналитики впоследствии смогут определить, все ли игроки расшифровывают (понимают) эти знаки правильно.
Если со знаками и обратной связью у игры все хорошо, это сильно облегчает игрокам понимание правил игры через собственное восприятие и взаимодействие с игровым окружением и интерфейсом. Если побуждающий знак функционирует как надо (например, призывает игроков взаимодействовать с объектом), вам не нужно добавлять текст, объясняющий игроку, что делать дальше, – так можно сэкономить на туториалах. И наоборот, если знаки и обратная связь отсутствуют или недостаточно ясны (см. следующий принцип), это вызывает раздражение и путаницу. Наличие знаков и обратной связи – залог высокого уровня юзабилити игры.
11.2.2. Ясность
Ясность помогает игроку воспринять и понять все знаки и обратную связь в игре. Если знак, побуждающий игроков взаимодействовать с неким объектом, недостаточно выделяется на фоне окружения, игроки, скорее всего, не обратят внимания на этот знак. Поэтому все знаки и обратная связь должны обладать хорошей читаемостью (сюда входят контраст, шрифт, информационная иерархия и т. п.).
Например, используемые шрифты должны быть удобны для чтения. Лучше взять «банальный» классический, зато понятный шрифт, чем креативный и модный, но неразборчивый. Конечно, если вы можете сделать уникальный шрифт, который к тому же легко читается, то дерзайте! Однако проверить это не так-то просто, поскольку в вашей выборке может не оказаться представителей, например игроков-дислексиков, или же трудность чтения не поддается измерению (так, шрифт может быть вполне читаемым, но требовать чуть больше времени на понимание, чем обыкновенный).
Рекомендации по шрифтам есть, и найти их нетрудно. Например, следует отдавать предпочтение шрифтам без засечек, использовать не более трех разных шрифтов и цветов, не писать длинные тексты только прописными символами (короткие заголовки можно), соблюдать контраст между текстом и фоном (помещать текст на контрастной подложке), выбирать читаемый размер символов и так далее. Читаемость особенно важна в случаях, когда игроку нужно принимать значимые решения: выбор класса, способностей, навыков, снаряжения и тому подобное.
Рис. 11.3. Diablo III (Blizzard). Diablo® III. Публикуется с разрешения Blizzard Entertainment, Inc.
Дизайнеры порой склонны давать предметам слишком развернутые описания. Несмотря на то что глубокий нарратив добавляет эмоций (см. главу 12), гораздо важнее помочь игрокам принимать решения, особенно стратегические (в отличие от просто косметических). Перечисляйте основные особенности и преимущества классов, видов оружия и способностей через маркированные списки. Избегайте длинных предложений – их все равно мало кто прочтет. Организуйте информацию так, чтобы было легко сравнить два (или более) предмета (см. пример из Diablo III от Blizzard на рис. 11.3). Пользуйтесь инфографикой, чтобы важная информация сразу бросалась в глаза: например, преимущества и недостатки оружия можно отображать с помощью полосок. В примере из Far Cry 4 на рис. 11.4 сразу видно, что выбранное оружие наносит большой урон и не замедляет игрока, однако имеет низкую точность, скорострельность и дальность стрельбы.
Рис. 11.4. Far Cry 4 (Ubisoft). Публикуется с разрешения Ubisoft Entertainment, © 2014. Все права защищены
Принципы гештальтпсихологии, рассмотренные в главе 3, также помогают сделать игровой интерфейс более ясным. Если помните, они описывают, как сознание человека воспринимает и организует пространство. Так, согласно принципу близости, элементы, расположенные рядом друг с другом, будут казаться частями одной группы.
Пользуясь принципами гештальтпсихологии, дизайнеры могут сделать игровой интерфейс более понятным для игроков. Например, в главе 3 мы видели, как реорганизация пространства между иконками навыков в Far Cry 4 помогает лучше воспринимать и истолковывать информацию. Следите за тем, чтобы иконки, используемые в игре, не вводили в заблуждение (т. е. избегайте мультиустойчивости), – если, конечно, трудность восприятия не является частью игрового процесса.
И последнее ключевое понятие в отношении ясности – это теория обнаружения сигнала, классика эргономики. Ее суть в том, что человек взвешивает и принимает решения в условиях неопределенности. Ему приходится выделять нужную информацию среди шума, например, ища ключи в бардаке на столе или парня в полосатой фуфайке в книге-игре Мартина Хэндфорда «Где Волли?».
Давайте для примера возьмем обнаружение врагов в шутере. Если дизайн противников недостаточно контрастирует с игровым окружением, то обнаружить их будет трудно (если так и задумано, то хорошо). Восприятие игрока можно обманывать, варьируя уровень неопределенности, если это оправданно с точки зрения геймплея [см. McLaughlin, 2016]. Например, можно добавлять в окружение элементы, похожие на врагов по цвету и очертаниям, создавая «ложную тревогу», чтобы игрок ошибочно стрелял по безобидным объектам.
Однако, если нужно привлечь внимание игроков к определенному знаку, он должен быть легко различим на фоне окружения. Рассмотрим для примера так называемую перегрузку красным. Красный – цвет крови и традиционное условное обозначение сигналов, предупреждающих об опасности. Часто в играх им отмечают угрозы или нанесенный урон. Также этот цвет чаще всего контрастирует с фоном. Однако если в игре и без того много элементов красного цвета, то очередной такой знак будет обнаружить не так просто, потому что он перестанет выделяться на общем фоне (т. е. красный «шум» забьет восприятие игрока, и он не сможет распознать важный сигнал).
В шутере от первого лица Unreal Tournament 3 (Epic Games), если вы играете за команду красных, почти весь интерфейс у вас красный: очки, здоровье, патроны и так далее. Когда вы получаете урон, контур экрана также окрашивается в красный. Весь этот «шум» мешает игрокам сосредоточиться на красной стрелке рядом с прицелом, указывающей, откуда стреляют, что является самой важной информацией, если игрок хочет как можно быстрее среагировать и убить врага, пока не убили его самого (рис. 11.5).
Рис. 11.5. Unreal Tournament 3 © 2007, Epic Games, Inc. Публикуется с разрешения Epic Games, Inc., Кэри, Северная Каролина, США
Эти мои наблюдения довольно тяжело проверить в лабораторных условиях, однако я подозреваю, что «перегрузка красным» вредна, в первую очередь для новичков. Я также подозреваю, что игроки из команды красных на доли секунды медленнее различают противников из команды синих, особенно если в прошлом матче они играли за синих и привыкли стрелять по всему красному, что движется. Для соревновательных режимов это существенно, потому что даже миллисекундная разница во времени реакции может предрешить исход стычки.
Такая ситуация чем-то напоминает эффект Струпа, описанный в главе 5 (когда нужно назвать цвет, которым написано название цвета, и если цвет слова не совпадает со словом, то на выполнение задачи уходит больше времени). Сначала нужно подавить выученный рефлекс стрельбы по красным элементам и привыкнуть считать красных персонажей своими. Именно поэтому я часто рекомендую оставлять красный только для самых важных знаков (когда есть непосредственная угроза, нанесен урон или осталось мало здоровья). Для врагов (их окантовки или полоски здоровья) можно использовать, например, оранжевый.
Не забывайте, что восприятие субъективно (см. главу 3). Именно поэтому нужно проследить, чтобы связь между знаками, обратной связью и геймплеем была четко видна. Также помните, что ресурсы внимания крайне ограничены (см. главу 5), соответственно, стоит подсказывать игрокам, на чем нужно сосредоточиться. Наконец, следует распределять информацию по значимости, чтобы не перегружать оперативную память игрока (см. главу 4).
Например, если во время битвы в многопользовательской игре отображать все знаки и обратную связь от каждого игрока, очень скоро можно запутаться. Поэтому необходимо определиться, какие звуковые и визуальные эффекты должны иметь приоритет (прежде всего те, которые сообщают игроку, что он ранен), а какие можно отключить, когда одновременно происходит слишком много. Точно так же стоит определиться, какие анимации, звуки или диалоги можно обрывать (например, анимация перезарядки стопорится, если игрок начинает движение, а второстепенные реплики обрываются, когда рядом с игроком вдруг взрывается граната), а какие нет.
В реальной жизни звуковое разграничение (ассоциация звуков с источником) гораздо труднее визуального [McDermott, 2009], а в играх и того труднее, особенно при режиме стерео. Конечно, если установить себе систему Dolby® Surround 7.1, трудностей будет меньше (как известно, все звучит лучше, когда «долбит»). Соответственно, расстановка акцентов для звуковых эффектов помогает игрокам разобраться, что творится в игре, поэтому будьте вежливы с саунд-дизайнерами и всегда держите их в курсе своих задумок. Я подчеркиваю этот пункт потому, что очень часто вижу, как саунд-дизайнеров привлекают только на поздних этапах разработки, и те вынуждены подстраиваться на ходу.
В своем эссе ниже звукорежиссер Том Байбл приводит примеры того, как саунд-дизайн помогает улучшить пользовательский опыт.
Том Байбл, звукорежиссер, саунд-дизайнер и композитор на фрилансе
Саунд-дизайн и UX
Джордж Лукас как-то сказал: «Звук – это половина впечатления». Действительно, звук – важный компонент пользовательского опыта, поскольку за его восприятие отвечает отдельный сенсорный канал. Слух срабатывает гораздо быстрее других чувств, что открывает прямой путь к подсознанию пользователя. Музыка, как известно, обладает сильным эмоциональным воздействием, и саунд-дизайн ей в этом не уступает.
Чтобы саунд-дизайн работал на улучшение пользовательского опыта, необходимо соблюсти ряд условий. Во-первых, он должен давать четкую обратную связь по действиям игрока. Благодаря различным звукам игрок сможет автоматически понять, было ли его действие успешным или неуспешным. Наглядный пример – это подбор предмета в виртуальной реальности. В Robo Recall (Epic Games), когда игрок может взять предмет, белое кольцо расширяется и одновременно проигрывается звук. Данное ключевое действие часто происходит за пределами поля зрения игрока. В этом случае звучит щелчок, а за ним идет звук, сопровождающий расширение белого кольца. Игрок постепенно учится соотносить этот звук с пониманием, что рядом есть объект, который можно взять. Через несколько минут повторения данная ассоциация становится подсознательной, и визуальный контакт с объектом больше не требуется.
Во-вторых, звуковое сопровождение должно соответствовать ожиданиям игрока. Например, в виртуальной реальности мы пытаемся добиться эффекта погружения, чтобы игрок чувствовал себя в ином пространстве. Для этого необходимо имитировать поведение звука в реальном мире, иначе может возникнуть эффект «зловещей долины»: игрок чувствует, что что-то не так, но не понимает, что именно. Имитируя же акустическую физику, мы помогаем игроку испытать погружение без когнитивного диссонанса.
В-третьих, необходимо делать так, чтобы звуки были узнаваемыми. Опытные игроки привыкли ждать от тех или иных объектов вполне определенных звуков. Поэтому, например, в озвучке неговорящих роботов стараются соблюдать человеческие интонационные рисунки для передачи настроения и намерений персонажа. Особенно хорошо это видно на примере R2-D2: мы на эмоциональном уровне «понимаем», что он «говорит». Однако важно помнить о культурных различиях. Интонации, скажем, в Штатах сильно отличаются от интонационных рисунков в Китае или Японии.
Помимо прочего, мы должны считаться с тем, что другие медиа, например кино, формируют определенные ожидания о звуках, не совпадающие с реальной жизнью. Возьмем, к примеру, оружие: в фильмах и играх звуки выстрелов сильно отредактированы, чтобы передавать ощущение мощи, тогда как на самом деле напоминают скорее просто «хлопок».
Самый, наверное, важный аспект пользовательского опыта с точки зрения аудио, хотя ему уделяется меньше всего внимания, – это сведение звука. Без хорошего сведения саунд-дизайн может совсем затеряться. Это особенно трудно в виртуальной реальности, где впечатление должно быть естественным и соответствовать законам акустики. Необходимо внимательно проследить, чтобы у разных компонентов микса были правильно проставлены приоритеты (по громкости). Таким способом можно выделить наиболее важные в данный момент звуки, не привлекая внимания к постоянным перепадам. Хороший пример – это сведение звука в Robo Recall: когда должны играть звуки одной категории, все другие немного «приглушаются». Чтобы привнести порядок в хаос, звуки разделены на категории важности, от низкой к очень высокой. Например, звуки «высокой важности» немного приглушают звуки «средней важности» и сильно – звуки «низкой важности», а звуки «очень высокой важности» остаются без изменений.
Добиться хорошего результата можно только методом проб и ошибок, изучая отклики игроков и других специалистов по звуку. Отклики могут быть очень субъективны, поэтому от участников плейтестов необходимо добиваться, понимают ли они значение тех или иных звуков. Итеративный подход крайне важен для интерактивного звукового сопровождения, поскольку игроки будут реагировать, исходя из того, как они его интерпретируют, а не так, как задумал дизайнер.
11.2.3. Функция определяет форму
Изначально пришедший из модернистской архитектуры, в гейм-дизайне этот принцип означает, что внешний вид (форма) какого-либо персонажа, предмета или символа в игре должен отвечать их назначению (функции). В промышленном дизайне используется схожий термин, уже упоминавшийся в главе 3, – «аффорданс», под которым понимают «связь между свойствами объекта и возможностями действующего лица, определяющая варианты использования данного объекта» [Norman, 2013]. Например, если у объекта (допустим, у кофейной чашки) есть ручка, то его можно взять одной рукой и поднять. Точно так же по визуальному облику игрового элемента игрок должен интуитивно догадываться, как с ним взаимодействовать. Например, предмет в виде ящика с зеленым крестиком (форма) сообщает игроку, что с его помощью можно восстановить здоровье (функция). Также можно предположить, что противника со щитом (форма) победить труднее (функция), чем такого же противника, но без щита. Подробнее типы аффордансов будут описаны в главе 13.
Для художников это означает, что их ассеты должны быть понятны игрокам и что в качестве эстетического ориентира выступает принцип «функция определяет форму». Ключевой вопрос: «Какие аспекты дизайна важны для успеха?» [см. Lidwell и др., 2010]. Успех в данном случае означает, что игрок по форме понимает, в чем смысл тех или иных элементов и как ими пользоваться (или как предугадать их поведение).
Этот принцип можно нарушать – естественно, при наличии оснований. Однако чем больше вы его соблюдаете, тем более интуитивно ваши игроки смогут ориентироваться в игре. Как упоминалось выше в разделе о знаках и обратной связи, если знак благодаря форме недвусмысленно указывает на возможность выполнения определенных действий, то это повод избавиться от лишних туториалов, которые, помимо прочего, нужно переводить на разные языки.
Описываемый принцип в ряде случаев полезен и для геймплея, например в многопользовательской игре, где игрокам важно быстро и точно узнавать роли сокомандников и противников исходя из их формы. Так, в Team Fortress 2 (Valve) персонажи легко различимы уже на уровне силуэта, отчего игрокам проще координировать свои действия, поскольку они знают, какую роль (функцию) выполняют персонажи поблизости (рис. 11.6).
Рис. 11.6. Силуэты персонажей Team Fortress 2 © 2007–2017 Valve Corporation. Публикуется с разрешения Valve Corporation, Белвью, Вашингтон, США
Применение этого принципа на практике требует соблюдения двух условий: форма элемента должна восприниматься четко и недвусмысленно (см. предыдущий раздел), а также должна точно передавать функцию. Если иконка, якобы изображающая сектор радара, воспринимается как кусок пиццы, значит, ее нужно переделать. С другой стороны, если форма воспринимается однозначно, но игрок неверно истолковывает функцию, значит, метафора или аналогия не работает. Допустим, вы сделали иконку в виде лупы (форма) для масштабирования изображения (функция). Игроки наверняка верно воспримут форму (т. е. увидят лупу), но могут ошибочно посчитать, что иконка связана с функцией поиска.
Чтобы легко и быстро протестировать форму и функцию основных иконок (персонажей, предметов и т. д.), сделайте опросник, где на каждой странице будет одна случайно выбранная иконка, и отдайте его представителям целевой аудитории. Пусть они сначала ответят, что видят на этой иконке (т. е. опишут ее форму), а затем – что, на их взгляд, она означает (т. е. опишут ее функцию). Это поможет вам оценить, все ли элементы воспринимаются игроками верно и все ли функции корректно распознаются.
Безусловно, не все функции можно однозначно изобразить в виде маленькой иконки, особенно когда речь касается разнообразных и специфических способностей в ролевых играх. Ничего страшного, если игрокам нужно разбираться, что значит та или иная иконка; главное, чтобы она не сбивала с толку. Например, если большая часть аудитории связывает иконку с функцией, которая радикально отличается от задуманной, откажитесь от этой иконки и придумайте другую. Куда сильнее игроков раздражает, когда их ожидания не оправдываются, чем когда смысл иконки не вполне ясен. Если функция явно не следует из формы, игрок начинает экспериментировать, чтобы разобраться, что делает тот или иной элемент – и это лучше, чем обмануться.
Принцип «функция определяет форму», конечно же, важен не только для иконок, но и для дизайна персонажей, объектов и окружения. По возможности максимально старайтесь передавать функцию через форму: то, что интуитивно понятно, не нуждается в изучении и тем самым позволяет снизить когнитивную нагрузку (см. далее). В крайнем случае постарайтесь хотя бы не обманывать ожидания игроков – если, конечно, это не является частью вашей задумки.
Ложные аффордансы, когда функция элемента воспринимается ошибочно, вызывают сильное раздражение. Например, если зона игрового мира кажется доступной для исследования, игроку будет обидно узнать, что при попытке туда пройти персонаж упирается в невидимую стену. Или еще пример: объект игрового мира (приставная лестница) указывает на возможность подъема, но взаимодействовать с этим объектом игрок не может.
Помните, что ваше восприятие субъективно и необязательно совпадает с восприятием аудитории, так что все важные визуальные образы, а также большинство важных звуков необходимо тестировать, чтобы убедиться, что они воспринимаются как задумано. Помните также, что на вас действует проклятие знания: то, что вам кажется очевидным, поскольку вы знаете свою игру до мелочей, не всегда будет таковым для новых игроков.
11.2.4. Единообразие
Все знаки, обратная связь, управление, интерфейс, навигация в меню, правила мира и видеоигровые условности должны быть единообразными. Например, если в игре можно открывать двери, то должна открываться каждая дверь, а если открывать можно только определенные двери, то они должны быть как-то выделены, чтобы игрок не путался в том, как работает система. Если у двух элементов схожая форма, то игрок ожидает от них схожей функции. И наоборот, если форма у двух элементов разная, то и функционировать они, скорее всего, будут по-разному.
Если система последовательна, то, усвоив правило, игроки должны иметь возможность применить его к подобным объектам с предсказуемым результатом. Допустим, если игрок понял, что патроны (например, у пистолета) кончаются и их нужно собирать, то он будет ожидать, что и другое оружие со снарядами (например, лук) поведет себя так же. При этом, если стрелы не исчезают и не ломаются, игрок может предположить, что их разрешено подбирать снова с убитых противников. Соответственно, если вы хотите ввести новый тип дистанционного оружия с бесконечным зарядом, то нужно выбрать что-то совершенно непохожее (например, бумеранг).
Разные функции должны быть выражены через разную форму, иначе игроки могут перепутать знаки и, как следствие, функции, что приводит к ошибкам. Допустим, в вашей игре предусмотрена смена дня и ночи и есть часы с цифрами, показывающие текущее время. Если появится счетчик с похожими цифрами, показывающий остаток времени на выполнение миссии, возникнет путаница. Чтобы ее избежать, схожие функции должны иметь схожую форму, а разные функции – разную.
Единообразие в управлении тоже очень важно – особенно потому, что заучивание движений рук и пальцев сильно завязано на имплицитной памяти (которую в этой связи часто называют «мышечной»). Да, в начале игроки должны ознакомиться с привязкой клавиш (типа «Нажмите Х для прыжка» на контроллере PS4), но по мере прохождения и многократного повторения одних и тех же движений пальцы начинают автоматически, без участия сознания, нажимать на нужные клавиши. Как было показано в главе 4, процедурная информация автоматизируется через практику, и поэтому ее труднее забыть (как говорится, если научился ездить на велосипеде, то не разучишься – или разучишься, но через очень долгое время). Это значит, что не стоит менять раскладку в похожих по функционалу ситуациях. Например, функцию бега и галопа (при езде верхом) лучше привязать к одной и той же клавише, а не к разным. Точно так же взаимодействие с интерфейсом должно быть организовано одинаково на протяжении всей игры, как в игровых меню, так и на экране инвентаря.
Единообразие можно нарушать, если для этого есть убедительные основания. Например, в Uncharted 3 (Naughty Dog), когда игрок находится на тонущем, кренящемся судне, управление «кренится» вместе с ним. То есть чтобы идти прямо относительно камеры, нужно отклонять стик влево. Нарушение единства между камерой и управлением в этой сцене сделано намеренно, чтобы создать дополнительную (и неожиданную) сложность.
Единообразие между играми также важно, поскольку учить игроков, уже знакомых с определенными условностями, проще. Например, в большинстве экшенов используется типовой набор клавиш для прицеливания, стрельбы, бега, прыжков, приседаний и перезарядки. Если ваша игра не поддерживает того же стандартного управления, игрокам, скорее всего, будет труднее разобраться и привыкнуть. Это, в свою очередь, может вызывать ненужное раздражение, а слишком трудное управление и вовсе может заставить некоторых игроков бросить игру. И опять же, если дизайн требует пойти наперекор условностям, дерзайте. Однако учтите, что игрокам нужно время, чтобы переучиться. Создатели игры Skate (Electronic Arts) придумали управление, совершенно не похожее на то, что использовалось в прошлых играх про скейтбордистов. Если раньше трюки выполнялись посредством сочетаний кнопок, то в Skate было введено управление только с помощью двух стиков. Продиктовано данное решение, скорее всего, геймплейными соображениями: чтобы игроки, умеющие кататься на скейте, ощутили через пальцы примерно то же, что ощущают, когда по-настоящему стоят ногами на доске (доходчивее объяснить, к сожалению, не могу: я не скейтбордистка).
Тем, кто всю жизнь прожил в Штатах и приехал в Великобританию, придется потратить время и усилия, чтобы привыкнуть к левостороннему движению и при переходе дороги сначала смотреть направо. От привычек, как известно, тяжело избавиться, поэтому попытки изменить укоренившиеся в сознании игроков условности должны быть обоснованы. В противном случае изобретать велосипед заново не рекомендую.
11.2.5. Минимизация нагрузки
Во время игры игрок подвергается нагрузке: когнитивной (т. е. на внимание и память) и физической (например, число нажатий на клавиши для выполнения действий). По возможность ее необходимо минимизировать, если только, как обычно, это не противоречит задумке.
• Минимизация физической нагрузки
Некоторые игры созданы для того, чтобы заставить игрока попотеть (например, Just Dance от Ubisoft) или проверить быстроту его пальцев (например, Guitar Hero от Harmonix). Однако в большинстве остальных игр физический вызов не главное. Соответственно, снижение физической нагрузки поможет избавить игроков от боли в мышцах и усталости. Например, вместо постоянных нажатий на кнопку для бега (или галопа), можно сделать так, чтобы ее достаточно было зажать (или вовсе нажать один раз для переключения режима). Если игра динамичная, проследите за тем, чтобы частотные действия (например, бросок гранаты, смена оружия или экипировки и т. п.) не требовали слишком много нажатий.
Чтобы рассчитать, сколько времени – и, соответственно, усилий – займет перемещение между интерактивными участками, воспользуйтесь законом Фиттса (он предсказывает, как долго занимает указание на определенную точку в зависимости от ее размера и расстояния от стартовой позиции). Если, например, для экипировки снаряжения нужно сначала выбрать предмет в левом углу экрана, потом перенести его в правый, а затем подтвердить выбор по центру, то на это потребуется больше времени и усилий (т. е. более размашистый жест). Соответственно, необходимо обращать внимание на все жесты, используемые в игре, и по возможности их упрощать.
На консолях эта проблема не так серьезна (по крайней мере, в меню), потому что игрокам нужно просто нажимать на кнопки, вместо того чтобы перемещать курсор. Исключением может быть виртуальный курсор, управляемый посредством аналоговых стиков (как, например, в Destiny от Bungie или No Man’s Sky от Hello Games). В этом случае физическую нагрузку и закон Фиттса необходимо учитывать, поскольку скорость движения курсора не всегда равна силе отклонения стика. Если расположение интерактивных участков продумано плохо, а курсор ползет очень медленно, это весьма скоро может вымотать. Обычно, если игрок отклоняет стик до упора, курсор ускоряется, а интерактивные зоны «магнитят» курсор к себе, что увеличивает точность нажатия (тот же принцип, что и в «автоприцеливании»).
Очень важно учитывать физическую нагрузку и на мобильных устройствах. Нужно представлять, как игроку следует держать телефон или планшет (вертикально или горизонтально), а также какие движения он должен выполнять пальцами. Если игрок держит смартфон вертикально и может управлять одним большим пальцем, то взаимодействие с интерактивными зонами в противоположной части экрана (т. е. в левом верхнем углу, если игрок правша) потребует дополнительных усилий и времени. Соответственно, туда следует помещать кнопки, нажимать на которые нужно не очень часто (поэтому кнопку настроек располагают в верхнем правом углу экрана).
Как видно, в зависимости от платформы и типа игры физическая нагрузка может оказывать большее или меньшее влияние на юзабилити. И все равно старайтесь ее учитывать и по возможности уменьшать.
• Минимизация когнитивной нагрузки
В первой части книги мы отмечали, что ресурсы памяти и внимания у нас весьма ограничены. Соответственно, когнитивную нагрузку, не имеющую первоочередного значения для геймплея, необходимо свести к минимуму. Например, в серии игр Assassin’s Creed (Ubisoft) доступные действия и отвечающие за них кнопки постоянно выведены на экранном интерфейсе (см. рис. 4.7 в главе 4). Таким образом, игроку не нужно запоминать, какие кнопки что делают. Разработчики решили, что держать в голове управление для игрового опыта не важно; гораздо важнее, чтобы игрок чувствовал свободу передвижения и совершал крутые трюки. И правда, трудно чувствовать себя крутым, если должен постоянно вспоминать, на какую кнопку в какой ситуации нажимать. Гейм-дизайн – это искусство компромиссов и непростых решений, поэтому вам нужно решить, на что игроки должны выделять когнитивные ресурсы, а где нагрузку можно снизить.
Также в первой части упоминалась проблема мысленного поворота, например при пользовании радаром или мини-картой. Если мини-карта не эгоцентрична (т. е. не ориентирована относительно того, куда смотрит игрок), на ее «поворот» потребуется определенное количество когнитивных ресурсов. Поэтому мини-карты принято делать эгоцентричными. В случае с обычными картами это не столь критично, потому что окно с картой занимает весь экран и игра ставится на паузу. Однако хорошо, если игроки могут добавлять на карту метки, которые потом отображаются на радаре: это снижает нагрузку на память, так как больше не нужно запоминать маршрут.
В своей книге «Не заставляйте меня думать. Веб-юзабилити и здравый смысл»[39] профессиональный UX-ист Стив Круг четко объясняет, что лишняя когнитивная нагрузка отвлекает нас от выполняемой задачи. В играх необходимость обрабатывать информацию, не связанную напрямую с текущей ситуацией, будет служить также раздражающим фактором. Особенно важно следить за когнитивной нагрузкой на этапе введения в игру, когда игроки только осваивают основные механики и правила, ведь как описано в главе 5, если требования к когнитивным ресурсам превышают ограничения оперативной памяти, качество обучения падает [Sweller, 1994]. Также не забывайте, что чем глубже информация обработана, тем лучше она запоминается. Соответственно, если вы хотите, чтобы игроки уделили больше ресурсов оперативной памяти нужным механикам и функциям, избавляйте их от лишней нагрузки.
Наконец, чтобы полностью погрузиться в основной опыт и испытать ощущение потока, игрок не должен отвлекаться. Соответственно, требование минимизации нагрузки касается тех задач, которые напрямую с этим основным опытом не связаны (см. раздел главы 12 о потоке в играх).
11.2.6. Предупреждение и исправление ошибок
Ошибки игроков приводят к гибели их персонажей. Это часть игрового опыта, и будь препятствия слишком простыми, мы не испытывали бы такого удовлетворения, преодолевая их (см. раздел главы 12 о потоке в играх). Это, однако, не значит, что вы не можете прощать игрокам некоторые ошибки или разрешать их исправлять, особенно когда они вызывают раздражение, не связанное с геймплеем. Помните про когнитивный диссонанс: если игрок не понимает, что он сделал не так, он едва ли будет винить в ошибке себя. Как и лиса из эзоповой басни (см. главу 6), чтобы избавиться от дискомфорта, он просто скажет, что игра тупая, и переключится на какую-нибудь еще (если только не мотивирован проходить дальше через боль и неудачи).
• Предупреждение ошибок
Наши мыслительные способности ограничены; мы не можем обращать внимание на все, что делаем, и не можем помнить всю информацию, которую получаем. Соответственно, мы всегда будем совершать ошибки. Ваша задача как дизайнера – предугадать возможные ошибки игрока, чтобы их предотвратить. Возьмем простой пример: если у вас есть две кнопки с противоположными функциями, скажем, «подтвердить» и «отменить», но расположенные при этом очень близко друг к другу, закон Фиттса предсказывает, что вероятность нажатия не на ту клавишу будет высока. Поэтому, если ошибка может привести к серьезным потерям (например, отменить скачивание игры за несколько секунд до конца), лучше разнести кнопки подальше.
Также обязательно запрашивайте подтверждение, особенно для радикальных или необратимых действий. Так, в World of Warcraft (Blizzard) случайно удалить персонажа было крайне трудно: для этого требовалось вручную ввести слово «УДАЛИТЬ» и подтвердить намерение. В общем, любое действие, ведущее к исчезновению чего-либо, должно требовать подтверждения (или иметь возможность отката).
Ошибки раздражают не только в меню, но и в самой игре. Здесь тоже есть способы щадить игроков и не позволять им совершать ошибки. Например, в Mario Galaxy (Nintendo) хитбоксы[40] врагов меньше, чем их трехмерные модельки. Соответственно, игрок может подходить к врагам ближе, не получая урона. Это весьма разумно, учитывая, что в трехмерном мире трудно с точностью рассчитать дистанцию между Марио и другим близким персонажем или объектом.
В играх-платформерах предупреждать ошибки можно также, разрешая управлять персонажем в прыжке или полете и позволяя безопасно попасть на платформу, даже если зона коллизии между моделью персонажа и платформы всего в один пиксель. А в играх с механикой крафта, например, вы можете предотвратить ошибки, если дадите игрокам возможность на ходу проверить, какое оружие у них экипировано и, соответственно, какие боеприпасы нужны.
Понимая, как работает мозг (см. первую часть книги), вы можете предвидеть наиболее вероятные ошибки и решить, предотвращать их или нет. Наблюдение за игроками в естественной обстановке на плейтестах также позволит выявить самые распространенные ошибки. Помните, что гейм-дизайнер должен учитывать человеческие возможности и ограничения. Если игроки массово совершают одни и те же ошибки, вероятно, это связано с дизайном. Помните, что даже высококвалифицированные летчики не застрахованы от фатальных промахов, если кабина самолета плохо сконструирована. От ворчания и потрясания кулаком за стеклом нет никакого толку. Если участники плейтеста точно отражают целевую аудиторию вашей игры, то после релиза другие игроки, скорее всего, будут совершать те же ошибки. Поэтому, если вы хотите предложить аудитории отличный опыт, необходимо разобраться, каким образом дизайн провоцирует ошибки.
И вот еще что: ни в коем случае не позволяйте игрокам выходить из игры без сохранения. Сейчас в большинстве игр прогресс сохраняется автоматически (и это еще один превосходный пример предотвращения ошибок), но иногда нужно сохранять его вручную. Поскольку данная процедура больше не является стандартной, не позволяйте игрокам случайно выйти, не сохранившись (исключение возможно, если в вашей игре предусмотрен единственный слот сохранения: кто-то может решить не перезаписывать его, чтобы продолжить именно с последнего сохранения). Наверстывать потерянное прохождение может быть очень трудно и утомительно. Точно так же, если в вашей игре есть контрольные точки, предупреждайте игроков, что произойдет, если они выйдут из игры, не достигнув следующей (например, сообщите, как давно прогресс сохранялся в последний раз).
И наконец, в многопользовательских играх четко сообщайте игрокам, что произойдет, если они выйдут из текущего матча. Во многих играх игроков, покинувших матч до завершения, штрафуют, но не все понимают, почему это неприятно для других игроков и каковы последствия. Кроме того, на консолях игрок может выйти из игры, выключив приставку, а это значит, что он не увидит сообщений о последствиях выхода (например, бан или предупреждение). Возможно, стоит отображать эти предупреждения при запуске игры.
• Исправление ошибок
Многие наверняка не раз испытывали облегчение, когда система позволяла исправить совершенную ошибку. «Отмена» – превосходная функция! В играх ее реализовать не так просто, если только она не является ключевой механикой (как, например, в Braid от Number One), однако как минимум разрешайте игрокам восстановиться в контрольной точке неподалеку от места ошибки (и гибели). А в ряде случаев стоит добавить полноценную кнопку «отмены». Например, в League of Legends (Riot) можно отменить последнее действие в магазине – покупку или продажу. Еще один пример: разрешайте игрокам сбросить очки, потраченные на развитие персонажа, чтобы перераспределить их и тем самым исправить неудачные решения.
11.2.7. Гибкость
Принцип гибкости связан с возможностью настроить игру под себя. Чем больше вариантов, например, управления, размера и цвета шрифтов, тем доступнее игра для пользователей, в том числе с особыми потребностями. Помните о субъективности восприятия: то, что вам кажется удобным (например, размер текста), может доставлять дискомфорт ряду, если не большинству, ваших игроков (например, тем, у кого слабое зрение или кому приходится читать субтитры). Кроме того, до 8 % мужчин на планете в той или иной степени страдают дальтонизмом, и это тоже следует принять во внимание.
Кроме того, люди делятся на правшей и левшей. У кого-то может быть временная нетрудоспособность (например, вывих кисти), а у кого-то – постоянная (например, ревматоидный артрит). Чем больше настроек управления вы предлагаете, тем выше доступность и уровень юзабилити в целом. Однако проследите, чтобы игроки знали о том, что что-то можно менять: мало кто копается в настройках перед тем как нажимает «Начать игру». Отличное решение применили создатели Uncharted 4 (Naughty Dog), предложив игрокам выбрать набор настроек при первом запуске игры.
Помните также, что только хардкорные игроки подгоняют настройки под себя; большинство же следует по пути наименьшего сопротивления и ничего не меняет. Поэтому, обеспечивая свободу выбора, как можно тщательнее задайте настройки по умолчанию с учетом массовой аудитории (опирайтесь на стандартные решения, принятые в индустрии).
Очень легко забыть о том, что многие воспринимают мир совсем не так, как мы. Ориентирование на гибкость и доступность – это не просто альтруизм, но и хорошая бизнес-практика, так как расширяет потенциальную аудиторию. Если позаботиться обо всем заранее, вам даже не придется тратить на это лишнее время. В своем эссе UX-дизайнер Иэн Хэмилтон объясняет, почему доступность важна и почему обеспечить ее не так трудно. Кроме того, приглашаю вас посетить сайт http://gameaccessibilityguidelines.com, где приводятся четкие инструкции по инклюзивному гейм-дизайну.
Гибкость также подразумевает возможность выбирать уровень сложности. Одним игрокам нужен серьезный вызов, а другие просто хотят расслабиться. Подумайте над тем, чтобы игроки имели доступ к элементам игры, которые обычно открываются только после определенного этапа прохождения. Это особенно важно в ряде пати-геймов[41], где для того, чтобы получить доступ к разным режимам, зачастую предварительно нужно пройти скучный и искусственно привязанный «сюжет» (а ведь суть пати-геймов в том, что вы можете играть с кем угодно и когда угодно, как в настольную игру). Это вызовет особое раздражение у тех, кто купил игру, чтобы развлечься с друзьями вечером. Нет причин запрещать игрокам получать удовольствие от всех аспектов игры, особенно если за нее уже заплатили. Если вам важна реиграбельность или удержание игроков, то можно прибегнуть к менее раздражающим механизмам (см. главу 12 о мотивации).
И напоследок упомяну о «принципе Парето», также известном как «правило 80/20»: за 80 % результата отвечают 20 % параметров системы. Например, 80 % использования продукта приходится на 20 % его функций. Иначе говоря, большинство будет пользоваться лишь пятой частью заложенного в игру функционала. Так что основной интерфейс должен быть максимально простым: отображайте только те элементы, которые обязательны для прохождения игры (и только тогда, когда необходимо), а хардкорные игроки пусть сами настраивают интерфейс под себя (отличный пример подобной гибкости можно встретить в World of Warcraft).
Иэн Хэмилтон, специалист по доступности и UX-дизайнер
Доступность – крайне важное направление в нашей отрасли, и по многим причинам. Во-первых, размер рынка: согласно официальной статистике, около 18 % людей обладают тем или иным дефектом. Не каждый дефект создает дискомфорт во время игры, но существуют проблемы, не отраженные в статистике, например дальтонизм (8 % мужчин) и дислексия (14 % взрослых в США). Разработчики не должны этим пренебрегать.
Во-вторых, доступность – это работа на благо людей. Если ваш доступ к развлечениям, культуре и социализации, которые многим кажутся само собой разумеющимися, ограничен, игры могут это исправить и сделать вашу жизнь лучше.
В последнее время мы наблюдаем развитие этого направления, причем темпы только растут. Еще многие задачи не решены, но прогресс налицо.
Сделать игру доступной нетрудно. С самого начала нужно определить, какие могут возникнуть помехи вовлечению и получению удовольствия с точки зрения двигательных, слуховых, речевых, зрительных и мыслительных способностей. Некоторые помехи неразрывно связаны с ключевыми механиками, и избавиться от них невозможно – ничего страшного. Главное – постарайтесь устранить лишние барьеры.
В большинстве случаев достаточно либо задействовать дополнительные каналы передачи информации – например, не только цвет, но и символ; не только речь, но и текст, – либо просто дать чуть больше гибкости, скажем, в настройках уровня сложности или управления. Если озаботиться этим как можно раньше, то предусмотреть все это нетрудно, а эффект будет значительный. Не делайте крошечный перегруженный интерфейс, и игра сразу станет более приятной как для людей с разными моторными и зрительными проблемами, так и для тех, кто играет на ярком солнце или в автобусе, едущем по неровной дороге.
Добавьте хорошие субтитры, и игра станет удобной для тех, кто играет без звука и без наушников, потому что рядом спит маленький ребенок. Оптимизация управления под одну руку сделает игру доступней для тех, у кого нет руки или она сломана, а также для тех, кто держится за поручень в метро, несет сумку или держит пиво. А иконки в дополнение к цветовым обозначениям на карте будут полезны всем игрокам.
Доступность важна для всех дисциплин, но именно UX обладает и великой силой, и великой ответственностью сделать наш мир лучше. Это единственная дисциплина, где необходимость стоять на страже нужд всех игроков прописана буквально в самом названии: буква U не означает «только те пользователи, которые могут полноценно взаимодействовать с игрой». Все необходимые для этого инструменты уже есть: экспертная оценка, анализ статистики, изучение пользователей. Лучшие практики выложены в открытый доступ на ресурсах вроде http://gameaccessibilityguidelines.com. Не поленитесь с ними ознакомиться!
Игры – великое орудие добра, а UX – уникальная дисциплина, способствующая воплощению этого добра. Нам всем нужно только постараться.