The number of community extensions is starting to grow! And this is great!
For the next version, the search and the display of tags will be improved (using the same kind of interface as for the āAsset Storeā - and the āResource storeā for the web app):
As more and more people start to get interested in making extensions (thank you!), a Trello board was made (thanks too, great idea!): Trello
Iām still unfortunately a bit of ābottleneckā, as Iām trying to review all extensions. This is to keep a high quality bar:
ensure the extension has a good reason to be there.
ensure the events are as simple as possible.
ensure the best practices are followed (use prefixed scene and global variable names).
ensure the description and names are well chosen, clearly explained. Ensure all sentences are correct, all parameters are shown, everything is following the same convention as existing actions/conditions/expressions.
This is taking a bit of time, so Iām wondering if you have ideas about how to speed up this? Should we set up some kind of ācommunity reviewā of extensions? Maybe a checklist that anyone could follow to ensure that it will pass the ā4ian reviewā?
Let me know if you have ideas. Another one would be to make it easier to publish exensions, but have a list of curated extensions selected and pushed forward in the UI.
Overall, Iād really like to ensure extensions are growing faster without me being a blocking point (and at the same time, ensure extensions are ācuratedā and offer all a great experience to users).
What Iād suggest is to make āreview teamsā. For example, one team could review the javascript in extensions, another the grammar and spelling, another for the design of the API, etc.
Then, we could also have a github actions that looks for common things (prefixing the variable names with ExtensionName__, empty fields, unused parameter).
Passing all extensions through this should already make the extensions pretty clean, and faster to review as there would be less problems.
What I then would propose is having 2 more repos: a āunstableā extensions repository managed by the community: Extensions get merged with almost no review there (we only check if no other extension gets deleted, vandalized, or if the extension is not a troll/fake/malicious extension) for users to share their extensions for easily sharing the extensions with the review teams or with whoever wants to already start to test it.
Then, once an extension is judged stable by the review teams, it can be moved to the second new repository, the ālabā repository. This repository contains extensions that are judged stable to use but still need testing in the real world. GDevelop users could download it and start to use it, and once the extension has been used for some time, you (4ian) could make your own final review before moving it into the ācore/mainā repository.
Extensions in the main/core repository would show up as it does currently. Extensions from the lab repository could show up in the list if a toggle at the top right is activated. And finally, unstable extensions would need to be enabled in the IDE parameters.
All extensions from the lab repo would have a little āexperiment vialā icon next to them, and unstable ones a warning icon to show the users that it is not a stable extension.
I feel if there was more documentation on the wiki for best practices, naming conventions, etc. The quality of extensions will go up and it will be easier for new people to create extensions.
For example, this is the main page for explaining how to make extensions. However, it doesnāt talk about prefixing variables, or that functions should be named using PascalCase instead of camelCase.
So I think that if this were to happen extensions would be submitted with a higher quality and take less time to review. Since all of the best practises would be made very visible. New extension makers would learn the right practises from the start.
Iāve started a page here: Extension Best Practices [GDevelop wiki]. Iāve made a link in the checklist that people must follow before submitting an extension.
Feel free to suggest new best practices or clarifications
I thought that instructions were camelCase? If they arenāt, we should update lifetime functions to adopt those conventions.
All extensions internally are using PascalCase for expressions/actions/conditions. Lifetime functions are not because they were directly mapped to functions in the generated behavior class.
