Визуальные новеллы: спортивная разработка велосипедов

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

ВМЕСТО ПРЕДИСЛОВИЯ

Привет, Олимпийский! Я Тимофей Хаханов, и за последние годы я запрограммировал несколько визуальных новелл. Две из них – For the People и With Good Intentions, дошли до релиза, как и техническая демка True Magician.

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

Я расскажу, как Tool Engineering решает уйму ваших проблем. Разумеется, добавляя новых.

Дисклеймер 1

Эта статья про подход, а не про тонкости реализации. Технические детали – как-нибудь в другой раз.

Дисклеймер 2

В 2022 я покинул Brezg Studio, об играх которой в основном пойдет речь, и больше не имею отношения к ее деятельности.

Поехали!

FOR THE PEOPLE

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

Разумеется, For the People вышла через полтора года: больше, амбициознее, и на другом движке.

ПРИКЛЮЧЕНИЕ НА 10 МИНУТ

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

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

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

Сюжетные скрипты – это тоже код. И чтобы работать с кодом эффективно и большой командой, нужны соответствующие инструменты. Которые уже есть, однако Fungus с ними дружить не хотел.

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

Поэтому я начал искать техническое решение, подходящий инструментарий. Это значило, что от Fungus надо избавляться, и переходить на сценарные системы, хранящие данные как код.

Где-то в этот момент я начал задумываться, что если и делать визуальное программирование сценариев, то как-то иначе...

Несколько экспериментов, пара презентаций команде, и решение было выбрано – переезд на Renpy.

RENPY

Хорошо...

Renpy – движок с открытым исходным кодом на Python. На момент разработки For the People – на Python 2, но недавно они наконец перешли на Python 3.

У Renpy есть два конкурентных преимущества:

Скрипты в Renpy – это программные инструкции, похожие на Python (и даже позволяющие вставлять туда непосредственно Python). Это значит, что хранится оно в тексте, и прекрасно обрабатывается системами контроля версий.

Совместная работа, код-ревью, автоматический анализ кода – это продало мне движок.

Вот что мы сделали:

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

...Да не очень

Пока сценарий делался начисто, разработка не стояла на месте.

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

Это был веб-редактор для игровых сущностей: документов, досье персонажей, писем. Нарративщики могли прямо в браузере создавать эти сущности, геймдизайнер раскидывал баланс – и все это прекрасно экспортировалось в игру в формате .json

На тот момент большая часть команды разработки – третьекурсники ЛЭТИ, по нашим меркам технология была прорывной. В какой-то момент наш бэкендер даже добавил совместное редактирования на веб-сокетах а-ля Google Docs.

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

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

На тот момент в нем было три источника строк: строки в сюжетных скриптах, псевдо-таблицы с переводами этих строк, и вынесенные нами в конфиг UI-ные строки.

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

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

РЕШЕНИЕ – ВЫШКА

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

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

Парсер и пересборщик языка Renpy на основе LL-грамматики.

Идея была простейшая: если мы не можем соотносить строки и их переводы в скриптах, давайте пометим все строки идентификаторами. И в скрипты, и в таблицу можно вставить комментарии – чем не место для id?

Для этого пришлось написать две программы:

У нас получилось не просто связать строки с их переводом, но и наладить импорт-экспорт из Brezg Content.

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

ИТОГО

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

Я взвесил все «за» и «против», и решил вернуться к Unity. Но теперь – без привязки к готовым инструментам.

ИНКВИЗИЦИЯ

OH UNITY, HERE WE GO AGAIN

Готовых решений под Unity за время работы над For the People стало больше. И они продолжали меня не устраивать.

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

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

Основные требования были определены так:

К назначенным дедлайнам появляется первая версия того, что в дальнейшем станет полноценным сценарным движком поверх Unity – Loki 0.1. Не то, чтобы существовала традиция называть плагины к Unity исключительно отсылками на скандинавскую мифологию, но один из лучших плагинов называется Odin, а я в восторге от викингов – название напросилось само собой.

Не шибко удобный, не шибко красивый и сравнительно долгий в работе – на тот момент он здорово уступал конкурентам.

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

ИТОГО

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

TRUE MAGICIAN

РЕДАКТОРЫ, ДЖОННИ, ОНИ НА ДЕРЕВЬЯХ

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

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

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

Loki обновился до версии 0.2.

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

Это сильно сократило время работы программистов.

Да и сам редактор стал сильно удобнее: многое менялось по фидбэку сценариста.

Другим важным нововведением стало создание сложных редакторов прямо в Unity, пришедших на замену Brezg Content.

Используя аддон Odin, получилось в несколько раз ускорить их создание и добиться сложного поведения. Через них в игру добавлялся контент вроде противников и оружия, настраивался баланс.

ФЕСТИВАЛЬ

Мы довели проект до демки для Steam-фестиваля. Удалось проверить гипотезы на полноценном публичном релизе: автоматические сборки работают, игра не вылетает, сценарии правильно отрабатывают.

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

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

Итого

К моменту выхода демки True Magician подошел к концу препродакшн следующего большого проекта студии. Все внимание переключилось на него.

WITH GOOD INTENTIONS

УСПЕШНЫЙ УСПЕХ

Мы снова расширили команду разработки, пересмотрели подход к UI, расшили возможности редакторов.

На версии Loki от True Magician собрали первое демо, которое показало: инструменты работают хорошо, но их нужно еще немного докрутить.

Релиз второго демо состоялся вместе с релизом Loki 1.0. Были добавлены:

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

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

Огромный буст к производительности дал вывод Loki из контекста проекта в отдельную библиотеку: когда ваш инструмент – независимый плагин, который игра может только расширять, вы можете синхронизировать его между двумя проектами. Обновления сценарного движка для With Good Intentions переносились в True Magician, обновления сценарного движка для True Magician переносились в With Good Intentions.

Эту модель я отмасштабировал: собрал по всем проектам вещи, которые хочется использовать в разных проектах и синхронно обновлять, вывел в Open Source, начал поддерживать scoped registry registry.khakhanov.dev

Это семейство плагинов для Unity, которое было названо Valhalla, насчитывает уже 15 библиотек. Все используются в нескольких проектах.

РЕЛИЗ И UNITY

With Good Intentions дошла до релиза. Когда проект разросся, вскрылось две проблемы:

Проблемы с локализацией были тривиальнее, чем в Renpy: штатная система импорта-экспорта падала на больших объемах данных. Опыт For the People тут помог, разработали свою систему чтения и записи таблиц. С автоматизацией, заменами и двух-сторонним объединением.

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

ИТОГО

А ДАЛЬШЕ?

За четыре года я и мои коллеги прошли путь от "что-то все не работает, какой бы движок выбрать" до полноценных кастомных инструментов поверх Unity. Они делятся между самыми разными проектами: начиная от визуальных новелл и заканчивая заказной мобильной MMO, над которой я успел поработать.

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

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

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

Надо ли оно вам? Зависит от проекта, но если вы играете в долгую, то скорее да, чем нет.

Сейчас я отошел от визуальных новелл.

В рамках KhanNorth Studio, чьим CEO я совершенно случайно являюсь, мы применяем все те же инструменты для создания ретро-RPG. Удивительно, как много наработок и опыта перекладываются на совершенно другой жанр: все те же библиотеки с открытым исходным кодом, все тот же сценарный движок Loki.

Думаю, за этот год многие новые наработки тоже перейдут в Open Source, особенно связанные с 3D.

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

А еще у меня твиттер есть, тоже подписывайтесь.

Khakhanov, out.

---------------------

Статью подготовил: Тимофей Хаханов

Источник: indie-space.ru – площадка инди-разработчиков