Создание дизайн-системы для игры: детальный разбор подхода06.04.2020 13:03

Меня зовут Максим Полстяной, я UI/UX Designer в Plarium Kharkiv. В этой статье я поделюсь опытом создания дизайн-системы для нашей браузерной стратегии «Войны Престолов», расскажу с чего все начиналось и какие этапы мы проходили.

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

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

Проанализировав проект, мы выявили ряд проблем:

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

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

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

Перебрав UI игры, мы выделили базовые неделимые частицы интерфейса, из которых составили основные группы.

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

Примеры элементов: кнопки, табы, слайдеры, текст и прочее.

2) Контрол — группа элементов, которые могут выполнять функцию управления, навигации, визуализации данных.

Примеры контролов: награда, пейджер, поиск по координатам и прочее.

3) Блок — логически сгруппированный набор элементов и контролов. Цель блока — группировка этих частей интерфейса для выполнения определенных задач.

Примеры блоков.

4) Шаблон — это группа блоков, из которых формируются экраны для различных задач. У шаблонов может быть своя система и правила построения. Цель шаблона — хранение логики поведения для контента внутри шаблона.

Пример шаблона.

5) Экран — это группы шаблонов, а также часть окна, которую мы видим в данный момент.

6) Окно — может состоять из одного или нескольких экранов.

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

Окна

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

Собрав все существующие окна, мы решили разделить их на три типа и прописали для каждого из них статическую ширину, а также минимальную и максимальную высоту. При выборе размеров нужно было учитывать, что одно и то же окно используется в соцсетях, браузере и десктопном приложении Plarium Play, но при этом область под игровой контент везде разная. Мы определили максимально возможный размер для окна, исходя из самой маленькой игровой области (для «ВКонтакте»).

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

Три типа окон: главное, внутренние окна и алерт.

Сетка

Мы выбрали сетку с клеткой 4×4 пикселя (один модуль) — она лучше всего подходила под наши требования. С такой сеткой можно быстро перемещать элементы на расстояния, кратные четырем, и делать нужные отступы. Например, сделать отступ на 4 клетки визуально проще, чем отсчитывать 16 пикселей. Все наши элементы и блоки имели размеры, кратные одному модулю. Функция привязки к сетке — еще один плюс такого подхода.

Для удобства верстки контента мы создали вспомогательную 12-колоночную сетку. Она позволяла гармонично располагать блоки и не высчитывать каждый раз горизонтальные расстояния. Сетка из 12 колонок очень гибкая, так как 12 делится на 1, 2, 3, 4, 6 и 12 частей. Параметры сетки: 12 колонок шириной 52 пикселя, межколонник — 12 пикселей, «уши» — по 16 пикселей.

Сетка 4×4 пикселя и 12-колоночная сетка.

Система отступов

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

Мы вывели четыре размера отступов: 4, 3, 2, 1 модуль (16, 12, 8, 4 пикселя соответственно).
4 модуля являются «охранным полем» окна, а также самым большим отступом. С добавлением новых блоков в макет (речь идет о вложенности) их охранное поле и отступ уменьшаются. Самое маленькое расстояние между контентом не должно быть меньше одного модуля, то есть самое маленькое расстояние — это 1 клетка 4×4 пикселя. Таким образом контент внутри окна подчиняется правилу близости. Пример такой структуры:

Система отступов.

Система отступов на примере экрана «Боевой отчет».

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

Подробнее о шаблонах

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

Примеры блоков, из которых состоят списки.

Собрав все разновидности, мы разделили контент на группы с общими характеристиками:

с иконками;
с прогресс-барами;
текстовые;
с кнопками;
группы с User control (контроль взаимодействия с игроком);
mix-группа, в которой может быть несколько элементов из предыдущих групп.

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

Правила построения блоков.

Разновидности групп и правила размещения элементов.

Типографика

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

Основной шрифт игры — Korinna Normal — трудно читался в маленьком кегле. Мы решили эту проблему, добавив шрифт Roboto Medium для мелкого текста.

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

Таблица со стилями текста.

Также мы разработали правила сборки, построения и использования для:

кнопок,
всевозможных карточек (карточка покупки юнита, турнирная и прочие);
тултипов и нотификаций;
прогресс-баров;
контролов;
панелей.

Что стоит учитывать при разработке системы?

Локализация. Наша игра доступна на семи языках. Нужно было учитывать это при выборе ширины кнопок или пространства для текста. Например, слово на немецком могло быть длиннее того же слова на английском в три раза.
Использование одного и того же окна на разных платформах. Учитывайте это, когда будете выбирать размер окна.
Общая терминология внутри команд разработки. Важно, чтобы гайдлайны были написаны на языке, понятном всем участникам процесса.
Соблюдение размеров, кратных 4. Это позволит легко расставлять блоки и элементы по клеточкам модульной сетки, а также делать нужные отступы, не высчитывая пиксели.
Большое количество контента, который нельзя будет заменить в проекте, даже если он морально устарел. Изменение дизайна некоторых элементов или UX может вызвать недовольство игроков, которые за много лет привыкли к определенному отображению интерфейса.
Ограничения по использованию скролла в окнах.

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

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

Итог

Мы создали понятную и удобную структуру всех составляющих графических элементов проекта в Confluence.

С помощью гайдлайнов и библиотеки элементов удалось:

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

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

Сравнение экранов до и после переработки

Окно боевого отчета (до/после).

Окно квестов (до/после).

Окно «Обитель» (до/после).

Окно «Альянсы» (до/после).

Окно «Теневой рынок» (до/после).

Окно «Магистрат» (до/после).

Окно «Магистрат», просмотр очереди постройки войск (до/после).