Better discoverability of curated add-ons into editor

[reduz]

DISCLAIMER: This is a personal proposal to help discussion happen, not a communication or official stance by the Godot project. The idea is to create a place to discuss these topics and ideas. Eventually those responsible for it within the Godot Foundation (not me) can pick them up or better understand how to move forward.

Describe the project you are working on

Godot Editor

Describe the problem or limitation you are having in your project

A lot of features that users request are in pretty common demand, yet, it is very hard to integrate them as built-in to Godot for the following reasons:

• There are too many different ways to do it and too customized for each game (Example: Terrain, State Machine, Dialog System, Inventory System, Level Prototyping, etc).
• They are not as commonly used (hence not worth including in core), but very important (such as video or audio codec support).
• They don't align to the project mission statement of supporting Open Standards (ex supporting a proprietary API).

The problem is, going to the Asset Library for this is cumbersome and chaotic, with not great discoverability. Asset Library is great when searching for very specific things, but it does not have any kind of "curated" listings.

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

The idea here is two-fold.

• Implement three levels of support for assets that users can choose from:
  • Official: This asset is developed officially and hosted in GodotEngine repos.
  • Endorsed: This asset is developed by a third party and recognized by the Godot project has having great value and demand by the community, hence it is endorsed. The asset author must keep this asset up to date or else it will lose the "Endorsed" status.
  • Community: The rest of the assets, which are community created.
• Implement "shortcuts" in the editor to the asset library to make it easier for users to find the types of assets they want.
  • From the Create Node dialog, implement a shortcut to "official/endorsed plugins providing new node types".
  • From the Create Resource dialog, or resource editing dropdown, implement shortcuts to "official endorsed" plugins providing a certain resource type.

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

Endorsed category

The first thing that has to be implemented is a new Endorsed category to the "Support" drop down:

Additionally, in the results, we should do as follows:

• Sort results by level of support in this order:
  • Official
  • Endorsed
  • Community
• Show the level of support in the result

Here is a mock-up of how this should look (sorry I know these are all community assets, I am just retouching it):

Still, this is by far not enough for discoverability. To enhance discoverability, we must implement ways to look for assets contextual to the place in the editor we are using.

Shortcuts

The first shortcut to the asset library that must be implemented is in the create dialog.
Here as an example, when creating a new node, we can add a shortcut to browse assets that would add new nodes to the user:

Clicking this would do the following:

• Open the asset library
• Do a special type of search (that we need to support) that will look like like: type:Node

This way, the asset library will show all node types available as add-ons (again, starting by official, then endorsed, then community).

This is a fantastic way to promote something like:

• Terrain ADD-On
• CSG add-Ons
• Generally any other type of add-ons that add new node types (they need to be tagged for this in the asset library).

Likewise, when adding a new resource type, we can add this in the resource picker:

Which would open a search with this text: type:Material. Assets providing these type of resources will appear in the asset library list.

Then, users can simply open them with the Quick Load dialog.

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

N/A

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

This is designed to make it easier to push things to the asset library.

FAQ:

