Overview

Here’s a fairly general overview of the Godot Engine, at the highest level of abstraction. It covers Godot’s design priorities, the development process, and last but not least, how public perception allows Godot to stay afloat despite numerous critical limitations, bugs, etc.

Some people who end up using Godot Engine say that it’s a decent tool for prototyping, some might even argue that it’s the perfect tool for this purpose. The engine has an easier learning curve compared to other alternatives that have a dedicated editor. But if you need to go more advanced, Godot doesn’t offer a complete configurable solution out of the box that could allow to solve slightly less trivial use cases easier. Things like editor usability are always preferred over performance, and if there’s a doubt to make something configurable or not, the most likely decision is the latter. A lot of features will be labeled as too specific by the core developers of Godot.

Due to the seemingly pragmatic nature of Godot’s development, most features are overly simplified to achieve good-looking results that won’t take hours or days for Godot users to implement. Intentional or not, it’s a trade-off that the core Godot developers seem to be making. This makes users of Godot feel empowered. The problem here is that this development approach may not be clear to the existing Godot audience who haven’t yet needed more than they’re currently using in their projects, which may lead to disappointment at some point in the future. This problem is especially noticeable for users switching from other game engines, as they typically expect a similar level of experience and feature completeness. Unfortunately, Godot does not meticulously flesh out every detail the way professional software engineers do.

While Godot does have its merits, the core problem with Godot is hypocrisy. Godot’s leadership doesn’t present it for what it really is, or instead lets the community eccentrically interpret and define Godot’s purpose. For example, most people understand that they won’t be making AA/AAA games with Scratch—or any games at all. This is because platforms like Scratch are primarily designed to help develop algorithmic thinking, which is perfectly fine. The problem arises when beginners who might start their career with Godot think they’re getting something on par with Unity or even Unreal Engine, which is not the case. Therefore, the misleading purpose of Godot leads to self-deception among its users and contributors.

The community is constantly misinformed that Godot is analogous and/or equivalent to existing solutions like Unity. Godot is released under a very permissive license, deliberately designed to be easy to use, and technically became one of the first open-source game engines with an editor that made it look like Unity. These factors alone made it possible to attract people with a predisposed bias toward Linux to promote Godot. The irony is that Godot and Unity cannot be compared on the same level. Godot’s leadership is trying to appeal to both the amateur and professional markets at the same time. As a result, Godot’s followers begin to believe that Godot can efficiently solve all their problems, either now or in the future, which stems from Godot’s leadership’s propaganda and the community’s desire for Godot to overthrow commercial engines, which is mostly an ideological rather than a pragmatic reason.

There are open-source game engines that are as popular as Godot, but unlike Godot, they are popular among professional developers specifically, because other open-source engines have more out-of-the-box customization and configuration options for specific use cases, they don’t try to reinvent the wheel, and they use well-established data formats, even if those engines don’t necessarily provide every feature out-of-the-box. Instead, professional game developers tend to use a set of dedicated tools that do their job well.

If we combine and generalize all the technical factors that contributed to Godot’s alleged popularity, it’s the set of factors that can be summarized under the umbrella of the all-things-for-all-people approach. But this comes at an extreme cost, which manifests itself as a severe lack of ability to customize the engine for advanced use cases out of the box. This makes the engine an unreliable choice for anything elaborate and/or long-term, especially since Godot’s core feature set is never set in stone, and often undergoes significant compability breaks even during so-called “stable” releases.

As long as game projects made with Godot have any chance of becoming popular, Godot’s features are constantly being changed to suit a variety of use cases that are unconditionally accepted by Godot’s leadership, without much regard to whether new changes cause problems for the rest of the users, who are considered “mere mortals” in the eyes of Godot’s leadership. Because of this, Godot developers often decide to simply remove features from the engine to resolve this kind of conflict, betraying the trust of existing users. Unfortunately, Godot devotees are unable to recognize this as an actual betrayal of trust, but choose to believe that they must suffer through these changes in the hope that Godot will eventually become stable. The irony is that the very nature of the name “Godot” suggests that this will never happen.

