Godot что это

Godot — это не новая Unity. Анатомия вызова API в Godot

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

Я, как и многие другие, в последнее время активно ищу «новую Unity». У Godot есть потенциал, особенно если на платформу удастся привлечь талантливых разработчиков, которые обеспечили бы её стремительное развитие. Это одна из самых крутых черт свободного ПО. Но здесь есть серьёзная проблема, сдерживающая развитие Godot: связующий уровень, проложенный между кодом движка и кодом геймплея, структурно рассчитан именно на медленную работу. Такое устройство кода очень сложно исправить, не снося всю конструкцию до основания и не перестраивая API целиком с нуля.

На Godot уже были разработаны некоторые успешные игры, поэтому, конечно же, вышеперечисленные факторы не являются непреодолимыми. Но в Unity в течение последних пяти лет ведётся работа по ускорению работы сценариев, и ради этого было запущено несколько проектов один другого страннее: создано два собственных компилятора, написаны математические ОКМД-библиотеки, разработаны собственные коллекции и аллокаторы. Разумеется, нужно упомянуть и о гигантском (и в основном незаконченном) проекте ECS. Техническое руководство Unity стратегически придерживается этой линии развития с 2018 года. Определённо, команда Unity считает, что для значительной части пользовательской аудитории быстродействие сценариев — ключевой фактор. Поэтому, переключаясь на Godot, я не просто перечёркиваю то, что было сделано в Unity за последние 5 лет — нет, всё гораздо хуже.

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

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

Подробно разберём, как реализуется бросание лучей на C#

Далее подробно разберём, как в Godot реализуется функция, эквивалентная Physics2D.Raycast из Unity, и что происходит под капотом при использовании этой функции. Чтобы немного конкретизировать изложение, давайте для начала реализуем тривиальную функцию в Unity.

Unity

// Простое бросание лучей в Unity bool GetRaycastDistanceAndNormal(Vector2 origin, Vector2 direction, out float distance, out Vector2 normal)

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

public static RaycastHit2D Raycast(Vector2 origin, Vector2 direction) => defaultPhysicsScene.Raycast(origin, direction, float.PositiveInfinity); public RaycastHit2D Raycast(Vector2 origin, Vector2 direction, float distance, [DefaultValue("Physics2D.DefaultRaycastLayers")] int layerMask = -5) < ContactFilter2D contactFilter = ContactFilter2D.CreateLegacyFilter(layerMask, float.NegativeInfinity, float.PositiveInfinity); return Raycast_Internal(this, origin, direction, distance, contactFilter); >[NativeMethod("Raycast_Binding")] [StaticAccessor("PhysicsQuery2D", StaticAccessorType.DoubleColon)] private static RaycastHit2D Raycast_Internal(PhysicsScene2D physicsScene, Vector2 origin, Vector2 direction, float distance, ContactFilter2D contactFilter) < Raycast_Internal_Injected(ref physicsScene, ref origin, ref direction, distance, ref contactFilter, out var ret); return ret; >[MethodImpl(MethodImplOptions.InternalCall)] private static extern void Raycast_Internal_Injected( ref PhysicsScene2D physicsScene, ref Vector2 origin, ref Vector2 direction, float distance, ref ContactFilter2D contactFilter, out RaycastHit2D ret);

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

Godot

// Эквивалентное бросание лучей в Godot bool GetRaycastDistanceAndNormal(Vector2 origin, Vector2 direction, out float distance, out Vector2 normal) < World2D world = GetWorld2D(); PhysicsDirectSpaceState2D spaceState = world.DirectSpaceState; PhysicsRayQueryParameters2D queryParams = PhysicsRayQueryParameters2D.Create(origin, origin + direction); Godot.Collections.Dictionary hitDictionary = spaceState.IntersectRay(queryParams); if (hitDictionary.Count != 0) < Variant hitPositionVariant = hitDictionary[(Variant)"position"]; Vector2 hitPosition = (Vector2)hitPositionVariant; Variant hitNormalVariant = hitDictionary[(Variant)"normal"]; Vector2 hitNormal = (Vector2)hitNormalVariant; distance = (hitPosition - origin).Length(); normal = hitNormal; return true; >distance = default; normal = default; return false; >

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

Для начала вызовем GetWorld2D() . В Godot все физические запросы выполняются в контексте игрового мира, и эта функция принимает тот мир, в котором выполняется наш код. Хотя World2D относится к управляемым классам, эта функция не делает никаких безумных вещей, в частности, не выделяет память всякий раз, когда мы ее запускаем. Ни одна из этих функций не должна делать ничего странного, если задача её — просто обеспечить бросание лучей, правильно?

Если заглянуть в эти вызовы API, то сразу видно, что даже очевидно простейшие из них – как, например, этот — реализуются при помощи довольно затейливых механизмов, и каждая такая операция сказывается на производительности, пусть и немного. Давайте в качестве примера разберём GetWorld2D , в частности, проясним некоторые вызовы, выполняемые на C#. Примерно так и выглядят все вызовы, возвращающие управляемые типы. Чтобы было понятнее, что тут происходит, я добавил в код комментарии.

// Это функция, которую мы подробно разбираем public World2D GetWorld2D() < // MethodBind64 – это указатель на функцию, которую мы вызываем в C++. // MethodBind64 хранится в статической переменной, поэтому перед тем, как извлечь его, нужно выполнить поиск в памяти. return (World2D)NativeCalls.godot_icall_0_51(MethodBind64, GodotObject.GetPtr(this)); >// Мы вызываем эти функции, опосредующие вызовы API. internal unsafe static GodotObject godot_icall_0_51(IntPtr method, IntPtr ptr) < godot_ref godot_ref = default(godot_ref); // Механизм try/finally даром не даётся. Чтобы с ним работать, нужно ввести конечный автомат. // Кроме того, он может блокировать JIT-оптимизацию. try < // Этап валидации, пусть даже весь код здесь является внутренним, и ему следует доверять. if (ptr == IntPtr.Zero) throw new ArgumentNullException("ptr"); // Здесь мы вызываем другую функцию, которая, фактически, вызывает указатель // и при помощи этого указателя помещает результат в godot_ref. NativeFuncs.godotsharp_method_bind_ptrcall(method, ptr, null, &godot_ref); // Далее предусмотрены механизмы для перемещения объектов через границу C#/C++. return InteropUtils.UnmanagedGetManaged(godot_ref.Reference); >finally < godot_ref.Dispose(); >> // Функция, фактически вызывающая указатель функции. [global::System.Runtime.CompilerServices.MethodImpl(global::System.Runtime.CompilerServices.MethodImplOptions.AggressiveInlining)] public static partial void godotsharp_method_bind_ptrcall( global::System.IntPtr p_method_bind, global::System.IntPtr p_instance, void** p_args, void* p_ret) < // Но подождите! // Ведь _unmanagedCallbacks.godotsharp_method_bind_ptrcall – это акт обращения к ещё одной статической переменной, // чтобы извлечь ещё один указатель функции. _unmanagedCallbacks.godotsharp_method_bind_ptrcall(p_method_bind, p_instance, p_args, p_ret); >// Честно говоря, этот вопрос я не изучал достаточно подробно, поэтому не могу комментировать, что здесь происходит. // В общем виде идея проста – здесь мы принимаем указатель на неуправляемый GodotObject, // переносим его в .Net, уведомляем об этом сборщик мусора, чтобы данный объект можно было отслеживать и // приводим его к типу GodotObject // К счастью, по-видимому, никаких операций выделения памяти здесь не происходит public static GodotObject UnmanagedGetManaged(IntPtr unmanaged)

