Godot для разработки игр уровня AA/AAA — чего не хватает?

Автор: Хуан Линецкий, 16 января 2023 г.

Скоро выйдет Godot 4.0. Он включает в себя значительные улучшения по всем направлениям в функциях, производительности и удобстве использования. Тем не менее, один из самых больших вопросов, который возникает у сообщества: как это соотносится с обычными коммерческими предложениями?

Улучшения Годо 4.0

Рендеринг

Godot 4.0 имеет совершенно новую архитектуру рендеринга, которая разделена на современные и совместимые серверные части.

Современный делает рендеринг через RenderingDevice (который реализован в таких драйверах, как Vulkan, Direct3D 12 и других в будущем). Кроме того, современная серверная часть может реализовывать методы рендеринга , такие как прямой кластерный, мобильный и другие в будущем (например, отложенный кластерный, кинематографический и т. д.).

Серверная часть совместимости основана на OpenGL ES 3.0 / OpenGL 3.3 / WebGL 2.0 и предназначена для работы на очень старом оборудовании ПК, а также на большинстве старых (все еще работающих) мобильных телефонов.

Рендеринг значительно более эффективен в Godot 4.0, используя алгоритмы, ориентированные на данные, для обработки отбраковки объектов и вторичных буферов команд, а также автоматическую пакетную обработку для эффективной отправки примитивов рисования.

Предлагаемые функции также намного больше напоминают игры AAA, такие как гораздо больше вариантов материалов и расширенные визуальные эффекты (включая круговую глубину резкости , объемный туман, AMD FSR и т. д.). Кроме того, Godot 4.0 поддерживает передовые методы глобального освещения, такие как лайтмэппинг (в том числе SH лайтмэппинг), Voxel GI (полностью работающий в реальном времени) и SDFGI (решение GI с открытым миром в один клик). Экранное пространство GI можно использовать для еще большего повышения реалистичности.

Физика

После неудачной попытки использовать Bullet Godot 4.0 возвращается к своему собственному физическому движку, который, несмотря на то, что он не является высококлассным физическим движком, таким как PhysX, стремится предложить пользователям гораздо большую гибкость и возможности «просто работает».

Начиная с версии 3.x, в Godot Physics было добавлено несколько функций, таких как поддержка мягких тел и цилиндрической формы, а также несколько оптимизаций для использования нескольких потоков.

В пользовательском физическом движке все еще остается значительное количество проблем, но мы прилагаем все усилия, чтобы обеспечить его приемлемое состояние для выпуска, когда 4.0 достигнет стабильности. После этого улучшения будут продолжаться в течение следующих циклов выпуска 4.x.

Тем не менее, Godot 4.0 предоставляет возможность связывания пользовательских физических движков во время выполнения (без перекомпиляции Godot) через GDExtension, поэтому сообщество вполне может интегрировать другие движки, такие как PhysX, Jolt или Box2D, если это необходимо.

Сценарии

Godot 4.0 имеет новую версию GDScript, которая намного мощнее и устраняет большинство недостатков версии 3.x. В основном, добавление лямбда-выражений, первоклассных функций/сигналов и значительно уменьшенная зависимость от строковых идентификаторов (которые подвержены ошибкам). Он также имеет более полезные встроенные типы данных, такие как целочисленные векторы.

Ядро

Ядро движка было значительно оптимизировано, особенно в области памяти и данных. Core и Variant были значительно очищены и стали более расширяемыми. Помимо того, что основная кодовая база стала быстрее и современнее, теперь ее значительно проще поддерживать и расширять.

GDExtension

Благодаря новой системе GDExtension теперь можно расширять Godot и добавлять в него функции практически на любом языке и без перекомпиляции движка. Помимо Godot C++ (который упрощает расширение Godot так же просто, как с помощью модулей, но допускает подключаемые динамические надстройки), в работе есть и другие привязки, такие как Python, Rust, Go и т. д.

Намного больше

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

Итак, чего не хватает?

Не заблуждайтесь: в Godot еще многого не хватает для комфортного использования в больших проектах и командах. Тем не менее, осталось гораздо меньше работы, чем для Godot 3.x.

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

Эти проблемы будут исправлены в точечных выпусках 4.x (что мы теперь намерены делать чаще, позволяя выпускать несколько выпусков в год). Может пройти еще год или даже два, пока все не станет таким прочным и быстрым, как все ожидают. См. эту статью о наших планах на 4.0 и более поздние версии.

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

Потоки

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