There is no philosophy behind the development of Godot. Rather, it consists of chaotic development decisions, which the Godot leadership refers to as an enigmatic “unwritten” consensus. Unfortunately, most people interested in contributing have to go through the tedious process of determining what kind of changes would make sense to include, which means that an abnormal number of feature proposals are either ignored or rejected by the core developers, unless of course someone manages to create a promising project using Godot. With each development iteration, Godot never converges to true stability, and is unlikely to ever reach it, because its development approach considers ways to maintain donations and attract sponsors to keep the investment bubble growing, so stability is never a priority for Godot. This approach of introducing never-ending novelty is the only viable way for them to sustain themselves, given that they lack professionalism.

Uncertainty permeates Godot’s development process. This kind of so-called vision is propagated by the manipulative rhetoric of Godot’s lead developer, something along the lines of “accepting the reality that nothing can really be finished.” Interestingly, it’s possible to draw some analogies from Extreme Programming to describe Godot’s approach, such as not programming features until they’re actually needed. However, what is needed or not is still a subjective opinion of Godot’s core developers. Needed for whom? The very ambiguity allows them to move the goalposts of the project’s direction in a whimsical way.

Some Godot followers have expressed frustration with the perceived lack of innovation in commercial engines. However, this perception is misguided and has been deliberately perpetuated by Godot leadership. While Godot may appear to be revolutionary, its developers have been known to recycle existing solutions and attempt to convince users of their uniqueness and innovation. However, upon closer examination, these claims are often found to be false. They attempt to replicate the success of other commercial engines by cloning them, clinging to the success of others, and by ripping off existing solutions. They attempt to incorporate every possible feature that excel in other engines, and try to integrate those features into a single product. The dramatic consequence of this approach is that none of the features end up being as effective as the features that we see present in other tools on an individual basis.

The “pro-Godot/anti-Unity” disinformation campaign is that people who are into Godot or who are affected by Godot’s propaganda start to ask questions like, “Why is Godot so popular?” Godot’s fans are so enthusiastic that they spread the word about their engine. They assume that Godot is popular in the game development industry as a whole, even though it’s not. They go along with this kind of misleading reasoning: “If Godot is popular, then it must be because of technical features that made it popular, and not hype.” These loaded questions are designed to attract people into using Godot, especially those who have little to no experience in game development.

Godot is certainly popular among some subset of indie game developers, especially the younger people. But its community is very vocal, and it hooks developers with its deceptive simplicity. Godot also serves as a kind of refuge for those who share anti-corporate sentiments. The irony is that Godot is de facto a corporate structure that they despise. It’s just that Godot’s leadership is very good at hiding it. The reason behind the relative popularity of Godot could also be attributed to the concept of gambling. The endless promises of a “bright future” keep people hooked and eager to explore new features in Godot. The combination of waiting, uncertainty, and the prospect of new features generates a sense of anticipation. Anticipation creates the expectation of a reward. It’s no coincidence that Godot is named after Samuel Beckett’s “Waiting for Godot.” As long as they can keep people from seeing the truth, it won’t look like a grift.

This is not to say that Godot is useless, of course. But even if we consider Godot’s current features, it could simply remain unnoticed, especially starting from the inconspicuous and insignificant Godot 1.0, the first public version of the engine. Some Godot followers even express mixed feelings: “Too terrible not to upgrade. Good enough to want to upgrade.” Therefore, there exist other non-technical factors that made it popular among a certain subset of users. The subsequent chapters are going to reveal another important factor which contributed to Godot’s alleged popularity, which closely correlates to the overzealousness of Godot community.

For a more detailed analysis of Godot’s technical limitations, please refer to this excellent summary by a long-term user of the engine.