Как сделать интерфейс для игры
Создание интерфейса игры
В наше время люди научились ценить время и больше не хотят тратить десятки часов на изучение игры. Да, вы можете возразить: “А как же Day Z или Arma?” Безусловно, песочницы никуда не ушли, они нашли свою аудиторию. Однако по-настоящему массовые продукты уже давно не полагаются исключительно на графику. Если пользователь “разобьется” об недружелюбный интерфейс и замороченное управление, никакое обучение или гениальный сюжет уже не заставят его продолжать.
В этой статье преподаватели Высшей школы бизнес-информатики НИУ ВШЭ, авторы образовательных программ “Менеджмент игровых проектов” и “Основы создания игр”, расскажут о дизайне игровых интерфейсов для современных игр.
Разработка игрового интерфейса
Разработка интерфейса — один из наиболее важных этапов создания игры. Интуитивно понятный интерфейс позволяет игроку глубже погрузиться в геймплей. От качества интерфейса зависит количество удовольствия, которое получит пользователь во время игрового процесса.
В разработке принимают участие сразу несколько специалистов: геймдизайнер, дизайнер интерфейсов и художник по интерфейсам.
Советы по дизайну интерфейсов
Создание качественного игрового интерфейса требует соблюдения ряда психологических и фундаментальных (логических) принципов. Первые связаны с умственной работой и зрительным восприятием информации, а вторые отвечают за логичность структуры UI игры.
К числу психологических принципов относятся:
При в разработке UI с позиций фундаментальной логики должны соблюдаться следующие правила:
Как научиться дизайну интерфейсов
Хотите узнать, как правильно реализовать интерфейс для своего проекта, чтобы пользователя ничего не отвлекало от геймплея? ВШБИ НИУ ВШЭ в Москве приглашает всех желающих пройти обучение по программам “Основы создания игр” и “Менеджмент игровых проектов”. Во время лекционных и практических занятий вы познакомитесь со всеми аспектами разработки, а также узнаете все секреты создания качественных интерфейсов от профессионалов игровой индустрии.
Еще больше информации вы найдете на канале МИП ВШБИ на YouTube. Подписывайтесь и не пропускайте свежие записи с открытых мероприятий ВШБИ НИУ ВШЭ.
Дизайн интерфейса для игры, рисуем пак иконок
Я Михаил Кравченко, дизайнер игровых интерфейсов.
Это статья о том как нарисовать пак иконок для игры. Ниже вы видите результат.
Фиксируем требования к результату
Вот к нам прилетела задача примерно такого содержания. В игре начинается событие — вторжение расы пришельцев на нашу планету. Мы будем побеждать захватчиков, из них будут выпадать различные предметы, и эти предметы нужно нарисовать.
Первым делом нужно сформулировать и зафиксировать требования к результату, это фундамент нашей работы. Имея такие требования перед глазами, мы с меньшим шансом нарисуем не то что нужно, будем иметь намного больше взаимопонимания с заказчиком и командой, а также будет по чему проверить результат нашей работы.
Список требований нужно составить, опираясь на описание задачи и собственные представления о том как стоит эту задачу решить. Дальше нужно сходить с этим списком к заказчику и убедиться, что мы понимаем задачу одинаково. Возможно в списке нужно будет что-то поправить. В итоге получим список требований к результату.
Вот пример такого списка:
Референсы
Найдем предметы, которые уже были нарисованы для подобных событий. Нам нужно будет рисовать в том же направлении, и эти предметы помогут нам не сбиться с правильного пути.
Помимо этого мы должны изучить солдат армии вторжения. Наши предметы должны будут иметь с ними некоторые общие черты, поэтому стоит собрать побольше картинок с захватчиками и строить дизайн, опираясь на них.
Противники отличаются по своей силе — есть обычные, средние и сильные. Можно от этого оттолкнуться. Например, использовать части слабых противников в дизайне обычных предметов, а части сильных противников в дизайне более редких.
Палитра
Нам нужно будет нарисовать много иконок в одном стиле, работать будет намного удобнее, если мы сделаем единую палитру и тех. процесс покраски для всех предметов. Если же мы не сделаем палитру, а будем набирать цвет пипеткой с референса, скорее всего предметы разъедутся по цветам.
Подберем референсы для цветов из уже имеющихся в игре предметов. Наши противники — это раса растений, поэтому зеленый цвет вполне подойдет. А в качестве второго цвета можно взять золотой. Ниже вы видите картинки с референсами.
Теперь нужно собрать цвета с референсов и сделать из них палитру. Берем основной цвет, он
находится примерно посередине между светлыми и темными участками предмета, цвета для светлых и темных мест, цвета для бликов и особенно темных мест. А также цвет для рефлексов от окружающей среды. Получилось два набора цветов, один для золотой части, а второй для зеленой.
Подготовка закончена, переходим к наброскам.
Наброски
В процессе работы мы будем пробовать разные варианты дизайна предметов, а когда получим удовлетворяющий нас результат, согласуем его с заказчиком. От заказчика прилетят пожелания и предложения, какие-то из них помогут нам улучшить результат, другие мы обсудим и отбросим. Некоторые вещи в нашем дизайне окажутся не совсем подходящими и ряд моментов нужно будет поправить или переделать.
Важный момент
Если мы сразу сделаем работу в финальном качестве, на это уйдет значительное количество времени. Потом нас с большой вероятностью попросят что-то подправить или изменить, и совершенно точно не получится сделать это легко и быстро. Скорее всего нужно будет снова потратить значительное количество времени и сил.
Поэтому сперва делаем наброски. На набросок уходит мало времени и сил, при этом он позволяет в общих чертах показать, каким будет финальный результат. Значит мы быстро и дешево можем перебрать несколько вариантов дизайна, а если нас попросят что-нибудь исправить, с этим тоже не будет проблем.
Наброски начинаются с лайнарта. Лучше взять круглую кисть с параметрами Opacity и Flow в районе 30%, изменяющимися в зависимости от силы нажатия на перо. Перед глазами держим части противников, которые мы выбрали, чтобы показать редкость предметов, а также изображения бижутерии, которые уже есть в игре. Ищем подходящую форму для предметов, в процессе такого поиска можно перебрать несколько вариантов, ниже вы видите пример такого поиска.
Если какие-то элементы в вашем дизайне будут повторяться, имеет смысл завернуть их в смарт объекты. Вполне вероятно что со временем вы захотите в них что-то изменить, а поправить один смарт объект намного проще чем пройтись по всем местам, в которых использован элемент.
И вот лайнарт для всех предметов готов. Можно переходить к покраске. Ставим на видное место заготовленные палитры и картинки предметов-референсов для цветов.
Сперва нужно покрасить один предмет, чтобы убедиться что текущая палитра позволяет добиться нужного результата. И получить образец, опираясь на который мы сможем покрасить все остальные предметы.
Нельзя рисовать такой образец в одном слое потому, что в таком случае мы не сможем покрасить другие предметы так же. Поэтому каждый цвет из палитры добавляем в отдельном слое, чтобы иметь перед глазами процесс покраски и суметь повторить его когда будем красить остальные предметы.
Вполне вероятно что результат, который мы получим, нас не устроит и нужно будет слегка изменить цвета, чтобы он стал более подходящим. Как хорошо что каждый цвет у нас лежит на отдельном слое и можно править любой цвет отдельно от остальных. Если изменим цвета предмета-образца, нужно не забыть подправить те же цвета на палитре.
Вот образец для покраски готов, он нас полностью устраивает и можно также покрасить все остальные предметы.
Создаем маску по форме всех предметов, чтобы не вылезать за их края, делаем отдельные группы для золотой и зеленой части предмета, содержимое этих групп делаем таким же как в предмете-образце. Ниже показан процесс покраски одного предмета.
Еще у нас в задаче есть камни и у них бывают разные цвета — синий, желтый, зеленый и голубой. Чтобы получить необходимый результат, достаточно нарисовать набор камней, сделать три его копии, положить поверх них слой с режимом наложения Color и покрасить сердцевины камней в нужные нам цвета. Еще можно положить поверх слоя с режимом Color слой с режимом наложения Overlay и поэкспериментировать с покраской в нем, рисование в таком слое повышает контраст картинки и насыщенность цветов.
Вот у нас готовы наброски для всех предметов и можно переходить к следующему этапу — утверждению дизайна с заказчиком и коллегами.
Утверждение дизайна
Перед тем как показывать наброски заказчику, нужно где-то зафиксировать путь, которым мы пришли к такому решению и показать его вместе с набросками. Когда этот путь виден заказчику и коллегам, многие вопросы отпадают сами собой, и мы тратим намного меньше времени на объяснения. Для презентации такого пути хорошо подходит figma, или другой подобный онлайн сервис.
Покажем набросок заказчику. Вполне вероятно что он попросит поправить пару моментов, будем к этому готовы. Когда мы договорились с заказчиком, нужно показать результат коллегам и попросить их поделиться своим мнением о результате. Это стоит сделать по нескольким причинам.
Во-первых, коллеги могут заметить вещи, на которые мы не обратили внимания. Например, я однажды рисовал символ для нового класса и он хорошо подошел под описание задачи, но потом коллега, увидел тот символ и сказал, что символ один в один похож на логотип сервиса май таргет и из-за этого выглядит довольно странно. Я загуглил этот логотип, и оказалось что мой значок очень похож на него.
Во-вторых, у коллег могут возникнуть неприятные, или странные ассоциации с предметом. И если такие ассоциации возникли у одного человека, они вполне могут возникнуть у игроков, а вызывать у них негативные эмоции нам совсем не выгодно.
В-третьих, кто-то может вспомнить, что у нас в игре уже есть подобные предметы, и если добавить к ним еще один почти такой же, это запутает игрока.
То есть проверка результата с помощью коллег помогает нам избежать некоторых ошибок, или по крайней мере снизить шансы на их появление.
Пример работы с обратной связью от коллег
Ниже показан пример работы с комментариями коллег.
Комментарий 01
Форма камней почти такая же как у другой расы вторжения.
Смотрим на все камни и видим, что у разных рас камни разной формы, и наши камни действительно похожи по форме на камни другой расы.
Меняем форму камней.
Комментарий 02
Такая форма сердцевины камня дает ассоциации с какими-то болезненными опухолями, что делает предмет не привлекательным.
Если такая ассоциация появилась у одного человека, можно предположить, что появится и у других. Нужно придумать еще что-то.
Комментарий 03
Надо поправить сердцевину среднего камня — он похож на аналогичный у камня демонов.
Смотрим на камни расы демонов, видим что камни сильно отличаются и текущий вариант подходит, а автор комментария ошибается.
Комментарий 04
Есть предложение увеличивать центральную часть камня в зависимости от степени его редкости.
Звучит логично, попробуем.
Получилось неплохо, оставим так.
Комментарий 05
Брошь слишком походит на просто оторванную верхнюю часть от колец. Мб им нужна какая-то подложка или иная форма.
Действительно похоже, может запутать человека, меняем форму зеленой части.
Комментарий 06
Теперь брошь отличается от кольца, но начинает походить на амулет. Можно усилить их различие.
Сравниваем предметы, усиливаем различие, сделав золотую часть более массивной.
Важный момент
Чтобы быстрее править наброски, можно скопировать группу с ними и схлопнуть ее в один слой, хоткей — Ctrl + E. Правки вносить в получившемся слое, а копию группы с тех. процессом покраски сохранить на потом. Она понадобится когда нужно будет рисовать предметы в финальном качестве.
И вот мы утвердили наброски предметов — все со всем согласны и можно перейти к чистовой отрисовке предметов.
Чистовая отрисовка
Самое главное на этом этапе — соблюсти единый тех. процесс отрисовки для каждого предмета. В этом случае все предметы будут нарисованы одинаково и ни один не будет выбиваться из общего стиля. Для ускорения процесса можно рисовать в векторе, в масштабе 100% от необходимого. Основные формы выводить пером, а потом создавать слой поверх, превращать его в Clipping Mask и закрашивать нужные области мягкой кистью. Хоткей на Clipping Mask — Ctrl + Alt + G. На картинке ниже показан процесс покраски части предмета.
Вот все предметы готовы и их можно показать заказчику и команде.
Скорее всего здесь будет минимум пожеланий и комментариев так как мы уже обо всем договорились на этапе набросков.
После того как предметы будут утверждены, нужно их сохранить в нужном формате. Очень рекомендую разметить документ с помощью Slice tool и дать название каждой ячейке. А потом сохранить все предметы разом через функцию Save for Web. Это очень удобно.
Надеюсь эта статья была вам полезна. Желаю всем удачи и творческих успехов.
Особенности создания интерфейса для мобильной игры Статьи редакции
Принципы и правила работы с небольшими экранами.
При создании интерфейсов для мобильных игр разработчикам порой приходится идти на компромиссы из-за относительно небольших дисплеев. И речь не только о размерах иконок и окон или об их расположении.
Ведущий UX и UI-дизайнер студии Azur Games Екатерина Кузьмичёва написала для DTF колонку об основных принципах, которыми следует руководствоваться при создании интерфейса для мобильной игры и о том, на что нужно обращать внимание.
Создание любого интерфейса предполагает комплексную работу с несколькими аспектами: с UX, со стилистикой, с синтаксической структурой, с эргономичностью, с логичностью и многими другими. В этой статье я хочу рассказать об особенностях UI мобильных игр, а также о том, как решаются характерные для этого вида интерфейсов проблемы.
Проектирование интерфейса f2p-игры осложняется тем, что разработчики часто не знают обо всех потенциальных фичах проекта. Развитие игры предполагает приобретение новых функций, о которых неизвестно на начальных этапах проектирования. Именно поэтому очень важно подготовить свой UI к масштабированию.
Мобильная игра — это всегда небольшой размер экрана. В работе приходится подстраиваться под разнообразие этих экранов, которое предлагает мобильный рынок. Хочется угодить каждому производителю, чтобы игрокам было комфортно при наличии любого мобильного устройства. И именно этот фактор является сильным ограничителем в подходе UI-дизайнера к работе.
Проектирование UI — это комплексный процесс, в который вовлечены специалисты разного профиля: информационные архитекторы, художники, верстальщики, собственно UI-дизайнеры, тестировщики. Этот процесс имеет сложности, типичные для каждой из упомянутых специальностей. Но факт проектирования UI мобильной игры сильно осложняется двумя вещами:
Реальность такова, что при работе с небольшим экраном мы имеем условно маленький диапазон (по сравнению с десктопными играми) вариантов размера и возможностей расположения элементов. Эргономическая составляющая диктует некоторым элементам UI находиться в определённом месте и быть определенного размера.
Помните мультфильм о купце, который принёс портному маленькую меховую шкурку с просьбой сшить из неё шапку? Потом он вошёл в свой купцовый раж и начал просить сшить две, три, нет семь (!) шапок из всё той же шкурки.
Этот сюжет я пересказываю коллегам и называю его «Притча о юайщике», потому что вижу сходство ситуаций. В мультфильме всё закончилось бодрым нравоучением о том, как плохо быть жадным. В работе UI-дизайнера вводные данные — это условная маленькая шкурка с большим ожиданием. Примерно так воспринимается эта сложная задача и её решение.
Ключевым принципом является подход: «Одна пользовательская задача — один экран». Этот принцип не нов, но я пишу о нём, поскольку до сих пор встречаются трудности его воплощения. Главным препятствием является нежелание прятать некоторые функции «далеко», за дополнительные клики. Есть риски, что эти клики так и не будут совершены. Кроме того, понятие «одна пользовательская задача» не всегда однозначно определимо. То, что является одной задачей для одного человека, может дробиться на несколько других.
И если мы понимаем, что на нашем экране будет чуть больше, чем одна пользовательская задача, то нужно максимально удобно и логично организовать пространство экрана. В этом помогает понятие зонирования — определение внешнего вида фрагментов UI (зон) со сходными функциями и принципы сочленения этих зон.
Зоны, определённые проектировщиком, должны организовываться на экране в соответствии с тем, какова выбранная ориентация устройства — портретная или пейзажная. Идея «у нас много вертикали, но мало горизонтали» (или наоборот) определяет работу проектировщика интерфейса на глобальном уровне. Картинка ниже иллюстрирует подобную стратегию расположения элементов UI.
Иногда встречаются мобильные игры в пейзажной ориентации, которые «считают» себя играми в портретной ориентации — именно так там организован контент.
Не стоит забывать пользоваться пространством за пределами экрана. К нашим услугам всевозможные слайд-панели. Информация на них должна обладать определённым свойством — быть необходимой ситуативно, по требованию. При обращении к этой информации пользователь никуда не перемещается, а значит продолжает находиться в том же контексте, что и был.
Ещё один принцип проектирования интерфейса мобильной игры звучит как жесткий императив — «ни одного лишнего элемента на экране». До сих пор находится огромное количество мобильных игр с элементами UI, не делающими собственно для UI ничего.
Среди доводов в защиту подобных завитков можно услышать «это стилистика, завитушка принесла атмосферу фэнтези». Да, резонно, но в условиях решения сложной задачи по приобретению пространства приходится быть требовательнее к элементам на экране.
Носители стилистической идентичности могут в то же самое время выполнять ещё какую-либо задачу, то есть «работать на двух работах». Например, завиток фэнтезийного типа одновременно разбивает пространство на зоны, или «сай-файное свечение» на одних элементах даёт понять, что эти элементы кликабельны в отличие от элементов без свечения. Поместить завиток ради завитка — непозволительная роскошь в условиях работы над интерфейсом мобильной игры.
Тезис «ни одного лишнего элемента на экране» не исчерпывается лишь крестовым походом против условных завитков. Убирание лишних элементов иногда может касаться даже не собственно элементов, а расстояний между ними. Вообще, пространство между элементами — это то, о чём следует думать не меньше, чем над самими элементами. Качество восприятия сложносоставных объектов определяется тем, сколько воздуха в них.
Получается некое противоречие, ведь мы знаем, что пространство мобильного экрана невелико, но хорошие воздушные отступы между элементами положительно сказываются на их читабельности. Возможным решением может показаться уменьшение самих элементов. Но это действие под запретом — мельчить на экране мобильного устройства нельзя.
Первое, что стоит сделать для решения задачи приобретения пространства — это внимательно изучить свои элементы. Если какая-либо информация появляется на экране более одного раза, почти наверняка она может быть вынесена за скобки.
Проверьте: если сложносоставной объект представлен последовательностью элементов, то нет ли возможности какой-либо из этих элементов переформулировать и представить его другим образом?
Выше описаны разумные способы приобретения пространства, интуитивно понятные многим проектировщикам. Теперь настала очередь «читерских». Главное условие их использования — ювелирность исполнения. И постоянное отслеживание воплощения на всех стадиях разработки, поскольку в командной работе всегда происходят коммуникационные потери. И есть опасность осуществления сценария «ювелирность + коммуникационные потери = топорность».
Наложение элементов друг на друга — своего рода использование третьего измерения экрана. Подобный приём не может быть применён к элементам, клики на которые обрабатываются отдельно. Здесь важно определить внешний вид каждого из участников наложения таким образом, чтобы они не мешали друг другу. Например, кто-то из них всегда тёмный, кто-то светлый.
Ещё одно использование третьего измерения экрана — «отступы без отступов». Здесь мы пользуемся способностью человеческого мозга самостоятельно дорисовывать образ.
Ходовая единица проекта, многократно встречающаяся в определённом размере, может быть порезана маской сверху-снизу (слева-справа) для какого-то конкретного окна. Её узнаваемость сохранилась: для пользователя это ровно та же самая картинка. Возможная альтернатива этому действию — пропорциональное уменьшение — иногда рискует потерять в площади клика и в целом выглядеть неприглядно.
Итак, перечислим последовательно стратегии, помогающие преодолеть трудности с небольшими экранами.
Если разработчик UI мобильного проекта грамотно распоряжается своим экранным пространством, то он приобретает большую свободу в других аспектах.
Основной геймплей вашего проекта — это сердцевина, которая может обрасти метагеймплейными фичами в каком угодно количестве. В этом заключается суть развития проекта. И каждая вводимая фича должна органично вписываться в имеющуюся систему, быть её логичным продолжением.
Можно выделить четыре группы стратегий, помогающих работать над UI растущих проектов.
Представьте, что вы работаете над UI игры какого-то определённого жанра. Если это не первая в мире игра-представитель этого жанра, то у вас есть великолепная возможность ознакомиться с играми-предшественниками. И почти наверняка большая часть фичей из этих игр будет и у вашей игры. А это значит, что на начальном этапе проектирования своего UI вы сразу учитываете всю сумму этих фичей. Отсюда и название этой стратегии — «Хрустальный шар», вы заглядываете в будущее и готовитесь к нему.
В каком-то смысле любая разработка придерживается стратегии предсказывания фичей, ведь существуют планирование и дорожные карты. Но при работе с UI это предсказывание должно стать очень конкретным. Вплоть до того, что вы размещаете в своих макетах прототипы пока ещё несуществующих фичей, резервируете для них место. И чтобы не запутать самого себя и ваших коллег, чётко разграничивайте актуальные на данном этапе сущности от тех, которые появятся потом.
Разумеется, наступившее будущее будет не таким, каким вы его ожидали. Потому что рабочие процессы внесут свои коррективы, некоторые фичи так и не будут введены. Но ваша подготовленность в любом случае облегчит вам работу.
Если новые функции структурно похожи на уже имеющиеся, пользователю будет легче в них освоиться. Его внутренний диалог «а, я понял, здесь всё работает так же, как в мастерской» (например) — это хороший шаг на пути к пониманию. То есть при проектировании UI новой фичи не стоит изобретать велосипед — лучше воспользоваться имеющимся решением.
А это значит, что нужно иметь некоторое количество шаблонов, с помощью которых генерируются новые макеты. В идеале, услышав от продюсера описание фичи, UI-дизайнер сразу представляет, каким конкретно шаблоном он воспользуется.
Но работая с шаблоном не стоит забывать и о «разрыве шаблона». Стройные ряды однотипных окон могут сыграть с вами злую шутку, ваши фичи могут потерять свою индивидуальность. Поэтому после того, как вы воспользовались конкретным шаблоном, подумайте о том, что станет отличительным маркером этого фичи, её изюминкой.
Важность ведения гайдов сложно переоценить — это альфа и омега дизайнерских процессов. Но также это и необходимый участник масштабирования, поскольку в нем задокументированы правила расширения проекта.
Хороший гайд знает всё о крайних случаях, о пустых или слишком длинных списках. В хорошем гайде наглядно показаны все возможные сочетаемости всех элементов и все возможные состояния всех элементов. В общем, гайд знает ответы на все вопросы.
Но этот всемогущий гайд не отлит в чугуне и не возвышается на пьедестале. Он создаётся по принципу прецедента, то есть время от времени обновляется с появлением новых функций в вашей игре.
Если однажды в вашей игре появятся кланы, чат, сезонные распродажи и тематические ивенты, нужно, чтобы пользователь смог туда пройти.
Потенциально мест, куда может захотеть переместиться пользователь, бесконечно много, поэтому нужен «бесконечный коридор». Конечность экрана кажется проблемой на пути решения этой задачи.
Чтобы преодолеть эту проблему мы можем:
Расширить экран с помощью свайпа. В игре «Star Wars Галактика героев» в центральной части главного экрана установлены объекты для взаимодействия, являющиеся по сути пунктами меню. Естественное движение свайпа обеспечивает быстрый доступ к этим пунктам.
Спроектировать сквозные переходы. Это актуально для смежных по смыслу фичей. Вообще если в какое-то окно пользователь может попасть строго через одну дверь, то это не очень хорошо для юзабилити. Если конечно речь не идёт о парадной двери.
Самое главное в процессе создания любого UI — это своевременный контакт с потенциальным пользователем. Очень важно на каждой из стадий разработки получать фидбек чтобы убедиться, что вы не увлеклись упрощением и ничего не потеряли.
Делать UI мобильных игр сложно. Часто нужно учитывать большое количество параметров и удовлетворять большому количеству условий. И иногда это взаимоисключающие условия. Надеюсь, что описанные в этой статье стратегии помогут другим разработчикам при проектировании UI.