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.

In an interview to Software Freedom Conservancy (SFC), Juan Linietsky says:

Coexistence with other free software projects is a bit difficult. Godot does mostly not make heavy use of other open source software as a base, and instead we write our own versions of things [emphasis mine]. This is because generally we have very precise needs to solve; it’s easier to roll out our own solution than doing politics with other projects to see how to work together. So, unless a library we use is exactly what we need, we tend to roll out our own. Things may take longer, but Godot becomes a lot more consistent as a result.

Have a look at how the core developers of Godot create their own version of physics. The image shows Godot’s built-in physics on the left and a third-party physics engine called Jolt on the right. Godot-Jolt integration is unofficial and is not a part of Godot:

When we compare these results, the only thing that we can agree on with Juan is that the NIH approach helps Godot become more consistent because the engine stays consistently broken! 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:

Analyses by experienced developers highlight Godot’s NIH decisions, evident in its choices of rendering techniques that disregard established industry standards:

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 intricate in Godot, read Customization chapter.

While evaluations above may be accurate to some degree, they could also 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 the NIH 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. Ironically, the fact that Godot left Software Freedom Conservancy for Godot Foundation reinforces the NIH syndrome even on an organizational dimension!

Of course, the Godot leadership would like to see their engine adopted by the big players out there, and they go out of their way to do so. As a result, the leadership and core maintainers would be seen as experts in the game development industry, so they could provide paid services through a syndicate of commercial companies such as W4 Games or Ramatak, which they co-founded. Regardless of their intentions, the above is one of the reasons why Godot is NIH. There are other important reasons for Godot’s approach, as you’ll discover in the following chapters.

References