Особенности создания интерфейса для мобильной игры

Принципы и правила работы с небольшими экранами.

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

Ведущий UX и UI-дизайнер студии Azur Games Екатерина Кузьмичёва написала для DTF колонку об основных принципах, которыми следует руководствоваться при создании интерфейса для мобильной игры и о том, на что нужно обращать внимание.

Особенности создания интерфейса для мобильной игры

Особенности интерфейса мобильных игр

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

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

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

Проектирование UI — это комплексный процесс, в который вовлечены специалисты разного профиля: информационные архитекторы, художники, верстальщики, собственно UI-дизайнеры, тестировщики. Этот процесс имеет сложности, типичные для каждой из упомянутых специальностей. Но факт проектирования UI мобильной игры сильно осложняется двумя вещами:

  • маленький размер экрана;
  • большое количество потенциальных фичей.

Маленький размер экрана

Реальность такова, что при работе с небольшим экраном мы имеем условно маленький диапазон (по сравнению с десктопными играми) вариантов размера и возможностей расположения элементов. Эргономическая составляющая диктует некоторым элементам UI находиться в определённом месте и быть определенного размера.

Помните мультфильм о купце, который принёс портному маленькую меховую шкурку с просьбой сшить из неё шапку? Потом он вошёл в свой купцовый раж и начал просить сшить две, три, нет семь (!) шапок из всё той же шкурки.

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

Правильно зонируйте

Ключевым принципом является подход: «Одна пользовательская задача — один экран». Этот принцип не нов, но я пишу о нём, поскольку до сих пор встречаются трудности его воплощения. Главным препятствием является нежелание прятать некоторые функции «далеко», за дополнительные клики. Есть риски, что эти клики так и не будут совершены. Кроме того, понятие «одна пользовательская задача» не всегда однозначно определимо. То, что является одной задачей для одного человека, может дробиться на несколько других.

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

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

Соответствуйте выбранной ориентации устройства

Зоны, определённые проектировщиком, должны организовываться на экране в соответствии с тем, какова выбранная ориентация устройства — портретная или пейзажная. Идея «у нас много вертикали, но мало горизонтали» (или наоборот) определяет работу проектировщика интерфейса на глобальном уровне. Картинка ниже иллюстрирует подобную стратегию расположения элементов UI.

Особенности создания интерфейса для мобильной игры

Иногда встречаются мобильные игры в пейзажной ориентации, которые «считают» себя играми в портретной ориентации — именно так там организован контент.

Игра <a href="https://itunes.apple.com/us/app/gladiator-heroes-clans-clash/id1061896024?mt=8" rel="nofollow noreferrer noopener" target="_blank">Gladiator Heroes Clash</a>. Структурные блоки окна складываются друг под другом, что было бы естественным при наличии большего количества места по вертикали
Игра Gladiator Heroes Clash. Структурные блоки окна складываются друг под другом, что было бы естественным при наличии большего количества места по вертикали

Используйте пространство за пределами экрана мобильного устройства

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

Тут важно не забывать о слайд-панелях самой ОС и не конфликтовать с ними
Тут важно не забывать о слайд-панелях самой ОС и не конфликтовать с ними

Количественный минимализм

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

Игра «<a href="https://itunes.apple.com/ru/app/%D0%B2%D0%B5%D0%BB%D0%B8%D0%BA%D0%B8%D0%B9-%D1%81%D1%83%D0%BB%D1%82%D0%B0%D0%BD/id1372638631?mt=8" rel="nofollow noreferrer noopener" target="_blank">Великий Султан</a>». Разработчики предпочли сократить заголовок, но сохранить завитки
Игра «Великий Султан». Разработчики предпочли сократить заголовок, но сохранить завитки

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

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

Тезис «ни одного лишнего элемента на экране» не исчерпывается лишь крестовым походом против условных завитков. Убирание лишних элементов иногда может касаться даже не собственно элементов, а расстояний между ними. Вообще, пространство между элементами — это то, о чём следует думать не меньше, чем над самими элементами. Качество восприятия сложносоставных объектов определяется тем, сколько воздуха в них.

Таблица слева воспринимается гармоничнее, чем таблица справа
Таблица слева воспринимается гармоничнее, чем таблица справа

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

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

