UX текстов в UI видеоигр на примере проекта, который я делаю

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

Речь про опыт пользователя, ведь именно так расшифровывается UX (User Experience). Опыт описывает отношение игрока к игре - насколько ему понятно и комфортно играть. Понятие UX очень тесно связано к когнитивной нагрузкой.

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

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

Так что же, и вовсе без текстов делать игру? Можно и так, это очень интересное направление, о чём я напишу отдельную статью. Но не всё так страшно, не спешите выпиливать весь текст из своего проекта. Текст - это гибкий инструмент. Одну и ту же информацию текст может передавать с разным качеством. Поэтому очень важно продумывать формулировки. Правильно сопоставлять их с выполняемыми игроком задачами. Убирать всё лишнее и подбирать точные слова.

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

Но прежде нужно немного ознакомиться с игрой, для которой этот интерфейс делался. На момент написания статьи я работаю над проектом "Danger! Energy". Игровой процесс прост как два рубля. Помните, в школьном возрасте учителя давали вот такую задачку:

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

На уровне расположено несколько электрогенераторов, которые игроку нужно активировать, а для этого - проводить прямые лучи через их центры. Делается это путём расстановки специальных усилителей, которые соединяются друг с другом по цепочке. Начало цепочки - Энергетический Колодец, из которого луч выходит в первый поставленный усилитель. Из которого луч идёт в следующий поставленный усилитель. И так далее.

Количество усилителей на уровне ограничено. А ещё есть стены, через которые луч не может проходить. Это порождает множество разнообразных задач по построению цепочек.

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

Теперь нас интересует UI. Изначальная версия выглядела так:

Игрок видит ТОЛЬКО сколько у него осталось тех или иных "ресурсов", причём в довольно громоздкой форме. И это мало того что не очень информативно, так ещё и сильно нагружает мозг, который, по-хорошему, должен думать над решением задачи, а не разгадывать формулировки интерфейса.

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

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

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

Ещё в игре есть миникарта и в интерфейсе нужно отобразить как её открывать. То же самое и с функционалом блокировки камеры.

Итого мы приходим к такому компоновочному прототипу:

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

Итак, мы жаждем конкретики. ЧТО и КАК отображать? Скорее всего, по центру (сверху и снизу) понадобится довольно много места. Значит угловые элементы нужно сокращать. Любые формулировки в духе "Генераторов осталось" или "Сегментов осталось" - слишком громоздкие. Даже если сократить до "Генераторы 2 / 4".

Это очень крутая тема ещё и тем, что иконка требует меньше времени на считывание мозгом, а информации она несёт порой даже больше. Но! Иконки нужно уметь подбирать. Лучше всего использовать какие-то устоявшиеся образы (дискета - сохранить, треугольник - проигрывание, три полоски - меню и т.д.).

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

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

А как отображать сами цифровые значения? Способов есть больше чем вы, скорее всего, думаете. Вот классические способы:

Остаток не годится совсем. В случае генераторов мне как игроку важно понимать мой прогресс. Если 2 генератора осталось - то это может означать разное. Может быть я сделал задачу наполовину (если их всего четыре). А может быть я уже вообще молодец и почти закончил уровень (если генераторов было 20). Неоднозначная трактовка интерфейса - это всегда плохо.

Прогресс хорошо отображать в процентах, но не в данном случае, т.к. генераторы - вполне конкретные объекты, их можно найти на уровне, и они счётны, т.е. я могу их легко пересчитать. Кроме того здесь примерно та же проблема что и в прошлом случае. Если у меня 50% генераторов запущено, сколько ещё осталось? Два? Четыре? Десять? Поэтому лучшим способом будет отображение через дробь: "готово / всего".

То же самое с сегментами. Они счётны. Мне, как игроку, важно знать точное количество оставшихся сегментов. И мне важно знать сколько их всего - чтобы оценить смогу ли уложиться по количеству с альтернативным маршрутом. То есть тут тоже идеальный вариант дробь "осталось" / "всего".

Ах да, небольшой нюанс. Есть же бонусные сегменты, которые игрок получает в процессе решения задачи. Как с ними быть? Сразу добавлять в общак? Или дописывать плюсом? В первом случае игрок может не понимать сколько у него было собрано бонусных сегментов и сколько доступно изначально. Это плохо для оценки альтернативных маршрутов-решений. Поэтому буду показывать бонусную часть отдельно даже несмотря на то, что она занимает место в интерфейсе. Что не критично, т.к. почти всегда бонусных сегментов не более 10.

Выбор цветов тоже важен. Часто я использую два цвета - обычный и главный. Главным выделяю особо важные элементы. И в данном случае цифровые значения главнее иконок и сопровождающего текста, поэтому они белые. Второстепенные элементы я сделал голубым в цвет обрамления панелей интерфейса.

Осталось ещё два левых угла. И ещё нужно найти место для блокировки камеры. Кстати, над миникартой неплохое место. И камеру с блокировкой можно делать иконками. У камеры и замочка есть вполне устоявшиеся образы. Настолько устоявшиеся, что я позволю себе их совместить, чтобы получить одну иконку, а не рисовать две. Оптимизируем количество сущностей.

Для миникарты тоже можно было бы подобрать иконку, наверное. Но опять же никаких прям однозначно устоявшихся образов. Решил оставить текстом. То же самое с главным меню сверху - это просто подсказка как вернуться на выбор уровня. Правда это имеет смысл только для управления с геймпада, т.к. на обычном ПК все знают, что в любой непонятной ситуации нужно жать Escape.

