Not Invented Here

Godot is a very NIH engine

Juan Linietsky. Source: Godot Contributors Chat

The NIH syndrome describes the tendency to avoid using third-party solutions. This term is usually used in pejorative meaning, but Godot core developers do not see this as a negative thing and take this approach deliberately, with a contrived rationale that Godot’s architecture is unique and requires independent development decisions because of this, all without trying to fit third-party solutions into Godot’s allegedly specific design. A lot was tested and dumped in Godot over years like SDL, Lua, Squirrel1, Assimp, Box2D, Bullet etc. According to Juan, it has worked well:

Godot is a very NIH engine and it has worked very well

Godot strives not to rely on platform-specific libraries, and in some cases doesn’t rely on third-party at all, for example, to render GUI components. However, Godot is not completely allergic to third-party solutions, but tends to prefer smaller sized libraries whenever possible, with varying degrees of quality…

Due to the above, Godot is a very NIH engine. Godot ends up doing a lot of things their own way. But this is not innovation either, because most of their work is based on cloning existing solutions, and the rest of the work is just the reinvention of the wheel. Godot developers say that it allows them to achieve “freedom”, or a compromise of “glue vs politics”, as lead developer says:

And I can definitely say that this because in my experience, you are having in one end of the scale NIH and Freedom, and on the other Glue and Politics, and choosing this wisely on a case by case basis is best.

But for experienced game developers to make meaningful contributions to Godot, this so-called “NIH and Freedom” approach clearly creates a problem:

In an intriguing pursuit of irony, Juan has amusingly proclaimed his disinterest in politics dozens of times, all the while actively being involved in a myriad of political and ideological debates on Twitter/X, ranging from technical topics to more serious ones, like military, gambling, etc. As we venture further into subsequent chapters, do bear this revelation in mind, quoting Juan2:

I am only here for gamedev, not for the politics.

Because Juan is a political maestro when it comes to handling tech, you can clearly see how he sticks to his guns and adopts a rather snobbish stance on, let’s say, rendering backends like BGFX, quote3:

Guys, thanks a lot for your enthusiasm, but I am the one doing the rendering work in Godot, not you. I’ve been working on 3D rendering for 25 years so, if I am telling you that things as they are now are optimal and BGFX will just stand in the way to being productive I hope you believe me.

Godot is often criticized for being extremely NIH, so much so that Juan himself wrote a post about it, literally claiming that no one has managed to make a game engine with pre-built stuff, which is obviously a false claim:

Godot’s NIH approach is further confirmed by reviews of those who use Godot in production and face its limitations, emphasis mine4:

Godot is absolutely amazing at a lot of things, and terrible at a lot of other things at the same time. A potential idea would be to rip things apart, scrap a lot of the bad parts, and rebuild internals to be less brittle.

Developers often have to customize Godot by rebuilding it from source just to make it work for their use cases in production. Ripping things apart is often necessary to achieve anything slightly more demanding in Godot, see Customization chapter.

While evaluations above may be accurate, they could arise due to the discrepancy between the initial expectations set by Juan (promising it to be absolutely amazing) and the actual performance experienced by the user (finding it terrible).

Godot developers might be grappling with feelings of disappointment and frustration, as their perception of the engine’s abilities clashes with the reality they encounter. This cognitive dissonance may lead them to express both positive and negative sentiments concurrently as they attempt to reconcile their initial excitement with the encountered limitations.

Yet they continue to use Godot, even when they admit it’s the engine that they’ve had the most trouble with in their entire lives. This social phenomenon mainly originates from the belief in a utopian “bright future” that many Godot users stubbornly hold onto, despite facing critical limitations:

Conclusion

Due to this syndrome, Godot won’t prioritize features like C# over GDScript because their priorities account for independence, see Simplicity chapter. This way, they achieve their so-called freedom, but end up making others dependent on their in-house technology, see Freedom.

Of course, Godot leadership would like to see their engine adopted by big players out there, and goes out of their ways in order to do so. As a consequence, leadership and core maintainers would be seen as experts in the game development industry, so they could provide paid services via a syndicate of commercial companies such as W4 Games that they founded. Regardless of their intentions, the above is one of the reasons why Godot is NIH. There are other important factors why Godot adheres to this approach as you’ll find out in the following chapters.

References