Дневники разработчиков Ash of Gods: Redemption, часть первая

Создатели мультижанровой фэнтези-игры о сценарии, боевой системе и визуальном стиле.

CEO AurumDust Николай Бондаренко написал статью для официального сайта Ash of Gods: Redemption, в которой объяснил, с какими сложностями сталкиваются разработчики на начальных стадиях проекта и как в нём сочетаются элементы стратегии и визуальной новеллы.

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

Большая часть августа и весь сентябрь ушли на поиск стилистики и техники рисования сцен. И тут я, как новоявленный «эй-я-знаю-всё», немного облажался. Рассчитывал, что концепт-художник Владимир Малаховский, мой товарищ и близкий друг нашего арт-директора Игоря, поможет с адаптацией стилистики сцен. Я уже работал с Владимиром над игрой Cradle of Magic, и он делал там тёплую и ламповую рисованную графику, которая на первый взгляд нам подходила.

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

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

Мы потеряли почти месяц на эксперименты, и это жутко демотивировало. На фоне того, что с персонажкой у нас всё получилось с первой же попытки — это выглядело провалом. Хорошо, что Игорь (арт-директор) вовремя вспомнил про Андрея Жердева, в первых же набросках которого чувствовалось именно то, что мы искали:

В конце августа (спасибо социальным сетям) мы нашли Юлию Жохову — прекрасную художницу, у которой был опыт работы в нужной нам иллюстративной технике. Начались поиски референсов и нащупывание стилистики, которой бы удалось верно передать атмосферу повествования. На город Альбус, его окрестности и двор дома Торна Бренина у нас ушло почти полтора месяца. При всей видимой простоте выработанная техника рисования (кисти, колористика, свет) всё ещё требовала уйму времени. Отдельно пришлось продумать дизайн растительности — отдельных деревьев, массивов и кустов. Понять, как верно рисовать строительные материалы. Так, в первой версии, наш Альбус смотрелся словно его минуту назад создал джин из сошедших мгновение назад со станка материалов.

Первая попытка собрать аниматик сцены в Unity произошла в конце сентября:

Нам нужно было найти решение, которое бы не только визуально всех устраивало, но и позволяло бы создавать контент быстро. Не уверен, впрочем, что нам это до конца удалось — с каждой новой сценой появляется что-то интересное и новое, чего не хватает в уже сделанном материале. Хочется вернуться и всё переделать или, как минимум, дорисовать. К середине декабря мы научились рисовать одну сцену в полтора-два экрана шириной за две-три недели — от идеи до сборки в Unity. Эта сцена, «Деревня у Арки» возле города Урсус — одна из наших первых побед:

В ней Юля использовала часть практик, которые чуть раньше были использованы Андреем Жердевым в третьем эпизоде игры (мы не показывали эти сцены) — элементы работы со светом, горные массивы на заднем плане, растительность, стилистика рисования Менгиров (здоровенные камни, образующие арку). Подобные штуки позволили здорово сократить время работы над иллюстрацией.

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

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

Необходимо было решить сразу несколько проблем. Так, в настоящей последовательности удара Rush — 53 кадра, и персонаж в этой анимации достаточно много двигается — приседает, вертит корпусом, отходит. Боевое поле представлено в изометрической проекции и для того, чтобы каждая анимация плавно переходила от одной к другой, у всех таких кадров должна быть верно выставлена точки привязки. Иными словами то, как вы центрируете одни кадры по отношению к другим. По наивности своей, я рассчитывал, что такая плёвая и обычная операция для любой 2D игры (а у меня достаточно большой опыт работы с такими материалами во Flash) обязательно будет в Unity. Как оказалось, таких инструментов, как впрочем и кучи всего другого, чего ты ждешь от платформы для 2D игры, в нём нет. Более того, практически всё, что можно найти в open source или магазине Unity для 2D игр, заточено исключительно под платформеры. Так что импорт и выравнивание боевых анимаций пришлось писать самостоятельно.

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

При этом, когда мы начали писать код в Unity у нас уже был прототип боевой системы, написанный мной на JavaScript. Сейчас мы всё еще добавляем и тестируем классы в нём, следуя правилу — пиши быстро и не думай о последствиях. Считаю, что главная сложность для реализации в Unity была в попытке перенести наш прототип, proof of concept боевой системы, максимально точно, сохранив всё, что есть в вебе, и при этом задолго до того, как начнётся работа над ИИ. Или мы решим внедрять готовые анимации, или в целом делать что-то серьезное именно с этой частью игры. Мне было важно сделать это как можно раньше, чтобы понять, насколько сложным это окажется, и как нам следует строить разработку в целом.

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

Каждое умение — это небольшой текстовый файл в формате YAML, в котором в декларативной форме описано, как работает умение. Тут можно быстро изменять параметры, добавлять или убирать эффекты или просто менять механику поведения отдельных классов. Это позволяет в считанные минуты проверять те идеи, которыми делятся люди, играющие с нами в прототип. Так, к примеру, идею класса «Молотобоец» нам подсказал Voice of Reason. Получился класс, который может перемещаться практически по всему полю, а единственная его цель — не дать не походившему персонажу противника сделать ход. Нужно несколько минут, чтобы завести класс и начать смотреть, как он играет и влияет на игровой процесс.

Всё это время Сергей Малицкий (автор сценария) и Дмитрий Ерохин (геймдизайнер) независимо работали с Articy. Эта такая штука, которая позволяет нам писать и проверять сценарий вне зависимости от того, как пишется код игры. Ещё нельзя полноценно поиграть в новеллу, но мы уже можем «поиграть» в первые 5 эпизодов в Articy — проверить, как работает ветвление и выборы.

Почти месяц, с середины ноября, мы параллельно занимались режиссурой диалогов — как нужно правильно ставить персонажей в сцене, как делать переключение планов на двумерных сценах. В диалогах в игре участвует максимум семь человек, так что мы пришли к модели «трех сцен» — двух основных и одной дополнительной. Геймдизайнер задает для каждой из таких сцен, какой персонаж где стоит, а Articy управляет тем, кто сейчас говорит.

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

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

И да, articy:access api — это большая боль. На поверку работа с ним оказалась не такой простой, как обещали рекламные проспекты. Истории «взял и всё сразу работает» с ним не вышло. Еще я с некоторым трепетом думаю о процессе локализации — обещанные с 2014 года инструменты интернационализации в Articy так и не появились. Не то, чтобы это была аховая проблема, но нервничать заставляет всё равно.