[Battlefields] Looking for input from plugin developers!

Discussion in 'Plugin Development' started by 2n3904, Oct 24, 2011.

Thread Status:
Not open for further replies.
  1. Offline

    2n3904

    I've been working on a minecraft arena-type plugin called Battlefields which lets you play custom gametypes in predefined regions on your server. This plugin is being made to be extremely extensible: Meaning that you, plugin devs, can develop your own Gametype "plugins" that install directly to this plugin in a similar manner to how you load plugins into Bukkit. These gametypes make use of the Battlefields framework in order to unify all mini-game type plugins into a universal format, where admins can develop multi-purpose battlefields and add/remove gametypes from them as they please.

    The WIP thread for this plugin is right here.

    Now, the reason for this second thread is that I am hoping to catch the attention of a broader audience - because I need suggestions! Especially from you, plugin devs. I am trying to decide on all the possible features that the Battlefields API includes. I want you to be able to create basically whatever you wanted with this plugin.

    Here's a breakdown of the format:

    Gametypes are just a .jar placed in the /plugins/Battlefields/gametypes folder. They install automatically on restart/reload. These gametypes consist of four files at their core:
    • gametype.yml
      • This is basically just like your typical plugin.yml. It contains the gametypeplugin.class path, the name of the plugin, a list of all the adjustable per-field settings for the plugin (i.e. score condition for win, enable so-and-so), a list of the teams you can play on (i.e. allow only non-team, or 2-4 teams), and a list of all the different statistics that the plugin records (i.e. flag captures and flag saves for CTF).
    • GametypePlugin.class (extends abstract)
      • This is the main loading class - meaning this is the class that initializes when the gametype is loaded into Battlefields. It handles the retrieval of the info in gamtype.yml, the gametype's config.yml, and initialization of new gametype.class. The only thing you really change here is whatever you want in onEnable().
    • Gametype.class (extends abstract)
      • This is the linkage class that basically serves as the instantiation of the gametype for a particular field. It links the field to the gametypelistener, and holds some general purpose methods that Battlefields calls (such as checking for a victory condition, getting the winner, etc.
    • GametypeListener.class (extends class)
      • This is the heart of the gametype plugin. It's basically the same thing as your typical Bukkit listener class. However, the events are much different. Battlefields basically provides filtering for the standard listeners, and the results dump into here. This means that when you write the listener for your gametype, you don't bother with anything relating to checking if the event applies to a battlefield, or if there is a gametype, or whatever. You only get listener calls for the field the gametype is on, and they are all formatted for extremely specific situations already. For example, a lot of people might know that onEntityDamage can get quite convoluted. The gametype listener has unique calls for basically every possible situation that might come from onEntityDamage: PvP, PvM, MvP, Enviroment damage.
    You: So, what do you want from us?

    What I am looking for is basically the community to share their ideas for gametypes that they want to create/want to see created. I want to be able support as many of your ideas as possible! And if plugin devs have any specific suggestions as far as the framework of the API, spill it!
     
  2. Offline

    Agil

    Since you have a new thread I'll just post the idea I just had here =)

    In Halo Combat Evolved, you had a gametype called Race. Basically, as like King of the Hill (Capture the Area), you have different pre-defined areas (checkpoints) that you have to run through in a specific order. The amount of checkpoints will remain the same during a match aswell as the order of all checkpoints.

    Imagine you have Point A, B, C and D predefined. People spawn throughout the arena and have to run through A, then B, then C, then D. Any other order will not be counted as progress. If someone is killed that already checked in at A and B, his/her progress will be reset and he/she will be spawned back randomly somewhere in the map. Multiple people can be checked into a checkpoint, its not like you really have to "capture" the area for yourself to keep.

    This gametype can exploit the FFA spawns, if defined, and (maybe?) calculate which spawns should be deactivated because they are too close to a checkpoint.

    This is also possible with two, three or four teams, though it starts to get more intresting and fast-paced once there are four teams I imagine, so making the Run gametype FFA would be the best shot.


    Also, and I recall I mentioned it before, it might be an idea to have something redstone (either a torch or a wire) be activated/deactivated by specific triggers. This might be possible with a sign with ln1. [Battlefield] ln2. [Redstone] ln3. [Line1] on it? After that alot of other plugins can be used such as Controllerblock and Falsebook/Craftbook or items such as pistons to make the battlefield more dynamic. That would be a great addition to have in the API, being able to set multiple triggers for multiple signs (line1, line2, line3) when making a Gametype (or editing an existing one?)
     
  3. Offline

    mindeavor

    This is exactly the sort of thing I would use. The type of arena game I'd create is a team gold rush match. Within a predefined region, players kill mobs that drop gold bars. However, during the daytime teams are left to kill and steal from other teams. Mining and item drops would be tailored to encourage building, raiding, sneaking, and teamwork.

    If your plugin would make my development easier, while providing tools for switching between multiple game types, I think it is a great idea.
     
Thread Status:
Not open for further replies.

Share This Page