Почему игровой движок Godot Engine непригоден для разработки перспективных проектов

Обычно игровые движки вроде Unity и Unreal Engine не являются бесплатными и свободными. Нельзя, просто взять и воспользоваться ими как захочется. С другой же стороны, стоят свободные Open-Source игровые движки вроде Godot Engine. Хотя я и не могу припомнить ничего вменяемого, кроме Godot в этой области. Сейчас мы поговорим о том, почему Godot Engine практически не подходит для создания перспективных проектов, как и многие прочие инструменты из разряда Open-Source. Для наглядности я возьму свой собственный проект под названием ChimbaBench.

Я могу открыть проект в Godot Engine 3.6 и продолжить работу несмотря на то, что изначально он разрабатывался в предыдущих версиях Godot 3.x. Всё логично.

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

Но у Godot Engine 3 есть проблемы. Одна из таких проблем — это плохая работа с OpenGL API. В режиме GLES3 можно столкнуться с проблемами на старых видеокартах, потому что движок, скорее всего, выходит за спецификации OpenGL 3.3. Это нестрашно с видеокартами уровня GeForce GTX 400+ и Radeon HD 5000+, но плохо с видеокартами Radeon HD 3000-4000 и GeForce 8000-9000 серии.

И если с видеокартами GeForce 8000-9000 серии многие проблемы решаются последними версиями драйверов от NVIDIA, то в случае Radeon решений нет, так как AMD постоянно бросает потребителей с поддержкой в кратчайшие сроки после выпуска видеокарт. Плохая поддержка и кривые официальные драйверы AMD — одна из причин, почему в среде Linux видеокарты Radeon иногда лучше работают, чем в среде Windows. Всё же в Линуксе драйверами занимаются посторонние люди. Хотя и тут AMD пыталась влезть своими разработчиками в проект Mesa3D, что лишь прибавило проблем.

Также у всех версий Godot Engine есть проблема обратной совместимости со старыми операционными системами. В случае Linux основное препятствие кроется в зависимости от GLIBC версии минимум 2.28 для Godot 4, GLIBC 2.17 для старых версий Godot 3 и GLIBC 2.15 для Godot 2.

Если проекты, разработанные в Godot Engine 3.5 можно запустить в Debian 8 выпущенном в 2015 году, то проекты на основе Godot Engine 4 уже потребуют Debian 10 выпущенный в 2019 году. Я не говорю про все версии Godot 3 только потому, что версия 3.6 уже требует GLIBC 2.28 вместо 2.17. Иначе говоря, разработчики испортили и так плохую обратную совместимость с дистрибутивами Linux. То же может произойти и с Godot 4.

Хотя я и называю это плохой обратной совместимостью, но прочий софт для Linux и такой совместимости зачастую не имеет. Некоторый софт для Linux уже не способен работать даже в актуальном Debian 12. Это прямо влияет на охват пользователей.

В случае Windows ситуация намного лучше. Начиная с Windows 7 выпущенной в 2009 году, работает Godot Engine. И этого достаточно для охвата подавляющего большинства пользователей. Но иногда нужна поддержка Windows XP, на что официальные версии движка уже не способны. Даже самые старые. Впрочем, никто не мешает потанцевать с бубном над исходным кодом и собрать версию для Windows XP. Только вот заниматься таким делом мало кто захочет.

Впрочем, охват Windows пользователей у Godot Engine вполне хороший. Только вот, в среде Linux, есть ощутимые проблемы. Но это же Линукс. От этого мракобесия, выдаваемого за операционную систему, почти никто и так ничего хорошего не ждёт. Теперь же перейдём к действительно серьёзным проблемам, которые сильно мешают разработке перспективных проектов.

Допустим, разработчик начал свой перспективный проект ещё во времена Godot 2. Для примера я набросал очень простой проект с десятком строк исходного кода. Потом выходит Godot 3 с поддержкой OpenGL 3.3, когда старый движок работал только с OpenGL 2.1.

Что произойдёт, если разработчик захочет получить преимущества новых графических API, обновив движок до новой версии? Да ничего! Godot 3 даже не видит проект, разработанный в движке прошлой версии. Нужно начинать всё с нуля.

Но даже если создам новый проект и попытаюсь воспользоваться старыми файлами, движок просто не поймёт их.

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

Мне удалось воссоздать крайне простой проект в новой версии движка. Но стоило ли оно затраченных усилий? Сомневаюсь.

Но вдруг выходит Godot 4 с поддержкой Vulkan API и я хочу этот же проект перенести на новый движок. Что произойдёт? Движок уже рекомендует провести конвертацию проекта. Звучит многообещающе.

Настолько простой проект действительно конвертировался под новую версию движка, хотя и работает не так, как было в предыдущей версии. Сразу можно отметить потерянный Environment (небо и окружение).

Но что, если мы возьмём не самое простейшее из возможных, а реальный рабочий проект?

Вот тут и начинается веселье. Язык GDScript так сильно меняется, что даже базовые функции движка отказываются работать, потому что были изменены. Почему игровой движок автоматически не преобразовал настолько элементарные вещи? Без понятия. Но факт есть факт. Реальный проект практически невозможно преобразовать под новую версию движка Godot.

Это уже не ChimbaBench, а что-то поломанное и нерабочее.

Движок настолько плохо преобразует проекты, что даже не осилил правильно преобразовать окружение, где было настроено небо и освещение. Поэтому сверху, мы получили чёрное окно вместо графики.

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

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

Помимо визуальных проявлений, есть и технические. Теперь не работают ограничения fps в нужных местах. Но это мелочи. Куда страшнее поломанные функции запуска сторонних утилит, благодаря которым осуществлялся запуск утилит для сбора и показа информации о системе. До кучи имеем ошибки «Invalid Call» на ровном месте, потому что Godot Engine сильно изменился, а преобразование проектов не работает должным образом.

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

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

Хотя Unreal Engine 5 и требует Glibc 2.28 как Godot 4, но разница в возможностях просто колоссальная. Что в первом делается двумя кликами мыши, во втором может потребовать полного написания функционала с нуля. Ещё и сам движок придётся доработать и скомпилировать заново.

Может ли Godot Engine сравниться с тем же Unreal Engine? Приверженцы всякого линуксоидного Open-Source хлама, вероятно, скажут да. Мол, бери исходники и делай хоть лучше, чем у Unreal Engine. Но нужны ли, эти неистовые пляски с бубном в линуксоидном стиле, разработчикам игр? Вопрос риторический.

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

Хотя я и не использую всем известный движок Unity для какой-либо разработки, но очень сомневаюсь, что используемый там язык c# и структура движка настолько сильно меняется, что нужно чуть ли не заново переучиваться при переходе на новые версии.

Ещё стоит вопрос необходимости перехода на новые версия движка. В случае Unreal Engine и Unity такой необходимости обычно нет, так как они изначально реализованы избыточно функциональными и готовыми к использованию. Тот же Genshin Impact, насколько я помню на 2023 год, вообще на Unity 2017 года работал, и это не мешает разработчикам значительно развивать игру.

В случае Godot Engine ситуация совершенно иная, как в Линуксах — бесконечная гонка за функционалом, которого кот наплакал. При этом пользователя всегда преследует бесконечная тень ошибок, неудобств и проблем. Потому что так исторически сложилось в хвалёном Open-Source.

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

Впрочем, есть и хорошая сторона функциональной несостоятельности. Это маленький размер исполняемых файлов и портативность. Тот же редактор Unreal Engine занимает у меня около 63 гигабайт места на диске, что несравненно много, как и разница в возможностях.

Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.