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…

Many people would like to know Godot’s vision, but in fact it has none or it’s deliberately hidden from the public. Those who are not afraid to criticize Godot’s management usually say something along these lines, here’s just one quote from a potential contributor to Godot2:

And to be frank, I don’t like the attitude of the leader when replying to feedback. I can disagree with someone and respect their views, but they seem very set out to to respond to so much feedback with “you don’t understand what you’re doing, you don’t understand my vision” [emphasis mine]. The former is almost never accetable, but the latter is all on Godot. If you want people to understand your vision, don’t have a 3 year outdated roadmap.

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 effort3:

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 specifically, rendering is a crucial part of every game engine4:

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 discussions5:

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 Godot6:

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 suffered from severe rendering bugs in production7 8:

Typically, resolving technical contradictions as mentioned above leads to innovation9. 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 believers10:

To be honest, if Godot embraces it becoming the Noah’s Ark for Unity developers [emphasis added] and prioritizes C# over GDScript to improve performance, it could be good both for Godot and C# ecosystems, and more emphasis on the ability to use very rich selection of libraries written for .NET would not hurt either.

The misconception and delusion that Godot is some kind of “savior” of the gaming industry is so severe that those who have truly grasped the reality of Godot’s capabilities are being overruled by the mob mentality, especially on Reddit. Those who have used commercial game engines like Unity or Unreal and successfully shipped games with them have a much more objective perception of what Godot really represents at its core:

I would say to Unity developers, don't use Godot.
byu/xuhuijie520 ingamedev

And I’d like to briefly state my opinion that this Godot engine is only good for laughs, and whoever uses it for real game development will be miserable!

Those who have already been seduced by Godot’s false promises and/or hopes tend to either ignore or suppress doubts about its true capabilities. In other words, when some people describe Godot as amazing, it may be the result of wishful thinking rather than a reflection of reality, or the supposed simplicity of the engine may overshadow any other negative aspects of Godot in the eyes of hobbyists, but not professionals. In fact, it may be a combination of these factors that reflects Godot’s nature. A software engineer with experience in the AAA industry sums up this issue11:

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 whether Godot is community-driven or not. 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

Devs learn rival Godot engine in a week to poke fun at Unity - Comment by johnnyanmac, YCombinator.com.

3

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

9

Contradictions - TRIZ.

10

The anatomy of a Godot API call - Comment by neonsunset, YCombinator.com.

11

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