Bukkit Arena - Bukkit's most flexible(and powerful) arena plugin!

Well, not a lot to say here, check out the bukkitdev project. Feel free to suggest ideas here, or on the comments section.

http://dev.bukkit.org/server-mods/bukkit-arena/pages/main/

Nice idea. We're currently using our own Arena/Game API on SpleefLeague. Gonna follow the development of this.

I'm glad you like it. I just got back from a week long trip to Moab Utah(hiking, biking, and rafting), but I hope the scheduled released date of mid-august stays.

Update!
As of 8/10/2012, a lot of the API has been finished. Based on the github commit history the size of the project is roughly 4,500 lines of code. For those interested, the repository is located here.
Here's what I have done:

• Loading custom modules to define arena types.
• Wave API.
• Class API.
• Point API.
• Team API.
• Objective API. Things like flags and regions can be done with this.
• Easy spawning for teams, waves, and players.
• Custom Events for everything done so far.
• Verbose Logger.
• Lobby(50%)
• Player and mob wrappers.
• Odds and ends.

Here's the large sections that still have to be done:

• Commands. Commands are probably one of the largest parts of this plugin, so this could take awhile.
• Listeners. Could take awhile, not as long as commands though.
• Testing and bugfixing. This WILL take awhile.

EDIT: Also thought I should mention that I'm currently looking for someone who can help create a website for this plugin. I own the domain bukkitarena.com, and receive free hosting from NodeCraft. I currently have Drupal installed, but I'm more than willing to change things if necessary.

Update!
So, as of 8/20/2012, I'm back in school, but more of the project has been finished. As for why things are taking a long time, I'll explain my coding style in one of the sections below. But, I am still making progress, and so I felt like I should start talking about how some of the features are going to work as well. For those curious the current size of the project is roughly 6,000 lines of code.

Now, for the various sections.
Newly Planned Features:

• Highscores can optionally be stored in a mysql database. I'll try and design an easy system for Arena Types to hook into so that they can quickly and efficiently store data from their different sections.
• (Code related)One of the big drawbacks of the current Configuration system of Bukkit is that deserialization and serialization is really poor, as all it gives you is a map. I'm going to be including a slightly modified version of this system, that, instead of using a map, offers both a ConfigurationSection and a Class for them to work with. ConfigurationSections are a lot easier to work with, and will allow you to name objects based upon their path, something that isn't easily/currently possible with Bukkit's deserialization and serialization system. I'll probably make a PR to Bukkit after I finish these changes, and push for them to use this system instead.

Why I Take so Long to Code:
I kind of felt like explaining my coding style, as I find it to be a bit unique, and probably inefficient, but I think in the long term it creates a far better project.

1. Figure out a problem or deficiency in the code, and write something to solve it.
2. Work on something else for awhile.
3. Look back at previous code and judge it, then end up re-writing it due to inefficiencies and ugliness.
4. See #3.
5. Repeat.

Although this is obviously inefficient, it generally ends up with a nice product, and I end up less likely to re-write the entire project.

Highlighted Feature - Lobbies:
In most minecraft Arena games, lobbies look a little like this:

1. Join a lobby.
2. (Optional) Select a class.
3. Ready up.
4. Start.

But yet, in most actual games with lobbies, it looks more like this:

1. Join a lobby.
2. Vote for Arena and Arena Type, readying up in the process.
3. Start.
4. (Optional) Select a class in-game.

As that's what is in actual games, it's the target of what I'm trying to do. So far I've set up a weird system of checking tasks and timers, which will see if the lobby has reached an appropriate number of votes, first for the Arena, and then for the Arena Type. Of course, if servers don't want to do this, all they have to do is only assign a single Arena to each Lobby, and only a single Arena Type to each Arena. If there's only a singly option to vote for, the Lobby will skip the voting process, meaning you get the boring, classical lobby system.

If you've got any suggestions, feel free to message me, or just post them here.

In Conclusion
Yeah, my release date of mid-August was unrealistic, I'm never good at release dates. There's a saying I've heard, that in order to actually find out how long it's going to take you to code something, you first spend a lot of time calculating every thing you'll have to do, and how long it'll take you. Then you multiply it by 3, and that's how long it'll really take you.
So, I'm going to keep working on this, but the progress is going to be slower during the week, thanks to school. On weekends I'll probably get a lot more done, and thanks to the per-student laptops at my school, I'll probably be able to work on it a bit at school. My teachers will probably flip for a student doing something productive on their laptop.

Cant wait for this to be finsihed, when will it?

@realiez As soon as I'm able to. I've been rewriting the configuration library from the ground up as https://github.com/evilmidget38/EvilConfiguration .

Any EST?

@realiez Not currently. I'm doing a lot with it.