Status update - 16 September, 2014

Here’s the lowdown on what’s happening.

Planning the API

To plan out the API, we are currently using two resources:

  1. A list of Java packages that should end up in Sponge
  2. Our issue tracker

Our procedure is as follows:

  1. Find something on the package list that needs development.
  2. Create a swimlane for the agile board for our first release.
  3. Add some “cards” for the most immediate tasks. For example, for the command API, there needs to be first be some command interfaces.
  4. Implement the code. (For example, see this commit for the command API).
  5. Move the cards over to the relevant column (i.e. “In review”).
  6. 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 BlockFace enum 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

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.


Nice, can’t wait for some more events :smiley: keep up the good work!

Also about Microsoft, it shouldn’t change much, don’t think they bought MC for the pc crowd. (MS has been ignoring PC gaming for years.)

To get ECS working with the minecraft server, how much effort would it take?

ECS seems easier to work with, code should be clean. That said, I’m not a developer. Great work, and thanks!

Looking forward to the completion of this project. Thanks for update @sk89q.

Multiple inheritence is nasty. Maybe the use of interfaces would work?

Great plan. Looking forward to try out Sponge soon.

Great! I can’t wait to see the first Sponge build released :wink:

1 Like

Reusablity then becomes easy: you can add the “grass eating” component to a creeper object and now creepers can eat grass.

I’ve always wanted to see a creeper that could eat grass…


Thanks for the update - you are all awesome!

I’m glad that Sponge isn’t using an ECS, mostly because it seemed a little silly to use a design pattern that is completely different from the one being manipulated… Although I was excited about the convenience of custom components. :sweat_smile:

So has there been any discussion on a solution for attaching our objects to Blocks, Entities, etc? Built-in persistence like what deltahat (who wrote Bukkit’s Metadata API) suggests would be awesome. :slight_smile:

Minecraft may be switching to a component structure in the future sometime anyway:

(from this [post][1])
[1]:Component System and Minecraft

I’d rather wait longer for a complete API than have an incomplete API where we have to include the API implementation for us to do anything ground breaking (like in Bukkit). The end goal I believe should be that there will never be a need to include an implementation as a dependency in your plugin code.

1 Like

Personally, I want to say thank you so much for the Update. It’s really hard to be able to nothing when I want nothing more than to help. This means a lot to a lot of people and hearing anything makes the loss a little easier, but I understand the road ahead is long and uncertain. Keep working team, we’re pulling for you.

1 Like

I already love this project.
a) it embraces the “community”
b) it communicates
c) it responds
d) it moves forward

Good job guys, I will keep my fingers crossed.


Glad to see that even though an eye of caution is open wide it is not slowing down progress. I personally do not thing that Microsoft’s purchase will cause this community to fail as the success of Minecraft is always created to the greater community that has opened up so many possibilities beyond the original scope. Yes Microsoft has made a few blunders in the past but when you put it into perspective look at the some of the wonderful things that they have accomplished: anyone remember when they first announced the XBOX and everyone told them they were fools getting into something they could never succeed at? Big companies are easy to hate, massive companies with huge market shares and a vast product offering are even easier to hate. This deal is (by Mojang’s own admission) been in the works for a good while now, with this level of continued interest there is little way they could not be aware of what the community of developers, modders, server owners/managers, etc have done to make Minecraft the global phenomenon that it is today. Of course none of us can say what they have for plans with this purchase, but they are not going to want to lose such an important piece of the success.

Thank you to all that have made a contribution in the past and to everyone doing their own part to continue this adventure. This is what makes a community so strong and powerful. I have to admit that I look forward each day I arrive home to reviewing the discussions that have taken place and following the work/progress that has been made. Keep up the amazing work and community commitment!

Should’ve used Scala, it supports mixins using Traits
Anyway, good work dev team!

Oh and why is the sprint called “Inspired Wallaroo”?

While I agree and think it would have solved some of the API design problems related to running on Java 6, Java is what people are used to (probably including sk89q and co).

I can’t wait to sign up for API development, this project is looking good.

1 Like

According to Owexz, the new versioning system for Sponge builds is an adjective and an Australian Marsupial.

On that note, allow me to blow my own trumpet: Bardic Extrapolation (Rime of the Ancient Sponge) - #7 by Inscrutable