Процесс работы над игровым интерфейсом

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

1. Концепция геймдизайнера

После того, как была написана документация для базового функционала игры, можно начинать разработку игрового интерфейса. Как правило, она идет параллельно с созданием первого прототипа игры - ведь даже с прототипом нужно как-то взаимодействовать. Для того, чтобы дизайнер интерфейсов мог приступить к своей части, ему нужно получить подробное ТЗ на UI от геймдизайнера. Такое ТЗ, как правило, состоит из:

• макета интерфейса (можно сделать через инструмент “рисунок” в обычном Google документе, или просто сфотографировать схему, нарисованную от руки на бумажке);
• краткого описания основных игровых задач интерфейса, ключевых нюансов для игрока;
• сносок с пояснением для каждого элемента и каждой кнопки на макете интерфейса;
• детального описания функционала интерфейса, которое является описанием технических возможностей тех или иных элементов, а также их отклика на взаимодействие;
• реакция, которой отвечает игра на нажатие на ту, или иную кнопку (автоматическое закрытие окна, переход в другое окно, сдвиг панелей, подсвечивание и прочее);
• нередко — ссылки на документы с описанием механики, если окно представляет собой активно участвующую в геймплее структуру (например, интерфейс крафта или улучшения каких-либо предметов: по факту прямо в окне апгрейда происходит игровой процесс).

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

Пример задачи для дизайнера интерфейсов ищите в конце статьи.

2. Макет дизайнера интерфейсов

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

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

Что же делать, если у вас маленькая команда и нет дизайнера интерфейсов?

Придется поднапрячься, вооружиться советами из вот этой статьи, и взять на себя эту роль самому геймдизайнеру. Лично я неоднократно занималась созданием макетов интерфейсов, которые потом вставлялись в игру для тестирования механик и юзабилити. Здесь мой совет будет довольно субъективным и дилетантским, я поделюсь способом, который мне всегда помогал, несмотря на то, что, возможно, есть тулзы получше и попроще. Я всегда пользовалась для создания макетов UI программой Adobe Illustrator: скачивала бесплатные векторные иконки и кнопки, и с их помощью собирала относительно приятный для глаза интерфейс. Мне нравится, что с Иллюстратором легко работать - он довольно простой, интуитивно понятный и его самых примитивных функций с головой хватает для того, чтобы сделать красивый заглушечный интерфейс с правильными размерами и пропорциями.

Сайты, где можно скачать векторы с бесплатной лицензией, легко гуглятся в интернете, но я докину пару ссылок:

• Freepic
• Vecteezy
• All Free Download

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

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

3. Верстка интерфейса программистом

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

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

4. Разработка визуальной части и стиля

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

Цвет

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

Для примера, в Dishonored 2 основной цвет — это серо-черно-синие тона в сочетании с холодным бело-голубым.

Основные художественные элементы

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

В Dishonored 2 основные художественные элементы — это полупрозрачные текстуры на плашках, вензельки, треугольники-осколки и пятна “крови”. Классическая викторианская готика с острыми и мрачными вкраплениями.

Основные формы

Какие формы будут преобладать в вашем интерфейсе? Круглые прогресс-бары и иконки, или может быть прямоугольники со скругленными углами? Будут элементы полупрозрачными? Объемными, или плоскими?

В Dishonored 2 наблюдается стройное единство форм. Почти все они — это четкие прямоугольники и квадраты с острыми краями в сочетании с ровными кругами.

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

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

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

5. Внедрение финального интерфейса в игру.

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

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

6. Тестирование интерфейса.

Я знаю, что существует довольно много методик тестирования интерфейса, таких как фиксирование движения глаз игрока и составление карты экрана, аналогичной снимку тепловизора; запись всех нажатий на экран; анкетирование и последующий анализ полученных данных. Иными словами, разного рода работа с фокус-группами. Лично я никогда не сталкивалась с подобными масштабными исследованиями, потому что они обычно довольно сложные, большие и проводятся крупными компаниями для крупных проектов. Если это ваша ситуация, то вы можете дать поиграть друзьям и коллегам, составляющим приблизительную ЦА игры, и понаблюдать за их действиями из-за спины с тетрадочкой, записывая для себя все спорные моменты. Как более продвинутый вариант — лучше будет попросить вашу “фокус-группу” делать запись экрана во время игры, а затем коллективно смотреть, как много игроков не находят ту или иную кнопку, либо игнорируют ту или иную функцию. Если вы видите, что какие-то ошибочные паттерны повторяются у игроков из раза в раз, то скорее всего вы где-то допустили ошибку и стоит еще подумать над функциональностью причастных к этому элементов интерфейса.

Пример задачи для художника по интерфейсам

Задача:

Отрисовать главный экран игры

Описание:

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

