Customization

Given slightly less trivial task, fruitful customization can only be achieved by modifying Godot’s source code. In contrast to other game engines out there, Godot severely lacks the number of knobs to configure, mostly because Godot’s built-in features are oversimplified in the interest of usability and clarity, so a lot of options remain hardcoded or unexposed.

Here’s what we could consider lead developer’s “philosophy” on customization¹:

Any unnecessary customization is bad customization.

While this compromise may allow engine developers to deliver a tool so that users can get results quickly, these results are only useful up to a certain point. That’s why you’ll oftentimes hear that Godot is mostly suitable as a prototyping tool instead.

According to Juan, customization in Godot is achieved by having a “clean codebase”².

Codebase is clean, well understood and easy to modify in order to add advanced or custom features.

First and foremost, it’s important to remember that Juan explicitly stated his indifference towards code organization and reuse, as discussed in the previous Do Repeat Yourself section. Therefore, this combination of neglecting code reuse and a need for custom modifications can inevitably result in regressions, and with Godot as a piece of peculiar software, such roadblocks are commonplace.

Despite this, Juan oftentimes suggests developers to build Godot themselves in order to “customize” Godot that way. This is substitution of concepts as proliferated by the authority of Juan. He presents this “build it yourself” approach as the main way to do “customization” in Godot. In other words, this type of “customization” shouldn’t be presented as the main way to “customize” Godot, because following this approach leads to having to maintain a custom fork of Godot and a custom build system to deploy the engine to various platforms yourself, which is quite expensive.

If developers have to modify the source code, that’s not true customization, that’s just forking the engine which means maintaining a custom version of it. Due to this, it’s very difficult to attribute great merit to Godot if modifying engine’s source is the actual necessity in order to make any successful game with it, because it shouldn’t be a necessity. The necessity to customize the engine via source code shouldn’t be presented as the best way to customize Godot, but rather bullet-proof way, and that always leads to additional maintenance effort which is better to be avoided.

Of course, you also have to pick the right tool for the job, yet Juan sells an idea that it’s easy to modify the engine to achieve what they want with it, which doesn’t reflect the reality, because one has to consider long-term shortcomings, not just near-sighted benefits that are too easy to fall into.

There exists even more lightweight engines in contrast to Godot that have more customization options without having to rebuild it from source, see Alternatives. So, one of those Godot’s moving goalposts is ability to “customize” the engine by rebuilding Godot, because such ability to “customize” reads more like an excuse for lack of ability for real customization out of the box, as an actual feature of the engine. Pretty much every software can be “customized” by rebuilding it from source, Godot is not unique in this regard. Even then, it’s difficult to call this as “customization” if we talk about this in terms of an end product rather than a software engineering perspective. Having this kind of approach would be tolerable if Godot were to be a library, but Godot is not a library; it’s a “feature-packed game engine,” as advertised by the Godot leadership.

Additionally, this kind of ability to “customize” by rebuilding Godot from source will likely lead to many custom forks out there, both open-source and commercial, and it’s not clear whether Godot leadership cares about division of community in this regard.

Here’s an analogy: imagine you have to disassemble an electric drill in order to fix it and to finally finish the job. You must agree that most professionals wouldn’t even decide to use such a tool in the future if it’s known to have such severe limitations. If someone likes to challenge themselves by having to workaround dozens of hidden limitations, that’s totally up to them to use Godot, because Godot does follow the principle of “if don’t like it, modify it yourself” religiously.

Taking into account above, if you stumble upon successful games made in Godot in the future, it would be mostly because of individual developers’ incentive to modify Godot and/or by integrating third-party code, it wouldn’t be Godot’s merit at large, but Godot followers will sort of “cling to” that merit by saying that a particular game was made exclusively with Godot’s built-in capabilities, which is a misleading, manipulative or blatantly false claim for the most part.

References