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: https://github.com/godotengine/godot-proposals/discussions/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: https://github.com/godotengine/godot-proposals/discussions/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:

• https://github.com/godotengine/godot-proposals/issues/142
• https://github.com/godotengine/godot-proposals/issues/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 https://github.com/godotengine/godot-proposals/issues/8114#issuecomment-1762883664

[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.

[SoyoTamo]

I think they should not be separated, and the difference should only be in some tags that the main team could adds, tags that only you can add. That would solve the problem and not create so much separation.

[AwayB]

@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.

For the initial curation, it would be interesting to have a "Pending" or "Requesting Endorsement" status for these addins. If the Foundation is going to be busy endorsing or discussing endorsement of a few addins, the system you've outlined seems sufficient, but what if it scales up to several dozens at the same time? It could be months before an endorsement happens, with a project staying in the "community" side without getting much attention in the meantime.

I think that if there is an interest from the maintainer (and the promise to keep maintaining), and some community support, the maintainer should be allowed to make a sort of official request and put his project as "pending" or "endorsable". Even if the endorsement doesn't happen in the end, this status is interesting:

• it shows that the maintainer has the intent to get it to endorsed status
• even if the project doesn't get endorsed, it can keep that status to indicate to the community that it wants to remain maintained
• it gives the community an occasion to get acquainted with the addin seeking endorsement and try it, and give feedback, both to the Foundation/jury and to the maintainer
• it makes the maintainer proactive, rather than having him passively wait for the Foundation or jury to make a decision
• if the project doesn't seem serious, the Foundation could use their veto to remove this "pending" status.

That way, you can get a community project sit as a "free, but no promises" tier of addin, a "pending endorsement" as a more serious, long-maintained project, and "endorsed" as fully endorsed. I think this works a bit better for the community. Names may have to be changed, I don't really like "pending endorsement" but I don't have a better idea.

[TackerTacker]

I think a big problem of the assetlib is layout. This is how much space one asset preview takes up in the list.

80% here is completely wasted space, literally empty, and that's not only this example, it's true for all the assets. Then what information do we actually get here in the 20% used space?

• A tiny icon, in this case (and many other) a Godot logo
• SPIRV importer (I don't know what that is)
• Shaders ( "Category: Shaders" So it has something to do with shaders. Only informative if you have "Category: All" selected )
• Author ( Important but not really relevant to me while searching )
• License ( For me personally, that's the only useful info ) So only 5% of this big asset preview capsule is filled with useful information.

Clicking on it to get more details reveals more empty space

• Description: Import *.spv files as RDShaderSPIRV ( Again I don't know what that means )

I'm sure the Author is amazing, the asset is amazing, and it's really cool that they spend their time creating this asset and putting it up for free. I'm also certain that people who need this will probably directly search for these terms. This is not meant to single out this one particular asset, I just randomly picked it as an example of something I see on the assets library all the time. Assets with the Godot logo as icon, no real description, not a single screenshot or broken screenshots, etc.

Maybe some info should be mandatory to fill out? Or maybe not mandatory but a warning that reminds the author that info is missing, that they didn't add any screenshots, or the description is very short. Another idea would be to allow a way for other people to write descriptions for the asset or add screenshots.

For the capsules, I think the layout needs to be more focused. What info do people look for when they visit the asset library?

• What is it ( name, preview image, description )
• how good is it ( update history, ratings, comments )
• What does it cost ( price, license, sales )

and how do we arrange it so that we waste less space

• An item like category, that's only 60-80px long shouldn't block an entire 650px wide row in the capsule
• Focus on a couple key elements, leave the rest to a bigger preview image in which authors can decide for themselves what's important for their asset to display
• A more boxy capsule instead of these long thin ones allows for more columns with more assets per page
• Don't show empty elements that were not filled out. This is especially the case for the detail view, if there is no screenshot/image/video added, don't show the empty image/video UI.

An asset library is chaotic by nature, everyone is throwing in their stuff, so the more easily digestible we make the layout of it, the easier it becomes for people to find the things they need.

[patwork]

For the love of Godot, please finish new Asset Library Store first. 😢 If the problem is due to difficulties with the Foundation accepting money for asset sales, publish a shop first in which all items have a price of $0 and are added to the user's account as soon as the user cart is accepted. In this way, you will start to collect important data on interest in assets right away and the proper payment module can be added later.

@TackerTacker: This is an example from a shop from LittleMouseDev, compare how the description looks like downloaded via the API from Godot versus the README from Github.

https://godotassetlibrary.com/asset/nzBRWo/edit-resources-as-table

BTW this is open source https://github.com/LittleMouseGames/GodotAssetLibrary

[reduz]

@patwork This is being worked on now, but It takes time.

[slipster216]

I don't see how "endorsed" can work. Despite whatever guarantee's are made by the developer, things will get abandoned unless they are part of the engine and thus required to be maintained. This is especially true when people aren't paid for the job. I've seen product lines making 5->6 figures get abandoned on the Unity asset store because the amount of support required is just not worth maintaining the products, so having some badge and promises made when getting it isn't going to solve that.

I firmly believe the best thing an engine can do is build a base for things to work around. For instance, I wrote a shader abstratcion for unity's SRP pipelines so you can write hand written shaders and have them work in all 3 renderers - as a thrid party asset, this sucks and is risky - but if Unity ever creates thier own it will solve a ton of issues in the engine and allow shader creation to flurish again like they did when surface shaders were a thing. Right now, very few people are able to create complex shaders for the asset store.

Next, terrain, an area I work in a lot- without an in-built system, it's impossible to build an eco-system around it. Even with some kind of endorsed flag, it's just too risky to build a business hoping that some 3rd party doesn't disapear, abandon their stuff, etc. And since there will likely be a fragmented solution, with each only supporting certain features, any system you write would have to target multiple systems. This is the SRP nightmare all over again, just for each feature in this category, and with a large change of abandonment and incompleteness. Almost all games using terrain use some form of height map terrain, and while their are different ways to generate geometry, render trees, etc, this is far more standardized than, say, lighting, or rendering is.

Having 3rd party libraries to do things can be great- but only where you want fragmentation of solutions. For instance, the tools for terrain are a perfect area - some people want a graph based system, runtime creation, or a stamp based system - but they all write to the same underlying data, and in most cases can work together well because of that. Unity users can use different shading, creation, or even rendering solutions - even ones which allow voxel based caves to work with heightmap based terrains. But any solution which doesn't target the standard Unity terrain basically dies in the store, simply because one person or team cannot compete with the entire ecosystem surounding the standard solutions.

So, if you want it to grow and flurish, I believe Godot needs to plant the seeds. Otherwise, as a 3rd party solution, it has very limited growth potential.

[cgvirus]

IMHO, endorsed option will become a political discussion as program usability and support varies user to user. Godot Foundation should focus on core. Not in some random plugin. Also opensource unpaid personal projects are not guaranteed to be maintained. An official and a community category is a safe place for everyone. No need to create haterade and drama. It consumes energy and time for everyone.

[Zireael07]

I fail to see how you're getting 'always maintained' from 'endorsed'?

[reduz]

@slipster216 For terrain it is possible there will be an official add-on.

@Zireael07 Not maintained, no longer endorsed.

[kennethrapp]

I think a big problem of the assetlib is layout. This is how much space one asset preview takes up in the list. An asset library is chaotic by nature, everyone is throwing in their stuff, so the more easily digestible we make the layout of it, the easier it becomes for people to find the things they need.

Better integration with Github's API might be a solution here. Instead of publishing data to the asset lib itself, just use whatever is in the repo.

[kennethrapp]

Whatever else happens, I think it needs to be possible to add arbitrary repositories to a local list. Gatekeepers and maintainers are OK but as language support and use cases diverge, people may want to keep track of, say, a random Python library or asset collection or whatever.

There could also be community and third party curators you could subscribe to, like Steam currently has.

[tangx246]

I'm not sure if this is on topic, but would endorsed add-ons need to have an enforced language (e.g. GDScript / C++)? The choice of language for the add-on may affect what platforms the game can be built for, and may be an important factor for users deciding what add-on to pull into their projects

[eon-s]

Looks good except for one thing, the part where it says "go to the asset library", that's too late for discoverability, it needs to be addressed in the project manager.

During project creation, the manager could show options asking what kind of project wants to be created (asking genre, style) which can be used to set project defaults but also can suggest add-ons from the asset library to install automatically during the creation. That's the best point for discoverability.

Another small but useful feature, there's a (underutilized) notification system in the editor now, it can be used to tell users about new plugins that match the ones of their project (and updates of their current ones), if it's opt-in it could be helpful for many users.

[reduz]

@eon-s I think that is a different proposal altogether (good one though) that should be opened separately. Where you can make your own project templates selecting add-ons from the asset lib.

[reduz]

@jmarceno Endorsement basically means: "Look, people uses this, people likes this, its maintained and up to date and the person who maintains it is trustworhy".

First comes the usage and interest from users, then comes the endorsement.

[TheDuriel]

Pretty happy with enhancements to the Asset Library for this.

I would prefer Editor integration to be more subtle though. I don't believe that an interface in which you are continuously reminded to go look for addons is desirable. Not only could it send the wrong message, but it also clutters the interface itself with options that don't immediately do what the user wants. (You want to add a Node, and your webbrowser / asset library opens.)

For example in the add node dialogue, it may be better for a search query to provide information about official and endorsed plugins tagged for a related thing. For example a user searching for a "heightmap" node, could be shown different terrain addons. But when nothing is being searched for, then nothing is shown. (This isn't an amazing idea, but an example of smoother integration: Offer the user options when they are explicitly looking for them. Keep them in the asset library when not.)

[SirLich]

Blender, anyone?

I've read through this entire thread, and as far as I can tell, nobody has mentioned blender yet. Blender seems like it would be a perfect model for Godots asset library.

Overview

For starters, they have the 'category' system described:

Second of all, they have three (two, really) categories:

Each entry is annotated like so:

Official vs Community

Blender's add-ons are split into two groups depending on who writes/supports them: Official: Add-ons that are written by Blender developers. Community: Add-ons that are written by people in the Blender community.

Both types of add-ons are maintained within Blender Foundation owned repos, and they're both included inside of the documentation of blender.

For TRUE third part add-ons, you need to go to places like Gumroad. This de-emphasis of community created content is a double edged sword: Nearly anything in the Blender add-ons section is worth downloading, which cannot be said for Godots asset library. At the same time, this limits discoverability for people making true third part content.

[KoBeWi]

@TackerTacker This reminds me of my old proposal: #3638 The problem with asset lib is that it only supports plain text. For my assets I just write the bare minimum and tell people to visit the repo for more details. In the README I put all possible info and divide it in sections enhanced with GIFs and stuff.

I do agree that assets should come with some description that isn't non-existent, but given how barebones is the AssetLib's editor, we also can't expect too much. I wonder if it would be possible to display README in the description or something (although it's probably not always desirable).

[TheDuriel]

Another example of a community maintained plugin library is https://obsidian.md/plugins

Here, you get a summary of the plugin with direct links to the repository.

The plugin browser within the software itself, meanwhile does display the plugins readme.md.

[rick551a]

Instead of 'endorsement' maybe an overall 'Seal of Quality' like Ninty has?

For example like this:

Bob's Terrian addon $12.99 (10% Goes to Godot Foundation) -GOLD seal of quality 22 reviews 80% 5 star (Personal endorsement by 3 Godot foundation members) -Used in titles like 'Kindness Squad', 'Vinyl beasts' -No telemetry, unlimited license for Desktop,Mobile exports -Compatible with 4.1x onwards , requires dedicated 3D Graphics card

MobiiiAddd Ads addon FREE -Bronze seal of quality 111 reviews 90% 2 star
-As used in 'Clash the Clonez' -Contains telemetry, EULA, per seat license for Mobile exports -Compatible with 4.2x onwards

[reduz]

@TheDuriel

For example in the add node dialogue, it may be better for a search query to provide information about official and endorsed plugins tagged for a related thing. For example a user searching for a "heightmap" node, could be shown different terrain addons. But when nothing is being searched for, then nothing is shown.

Due to privacy reasons, the Godot editor will not do any connection without the user consent, so we can't automatically search on the asset library when typing. Additionally it would be pretty weird to just show nodes out of nowhere.

[cassandrus]

So, when I proposed to place plugins in a create new node dialog for better discoverability, everyone said it's an awful idea. Now Juan proposes absolutely the same and it's ok.