Q: I make assets, how can my asset be endorsed?
A: Your asset must prove to be something users show significant interest into, and you must commit to maintain it and keep it up to date (as in, ensure it works with the latest Godot version) . Additionally, your asset must be free and open source and promoting open standards (As in, if you are a company promoting your own asset for a commercial service integration, this can't be endorsed as it goes against the project mission statement). Rules need to be completely ironed out and this proposal aims to be an open discussion about it, but that should be the general idea.

Edit: My personal opinion on how endorsement should happen is in this comment here, but it ultimately should be something that has broad community consensus.

[ratepenado]

A double notation system like steam, and a date of last update would be very useful too

[Structed]

I struggle a bit understanding how one gets endorsed.

Do we need a voting system for that or is the core team deciding it? How are they being made aware of this? Is there an application process? 😉

[WolfgangSenff]

I like the idea mentioned above of the date of last update being included - just ran into an issue where I was looking for an asset and there were almost a dozen of them and had no idea which one was kept up-to-date until just searching Google for them and actively looking. But I love this idea in general - only thing I'm a bit iffy on is what @Structed just said, with the, "How to get endorsed". I guess it's some kind of system you submit on the website when you submit/re-submit the asset, but just curious.

[bitbrain]

Thank you for writing this up - regarding the "Endorsed" status of an addon, an addon might not receive much updates at all since it is mostly stable and does what the community needs. At the same time, it can be in high demand, so it should still be considered "Endorsed" as an addon can still bring a lot of value to it. Therefore I'd suggest that we may need a bit more clarity on the "Endorsement System" for addons. For example, a "vote system" could be useful that influences the popularity of an addon, leading it to become endorsed automatically? The advantage of endorsing an addon based on "usage" metrics (e.g. total downloads) is that it cannot be gamed. Someone could "upvote bomb" a certain addon via promotion and get their addon endorsed.

The asset author must keep this asset up to date or else it will lose the "Endorsed" status.

Another thing that is currently unclear: how exactly would addons be endorsed/de-endorsed? Is this a human process or would this be somewhat automated?

Some addons have not been discovered at all by people but they might be extremely useful. Endorsing those "manually" by the Godot core team could be cool too, e.g. "Picked by Godot"

[LauraWebdev]

I'd say the criteria for "Endorsed" content is quite crucial for this proposal. You say yourself that they would need to be ironed out, and I think they are the key component that can steer the proposal in any direction.

Regarding the mockups: There should definitely be a unified naming for these "hints" (ie no "Find more (Browse)" and "(Search) for Addons...")

[TokisanGames]

Within the asset library is fine, but the list of official and endorsed plugins should also go on the website in a featured plugin section. In 6 years I've only used the asset library once or twice to download demos, and never for plugins.

The asset author must keep this asset up to date or else it will lose the "Endorsed" status.

This is a reasonable ask, but it needs a give. Specifically in terms of priority. If core devs or plugin devs are maintaining an official or endorsed plugin then their engine bugs need higher priority.

Eg In Terrain3D, we can create 16k x 16k terrains in memory, but cannot save them to disk due to this bug .

In the normal course of operation an engine bug might only affect a handful of games, and may have a workaround. But if it affects a plugin, especially if no workaround can be made, it could affect hundreds or thousands of games.

[Structed]

I think, and I believe that's what you are saying: Endorsed should be in a sense worthy of being part of the engine.

In my opinion, this must then be decided by the core team, or the Foundation Board(?).

I'd love to see an additional category "supported". There, it is possible for the author to declare that an add-on has a "Support Plan", either free or commercial.

[theraot]

Yes, we need metadata (e.g. type:Material ans type:Node), and yes we need "shortcuts". I imagine that both the new metadata and the new endorsed category will make the review process more difficult.

Since we are talking of changes to the asset library, and knowing that there might be a store in the future, I want you to consider metadata files, I made a discussion last week at the time of writing with similar points: #7990

I would also be interested in allows a repository to host multiple add-ons. This might allow to install them independently. And it will remove friction for me (I have plenty of add-ons made for internal use, and making a repository for each one is discouraging).

---

Slightly off-topic: While I'm aware it is not what is discussed here, since we are talking of changes to the asset library, and knowing that there might be a store in the future, I also want to bring attention to the issue of supporting dependencies. Please see: #6802 - And I say this knowing that dependency hell is hell.

[reduz]

@Structed While final say on what endorsement is (and if endorsement will exist) will be from the foundation team working on this, I think its good these things are discussed here.

@TokisanGames Endorsed plugins are by definition those not worked by core devs but by community separated from the project, but endorsed due to their value. Official plugins are those hosted in the Godot GitHub repository.

@LauraWebdev Absolutely, as I said this is mostly a proposal to get discussion on this topic to happen and have community participate.

[coppolaemilio]

I think endorsing assets is a good idea but potential a huge problem. First of all, who endorses the asset?

• If it is the Godot Foundation: are we responsible for an asset that turns out is malicious? There's also a big conflict of interest here, because many of us (members of the Foundation) have made plugins.
• If we get people to "vote" on which assets are the most popular for it to be endorsed, we are sooner or later be victims of spam.
• If we endorse by use, that means that we need to start tracking users to tell which plugin is most used or not.

We can improve the indicators and the search result to better display which assets are "recommended" over others. For instance, if the asset is linked to a GitHub repo, showing the number of stars the repo has can be an indicator. As other have said already, displaying the latest update date could also help. Is the asset supporting C# or just GDScript, etc...

That way, we can assist users to pick one over other depending on their preferences without having to create the "endorsed" label and have to deal with the issues that come with it.

[WolfgangSenff]

Having thought about it more, and seeing @coppolaemilio's great post, I 100% agree. I also worry that any voting system may require so much maintenance that it would take away from maintainer's time, and eventually would need someone dedicated to it, since there could be such a large number of endorsed plugins. I like the stars idea, though that's not always an indicator of usage. Would it be possible to include a link to the Discord channel or something, maybe, if the asset developer submitted one? Not sure, but it's a thought as a way to improve the asset store and would probably lead to better discoverability - assuming users prefer ones that have Discord servers for the asset's development.

[theraot]

@coppolaemilio I mostly agree. Just one note: Using Github stars gives preference to Github. I might, for example, prefer Bitbuket for the way it allows to group repositories (and thus keeping add-ons separated from repositories for other things, which would be useful if I have a bunch).

[coppolaemilio]

@theraot We could add a way to "star" assets on the asset library. That way we don't rely on GitHub's stars. But I was only giving an example of an indicator that people use when deciding which technology to use initially.

[reduz]

@coppolaemilio I agree, I think it has to be ironed out.

My feeling is that it would ultimately be a combination of:

• User demand (combination of votes, stars on GitHub, asset download stats, whathever we can figure this out) to do the initial curation.
• Maintainers demand (maintainers agreeing this should be endorsed).
• Some general rules that need to be set in place that the asset needs to pass.
• An independent, anonymous jury (probably only known by the foundation)
• Ultimately as a warranty that the system can't be rigged, the foundation board can have veto power (though as always Godot, never actually use it).

Similar to how it happens with proposals here, the decision is not only a clear set of rules that need to pass, but general consensus between all the above entities mentioned, Godot style. This eliminates the potential of rigging and conflict of interest, or people trying to bend or reinterpret the rules in their favor.

Additionally, to me this should be a reject by default policy. An endorsed asset means the foundation gives a vote of confidence on something, and hence community expects the foundation to choose well. This means striving to have few instead of many endorsed assets.

[TokisanGames]

@TokisanGames Endorsed plugins are by definition those not worked by core devs but by community separated from the project, but endorsed due to their value. Official plugins are those hosted in the Godot GitHub repository.

@reduz I'm clear on that. Doesn't change what I said.

Both core devs and plugin devs need priority on engine bugs that affect both official and endorsed plugins. Whether that's clayjohn, Zylann, myself or anyone else. If an engine bug languishes for years, it potentially affects dramatically more people if it has hamstrung a plugin.

[AwayB]

Edit: proposal already up.

[reduz]

@AwayB I think dependencies is a separate thing that should be discussed. While many of us in the project are against having a system like pip (or Unity packages) because its very easy to run into dependency hell or lots of dependency bloat, there is general consensus that having basic dependencies between assets should be something that must be supported.

I want to open a specific proposal about it too, but one thing at a time, so I suggest not derailing this discussion to offtopic.

[reduz]

@TokisanGames

Both core devs and plugin devs need priority on engine bugs that affect both official and endorsed plugins. Whether that's clayjohn, Zylann, myself or anyone else. If an engine bug languishes for years, it potentially affects dramatically more people if it has hamstrung a plugin.

Unfortunately as I said many times, this is not how Godot works. While the production team pokes contributors in general for each release to take a look at bugs (and the poke is a bit harder if the bug is critical), ultimately it is still up to contributors to focus and fix a bug, they can't be forced to do it.

[theraot]

There are plenty of proposals around assets already. @AwayB, these are adjacent to what you say:

• Add dependency handling and enable users to organize and publish addons and addon-collections as packages #142
• Add support for global plugins/universal addons #831

[reduz]

@theraot I think these are pretty much agreed as wanted, but what is missing is proper technical implementation proposals for those. For global editor plugins I opened this proposal, which I believe is the most sensible way to do it.

[Flynsarmy]

I was originally against the idea of the 'endorsed' category as it would result in us just getting a list of gdquest and Kenney add-ons with everyone else left in the dust, however some of the things reduzio proposed changed my mind:

• They must be free and open source
• They must be maintained and lose endorsement if not
• An anonymous jury has final say (outside of the never-used foundation veto)

These all sound pretty essential. My only issue left is jury selection. Who gets to be on the jury? What happens when a jury member wants to submit an asset? How long will they be on the jury? If it ends up just being the popular content creators (ie the two listed above) it also wouldn't be very anonymous.

[mathphye]

Please add also 'local', 'own', or 'my add-ons'. Copy/pasting add-ons that you made should be possible to do within the Godot software. Allow to set a global folder to call/import add-ons from there.

Also, you might collect many add-ons in a local folder and want to reuse them, instead of downloading them frequently.

[reduz]

@Flynsarmy If there is a jury (again all this is speculation) I imagine it should meet the following criteria:

• Picked by Godot Foundation board, since it is possible this may be paid work.
• Anonymous to avoid harassment.
• It definitely should not be composed of anyone creating assets for the store.
• Their work will pretty much be checking if maintainers and community are in consensus for a given asset, and ensuring foundation board does not veto (which should never happen in practice if there is consensus).

[Flynsarmy]

Another important topic I'm not sure has been brought up yet is the author's desire for an asset to become endorsed. I believe the author should kick off the process by applying for endorsement.

This way if an author puts out an incredibly popular asset but does not believe they are willing or capable of continuing to meet criteria for endorsement, it won't be surprisingly placed upon them.

Edit: Ignore everything above. This is even better #8114 (comment)

[reduz]

@Flynsarmy To be honest, the process would probably be the opposite. Authors being reached to to see if they are OK being endorsed. Nothing prevents authors to reach out and ask, but this should not be a formal process in my view.

These assets need to be verified and tracked in every Godot version to see if they are up to date, whether they do what they are supposed to, and generally there will be a lot of care put into ensuring that the author is someone trustworthy or with a track record (since after all, this means the image of the foundation is at stake by endorsing an asset).

The idea is these are the minimum possible amount of assets so its something that can be maintained, and not a free for all process.

[TokisanGames]

ultimately it is still up to contributors to focus and fix a bug, they can't be forced to do it.

@reduz There's a lot of room between "force" (making demands of paid staff) and leadership through organizational focus and priorities. You and the board already lead through setting technical direction and philosophy. You already identify critical bugs. I'm not asking for a change from how you already operate. I'm asking for a refinement in process for flagging bugs that impact a high number of people.

Perhaps not just a critical label but a high priority label, and a way for plugin devs to get these bugs flagged. That way, if a contributor is looking for direction on which bugs to tackle, they are more likely to target critical, then high priority bugs first.

Eg the bug I noted is just marked as bug/confirmed. Same as 10s of thousands of others. Most games didn't need to save >1gb resources before, but now a terrain system exists and many more games could start running into that limit.

[theraot]

If there will be an endorsed category, I would be interested in this criteria: don't have warning or errors even in the more restrictive settings.

Yes, I know GDScript warning are disabled on the addons folder by default, but:

• On one hand, I turn it on warnings on the addons folder for the benefit of those I develop internally. And I cannot turn it off for specific addons.
• On the other, I would want code quality from endorsed addons, for example static types as much as possible.

Although, I understand this might be too much work to check. I'd wish for as much as possible of the review system to get automated, for the ease of whoever has to deal with this.

[patwork]

This is something that should absolutely be done, once the new Asset Library Store is up and running. Why reinvent the wheel? Just look at the current Unity or Unreal stores.

1. through the process of 'buying' assets by adding them to your cart and your account, you collect information on how many people are interested in a particular asset

2. through the 'add to favourites' process, you have information on which assets are recommended by the community

3. Through comments and ratings (1-5 stars), you have information about the quality of the assets, and in addition, by keeping track of the ratings of a particular asset over time (e.g. after subsequent updates), you know how involved the authors are.

Finally, a selection of the best assets can be hand-picked by the core team and displayed on the main shop page.

[bodamat]

Would be good in the future also have rating system with comments and release notes. It will make clear if some assets is not malicious or mistakenly did something wrong with project and creator of the assets need to fix it. Also information for which Godot version it was made. Old assets could be compatible with new ones, would be good to know it.

I think in the store should be some point to donate to the assets or make it completely paid. Yes it’s hard decision and maybe someone don’t like it, but make it endorsed cost a lot of time, which is hard to do it free. Even some kind donation could help in it.

For the company assets I think it should also have some label, not just community, because there another structure to make assets and could be also another type of support.

[bitbrain]

Would be good in the future also have rating system with comments and release notes.

One challenge with anything that requires comments is that it also requires some sort of content moderation. Review bombing on Steam are a good example for this and introducing comments demands an infrastructure for appealing reviews + comments (which someone then needs to look at). Otherwise you might end up with a review score that may not truly reflect the quality of an addon. Also, how would someone be able to leave a comment/vote? That may require an account system, and people could just create hundreds of accounts to downvote/upvote an addon?

[bodamat]

About moderation, I think author of the plugin can decide or report about it. Reported by author has bigger priority.

Yes, a review can be downgraded, and still need to check the asset's reviews to understand the point, so comments could be mandatory. This will be much easier to understand, but at the same time, review can leave only person who bought or download it. This is preventing a lot of attacks, because download it to each new created account is time-consuming.

After these implementations, I didn't see so much review bombing. Yes, it still can be, but so much less. No one secure about anything.

[Flynsarmy]

Not sure comments are a good idea as much as a forum for each add-on. A good review isn't super helpful and a bad review is often user error but reflects negatively on the author and the addon. Half the time in my experience bad reviews are just support request demands in disguise or comments on 'missing' features that would make no sense in the addon to begin with. All of that stuff could be sent to the add-ons forum instead.

[SlugFiller]

I feel like if it appears in the Create New Node at all, then #6934 needs to apply. It shouldn't just show a link. That's not useful in this dialog. While not every plugin adds a node, most of the ones that are most likely to see common use from many users, are the ones that do.

Obviously, what's necessary is a combination between the two. You want to just show new node types and allow auto-installing a plugin that provides them. But you also want to filter by plugin reliability, i.e. official vs community. You don't want all community nodes to just show up by default.

And yes, you also want to be able to add third party sources. If for no other reason than the author wants to update more often than having to poke an asset lib maintainer on every update would allow.

As for "endorsed", which IMO took way more of this issue's discussion than it should have, since there is "official", then "endorse" should be derived for it. As in: It's something that the Godot maintainers/foundation did not write, but did do a full code review of, and/or are using themselves. It shouldn't be votes/jury/reviews/etc. That can be provided separately, and is applicable to community.

Also, if at all possible, "endorsed" should be version-locked. As in if you activate only "endorsed" you only get an officially reviewed version of the addon. But if you activate "community", you may get access to a more up-to-date version of the same addon. This would prevent a bait-and-switch scenario.

[PPillau]

I think this whole "lets make everything a plugin rather than base functionality" attitude of some of the Godot maintainers will harm Godot's growth and it's future prevelance.

As an example let's take the terrain functionality. While all of the points made in this twitter thread by reduz might be true (eg. complex, high level problem, individual worksflows, etc.) this is and will always be a feature that people just... need. No way around it. A good game engine needs a terrain creation workflow...

"But if the community needs it then they can just create it themselves via a plugin", while that might be a positive way of thinking, there is a huge problem with it and the whole "Godot will endorse plugins from the community" approach:

Endorsement is just that: A label. Nothing more.

Let's think about what endorsement really is: Godot is officially telling everybody that this plugin right here is usable, reliable and of very high quality. While that might be a nice thing to know, it really doesn't tell me anything about the future of this plugin: Who says that this plugin will be usable, reliable and of very high quality tomorrow?

Exactly: nobody!

Let's say the developer of that endorsed terrain plugin decides to not maintan it anymore, starting today? What will happen next? Will somebody else in the community pick up the repo? Will godot maintainers? Will it get integrated into engine instead? I simply don't know. The only thing I do know is that eventually it will lose it's endorsement status.

Wow... That really is a huge relief... not. No I am stuck 2 years deep into the development of my project, and the one plugin that I rely on lost the little "endorsed" flag next to it. No way to know if that critical bug get's fixed anytime soon, or if that long-awaited feature will get integrated into the terrain editor.

The endorsement status has brought me no merit at all in this scenario, which in itself is not an unlikely one at all. In my time learning godot I have probably stumbled upon ten or more cases where that really cool feature I really need right now is a plugin on a github repo that only supports Godot 3 and has last been updated 2 years ago...
Not to mention that for terrain editing there are like 3 big projects right now? Which of these is the most stable and doesn't crash my engine every 2 minutes? I simply don't know...

Now you migh ask: "All of open-source development has this same problem". While that might be true theoretically, there is something that differentiates projects like Blender and Godot from any open-sourced github repository out there: Funding

As long as funding for an open source project like Godot continues at an acceptable rate monthly, I basically get a guarantee for the future that this project will receive new updates, or at the very least bug fixing for ever.

This right here is the big takeaway from my comment:

And endorsement status is just a label, while funding is a guarantee for the future

So if the critical featuers like a terrain editor or behaviour trees are integrated into the engine directly and not sidelined to plugin-status, it basically guarantees everyone in the community that this feature will get maintenance for as long as the engine exists...

[SlugFiller]

I think this whole "lets make everything a plugin rather than base functionality" attitude of some of the Godot maintainers will harm Godot's growth and it's future prevelance.

There is a pretty big reason for that attitude. Godot engine is incredibly small. One of the reasons I picked up Godot, is because I had just finished trying Unreal, and besides being horribly unintuitive to use, a nearly empty project exported at over 1GB. 1GB, for an empty project!

Given that the goal of the project I was working on at the time, was to upload it to a small free host, that was utterly unacceptable. By contrast, Godot was so tiny, I could fit a web export within the strict limitations of the free host.

Now consider that every added feature compiled into the engine, is bundled into every game. Sure, there's a flow for building Godot with various modules turned off. But compiling to multiple platforms is a very difficult process. At a bare minimum, you're going to have trouble with Mac. By contrast, installing an addon takes only a couple of clicks.

For web exports in particular, the engine has to be as lean as possible. Because each time any user plays the game, they have to download the engine fully. This is both time the user spends waiting for the game, and bandwidth load on the host you've put the game on. There is no reason you and your users should have to pay for a feature you do not use.

A good game engine needs a terrain creation workflow...

What a perfect example of what a game engine absolutely does not need to have in core. Imagine if every person making every type of game in Godot, ever, has to ship that game with a terrain node in the code. Even if it's a 2D platformer. Even if it's a Pokemon or Undertale clone. Even if it's an Antichamber-style first-person puzzler. Or a city-scape racing game.

Heck, off the top of my head, I have a hard time thinking of a game which uses terrain. Flight simulator, maybe? At the very least, it's hard to justify every single game paying overhead for the few that might use a terrain system.

And mind you, you are benefitting from this as well. Even if every game you create uses a terrain system, I'm betting at least some of them don't use a dialog system, or an inventory system, or a destructable objects system, or a procedural maze generator. If you start thinking that anything and everything is "necessary", the list never ends. The result would be what you get with Unreal (and, honestly, with Unity, too): A 1+GB export for an empty project.

Let's say the developer of that endorsed terrain plugin decides to not maintan it anymore, starting today? What will happen next?

You will continue to use the last released version for the duration that Godot 4 is supported. Godot's non-breaking guarantee means that if the addon works on 4.0, then it must work on 4.99 as well.

No way to know if that critical bug get's fixed anytime soon, or if that long-awaited feature will get integrated into the terrain editor.

If it has a critical bug, it wouldn't have gotten endorsed in the first place. If there's a feature you want that it doesn't have, there was no guarantee it was going to get implemented anyway. Even if thousands of people want it. Just like Godot itself (cough Vector Graphics cough) You can always add it yourself.

The entire thinking here is backwards. Most dev-oriented package managers nowadays (Maven, NPM, etc) actually recommend locking your package versions, to make sure they do not receive updates. Because it's a lot better to rely on the version you've already integrated into your project, and tested with your use case. Newer versions have just as much of a likelihood to introduce bugs rather than solve them, and updates are usually only done if a critical security flaw is found (Like in the webp case). This is why I suggested that endorsement should be on a per-version basis, not a per-addon basis. Because it's better to have an old and reliable version.

(And, just to show I practice what I preach, I'm writing this post on a fork of Firefox 56)

As long as funding for an open source project like Godot continues at an acceptable rate monthly, I basically get a guarantee for the future that this project will receive new updates, or at the very least bug fixing for ever.

You overestimate how much funding Godot gets. Just the other day, one of the maintainers gave a speech mentioning that they, and most of the maintainers, are working for free, with only very few of them getting symbolic pay. It was in the context of "You're getting paid, why don't you make features?", but the point still applies.

So if the critical featuers like a terrain editor or behaviour trees are integrated into the engine directly and not sidelined to plugin-status, it basically guarantees everyone in the community that this feature will get maintenance for as long as the engine exists...

Having them as official plugins would achieve the same (at least, to the degree that any other part of Godot is maintained, which might not be as much as you think), but without adding an extra download cost to every web-based shmup made in Godot.

P.S. And since you mentioned behavior trees, another disadvantage in making something a core feature, is that it would mean there is exactly one implementation, and one interface. And for some advanced/complex features, people might not agree on a single way in which they should work, or be presented.

[TokisanGames]

@reduz @akien-mga Is it possible in a future version to change Godot's build structure so that core modules are built to external libraries as plugins are today? So, multiple core supported terrains, godot physics and jolt physics, the fast noise library, csharp, image compression libraries, maybe even the 3D renderer are all built to dlls/libs that are included or excluded with projects during export time? Then web exports and mobile games could get even smaller, including only the libraries needed (which could be manually chosen or auto detected)?

Godot's non-breaking guarantee means that if the addon works on 4.0, then it must work on 4.99 as well.

As a terrain plugin developer, there is definitely no such guarantee in practice. I've had to make changes from 4.0 to 4.1 and keep a running log of changes we need to make it work in future versions. I already know of at least one thing I need to fix for 4.2. The API changes all the time in major and minor versions. It's only consistent in patch versions (4.1.0->4.1.1).

Not to mention that for terrain editing there are like 3 big projects right now? Which of these is the most stable and doesn't crash my engine every 2 minutes? I simply don't know...

What is stable for GD4 are:

• Zylann's HTerrain as a heightmap based GDScript plugin
• Zylann's Voxel Tools as a voxel based C++ module
• Our Terrain3D as a heightmap clipmap based C++ plugin

I know of least two others in development for public distribution, and a few others seemingly for private use.

[vpellen]

The argument against feature excess has always struck me as a little disingenuous. There isn't a single feature that nobody uses, and there isn't a single feature that everybody uses. Every feature is optional to somebody, and every feature is vital to somebody.

While it's true that if you try to include every wanted feature you'll end up with an engine so bloated that nobody wants to use it, the counterpoint is that if you cut every feature that isn't used by the majority then you'll barely have anything left at all. There has to be a happy middle ground between "barebones glue library" and "20 gigs of engine bloat". Finding that middle ground is a matter of arbitration.

The problem with Godot, then, is that the current method of arbitration in regards to what constitutes an "essential feature" appears to be a matter of autocratic tasseography.

[SlugFiller]

there isn't a single feature that everybody uses

_process. But that's kind of a smarmy answer. Still, if you ignore die-hards who use the servers directly, most of the basic scene tree stuff is used. And 2D is used for compositing even if you're making a 3D game with no hud or menu. Something like navmesh can be more questionable, but read below as to why that's not an issue.

I think the definition of "essential feature" is pretty clear: Anything you can't implement with the existing features is an essential feature. For instance, you can't implement SDFGI using GDShaders. You could try, but you would fail. It would need extra steps that can't be accurately emulated with stacked viewports, certainly not at comparable performance.

Navmesh is an even better example. The majority of games probably do not need it. You don't need it for a shmup, or a platformer, or a board game, or a JRPG, or a flight simulator. But refactoring it into a plugin is just not practical. You couldn't get the baking and necessary performance done without tight integration with the engine and editor.

If it had been possible to refactor it as external, it would be my first vote.

And hey, having a more modular engine is actually a good thing.

P.S. Speaking of Terrain, I will point out that while terrain itself is not being integrated into the engine, supporting low-level features that make it easier to make are being integrated. cough Drawable textures cough

[vpellen]

_process. But that's kind of a smarmy answer.

It's also an answer that I can easily out-smarm: There may be a legitimate desire to tie everything to _physics_process and never touch _process. Hell, if you're making a turn-based roguelike, you may want to tie everything to signals and _unhandled_input.

But, of course, that's not the main issue.

I think the definition of "essential feature" is pretty clear: Anything you can't implement with the existing features is an essential feature.

This definition seems fine until you realize how easily it fails to a basic test of logical regression - You can implement most things in GDScript if you've got the time and the patience and you don't mind the performance hit. You touched on it a bit closer when you mentioned certain things being "just not practical". Game engines are, by definition, a tool of convenience. There's nothing Godot can do that can't be done in a dozen other languages - it's just that doing it in Godot is far easier. That's what the arbitration issue is about - what features warrant being a part of the "main engine"? Who draws that line, and where, and why? This isn't unrelated to the current topic, either - the whole point about the nature of add-ons is that it's downstream from that fundamental problem of arbitration.

That said, I don't object to the idea of a heavily modular engine, though that also leads to its own problems with decentralization. Unity tried to follow the mindset of multiple solutions, and they ended up with three renderers, several GUI implementations, and two different input systems. There's no reason Godot why isn't capable of ending up in just as miserable a situation.

[SlugFiller]

It's also an answer that I can easily out-smarm: There may be a legitimate desire to tie everything to _physics_process and never touch _process.

It's the same feature. They both follow the same code path, with the exception of _process_physics being called inside a loop a bit earlier in the iterator. At certain parts of the code path, the only difference between the two is a bool p_is_physics.

Hell, if you're making a turn-based roguelike, you may want to tie everything to signals and _unhandled_input.

Halfway granted. "Halfway" because it only works if the game is also visually static. i.e. Between turns, it's a screenshot. It only takes a single animated sprite or button to require _process.

You can implement most things in GDScript if you've got the time and the patience and you don't mind the performance hit.

As someone who actually tried that a few times, it only works if you use an absurdly loose definition of "performance hit". GDScript can be 2 orders of magnitude slower than native code. If an algorithm that needs to run once per frame (at 60 FPS) is re-implemented to require 10 seconds per run, then you don't have a game. Otherwise, you may as well write a whole software renderer in GDScript. It'd only take a few weeks per frame rendered.

Just as an example, I implemented unzip in GDScript, and it turned 200 milliseconds (using the native method) to 20 seconds (using GDScript). If this was used to load resources needed by a game, this would turn a near-instant start into a PS1-era scratched disc loading times.

If you reduce the definition of "practical" to "I can actually release this game as more than just the Godot equivalent of 'I made Doom using redstones in Minecraft'", then it becomes a far more objective definition.

I will admit that the existence of GDExtensions blurs the line there a bit more. Eventually, it might even be possible to move things that are currently core to GDExtensions. Maybe even navmesh. But currently, it's not doable. GDExtensions still lack some basic functionality, like support for web export. And there are some aspect of the engines that are not yet exposed to GDExtensions (and, by extension, to GDScript) at all, like the rendering pipeline internals used by the new custom compositor being currently developed.

Game engines are, by definition, a tool of convenience. There's nothing Godot can do that can't be done in a dozen other languages - it's just that doing it in Godot is far easier.

There's a pretty big difference between "install an addon" and "write your own engine". Godot itself has been developed for well over a decade, by a large number of people, has many algorithms that even experienced programmers would have trouble creating from scratch (e.g. physics), and still relies on many third party libraries. Installing an addon is just a couple of clicks. At worst, it takes 10 minutes.

Godot is not supposed to give you the same convenience as having every addon out there installed. It's supposed to give you the convenience of being able to install those addons with sufficient ease. Hence going back to the original point: If it can be an addon, then it should be. If it can't be an addon, figure out why, and fix that issue locally.

[vpellen]

Hence going back to the original point: If it can be an addon, then it should be.

That's a reasonable stance to take, but you might want to think carefully about just how low a bar that really is. I'm not being facetious - if you try and find a lower bound for "could reasonably be an addon", even if you have a fairly safe definition of "reasonable", you might be surprised at just how much could conceivably be stripped out of the engine and stuck in its own repository.

And if that's where Godot wants to go, that's definitely a discussion worth having, but right now we're not talking about a total overhaul to the nature of the engine, we're talking about some arbitrary midpoint where features get offloaded to the community. My question is, and will continue to be, where is that midpoint? Because there are a ton of things that are in the engine right now that could be purged from the engine, and I wouldn't mind knowing where the line is going to be drawn, because my ability to use Godot directly depends on that knowledge.

I don't think it's unreasonable to describe Godot's scope limit as somewhat nebulous, and I don't like the idea of investing my time and energy into something with an unstable foundation. That's why I'm even in this thread in the first place.

[favoyang]

I am the author of OpenUPM, a public registry for the Unity Package Manager. I'd like to provide insights into this multifaceted topic.

Unity's journey begins with core editor releases every year and asset stores for 3rd-party content.

Later, Unity recognized the challenges of aligning every feature with a major release to introduce bug fixes or new features. They sought a more modular system and introduced the Unity Package Manager. This package manager system adopted the NPM protocol on the server side and implemented a client based on Unity's vision. With this evolution, Unity content can be categorized into several layers:

• Unity's core engine that provides fundamental features such as language and editor APIs.
• Unity module packages hosted on the official registry, offering essential features for game development.
• Unity Asset Store content, which essentially consists of mutable content that gets unzipped into your project folder.
• 3rd-party packages hosted on a registry like OpenUPM, essentially containing immutable content managed by the Unity Package Manager.

In a modern package manager like NPM, managing packages with operations like adding, removing, listing, and updating is more streamlined. It introduces the concept of dependencies, where your content relies on the work of others—a common practice in modern software development. While it's not a one-size-fits-all solution, the benefits are substantial, particularly for fundamental software.

The downside of Asset Store content is its mutability. Once installed, it's challenging to uninstall, and updating to the next version can be tricky. The package manager system partially resolves this issue by making packages immutable. Mutable components are imported into the project folder as needed, and once imported, they are no longer managed by the package manager system.

Historically, the Unity Asset Store predates the package manager system by a few years and has been a significant success in the Unity ecosystem. However, the transition to the new package manager system has been gradual. Often, if you import several 3rd-party Asset Store contents, your project folder can become quite messy.

I know there are a few discussions about the package manager for Godot. And this proposal can be a more pragmatic solution for now. However, understanding the trade-offs of Unity's approach can provide valuable insights. Here are my two cents:

• Implement a package manager that can provide fundamental values to the system.
• Build the asset store on top of the package manager rather than maintaining two different systems.
• A web UI is more flexible than any in-editor GUI for discoverability because you don't ship it with the editor binary. Consider a robust package manager in the editor that can respond to adding, removing, updating, and listing installed packages, along with a continuously improved website for asset listing.

[SlugFiller]

you might be surprised at just how much could conceivably be stripped out of the engine and stuck in its own repository.
Because there are a ton of things that are in the engine right now that could be purged from the engine,

I'd appreciate a list, or at least one or two prime examples. There are a lot of features in Godot I still don't know/haven't explored. But of the ones I do know, I can't point at any and say "This could be done just as easily in GDScript, without suffering a significant framerate drop or load times from hell". So I'm very open to counter-examples.

(Closest I can think of is vehicle physics, but that topic is a whole can of worms in and of itself)

That said, backwards compatibility demands nothing be purged unless a perfectly compatible plugin can be auto-installed when upgrading from older Godot versions. If and when that becomes a possibility, I'm all for purging any features that don't absolutely need to be in core.

[PPillau]

Hence going back to the original point: If it can be an addon, then it should be.

This comment still IMO represents the a wrong approach for Godot. Instead of thinking about what we can "get rid off" we should be thinking about what fundamental feature the engine is still missing.

As @vpellen mentioned, if we go down that path we can argue for basically next to everything to get removed from the engine for the sake of simplicity, maintainability and lightweightedness....
Multiplayer functionality? Throw it out, 90% of people dont't use it. Navigation also too advanced for many people. Heck throw out 3D completely because 50% of games aren't using them ;)

In the end we can probably reduce the Godot editor to a terminal window. Now we really only have things in there that everybody needs! \s

See the thing is most people just want things to work out of the box, and I am telling you now that having features just not in there, will make people move to other engines, because the entry barrier for getting the feature into the engine is just too high.

Godot's non-breaking guarantee means that if the addon works on 4.0, then it must work on 4.99 as well.

As @TokisanGames already refuted this point, my initial argument still stands: The endorsement flag is nothing more than a label that can disappear from one day to another leaving me with a no-longer supported version of an otherwise essential feature in my game engine.

You overestimate how much funding Godot gets. Just the other day, one of the maintainers gave a speech mentioning that they, and most of the maintainers, are working for free, with only very few of them getting symbolic pay. It was in the context of "You're getting paid, why don't you make features?", but the point still applies.

Well... then they should be getting payed right? Isn't that the whole point of the funding in the first place? Hire as many developers full/part-time as possible with the currently available amount of funding, and depending on how many there are focus on bugfixing only (or future features if possible).
I want my funding to go towards the developers that work on the engine I use...

Having them as official plugins would achieve the same (at least, to the degree that any other part of Godot is maintained, which might not be as much as you think), but without adding an extra download cost to every web-based shmup made in Godot.

No this is absolutely not the case. As I have stated beforehand the difference is very big: Everything that is IN the engine is getting maintained by my and everybody else's funding, so i can directly control that the terrain editor I need is in the engine I need.
Everything that is NOT IN the engine but in a plugin instead is getting maintained by RandomCoder123 on github, who moves on after 1 year because he is no longer interested in the project so it's rotting away in some repository and no amount of money I throw at his paypal can get him back because he just doesn't care anymore.

If the terrain editor plugin I use dies, the plugin dies. If the Godot editor dies (because of a lack of funding) then the whole project dies, but there might still be enough community pressure that other people continute it's legacy. I do not have that kind of guarantee for all of these new "endorsed" plugins.
When using Godot I am taking on 1 risk: The risk of the project itself dying. When using Godot engine + random plugin ABC I am taking on 2 risks now: The risk of the project itself dying, and the risk of the plugin dying. Double the risk already...

There is a pretty big reason for that attitude. Godot engine is incredibly small. One of the reasons I picked up Godot, is because I had just finished trying Unreal, and besides being horribly unintuitive to use, a nearly empty project exported at over 1GB. 1GB, for an empty project!

This I don't understand. Why should features inside the Godot Editor (like terrain editing tools, or a drag and drop graphical behaviour tree) affect the project-size of the compiled project (or project directory for that matter). The heightmap for the terrain takes up disk space whether I create it inside Godot or with some 3rd party tool.
And if you are talking about the Godot Engine itself, that is a 115 MB file right now and IMO easily be stuffed with features until more than double the size at 300MB and it still would be 10 times more performant and lightweight than Unity and Unreal and all the other stuff out there.

(And, just to show I practice what I preach, I'm writing this post on a fork of Firefox 56)

And this right here I think is the underlying problem: Just because you and the Godot maintainers think like this, doesn't mean everybody else does or even cares. 99% of people don't lock there browser version because of potential problems with updates further down the road. 99% of people don't use Linux because of security concerns or whatever.
And 99% of people will not care for the reason why this new engine they are trying out doesn't have a terrain editor, as good as those reasons might be. They will simply shrug their shoulders and say "guess I'll go to Unity then, cause they have it".
The only thing that line of thinking achieves is alienate part of the potential userbase, because they don't want to scour through endless lists of plugins to find the thing that they need, then decided between 5 alternatives of basically the same thing because there are so many individual ways to of doing something and people have different preferences.

Guess what? You don't have to reinvent the wheel every other day. If you have a feature in the engine it will be perfectly fine for 95% of users. Just make the feature (like a terrain editor) like they do it in Unity or Unreal, and mostly everbody will be perfectly fine with it. And for everybody else who doesn't see his needs fullfilled can move on to some additional plugin. But for the rest of people they now have a prebaked solution in there all-in-one game engine editor.
Now everbody is happy :)

[Flynsarmy]

Any chance we can get this thread back on topic? It's not about what features should and shouldn't be part of core, it's about discoverability of curated add-ons...

[aaronfranke]

@PPillau Your argument of "Who says that this plugin will be usable, reliable and of very high quality tomorrow?" is not applicable, because that guarantee also does not exist for engine features. The people maintaining an engine feature can disappear in the same way that they can disappear for an endorsed plugin.

Everything that is IN the engine is getting maintained by my and everybody else's funding, so i can directly control that the terrain editor I need is in the engine I need.

This is just not true.

1. What leads you to believe that everything in the engine is being maintained?
2. What leads you to believe that the parts of the engine being maintained are doing so through funding?
3. What leads you to believe that an official addon can't be funded by the Godot development fund?
4. What leads you to believe that an official addon won't keep working like an engine feature will?

Many parts of the engine are not being maintained by paid contributors. A lot of Godot's development is volunteer work ("RandomCoder123 on GitHub" as you put it). If the people doing that work leave, that part of the engine will likely just sit around unchanged - the same outcome as if an official addon was not maintained, it will very likely still compile and run as it did before.

This comment still IMO represents the a wrong approach for Godot. Instead of thinking about what we can "get rid off" we should be thinking about what fundamental feature the engine is still missing.

No, that's wrong. Godot's number one development philosophy is the problem comes first. We must first approach with problems that need solving, and then find a solution. That solution may be in the form of an engine feature or an add-on. But regardless, we do NOT start by thinking about what features the engine is missing, because that will lead us to just adding features for fun with no target use-case.

Heck throw out 3D completely because 50% of games aren't using them ;)

On one hand, it's true that many games don't need 3D. This is why Godot has the disable_3d=yes compile option (and here's the equivalent for 2D). But 3D is extremely common, and every 3D game needs similar capabilities of 3D nodes (transforms, meshes, lights, rendering, physics, etc), and we must provide a solid base for addons to built on top of (ideally, we won't have many addons that depend on other addons - so having 3D be an addon which every other 3D addon depends on is not good). Therefore, 3D must be a core feature of a 2D and 3D game engine.

I want my funding to go towards the developers that work on the engine I use...

Why can't the engine you use be "core engine + addons" instead of "one big core engine"? Why would the funding have to only go towards the core engine?

Why should features inside the Godot Editor ... affect the project-size of the compiled project

Only features in the export templates affect the exported project size. Godot's export system is highly simplified, by default it just copies the export template (engine executable) as-is, and all project data is placed into a .pck file.

If a feature is truly editor-only then it won't affect the export template size, but that doesn't mean we can just ignore the bloat. It would still increase the download size of the editor, make it bigger, slower to start, etc. Qt takes up over 20 GB, while Godot has a great GUI system at only a tiny fraction of the size. This is because Godot doesn't look for features to add, it looks for problems and tries to solve them.

[patwork]

The thing is, it is not clear which should be curated.

In my personal opinion, a good example of curated addons is the Blender collection. A selection of projects started by various developers, currently maintained in the Blender repository (https://projects.blender.org/blender/blender-addons.git). For example, the Node Wrangler plugin written by Bartek Skorupa and Greg Zaal has been moved and the original repository was archived (https://github.com/gregzaal/node_wrangler). This ensures that even the eventual abandonment of the project by the original authors does not mean that no updates are possible. In other words, each curated/endorsed plugin must first be added to a repository belonging to the Foundation.

Personally, I don't like the 'find more in add-ons' buttons, as they resemble Microsoft's attempts to use Bing search. Additionally, once the new Asset Store is up and running, such redirects could suggest that additional functionality costs money. How do you explain that only free addons can be endorsed? If some revolutionary $1 addon appears in the Asset Store, will you recommend another inferior one, just because it is free?

My suggestion is to create a list of addons that will be supported and maintained by the Foundation and display them when a new project is created:

[SlugFiller]

As @vpellen mentioned, if we go down that path we can argue for basically next to everything to get removed from the engine for the sake of simplicity, maintainability and lightweightedness....

Can we? Well, let's see, what do we have here... A perfect list of counter-examples.

Multiplayer functionality? Throw it out, 90% of people dont't use it.

But it can't be an addon, because network traffic will not wait for GDScript to serialize and deserialize a whole scene. You can't afford to have your scripting language add lag on top of network lag. Especially not in action games where every millisecond of lag matters.

Navigation also too advanced for many people.

I've already explained why it can't be an addon. Baking a navigation mesh is a process that's already long enough when written as native, and would take away a year of your life if you had to do it in script. Per export. That means your game would take 50 years to release, because you're waiting for navmeshes to bake.

Heck throw out 3D completely because 50% of games aren't using them ;)

But the remaining 50% do need 3D, and there's no way to do it on top of 2D, not with an addon, nor any other way. It can't be an addon, therefore it isn't.

Again, let me repeat the previous point: If it can be an addon, then it should be.
And conversely: If it can't be an addon, then it shouldn't.

Stop giving examples that absolutely can't be addons.

The reality is that no, not every feature can be removed if you take things too far. But the converse is not true: If you take things too far, you absolutely can add a shitton of features, which would simply bloat the engine, and make it unusable for everyone. Or at least for anyone targeting web, where every byte matters.

Well... then they should be getting payed right? Isn't that the whole point of the funding in the first place? Hire as many developers full/part-time as possible with the currently available amount of funding, and depending on how many there are focus on bugfixing only (or future features if possible). I want my funding to go towards the developers that work on the engine I use...

Again, you extremely overestimate how much funding Godot gets. Most of it just goes to keeping the website up and running.

This I don't understand. Why should features inside the Godot Editor (like terrain editing tools, or a drag and drop graphical behaviour tree) affect the project-size of the compiled project (or project directory for that matter).

They don't, but they are also insufficient for creating terrain. Look at the existing terrain plugins. They aren't simply editor plugins that go away on export. You need terrain generation, chunking, culling, terrain-specific physics collisions.

The same is true for a behavior tree: You don't just need an editor. You also need a module that actually runs the behavior tree you created when the game runs. Otherwise, it is just a meaningless tree of nothing.

The heightmap for the terrain takes up disk space whether I create it inside Godot or with some 3rd party tool.

As does the chunking, culling, and physics code, not to mention the shader. The problem is that, in the case of a core feature, the latter also take disk space from people who don't use heightmap terrain. In the case of an addon, however, it takes space only from you, who actually install the addon, and not from anyone else.

And if you are talking about the Godot Engine itself, that is a 115 MB file right now and IMO easily be stuffed with features until more than double the size at 300MB and it still would be 10 times more performant and lightweight than Unity and Unreal and all the other stuff out there.

It would be more lightweight than Unity, sure. But at 115 MB it's already 3 times the size of Godot 3, and several times the size of the average web game. (Actually, I have an old web export from Godot 3, and the size of the wasm is merely 13MB. But the desktop version is 32MB, so I'll measure by the larger one) The fact that Unity and Unreal are terrible doesn't mean they get to set the bar. Godot is intentionally a lightweight engine, in contrast to those other two.

Compare it to something more along the lines of Construct.

Now think of the time and cost of downloading 115 MB on a mobile network. Now multiply it by 3. It is completely unacceptable. Some people have metered network, you know.

Even as is, there are talks about replacing certain third party libraries with smaller alternatives, just to shave off a few more megabytes from that hefty 115 MB. And make no mistake, that size is hefty. It's already too big. There are simply very few places that can be shaved.

99% of people don't lock there browser version because of potential problems with updates further down the road.

And then they're surprised when they get a virus, or have their harddrive encrypted and asked for ransom. Since when is what 99% of people do taken as a measure of anything? 99% of people have no idea what they're doing.

If you reduce the sample group to developers, however, the image flips. The vast majority of developers do lock the versions of their dependencies, build tools, etc. That's what the people who know what they are doing, do.

And for everybody else who doesn't see his needs fullfilled can move on to some additional plugin.

Except now they're paying double the disk space: For the version they're not using, and for the version they are using.

Now everbody is happy :)

