Интервью: разработчики Astral Ascent об особенностях работы в Construct 3
Эксклюзивный материал специально для сообщества Construct на DTF.
Неожиданно, на мой разбор игры Astral Ascent откликнулся Yaroslav Pangolin который занимался локализацией этой самой игры и предложил связаться с разработчиками, чтобы лично задать интересующие вопросы. Я меркантильно сверкнул глазами и расспросил обо всем, что интересно узнать лично мне. И представьте: мне ответили на ВСЕ! Открыто поделились проблемами и слабыми сторонами своей игры, а также рассказали о процессах, которых придерживаются во время разработки. Поэтому предлагаю вам интервью: про плюсы и минусы работы целой студии с конструктором игр, «секретные» техники помогающие довести игру до выхода в ранний доступ и почему, собственно, выбор пал на Construct 3. Перед началом, полагаю будет полезно почитать предыдущий пост, чтобы понимать путь студии к своей второй игре.
Ренан (Renan «Relixes» Rodrigues) — Ведущий разработчик
Луис (Louis Denizet) — Продюсер и Креативный директор
Алекс (Alexandre Magnat) — Продюсер и Ведущий художник
Гейл (Gaël Giudicelli) — Художник по окружению и персонажам
Ромэйн (Romain Rope) — Звукорежиссер
Как прошел переезд с Clickteam fusion? У вас получилось перенести логику кода из Dark Devotion, создавали события с нуля или нашли примеры в сообществе?
Луис: Насколько я понял, у Clickteam Fusion и Construct общий базовый код, и поэтому переход между ними был чрезвычайно простым. Construct ближе к «реальному» коду, поскольку он не скрывает понятия за именами (булевые переменные (Boolean) в Clickteam Fusion, например называют «флагами»), а также имеет гораздо больше функций, чем Clickteam Fusion. А еще сообщество гораздо активнее, что облегчает задачу, когда нужна помощь. Всегда сложно начинать новый проект с нуля, особенно на новом движке, как в нашем случае.
Чтобы освоить движок я прошел курс Udemy по C2, а после получал опыт путем проб и ошибок. Наверно так и стоит делать или еще можно потренироваться на очень маленьком проекте, потому что ошибки, которые вы сделаете на раннем этапе, будут тянуться спустя месяцы или годы. В целом, у нас ушло несколько месяцев обучения, чтобы быть готовыми.
Сколько времени заняла разработка по этапам: смена движка, препродакшн перед Kickstarter, ранний доступ? Игра сейчас находится в раннем доступе, вы заняты расширением контента или доделываются и основные части? Есть опасение, что масштаб игры упрется в лимиты движка?
Знакомство с C3 и пре-продакшн шли одновременно, и на это у нас ушло около 4 месяцев. Подготовка была осложнена, потому что мы только закончили Dark Devotion: нашу первую игру. Мы с Алексом были изрядно измотаны, закончились деньги, и нам пришлось заново мотивировать себя к разработке игр. Было сложно еще потому, что Dark Devotion был очень мрачным, и поскольку мы самоучки — было сложно делать что-то еще, кроме того, к чему мы привыкли. Мотивация начала резко расти, когда начали собирать команду и находить инвестиции для проекта.
Мы планируем быть в раннем доступе около года, чтобы релиз на ПК и консолях состоялся одновременно. На данный момент все основные системы игры готовы, поэтому мы заняты расширением существующего контента: новые боссы, миры, заклинания, игровые персонажи и т. д.
Мы уже достигли некоторых ограничений движка, но наши будущие версии будут экспортироваться MP2Games с помощью Chowdren (прим. рекомпилятор событий в С++ код, для повышения производительности и портирования приложений на другие платформы), и это должно помочь убрать многие такие ограничения.
Темп игры и количество одновременных действий очень высокие, особенно сравнивая с вашей первой игрой. Были сомнения, что листы событий (Event Sheets) конструктора будут не успевать выполняться, как обычный код? Проводили ли стресс тест и какие результаты получились.
Ренан: На самом деле мы с самого начала беспокоились, что могут возникнуть проблемы с производительностью игры. Тем не менее, быстрый и читаемый код был в приоритете, поэтому на ранних стадиях разработки производительность не учитывалась. Частично это было связано с тем, что мы рассчитывали запустить игру в Early Access (ранний доступ), используя кастомную сборку Chowdren от MP2Games, которая должна была заставить игру работать намного быстрее, чем при обычном экспорте NWjs. (прим. стандартная оболочка для экспорта С3). К сожалению, из-за ограничений по времени нам не удавалось скомпилировать игру в нем. Поэтому за несколько недель до старта раннего доступа мы принялись оптимизировать игру под NWjs настолько насколько это возможно.
Мы сделали все, что могли, но в итоге все равно получили массу жалоб на просадки FPS после запуска. Причин тому было несколько:
- Несмотря на то, что мы пытались оптимизировать игру для Early Access, в коде по-прежнему было много мест, требующих большой загрузки ЦП (циклы — ваш злейший враг, если вы хотите избежать чрезмерной нагрузки на ЦП, а у нас их было очень много, везде!);
- Мы используем много эффектов в игре (шейдеры), и C3, похоже, не очень хорошо справляется с объединением эффектов (используя несколько эффектов в одном объекте или на нескольких слоях), это привело к тому, что игра требует много мощности от GPU;
- После запуска мы узнали, что некоторые видеокарты (особенно на ноутбуках) NWjs просто не видит. Таким образом, в нашей игре с относительно высокими требованиями к железу (из-за эффектов C3, как упоминалось ранее) в некоторых случаях, мощные видеокарты просто не участвовали в работе. Упс…
Как вы оптимизировали игру?
Чтобы исправить проблемы с производительностью:
- С момента запуска мы выпустили множество обновлений для повышения производительности. Некоторые игроки по-прежнему жалуются на падение FPS, но текущая версия игры работает намного лучше, чем версия первого дня. И мы продолжаем над этим работать!
- Мы добавили возможность изменять разрешение во время игры (для этого нам пришлось немного взломать сам C3) + мы добавили дополнительные графические настройки, чтобы игроки со слабым железом могли понизить графику и повысить производительность. Мы также постарались отключить эффекты и слои, которые не использовались в некоторых ситуациях. Сочетание всех этих действий сделало игру относительно очень доступной (с точки зрения GPU).
- Также с помощью нашего партнера из MP2Games, Матиаса, удалось найти способ исправить экспорт NWjs, чтобы он наконец обнаруживал недостающие видеокарты.
Какой можно сделать из этого вывод… Очень сложно добиться хорошей производительности без стороннего экспортера!
Вы сами писали дополнительные плагины, нашли их в свободном доступе или заказывали на аутсорс? Каков процент использования стандартных средств C3? Вы использовали вставки Javascript внутри событий?
Ренан: Ни я, ни Луис (два программиста) не знакомы с разработкой плагинов для C3, но мы используем некоторые сторонние плагины/эффекты. Большинство из них общедоступны, а некоторые из них были заказаны специально для Astral Ascent. Пользуясь случаем, передаем привет Skymen и Mikal, большинство наших сторонних плагинов были сделаны ими, и эти ребята очень полезные и активные члены неофициального сообщества Construct 3 в Discord! Тем не менее, большую часть времени мы используем лишь стандартные плагины C3. Их одних уже достаточно, чтобы сделать многое! Я бы сказал, что около 90% всего в игре сделано стандартными средствами C3.
Что касается использования javascript, то мы его использовали очень редко. Без него, студии портирования будет немного легче потом переносить игру на консоли. Я лично также не очень хорошо знаком с JS, поэтому придерживаюсь событий, когда могу. Javascript используем только в особых случаях, когда это сильно повлияет на производительность или невозможно реализовать событиями. Думаю, что javascript в коде всего, 1%. Наверно даже еще меньше.
Какие инструменты использовали для анимации, рисования спрайтов и редактирования данных. Мне показалось или вы «читерили» промежуточными кадрами?: )
Алекс: Я использую Photoshop и нет, я не использую «читы», все делается вручную (кроме анимации растительности, с которой я использую программу Juice fx).
Ренан: Для файлов локализации игры и других вещей, таких как словари (Dictionary) и массивы (Array), которые содержат информацию об игре (например, урон от заклинаний, порядок разблокировки навыков, спавн врагов и т. д.), мы используем Google таблицы. Мы обнаружили, что Google таблицы — очень удобны, поскольку несколько человек могут совместно работать над одним и тем же файлом, и там намного проще оставлять комментарии.
Чтобы перенести данные из Google таблицы в Construct 3, мы используем скрипт на Python, который захватывает эти данные из таблички и преобразует файлы в объект Массив (Array) и json файлы.
Для диалогов в игре мы используем инструмент под названием Dialogue Designer, который, к сожалению, я не могу особо рекомендовать остальным…
В дневниках разработчиков описывался процесс создания наглядного контента: построение уровней, боевая система. А каков был «пайплайн» разработки скрытых компонентов игры: генерация контента уровней, интерфейсы, магазины, система сохранения, настройки? Вы держали их в голове с самого начала или добавляли задним числом?
Ренан: Лично я присоединился к Astral Ascent через год после начала разработки. На тот момент у Луиса уже было создано несколько механик, но много чего еще предстояло сделать. Наш рабочий процесс был очень естественным. Мы постарались как можно раньше создать большинство основных механик, которые, по нашему мнению, понадобятся при разработке игры (система сохранения, генерация уровней, элементы управления, инвентарь, меню и т. д.). Мы не тратили много времени на обсуждение. Члены команды кратко описывали свои идеи и следили за тем, чтобы они все работали на основную идею игры. После этого мы просто делим задачи между собой и каждый занимается своей частью.
Было обычным делом: по многу раз переделывать механику с нуля и настраивать ее, пока она не получится «идеальной».
Как только были готовы все основные механики игры, мы начали собирать их воедино. Именно тогда мы начали тестировать игру. Во время игровых тестов мы пытались понять, какие механики работали хорошо, а какие нет, и решали: что нужно переработать, удалить или добавить новые механики. Такой цикл разработки подходит нашей студии и мы будем придерживаться его до конца Раннего доступа.
Сколько у вас рабочих машин с совместным доступом к С3 и как выглядит синхронизация проекта?
Луис: У нас есть лицензия pro для студии, и мы используем GitHub для синхронизации. Работать с файлами проекта одновременно может быть опасно, были даже откаты версий несколько раз, но сейчас мы к этому привыкли, и проблемы случаются очень редко.
Какие ограничения движка помешали вашим задумкам, какие функции пришлось вырезать?
Ренан: С точки зрения гейм дизайна, я не могу вспомнить никаких ограничений движка, которые не позволяли бы нам делать в игре то, что мы хотели. Обычно делали все, что хотели, стандартными средствами C3, а когда это было невозможно, находили сторонние плагины.
Однако с технической точки зрения мы достигли некоторых пределов движка. За неделю до выхода в ранний доступ мы импортировали в проект множество аудиофайлов, для озвучки диалогов. C3 это совсем не понравилось. Внезапно музыка в игре перестала играть, а также возникли проблемы с загрузкой других звуков. Пользователи еще сообщали, что у них начинались проблемы (игра крашилась), когда включался стандартный видео-плагин (Video). Полагаю это были две самые крупные проблемы, связанные с движком, которые нам попались в Astral Ascent.
Хочу расспросить вас о том как вы работаете в C3. Можете поделиться своими особыми приемами?
Ренан: Я думаю, что мы могли бы многое улучшить, оглядываясь на полученный опыт, но некоторые вещи, у нас работают хорошо:
- Используйте как можно больше листов событий (Event Sheets) и групп для организации событий;
- Придерживайтесь общего нейминга игровых объектов и переменных, чтобы вы могли быстро находить объекты при вводе выражений;
- Используйте семьи (Families) как можно чаще! Если хорошо спланируете, вы можете избежать повторения большого количества событий, просто добавив некоторые объекты в семейства. На мой взгляд, семьи — лучшая фишка Construct 3;
- Используйте какой-нибудь тип контроля версий! Мы используем GitHub. Это спасло нас пару раз, когда нам нужно было вернуться к более старым версиям проекта. Кроме того, это позволило организовать приятный рабочий процесс, когда над проектом одновременно работало несколько человек (это очень важно для команды).
Локальный кооператив получился сам собой — простым переназначением клавиш для второго игрока или требовал много ручных правок во всем проекте?
Ренан: Добавление локального кооператива оказалась больше дизайнерской задачей, а не технической! Нам часто приходилось переосмысливать то, как работают некоторые механики, потому что это не сочеталось с многопользовательским режимом.
С точки зрения кода у нас тоже были некоторые проблемы. Нелегко протестировать локальный мультиплеер, работая сидя по домам (как сложилось у нас в студии) . Пандемия 2020 года этому тоже не способствовала. Нам часто приходилось использовать программы для удаленного управления, чтобы тестировать локальный кооператив. К счастью, это не создало много проблем. Большинство вещей, которые мы реализовали, правильно работали в кооперативе без особых проблем.
ИИ разных типов врагов уникальны или есть общая модель поведения использующая разные части событий? Схожий вопрос для героев, которыми управляет игрок.
Луис: Большинство врагов делят между собой большие куски общего кода в своем поведении, включая: дистанцию до остановки от игрока, частоту убегания, скорость и многое другое — это все общие переменные, значения которых уже меняются для каждого врага отдельно. Боссы не относятся к этой части ИИ, так как мы решили, что их атаки в основном не будут связаны с действиями игроков. Мы сделали полную противоположность в Dark Devotion, где боссы тоже были важной частью игры, но боссы вели себя как обычные противники, реагируя на расстояние до игрока, его движения и т. д. Мы поняли тогда, что это слишком загружает игроков, и если сделать меньшее число атак с более узнаваемыми паттернами, они лучше будут подходить для боссов.
Для разных персонажей игрока события абсолютно одинаковы, на самом деле это скины поверх общего коллайдера, так что вы даже можете без проблем иметь на экране двоих Kiran или Ayla.
Звук на Kickstarter подается как одна из серьезных фич игры. Задействованы ли в нем какие-то функции C3 или имелся ввиду талант композиторов?
Ренан: За крутые звуковые эффекты, присутствующие в игре, мы обязаны нашему (невероятному) звукорежиссеру Ромейну Роупу (Romain Rope). Он сделал много классных композиций, а потом мы просто импортировали эти файлы в проект. У нас есть события, которые срабатывают на определенных кадрах анимаций с некоторыми условиями, как звук будет проигрываться (зацикливаться, затухать, и. т. д.). И на самом деле это все, никакие эффекты из звукового плагина мы не используем.
На сколько автономен процесс портирования на консоли сторонней компанией (MP2 Games), а также студий локализации?
Ренан: Мы еще не дошли до этапа сборки Astral Ascent вместе с MP2Games и их Chowdren. Для этого нужно кое что подготовить, например преобразовать некоторые плагины и функции в код C++. На сколько я понимаю: в начале надо потратить некоторое время на подготовку для билдов, но после этого их можно делать на лету, даже если поменяется код игры.
Yaroslav Pangolin (об опыте взаимодействия со студией): Локализация игры делалась через Google табличку. Это само по себе не удивительно, так часто делается, но у них она моментально позволяет отправить локализацию в новую сборку. Впервые с таким сталкиваюсь, и я приятно удивлён.: )
Вы «храните» спрайты (например, для окружающей среды) внутри одного объекта или держите их все отдельно?
Ренан: Для большинства объектов окружения и прочих декораций мы обычно создаем по одному объекту для спрайтов одной «категории». Например: скалы, деревья, трава, облака и т. д.
До полноценного релиза впереди еще много работы, но какие у вас планы на следующий проект?
Луис: У нас был проект, который мы изначально хотели сделать, но мы чувствовали, что он слишком амбициозен, и мы предпочли вместо этого сделать Astral Ascent, который, как нам казалось, был бы проще и не таким амбициозным. На данный момент мы полностью отдаемся созданию из Astral Ascent лучшей игры, даже планируем сделать DLC после релиза, но потом, у нас есть много потенциальных идей для новых игр.
Большое спасибо Ярославу и команде Hibernian Workshop за потраченное время и ответы на вопросы!
У нас в закрытом чате с разрабами есть специальный канал, куда подтягиваются все отзывы от игроков. Команда Hibernian Workshop просматривает каждый отзыв в Steam, особенно уделяет внимание жалобам, чтобы разобраться в проблемах (технических и не только) и исправить их. Это одни из самых внимательных к игрокам разработчиков игр, с которыми доводилось работать.
Надеюсь всё у них будет отлично: выйдут новые боссы, новые миры, успешно пройдёт полноценный релиз и выпустится DLC :)
Комментарий недоступен
@Granger в геймдев репостните)
Ого нас откопали)
Я для себя отметил несколько моментов:
- есть способ дополнительно увеличить производительность, если она вдруг перерастет стандартные средства. Типа про запас. А так можно оставаться на NWjs, раз сейчас игра вполне работает на нем в раннем доступе.
- нет ничего зазорного искать готовые решения в открытых источниках
- стандартные системные функции игры, типа настроек и сохранений лучше добавлять с самого начала.
- ну и разработчики подтвердили, что констракт легитимный вариант чтобы делать игры. В частности, что он дает возможность быстро дизайнить и перебирать разные варианты механик.
- однако, чем дальше отходишь от стандартного функционала, тем больше надо быть готовым, что именно здесь вылезут какие-то проблемы.