Godot — это как Unity, но лучше и дешевле
С чего всё началось
Эта статья претендует не на объективное сравнение движков, А НА УЛЬТИМАТИВНО-СУБЪЕКТИВНУЮ БАЗУ. Наверняка многие испытают такие же мысли при изучении Godot и эта статья будет им полезна.
Начать надо с причины, по которой я вообще начал знакомство с Godot после 8 лет опыта работы с Unity. Это была блокировка аккаунта UnityHub по причине «бла-бла-бла, двухфакторная авторизация, трёхфакторная идентификация, пользователь, иди в жопу». Пожав плечами, я скачал Godot и начал готовиться к тяжёлому и муторному переносу проекта на совершенно новый движок. Мне было не впервой делать это. Всего три месяца назад я начал масштабный рефакторинг своего проекта LesOiseauxDuGuerre. Кто не знает — это пошаговая конспирологическая стратегия про джиннобойную артиллерию и многоэтажки на бройлерных окорочках. Процесс рефакторинга сразу превратился в переписывание проекта с нуля на Unity Built-in Render Pipeline вместо URP. Я рассудил, что BiRP имеет больше возможностей, чем URP, несмотря на заверения разработчиков Unity в обратном. Зря я в первый раз корпоратам поверил…
С замиранием сердца кликаем по ярлыку...
Первые впечатления от Godot — это скорость загрузки. От клика по ярлыку до рабочего редактора проходит 4 секунды, в то время как для Unity этот параметр в худшем случае составляет три дня. Наконец, перед глазами интерфейс. Первая мысль — а шо, не так уж и плохо, в чём-то даже хорошо! Есть чёткое разделение между 3D-режимом редактора и 2D-режимом, между которыми можно переключаться как между вкладками в браузере. В Unity игровой интерфейс до сих пор является частью 3D-сцены со всеми вытекающими последствиями.
Структура проекта основана на нодах. Главное отличие от Unity GameObject — это отсутствие компонентов, которые можно неограниченно навешивать на объект. Вместо этого надо добавлять дочерние узлы, которые определяют поведение сущностей. Хочешь, чтобы объект имел визуал? Добавь дочернюю ноду MeshInstance3D. Надо столкновение? Добавь CollisionShape3D. С некоторой натяжкой можно сказать, что дочерние ноды являются заменой компонентов. Эта система сделана настолько удобно и красиво, что ограничения Godot быстро теряются на фоне общего благолепия.
И, пока не забыл, у Godot очень красивый и логичный интерфейс.
Они даже догадались сделать значки нод разного цвета в зависимости от их типа! И есть поиск свойств ноды, иерархическое отображение свойств и многое другое.
Плюсы Godot по сравнению с Unity
- Бесплатность! Полная! Абсолютная!
- Быстродействие. И время запуска, и время компиляции, и время экспорта проекта. Всё, что можно делать быстро, Godot делает быстро. За то, что быстро сделать нельзя, он даже не берётся.
- Огромное количество настроек стандартного материала. Их настолько много, что необходимость писать свои шейдеры наступает весьма нескоро.
- Кстати, о шейдерах — их можно писать как кодом, так и визуально, совсем как в Unity Shader Graph. Только, в отличие от Unity, в Godot не приходится выбирать между ними.
- Интуитивная понятность GUI. Я разобрался с вертикальной компоновкой кнопок быстрее, чем в Unity, несмотря на многолетний опыт работы с ним. Вы не ослышались: в движке, который я запустил в первый же день, я быстрее сделал компоновку GUI, чем в Unity.
- CompositorEffect. Это как Renderer Feature из Unity, только написанный душевно здоровыми людьми. Идейно это та же сущность: набор эффектов, которые последовательно добавляются к исходному кадру. Но главным плюсом, как и минусом, является доступ к графическому API на низком уровне. Почти всё — выделение памяти, передача параметров в шейдер, настройка параметров запуска — надо делать вручную. Казалось бы, что в этом хорошего? На словах в Unity Renderer Feature сделан гораздо проще и удобнее — да вот только работает он не так, как должен. Но на самом деле высокоуровневый подход Unity только запутывает, в то время как Godot не отходит от уровня железа. А там всё описано в спецификации Vulkan. Сложно, но предсказуемо. А ещё CompositorEffect можно назначать на уровне сцены, а не глобально для проекта.
- В редакторе может быть открыто множество сцен, между которыми можно переключаться в любой момент как между вкладками.
- Документация! В движке есть справка! Можно навести мышку на любое свойство и появиться окошко с подробным описанием его! Ну где ещё можно такую прелесть увидеть...
Минусы (актуальные для меня)
- Магазин ассетов гораздо беднее, чем в Unity.
- Нет прямого аналога unitypackage для экспорта сцены со всеми зависимостями.
- Работа с мешами и меш-коллайдерами неудобна.
- Как и работа с ресурсами (текстуры, 3D-модели и т.д.).
- При запуске проекта нельзя посмотреть, как выглядит сцена из редактора, и визуально её исправлять (перетаскивать объекты и т.д.). После запуска в режиме отладки становится доступна иерархия объектов запущенной игры, которую можно редактировать как угодно. А посмотреть из редактора нельзя. То есть трогать можно, а смотреть нельзя. Странная ситуация. Как в стрип-клубе, но только наоборот.
- Более ограниченная работа с буфером трафарета (stencil buffer). Нельзя проверять, совпадает ли значение буффера с A и при совпадении записывать в него B.
- Нет прямого аналога RenderTexture как текстуры, которую можно изменять при помощи шейдера. Subviёwport — это немного не то. Он не заставляет сердце биться чаще и далеко не так удобен. Заодно сюда я записываю низкоуровневые функции библиотеки GL.
- Нет VFX Graph, как в Unity. Встроенная система частиц гораздо слабее. Единственная вещь, по которой я скучаю.
Сомнительные вещи (не плюсы и не минусы)
- Гораздо более простой язык шейдеров. С одной стороны, их писать проще и удобнее, но есть вероятность, что не хватит возможностей языка для выражения всех идей.
- Наличие двух различных языков программирования: GDScript (основной) и C#. Само наличие в движке любых конкурирующих сущностей является проблемой, потому что разработчикам надо поддерживать все из них. Одна из них может перетягивать на себя внимание, а другой придёт в упадок к недовольству разработчиков, привыкших к нему. Unity уже постигла эта беда с созданием трёх независимых конвейеров рендеринга (с подозрением кошусь на режимы рендера Forward+, Mobile и Compatibility в Godot).
- Встроенные скрипты. С одной стороны, это удобно — не надо для всякой мелочи создавать свой класс C#. Но я всё равно недовольно надуваю губы, только причину пока не придумал.
Вывод
В целом Godot полностью соответствует главному требованию, предъявляемому к игровым движкам — молча делать то, для чего он создан. С небольшими усилиями можно привести процесс разработки до уровня Unity. Отсутствие последних графических технологий можно рассматривать как достоинство, ведь новые функции порой ломают то, что работало раньше. Стабильность важнее инноваций, а удобство — важнее новаторства. Поиск свойств ноды по названию важнее, чем трассировка лучей. А небольшие сложности при переходе на Godot успевают решиться ДО того, как они начинают раздражать.
Вывод из сравнения движков такой: Godot — это когда многое ломается, но потом легко чинится. Стоил ли переход на него потраченного времени? Определённо да!