Предисловие Пользовательские интерфейсы (UI) таких экшн-игр, как Overwatch и Battlefield, уникальны тем, что предоставляют игроку всю важную игровую информацию, не отвлекая его от игрового процесса.
В этой статье я опишу уроки пользовательского опыта, которые я усвоил при создании боевой игры.
HUD для игры Дредноут. По сути, в этом эссе более подробно рассматриваются способы модификации хорошо известных подходов к анализу моделей пользовательского опыта, таких как закон Фиттса, для использования в HUD-играх.
Прежде чем вдаваться в подробности, я должен упомянуть предысторию, чтобы вы могли лучше понять наблюдения, которые я сделал за последние два или три года.
Я часто буду ссылаться на концепцию, придуманную Джефф Раскин , легендарный специалист по компьютерным интерфейсам; в своей потрясающей книге «Гуманный интерфейс» он ввел понятие «локус внимания», которым я буду пользоваться без зазрения совести, чтобы не запутать вас другими родственными терминами.
Короче говоря, локус внимания относится к физическому объекту или месту, которому ваш мозг в данный момент уделяет все внимание, сознательно или подсознательно.
Большинство других терминов, таких как «фокус» или «цель», во многом подразумевают сознательное решение обратить внимание на определенное место или объект. Это важное отличие, поскольку пользовательский интерфейс игры должен позволять пользователю менять локус внимания игрока, не заставляя его делать это сознательно.
Я искренне рекомендую прочитать книгу Джеффа, потому что, несмотря на ее возраст и новые технические улучшения, она все еще содержит много идей, которые пользовательский интерфейс или дизайнер пользовательского опыта могут применить к современным цифровым интерфейсам.
Для игровых HUD можно применить закон Фиттса в модифицированной форме.
Если вы не знакомы с Закон Фиттса , то это один из самых фундаментальных научных методов оценки и прогнозирования практически любого интерактивного элемента, как физического, так и цифрового.
Соответственно, это позволяет делать относительно точные прогнозы об удобстве использования элемента пользовательского интерфейса даже без его использования в дизайне меню или игры.
Формула определяет легко рассчитываемый индекс сложности ID; По сути, это означает, что элементы интерфейса, требующие от пользователя перемещения на большее расстояние (обозначается амплитудой A), а также имеют меньший размер (обозначается шириной W), сложнее в использовании, т.е.
имеют более высокий индекс сложности, и наоборот, низкий показатель эффективности.
Аналогичным образом, меньшие расстояния и большие размеры элементов приводят к более низкому индексу сложности.
Согласно закону Фиттса, сформулированному Шенноном [1] ID рассчитывается по следующей формуле (см.
рисунок А).
Рис.
Ответ: Закон Фиттса, сформулированный Шенноном.
Рекомендую посмотреть это видео для подробного объяснения.
[2] , что хорошо иллюстрирует закон.
Формулировка Шеннона больше ориентирована на активное, осознанное использование интерфейса, физического (кнопки устройства или прибора, рычаги и т. д.) или цифрового (все стандартные компоненты пользовательского интерфейса, такие как меню, кнопки, ползунки, полосы прокрутки и т. д.).
Естественно, он менее полезен для оценки того, насколько эффективно пользовательский интерфейс пассивно работает, предоставляя информацию пользователю, поскольку игрок может не искать эту информацию активно.
Однако, как я опишу ниже, этого также можно достичь, сделав довольно простые замены и модификации исходного уравнения.
Следует отметить, что далее я определяю оба типа пользовательского интерфейса соответственно как интерактивный (пользователь нажимает кнопки и т. д.) и только информационный (пользователь пассивно потребляет информацию).
Чтобы внести значимые изменения в закон Фиттса, полезно наблюдать, как пользователь взаимодействует с интерактивный И только информационный Пользовательский интерфейс.
С одной стороны, при активном использовании пользовательского интерфейса, требующего ввода с помощью мыши, пользователь фактически переключает свое внимание на элемент пользовательского интерфейса, с которым он выбрал для взаимодействия.
Например, нажатие кнопки или открытие подменю всегда требует определенной степени сознательного усилия, т.е.
необходимое переключение внимания начинается непосредственно с пользователя.
С другой стороны, с целью применения только информационный HUD игры, переключение внимания пользователя должно быть вызвано самим пользовательским интерфейсом.
Для оптимальной производительности мы в первую очередь стремимся создать пользовательский интерфейс с элементами, расположенными таким образом, чтобы они быстро привлекали внимание игрока, когда это необходимо, но позволяли ему легко вернуться к игровому процессу после получения всей необходимой для игры информации.
По сути, мое предложенное изменение индекса сложности для только информационный Пользовательский интерфейс игры определяет, в какой степени рассматриваемый элемент пользовательского интерфейса способен смещать локус внимания и передавать информацию быстро и достаточно эффективно, чтобы игрок мог ее использовать.
Важно отметить, что я говорю об играх, ориентированных на действие, таких как Dreadnought, фокус внимания которых традиционно сосредоточен в центре экрана.
Это критический аспект, который следует учитывать при разработке пользовательского интерфейса такого типа, особенно потому, что наш мозг отфильтровывает информацию на краях поля зрения; Размещение элементов пользовательского интерфейса по краям экрана может привести к возможному снижению внимания пользователя по сравнению с тем, что задумал дизайнер.
Теперь я углублюсь в настоящую модификацию формулировки Шеннона и ее применение.
Чтобы закон Фиттса мог предсказать удобство использования с помощью индекса сложности, в случае только информационный UI нам нужно заменить исходное значение амплитуды.
Чтобы создать поле зрения, глаза движутся так быстро и хаотично, что мы можем игнорировать физическое расстояние как фактор; мы заменим ее более структурно-ориентированной составной переменной только информационный пользовательский интерфейс Амплитуда А в этом случае будет определяться сила визуальной индикации или изменение сигнала.
Полезно подумать об этой амплитуде А как способ описания соотношения сигнал/шум в нашем мозге.
Чем сильнее изменение внешнего вида элемента, тем больше вероятность смещения локуса внимания на него.
Это также объясняет, почему А определяется как составная переменная, состоящая из нескольких параметров и переменных: поскольку интерес мозга к входным визуальным сигналам может активироваться изменениями размера, цвета, движения, шума и т. д. объекта.
Например, в случае HUD А может включать такие факторы, как процент контрастности, увеличение, уменьшение или разница в цвете или изменение яркости или просто изменение размера в HUD; все, что может привести к увеличению или уменьшению визуальной стимуляции и является измеримым действием, которое, в свою очередь, может привлечь внимание пользователя.
Все эти факторы можно умножить, чтобы лучше понять их фактическое влияние на индекс сложности задания.
Если требуется большая точность определения того, какие визуальные индикаторы вызывают наибольшие изменения амплитуды, ту же формулу можно применить только с одним изолированным параметром - амплитудой.
Это, в свою очередь, позволит нам определить вес каждой переменной, влияющей на А .
Наряду с амплитудой в формулу необходимо ввести новую переменную: расстояние D, которое представляет собой расстояние от основного куска внимания игры до рассматриваемого элемента.
Основным локусом внимания является выбранная вами область внимания, которой игрок должен уделять все внимание большую часть времени.
В игровых жанрах ФПС И ТПС скорее всего, это будет центр экрана.
Чтобы получить предсказуемые результаты, соответствующие точности исходной формулы, нам нужно разделить расстояние на составную амплитуду.
Рис.
B1: Модифицированная формулировка закона Фиттса для использования в игровых интерфейсах.
Это даст нам два важных преимущества.
Используя эмпирические измерения, мы можем сделать вывод, что компоненты пользовательского интерфейса, расположенные ближе к основному локусу внимания, значительно лучше привлекают временные сдвиги локуса внимания.
Кроме того, чем ближе виджет к текущему локусу внимания, тем больше мы уменьшаем реальную амплитуду, которую виджет регистрирует зрительная кора, позволяя игроку оставаться сосредоточенным на игровом процессе.
На самом деле, есть очень простой эксперимент, который позволит вам испытать эти эффекты на себе.
Все, что для этого нужно, — это время и один помощник.
Эксперимент потребует от вас полного внимания к одному предмету или задаче, поэтому вы вдвоем сможете попробовать его во время работы.
Помощник должен дождаться, пока вы полностью сосредоточитесь на выбранной вами задаче.
Затем следует начать смещать локус вашего внимания с низкой амплитудой.
Вы обнаружите, что когда помощник пытается привлечь ваше внимание с низкой амплитудой, находясь на периферии вашего поля зрения, может потребоваться некоторое время, чтобы привлечь ваше внимание.
Однако если оно ближе и его амплитуда огромна, это может вас даже напугать.
Таким образом, существует оптимальная точка, в которой ваши элементы пользовательского интерфейса должны создаваться с точки зрения положения и амплитуды.
Чтобы дополнительно проиллюстрировать эту довольно скучную тему, я покажу два примечательных примера, в которых боевой пользовательский интерфейс Дредноута значительно выиграл от переделки компонентов пользовательского интерфейса с целью снижения индекса сложности.
Первые элементы, о которых я хочу поговорить, — это два наиболее важных элемента пользовательского интерфейса всего HUD: «здоровье» и энергия корабля игрока.
В нашем первоначальном прототипе мы разместили оба элемента внизу экрана.
Мы сделали это, чтобы не отклоняться слишком далеко от шаблонов, к которым привыкли игроки в шутеры от первого лица; Также за счет близости к локусу внимания игрока элементы были лучше видны в пылу боя.
(см.
рис.
С1) 
Рис.
C1: Первоначальный макет компонентов пользовательского интерфейса для здоровья и оружия.
Но наше внутреннее тестирование вызвало сомнения в достаточной видимости элемента.
Члены нашей команды начали просить переместить индикаторы в место, более обычное для индикаторов здоровья в шутерах от первого и третьего лица, а именно в нижние левый и правый углы конуса обзора.
Итак, мы поняли, что, несмотря на наши надежды на улучшенную компоновку элементов пользовательского интерфейса, ожидаемого результата мы не получили; они были недостаточно хороши, чтобы преодолеть привычки опытных игроков.
Рис.
C2: Примерная область, требующая повышения уровня амплитуды для смещения локуса внимания.
Зелёный и синий обозначают области, которые игрок активно просматривает во время интенсивного игрового процесса, красный — область, где он, скорее всего, не заметит изменений.
Это заставило нашу команду более тщательно задуматься об оценке и прогнозировании эффективности элементов.
только информационный UI, что привело нас к выводам, изложенным в этой статье.
В частности, мы начали решать проблему, тестируя способы организации элементов пользовательского интерфейса таким образом, чтобы они преодолевали привычки опытных игроков и обеспечивали улучшенный пользовательский интерфейс для обычных или совершенно неопытных игроков.
Мы остановились на решении, которое поддерживало ощущение командования большим космическим кораблем благодаря более яркому визуальному стилю и улучшенному удобству использования.
Перемещение элементов туда, где они всегда были на виду, дало нам возможность ненадолго сменить фокус внимания с самого боя, не ухудшив при этом качество игры.
Если коротко, то мы разместили две дуги в районе расположения движущегося прицела корабля в самые напряженные моменты боев.
(см.
рис.
D1) 
Рис.
D1: Улучшен виджет здоровья и энергии.
Это позволило нам значительно уменьшить реальный размер элементов, поскольку теперь большую часть времени они по-прежнему находятся гораздо ближе к фокусу внимания игрока; Мы также увеличили соотношение сигнал/шум с помощью цветных дуг, чтобы лучше сигнализировать о низком уровне здоровья или энергии.
Это, в свою очередь, помогло приблизить амплитуду к необходимым уровням, не напрягая при этом зрение игрока; нам удалось привязать элемент к области на минимальном расстоянии от основного фокуса внимания.
Кроме того, пользователи получили возможность быстрее реагировать на определенные ситуации в бою.
(см.
рис.
D2) 
Рис.
D2: Расширенные компоненты расположены ближе к центру основного локуса внимания.
Как показано на рис.
D3, нам удалось существенно снизить индекс сложности.
Улучшения по меньшей мере на 400 % были достигнуты за счет сочетания улучшения амплитуды примерно в 4,5 раза по сравнению с амплитудой, используемой для старого компонента, а также оптимизации компоновки.
Рис.
D3: Значения индекса относительной сложности старых и новых компонентов здоровья и энергетики.
Чем ниже значения, тем лучше.
Третьим компонентом была демонстрация оружия.
Мы использовали аналогичный подход, чтобы исправить это; Наконец-то мы получили HUD, сбалансированный с точки зрения лучшего визуального отображения, а также большей эффективности передачи необходимой информации игроку.
Сначала мы разместили его в правом нижнем углу, как это бывает во многих играх.
Многие альфа-игроки, тестеры и разработчики сообщают, что они точно не знают, почему оружие начинает перезаряжаться в определенный момент времени; Также немало времени заняла проверка оставшихся боеприпасов.
Это значительно снизило их возможности выиграть текущую битву.
Для повышения эффективности компонента мы решили разделить интерфейс основного и дополнительного оружия на отдельные визуальные области; мы разместили их рядом с показателями «здоровья» и энергии, о которых я писал выше.
Рис.
E1: Новый макет отображения оружия.
Кроме того, мы больше не показываем постоянно название оружия, а только при переключении оружия или появлении во время игры.
Это освободило примерно 60% места, которое занимали исходные компоненты, а также предоставило возможность постоянно информировать игрока о текущем состоянии обоих комплектов оружия; теперь гораздо проще определить, какой из них активен; Также мы добились увеличения амплитуды сигнала при отображении сообщений о перезарядке любого оружия.
Рис.
E2: Все компоненты четко расположены в выбранном нами оптимальном конусе обзора.
Наконец, мы позволили игрокам быстрее реагировать на сигналы при выборе режима снайперского прицела оружия.
Поскольку это снижает их видимость в игре, мы хотели предоставить им больше информации о текущем состоянии их корабля.
Для этого мы переместили все элементы, расположенные вокруг локуса внимания, еще ближе к центру.
Теперь даже игроки-снайперы смогут реагировать на возможные ближайшие угрозы быстрее, чем раньше.
Рис.
F1: режим «Снайперский прицел», повышающий читаемость информации в ситуациях высокой фокусировки.
Честно говоря, у меня не было этого уравнения, когда мы применяли последнюю версию нашего HUD; однако я не хочу дискредитировать ценность наших предположений, поскольку мы ясно видим улучшение опыта игроков после этих изменений.
Однако меня всегда беспокоило то, что наше понимание этой проблемы было, мягко говоря, очень ограниченным.
Поэтому я начал искать возможные научные объяснения.
Я думаю, что полученные знания сделают этапы планирования и проектирования будущих проектов менее утомительными и с большей вероятностью принесут прогнозируемые результаты.
И последнее, что я хотел бы упомянуть, это то, что очень важно найти хороший баланс макета и размера.
Конечно, увеличение амплитуды и размера компонентов приведет к повышению удобства использования этих компонентов, но это, в свою очередь, может снизить удобство использования других; Это тонкий баланс, хотя упомянутые мной инструменты могут облегчить путь к хорошим результатам.
Привычка, ты знаешь, где дверь! Но не забудьте вернуться позже! Обратите внимание, что материал этого раздела основан на моем собственном опыте, и существует множество различных точек зрения на эту тему, каждая из которых имеет свои плюсы и минусы.
У меня не будет для вас всех ответов относительно только информационный пользовательский интерфейс Часто расположение довольно важных элементов пользовательского интерфейса основано на устоявшихся привычных шаблонах.
Это не обязательно плохо, но привычки могут сильно препятствовать внедрению улучшенных шаблонов UI/UX и их принятию более широким сообществом разработчиков игр.
С помощью таких шаблонов мы можем легко распараллелить задачи, которые в противном случае заняли бы гораздо больше времени.
Однако это палка о двух концах: пользователи могут получить большую выгоду от улучшенных моделей пользовательского опыта, но если разработчики решат придерживаться неэффективных, но распространенных стандартов UX, мы увидим, что игроки осваивают новый жанр с большей трудностью, чем обычно.
Для меня это безопасное практическое правило: если опытный и искушенный разработчик игр может очень быстро привыкнуть и освоить новый шаблон, у опытных игроков тоже не возникнет с этим проблем.
Худшая ошибка, которую вы можете совершить, — это предположить, что ваши пользователи не справятся.
Никогда не считайте их ограниченными или даже глупыми.
Просто наблюдая за тем, как во многих многопользовательских играх есть удивительные моменты, когда игроки находят способы играть так, как не задумывалось разработчиками, это лучший пример того, как игроки подготовлены к таким испытаниям.
В конце концов, мы просто хотим сделать игру более доступной для всех игроков, и новые игроки больше всего выиграют от улучшений UX. В качестве практического примера я приведу наиболее яркий пример того, что, по моему личному мнению, является одним из самых больших провалов в старейшем жанре в истории видеоигр: полоска здоровья в шутерах от первого лица.
Во многих, если не в большинстве старых и новых шутеров от первого лица, создатели размещают индикатор здоровья в левом нижнем или правом нижнем углу экрана; Как мы выяснили в первой части статьи, это значительно затрудняет переключение фокуса внимания на этот виджет во время интенсивного игрового процесса.
Как видите (рис.
G1), они явно расположены вне «конуса внимания», который мы приняли условно оптимальным для нашей игры (см.
рис.
C2).
Я не хочу сказать, что это обязательно плохое место, но вы всегда должны думать о последствиях использования такого пункта, а также проверять, соответствует ли этот пункт тем требованиям, которые вы установили с разработчиками игры.
Рис.
G1: Виджет пользовательского интерфейса здоровья в популярных играх FPS. Следует учитывать, что очень часто для уменьшения помех используют метарешение: подумайте о пост-эффектах по краям экрана — например, капли крови на «объективе камеры», когда здоровье падает до критического уровня.
; примеры этого вы можете увидеть на рис.
G2. В зависимости от их силы это может привести к другим проблемам: негативно повлиять на игровой процесс для пользователей с физическими недостатками, такими как дальтонизм.
Мета-решения, подобные приведенным выше, обычно работают довольно хорошо, но также поднимают вопрос о том, действительно ли они более удобны, чем сама полоса здоровья; и если да, то нужен ли вообще этот показатель? Популярные игры, такие как Call of Duty, похоже, уверенно отвечают на этот вопрос «нет».
Однако, если он вам нужен, вы можете подумать о своем собственном размещении и размере энергетической панели.
Рис.
G2: Мета-решения для отображения низкого здоровья в современном FPS. Я предлагаю всем разработчикам игр, UX-экспертам и UI-художникам собрать все элементы, которые имеют популярное применение или общие шаблоны в других играх; дело в том, что они могут совпадать с типом разрабатываемой вами игры; проанализируйте эти элементы и будьте честны и открыты, если обнаружите недостатки в примерах их использования.
Если у вас есть какие-либо сомнения относительно требований к уровню производительности компонента, назначьте ему еще одну итерацию проектирования.
Будьте терпеливы и настойчивы, используйте свои знания закона Фиттса и других UX-паттернов, чтобы найти способ создать компонент с более низким индексом сложности.
Если вы достигли стадии тестируемого прототипа, попросите свою команду просмотреть его.
Очень часто элементы имеют популярные решения, поэтому новый дизайн изначально может вызвать отторжение.
Это чувство может затронуть даже вас: очень легко попасть в ловушку «так всегда делалось!» Постарайтесь побороть желание просто вернуть старый компонент и сначала немного поэкспериментируйте.
Я видел этот эффект в прошлом году, когда мы перерабатывали дизайн отображения оружия.
Я думаю, что он содержит один из важных аспектов как для поиска лучшего UX-шаблона, так и для того, чтобы пользователи быстрее адаптировались к UX-шаблонам.
Самая важная часть — попытаться обмануть мозг и заставить его частично отказаться от привычного.
Параллельно протестировав две версии элемента пользовательского интерфейса, мы смогли устранить упомянутые выше барьеры для входа.
Убедитесь, что цикл тестирования рандомизирует использование одного из вариантов.
Это приведет к тому, что наш мозг не сможет последовательно применять ранее изученные навыки из-за различных требований к пользовательскому интерфейсу, предъявляемых к игроку.
Ключевым индикатором теперь будет проверка того, сколько времени потребуется игроку, чтобы вернуться к нормальному поведению; Обычно лучший UX-шаблон — это тот, к которому игрок легче возвращается и гораздо быстрее достигает зоны комфорта по сравнению со слабым дизайном.
Это достаточно простой и быстрый способ найти лучшее решение, оптимизированное под требования вашей собственной игры.
Прототипы жизненно важны Многим из нас это может показаться очевидным, но я по-прежнему считаю, что прототипы — это недостаточно используемый инструмент в разработке игр, поэтому я хотел бы дать пару советов о том, почему вам следует попробовать внедрить их в свои циклы разработки.
Я не могу не подчеркнуть, насколько важно как можно скорее иметь работающий прототип HUD, если эти элементы будут использоваться в вашем игровом процессе.
Это отличный способ определить точку отсечения того, что нужно игроку: «больше» не всегда означает «лучше», когда речь идет о чрезвычайно хрупкой экосистеме пользовательского интерфейса, ограниченного экранным пространством.
Ранние прототипы могут дать вам четкое и ясное представление о том, что помогает, а что сбивает с толку вашу базу пользователей.
Ранние прототипы — безусловно, лучший инструмент в вашем распоряжении, когда дело доходит до создания хорошего пользовательского интерфейса.
Сообщите своей команде, что прототип должен функционировать так, как требуется, но не быть таким отточенным, как конечный продукт. Хотя это очевидно, у меня часто возникали ситуации, когда сотрудники чувствовали, что им нужен «окончательный вариант» прототипов; Это довольно глупо: люди, создающие определенные части игры, должны обладать более чем достаточными навыками абстракции, чтобы понимать, что часть работает без 100% полировки всех иконок и элементов.
Сглаживание неровностей на этом этапе должно быть относительно простым по сравнению с пользовательским интерфейсом, близким к его окончательной форме.
Возможность быстро вносить изменения до тех пор, пока ваши игры не станут идеальными, в конечном итоге будет очень важна для игроков.
Заключение В заключение я рад, что мы создали такой функциональный и понятный HUD, хоть ему иногда и нужно отображать много данных.
Хотя у меня не было особых знаний для его поддержки, поскольку это был мой первый опыт в играх такого жанра, я доволен полученными инструментами, которые буду использовать в будущих проектах.
Я также понимаю, что не каждый жанр может или способен принять такую оптимизацию пользовательского интерфейса игры; однако я уверен, что каждый разработчик игр и UX-эксперт сможет извлечь из этих инструментов определенные уроки, которые улучшат восприятие игроком как пользовательского интерфейса, так и самой игры.
Ссылки [1] Биты в секунду: инновации в моделях, основанные на теории информации [2] Указатели мыши и закон Фиттса Теги: #Игровой дизайн #интерфейсы #Юзабилити #ui #дизайн ux #fps #HUD #dreadnought
-
Звуки Венеры
19 Oct, 24 -
Песочница С Использованием Scvmm
19 Oct, 24 -
Windows 7 – Свежие Скриншоты
19 Oct, 24 -
Эволюция Угроз И Стратегии Защиты
19 Oct, 24 -
Как Я Писал Классические Танки С Интеллектом
19 Oct, 24 -
Умер Рэй Нурда, Основатель Novell
19 Oct, 24 -
Стальные Ликвидаторы
19 Oct, 24
