Быстрая итерация дизайна в Breachers с помощью AssetPostprocessor и Blender

Triangle Factory - быстро развивающаяся бельгийская игровая компания, которая использует Unity для создания высококачественных многопользовательских VR-игр, таких как Hyper Dash и их последняя игра Breachers. Triangle Factory использует такие инструменты, как Cinemachine, Unity Profiler, Game Server Hosting, Matchmaker, Voice Chat (Vivox) и Friends для создания захватывающего опыта для игроков.
В этом блоге Джел Садонес (Jel Sadones), ведущий дизайнер уровней и техник-арт, и ведущий разработчик Питер Ванторре (Pieter Vantorre) рассказывают нам о конвейере Blender-to-Unity и о том, как они воплотили в жизнь свою VR-тактическую FPS-игру Breachers.
Unity является нашим основным движком и средой разработки уже более десяти лет, и за эти годы мы прошли через множество рабочих процессов, связанных с моделированием и дизайном окружения. Это включает в себя использование встроенных инструментов моделирования, таких как ProBuilder (который мы до сих пор используем и любим для быстрого создания прототипов), и сборку сцен из префабов, созданных в других пакетах моделирования. Однако для наших текущих проектов мы остановились на рабочем процессе, в котором моделируем и организуем уровни в Blender, а для их интеграции в проект Unity используем AssetPostprocessor.
В этой статье мы расскажем вам, как мы пришли к такому рабочему процессу и как он поддерживает быструю итерацию дизайна, необходимую нам для наших игр.
В 2021 году мы выпустили нашу первую крупную VR-игру Hyper Dash, стремительный шутер на арене 5v5. Когда мы начали разработку игры в 2019 году, у нас был базовый рабочий процесс от Blender до Unity, который, вероятно, многим покажется знакомым: Мы просто смоделировали геометрию в Blender, экспортировали наши активы в файлы FBX и вручную интегрировали их в Unity. Ручная интеграция включала в себя несколько этапов:
- Установка динамических объектов в сцене, например, захвата оружия, дверей спавна, точек захвата
- Размещение коллайдеров, не позволяющих игрокам ходить или телепортироваться в определенных областях
- Настройка невидимых направляющих, чтобы боты вели себя правильно
- И т.д.

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

На этапе создания прототипа мы все еще полагались на префабы для динамических объектов, таких как, например, оконные баррикады. Это предметы, которые мы помещаем в оконные рамы, чтобы перекрыть видимость между внутренними помещениями и внешней стороной, чтобы команды не видели друг друга во время разминки во время игры.
Во время тестирования нашего прототипа мы постоянно перемещали окна, чтобы улучшить геймплей, что означало изменение геометрии в Blender и реэкспорт в Unity, а затем ручное перемещение объектов баррикад в соответствии с нашими изменениями. Многие часы были потрачены на то, чтобы полетать по сцене Unity, вручную проверяя и исправляя подобные вещи. Тем не менее, мы не раз проводили плейтест, когда только во время игры замечали, что что-то было упущено.


Очевидно, что такая схема работы не позволяла нам быстро итеративно дорабатывать дизайн карт в ходе игрового тестирования, как внутреннего, так и в рамках открытой альфа-версии, где мы планировали выложить одну карту в свободный доступ, чтобы получить отзывы от сообщества. Мы с нетерпением ждали всех этих отзывов, но совсем не ждали ручного труда, связанного с их применением на наших картах.
Еще одним потенциальным недостатком рабочего процесса проектирования на основе сборных конструкций является производительность. В основном для наших игр мы выбираем мобильные, автономные VR-гарнитуры. Мы хотим довести визуальные эффекты до максимума, поэтому нам нужно выжать из рабочего процесса все до последней капли производительности.
Сборка уровней из префабов может быть менее эффективной, чем создание водонепроницаемой сетки в программе моделирования. Если вы соедините две модульные стены вместе, между ними всегда будет оставаться незамкнутый контур геометрии. С помощью префабов также легко разместить в сцене множество геометрии, которая не видна (потому что она находится на нижней стороне объекта или прислонена к стене), но при этом занимает ценное пространство лайтмапа. На протяжении всего уровня эти мелкие недочеты могут привести к потере производительности и ухудшению визуального восприятия.

