Okay just to be clear I am NOT asking their differences/similarities…
Disclaimer: Everything in the post reflexes my personal thought. Although I wrote ~100 plugins in the past two years, I declare myself “far from being a pro in java or programming”.
After I took a little peek into the Sponge API, the first impression that brought to me was “really different from Bukkit’s”. More specifically, this or maybe this could be two simple examples. And yes I realized that Sponge grammar looks more like Forge than Bukkit.
I am wondering whether this could be friendly to Bukkit plugin developers. Around two years ago, while I was trying to develop my first plugin in Bukkit. I found it was very easy to use and start with, since I do not have to know a lot of the API when I start. Moreover I get more familiar with Bukkit as I write more plugins.
And question: why Sponge can’t just simply make it as similar as Bukkit, so that no developers will waste time to get familiar with a brand-new API?
Ps: If you wanna say “This is Sponge, not Bukkit.” Here is my response. First, using similar method/format compared to Bukkit will be fine (why not). Second, although Sponge becomes a new Minecraft server API it does not mean it should set up a new concept in a plugin developing community just because Sponge API developers wish for it. To maximize efficiency and minimize developers from getting familiar with Sponge, replicating Bukkit’s format would be a better choice.
I won’t respond with a “This is Sponge, not Bukkit” and instead ask why we must “just be Bukkit”.
One of Sponge’s biggest goals is to re-think what a Minecraft API is all about. I like to think that with what API we have right now (and we have quite a bit) has remained rather similar to Bukkit (with noticeable improvements). The goal was to never just “re-create Bukkit” (otherwise we would have just implemented Bukkit in Forge).
While I do feel for you and others with extensive Bukkit experience, I will not let our API be held to the many restrictions Bukkit’s did. SpongeAPI is a great opportunity for us to go back and re-think/fix many aspects of Bukkit that were flawed (but remain similar at the same time).
While I agree the bukkit API is nice and well made, what @Zidane said is spot on. Bukkit has had it’s fair share of restrictions and problems in the past; many of which I have had the displeasure of noticing (one prominent thing was the scoreboard API not working at all for me for some reason) I feel like it’s best for us to have a fresh start with a completely new API, that won’t have the same issues as bukkit did. Besides for many people being similar to forge can be a huge plus if they want to eventually get into modding. Although if you really still wanna write bukkit plugins, you could still do that with spigot and you can use them on sponge with pore when that comes out later.
One example is how to handle the commands like this
Suppose in Bukkit we write:
public void myEvent(PlayerDeathEvent event){
Bukkit.BroadcastMessage(event.getEntity().getName() + " is bad at Minecraft!");
event.getEntity().sendMessage(“HAHAHA”);
}
Will this be a good idea that how it is handled in Sponge?
public void myEvent(PlayerDeathEvent event){
Sponge.BroadcastMessage(event.getPlayer().getName() + " is bad at Minecraft!");
event.getEntity().sendMessage(“HAHAHA”);
}
(Ps: I am glad to see we can do getPlayer() in PlayerDeathEvent in Sponge)
While bukkit and sponge both will differ based on API’s there are certain methods like getPlayer() for instance. As you can see it was kept the same because it made the most sense to call it that, the only major differences with these methods is they work differently within the API (as you pointed out). In the end the resulting API should be much more flexible and should make much more sense compared to bukkit once you play with it a bit. (No more plugin.yml’s yay! )
PS:
public void myEvent(PlayerDeathEvent event){
Sponge.BroadcastMessage(event.getPlayer().getName() + " is bad at Minecraft!");
event.**getPlayer()**.sendMessage("HAHAHA");
}
I disagree, it hurts the ability to add/remove commands dynamically without hack-esque approaches through non-API code. I’d rather just do it purely programmatically since you have to do so anyway, might as well do it all that way instead of wasting my time with a limiting embedded resource.
Learning SpongeAPI should be easy WHEN documentation is out. Currently it may not so easy for new programmers, as only doc is Javadoc. But the tutorial will come when someone haves time to write it.
You should learn java instead off “SpongeAPI”. The API is just a bunch of java classes and objects. So learning “SpongeAPI” is basicly learning java. No reason to wait .
learned it similarly
which is why i’m a 9000% nub on every other topic you could throw at me~
getting familiar with a brand-new API shouldn’t be that much of a problem; and there -are- similarities between the two that you might be able to use. the coding documentations will be out soon, and with that to start you off you can start getting familiar with Sponge like you probably have with Bukkit: by making more and more plugins. in the long run, remember the javadocs are your best friend; explore them as much as you can.
other than that, the prime reason is to start anew and attempt a fix at all the things that went wrong in Bukkit. not even completely that, actually; just to start anew in general and envision a new API thats potentially more flexible and less bug-ridden than Bukkit was. there’re a lot of cases where its better to start clean if possible, because you can take all the mistakes from the past attempt and avoid them in the new one.
They still have a long way to go to have a complete API. They only did this in a few months and that is impressive alone. I am personally awaiting the ability to create my own blocks and write my code around them. The possibilities are insane. Once the API is close to completion then the how to docks will show up more followed by how to convert your bukkit to sponge. I rather them to take their time and do it right the first time then be in the same hole as bukkit. Got to have a little faith in these devs.
)
.