В сущности, это немалые издержки. У нас несколько уровней косвенности между нашим кодом и кодом на C++, которые мы создаём при преследовании указателя (pointer chasing). На каждом из этих этапов выполняется поиск в памяти, а сверх того приходится заниматься валидацией, try finally и интепретацией возвращённого указателя. Может показаться, что всё это — всего лишь мелкие несогласованности, но, если каждому направляемому в ядро вызову и каждой операции доступа к свойству/полю в объекте Godot приходится проделывать весь этот путь, то издержки начинают накапливаться.

Присмотревшись к следующей строке, где выполняется доступ к свойству world.DirectSpaceState , окажется, что многие из этих операций мы уже проделывали. При помощи всё той же машинерии объект PhysicsDirectSpaceState2D опять вытягивается с территории C++. Не волнуйтесь, деталями вас утомлять не стану!

А вот следующая строка первая в этом коде, которая реально меня озадачила.

PhysicsRayQueryParameters2D queryParams = PhysicsRayQueryParameters2D.Create(origin, origin + direction);

Что тут может быть интересного, это же просто небольшая структура, в которую упакованы параметры бросания лучей, верно? Нет. PhysicsRayQueryParameters2D — это управляемый класс, а с точки зрения сборщика мусора — это как раз источник мусора, под который постоянно выделяется память. Настоящее безумие — оставлять такую штуку на оживлённом пути, на котором особенно критично выдавать максимальную производительность. Но ведь можно быть уверенным, что память здесь выделяется всего один раз, верно? Давайте-ка посмотрим, что внутри.

// Резюме: // Возвращает новый, заранее сконфигурированный объект Godot.PhysicsRayQueryParameters2D. С его // помощью быстро создаются параметры запроса, для этого применяются самые обычные опции. // var query = PhysicsRayQueryParameters2D.create(global_position, global_position // + Vector2(0, 100)) // var collision = get_world_2d().direct_space_state.intersect_ray(query) public unsafe static PhysicsRayQueryParameters2D Create(Vector2 from, Vector2 to, uint collisionMask = uint.MaxValue, Array exclude = null) < // Да, тут задействуются всё те же механизмы, что рассмотрены выше. return (PhysicsRayQueryParameters2D)NativeCalls.godot_icall_4_731( MethodBind0, &from, &to, collisionMask, (godot_array)(exclude ?? new Array()).NativeValue ); >

Ох. А вы тоже заметили?

Этот Array — массив Godot.Collections.Array . Это ещё один тип управляемого класса. Посмотрите, что происходит, если мы передаём ему значение null .

(godot_array)(exclude ?? new Array()).NativeValue

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

Чтобы передать два простых значения Vector2 (16 байт) функции бросания лучей, нам требуется выделить из кучи две отдельные порции данных общим объёмом 632 байта!

Как будет показано ниже, эту проблему можно сгладить, кэшируя PhysicsRayQueryParameters2D . Но, как вы уже понимаете из документирующего комментария, которым я снабдил код, API явно ожидает (и рекомендует) создавать свежие экземпляры для каждого акта бросания лучей.

Перейдём к следующей строке. Куда уж безумнее, правда?

Godot.Collections.Dictionary hitDictionary = spaceState.IntersectRay(queryParams);

Действительно, в результате бросания лучей возвращается нетипизированный словарь. И, да, он является источником мусора, так как выделяет в управляемой куче ещё 96 байт. Хотел бы я сейчас видеть, как вы озадачены и растеряны. «О, так, может быть, он хотя бы возвращает null , если ни на что не наткнётся? Нет. Если он ничего не найдёт, то он выделит и вернёт пустой словарь.

Здесь давайте перейдём непосредственно к реализации на C++.

Dictionary PhysicsDirectSpaceState2D::_intersect_ray(const Ref &p_ray_query) < ERR_FAIL_COND_V(!p_ray_query.is_valid(), Dictionary()); RayResult result; bool res = intersect_ray(p_ray_query->get_parameters(), result); if (!res) < return Dictionary(); >Dictionary d; d["position"] = result.position; d["normal"] = result.normal; d["collider_id"] = result.collider_id; d["collider"] = result.collider; d["shape"] = result.shape; d["rid"] = result.rid; return d; > // Это структура с параметрами, которую принимает внутренняя функция intersect_ray. // Здесь ничего особо безумного (хотя, exclude, вероятно, можно было бы доработать). struct RayParameters < Vector2 from; Vector2 to; HashSetexclude; uint32_t collision_mask = UINT32_MAX; bool collide_with_bodies = true; bool collide_with_areas = false; bool hit_from_inside = false; >; // А вот вывод. Совершенно нормальное возвращаемое значение для ситуации с бросанием лучей. struct RayResult < Vector2 position; Vector2 normal; RID rid; ObjectID collider_id; Object *collider = nullptr; int shape = 0; >;

Как видите, тут обёрнута очень хорошо сделанная функция бросания лучей, только работает она безбожно медленно. Эта функция intersect_ray является внутренней, но она должна быть в API!