Последняя проблема, связанная с префабами, о которой мы хотим упомянуть, заключается в том, что можно легко все сломать, внеся, казалось бы, невинные изменения в исходную модель в Blender, например, переименовав объект. По мере развития игры или уровня вам часто захочется реорганизовать активы и дать им улучшенные или более устойчивые названия. Но переименование объекта в Blender и его повторный экспорт могут легко (и без предупреждения) нарушить переопределения и дополнения, сделанные для объекта в Unity, что приведет к регрессам.
В этом упрощенном примере у нас есть вентиляционная решетка Prefab, и мы хотим, чтобы из нее выходил дым. Импортировав сетку в Unity, наш художник добавил систему частиц дыма в качестве дочернего объекта и добавил компонент типа поверхности в Prefab, чтобы обозначить его как металлический объект.
Здесь вы можете увидеть, что произойдет, если мы переименуем нашу сетку в Blender:
При повторном импорте сетки с обновленным именем Unity больше не может найти старую сетку по имени, поэтому удаляет объект из модели Prefab. Дочерние объекты этого удаленного объекта перемещаются в корень префаба, а существующие скрипты удаляются, что снова приводит к ручной очистке, которой мы предпочли бы избежать.
В то время как фаза прототипирования Breachers завершалась, и мы готовились к запуску в производство в начале 2022 года, наши команды художников и разработчиков собрались вместе и выяснили, что мы можем сделать, чтобы устранить эти проблемы. Мы определили четкие цели для нашего идеального конвейера активов, который поддерживал бы быструю и гибкую итерацию, необходимую для Breachers:
- Все создание и изменение геометрии уровней должно происходить в Blender.
- WYSIWYG: То, что дизайнер создает в Blender, должно как можно точнее соответствовать результату в Unity.
- Когда что-то обновляется в Blender, импорт изменений в Unity должен происходить автоматически и не требовать никаких ручных усилий.

Как уже говорилось выше, нашей главной целью было получить точную визуализацию игры в Blender - не только правильно отражающую то, как конечный результат будет выглядеть в Unity, но и то, как устроена механика геймплея. Геймплей в Breachers зависит не только от планировки уровня, но и от динамических объектов (например, пробиваемых стен) и невидимых элементов (например, громкости звука и коллайдеров). Мы хотим, чтобы вся эта информация была видна на этапе проектирования и точно переносилась в Unity.
![Рисунок 5: Изображение Breachers предоставлено Triangle Factory [Часть нашего уровня "Небоскреб" в Blender (только статическая геометрия уровня и реквизит)]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Ffuvbjjlp%2Fproduction%2F3d1ec8eaf99391b246965c8a7ac1fafd1b6f121c-3810x2058.png&w=3840&q=75)



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

Это обеспечивает нам большую гибкость и стабильность. Эти свойства остаются связанными с объектами на протяжении всего конвейера, поэтому мы можем реорганизовывать и переименовывать объекты в наших уровнях сколько угодно, не беспокоясь о том, что они сломаются или выйдут из синхронизации.
В Unity есть мощный класс AssetPostprocessor, который позволяет изменять активы во время их импорта. Это то, что мы используем во время импорта для анализа этих пользовательских свойств и действий с ними.
Ссылки на сборные конструкции
У нас есть пользовательское свойство PrefabLink, которое сообщает Unity, что объект, импортированный из Blender, должен быть заменен на Prefab, уже имеющийся в проекте Unity, с сохранением трансформации импортированной модели. Это позволяет нам размещать эти динамические объекты в Blender, сохраняя преимущества префабов после их импорта в Unity. Оконные баррикады в сцене Blender выше - хороший пример этого.

