Как мы перешли на светлую сторону и ушли от разработки мобильных игр [часть 3 - светлая сторона]

Перерождение проекта

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

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

Речь пойдёт о жанре RPG с элементами Rogue-like в сеттинге тёмного фэнтези под рабочим названием Styria: Cursed Soul.

<i>И снова все начинается в дизайн-документации</i>
И снова все начинается в дизайн-документации

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

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

Как мы перешли на светлую сторону и ушли от разработки мобильных игр [часть 3 - светлая сторона]

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

Лично на мой вкус и взгляд скроллинг длинных документов загружает мозг ненужной информацией и создаёт иллюзию слишком огромного документа. Поэтому я предпочитаю именно древовидную структуру.

<i>Пример структурного разделения механик игры</i>
Пример структурного разделения механик игры

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

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

<i>Местами мой внутренний дизайнер заигрывается и делает не слишком оптимально</i>
Местами мой внутренний дизайнер заигрывается и делает не слишком оптимально

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

Боевая система - мать игрового процесса

Мы полностью перебрали по кусочкам боевую систему и пришли к динамичному hack & slash с большой вариативностью билдов и ролевого отыгрыша. Теперь вместо унылого закликивания и перетанчивания крипов хилками, у нас скилло-зависимая боевка, где важно соблюдать тайминги и ситуативно принимать решения по применению способностей.

Так выглядел первый билд боевки

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

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

Как мы перешли на светлую сторону и ушли от разработки мобильных игр [часть 3 - светлая сторона]

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

Это упрощает работу с членами команды, кто не принимает непосредственного участия в разработке.

<i>Так выглядит документация по разработке, она также имеет структуру, почти аналогичную дизайн документу</i>
Так выглядит документация по разработке, она также имеет структуру, почти аналогичную дизайн документу

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

Как мы перешли на светлую сторону и ушли от разработки мобильных игр [часть 3 - светлая сторона]

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

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

<i>Как пример такого участка, где все механики являются вторичным геймплеем и не предоставляют ценности вначале</i>
Как пример такого участка, где все механики являются вторичным геймплеем и не предоставляют ценности вначале

Стало скучно? Давайте немного разбавим рутину контентом

<i>Оксюморон или лудонарративный диссонанс в виде пикчи и названия статьи, автор моделей: <a href="https://api.dtf.ru/v2.8/redirect?to=https%3A%2F%2Fsketchfab.com%2FNexysStormcloud%2Fcollections%2Fstyria-0a84a6342b8145009e473cec40c903fd&postId=1875077" rel="nofollow noreferrer noopener" target="_blank">NexysStormcloud</a></i>
Оксюморон или лудонарративный диссонанс в виде пикчи и названия статьи, автор моделей: NexysStormcloud

Разработка существ ведётся в 4 основных этапа:
- Нарративный этап: продумываем образы, места обитания, историю и прочие штуки персонажей
- Этап концептирования: берём за основу нарративную часть существа и отправляем техническое задание 2D концептеру и ждём магии
- Гейм-дизайн существ: на этом этапе важно проработать игровые особенности и поведение. Частично этот пункт затрагивается при проработке нарратива, но здесь мы глубже копаем в игровой процесс
- Создание 3D моделей: после того, как концептуальная часть полностью готова, формируется техническое задание для 3д-шника и мы опять ждём магии.

Давайте разберём на живом примере

Здесь представлено техническое задание для 2D концептера на существо под названием Крикун. Он издаёт противный звук и созывает своих союзников к обнаруженному врагу.

Как мы перешли на светлую сторону и ушли от разработки мобильных игр [часть 3 - светлая сторона]
Как мы перешли на светлую сторону и ушли от разработки мобильных игр [часть 3 - светлая сторона]
<i>2D концепт существа Крикун, автор концептов <a href="https://dtf.ru/u/31295-yaroslav" rel="nofollow noreferrer noopener" target="_blank">Ярослав</a></i>
2D концепт существа Крикун, автор концептов Ярослав
<i>3D модель персонажа</i>
3D модель персонажа

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

<i>А так выглядят более человечные образы в концептах</i>
А так выглядят более человечные образы в концептах

Смерть - это новое начало

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

Примерная реализация подобной задумки была в разных играх, наиболее близкой к нам является Rogue Legacy 2.

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

В качестве движка было принято решение выбрать на этот раз Unreal Engine 5.1 вместо Unity

А вот и пересобранный прототип основных механик уже на Unreal

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

2525
11 комментариев

А в чем документацию ведете, если не секрет?

Ответить

Документацию ведём в Notion

1
Ответить

Комментарий недоступен

Ответить

Да в основном ничем, просто мейн разраб предпочитает работать в Unreal

1
Ответить

Похоже это будет проект достойный релиза в ВК плей

Ответить
Ответить

В гугл докс есть возможность показывать постоянно структуру документа. Это к вопросу Диздока оформленного как сайт.

Ответить