Найти в Дзене

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

Как происходит работа над игровым интерфейсом? Какие итерации он проходит от концепции на листке бумаги до готового окна в игре? Можно ли сделать первичный прототип без дизайнера по интерфейсам так, чтобы после верстки кровь не текла из глаз? Нужен ли художник для работы над UI? Как поставить задачу дизайнеру по интерфейсам?
Оглавление

Эту и другие статьи можно найти в моем блоге Вконтакте: https://vk.com/mistle_gamer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цвет

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

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

-2

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

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

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

-3

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

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

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

-4

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

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

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

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

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

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

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

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

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

Задача:

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

-6

Описание:

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

-7

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 силами самого геймдизайнера, если на проекте нет и не предвидится дизайнера интерфейсов. Такой интерфейс, в принципе, можно сразу нарезать и отправлять программисту на верстку прототипа. Если вы чувствуете уверенность в своем художнике, то прототип можно скомпоновать совместно с ним, стараясь сеять в нем интерес к макетированию интерфейсов. Помощь и квалифицированность художника в этом вопросе, будет для вас очень полезна в будущем.

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

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

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

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

Эту и другие статьи можно найти в моем блоге Вконтакте: https://vk.com/mistle_gamer