Многие игры до сих пор используют этот подход (в конце концов, если он не сломан, не чините его), но все чаще гейм-дизайн движется от «отдельных этапов» к «открытым» или «непрерывным» мирам, где границы между уровнями пропадать. В результате создание игр таким образом становится более сложной задачей.

В настоящее время для этого используется технология, называемая «стриминг». Это означает, что ресурсы извлекаются с диска по запросу (загружаются только тогда, когда они необходимы), а не как часть более крупного этапа. Наиболее распространенные типы потоковой передачи:

• Потоковая передача текстур: по умолчанию все текстуры загружаются в маленьком размере. По мере того, как текстуры приближаются к камере, версии с более высоким разрешением (или мип-карты) передаются с диска. Вместо этого освобождаются текстуры, которые не использовались для некоторых кадров. В любой момент времени загруженные текстуры (и их детализация) точно отражают место, в котором находится игрок.
• Потоковая передача сетки : модели загружаются с низкой детализацией (мало вершин). По мере того, как они постепенно приближаются к камере, версии с более высоким разрешением передаются с диска. Модели, которые не использовались (не отображались) какое-то время, часто просто освобождаются и при необходимости загружаются снова.
• Потоковое воспроизведение анимации . Современные игры имеют длинные ролики, для которых требуется много анимационных данных. Для загрузки этих анимаций требуется много памяти, и их загрузка занимает много времени. Чтобы избежать этого, анимация передается в потоковом режиме, обычно сохраняя первую или две секунды в памяти, а затем новые разделы загружаются по запросу во время воспроизведения анимации. Godot 4.0 поддерживает сильное сжатие анимации и анимационные страницы, так что большая часть работы уже сделана.
• Потоковое аудио . Подобно потоковой передаче анимации, для этого требуется сохранить первую или две секунды аудио, а затем передать остальную часть непосредственно с диска.

Из вышеперечисленного большинство относительно просты в реализации. Наиболее сложной является потоковая передача сетки , которую обычно необходимо реализовывать вместе со стратегией отбраковки графического процессора, чтобы гарантировать, что очень большое количество моделей может быть отрисовано без затрат ЦП. Это более или менее то, что такие техники, как Nanite , делают в Unreal, хотя Godot не нужно реализовывать что-то настолько сложное, чтобы его можно было использовать в большинстве случаев.

Потоковая передача — самая важная функция, которой не хватает для управления большими сценами или открытыми мирами. Без него пользователи Godot будут долго загружаться (поскольку каждая текстура, модель и анимация должны загружаться до того, как что-либо будет показано). Также существует риск нехватки памяти, если слишком много ресурсов загружается параллельно, а не в потоковом режиме.

Низкоуровневый доступ к рендерингу

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

Философия Godot всегда заключалась в том, чтобы решать наиболее распространенные варианты использования и оставлять дверь открытой для пользователей, чтобы они могли самостоятельно решать менее распространенные .

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

Система задания сцены

Большая часть работы, проделанной для Godot 4.0, включала в себя значительные улучшения функций и производительности всех серверов (рендеринг, физика, навигация и т. д.). Серверы также теперь многопоточные и оптимизированы. Даже загрузка ресурсов теперь может выполняться в многопоточном режиме (с использованием нескольких потоков для загрузки нескольких ресурсов).

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

Узлы сцен в Godot в основном предназначены для выполнения сложных высокоуровневых поведений (таких как деревья анимации, кинематические персонажи, IK, скелеты и т. д.) для ограниченного количества объектов (не более сотен). В настоящее время многопоточности не происходит вообще, и используется только одно ядро hellЦП. Это делает его очень неэффективным.

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

Рои

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

Это необходимо для некоторых типов игровых механик, таких как:

• Снаряды (например, bullet hell).
• Юниты в некоторых типах стратегических игр с тысячами существ, бродящих по карте.
• Автомобили/люди в городских симуляторах, где тысячи появляются по всему городу.
• Симуляторы в стиле песочницы.
• Сложные пользовательские частицы, работающие на процессоре.
• Стаи, рои, мобы, мусор и т.д.

Более опытные программисты могут использовать серверы напрямую или даже подключать код C++ для выполнения тяжелой работы. ECS часто также предлагается в качестве решения для этого. Даже вычисление на GPU (полностью поддерживаемое в Godot) можно легко использовать для решения этой проблемы.

