Bukkit

@deleted_6833624

I said before I hate to give ETA's, so Ill just sum up what's been happenin'

I'm at the point at which I can pretty much start writing proper gametypes for it, which I am doing (starting with CTF). But since these are the first gametypes, they let me know all of the problems in the plugin that developers would face, or things that are just kind of messy/difficult to deal with from an outside programming perspective. So its more painful then normal, as it involves quite a bit of going back into the main code and changing things round.

Probably the main thing that is different from the early versions of this plugin is the Lobby system. It basically emulates the kind of lobby you see in a typical FPS game.

Basically, you can create a game room whenever you wish and invite players to join. You as a host can set the gametype, the field you want to play on, and all the settings you need (things like number of teams, rounds, time limit, weapon loadout, weapon respawns, player respawns for default options, and then whatever options the gametype has as well). When you change your field, you and your players are all teleported to the field (providing it isn't occupied by another room of course. (You can also choose to forgo this option, and instead force players to physcially travel to the field to join). When you are in a game room with a field selected, you can't leave the field unless you quit the game room (also optional). So you think of typical FPS lobbies as a chat room you wait in, the Battlefields lobbies are the same - just that you are milling around the field before the match instead of in a GUI. This system lets you party up with players way before a match (and do whatever you want) until you are ready to play a game (at which you just choose a field and bam, you are there waiting to hit start)

My biggest annoyance with creating things like the lobbies is the inability of Minecraft's font to align properly, which may seem amusing but it is reallly annoying. Ah, I can't wait to finish the main plugin so I can work on adding spout GUI capability.

To make a gametype the developer only needs one class. This class doubles as the listener and the game information storage. Meaning that all listener calls are done here, and all the information the game needs to keep track of and reference is there.

I wrote the battlefields event system to be exactly the same as the Bukkit event system (new one, of course). It's basically just an extension of it. Battlefields has a bunch of it's own 'special' game mechanic events (things like game-start, round-start, join game, team change, region entry/exit, blah blah blah), some redone Bukkit events (things like PVP damage/death which doesnt need all the work EntityDamageByEntity does), and the ability to capture all of Bukkit's normal events as well. The unique thing about the Battlefields event system though is that all of the events are routed ONLY to the game which the event deals with. For example, all PlayerEvents will only trigger on the games the player is playing in. So every field playing a game is kind of like it's own little universe.

Lets see... Hmm. Oh, and the map system is all working A+. Every field you create is saved in it's own folder (including all the data for the field regions/spawnpoints/special features/physical minecraft map. So if you want to share a map with people, all you need to do it zip that folder up. To "install" a map is super easy. You just drop the map folder into the battlefields map folder, go in game and /field import <name>. It will copy the entire physical map into your world at your location with all the spawnpoints, features and everything, and you are ready to go! (Unless you want to edit it : P) Battlefields is going to 'ship' with a handful of maps I've made. Including a special one, one of my favorite FPS maps you might recognize (you'll see it in the first demo vid I put up : D)

Thanks for considering donating! Um, apparently the donation button doesn't show up on projects without an upload, I guess. I put a link at the bottom instead.

Update

The field editing system is pretty much finalized. The basic system is that a field has a list of objects (things like locations, blocks, regions...) with special ID's, and an associated team (including default, which is no team). Every one of these items has a set of associations, which are like aliases. Gametypes, when loaded, will search through the list of objects for what it needs to work correctly, searching by alias. For example, take CTF, which needs a "flag" block for each team. The field creator will add a 'block' object to each team (any name ID they want). Then for each of these blocks, they will add the alias: ctf_flag (or whatever the gametype defines the name of a flag block to be). When you try to load the CTF gametype on the field, the gametype will take a look through the field's objects and make sure there is a block with ctf_flag alias for each team... Then store these for messing with during the match. If if can't find a particular needed object, then it will throw some errors and not be playable on that field.

The editing of these items is done through an editor menu, which provides a minimum of typing to operate and relies on key-based tools for most of the work. The editor also provides a wide range of features that let you work with multiple objects at a time, do filter-based searches for objects, replace objects, etc. There of course is a learning curve, but it is quite shallow. Most of the complex features of the editor are not needed usually, but are there to be helpful if you want them.

This alias system allows objects on fields to be uniquely defined for a wide range of gametypes, or to be multi-purpose and shared between gametypes. For example, you can have one region on your field that is used for different things for three different gametypes.

@jadeddragoon

Wow, this is what I am talking about. I love getting suggestions like these.

Minecraft Gamemodes

Yes, this will be done.

Permissions

I think the way this is going to be implemented is to have a list of commands in the Battlefields main config file that are disallowed on Battlefields during matches. Battlefields will just catch when these commands are used, and if they are used while in an active game, they will be cancelled. So if you have a troublesome '/tp' command, when you use it in a game you will be reprimanded. "NO CHEATING, fool!"

Inventory Handling

Also yes. Gametypes will be able to define a concrete list of allowed/disallowed weapons/items that all matches must adhere to, and the host player on the field will be able to edit the basic starting loadout (following this 'restriction' list) on a per-game basis. Going even further, if the field is set up with item spawn points, then the host can also set the types of weapons that will occasionally spawn on the field during the game. Of course, in all situations, the abilities of the host will have to follow the restrictions placed on them by the gametype, if any.

Warfare

I've played that before! It will be interesting to see something like that played in Minecraft XD. I'll have to keep thinking about it but I am pretty sure it is perfectly doable with the way things are going at the moment. The basic plugin core is fairly generic. It would just be more intensive to code then most.

My biggest annoyance with this plugin is the lack of any decent HUD manipulation ability in normal Minecraft. Spout of course fixes this, and I will be supporting spout to this end, but I won't make it a requirement. I mention this because of the HUD map that is so critical to the type of games you describe - up to date info on exactly how the game is playing out, preferably without clogging your chat bar with endless notices.

Also, Battlefields has a system to load/unload block structures (think world-edit schematics) which is mainly used for saving/loading the physical state of a map (either for copying into other worlds or fixing damage to the field) - but its made to be used for anything. So it is possible for Battlefields gametypes to contain these schematic files in their .jars and to dynamically place them in the course of the game. Think of them as model files, when used this way. They are all copied by reference - meaning that in addition to storing the block data, they also store a positional reference from which to copy the blocks. So on the developer's end, all they have to do is load the schematic with one line of code, and paste it to any location on the field with another. They can also use Battlefields to restore a given region of the field to it's original state if they want to undo things. At the end of a game, Battlefields will always clean up the map to restore any damage/delete any 'models'.

Again, thanks for taking the time to make suggestions: they A. Show that people have interest in what I am doing, B. Help me get my ideas together and C. make things awesome!

@bobbysmithyy

Almost... : /

@TheNoobWar

In a way, yes.

My other plugin Gateways has kind of been a testbed for a plugin backend which I decided to integrate into Battlefields. I just completed that backend, which is going to make finishing Battlefields 100x easier for me - as all the text-GUI and utility code is completely written, and I managed to make it very versatile. This was the main thing holding me back - I have been through three iterations of this "backend" before I managed to come up with something that satisfies all of the things I needed.

So, expect things to liven up here as Gateways gets finalized and I get the backend integrated into this plugin.

@johnlier

Yeah, I am still writing up the pages, they are all unfinished. I just put it up today, give me another day to get things settled : )