Except anyone trying to export a small game for the web, suddenly finding out all of their users are complaining, because running the game takes 3 times as long, because the engine is 3 times as large. Oh, and all of those complaining users, of course. It's not happiness driving them to complain.

[vpellen]

I've been preoccupied but @SlugFiller I never specified that the addons had to be GDScript, that was part of a separate argument (namely that the definition of what "needs" to be implemented natively is subjective, because it is)
If you remove the arbitrary GDScript constraint, the "everything can justifiably be an addon" statement has far more weight

[aaronfranke]

@SlugFiller The statements about performance are not relevant if you are comparing to C++ in GDExtension (or similarly high performance languages like Rust). So I don't agree with that particular argument you gave for navigation.

Most of it just goes to keeping the website up and running.

I don't think "most" of the money goes to the website, it's just a website... barely any goes there.

[SlugFiller]

If you remove the arbitrary GDScript constraint

It's not arbitrary. Just the other day, I pointed this out in another issue: At the time of this writing, GDExtensions cannot export to web, and neither can C#. GDScript is the only language that supports all of Godot's platforms with no exception.

To add to that, because of the unfortunate choice to not add a compilation exception to GDExtensions's mandatory header file, GDScript is the only way to release an addon with an arbitrary license, and will continue to be so for the foreseeable future, possibly forever.