Этот код C++ выделяет нетипизированный словарь в неуправляемой куче. Если мы пристальнее в него заглянем, то, как и следовало ожидать, найдём там хеш-таблицу. Для инициализации этого словаря выполняется шесть операций поиска (при некоторых из них даже могут выполняться дополнительные выделения, но настолько подробно я в теме не разбирался). Но, подождите-ка, это ведь нетипизированный словарь. Как это работает? Используемая здесь внутренняя хеш-таблица отображает Variant на Variant.

Уф. Что еще за Variant ? Действительно, данная реализация довольно сложная, но, упрощённо говоря, это большое размеченное объединение (один экземпляр), куда включены все возможные типы, которые могут содержаться в этом словаре. Можно сказать, что перед нами динамический нетипизированный тип. В данном случае нас интересует, каков его размер — оказывается, 20 байт.

Так, хорошо, значит, каждое из этих «полей», которое мы записываем в словарь, имеет размер 20 байт. Ключи тоже такие. Помните те значения Vector2 по 8 байт? Теперь они по 20 байт. А те int? Тоже по 20 байт. Идею вы уловили.

Просуммировав размеры всех полей в RayResult , мы получим 44 байта (если предположить, что размер каждого указателя равен 8 байт). Если просуммировать размеры всех ключей Variant и значений, содержащихся в словаре, то получится 2 * 6 * 20 = 240 байт! Но, подождите-ка, ведь это хеш-таблица. В хеш-таблицах данные хранятся не компактно, поэтому реальный размер, занимаемый этим словарём в куче, будет, как минимум, вшестеро превышать размер тех данных, которые мы хотим вернуть, а, возможно, и гораздо сильнее.

Ладно, давайте вернёмся к C# и посмотрим, что происходит, когда мы возвращаем эту штуку.

// Функция, которую мы вызываем public Dictionary IntersectRay(PhysicsRayQueryParameters2D parameters) < return NativeCalls.godot_icall_1_729(MethodBind1, GodotObject.GetPtr(this), GodotObject.GetPtr(parameters)); >internal unsafe static Dictionary godot_icall_1_729(IntPtr method, IntPtr ptr, IntPtr arg1) < godot_dictionary nativeValueToOwn = default(godot_dictionary); if (ptr == IntPtr.Zero) throw new ArgumentNullException("ptr"); void** intPtr = stackalloc void*[1]; *intPtr = &arg1; void** p_args = intPtr; NativeFuncs.godotsharp_method_bind_ptrcall(method, ptr, p_args, &nativeValueToOwn); return Dictionary.CreateTakingOwnershipOfDisposableValue(nativeValueToOwn); >internal static Dictionary CreateTakingOwnershipOfDisposableValue(godot_dictionary nativeValueToOwn) < return new Dictionary(nativeValueToOwn); >private Dictionary(godot_dictionary nativeValueToOwn)

В первую очередь тут нужно отметить следующие вещи. Во-первых, мы создаём на C# новый управляемый словарь (да-да, и он тоже оставляет мусор при работе), а в этом словаре содержится указатель на тот словарь, что был создан в куче C++. Эх, хотя бы нам не приходится копировать содержимое этого словаря! На данном этапе пытаемся экономить на всём, где только можем.

Окей, так что же дальше?

if (hitDictionary.Count != 0) < // Приведение от строки к Variant может быть неявным – здесь я делаю его явным, чтобы было понятнее Variant hitPositionVariant = hitDictionary[(Variant)"position"]; Vector2 hitPosition = (Vector2)hitPositionVariant; Variant hitNormalVariant = hitDictionary[(Variant)"normal"]; Vector2 hitNormal = (Vector2)hitNormalVariant; distance = (hitPosition - origin).Length(); normal = hitNormal; return true; >

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

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

Если мы попадаем в какую-либо преграду, то с каждым полем, которое мы хотим прочитать, проделываем следующие операции:

Приводим ключи string к структурам C# Variant (это же делает и вызов, направляемый в C++)
Преследуем ещё некоторые указатели функций, которые требуется вызывать в C++ — теперь нам уже привычно, как именно это происходит.
Выполняем поиск в хеш-таблице, чтобы получить тот Variant , в котором содержится наше значение (естественно, это делается путём преследования указателя функции)
Копируем эти 20 байт обратно на территорию C# (да, даже хотя мы читаем значения Vector2, в которых всего по 8 байт)
Извлекаем значение Vector2 из Variant (да, здесь также приходится преследовать указатели до самого it C++, чтобы выполнить это преобразование)

Итак, приходится проделать немало работы, чтобы вернуть 44-байтовую структуру и прочитать пару полей.

Можно ли тут что-то улучшить

Кэширование параметров запроса

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

readonly struct CachingRayCaster < private readonly PhysicsDirectSpaceState2D spaceState; private readonly PhysicsRayQueryParameters2D queryParams; public CachingRayCaster(PhysicsDirectSpaceState2D spaceState) < this.spaceState = spaceState; this.queryParams = PhysicsRayQueryParameters2D.Create(Vector2.Zero, Vector2.Zero); >public bool GetDistanceAndNormal(Vector2 origin, Vector2 direction, out float distance, out Vector2 normal) < this.queryParams.From = origin; this.queryParams.To = origin + direction; Godot.Collections.Dictionary hitDictionary = this.spaceState.IntersectRay(this.queryParams); if (hitDictionary.Count != 0) < Variant hitPositionVariant = hitDictionary[(Variant)"position"]; Vector2 hitPosition = (Vector2)hitPositionVariant; Variant hitNormalVariant = hitDictionary[(Variant)"normal"]; Vector2 hitNormal = (Vector2)hitNormalVariant; distance = (hitPosition - origin).Length(); normal = hitNormal; return true; >distance = default; normal = default; return false; > >

Считаем: после первого луча удаляется 2/3 выделений памяти C#/GC на луч и 632/738, если перевести это в байты. Ситуация всё равно не так хороша, но, тем не менее, это прогресс.

Что насчёт GDExtension?

Как вы, возможно, слышали, Godot также предоставляет API для C++ (или Rust, или другого нативного языка), позволяющий нам писать высокопроизводительный код. Нам это здесь как раз пригодится, правда? Правда?

Оказывается, GDExtension предоставляет точно такой же the API. Ага. Можно писать быстрый код на C++, но всё равно вы получаете API, возвращающий нетипизированный словарь с раздутыми значениями Variant. Ситуация немного лучше, так как здесь можно не беспокоиться о сборке мусора, но… сейчас опять будет повод взгрустнуть, готовьтесь.

