Extensibility

Since Godot is open to various interpretations, in the realm of game engines, the vision of Godot’s leadership remains ambiguous. The question arises whether they aspire for their engine to be regarded as the esteemed “Linux of Game Engines”, renowned for its adaptability and flexibility, or if they seek to position it as an all-inclusive package akin to the versatile software suite, “Blender.”

The ultimate trajectory depends on whether Godot opts for a lightweight approach that may risk rendering it somewhat ineffectual out of the box, or if they choose to incorporate additional features, which may result in a perceived engine “bloat,” yet deliver a feature-rich experience. Neither approach is inherently wrong, but watch this satirical piece first:

Labeling Godot as a prospective “Blender of Game Engines” would indeed fail to do justice to this so-called “visionary” project. It is crucial to recognize that the concept of being the “Blender of Game Engines” originates from a catchphrase masterfully devised by Godot’s leadership, encouraging devoted Godot enthusiasts to propagate the message. Yet, it is essential to note that merely presenting Godot in this light does not guarantee its ultimate success.

Therefore, if Godot embraces the path of the “Linux” model, numerous proposals formulated by individuals of “mere mortal” status should be directed towards module, plugin, or addon development instead. The current course of decisions seems to indicate Godot’s inclination towards this route. Despite this, you can still observe the Godot followers using the “Blender of Game Engines” catchphrase, almost as if it has become Godot’s own slogan by now. Due to this, perhaps it would be helpful to remind Godot followers of their original slogan!

The game engine you’ve been waiting for.

Lead developer of Godot presents his what he calls “philosophy” of pushing stuff out of the engine1:

Philosophy to me should be that something should be part of the engine only if ALL the criteria below are met:

1. It’s used relatively often.

2. It’s difficult to do yourself.

3. There is only one way to do this feature.

This rules out spring arm, terrain and I hope it can help to, in the future, remove features such as InterpolatedCamera, Vehicle, etc. that I believe should be outside the engine.

If that’s the case, this leads to the next question of whether Godot would be willing maintaining those features via plugins officially. If Godot aims to further remove features from the engine to allegedly prevent bloat, would those features be actually maintained by the core developers? If not, maintenance burden will lie on the shoulders of individuals who are not seen as official members of Godot (volunteers). Here’s what Juan replies to these expressed concerns by Godot contributors:

The main concern about this is that, if something is not official it’s not going to be maintained. This is where you guys are wrong.

No one said these things should not be official, we can have an official repository for them and they can be first party extensions. Demos are maintained this way and they are up to date, so I don’t see why it wouldn’t work for an official extension repo.

Godot demos repository is actively maintained because Godot as a game engine is designed to look good on the surface. They do everything necessary to sort of “sell” a good picture/image of Godot, so it makes sense for them to maintain such a repository regardless.

For the rest of the things, some features are already removed from the engine and are no longer official, contrary to what Juan said. Features like InterpolatedCamera are already removed from latest versions of Godot2, and such classes are not moved to officially maintained repository. Features like these are pushed away to unofficial repository called Godot Extended Libraries, which is not handled by Godot leadership. Another example is VisualScript, which is removed from latest versions of Godot as well3. This means that most features that are pushed away like that won’t be actively maintained or won’t be maintained at all.

Even if Godot features may be moved to officially maintained extensions outside of the core engine, this could further split the community, as those extensions would have to be installed manually by users, going against “feature-packed” approach which Godot has been advertising all these years.

If Godot truly upholds its claim of being “highly organic” and genuinely aims to prevent bloat, one would expect them to establish a concrete “Feature Removal Policy” to guide their development process. However, it is evident that such a policy does not exist within Godot organization. Unless policies are directly related to Godot’s community, Godot adamantly avoids adopting any policies that could potentially expose their inconsistencies or contradictions. This blatant disregard for transparency and accountability raises questions about their true purpose concerning the development of extensions.

In the proposal titled “C++ Game modules,” Juan proclaimed the following4:

For the rest, I really think it becomes a much more corner use cases, which does not make sense for having an entire feature for, given the idea is to discourage the use of modules as much as possible towards the future. [emphasis mine]

In a proposal/pull request which aims to add built-in SQLite support, which has been neglected and ignored for more than three years now despite community needs, some Godot contributor comments on Juan’s discouragement above5:

I believe rationale might be different, but real life is tough, so it will quickly turn into situation where Godot will be ‘like open source’ engine with few basic functionalities, then there will be many paid and closed source, licensed third party GDNative DLL’s for any/each serious feature, without alternative of open-source modules…

Godot leadership says that there’s no guarantee that all feature proposals that received community support (in the form of thumb-ups or otherwise) will be implemented. And that’s totally understandable. Godot cannot possibly implement all features that exist under the sun. But when contributors ask Godot leadership whether they would be interested in cooperation by promoting community extensions for Godot, such requests are ignored by Godot leadership, likely in the fear that this would lead to community division. This ambivalent attitude makes it very difficult to make a meaningful impact without going into unnecessary conflicts with Godot leadership.

References

2

InterpolatedCamera3D add-on - By Hugo Locurcio.

5

Add SQLite to Godot - Comment by Avril, Godot contributor.