Карта экранов в разработке игрового интерфейса

Как упростить работу при создании UI.

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

Борис Киселев, ведущий дизайнер интерфейсов студии Rocket Jump, написал для DTF колонку о картах экранов — удобном инструменте для упрощения разработки интерфейса игры.

Карта экранов в разработке игрового интерфейса

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

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

Bunker
Bunker

Обычно хранение и просмотр файлов организованы иначе — дизайнеры ограничиваются набором поэкранных превью, названных по определённой системе. То есть, скорее всего, многие привыкли к примерно такой картинке.

Карта экранов в разработке игрового интерфейса

Это простая, проверенная, рабочая система организации, и я не призываю от неё отказываться. Без поэкранных превью всё равно не обойтись — они понадобятся для отсмотра на устройствах, для вёрстки, для презентаций. Но не стоит ограничиваться только ими.

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

Вкратце перечислю основные преимущества их использования.

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

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

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

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

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

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

Фрагмент карты экранов с нашего проекта Dungeon Brawlers
Фрагмент карты экранов с нашего проекта Dungeon Brawlers

Пару слов о минусах подхода.

  • Составление и поддержание карты в актуальном виде требует дополнительного времени и усилий.

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

  • Поначалу нужно будет учить команду работать с картой — не оставляйте её «в столе» только для себя. Активно оперируйте ею и всячески продвигайте использование инструмента, только так карта экранов станет неотъемлемой и полезной частью вашего производственного цикла.

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

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

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

  • Экраны на карте должны быть подписаны. Папки, исходники и файлы-превью должны иметь те же названия. Если на схеме вы назвали экран «inventory», папку с макетами на сервере «storage screen», а сам макет «items_finalVER12», то вы на верном пути в бездну.

  • На карте отражены все основные переходы и связи между экранами (кроме повторяющихся и очевидных, вроде кнопки «назад»).

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

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

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

  • Старайтесь без жёсткой необходимости не менять расположение экранов на схеме с каждой итерацией — это запутывает. Лучше оставляйте плейсхолдеры под те экраны и разделы, которые пока находятся в разработке.

  • Карта должна обновляться регулярно, но без фанатизма. Цените своё время. Если вы на каком-то экране поменяли размер шрифта в колонке с 30 на 24 pt, то обновлять всю схему необходимости нет. Только не забудьте отследить, чтобы эта информация не потерялась по пути до верстальщика.

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

  • Старые варианты карты лучше сразу удалять или хранить их там, где на них никто не наткнется случайно.

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

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

Fantasy Alliance
Fantasy Alliance

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

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

Однако это вопрос привычки. Photoshop также прекрасно справляется с подобными задачами. Кроме того, есть ряд весьма неплохих онлайн-сервисов вроде realtimeboard, conceptboard или mural.co, позволяющих составлять карты экранов онлайн, а кто-то вообще работает с ними в Google Docs. Попробуйте разные варианты, чтобы понять, что лучше подходит именно вам и вашей команде.

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

5656
7 комментариев

Интересно читать как люди с другой стороны подошли к процессу, который мы используем и развиваем >10 лет )
Попробуйте инструменты специально созданные для этого — есть плагины для Sketch, есть возможности делать это в inVision (и это будет ещё и прототип, кнопки можно "нажимать" и оно будет переходить по экранам), и там удобно комменты прямо на экранах оставлять, есть версии и тд, так же недавно вышел в бете инструмент специально для создания этих схем (обыно их называют app flow, ux flow, user flow и тп) — https://overflow.io/, которому мы делали дизайн, чтобы использовать самим.

12
Ответить

Делать можно хоть в Пейнте. Человек написал про общий подход и конкретные советы как с ним работать.

Сам метод не нов, но я удивляюсь сколько UX-дизайнеров не в теме.

Ответить

Спасибо за комментарий! Да, все так: прием не новый. Однако мой основной поинт был в том, что

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

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

В качестве забавного примера - знакомые ребята-разработчики делали ч/б распечатки экранов и клеили их на огромную пробковую доску, а для комментов использовали канцелярские стикеры. Получалось что-то в стиле карты подозреваемых Шерлока Холмса, но вот так им больше нравилось. И, как ни странно, это работало )

А за https://overflow.io/ спасибо. Не знал о них, буду следить,за тем, во что они разовьются.

Ответить

Опыт ошибок горьких! Я на флеше (Adobe animate CC) собирал мокапы для теста стейтов персонажей и GUI анимаций. Один плюс можно было добавлять разные эффекты типа bevel и редактировать тайминги (удаляя кадры или меняя их длительность)

Ответить

Норм так. Еще на карту экранов хорошо ложится коре луп, либо можно выносить в отдельную карту. Там можно отслеживать смещение фокуса игрока в сессии и иногда позволяет поправить нелепые моменты, типа когда все экраны вроде как хороши и в стиле, а вместе не работают. Или когда луп внезапно на самом деле не луп :)

2
Ответить

Первая картинка на Mind Map похожа. И да, они удобны.

Ответить