Типы поверхностей
Определение поверхности чрезвычайно важно для Breachers. Ходьба по металлической лестнице звучит иначе, чем по бетонному полу. Проникновение пули через дерево сильно отличается от проникновения через сталь. И каждый тип поверхности имеет свои собственные эффекты воздействия. Просматривать каждый реквизит в Unity и отмечать его как правильный тип поверхности было бы очень трудоемко, поэтому мы решаем эту задачу на этапе проектирования в Blender, устанавливая пользовательские свойства для наших геометрических коллайдеров.
Статические флаги
Еще одним важным параметром для оптимизации являются статические флаги Unity. Правильная настройка этих параметров может оказать значительное влияние на такие вещи, как выбраковка видимости, запекание света и пакетная обработка. Используя пользовательские свойства в Blender, мы можем задать их для любой части уровня, включая многократно используемый реквизит, и перенести эту информацию в Unity на все наши уровни.
Коллайдеры
И наконец, мы хотели бы рассказать о том, как мы настраиваем коллайдеры. В Unity есть простая, но эффективная система, которая автоматически определяет варианты уровня детализации для моделей, когда вы добавляете к имени актива модели постфикс _LOD0, _LOD1 и т. д. Мы вдохновились этим и создали аналогичную систему для коллайдеров: Просто имея геометрию с _BoxCollider или _NoCollision в имени, мы заменяем сетки из Blender на коллайдеры в Unity.


В качестве конкретного примера здесь приведен фрагмент нашего LevelSetupPostprocessor, который считывает пользовательские свойства и присваивает нужные статические флаги каждому импортируемому объекту:
Чтобы все это работало гладко, нам пришлось поработать и над Blender.
Пользовательские свойства немного скрыты в пользовательском интерфейсе Blender, и художникам пришлось бы каждый раз вручную вводить пользовательские свойства, что не очень удобно. Полагаться на ручной ввод текста также было бы очень опасно, что сводит на нет все преимущества настройки в Blender. Переход от рабочего процесса, основанного на префабах, к Blender также заставил нас упустить некоторые преимущества префабов, такие как наличие хорошей библиотеки объектов, которые можно просматривать и выбирать. К счастью, Blender, как и Unity, очень гибок и легко расширяем.
Решение проблемы организации префабов появилось в Blender 3.2 благодаря библиотекам ассетов. Эта система немного напоминает систему Prefab в Unity: Он позволяет создавать активы в отдельном файле, а затем импортировать их в сцену Blender, при этом изменения в файле актива автоматически отражаются в сцене Blender. Кроме того, он гарантирует, что любые пользовательские свойства или коллайдеры будут правильно применены к каждому экземпляру этого актива в Blender.


Для Blender мы написали собственное дополнение, помогающее настраивать пользовательские свойства в более понятном пользовательском интерфейсе. Это упрощает установку пользовательских свойств: достаточно выбрать соответствующие объекты Blender и нажать кнопку, вместо того чтобы вводить каждое свойство вручную.
Дополнение Bundle Exporter - это дополнение с открытым исходным кодом, которое мы используем для экспорта всех наших FBX-файлов в один клик. Мы модифицировали его для работы с пользовательскими свойствами и обновили пользовательский интерфейс, чтобы ускорить экспорт для наших конкретных нужд.

Настройка рабочего процесса проектирования уровней для Breachers потребовала больших временных затрат, но мы уверены, что это был правильный выбор для проекта. А еще это было очень весело!
По мере того как мы создавали игру, начиная с первых блоков и заканчивая альфа-тестированием и месяцами, предшествующими финальному релизу, итерации над нашими уровнями проходили быстро и безболезненно. Мы смогли избавить наших дизайнеров и художников от лишней работы и переложить на них обязанности, для выполнения которых им раньше потребовался бы разработчик.
Мы были впечатлены способностью Unity и Blender так гладко интегрироваться друг с другом, и мы уверены, что эта интеграция сыграла решающую роль в создании игры Breachers, которой мы довольны и гордимся тем, что можем поделиться с миром.
Спасибо, что прочитали, и наслаждайтесь игрой!

Breachers от Triangle Factory уже в продаже. Ознакомьтесь с другими блогами разработчиков Made with Unity здесь.
