Каша из топора-6: как создается аналог мобильной ролевой игры Darkest Dungeon

Руководитель студии Ole Pole Виталий Мороз написал цикл материалов о том, как создается игра Vikings Dungeon — любительская мобильная версия ролевой игры Darkest Dungeon.

● Первая часть

● Вторая часть

● Третья часть

● Четвертая часть

● Пятая часть

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

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

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

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

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

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

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

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

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

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

У меня получился такой список экранов и их функций:

● Бой

○ перемещение (нет врагов)

○ бой

○ инвентарь

○ награды

● Рекрутинг

○ просмотр характеристик персонажа

○ найм персонажа

● Выбор миссии

○ карта

○ информация о миссии

● Больница

○ кого от чего лечим

● Вальгалла

○ возрождение павших героев

● Кузница

○ разборка предметов

○ сборка предметов

● Магазин

○ покупка предметов

○ продажа предметов

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

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

Беглый анализ задачи показывает, что в игре у нас будет множество списков — предметов, героев.Списки — это значит либо таблицы, либо ленты. Ленты могут быть горизонтальными и вертикальными — для ПК я бы предпочел вертикальные ленты, но для мобильного лучше использовать горизонтальные (думаю, выбор вполне очевиден).

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

Теперь попробуем запроектировать бой исходя из озвученных принципов.

Что игроку должен видеть в бою:

● Персонажи— свои и врага;

● Приемы — элементы управления персонажами;

● Инвентарь — дадим лечиться из инвентаря и активировать всякие предметы;

● Cами предметы;

● Кнопка вызова инвентаря;

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

Конечно, к такому виду я пришел не за одну итерацию.

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

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

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

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

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

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

Когда и тут был наведен порядок, я принялся за детализацию окон.

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

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

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

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

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

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