Совершенно иной подход — с узлом RayCast2D

Подождите! Действительно, ведь можно поступить совершенно иначе.

bool GetRaycastDistanceAndNormalWithNode(RayCast2D raycastNode, Vector2 origin, Vector2 direction, out float distance, out Vector2 normal)

Здесь показана функция, принимающая ссылку на узел RayCast2D в данной сцене. Как понятно из названия, это узел сцены, осуществляющий бросание лучей. Он реализован на C++, поэтому не проходит через вышеупомянутый API и не несёт всех издержек, связанных со словарями. Это довольно неуклюжий способ реализовать бросание лучей, поскольку нам нужна ссылка на узел в сцене, которую мы можем как хотим менять. Чтобы выполнить запрос, нам потребуется переставить узел в сцене. Но сначала давайте заглянем внутрь.

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

public Vector2 Position < get =>GetPosition() set => SetPosition(value); > internal unsafe void SetPosition(Vector2 position) < NativeCalls.godot_icall_1_31(MethodBind0, GodotObject.GetPtr(this), &position); >internal unsafe static void godot_icall_1_31(IntPtr method, IntPtr ptr, Vector2* arg1)

Теперь давайте посмотрим, что именно делает ForceRaycastUpdate() . Уверен, что код C# вам теперь вполне понятен, так что давайте углубимся в C++.

void RayCast2D::force_raycast_update() < _update_raycast_state(); >void RayCast2D::_update_raycast_state() < Refw2d = get_world_2d(); ERR_FAIL_COND(w2d.is_null()); PhysicsDirectSpaceState2D *dss = PhysicsServer2D::get_singleton()->space_get_direct_state(w2d->get_space()); ERR_FAIL_NULL(dss); Transform2D gt = get_global_transform(); Vector2 to = target_position; if (to == Vector2()) < to = Vector2(0, 0.01); >PhysicsDirectSpaceState2D::RayResult rr; bool prev_collision_state = collided; PhysicsDirectSpaceState2D::RayParameters ray_params; ray_params.from = gt.get_origin(); ray_params.to = gt.xform(to); ray_params.exclude = exclude; ray_params.collision_mask = collision_mask; ray_params.collide_with_bodies = collide_with_bodies; ray_params.collide_with_areas = collide_with_areas; ray_params.hit_from_inside = hit_from_inside; if (dss->intersect_ray(ray_params, rr)) < collided = true; against = rr.collider_id; against_rid = rr.rid; collision_point = rr.position; collision_normal = rr.normal; against_shape = rr.shape; >else < collided = false; against = ObjectID(); against_rid = RID(); against_shape = 0; >if (prev_collision_state != collided) < queue_redraw(); >>

Кажется, что тут много чего творится, но это только на первый взгляд. Если внимательно рассмотреть этот код, то видно, что структурно он практически аналогичен нашей первой функции GetRaycastDistanceAndNormal на C#. Она получает игровой мир, состояние, собирает параметры, вызывает intersect_ray для выполнения фактической работы, а затем записывает результат в наши свойства.

Но взгляните! Никаких выделений кучи, нет Dictionary и нет Variant . Вот так уже лучше. Можно предположить, что этот код будет работать гораздо быстрее.

Померяем время

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

Как было показано выше, функция RayCast2D.ForceRaycastUpdate() очень близка к самому минималистичному вызову intersect_ray из движка, обслуживающего игровую физику, так что давайте возьмём эту функцию в качестве отправной точки. Не забывайте, что и в этом вызове есть издержки, связанные с преследованием указателей. На каждой контрольной точке мы прогоняем 10 000 итераций тестируемой функции, с предварительным прогревом и фильтрацией выбросов. Сборку мусора я на время тестирования отключил. Такой бенчмаркинг игр мне нравится проводить на сравнительно слабом железе, поэтому, если попытаетесь воспроизвести мои тесты, то ваши результаты получиться даже лучше. Но нас в данном случае интересуют относительные числа.

В качестве модели возьмём простую сцену, в которой для столкновений предусмотрен круг, и наш луч в этот круг всегда попадает. Мы хотим измерить издержки на связывание, а не производительность игрового движка как такового. Мы имеем дело с задержками отдельных лучей, они измеряются в наносекундах, и поэтому числа могут получаться нелепо маленькими. Чтобы лучше проиллюстрировать, насколько они важны, также указываю кадровую частоту и указываю, сколько раз функция может быть вызвана в пределах одного кадра при кадровой частоте 60 кадр/сек и 120 кадр/сек, если в программе не делается ничего сверх тривиального бросания лучей.

Метод

Время (μs)

Базовый множитель

Кадровая частота (60 кадр/сек)

Кадровая частота (120 кадр/сек)

Выделение GC (байт)

ForceRaycastUpdate (скорость движка не важна)

Можно ожидать, что в типичном движке/API, чтобы максимально быстро бросать лучи, нужно использовать функцию, предназначенную именно для того, что описано в документации как канонический вариант. Как видим, если так поступить, то издержки на связывание/API приводят к тому, что код работает в 50 раз медленнее, чем «сырой» движок игровой физики. Ой!

Работая с тем же самым API, но разумно (пусть и иногда неизящно) подходя к кэшированию, можно сократить вышеупомянутые издержки до шестнадцатикратных. Уже лучше, но всё равно страшно.

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

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

На самом деле, в нижней части диапазона эти числа очень скудные. В моих нынешних проектах требуется более 344 актов бросания лучей на кадр. Разумеется, одним бросанием лучей работа в кадре не ограничивается. Этот тест — тривиальная сцена с единственной фигурой для столкновений. Но, если речь заходит о бросании лучей для выполнения реальной работы в более сложной сцене, то числа могли бы быть ещё ниже! Если бросать лучи стандартным способом, так, как это описано в документации, то вся игра намертво застопорится.

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

Чисто для интереса я также проделал бенчмаркинг Unity. Там делается полноценное рабочее бросание лучей с установкой параметров и извлечением результатов, всё примерно за 0,52 μs. До учёта присутствующих в Godot издержек на связывание оказывается, что скорость работы у ядер Unity и Godot оказывается сопоставимой.

Может быть, я тенденциозен

