Epic Battle plugin

Discussion in 'Archived: Plugin Requests' started by xphoenixxx, Nov 21, 2013.

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

    xphoenixxx

    Epic battle/battle zone plugin


    Plugin category: PVP/Special effects/FUN

    Suggested name: Epic Battles / Space Battles / Capital Ship Combat / Warzone / Spacewar

    Footnote(Preface? lol): This plugin suggestion refers frequently to Jogy34's plugins, as this was originally a discussion I had with him.
    Also this plugin is a lot simpler than the wall of text below suggests, I have merely gone into a lot of detail over the "gameplay logic" - not all features are needed. A simple shoot and impact effect with respawning blocks on a timer in a nutshell. But with some extra interactive bits for players.

    All features can use existing blocks, entities, sounds, visual effects, or mobs. Merely linked to timers and effect loops. As such this would essentially be mainly a number crunching exercise, with visual and audio effects being triggered when certain conditions are met. So coded right, this should be surprisingly lag free, and not all that complicated. Events should be "queued up" much like how anti-lag plugins deal with tnt stacks now. This may pose an issue for inexperienced coders, but the "backend" of this need not be very complicated. You just need to have clearly defined gameplay logic rules to follow.

    What I want:
    A "warzone" (stand alone) plugin - combining various visual and sound effects for PVP (or even PVE) with shock and awe Epicness.

    Imagine logging into a server - and you hear lightning and explosion sounds... you look up, and there is an Epic Air/space battle raging above your head.

    Basically let me break the idea down -
    1. Firstly unlimited ammunition (although this could be a toggle - also have a chest a bit like the tardis-xern huons or simply some chest treated as "ammo or energy" - but some stuff should be configurable by admin to be unlimited will explain why further down at point 4 and 7) Suggested limits are a "power grid/pool"
    2. Secondly visible weapon fire - eg fireball, flaming arrows, fireballs etc (needs to look epic - especially at night)
    3. Thirdly explosions and/or lightning and/or burning effects on targeted blocks - this may be tricky you need to flag normally non-flammable blocks to appear to burn like wood.
    4. Fourthly - and this is the more important part - regenerating/re-spawning blocks. So you have a bunch of fire/artillery damage etc.. and after a time it regenerates, ideally a small amount at a time (timer based) - although entire structures could too, but it should not be everything at once, as that would look odd. This is to simulate repairs over time - and should also be configurable. (eg you may want a war running on "auto pilot" 24/7 over spawn thus regen needs to be faster, but not so fast that the combatants instantly repair... they should take epic damage on both sides) However on a player initiated war, the repair needs to be slow enough that an eventual victor can emerge. This could be tricky but possible as you would need multidimensional arrays to track the type/status of blocks in a battlezone.
    5. Fifth - damaged/destroyed blocks should not "drop" (we dont want entity lag) (although if a ship looses its engine room or some other critical part you could turn the entire thing into gravel or gravel like behavior and have it crash to the ground :p)
    6. Sixth - certain block types could go through damage "progression" eg start with iron blocks, first hit turns it into say smooth stone, second hit makes it cobble, third hit makes it black wool, fourth hit destroys it, preferably with an appropriate special effect. (see Tardis-Xerns "dematerialize" effect for example) You could even use "glass" for the final step and let the natural glass break sound play when it breaks. A simple effect might be on blocks damaged a certain amount - they get the "on fire" flag so the damage glows/burns in the dark. When a block goes from one damage state to another - use a small explosion effect or even the spiraly lava spark/blaze effect used on the who regeneration plugin to a smaller extent.
      "Repairs" would reverse this damage by one or more steps
    7. seventh - "effects zones" basically these are "decorative" battles the staff setup... eg two capital ships firing unlimited ammo at each other with random explosions, and the block damage rarely goes beyond "wool" and "on fire"before it regenerates - so the ships never entirely destroy themself.
    8. You would need - a "cannon" configuration - basically a set of particular blocks with a chest or dispenser etc that fire a particular ammunition type when powered by redstone. A little bit like the craftbook IC's. You could use different types etc for fireball/flaming arrow/fire charge etc. This would be the trickiest coding as you would need to override default arrow behavior etc.
    9. No mans land zone - this is an area you define, (possible as part of the allowed battle areas between combatants, or simply a natually effect of flagging an area a battlezone) where you get random explosions and/or lightning. This should use "geomod" physics.. where the blocks are damaged in a "splashlike" way so that it never digs down to bedrock. Eg an explosion makes a crater of black wool, on fire with dirt walls, - another explosion on the wall of the crater creates a new crater - that "pushes" the dirt sideways. but only ever damages down to a certain depth. A cheap way to simulate this would be the explosion animation then spawn in blocks(and air) in a crater shape within the AOE radius.. so two overlapping craters would look a bit like an overlapping figure 8. you could be lazy and simply "paste in" the crater shape with some random 1-3 height variation for the geomod effect, or actually crunch the xyz coords to make it realistic, either way done right should be negligible cpu overhead.
    10. long term you could even have objectives and defined zones.. so for example if one side of the battle looses more than a certain % of their base/ship or perhaps loose a particular block (representing the reactor or ammo magazine) that area is flagged no mans land and the battle progresses back... etc. So a ship stops "repairing" etc If fire stops, (or the battle is won) the ships "reset/revert/respawn after a given timer etc.. this would allow a bunch of smaller ships supporting a bigger ship etc. and once the battle is over the "pieces" reset to their starting position. This part would be most difficult to code but make the plugin more friendly to play.
    Other Gameplay points / logic to consider
    1. NB: a "repair" facility, such as a room with buttons /levers to direct repairs and a "repair budget" to allow players to prioritize weapons/power/armour/fire control etc might be an idea. Armour could take more of a beating giving more time to repair weapons for example, or if you are in the end game, prioritizing guns/power to finish off the enemy etc/
    2. NB++ Although it is not expected these ships should "move" within reason the ships should be self detecting, so world edit/movecraft type move/rotate/cut/paste effects should not break the capital ship - merely redirect the firepower where ever the guns now point
    3. NB+++ A "warp" facility could be added to the ships to move them in or out of battle - using a simple worldedit cut/paste sort of arrangement - so you can retreat or enter the battle - this could be limited to "warping" between defined "warzones" and "friendly territory zones"
    4. NB++++ Different types of guns could do different types of damage. Flaming arrows could be Armour piercing/tracer, but can only damage/burn a limited amount to certain depth in a straight line - but could swing back and forth with high rate of fire; fire charges could be "hot/plasma/Ion" and cause a lot of damage on the target blocks and immediately adjacent blocks (even set it on fire) but lack penetration. "Fireballs" could be your torpedo/explosive AOE splash damage, damaging lots of blocks at once in given radius AOE, but lacking penetration, Normal arrows could be used like "mortar/explosive" high arc artillery. Activated TNT could be used in a grenade sort of way. Lots of little damage, but shrapnel means more effect on mobs/players - these need to be launchable (simulating the old TNT canons people made)
    5. Villagers (or any mob rally) could be used to run around doing repairs, loading/firing guns etc- as such heavy fire on them would slow down repairs. This allows a single player to have as much fun as several players in slow times. This could be internally tracked with variables, and merely spawn/despawn/teleport the mob as a visual reference - and a target. If they are killed before they despawn and respawn at the next point - they are moved to a "injured" pool and the available crew count is reduced until a defined "healing" time passes. Should one ship module be a "medical bay" they wont heal at all if all the medical bays (or whatever module you use for it) are destroyed/out of power - thus all the crew could be lost leaving just the players!
    6. In the case of unlimited ammo - weapons could be limited by available power - as such be part of something similar to the repair prioritizing system. Limits could be in the form of a delay to "retrieve/replicate more" and load ammunition from the magazine room. If that room/module is lost once you run out of ammo that gun stops working... unless you power down another and its remaining ammunition is used on the active one - or a player deposits a particular item type in the chest/dispenser of that weapon.
    7. Partially Automated construction - as you build weapons/structure/Armour/power etc - a "control room" may automatically generate appropriate signs and/or buttons for operating them - or at the very least a room that shows what is operational or not. This would need to be a fixed design. Say a room full of signs with 2 levers and a button. As you add things to your ship - the signs auto-fills (eg Gatling 1, Gatling 2, Ion 1, Ion 2, Missile 1, Mortar 1, Reactor 1 etc. the module itself should have a matching name sign) this would also allow a ship to limit the number of installed modules. (also the possibility of ship "class" sizes) In the middle could be some signs indicating used/available power and any warp type signs. And a generic set of shield power levers for each side of the ship. And likewise a set of hull repair priority buttons (repeating myself here i think)
    8. Usage of the levers/buttons for example would be for "allocate power" basically an on off switch, a "Manual/Automatic" switch (for firing), a "fire/use" button and a "repair priority" button or switch. the sign would indicate the system type, power usage/availability, and condition. This would allow in the case of players to set a gun to manual, and have a player fire/reload that gun, freeing up the NPC "crew" for other tasks. The "repair priority" buttons are necessary, as the given system may be entirely destroyed so a player may not be able to go there and manually hit the "repair me" button. Conversely in the endgame the control room may be destroyed but some guns and reactors may still be intact allowing for a last man standing sort of battle.
    9. The actual modules themself could have a similar set of buttons/levers. Except these would actually perform repairs/rearm/fire etc - while the "control room" buttons only indicate these should be repaired/loaded/fired in the crew rotation. (eg in control room you hit repair, and a crew member npc goes and does the repair, or you could leave the control room and hit the repair button yourself - giving a faster repair.. but then nobody is in the control room)
    10. a "shield" system using glass or cobwebs as the block placed just outside the hull. Depending on power allocated to it, these will regenerate faster than the "hull repair" rate, but equally can only withstand a single hit in a given point. In the case of missile hits the hull would still be in the AOE but the outer radius would damage less of the hull. These would be special block configuations (eg a glowstone or lamp block with a sign reading "shield") They will need a basic amount of power to run, but any excess unallocated power increases the recharge rate. Under heavy fire + massive recharge speed - you could use colored class on heavily effected areas - or to represent areas where you have diverted power away. Only suggest this, as it would look pretty cool to spectators, seeing shields.
    11. Missiles (fireball) should have a lower fire rate, and need "time" to "reload" This reload could be limited by a "available Ammunition pool" or similar "box of ammunition" type logic.
    12. Ion cannons (fire charge) would only fire as fast as there is enough power to "charge" and "fire" - and require a dedicated crew member to operate
    13. Gatlings (flaming arrows) would have "magazine sizes" and only fire so many times before a "reload"
    14. Artillery/Mortar (normal arrows) would be slow but consistent fire, but can also run out of "ammunition" over time - requiring a mob to go get some more.
    15. Grenades (tnt) launchers would be highly inaccurate - and require a constant supply to keep firing.
    16. Fireworks effects could be used as well. (players firing from no mans land perhaps?)
    17. There should be a limited "pool" of "mobs" or "crew" on each ship, just as there is limited power, repair condition, shield power, and "batches" of ammunition between fire bursts.
    18. Grenade logic - you need a mob to get a grenade and a mob to load/fire the grenade. Too many grenade launchers and you tie up all the crew - similar logic for the other guns.
    19. If everything is enabled the crew move round the modules on rotation. This means only a limited amount of systems will be "powered", "firing", "loading" or "repairing" at a given time - limited to the crew size (and real players) on the ship. Eg crew member hits shield generator 1, it recharges its shield zone, then crew member goes to hull and repairs a block of armor, then crew member goes over to a gun and fires it, then crew member gets ammo and loads a gun etc etc. this also has the effect of limiting the amount of "Action" (and subsequent lag) at a given moment at well.
    20. This is all number a crunching exercise. The amount of "mob spawn/despawn/pathing" could be limited as well although this would make it harder to snipe the other ships crew.
    21. Final thoughts - Ground facilities? if we have no mans land, why not use it as well some how? Ships could just as easily be on the ground too (sailboat battles etc) or little fortresses on hills. (this would work well with the randomness of the grenades) and make the plugin more flexible to suit the server's theme.
    22. Repair times? should be different depending on the system type being repaired. Some things like a reactor should take a very long time to replace. Moreso if you have no working reactors - although in that case it would be offset by the entire crew focusing on that system due to lack of power to operate/repair the other systems. If a ship is warped to a "friendly" zone all guns turn off, and the entire crew is available for repairs, even if they had all been killed and no medical bay - so repairs are faster there.
    23. Repair chaining - on a ship with no reactors, crew build a "temp power source" then they repair the "replicator/magazine" if it is also damaged, then with that system working they attempt to build a proper replacement reactor, once built they split off to repairing hull/guns/etc as normal. a "Temp power source" should at this point be treated like a "heavily damaged" reactor, (and cannot be repaired to a "real" reactor unless there is a fully functional reactor). -
    24. Repair chaining should be a config file setting. (some admins might not want reactors repairable before end of battle) Equally reactors (and other modules) should be configurable to be repairable in battle or in "friendly zone only" or "only after battle"
    25. "Ship size classes" depending on the design of the control room perhaps have the size and number of modules as a configurable setting as well.. (only want epic capital ships, disable small ships, only want epic swarm battles? disable epic capital ship sizes etc, only want ground strongholds? disable "flying" ships (or set a height limit?))
    26. I am of two minds as to if redstone linking the systems should be necessary - this would introduce much programming complexity - but would add realism.

    Ideas for commands: Commands to define zones and ship regions/facilities. Although a lot of this could be achieved using signs as well (similar to craft book or movecraft)

    Eg. A sign on a particular block, say TNT or glass or combination of such. With the wording "reactor" would define that as the power source (and the win condition for the enemy)
    A set of blocks ending in a dispenser or similar and a sign with the wording "ion cannon" "gatling gun" etc. - using TNT for the reactor also reduces the SFX coding needed should this "system" be hit, as it will just explode using vanilla TNT logic.

    Some fixed things like warzones, and Allied territory zones would need to be defined in a world edit/guard selection/flag sort of way.

    Would need a command to flag a particular zone as unlimited ammo or no damage, or no reset/respawn for admins to define/finetune ongoing battles that run 24/7 for visual effect.

    Ideas for permissions: warzone.define.battle warzone.define.friendly warzone.build warzone.repair warzone.rearm warzone.fire warzone.command warzone.join warzone.quit warzone.admin.all warzone.admin.reset warzone.delete warzone.shield etc etc .build could be further broken up into module types - allowind server admins to define player classes like engineer (load/repairs) gunner (fire) etc

    When I'd like it by: Ready to run under bukkit/spigot with a proper 1.7.* version release of minecraft or better.
     
  2. Offline

    AndyMcB1

  3. Offline

    Necrodoom

    Locked. Protocol hacks are not supported here.
     
    timtower likes this.
Thread Status:
Not open for further replies.

Share This Page