Priorities

This covers general priorities that Godot seems to follow. Priorities cannot be inferred from Godot’s project roadmap because, in reality, Godot does not have one!

Godot’s project manager, Rémi Verschelde, describes this as a so-called “unwritten consensus.”1 Any instances of the term “roadmap” used in the context of Godot usually pertain to backlogs, which are collections of issues or features compiled as to-do lists. However, these backlogs do not constitute a concrete roadmap.

A roadmap is not merely a list of upcoming features; it also relies on a clear definition of goals. Unfortunately, Juan Linietsky, the lead developer of Godot, does not recognize goals as a fundamental concept within the Godot project, as evident from Juan’s diagram that you will discover in a subsequent chapter Companies vs FOSS. Juan says that at GDC 2019:

I mean, we don’t have such a long-term vision, so, well, whatever…

Consequently, this lack of defined goals or a clear direction means that a proper roadmap cannot exist within the Godot project, as the very essence of a roadmap depends on the presence of well-defined goals.

Godot’s leadership mostly hope that “big studios” are going to notice them and they would determine Godot’s direction. Ironically, as Rémi pointed out, this creates chicken-or-egg problem: why would big studios use Godot if it’s yet to be proven? Big studios still need to have some sense of direction before even considering adopting Godot!

Speaking of big players, if we take a review written by creator of RimWorld, he describes Godot’s lack of decided focus as mis-spent effort2:

My main concern with Godot at this point is that it seems to be trying to be all things to all people. It’s trying to appeal to the “my first game” student market, via visual scripting and GDScript and so on. But it’s also trying to hit AAA features like advanced rendering and a built-in particle engine.

This lack of decided focus manifests as IMO mis-spent effort on things that almost no serious indie should be using (advanced rendering features which look pretty in demo videos, visual scripting), while deprioritizing things that absolutely every indie should be using (C#).

At the same time, we can still infer some of Godot’s priorities. According to lead developer’s response directed to the creator of Rim World, we can draw the inference that Godot aims for high-level functionality and implementing back-ends which allow to make games to look pretty, cover the most common use cases and only allow some tweaking, even if he talks about rendering specifically3:

Godot in contrast aims for mostly high-level only rendering backend that looks pretty, covers most common use cases and only allows some tweaking. The idea is that out of the box it looks as good as Unreal, is much easier to use, but of course may lack the ability to tweak performance for corner use cases (though it should still be good for most games). The vision here is that this can be achievable with a relatively simple renderer (there is not as much rendering code in there as you might think), and that if a large company ever wants to use it, they have the money to hire a render engineer and tweak it themselves.

Full reply by Juan Linietsky can be found here:

Comment
byu/lmbarros from discussion
ingodot

As we covered in Waiting for Philosophy chapter, Juan has been telling users and contributors of Godot that it doesn’t have any kind of vision, and philosophical discussions are irrelevant. But when big players start to evaluate Godot, all of a sudden Juan provides Godot’s claimed priorities. Don’t you think this kind of behavior is hypocritical, to say the least?

The false dilemma of using Godot over other engines like Unity or Unreal becomes evident in various ways, sparking numerous discussions4:

Anyone else not excited about Godot?
byu/Atsurokih ingamedev

For example, Winter Pixel Games, the creator of Rocket Bot Royale, made with a heavily customized fork of Godot coupled with other custom modules and monstrous efforts that made the project possible, expresses an ambivalent approach when it comes to addressing Godot’s limitations, in the larger context of discussing both the management and functional pros and cons of Godot5 [emphasis added]:

From scratch would be very difficult… 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.

Even if we temporarily assume Juan’s claim above that Godot’s rendering can be easily modified from the source code due to its “relatively simple renderer,” the truth remains that Godot introduces unresolved technical debt for those who decide to adopt it for their projects. This technical debt becomes the responsibility of companies to address on their own, rather than being resolved by Godot from the start.

A notable example is the experience of Blind Squirrel Entertainment in developing Sega’s Sonic Colors Ultimate, where they opted to use a customized fork or subset of the Godot Engine codebase. As it turned out, this custom implementation actually suffered from numerous rendering bugs in production6 7:

Typically, resolving technical contradictions as mentioned above leads to innovation8. However, in the case of Godot, these unresolved contradictions do not stem from technical aspects but rather arise from inadequate project management and false expectations proliferated by both Godot’s leadership and Godot believers.

Unfortunately, it appears that those who have already been allured by Godot’s false promises and/or hopes tend to either ignore or suppress doubts regarding its true capabilities. In other words, when people describe Godot as “amazing,” it may be more a result of wishful thinking rather than a true reflection of reality. In fact, it could be a combination of both wishful thinking and reality, which contributes to the captivating nature of participating in the Godot community. This ambivalence of Godot is very reminiscent to gambling, as covered in previous chapters. A software engineer with experience in the AAA industry summarizes this issue9:

These findings, combined with the general messaging of “we’re an engine made for our users and contributors, not an engine made for our own goals” (paraphrased heavily), gives me the impression that there is no plan [emphasis mine]. Godot will have the features people decide to build for themselves, or the features that lots of people ask for, on some sort of timeline. And even if you make a feature, there’s no guarantee [emphasis mine] it will get merged, even if it is highly upvoted. This doesn’t have to be a bad thing, but it does mean you can’t expect from Godot the sort of steady, planned, expected updates you can expect from a professional software company.

Furthermore, there is no guarantee of any decisions being made in Godot, as you will learn in later chapters, like the Community-Driven one. Godot’s absence of a plan is not attributed to its FOSS nature, but rather to preserve ambiguity in feature prioritization, driven by the hidden agenda of the lead developer. Because Juan Linietsky wields significant influence over contributors, they often find themselves adapting to Juan’s shifting goals. While outsiders may occasionally observe this dynamic, contributors often remain oblivious to such influence.

References

2

Tynan Sylvester’s comment on Godot - By Tynan Sylvester.

8

Contradictions - TRIZ.

9

Godot: The Good, the Bad, and the Ugly - By Margaret Ó Dorchaidhe, September 19, 2023.