Promote development of extensions for Godot

[Xrayez]

Describe the project you are working on

Goost - a general-purpose, extensible and customizable C++ extension for Godot Engine.

Describe the problem or limitation you are having in your project

Due to Godot's development philosophy (or lack of thereof, since there's no absolute philosophy in Godot), it becomes somewhat difficult to effectively contribute new features to Godot as a community-driven project. Me and other contributors have up to 10, 50, or even 200 opened pull requests in Godot main repository (this is not an exaggeration, bonus points to those who can figure out the exact contributor). 🙃

Taking about myself, I have currently over 30 opened Godot proposals, and some of them are 3 years old, and I estimate that only 10% of them will be eventually implemented specifically in Godot. Of course, I'm grateful for already merged features.

With the advent of GDExtension, I think the idea of promoting extensions development should become a high priority for Godot 4.x (or even the highest priority).

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Due to the above problem, I've created https://github.com/goostengine/goost in hopes that new and existing Godot contributors could implement various feature proposals that don't find a home in Godot specifically.

There are other similar projects like https://github.com/godot-extended-libraries/godot-next created by @willnationsdev that have a similar mission, but use scripting languages such as GDScript and C#.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I don't ask for too much: simply mention Goost in Godot's documentation, and any other project that you recognize as sharing similar mission. Not just adding a project to Awesome Godot list, but effectively promoting such projects as an alternative and/or complementing solutions for Godot via official recommendation. Reason: we'd like to prevent excess division of community. You may also agree that division is inevitable in the future (see numerous Linux distributions) and that's alright as long as new projects have different missions, otherwise it makes sense to centralize the development to a reasonable extent.

If Godot chooses not to support certain specific use cases out of the box (or when Godot does not recognize or see any concrete use cases associated with proposed features), then I'd really appreciate if Godot core developers could redirect such proposals to Goost at the very least, I really believe that we could have a nicely integrated symbiotic development mechanism that way. 🙂

There are numerous reasons to do so:

1. The vast majority of features will not be implemented in Godot. That's a fact, see "Will your contribution be merged? Here's how to tell" article.
2. Even if a feature finds community support, it still might not be merged. An example of this is @Zylann's terrain stuff:
   • Add a built-in terrain system #445

I'm not denying that some of those features will be eventually merged, but:

• it may certainly take a lot of time before a feature is even considered;
• once merged, a feature may not be as complete as originally intended by an author, which could also be the reason for resistance from the perspective of an author who'd like to have independence in decision making process.

3. Due to all above, Godot may choose to merge features based on real-life usages that are already battle-tested in production outside of Godot. If we talk about Goost specifically, we have a notion of experimental features which allows us to integrate functionality without the "obligation" of maintenance, so this speeds up both the development and eases the transition from a theoretical proposal into practice.

Several features have been ported from Goost to Godot so far, such as:

• Add ShapeCast2D node godot#54803
• Add GradientTexture2D #2 godot#53234
• Add 2D polygon boolean operations in Geometry singleton godot#28987

Of course, the same would apply to other projects that share a similar mission.

Alternatively, you can write a blog post about the intention of Godot, something like "Why we want to keep Godot's feature set small", and mention Goost as a solution for preventing bloat. In fact, something similar was already done by @reduz's article regarding ECS in Godot called "Why isn't Godot an ECS-based game engine?", where @reduz mentions about Godex project as a solution to the problem.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Because a lot of features:

• rely on performance;
• reuse built-in functionality;
• require out-of-the-box experience;
• require workarounds;

there's no practical way to work around this other than forking the engine...

With GDExtension, there will still be a problem of not being able to distribute libraries as part of an official Godot build, because according to recent discussions, GDExtension will be limited to a specific project when extensions are used, and there will be no global plugins implemented (will be restricted to editor-only):

• Add support for global plugins/universal addons #831
• Share code between multiple projects #577
• New Add-On (sub-project) system #1205

See also:

• C++ modules vs. GDExtension - who wins? goostengine/goost#135

This means that every Godot project would need to:

• fetch source code from external resource
• activate and/or compile it

We'd like to avoid this to achieve out-of-the-box experience Godot currently has. We are aware of the limitation that pertain to having libraries available globally (like missing dependencies), but this is already the case when using static modules that basically embed all features into one executable, therefore we don't see this as a limitation but as a feature:

• Embedding GDScript plugins into Godot executable (built-in addons) goostengine/goost#173

We just need the same built-in experience with binary dynamic libraries, since they will be distributed as Godot + Goost (officially distributed by the core Godot team as an executable, and the extension library developed by us). Unfortunately, we have to distribute our own custom Godot builds just to be able to achieve the requirements outlined above.

This is one of the major reason why numerous Godot proposals get rejected and pull requests not merged (talking about new features only, of course), because I've seen a lot of people expressing the desire of not having to download anything extra just to do X or Y.

Is there a reason why this should be core and not an add-on in the asset library?

That's a good question, and you already know the answer. 🙂

I'm not saying that Goost should be officially maintained, nor implying that Godot does not accomplish its mission. I'm simply saying that there's a "A Whole New World" out there and it's reasonable to think about supporting and/or recognizing third-party extensions for Godot on respectable terms, because I do believe we have the same mission in common: providing solutions for game development needs, from people to people.

[nonunknown]