Но чтобы сделать Godot доступным и простым в использовании, идея состоит в том, чтобы создать роевую систему , которая позаботится о рендеринге/физике и т.д. в большом количестве этих объектов, и пользователю нужно только заполнить логику кода.

Поддержка VCS большой команды

Форматы текстовых файлов Godot очень удобны для контроля версий. Они пишут только то, что необходимо (без лишней информации), сохраняют порядок разделов и достаточно просты, чтобы понять изменения, просто взглянув на diff. Некоторые другие технологии также работают в этой области.

Несмотря на это, этого далеко не достаточно для совместной работы большой команды. Для этого необходимо улучшить поддержку Godot VCS в нескольких областях:

• Лучшая интеграция с доком файловой системы.
• Лучшее обновление активов в реальном времени, если они были изменены извне (и извлечены).
• Поддержка разрешений и блокировки файлов: Git не поддерживает это из коробки, но Git LFS и Perforce поддерживают. Эта функция важна для больших команд, чтобы избежать конфликтов и защитить файлы от непреднамеренных изменений (например, член команды модифицирует код или сцену, которой он не владеет по ошибке).

Если поддержка этого не будет надежной, использование Godot в больших командах будет затруднено.

Магазин платных ассетов

В то время как для очень крупных студий это не представляет интереса, студии среднего размера по-прежнему полагаются на значительное количество ресурсов и готовых функций. Библиотека ассетов, существующая в настоящее время в Godot, связана только с ресурсами с открытым исходным кодом (например, размещенными на GitHub или GitLab) и не может использоваться для коммерческих ассетов.

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

Достаточно ли решения этих проблем, чтобы Godot стал топовым игровым движком АА/ААА?

Ответ - «всё зависит от ситуации». Godot, по своей сути, есть и всегда будет (по замыслу) игровым движком очень общего назначения. Это означает, что предоставленные инструменты, хотя и способны, по-прежнему нейтральны для игры. Цель Godot — предоставить отличный набор строительных блоков, которые можно использовать и комбинировать для создания более специализированных игровых функций и инструментов.

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

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

Итак, о каких особенностях идет речь?

Шаблоны и поведение для конкретных игр

Например, Unreal поставляется с контроллером игрока, контроллером среды и множеством инструментов для управления темпом и ходом игры. Скорее всего, предназначен для игр TPS / FPS, которые являются наиболее популярным типом игр, созданных с помощью движка.

Некоторые из них можно найти в качестве шаблонов в библиотеке активов Godot, но они не имеют такой функциональности. В конце концов, должны быть созданы официальные, более мощные и полные.

Визуальный редактор кода

Хотя в прошлом у Godot были визуальные сценарии, мы обнаружили, что форма, которую мы внедрили, на самом деле не соответствовала потребностям сообщества, поэтому она была удалена.

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

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

Специализированные интерфейсы художников

При выполнении таких задач, как редактирование шейдеров, VFX (частицы) или анимация, существует большая разница между Godot и такими движками, как Unreal.

Разница не столько в поддерживаемых функциях. На самом деле, набор функций довольно похож! Основное фактическое различие заключается в том, как они представлены пользователю.

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

• Узел GPUParticles.
• Ресурс GPUParticlesMaterial (или даже дополнительный выделенный шейдер).
• Ресурс сетки для каждого прохода частицы.
• Ресурс материала сетки для каждой поверхности сетки (или даже дополнительный выделенный шейдер).

В качестве другого примера, AnimationTree в Godot требует, чтобы AnimationNodes располагались в виде дерева. Они могут экспортировать параметры, секции можно использовать повторно (потому что они являются ресурсами) и т.д.

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

Это делает Godot чрезвычайно мощным движком, который дает разработчикам большую гибкость, но…

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

Напротив, такие движки, как Unreal, имеют полностью выделенные и изолированные интерфейсы для каждой из этих задач (материалы, кинематографическая временная шкала, VFX, анимация и т. д.).

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

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

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

Значит, мы даже не близки?

Хотя цель этой статьи — прояснить, насколько важна оставшаяся работа, чтобы сделать Godot предложением, более близким к предложениям в коммерческом сегменте, важно не забыть одну ключевую деталь:

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

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

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

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

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

Будущее

Я надеюсь, что эта статья прояснила, почему Godot является такой ключевой технологией для будущего игровой индустрии. Мы продолжим усердно работать над тем, чтобы все больше и больше людей и компаний находили Godot полезным! Но нам нужна ваша помощь, поэтому, пожалуйста, рассмотрите возможность пожертвования проекту .