1 - Портрет героя игрока, генерируется автоматически исходя из внешнего вида персонажа, созданного при старте игры.
2 - Никнейм персонажа (указать максимальное количество символов).
3 - Иконка гильдии персонажа, название гильдии. Если игрок не состоит в гильдии, это поле будет пустым. Одновременно персонаж может состоять только в одной гильдии.
4 - Уровень игрока. На данный момент максимальный уровень игрока - 99 (но можно заложиться под трехзначное число).
5 - Прогресс бар с показателем заработанного опыта и количества опыта до следующего уровня (нужно подумать, стоит ли загружать эту часть цифрами с текущим цифровым показателем опыта и количеством, необходимым до следующего уровня).
6 - Кнопка перехода в окно с журналом заданий. По тапу на кнопку открываем окно с журналом заданий. Если у игрока есть новые задания, или задания, за которые игрок может собрать награду, на кнопке должна отображаться соответствующая индикация.
7 - Название большой локации, на которой находится игрок (указать максимальное количество символов).
8 - Точное название территории, на которой находится игрок (территория в подназвании является частью большой территории из главного названия).
9 - Иконка перехода в окно разблокированных игроком портовых городов. Каунтер на иконке вида 1/99, где 1 - количество открытых игроком городов, а 99 - общее количество городов на данной территории.
10 - Иконка перехода на общую карту большой локации. Каунтер на иконке вида 1/99, где 1 - количество открытых игроком территорий, а 99 - общее количество территорий на данной большой локации.
11 - Кнопка перехода в окно персонажа. По тапу открываем окно героя.
12 - Кнопка перехода в окно премиум-магазина. По тапу открывается окно премиум-магазина. Нужно сделать отличающимся от основных кнопок цветом. Если в окне премиум-магазина появились новые предложения, кнопка должна быть заанимирована (слегка подрагивать, поворачиваясь из стороны в сторону).
13 - Кнопка перехода в окно гильдии. Если игрок состоит в гильдии - открывает окно списка членов гильдии. Если игрок не состоит в гильдии, по данной кнопке он переходит в окно поиска доступных гильдий (надо подумать, нужны ли разные иконки для этих двух случаев).
14 - Кнопка перехода на стартовый игровой экран.
15 - Каунтеры валют: Премиум валюта, Золото, Энергия. На данный момент максимальное число Премиум валюты и Золота - шестизначное, Энергии - четырехзначное. Если в дальнейшем эти числа увеличатся, нужно будет сдвигать каунтеры влево.
16 - Иконки пройденных игроком битв на карте территории. В зависимости от качества прохождения, игрок может пройти битву на 0, 1, 2 и 3 звезды. Нужно продумать, как показывать “пустые”, незаработанные звезды (если игрок прошел на 2/3 звезд, например). По тапу на иконку битвы открывается попап входа в битву.
17 - Предстоящие, не пройденные игроком битвы. Нужно сделать сами иконки другого цвета. По тапу на иконку битвы открывается попап входа в битву.
18 - Линия прогресса (продвижения по территории). Представляет собой путь игрока, на ней будут располагаться все битвы территории Будет рисоваться программно, нужен тайлящийся паттерн из нескольких точек и прочерков.
19 - Рисованный бэк: картинка, которая будет подкладываться под интерфейс. Зажимая и сдвигая в сторону бэк, игрок может перемещать камеру по карте территории.

Пожелания по интерфейсу:

• Разделить визуально по стилю нижние кнопки ХАДа, кнопки на экране и верхние кнопки хада в соответствии с их геймплейной важностью: на первом месте - нижние кнопки (11-14), на втором — журнал заданий (6), а третьем — кнопки на карте (9-10).
• Постараться сделать цветовое оформление максимально простым, обойтись простыми градиентами и заливками - на экране и так много информации.
• Сделать декоративные элементы (ленточки и подложки) максимально тайлящимися.

В реальности в качестве референса для постановки задачи дизайнеру интерфейсов можно было бы обойтись рисунком на листке бумаги, или обычным рисунком из плоских квадратиков в документах Google. Также при упоминании в описании других окон, желательно давать ссылки на ТЗ по ним тоже. Выше я скомпоновала пример того, как можно собрать интерфейс из готовых векторных элементов в Adobe Illustrator силами самого геймдизайнера, если на проекте нет и не предвидится дизайнера интерфейсов. Такой интерфейс, в принципе, можно сразу нарезать и отправлять программисту на верстку прототипа. Если вы чувствуете уверенность в своем художнике, то прототип можно скомпоновать совместно с ним, стараясь сеять в нем интерес к макетированию интерфейсов. Помощь и квалифицированность художника в этом вопросе, будет для вас очень полезна в будущем.

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

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

Зачем хранить ТЗ после завершения работы над интерфейсом?

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