I see you being a little contraditory here, you said you want to avoid division between community but you (with excellence ofc) maintains by yourself goost engine, I think you can be way more useful working with the godot team, you have a lot of knowledge, and every PR that is not merged its because usually goes in a different direction than godot's philosophy, remember that every PR is checked by godot team, the thing is, godot is growing faster, and maintaining it becomes harder as code base grows and community want to add features, also remember that every new feautre needs to be mantained by the godot team, and this new feature must be generalist and not case specific.

Dont get me wrong, the purpose of goost is awesome, as mentioned in the beginning you by yourself is dividing the community, and I really think you can be way more effective by participation on PR meetings, and helping the godot team to mantain this repo!

[Xrayez]

@nonunknown I'm grateful for your opinion and this is all good, but what do you propose?

[nonunknown]

well, since you've asked, here's my opinion:

• Stop Goost development
• Ask godot team for joining (you can already be part, I'm not sure, but calinou is not part of the team officially but I'm sure he has granted permissions do manage PRs and other communication stuff, which would be awesome to have you, since you're very dedicated)
• Transfer all of goost's features to godot engine (as many as possible)
• Also I'm very sure you're the perfect person to create GDExtension complete documentation as well

[Zireael07]

@nonunknown I fail to see how the existence of Goost is "dividing the community".
Also most if not all things in Goost are things that Godot devs didn't want for various reasons, leaving them to modules/addons.

[nonunknown]

which makes sense, if can be done as modules/addon, why you would want to make it core, since maintaining core is harder than the module/addon developer maintain his stuff.

[Zireael07]

Yeah, your latest comment is, however, in exact opposition to your earlier statement "transfer all of goost's features to godot engine". Because you effectively wanted those things to be made core.

[nonunknown]

also I said "as many as possible", because not all of them will be accepted, but they can become GDExtension stuff.

Just to be clear, I'm not mad at this, Its just my opinion, which can be shitty, at the end of the day we're a community and together we must find a way that many people as possible gets benefited by decisions we take.

[Xrayez]

• Stop Goost development
• Ask godot team for joining (you can already be part, I'm not sure, but calinou is not part of the team officially but I'm sure he has granted permissions do manage PRs and other communication stuff, which would be awesome to have you, since you're very dedicated)
• Transfer all of goost's features to godot engine (as many as possible)
• Also I'm very sure you're the perfect person to create GDExtension complete documentation as well

Oh sure, lets do this. But only if you become my lawyer. 🙂

[filipworksdev]

Controversial but your best solution is to soft-fork Godot. Turn all your work and most of the non essential Godot engine features into separate extensions.

Goost engine

• Goost core = a streamlined, stripped-down and enhanced version of Godot that is backwards compatible with Godot 3.x
• Goost extensions = all your modules and non-core Godot features/modulesconverted to extensions. Adjust the Asset lib to download extensions straight from a github repo similar to how scoop does it.

[Xrayez]

Controversial but your best solution is to soft-fork Godot.

This gives the ultimate Freedom™, but as you may know, "with great power comes great responsibility".

According to "The Future of Godot" topic at Godot forums, I think that the majority of Godot users wouldn't want this. Even if I have to modify the core, it's mostly because I have some specific issues that I'd like to resolve in my project. In fact, I have to do this for one of the projects I'm working on. But again, those modifications wouldn't be useful for the majority of people.

Of course, there will always be features that can only be implemented by modifying the core. Godex is one example of this. Even then, the module requires only a minimum set of patches for it to work. In the case of Godex, it's just one patch at the moment.

However, I have yet to see in what direction Godot 4.x is going, since I'm currently using Godot 3.x exclusively at the moment. So, the decision to fork or not to fork ultimately boils down to decisions made during Godot development, and my willingness/motivation to maintain things.

For certain, most of the features that I have created in both Godot and Goost I'm using myself at the moment. But If we take things further, frankly, I don't want to be an engine developer. I just want to makes games. My development journey with Godot started from a single game idea. As I proceeded further with my ideas to concrete implementation, I got into engine development. Then curiosity started to take over me, the desire to communicate with people, and as any person I wanted to get some recognition, both as a software developer and to feel accepted/welcomed as a human being.

So, as you see, this has a lot of dimensions. This particular discussion is the net result of all discussions that I had with Godot developers throughout these 5 years. But now the outcome of this discussion is not really important to be honest. It's mostly about collaboration, and I'm suggesting an alternative approach to collaborate, for whatever reason you may have as a contributor, and most importantly as a human being.

If I could say more here, I certainly would.

[azur-wolve]

@Xrayez out of curiosity (and a bit off-topic) which features Godot lacks that you need to your project?

[YuriSizov]

@KiwwiPity Unfortunately, they cannot answer you as they have a community wide ban.

But everyone needs some things to work differently for their own projects. That's why we have plugins and modules and the low-level extension system. Godot is general purpose, so it wouldn't fit everyone perfectly, and tuning it is completely expected. We try to focus on features that benefit the most, but we often reject features that while cool only benefit some. You can find many closed proposals that had some support from a few users. Some of them may have had to come up with their own, bespoke solution as a result.

[Zireael07]

Offtop: whoa what happened, he was one of the contributors whose handles I recognized (therefore very active) and I haven't seen him be rude ever...?

[YuriSizov]

I'd appreciate it if you used other platforms for these questions, as this is indeed very offtopic. I only mention this so the user doesn't expect an answer they can't receive.

Also, reactions don't work because of that, so nobody can even upvote their proposals anymore. Thanks, GitHub...