As a result, the natural assumption for "Can be done with an addon" is "via GDScript".

Do note that even if you did allow GDExtensions, you couldn't refactor 3D to it, because you'd need a way to at least get the native window handle to create a GL or Vulkan context, and such an API does not exist in core. But something like navmesh or physics server might be doable. And the popularity of the Jolt plugin suggests that this might be exactly the path Godot will eventually take, once GDExtensions sufficiently matures.

[dsnopek]

At the time of this writing, GDExtensions cannot export to web

(Totally unimportant correction: GDExtension will support exporting to web in Godot 4.2 :-))

[YuriSizov]

Please stay true to the subject matter of this discussion — discoverability of curated/endorsed addons. Operational costs of Godot are hardly a relevant point to discuss here. Neither is the meta point about what should or shouldn't be an addon.

[novemberist]

I don't know if this is out of the scope of this proposal and this is of course just my personal opinion, but I find the result of a lack of naming and style conventions in many Asset Stores / Libraries (including Godot's) usually very off-putting. I know most programmers are not artists, but I think there should be certain official guidelines, how icons and preview images should look like, assets/plugins shoud be named, what descriptions they should at least contain and how they are formatted - otherwise it just looks like a circus with flashing colors and odd names everywhere etc.

It might sound pedantic and like judging a book by its cover, but I find it very annoying whenever (I'm exaggerating here for the sake of argument) I see a $$$mYaSsetPaCk123$$$ with a pink rectangle and yellow text in comic sans as a logo and a one-liner description. I will simply not install something like this, even if it might be exactly what I'm looking for.

I know it's probably not easy to find consensus on what those naming/style conventions should be, but I think they are necessary for giving the Asset Library a professional look and feel and they should be enforced at least for official and endorsed add-ons.

[moritztim]

I think there should be certain official guidelines, how icons and preview images should look like, assets/plugins shoud be named, what descriptions they should at least contain and how they are formatted - otherwise it just looks like a circus with flashing colors and odd names everywhere etc.

think this would be great and we have an opportunity to make this work from the ground up, at least with paid assets, since they don't exist yet. If there is a style guide right from the start, I think it's actually realistically achievable to have a lot of assets following this.

Maybe there could be 2 tiers of style guides, a more flexible one for free assets, to avoid discouraging users from publishing and a more "restrictive" one, for lack of a better word, for the paid ones, since there's the added incentive of money

[Flynsarmy]

I believe the unreal marketplace has strict requirements for how uploads of each type of plugin must be formatted, named etc. Perhaps we could take influence from there? It's quite nice and made everyone's lives easier.