Сознательное дилетантство в дизайне интерфейсов

• 09 февраля, 2015
• 2 комментария

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

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

Работу интерфейса можно разделить на следующие функции:
1) Предоставление игроку информации о текущем состоянии системы, о его возможностях и ожидаемых последствиях.
Пример: Перед игроком два врага. У одного 5 единиц здоровья, у другого — 8 единиц. У игрока есть возможность бить мечом, нанося 6 единицы урона за удар.

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

ММО — это просто и понятно. Какая же статья про интерфейсы без этой картинки.

2) Дать игроку возможность принять решение.
Пример: При клике на монстре персонаж игрока атакует его мечом.

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

3) Дать мгновенную обратную связь, подтвердив, что решение игрока принято к исполнению.
Пример: Персонаж игрока практически моментально замахнулся мечом, а затем проиграл быструю анимацию атаки.

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

4) Сообщить игроку о последствиях его решения.
Пример: Отыгралась анимация удара. Проигрался эффект попадания. Монстр закачался и упал.

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

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

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

Для начала обратим внимание, что у монстров разное значение здоровья, то есть они разные. Значит они должны визуально выглядит по-разному. Игроки только спасибо скажут, если мы не будем выдавать одну и ту же картинку за двух разных монстров.

Дальше у нас есть значения здоровья и значения урона. Но зачем их нужно знать игроку? Чтобы он мог посчитать сколько ударов нужно нанести, чтобы победить монстра. Так может лучше ему сообщать эту информацию о количестве необходимых ударов, а не заставлять играть калькулятор. Но как сообщить игроку эту информацию? Да проще некуда. Просто дать ему несколько раз сразится с этим типом монстров, чтобы он запомнил, сколько ударов требуется для победы.

Конечно, это всё сильное упрощение. Не должно быть разброса в значениях урона. Рядовые противники не должны быть уникальными. Каждое новое оружие — это событие для игрока, ведь оно должно заметно влиять на ход боя, а значит не может быть арсенала из миллиона похожих друг на друга мечей.

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

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

Эволюция HUD (Head-up Display) в шутерах. Doom 2. 1994 год.

Эволюция HUD в шутерах. Call of Duty: Advanced Warfare. 2014 год.

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

* Monument Valley
* Limbo
* Portal 1, 2
* Journey
* Flower
* Gone Home
* The Vanishing of Ethan Carter
* Anmesia
* Another World
* Brothers: A Tale of Two Sons