Here’s the lowdown on what’s happening.
Planning the API
To plan out the API, we are currently using two resources:
Our procedure is as follows:
- Find something on the package list that needs development.
- Create a swimlane for the agile board for our first release.
- Add some “cards” for the most immediate tasks. For example, for the command API, there needs to be first be some command interfaces.
- Implement the code. (For example, see this commit for the command API).
- Move the cards over to the relevant column (i.e. “In review”).
- Go back to step 3 and repeat until that portion of the API is complete.
(Note: We are currently not doing sprints, for those familiar with agile development.)
Where core developers and the community come in
Making a good API requires some of the following goals:
- The API should be somewhat opinionated.
- The API should be consistent.
- The API should consider how it may be used in the future.
- The API should maximize reusability.
Community-designed APIs can suffer from inconsistency and the quality of each part of the API may vary a lot between different authors.
For that reason, we are currently focusing on designing the core API by a group of “core developers” and asking for assistance for specific parts of the API. We still absolutely welcome suggestions and criticisms of our work as time goes on, as you all know best the struggles you have had with Bukkit and other APIs in the past. Generally, you can comment on our changes on our GitHub repository.
While this seems unfortunate, we believe that trying to involve large numbers of people before code is even written is going to significantly delay the process. Instead, if we simply post code and await comments, things should move along more quickly.
Despite that, it is possible to become a core developer. I will get into how you can become a core developer in a second.
If I’m not a core developer, can I still submit pull requests?
Yes, but we need to lay down some rules.
If you’re going to submit a pull request, please make sure that:
- It’s not an interface that is simply copied form Bukkit. It is quicker for us to rewrite the interface ourselves rather than handle such a pull request.
- It’s not a really small class or enum. It’s quicker for us, for example, to write a
BlockFaceenum ourselves than having to process a PR submitting the same thing.
If you’re wondering how exactly you could help out, we’ll get to that in a second.
How do I become a core developer?
Our current problem is that we’ve so far have gotten a lot of offers for help, but we asked for too little information for us to be able to be choosey.
In the following days, we plan to put out a form where people can “sign up” to write a part of the API. The form will ask what part of the API the developer would like to work on, as well as a field for the developer to express some goals for such an API.
What about everyone that already submitted the first form?
Currently, we admit that that was a bad idea. The number of entries currently numbers in the hundreds and going through the list is going to take some of our time. Most likely, we plan to email everyone who has submitted their details with information on how to sign up for the core developer position (as mentioned in the previous section).
I don’t want to be a core developer. Can I still help?
After we’ve done some basic API work, we are putting out requests for help on our issue tracker using the “looking for dev” tag.
See what issues have the “looking for dev” tag
If you would like to tackle one of those issues, we recommend making a comment on the issue so that other people know that you are working on it. Please also express some of your general ideas as to how it will be implemented so the team and others can discuss them.
I heard something about a “component system”
There has been momentum to implement a “component system” (ECS) for handling entities (as well as items and so on) in Sponge. Right now, both Bukkit and Minecraft heavily use inheritance instead. For example, all living creatures inherit some “living entity” class, which then inherit from an “entity” class.
You get a tree:
- Entity
- Vehicle
- Minecart
- LivingEntity
- Cow
- Sheep
- Vehicle
The problem with inheritance, however, especially in a language like Java without multiple inheritance or mixins, is that’s really hard to reuse code. Let’s say you put some jumping code in Skeleton – how do you reuse that code in Sheep? Copying is a no no, and putting that jumping code in Entity would mean that all entities may have it.
An entity component system solves that problem by making use of composition. Rather than using inheritance, all entities are of one type that contains a list of components per entity. For example, a sheep object would possibly contain the following components:
- Grass eating
- Shearable
- Healable
- etc.
But the sheep object is still just a generic “entity.” There is no sheep entity. There is no living entity.
Reusablity then becomes easy: you can add the “grass eating” component to a creeper object and now creepers can eat grass.
ECS is frequently adopted in game development these days, especially in massive multiplayer online games.
But let’s be realistic
While some people would like an ECS system, it lends to some issues:
- Minecraft currently is not written using a component system. Sponge would have to somehow modify Minecraft to use our ECS, and even then, we would likely be unable to actually allow you to adjust all components (for example, you may not be able to remove the grass eating component from sheep).
- Java, in this case, presents a problem. An ECS requires a lot of objects, especially if you want the API and code to look elegant. Objects in Java use a non-trivial amount of memory, so your most obvious way to implement an ECS would use a lot of memory. We don’t want that.
- Many people are simply unfamiliar with component systems. We don’t want to confuse everyone.
For that reason, we will continue implementing Sponge using inheritance, as how developers are used to in Bukkit. However, we will allow some of the Sponge developers to continue working on ECS for the possible future where we may have both the inheritance-based code and an ECS system co-existing in Sponge.
So, Microsoft and Mojang. What does this change?
It’s too early to say at this point. We will continue with caution and update you all on changes to the situation.
Something something about too many chefs?
We apologize that we haven’t been putting out announcements. Unfortunately, it’s been a busy few weeks for many of us, but we’re still going full steam ahead.
To our knowledge, some people were “not a fan” of the ECS and have expressed their feelings that this is the result of having too many developers having input. We disagree. ECS is merely one option that we have considered, among others, on the path forward.
Date of first release?
Truthfully, we don’t know yet. Once we are able to go through all the portions of the API that should be added (from the previously mentioned spreadsheet), we’ll have a good clue of when we may be able to make our first release.
The first release won’t be able to do everything. It won’t be able to make you toast. However, we plan to have it in a usable state.
We rather not take more than one month to get the first release out. The sooner, the better.
keep up the good work!
