Детские болезни игровых интерфейсов

6.
Опора на стандартные интерфейсные модели

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

Интерфейс обмена

В качестве первого примера, рассмотрим диалог "Лавка заклинаний" из игры "Демиурги" (Etherlords). Подключившись к коллективу разработчиков игры на стадии завершения бета-версии, мы столнулись со сложной задачей – улучшить понимаемость и удобство интерфейсов, не меняя их сколь-нибудь радикально.

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

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

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

При проектировании аналогичного диалога для игры "Демиурги II" мы сделали еще два шага. Во-первых, убрали визуальный шум, который изрядно запутывал (например, в изначальном диалоге отдельные группы элементов, принадлежащих герою, были отделены графически сильнее, чем Герой в целом от элементов Лавки). Во-вторых, для перемещения заклинаний реализовали механизм drag-n-drop, который для этих целей наиболее удобен.

---

Дерево и Мастер

Другая задача, с которой мы сталкнулись в работе с "Демиургами", касалась разработки принципиального нового Приложения для локализации игры. Забота была нешуточной – предстояло перевести изначально англоязычную игру на множество (как выснилось в конечном итоге – на 12) языков. А доставшийся в наследство от предыдущей игры Localization Kit, реализованный средствами Microsoft Access, был не слишком удобен.

Проблем было несколько. Во-первых, прежний ELK почему-то пугал неподготовленных пользователей (каковым и будет всегда основной потребитель ELK – переводчик) – пугал настолько, что преводчики отказывались с ним работать. Во-вторых, невозможно было быстро определить общее состояние дел с переводом. В-третьих, неумение удобным способом отслеживать изменения и дополнения, вносимые в тексты и их переводы, приводило к тяжелейшей работе по распутыванию возникающих коллизий.

Стартовое окно прежнего ELK было внешне достаточно простым. Рамкой "Edit" выделены все ресурсы игры, которые нужно переводить (правда, попытка заранее угадать, в чем разница между "Simple 1 line resources" и "Simple 2 line resources" наверняка поставит переводчика в тупик). Однако, сразу видны существенные проблемы: как увидеть общий объем работы, текущее состояние локализации и отличия текущей версии от предыдущей?

Заходим в раздел "Simple 2 line resources". Опять же, вроде все нормально – есть поля с исходным текстом, есть поля для вписывания перевода – сиди себе и работай. Можем попытаться предсказать, что не понравится пользователю. Во-первых, смутит список "Type" – что означают все эти сокращения в программистском стиле? Во-вторых, все еще никакой ясности с количеством работы – что означает сообщение в строке состояния: Record 1 of 1399 (Filtered)? Чем (где выбор фильтра) и из чего filtered (из всех ресурсов, из "2 line" ресурсов, из "2 line" ресурсов типа ALLOD)?

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

Наиболее простой способ принудить пользователя выполнить заданную последовательность действий (обновить ресурсы после получения новой версии ELK, перевести новые элементы, создать окончательные игровые текст-ресурсы) – навязать ему т.н. Мастер-интерфейс (Wizard), то есть набор экранов, последовательно сменяющих друг друга по мере выполнения шагов-заданий. Стремясь, однако, избегнуть неприятной дидактичности и негибкости Мастера, мы задали порядок действий, расположив шаги на последовательных закладках.

Остается лишь подправить заголовок нашей истории (слегка усилив его восточный аромат): "Цветущее Дерево и гибкий Мастер" – так будет точнее.

Читать дальше >>