Текстовая информация, превратившись в графическую, освободила место
Текстовая информация, превратившись в графическую, освободила место

Проверьте: если сложносоставной объект представлен последовательностью элементов, то нет ли возможности какой-либо из этих элементов переформулировать и представить его другим образом?

Выше описаны разумные способы приобретения пространства, интуитивно понятные многим проектировщикам. Теперь настала очередь «читерских». Главное условие их использования — ювелирность исполнения. И постоянное отслеживание воплощения на всех стадиях разработки, поскольку в командной работе всегда происходят коммуникационные потери. И есть опасность осуществления сценария «ювелирность + коммуникационные потери = топорность».

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

Вкладка «Избранное» не подразумевалась на начальном этапе разработки. Из-за невозможности удлинить таббар мы воспользовались глубиной экрана
Вкладка «Избранное» не подразумевалась на начальном этапе разработки. Из-за невозможности удлинить таббар мы воспользовались глубиной экрана

Ещё одно использование третьего измерения экрана — «отступы без отступов». Здесь мы пользуемся способностью человеческого мозга самостоятельно дорисовывать образ.

Особенности создания интерфейса для мобильной игры

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

Особенности создания интерфейса для мобильной игры

Итак, перечислим последовательно стратегии, помогающие преодолеть трудности с небольшими экранами.

  • Зонирование.
  • Соответствие выбранной ориентации устройства.
  • Пространство за пределами экрана мобильного устройства.
  • Количественный минимализм.

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

Большое количество потенциальных фичей

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

Можно выделить четыре группы стратегий, помогающих работать над UI растущих проектов.

  • «Хрустальный шар».
  • Стандарты и шаблоны.
  • Гайд.
  • Навигационная свобода.

«Хрустальный шар»

Представьте, что вы работаете над UI игры какого-то определённого жанра. Если это не первая в мире игра-представитель этого жанра, то у вас есть великолепная возможность ознакомиться с играми-предшественниками. И почти наверняка большая часть фичей из этих игр будет и у вашей игры. А это значит, что на начальном этапе проектирования своего UI вы сразу учитываете всю сумму этих фичей. Отсюда и название этой стратегии — «Хрустальный шар», вы заглядываете в будущее и готовитесь к нему.

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

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

Стандарты и шаблоны

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

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

Но работая с шаблоном не стоит забывать и о «разрыве шаблона». Стройные ряды однотипных окон могут сыграть с вами злую шутку, ваши фичи могут потерять свою индивидуальность. Поэтому после того, как вы воспользовались конкретным шаблоном, подумайте о том, что станет отличительным маркером этого фичи, её изюминкой.

Имеющийся шаблон позволяет генерировать новые окна, но с уточнениями
Имеющийся шаблон позволяет генерировать новые окна, но с уточнениями

Гайд

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

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

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

Фрагмент гайда
Фрагмент гайда

Навигационная свобода

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

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

Чтобы преодолеть эту проблему мы можем:

Расширить экран с помощью свайпа. В игре «Star Wars Галактика героев» в центральной части главного экрана установлены объекты для взаимодействия, являющиеся по сути пунктами меню. Естественное движение свайпа обеспечивает быстрый доступ к этим пунктам.

Особенности создания интерфейса для мобильной игры

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

Фрагмент информационной архитектуры условной игры. Красными пунктирными стрелками показаны сквозные переходы
Фрагмент информационной архитектуры условной игры. Красными пунктирными стрелками показаны сквозные переходы

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

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

36K36K открытий
31 комментарий

Таблица слева воспринимается гармоничнее, чем таблица справа Мне вот наоборот справа больше нравится)

Ответить

Да ну, слеплено как-то. Вы же на телефоне будете это смотреть.

Ответить

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

Ответить

Gabe, когда hl3 выйдет?!

Ответить

Мне тоже справа нравится. И паре знакомых программистов тоже. А вот почти всем остальным кого я знаю - нравится слева...

Ответить

А можно чуть подробнее про пример с вкладкой Избранное? Пытался понять разницу было/стало с учётом вводной про глубину, но не смог :(

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

Ответить

Хороший UI - минимум UI .

Хотя кто то считает что любая игра - это набор UI шек.

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

Ответить