Hello everyone !
I wanted to discuss the current state of the extension team, and talk about our recent achievements and things I think are important to talk about.
Recent achievements
-
We now have 92 extensions! We are rapidly approaching the milestone of 100 extensions
!
-
Some of the extensions begin to get really advanced! Check out the Dungeon Generator extension made by @tristanrhodes and @oscuridad666
-
We have successfully converted 70 out of the 92 extensions to the new author format, using the GDevelop profile instead of a text field. The rest will be converted soon as the authors of the extensions register their GDevelop profile. Thanks to @Add00 and @arthuro555 for manually converting all of those extensions!
Current state of the extension team
The extension team is not exactly in its āgolden ageā currently.
-
@VegeTato wants to quit submitting extensions since they disagree with the open-source nature of the extension gallery.
-
Most of the members seem currently busy, resulting in fewer extension submissions and reviews.
That doesnāt mean we are not functional though! While there were fewer new extensions submissions, multiple extensions were updated and the pipeline of extension submission was improved, and we now have automatic checks on new extensions against the best practices
Discussion
I would like to start a discussion on the following points:
Structure of teams
I am just going to quote the last news post here:
To add more structure, I think we ideally would need clear rules to be discussed out carefully to get a good set of rules. Since that did not seem to be working in my past attempts though, I am going to try the RFC methods and post a set of rules and discuss those instead of trying everyone to come up with them together.
Here are a few rules I would suggest:
š£š±š® ššš®šæš®šµšøš¹ š£š®šŖš¶š¼ šš¬š½
-
A GDevelop team has 1 or more leaders and multiple members.
-
A GDevelop team members have to be an actor in the development of the aspect that the team is focused on.
-
A GDevelop team obtains a role on discord and a group + title on the forum assigned to them, so that they may be recognized as the ones in charge of a field of development in GDevelop and mentioned if attention from any/all of their members is needed.
-
A GDevelop team leader has to be a well-known and trusted member of the community.
-
A GDevelop team leader has extra permissions given to them to the resources linked to the resources, and to allow them to grant the discord role/forum group + title to new members.
-
A GDevelop team leader is responsible for selectively giving out permissions, adding new members or removing some from the team, creating and managing subteams if they think it is useful and necessary, and organizing the team (getting multiple members not to work on the same thing, organizing meetings and discussions if necessaryā¦).
-
GDevelop team leaders are given free GDevelop Indie as a thank for their work + can gift 3 months of GDevelop indie to a member of the team once every 2 month (for rewarding for example a new extensions creator for his multiple new extensions submissions).
-
GDevelop teams can only be created by @4ian.
-
One can only be made a team leader by a team leader of the team in question or @4ian.
-
A team leader can be destituted if more than 1/4 of the team is dissatisfied with them, or if they are doing anything very wrong like spreading hate, infecting GDevelop with potentially unwanted programs, harassment, abusing their permissions, etc.
-
All teams get 2 channel on discord: an announcement channel where only team leaders can post to post updates, news, and announcements to the team and/or GDevelop users, and a public discussion channel, where the team or non-team members/normal develop users can talk about the topic the team is about.
-
A team leader that is inactive for 2 weeks without prior notice will be destituted as a safety measure.
In the context of the extension team, the āadvantagesā one would get for being a leader is
- Permission to push to master on GDevelopApp/GDevelop-extensions
- Permission to select new members, and give them an āExtension Teamā role/group/title
- A special āExtension team leaderā role/group/title
Currently, as far as I understand @tristanrhodes is the sole leader of the extension team. If you all agree, I would like to apply for joining the co-leadership of the team since
- I am an experienced GDevelop extension developer my self too now
- I have good git knowledge, allowing me to help manage efficiently the extensions repository
- I am already trying my best to try and organize the GDevelop space, and I hope that getting an āofficialā position for that would make it easier for me to make things easier for everyone
Extensions missing features list
I would like to put up a list of everything that is currently limiting us or could be improved in terms of extensions. Here is what I have so far:
- No extension cross-dependencies
- Private functions renaming (also another way of showing they are private would be nice since on small screen space/long function names they are overflowing out of view)
- No accepting variables as argument
- No using private functions from a private function
- No colorful icons
- No notification of availability of updates for extensions
- No changelog in extensions
If you have anything more to add, please do I will try to implement those, and we can notify the core development team about that list so that they may look into it as well.
Extensions for streamlinening processes across extensions
I want to ask a few questions about patterns in extensions. First of all, extensions abstract tasks for writing games, but should we try to use them to abstract tasks infro writing extensions too?
For example, the P2P, MQTT, and WebSocket extensions all have an āevents queueā, which is internally an array with all incoming events, and it can be used either by a condition āevent triggeredā (checks if the array length is not 0), āmark current event as triggeredā (removes element at index 0), āget event dataā (returns the value at index 0), and it calls mark current event as triggered in onScenePostEvents.
Redoing this for every extension is like reinventing the wheel every time. Using a common extension for those queues would have multiple advantages:
- The development of the extensions using such an events queue is simplified as prior work is reused
- If a problem is spotted with the events queue, or a new feature needs to be added, the update is automatically made available to all extensions that use it, without needing to change the extensions individually
- It gives a consistent way events queues work (for example, the different events queues in the different extensions may have some differences, like one could have the current event the last element in the array, the other the first element)
- It gives the user a consistent way to use events queues, so that the experience is always the same independently of the extension, allowing to carry knowledge over
There is one huge disadvantage though, it is that an extension would not be self contained anymore. If one wants to use P2P for example, the donāt have to ājust learn P2Pā but also events queues. Of course, in practice, it takes as much learning as without splitting the functionality, but it gives off the impression of being more complicated.
This example is about events queues but it can apply to other domains too. For example, one could make a ābinaryā extension that stores binary data efficiently using javascript, that the user would not use directly but for example the firebase extension could download a binary image from firebase storage, store it into the binary extension and return an ID for the image to the user that they can give the sprite extension, which could exchange it with the data via the binary extension to set a sprite image to that downloaded image binary data.
What do you think of it? Should extensions rather be always self-contained or modularized like that?
Conclusion
That is all I wanted to share If you want to add anything or discuss all of this, do not hesitate to do so