Как мы перешли на светлую сторону и ушли от разработки мобильных игр [часть 3 - светлая сторона]
Перерождение проекта
После утомительных лонгридов про авантюру в мобильном геймдеве и попытки впарить дичь инвесторам, я, наконец, перехожу к сути этой затеи - ведению логов разработки.
Было принято решение кардинально пересмотреть концепт проекта и выкинуть из него все элементы ленивой монетизации и по сути от него остался только нарратив. Все игровые механики полностью были вырезаны и переработаны.
Речь пойдёт о жанре RPG с элементами Rogue-like в сеттинге тёмного фэнтези под рабочим названием Styria: Cursed Soul.
Первым глобальным изменением в проекте стала дизайн документация. Теперь мы постарались максимально сконцентрировать своё внимание на разработке проекта, а не маркетинге, как было раньше.
Нами были улучшены: навигация по проекту, визуальное восприятие, расширяемость блоков, порог входа в проект.
Мы создали удобную, на наш взгляд, структуру документа: каждый раздел разработки занимает свою подстраничку и внутри может также иметь подразделы. Если объем фичи или сущности начинает превышать один экран или здравый смысл, ему выделяется отдельная ветка, работа над которой ведётся автономно.
Лично на мой вкус и взгляд скроллинг длинных документов загружает мозг ненужной информацией и создаёт иллюзию слишком огромного документа. Поэтому я предпочитаю именно древовидную структуру.
Когда проект разрастается информацией, его становится тяжело не только менеджерить, но и презентовать новым участникам команды. Ведь не только лишь все хотят тратить время на обучение каждого желающего вступить в проект навигации по документу. По этой причине мы сейчас внедряем отдельный раздел-гайд для новичков в команде, который призван упростить "втыкание" в проект и ускорить старт работы.
Почерпнул я это из небольшого опыта работы в команде из 90 человек на энтузиазме. Там дизайн документация была разнесена настолько хаотично, что при всем моём желании я не смог вникнуть в суть. Приходилось заставлять себя скроллить десятки страниц, чтобы хотя бы по базе пройтись.
Стоит отметить, что рутинная работа над дизайн документацией может убить энтузиазм и ваши ресурсы и именно поэтому я предпочитаю разбавлять эту монотонность креативным подходом, пусть порой и во вред документу. Нужно давать волю талантливым художникам, а то случается всякое.
Боевая система - мать игрового процесса
Мы полностью перебрали по кусочкам боевую систему и пришли к динамичному hack & slash с большой вариативностью билдов и ролевого отыгрыша. Теперь вместо унылого закликивания и перетанчивания крипов хилками, у нас скилло-зависимая боевка, где важно соблюдать тайминги и ситуативно принимать решения по применению способностей.
Поскольку были внедрены элементы роглайка и игроку нужно часто заниматься повторяющимися действиями, мы выбрали в качестве основы гибридную классовую систему. Она, как нам кажется, позволит получать новый опыт от игры вне зависимости от того, какое это по счету прохождение.
В игре нет строгих классов, вместо них предоставлены различные ветки развития из широкого набора уникальных билдов. Каждый из классов имеет свои особенности отыгрыша: один придерживается быстрых и скрытых убийств, а второй нападает в лоб, благодаря своей стойкости.
Обратите внимание: во многих документах используется язык игроков, а не разработчиков. Для разработчиков у нас есть внутренняя развернутая документация, как правило, содержащая более технические определения.
Это упрощает работу с членами команды, кто не принимает непосредственного участия в разработке.
Есть отдельный мини-документ под названием Vision. Он даёт беглое понимание происходящего в проекте и ведёт за ручку новоиспеченных членов команды. Очень удобно складировать тупая общие концепты механик на языке игрока, чтобы не усложнять восприятие.
Подробная документация позволяет не только выполнять свои основные задачи, но также и оценивать объем конкретной фичи.
По объему документа сразу становится понятно, сколько нюансов придется проработать команде, чтобы эта фича заработала и иногда это позволяет сдвинуть на второй план реализацию менее важных вещей, но которые отъели бы значительную часть времени.
Стало скучно? Давайте немного разбавим рутину контентом
Разработка существ ведётся в 4 основных этапа:
- Нарративный этап: продумываем образы, места обитания, историю и прочие штуки персонажей
- Этап концептирования: берём за основу нарративную часть существа и отправляем техническое задание 2D концептеру и ждём магии
- Гейм-дизайн существ: на этом этапе важно проработать игровые особенности и поведение. Частично этот пункт затрагивается при проработке нарратива, но здесь мы глубже копаем в игровой процесс
- Создание 3D моделей: после того, как концептуальная часть полностью готова, формируется техническое задание для 3д-шника и мы опять ждём магии.
Давайте разберём на живом примере
Здесь представлено техническое задание для 2D концептера на существо под названием Крикун. Он издаёт противный звук и созывает своих союзников к обнаруженному врагу.
Всю коллекцию текущих моделей посмотреть можно на sketchfab, модели имеют не финальный вид и релизные версии могут серьезно отличаться от текущих.
Смерть - это новое начало
Каждая смерть в игре будет возвращать нас к выбору 1-го из 3-х персонажей с некоторыми особенностями. Так, например, вам может выпасть худощавый рахит, которому будет тяжело развивать физические способности или вы получите потенциал к развитию магии.
Примерная реализация подобной задумки была в разных играх, наиболее близкой к нам является Rogue Legacy 2.
Как итог мы получили мрачное фэнтези с механикой перевыбора персонажа после смерти, объединили это все динамичной боевой системой и приправили незаурядным повествованием.
В качестве движка было принято решение выбрать на этот раз Unreal Engine 5.1 вместо Unity
Следите за новостями проекта, мы и дальше будем делиться публикациями и подробнее остановимся на каждом пункте.