Когда я разместил тот тред на reddit, нашлось немало людей, которые говорили, что API игровой физики донельзя плох, поэтому по нему нельзя судить обо всём движке целиком. Честно, я совершенно не пытался выбрать API похуже — просто так получается, что именно бросание лучей я первым делом попробовал выполнить, взявшись разбираться с Godot. Правда, может быть, я немного лукавлю, поэтому давайте это проверим.

Если бы я хотел специально выбрать метод похуже, то долго искать бы мне не пришлось. Прямо рядом с IntersectRay находятся IntersectPoint и IntersectShape , для которых свойственны всё те же проблемы, что и для IntersectRay, а также ещё одна безуминка: дело в том, что, имея множественные результаты, они возвращают выделенный в куче управляемый Godot.Collections.Array ! O, кстати, этот Array — на самом деле типизированная оболочка, в которую обёрнут Godot.Collections.Array . Поэтому каждая 8-байтная ссылка на словарь на самом деле хранится в виде 20-байтного Variant . Конечно же, я выбрал не самый плохой метод в API!

Если просканировать весь API Godot (при помощи рефлексии C#), то, оказывается, что здесь не так много сущностей, которые возвращали бы Dictionary . Получается эклектичный список, где есть, в частности, метод AnimationNode._GetChildNodes , свойство Bitmap.Data , свойство Curve2D._Data (и 3D), некоторые вещи в GLTFSkin , кое-какой материал из TextServer , некоторые элементы NavigationAgent2D , т.д. Ни в одном из этих мест не годится иметь медленные словари, выделяемые в куче, но? даже на фоне всех вышеперечисленных методов, API игровой физики особенно плох.

Правда, мой опыт подсказывает, что во всём движке мало найдётся таких API, которые использовались бы столь же активно, как и физический. Если посмотреть вызовы API движка в моём коде геймплея, то оказывается, что примерно 80% из них приходятся на физику и преобразования.

Также не будем забывать, что Dictionary — всего лишь часть проблемы. Если чуть шире посмотреть, какие сущности возвращают Godot.Collections.Array (напомню: они выделяются в куче, по содержимому как Variant ), то найдётся масса деталей из физики, работы с игровыми сетками, геометрией, навигацией, картами замощений, рендерингом и многим другим.

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

Так почему же мы до сих пор в ожидании Godot?

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

Если рассмотреть, как написанное на C++ ядро Godot предоставляет свой API, то найдётся кое-что интересное.

void PhysicsDirectSpaceState3D::_bind_methods()

При помощи этого разделяемого механизма генерируются связки для всех трёх скриптовых интерфейсов: GDSCript, C# и GDExtensions. В ClassDB собирают указатели функций и метаданные по каждой из функций API, которые затем как по конвейеру передаются через различные системы генерации кода с целью генерации связок для каждого языка.

Таким образом, каждая функция API проектируется прежде всего для купирования ограничений GDScript. IntersectRay возвращает нетипизированный динамический словарь Dictionary, поскольку в GDScript не существует структур. В нашем коде на C# и даже коде на C++ для расширений GDExtensions за это приходится платить катастрофически высокую цену.

Такой способ обработки связок через указатели функций также сопряжён с существенными издержками: как мы уже видели, даже простые обращения к свойствам идут медленно. Напомню, что каждый вызов начинается с поиска в памяти (находится указатель на ту функцию, которую требуется вызвать). Затем выполняется ещё одна операция поиска, чтобы найти указатель на вторичную функцию (которая, собственно, и отвечает за вызов первой функции). На всём этом пути выполняется дополнительный валидационный код, ветвление и преобразования типов. В C# (и, очевидно, в C++) есть быстрый механизм для отправки вызовов в нативный код. Он называется P/Invoke, но в Godot этот механизм просто не используется.

Итак, в философии Godot заложена его медленная работа. Единственная практическая возможность взаимодействия с движком — через его слой связывания, но ядро движка спроектировано так, что просто не может работать быстро. Сколько ни оптимизируй реализацию Dictionary, ни ускоряй физический движок — не уйдёшь от того факта, что мы передаём туда‑сюда целый ворох значений, выделенных в куче, тогда как здесь следовало бы работать с крошечными структурами. Поскольку API C# и GDScript остаются синхронизированными, это неизменно тормозит развитие движка.

Окей, так давайте же это исправим!

Что можно сделать, не отступая от работы с имеющимся уровнем связывания?

Если предположить, что по-прежнему необходимо поддерживать совместимость GDScript со всеми нашими API, то всё равно остаётся несколько областей, в которых, пожалуй, можно что-то подправить, даже если получится и не очень красиво. Вернёмся к нашему примеру с IntsersectRay.

GetWorld2D().DirectStateSpace можно ужать с двух вызовов до одного, введя в код GetWorld2DStateSpace() .
Проблемы с PhysicsRayQueryParameters2D можно устранить, добавив такую перегрузку, при которой все поля принимаются как параметры. Всё это позволило бы нам примерно сравняться по производительности с CachedRayCaster (в 16 раз медленнее базовой), не прибегая к кэшированию.
От выделения Dictionary можно избавиться, разрешив передавать для записи такой словарь, который находится в кэше/пуле. По сравнению со структурами такой подход уродливый и неуклюжий, зато без выделений.
Процесс поиска в словаре до сих пор смехотворно медленный. Его можно было бы улучшить, возвращая класс с ожидаемыми свойствами. От операции выделения здесь можно было бы избавиться, применив кэш/пул так, как было описано в случае с Dictionary .

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

Также можно было бы улучшить код, сгенерированный для всех операций с преследованием указателей. Я пока детально не изучал этот вопрос, но, если там найдутся потенциальные выигрыши, то они будут применимы и в рамках всего API, и это будет круто! Как минимум, можно было бы убрать из релизных сборок валидацию и блоки try finally.

Что если бы было разрешено добавлять дополнительные API для C# и GDExtensions, такие, которые несовместимы с GDScript ?

Отлично, давайте поговорим об этом! Если мы считаем, что это возможно (может быть, это уже реализовано, но я точно не знаю), то, теоретически, можно было бы добавить к имеющимся связкам ClassDB другие, более качественные, которые взаимодействовали бы напрямую со структурами через полноценные механизмы P/Invoke. Таков путь к приемлемой производительности.

К сожалению, если продублировать весь API такими улучшенными версиями, то код превратится в огромную мешанину. Это можно было бы преодолеть, например, размечая сущности [не рекомендуется] и подталкивая пользователя в верном направлении, но из-за таких проблем как конфликты имён всё станет совсем уродливо.

А что, если снести всё до основания и сделать заново?

Безусловно, в краткосрочной перспективе такой вариант очень болезненный. Godot 4.0 вышел совсем недавно, а тут я говорю об обратной совместимости, ломающей весь redux API, практически о Godot 5.0. Правда, если быть честным с самим собой, то это единственный жизнеспособный вариант, который позволил бы года за три привести движок в порядок. Если бы мы смешивали медленные и быстрые API, так, как это описано выше, это стало бы для нас головной болью на многие десятилетия. Подозреваю, движок угодит как раз в эту ловушку.

А не кликбейтный ли заголовок у этой статьи? Может, я кого-то на слезу пробить хочу?

Может быть, немного. Но не слишком.

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

В некоторых проектах 95% нагрузки на ЦП даёт алгоритм, который даже не касается API движка. В таком случае, всё это не имеет значения (сборщик мусора важен всегда, но с ним проблемы можно решать при помощи GDExtensions). Во многих других случаях важно обеспечить качественную реализацию физики/столкновений в программе и вручную модифицировать свойства огромного количества объектов, что играют в проекте ключевые роли.

Многим просто важно знать, что такие вещи можно сделать, если потребуется. Может быть, вы два года занимались проектом, полагая, что в нём не потребуется ничего, кроме бросания лучей, но потом, на позднем этапе разработки игры, было решено реализовать какие-то элементы работы с ЦП, которые позволяли бы проверять столкновения. Это совсем небольшая красивость, но вдруг вам требуется обращаться к API движка — и у вас проблемы. Много слов сказано о том, как важно доверять движку и знать, что в будущем он сможет послужить вам опорой. В Unity есть проблема с мутными бизнес‑практиками, а в Godot — с производительностью.

Если Godot стремится повоевать с Unity на её основном рынке (кстати, я не знаю, стремится ли в самом деле), то в Godot требуются быстрые и фундаментальные изменения. Многие из вещей, рассмотренных в этой статье, для Unity-разработчиков просто неприемлемы.

Обсуждение

Я опубликовал эту статью в подреддите r/Godot, и там развернулась весьма активная дискуссия. Если вы пришли в этот пост с какого-то другого сайта, то не стесняйтесь высказываться и комментировать.

Благодарю

_Марио Босса с reddit за то, что он первым обратил моё внимание на фокус с узлами при работе с Raycast2D.
Джона Риччительо за то, что наконец‑то мотивировал меня подробнее исследовать другие движки.
Майка Бизелла за то, что позволил позаимствовать его шутку с предвидением. На самом деле, разрешения я не спрашивал, но он, по‑видимому, настолько добрый малый, что не стал искать меня и разбираться.
Фрейю Хольмер, так как при работе над этой статьёй было крайне забавно читать её жалобы о том, что в Unreal физика делается на уровне сантиметров. Жду, когда она перепугается, как и я, когда обнаружит, что в Godot есть такие единицы, как килограммы на пиксель квадратный. Кстати, одну из моих шуток всё‑таки заметили.
Клэнки с reddit за подсказку, что у меня случайно затесались наносекунды там, где должны быть микросекунды.

Godot Engine

Godot Engine — открытый кроссплатформенный игровой движок для разработки 2D/3D-видеоигр и приложений для ПК, мобильных устройств, веб-платформ. Адаптирован ко всем распространенным операционным системам, включая Linux, macOS, Windows, Android и iOS.

Освойте профессию «Разработчик игр на Unity»

Godot разработали в 2007 году два программиста из Аргентины — Хуан Линецкий и Ариэл Манзур. Первоначально его использовали несколько игровых студий Латинской Америки. В 2014 году разработчики выложили движок на GitHub по лицензии MIT. В декабре того же года вышла первая стабильная версия 1.0. С этого момента началось развитие проекта и его распространение в других странах.

Возможности Godot

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

Работа с двух- и трехмерной графикой — поддержка эффектов отражения, динамических теней, статичного и динамичного глобального освещения, полноэкранной постобработки (засветки, глубины резкости, гамма-коррекции и т.д.).
Поддержка реалистичной физики — системы частиц (дыма, тумана, пара, взрывов и т.д.), свойств динамичных и статичных тел, столкновений и разрушений, трассировки лучей и других физических процессов.
Работа с анимацией — опции создания скелетной анимации, наложения объектов, кат-сцен в реальном времени.
Сетка навигации (Navigation mesh) — алгоритм нахождения игровым агентом оптимального маршрута в сложном пространстве.
Поддержка мультимедиа — воспроизведение аудио- и видеофайлов с помощью подключаемых кодеков Theora, OGG Vorbis, WAV.
AR/VR — встроенный мобильный интерфейс дополненной и виртуальной реальности с использованием 3DOF-датчиков на телефоне.
Подключение устройств ввода — клавиатуры, мыши, геймпада и сенсорного экрана.
Процедурная генерация — автоматическое создание внутриигрового контента (окружения, NPC, объектов, оружия и т.д.) с помощью алгоритмов.
Поддержка языков — «Годо» имеет свой собственный высокоуровневый язык программирования GDScript, также можно использовать С# и C++.

Профессия / 18 месяцев
Разработчик игр на Unity

Создавайте виртуальные миры

Group 1321314346 (2)

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

Ключевые концепции Godot

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

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

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

Узлы различаются по своему назначению. Одни показывают изображение, другие отображают 3D-модели, третьи воспроизводят звук. Подключая один узел к другому, можно получать дерево узлов, обладающее более сложным функционалом. На этом строится основной принцип разработки игры.

Сцены. Это дерево иерархически соединенных друг с другом узлов. Имеет следующие атрибуты:

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

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

выступают в качестве префабов — «заготовок», задающих изначальную структуру и свойства для экземпляров;
вкладываются друг в друга — например, персонажа можно разместить на уровне, а в руки ему дать оружие или магический посох.

Дерево сцен. Это совокупность иерархически связанных сцен. Создаваемый в Godot проект (игры, приложение) — последовательность их выполнения. А сам движок — редактор, в котором разработчик продукта определяет порядок и способ исполнения взаимосвязанных сцен. При запуске проекта сначала инициируется основная (корневая) сцена, которая последовательно запускает остальные.

Разработчик игр на Unity – одна
из самых творческих профессий в IT. Создайте виртуальные миры уже через полгода обучения

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

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

Преимущества Godot

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

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

Поддержка сторонних языков. В ядро Godot уже встроена возможность работы на GDScript, C# и C++. Также модуль GDNative позволяет привязать к ядру движка код, написанный на других языках программирования. С помощью системы VisualScript программировать можно без кода, работая на уровне узлов. Это подходящий вариант для новичков не только в геймдеве, но и в программировании в целом.

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

Независимое 2D и 3D. Godot создавался как двухмерный игровой движок, 3D-редактирование появилось позже. Разработчики оставили для каждого режима свой редактор, а не стали использовать псевдодвухмерный. Возможность работы с пиксельным 2D упрощает разработку и оптимизацию двухмерных игр. Это ценят разработчики небольших инди-проектов.

Открытый исходный код. Godot — бесплатное программное обеспечение, распространяемое по лицензии MIT. Созданные игры и приложения являются собственностью разработчика. Кроме того, открытость движка способствует появлению множества расширений и инструментов. При отсутствии функции в ядре «Годо» ее можно получить, скачав подходящее дополнение с официального сайта или ресурсов, входящих в экосистему.

Кроссплатформенность. Godot существует в версиях для Windows, Mac, Linux, Android, iOS. Также есть поддержка универсальной платформы UWP от Microsoft, на которой можно разрабатывать приложения для Windows 10, Windows Mobile, Xbox One и виртуальной среды HoloLens без необходимости переписывать код под каждую ОС.

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

Недостатки Godot

Недостаточная проработка 3D. По этому параметру Godot уступает конкурентам вроде Unity или Unreal Engine. «Годо» развивался как 2D-движок, трехмерный редактор был добавлен позже. В последних версиях работа с 3D значительно улучшена.

Сложности с разработкой консольных приложений. Разработчики отмечают проблемы при создании или портировании «Годо»-игр на консоли. Это требует использования сторонних инструментов и большого опыта. Одна из возможных причин проблемы — закрытый характер консольных инструментов, что противоречит открытости самого движка.

Использование Godot

Открытый исходный код, простота и особенности редактора «Годо» сделали движок популярным в среде разработчиков инди-игр. Из известных гейм-девелоперов, использовавших его в своих проектах, — аргентинская компания OCAM Studio и LRDGames, Inc., выпустившая в 2021 году сатирическую стратегию Rogue State Revolution. Также этот движок применяется в разработке:

мобильных игр, в том числе многопользовательских (платформеров, пазлов, головоломок);
приложений — мультиплееров, планировщиков, музыкальных редакторов и т.д.

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

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

Разработчик игр на Unity

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

Godot Engine. Обзор игрового движка ⁠ ⁠

Godot Engine. Обзор игрового движка Разработка, Gamedev, Godot, Godot Engine, Игры, Компьютерные игры, Игровой движок, Длиннопост

Этот материал актуален для молодых игроделов –кто делает первые шаги в индустрии и мучительно выбирает движок. А также для тех разработчиков, кто устал вносить денежки владельцам проприетарного ПО и хотел бы пересесть на что-то подешевле.

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

Мною было приложено много усилий, чтобы обзор получился ёмким и более-менее объективным. Это не копипаста чьей-то более ранней статьи, обзор основан на личном опыте использования движка.

Немного истории

Разработкой движка Godot (читается «годо») с 2007 года занимались Хуан Линетски и Ариель Манзур. Стоит отметить, что в те бородатые времена движок был проприетарным, закрытым и создавался для нужд частных заказчиков.

В 2014 году авторы выпустили обновлённую версию движка под лицензий MIT и выложили исходники на GitHub, разработка перешла сообществу Godot Engine Community, и продолжается до сих пор.

Godot Engine – очень компактный (~74MB), быстрый и оптимизированный движок, позволяющий создавать с нуля любую игру любого жанра. Он кроссплатформенный, мультифункциональный, бесплатный, опенсорсный.

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

Он достаточно дружелюбен к новичкам. Элементы документации продублированы в трёх местах, что обеспечивает быстрый доступ к справке «без отрыва от производства». Так же в движок зашиты ссылки на он-лайн ресурсы, которые помогут вам в решении большинства проблем.

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

При этом базовая сборка не тащит за собой «ваще все библиотеки, которые только есть в природе» – вплоть до того, что в ней отсутствуют инструменты для билда. Godot – это конструктор. Он не знает, чем вы будете заниматься, поэтому предоставляет функционал разработки… и… всё! Остальное вы докачиваете сами по мере необходимости.

Периодически ~~в этих ваших интернетах~~ на форумах и у обзорщиков проскальзывает снисходительная ремарка «Godot – движок для первой игры, и всё». Это не так. Godot – высокоуровненвый профессиональный инструмент, достаточно дружелюбный, но своеборазный и сложный в освоении, если вы хотите нарисовать что-то сложнее пиу-пиу платформера.

Среда разработки

Godot «из коробки» обладает всеми необходимыми компонентами для разработки, отладки, тестирования и конструирования игры, не требует использования дополнительного ПО для создания программной и архитектурной составляющих (разумеется, вам в любом случае потребуются программы для создания визуального контента, звуковых ассетов, etc.).

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

Для воплощения ваших самых смелых идей он имеет 2D и 3D пространство со стандартным набором классов и объектов, а так же редактор скриптов и два редактора шейдеров — для прямого программирования и визуальной настройки. Поведение любого класса вы можете расширять и/или изменять по мере надобности.

Об особенностях рендера и визуальной среды ниже.

Редактор скриптов обладает возможностями дополнения кода, авто-отступами, подсветкой синтаксиса, быстрым доступом к API движка и докам.

Интерфейс приятный, лакончиный и довольно интуитивный:

Внутренние ресурсы проекта

Основным объектом для программных манипуляций является дерево «сцен» и «узлов». Узлом может являться как самостоятельный объект, так и группа объектов. Прелесть заключается в том, что любой из узлов в любой момент времени можно изолировать в самостоятельный компонент («сцену»). Поэтому при разработке можно быстро и безболезненно редактировать, масштабировать или полностью менять структуру проекта и/или его отдельных модулей.

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

Возможно, вам трудно осознать преимущества этого подхода, поэтому отмечу, что упрощённая система хранения данных обеспечивает лёгкий доступ всех членов команды разработчиков ко всем ассетам (мы не зависим от версии БД, текущей версии продукта и даже версии самого движка!), а так же сильно облегчается контроль версий — особенно если применяете внешние системы управления.

Godot исользует собственный высокоуровневый динамически типизированный скриптовый язык программирования — GDScript, который является ~~плодом порочной связи~~ гибридом Python и Lua.

Язык специализировался и оптимизировался под ранее упомянутую архитектуру систем сцен и узлов, однако если по какой-то причине вам хочется писать на другом языке (допустим, не хватает каких-либо инструментов, или вы просто не хотите осваивать новый синтаксис), Godot умеет интегрировать другие языки программирования, в частности C#, C++, Rust.

Помимо этого (начиная с версии 3.0) присутствует компонент для визуального программирования — Visual Scripting. Про него не могу ничего сказать, не приходилось пользоваться, но, думаю, это легко нагуглить.

Идеология движка имеет строгое ограничение: один узел — один скрипт. Однако, если вам необходимо менять поведение и/или состояние объекта в зависимости от игрвого состояния, Godot любезно предоставляет возможность заменять один скрипт на другой «на лету» или пользоваться внешними скриптами, которые вообще не привязаны ни к одному узлу — например, это могут быть списки оружия, брони и соответствующее им поведение, которое подхватывается из мирно дремлющего скрипта активным и применяется.

Визуализация

Графическая система — OpenGL ES. Для рендеринга 3D-сцен применяются технологии order-independent transparency, normal mapping, specularity, полноэкранные постэффекты типа FXAA, bloom, DOF, HDR, гамма-коррекции, distance fog, динамические тени на основе shadow maps и другие.

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

В отличие от многих других движков, которые имитируют 2D-среду на 3D пространцстве, 2D компонент Godot полностью изолирован, оптимизирован и имеет свой собственный набор классов и объектов. Следствием этого является компактность и быстродействие готового игрового продукта (мы не тащим с собой тяжёлые 3D-объекты и обвязку к ним там, где это не требуется), а так же удивительная лёгкость манипуляций с 2D компонентами в процессе разработки.

Помните, выше упоминалось, что Godot поддержит вас в любых самых сумасшедших начинаниях? 😉 Стартуя работу с 2D сценой, вы легко можете добавить в неё 3D объекты или целые блоки, воспользовавшись многоуровневой системой вьюпортов. Благодаря изоляции 2D и 3D пространства (и, разумеется, многопоточности) компоненты не мешают друг другу и не тормозят работу продукта. В обратную сторону это тоже работает 😉

Игровая физика

Физический движок для 2D и 3D тоже уникальный и разработан с нуля, что позволило добиться требуемого уровня оптимизации физической подсистемы. Реализованы возможности рейкастинга, обнаружение столкновений, динамики твёрдых тел и соединений между ними. Так же имеется обширный арсенал инструментов, осуществляющих кинематику.

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

К сожалению, в версиях движка 3.0 — 3.5 (к настоящему моменту самая свежая из стабильных) на 2D пространстве отсутствует физика частиц — поведение имитируется, оставаясь не более, чем визуальным эффектом. Честной физики мы тут не увидим. В Godot 4.0 этот компонент улучшен, но это всё ещё альфа — имейте это в виду, если захотите поиграть с физикой частиц в новой версии движка. Для 3D всё в порядке.

Напоминаю, для того, чтобы сбилдить проект вам сперва нужно скачать и настроить соответствующий компонент. Выбор при этом у вас впечатляющий. Godot поддерживает Windows (и UWP OS), MacOS, X11 (Linux, BSD), Android OS, iOS, HTML5. Также можно производить экспорт на другие платформы вручную через компилирование движка для SDK целевой платформы.

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

Подведём итоги

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

— не трубет установки;

— эффективное управление ресурсами компьютера;

— удобство для использования;

— быстрый доступ к справке и внешним библиотекам;

— возможность взаимодействия с компонентами управления из вашего скрипта (например, можно статистику смотреть не на выделенной панели, а вывести прямо во вьюпорт игры).

— скундый набор инструментов визуальной разработки;

— отсутсвие предустановленных тимплейтов;

— отсутствие встроенных инструментов для билда;

— неудобные инструменты вёрстки диалоговых окон;

— слабые AR/VR компоненты;

— осутствие физики для 2D частиц;

— отсутствие возможности редактирования мешей и уровней сглаживания;

— низкая популярность в России (очень мало материалов на русском языке).

Благодарю за внимание! Надеюсь, вам было интересно в общих чертах познакомиться с Godot. Если у вас остались вопрсы, можете задать их в комментах, постараюсь ответить на все 🙂

Всем хорошего дня, вдохновения и успехов в освоении Godot!

P.S.: Следующим постом выложу полезные материалы для новичков с кратким описанием полезности.

P.P.S.: К сожалению, невозможно запихать в один обзор всю полезную и интересную информацию, поэтому в перспективе планирую сделать подробное описание каждого блока с разбором функциональных компонентов. Пожалуйста, посигнальте в комментах, если эта информация вам интересна.

Поддержать

77 постов 240 подписчиков

Подписаться Добавить пост

Правила сообщества

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

1 год назад

@46165957 оргомное спасибо за волшебный пендель! ^_^ От осознания того, что это может быть Вам интересно, мотивации ощутимо прибавилось 🙂

раскрыть ветку
1 год назад

Помимо этого (начиная с версии 3.0) присутствует компонент для визуального программирования — Visual Scripting. Про него не могу ничего сказать, не приходилось пользоваться, но, думаю, это легко нагуглить.

не так давно объявили, что его скоро не будет

раскрыть ветку
1 год назад
Подписался, будем ждать!
раскрыть ветку
1 год назад

С годо всё отлично. Вполне работоспособный, гибкий инструмент (верстак!) для разработки игрушек, или других десктопных приложений. В принципе, он вроде как «сам на себе» написан 🙂

Меня в нём удручает некоторая бедность библиотек и лёгкая «корявость», например, встроенного дебаггера.

Впрочем, я вполне допускаю, что это от «привычки к шибко хорошему» вроде Visual Studio (с его сверхмощными средствами отладки) и всякими linq, позволяющими проворачивать функциональную магию со всякими перечислениями.

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

1 год назад

Хочу попытаться в годот, боюсь что не смогу потянуть, тяжело дается кодинг.
Опыта 0, а то что я 6 лет в консольном левел билдере работал это вряд ли поможет. Но очень хочется попробовать на самом деле, надеюсь смогу.

раскрыть ветку
Похожие посты
22 часа назад