При создании любой игры у разработчика встаёт вопрос о выборе игрового движка для основы. Кто-то решит написать свой игровой движок, но на сегодняшний день большинство выберет готовое решение.
Однако есть очень тонкий момент. Можно просто взять и создать игру на коленке. Такое часто делают начинающие разработчики игр. Никакого планирования, никакой предварительной подготовки. С этим подходом, при должном усердии вполне можно создать какую-нибудь игру про копание ямы на заднем дворе.
Но что, если игра немного сложнее, а игровой мир больше и разнообразнее? Правильно! Мир разделяют на отдельные локации! И дело тут не только в ограниченной производительности старых компьютеров, во времена которых выходили такие игры, как Half-life.
Мощности старых компьютеров легко хватило бы даже для создания огромных миров при грамотном подходе. Но у всего есть пределы. Нельзя просто взять и создать большой мир. Особенно во времена 16-ти битных и 32-битных процессоров, физически не способных проводить вычисления с достаточной точностью, для приемлемого функционирования таких миров.
Можно пойти на хитрости и эмулировать значения высокой точности, но это сильно ударит по производительности. Такие хитрости даже для современных вычислительных устройств порой выходят боком. Но погодите! Были же игры вроде Wold of Warcraft, Aion, Lineage и тому подобные! И там миры не маленькие!
|
|
|
Но вот нюанс. MMORPG игры довольно нетребовательны к точности, ведь управление происходит от третьего лица. Игроки просто не обращают внимания на мелкие детали. А сами миры хоть и выглядят огромными, но по факту меньше, чем выглядят, а так же зачастую разбиты на несколько отдельных загружаемых локаций.
Полагаю, каждый пытался переплыть море в World of Warcraft без помощи специального транспортного корабля или телепорта, но их ждало только разочарование, ибо игра убивала таких игроков. Это один из способов маскировки ограниченности игрового мира. Просто не подпускать игрока к границам локации.
И, по правде сказать, даже старый мир игры WoW выглядит как проблема для «современного» игрового движка под названием Godot Engine. Почему? Ну... Просто это типичный Опен-Сорс.
Почти все знают про Linux от мира Open-Source. Почти никто в здравом рассудке, по своей воле не станет использовать эту «операционную систему» вместо Windows, какой бы плохой не становилась последняя. Так было 30 лет назад, так было 10 лет назад и так есть сейчас. Linux многим даже даром не сдался. Что бы не рассказывали ярые приверженцы.
Так и с игровым движком Godot Engine. Существует уже больше десяти лет, но многим и даром не нужен такой движок. Может, это происки злых корпораций? Заговоры? Или пользователи слишком глупые? Наверняка, пользователи просто глупые! Такой прекрасный и бесплатный движок не хотят использовать! Что это, если не глупость?
На самом деле всё намного проще. Как и подавляющее большинство софта от мира Open-Source, игровой движок Godot Engine создан не для пользователей, а скорее, вопреки пользователям. В любом нормальном игровом движке есть какие-то базовые ресурсы вроде точки появления игрока. Которую можно поставить в игровом мире и сразу начать играть. Это, конечно, в общем плане. Но только не в Godot Engine. Там придётся самому конструировать игрока из говна и палок. В этом весь Open-Source.
Но это всё ерунда. При желании можно поднатужиться изучив язык программирования и слепить игрока. Как и решить множество прочих подобных моментов. Настоящие проблемы возникают, когда разработчик желает реализовать действительно полноценный игровой мир и при этом соблюсти вменяемый масштаб локаций без жёстких условностей, вроде городов состоящих из трёх домов, по шесть полигонов на каждый.
Допустим, я хочу создать игровой мир на планете диаметром почти 13 тысяч километров. В специализированной программе Blender такую планету создать получается без особых проблем.
Но что произойдёт, если планету вставить в игровой движок Godot Engine в полном масштабе? Ничего хорошего. Даже в масштабе 10% на поверхности такой планеты просто невозможно находится и передвигаться без сильных рывков. Даже элементарный поворот камеры приводит к тому, что объекты в поле видимости начинают смещаться как попало. Такой эффект можно наблюдать у старой PlayStation 1, когда вершины объектов плавают, из-за низкой точности процессора без FPU модуля.
|
|
|
Только сейчас мы имеем дело не с древней PlayStation 90-х годов выпуска, эпохи зарождения потребительской 3D графики, а с «современным» игровым движком! А ведь это была одна десятая от необходимого размера мира. И уже такие серьёзные проблемы...
Как там дела у других игровых движков? Вдруг я просто нагоняю суету? Давайте возьмём Unreal Engine 5 в качестве подопытного! Ничего страшного не происходит, даже если планету вставить в полном масштабе. Физика работает без проблем, управление без дефектов. Движок справляется, даже несмотря на координаты по оси Z, переваливающие за 638 миллионов единиц.
|
|
|
Godot Engine уже при координатах 640 тысяч единиц работает крайне неадекватно. Хотя Unreal Engine 5 не идеально точно отображает столь массивную модель на таком расстоянии. Но это единственная замеченная неточность. И фактически ничего не значит, ибо модель можно сделать более точной при желании или вообще не использовать при приближении к ней, заменяя более точными локациями в нужных местах.
|
|
|
Так что я не просто так навожу суету, как некоторые могли подумать. Unreal Engine — действительно современный игровой движок. Он без особых проблем справился с задачей. Игровой движок Godot Engine разрабатывали, судя по всему, далеко не самые компетентные люди, ибо допустили фатальную ошибку в самом корне движка. Классика Open-Source...
Они не просто использовали 32-битный тип данных для хранения координат, но и делают это запихиванием трёх осей в одну 32-битную структуру, когда любой адекватный разработчик игрового движка сделал бы это тремя переменными для каждой оси в отдельности. Тогда и 32-битного Int хватило бы для нормальной работы с вменяемой точностью при гораздо больших мирах, чем способен сейчас Godot.
Отсюда и такая паршивая точность, не позволяющая создавать адекватные по размерам игровые миры. Уже на координатах более 4096 начинаются первые заметные проблемы. Какое решение предлагают разработчики? Как почти в любом «Опен-Сорсе»: Берите бубен в руки и компилируйте всё сами!
|
|
|
Более предусмотрительные разработчики скомпилировали бы версию движка, пригодную для полноценного использования, и выложили бы в раздел загрузок. Но только не разработчики Godot Engine.
Я даже попытался скомпилировать Godot в Debian 10, чтобы не совсем ущербная обратная совместимость с Линуксами была, но столкнулся с типичными мёртвыми репозиториями. А ведь без репозиториев невозможно собрать набор зависимостей, необходимых для компиляции.
Но даже отыскав перемещённые репозитории (привет хвалёная стабильность Линуксов!) и после установив весь набор необходимых зависимостей для компиляции по инструкциям из Интернета, хвалёный «дряхлый пингвин», просто сломался и дальше окна авторизации не смог запуститься... На этом было решено отложить компиляцию «современного» игрового движка до лучших времён, если не уйду на Unreal Engine 5.
В итоге, судя по всему, Godot Engine так и останется инструментом для создания GUI приложений и тонны мусора, заполоняющего игровые торговые площадки. Но не для создания полноценных игр.
Впрочем, попытаюсь ещё раз собрать Godot Engine из исходного кода, на этот раз в чуть менее мёртвом Debian версии 11. Только скорость линуксоидских репозиториев меня совсем не радует.
Я пытался найти уже скомпилированные версии Godot Engine с двойной точностью, но, увы, не нашёл. Потому беру бубен в руки и компилирую сам. Такое вот сообщество у линуксоидов. Якобы кто-то да сделает. Ага, конечно... Это действительно много времени занимает, и не факт, что всё получится как надо. А потом некоторые искренне не понимают, почему это Линукс многим и даром не сдался вместе со свободным и открытым софтом.
О чём я и говорил...
Ладно, ладно... Пошла компиляция! На удивление, это не самый мракобесный процесс компиляции софта. Я бы даже похвалил разработчиков Godot Engine за относительную простоту компиляции исходного кода. Жаль, они не удосужились это сделать вместо меня, пользователя...
Компиляция внутри виртуальной машины заняла внушительные 23 минуты времени.
И оно работает. Правда, редактор сам по себе бесполезен. Нужно ещё скомпилировать шаблоны экспорта.
Было много страшных предупреждений. Однако мне удалось собрать шаблон экспорта, потратив всего 15 минут времени. А теперь скажите, почему я не должен быть возмущён распространением софта в виде исходного кода, вместо нормальных исполняемых файлов?
|
|
|
А потом скомпилировал заново редактор Godot с параметром Production, ибо с ним меньше весит и быстрее работает. Так написано в инструкциях. Короче, в общей сложности потрачено больше двух часов времени на компиляцию игрового движка из исходного кода, включая создание виртуальной машины и подбор подходящего Линукса. Даже не знаю, был ли смысл компилировать с флагом Production? Размер слегка меньше, а запускается, на глаз, одинаково.
Хотя простой тест показал, что Production версия работает на 11 процентов быстрее. Так что не зря компилировал повторно!
|
|
|
Осталось проверить на тестовом проекте.
Хорошо, что мой предыдущий ноутбук, с Ryzen 7 4800H вместо процессора, скончался по вине короткого замыкания в чипе Radeon RX 5600M. Иначе я замучился бы ждать импорт некоторых моделей «массой» около четырёх миллионов примитивов. Unreal Engine, к слову, с такими моделями справляется заметно быстрее.
Аллилуйя! В масштабе 10 процентов от необходимого, явных проблем больше нет. Только модель слегка плавает. Но это было и в Unreal Engine. Главное — сам игровой мир работает теперь как положено.
|
|
|
Даже на координатах в 6 с лишним миллионов я не заметил очевидных проблем в работе движка. Unreal Engine, конечно, точнее передавал саму модель планеты, но в остальном всё нормально работает. Это уже относительно пригодно для создания нормальных игр.
На координатах в 640 миллионов единиц движок уже не смог сохранить дееспособность. Есть заметные проблемы с точностью. Всё же это не уровень Unreal Engine. Увы...
|
|
|
Для наглядности создаю платформу с коллизией. Но при запуске камера проваливается под платформу. Не хватает точности движку, на столь отдалённых координатах.
|
|
|
Осталось проверить функционал экспорта проекта. Обычные шаблоны тут подойдут, но возникнут проблемы с точностью после экспорта игры. Потому подкидываю скомпилированный шаблон с двойной точностью. При смене физического движка происходит сохранение и перезапуск редактора, но сцена сохраняется неправильно... Будто Godot пытается центрировать объекты по координатам в низкой точности. Пришлось перенести камеру на внушительное расстояние, чтобы она оказалась не на одной координате с платформой.
|
|
|
Я не знаю, как эту проблему лечить. В редакторе с точностью визуально вроде как порядок, значки только неадекватно прыгают при движении. Но при попытке поиграть возникают серьёзные проблемы. Проблемы не решились даже при создании нового проекта. Хотя на координатах 640 тысяч игра ведёт себя вполне адекватно.
Это, конечно, довольно печальный уровень точности. До уровня Unreal Engine очень далеко. Но намного лучше того, что предоставляют разработчики игрового движка в разделе загрузок на официальном сайте. Полагаю, теперь Godot будет нормально работать примерно до пяти миллионов единиц по координатам игрового мира.
Чтобы мои труды не потерялись зря, было решено упаковать скомпилированный Godot Engine Double Precision в распространяемый формат Installer-SH. Первым делом копирую шаблон экспорта в локальный домашний каталог. Изначально я думал оставить программу на свободе, но потом передумал. Лучше пусть сидит в своей песочнице, тем более мусорит довольно много.
В процессе настройки установочного пакета, меня посещали мысли о неправильности происходящего. Потому было решено потратить ещё часик-другой на компиляцию всех основных шаблонов экспорта для Linux и Windows.
Для мобильных устройств не буду ничего собирать. Там хватит и официальных вариантов с низкой точностью. Наверное. Кому надо, пусть компилируют сами. А потом у меня закончилось место на диске прямо во время компиляции одного из шаблонов экспорта. Следом посыпалась часть Линукса, ибо виртуальная машина находилась на системном диске. Придётся компилировать заново для надёжности.
Так гораздо лучше.
Можно упаковать архив с приложением.
Устанавливаем Godot Engine с помощью Installer-SH.
Проверяем!
Загрузил проект и всё работает. Даже шаблоны экспорта не нужно руками подкидывать, так как уже встроено всё в выделенный домашний каталог для Godot Engine. Теперь игровой движок не будет создавать помойку в основном домашнем каталоге.
При этом установочный пакет весит 91 МБ, что не так уж и много, учитывая, что в распакованном виде имеем около 440 МБ.
Осталось только загрузить установочный пакет в Chimbalix-Software-Catalog, чтобы мне и другим людям не приходилось снова заниматься таким же мракобесием с компиляцией движка из исходного кода.
https://github.com/Shedou/Chimbalix-Software-Catalog/releases/tag/godot441_dp
Очень жаль, что это всё приходиться делать пользователю, то есть мне. Хотя на самом деле, это обязанность разработчиков софта — донести свой софт до пользователей в удобном для использования виде.
Кто-то в оправдание скажет, мол, что я просто наезжаю на Godot Engine без причин. На самом деле, это якобы прекрасный движок для новичков! Звучит здраво, но ситуация в корне вредоносная. Ведь новички не знают таких специфических особенностей движка. Они тратят силы и время на изучение, а когда пытаются создать полноценную игру, внезапно выясняется, что движок не так хорош, как про него заявляли.
Во что эта ситуация выливается? Правильно! Разработчик вынужден плясать с бубном, как я сейчас плясал, и, окончательно разочаровавшись, вынужден бросить все свои знания и труды и просто перейти на Unreal Engine или Unity. Ведь Godot слишком неточный для реализации серьёзных проектов. Так, побаловаться, и зря потратить время на изучение. Я не могу советовать Godot Engine к изучению и использованию для создания игр, ибо это будет зловредный совет, учитывая серьёзные проблемы с точностью самого движка.
Самое печальное то, что разработчики могут нормально скомпилировать движок, но не делают этого. Предлагают пользователям откровенно ущербную версию, что, вероятно, проигрывает в точности даже давно устаревшим движкам. Кто-то скажет, мол, возьми и скомпилируй с двойной точностью! Но знали бы экологи про таких умников, учитывая, что на компиляцию было потрачено порядка трёх или четырёх часов времени и усердной работы компьютера. А это электроэнергия, на секундочку.
И так каждый пользователь в отдельности, должен сидеть компилируя исходный код программы. И далеко не у каждого энергоэффективный процессор в компьютере. Представляете, сколько это выброшенной в окно электроэнергии чисто на компиляцию софта из хвалёных исходников? Я даже рад, что Open-Source с философиями компиляции из исходников скорее мёртв, чем жив.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.