Ну что, с самым простым разобрались. Пора переходить к по-настоящему сложной задаче.

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

Но это только если ограничение на длину всей цепи стоит. А если его нету? Смотрим что получается:

Смотрим и пытаемся делать выводы. С остатком цепи проблема аналогичная с генераторами и сегментами. Непонятно сколько от ограничения игрок уже "съел", что мешает планировать маршрут. Тем более, игрок глядя на интерфейс вряд ли сможет соотнести эти "метры" с расстояниями на игровом поле. Что порождает целый пласт проблем, к которым мы ещё вернёмся.

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

А вот третий вариант получился довольно лаконичный. Именно здесь проценты отлично подходят, т.к. длина принимает большие значения и не счётна. Однако, в данном случае непонятно что эти проценты обозначают, особенно в контексте длины. Ведь речь идёт о максимально допустимой длины, которая от уровня к уровню разная. И есть вопросы как будет выглядеть эта строка когда ограничения нет? Писать там 0% или 100% или даже бесконечно - довольно тупо и выглядит как костыль, а не как грамотный UX.

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

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

Это означает, что помимо процентов нужно где-то показывать текущую длину цепи и максимальную. И делать это лучше прямо на игровом поле. Я пока отложу этот вопрос, т.к. есть подозрение что нечто подобное меня ждёт в нижней строчке про ограничение на сегмент цепи.

Теперь работаем с отдельно взятым сегментом. Обычно сегменты не имеют ограничений, т.е. имеют бесконечную длину. А если они имеют ограничения по длине то к ним может быть взят бонус. Поэтому я не думаю, что здесь годится вариант с процентами, т.к. непонятно в каких единицах эту бонусную длину показывать? В метрах? В процентах? Зато можно попробовать вариант с отображением только ограничения.

Я не стану отдельно приводить случаи без ограничений, т.к. здесь это просто заменится на иконку бесконечности.

Второй вариант сразу мимо - очень много текста, сложно разбираться. У варианта с остатком те же самые проблемы, о которых я писал выше. И ещё непонятно как будет выглядеть "расход" бонусной длины. Вариант с ограничением длины уже выглядит неплохо за исключением того, что игрок не знает текущую длину сегмента.

Отмечу, что у всех вариантов есть две проблемы:

Это всё решается грамотной подборкой слов и формулировки. Это сложно делать, но почти всегда возможно. Хотя, порой на такие вещи тратится несколько дней. Ага, просто на поиск оптимальной формулировки.

В процессе раздумий я пришёл к тому, что отображение текущей длины сегмента в интерфейсе не имеет смысла, поэтому я вынесу её на игровое поле. Это будет выглядеть как "условная линейка" и даст игроку возможность почувствовать размеры. Здесь же на игровом поле можно отобразить общую длину цепи. И ограничение.

Это значит, что можно не проносить эти параметры в интерфейс и меня вполне устроит вариант с общим ограничением. Только я поработаю над формулировкой чтобы дать игроку понять, что речь о конкретно текущем сегменте. И вообще постараюсь сделать всё более лаконичным.

Добавил конкретики, избавился от слова "длина". Словосочетание "не более" одновременно подчёркивает что речь именно о длине и говорит об ограничении.

Теперь нужно понять как всё это будет выглядеть когда ограничений нету. Что будет с процентами? И снова писать бесконечность у длины сегмента?

Можно было бы вообще ничего не писать. Но тогда был бы риск разрыва контекста, когда в определённом уровне вдруг появляются какие-то ограничения. А так сразу понятно что нагрузка цепи может быть не в норме и на сегменты могут накладываться ограничения. Игрок к этому заранее будет готов, что хорошо для паззлов.

Можно сделать ещё один завершающий штришок. В начале уровня, когда ни один сегмент не проведён, можно вместо "энергонагрузки цепи" сделать вот так:

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

Стоит помнить, что UX - это очень комплексная задача. И рассматривать интерфейс нужно не только в разных состояниях граничных значений его элементов, но и в разных состояниях контекста игрока. Чем чаще задавать вопрос "А что будет если...", тем больше случаев будет рассмотрено, тем более продуманным будет интерфейс, тем комфортнее игроку будет им пользоваться.

В реальных командных проектах строятся ux-flow карты, т.е. схемы переходов игрока к разным состояниям игры, которые часто подразумевают разные состояние интерфейса. Figma, кстати, позволяет не только строить такие карты, но и превращать их в кликабельные прототипы, отлаживая разные UX-маршруты. Но это всё тема для отдельной статьи. Пишите в комментариях если вам будет интересно про такое почитать.

Это был конкретный пример работы с текстами для конкретной игры, но рассмотренные задачи - достаточно типовые.

При работе над UI/UX интерфейса немаловажно уделить достаточно времени на анализ механик игры, чтобы понимать что отображать в интерфейсе. Это сильно поможет потом думать когда и как это отображать.

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

От формулировок текстов очень сильно зависит восприятие игрока. Неправильные тексты могут заруинить весь интерфейс. Хоть и бытует порой мнение UX-еров, что хороший интерфейс должен быть без текстов, но если тексты в нём правильно сформулированы и встроены в интерфейс, можно сэкономить на обучении игровым механикам. Интерфейс сам будет это делать.

Ещё больше про этот и другие мои проекты: