• IP Copied!
    Click to Copy IP
    Loading...
  • Our Discord
    Loading..
  • New minigame under development

    Thoughts on this:

    • It could be a good minigame. (Don't check this if you hate the concept)

      Votes: 4 40.0%
    • It needs some serious changes.

      Votes: 0 0.0%
    • The gamemode will be unbalanced, no matter what.

      Votes: 1 10.0%
    • umies :D

      Votes: 6 60.0%

    • Total voters
      10

    DreadySemicolon

    Bishop of the umi order
    New minigame project: Stompertack (Placeholder name)
    Hi, as some of you might now, I'm a novice Java programmer, and I'm trying to learn... well... Java programming. I am fully able to write simple console applications, and I've got a little bit of experience with the Bukkit/Spigot API. Some years ago I came up with a crazy project, which I've always been referring to as"Stomp Mode". It was supposed to be something of the likes of Juggernaut in Halo games: one player holds da powah, the others kill it.

    I've learned a lot since I last picked it up, and just a few weeks ago, I decided to get it back on my desk.

    Before you keep reading: this is merely a silly project of mine, which WILL come to an end, but it is unlikely to be implemented on Aspiria. There are two reasons for that:
    • I'm not an licensed software engineer. I'm pretty skilled for someone who learned the language himself, but I'm no professional.
    • We already have enough minigames. I think... Right?
    Basic introduction:
    There's a bunch of people (survivors) who need to cooperate in order to kill an overpowered dude (the "stomper"). The end.

    Joining and leaving a game
    The Stomp plugin features, of course, configurable arenas, and every arena has a lobby.
    To join an arena you simply have to enter "/stomp join <arena_name>". Upon joining an arena, you will be teleported inside the lobby, where you'll have to wait for the game to begin IF less than 5 people have already joined (otherwise you can just step in). To mark yourself as ready, you'll either type a command or do something I haven't thought of yet.
    Once you're in-game, you'll either leave after entering "/stomp leave", upon death or when you are the last one to live.

    Equipment choice
    Usually, when playing a PvP-based gamemode, you see classes, or randomized inventories, or nothing (like in HG). With Stomp, you just bring your stuff (however it is not recommended to bring your best items with you for various reasons).
    Obviously you can't just overpower everyone with your SharpnessMXII axe: the stomper will be able to deal damage to player X according to the damage dealt by X's last few attacks; instead, the [missing_name]will have a default inventory, since every item has its property.
    Talking about [missing_name] abilities, along with normal weapons it will have [] special items:

    Snowballs:
    They explode. Yes. They explode. More precisely, each snowball will create a 3 blocks wide explosion on hit snowballs randomly regenerate when the stomper hits a foe.
    The "Eye for an eye" ("EFE" for friends, represented by a spider eye):
    While holding this item, you will deal damage to player X according to the last 3 times X attacked you; this is useful (and works) against powerful melee-based enemies, but it's useless against bows or enemies that knock you back towards other less powerful ones.

    Note: Damage-per-damage follows a logarithmic behavior (for those who know math :3), so you should really avoid bringing overoverpowered things.​
    Heavy ankles (a.k.a. "Stomping superpower"):
    It's not really an item. As a stomper, when you land after a jump, if the jump was high enough to get fall damage (which is normally canceled) and you are crouching when landing, you will generate an explosion: it will be as wide and powerful (and harmful for you) as "sweet" your landing was.

    Note: the damage you take when "stomping" will slightly differ from the usual Minecraft fall damage mechanics.

    Suggestion from BiGGi (yet to implement): everyone hit by the explosion gets propelled away from the stomper.​
    Sidekick:
    It behaves a bit like the EFE, but instead of considering the last 3 enemy attacks it will deal damage according to the target's armor (to avoid it being overpowered against weak people). It's like a normal weapon, HOWEVER, the damage increases (max. damage: 2.5 times the default damage) when you attack the enemy from the side (not from the back!).​

    Server-side customization
    This part will describe the more-technical stuff, things that non-administrative users won't need to care about.
    Arena customization
    Setting arenas up will be tricky, but if you're a server owner you probably know how to handle this kind of things.

    Shape (if you don't have any XZ space issue at all, ignore this stuff)
    Arenas will (probably (if I actually manage to win laziness and define a class for this)) be able to have multi-rectangular shapes. What does it mean, you ask?

    Normally, plugins such as Districts, Factions or what else define regions as XZ rectangles. That's the least expensive in terms of memory, but for whatever reason (lack of space?) you might need to preserve as many XZ columns as you can. Space optimization rules say you should create rectangular arenas and use all of the available space; I say otherwise. With multi-rectangular area definitions, you will be able to overlap multiple rectangles to form non-blocky arenas, if you need to make one right next to another, or if you want the arena lobby to be INSIDE the arena default rectangle.

    I will provide an explainatory picture in the future. It will be mindblowingly easy to understand.​

    Entry points (EPs for short; also known as spawnpoints)
    Both the arena and the lobby will have one or more EPs (the arena will have more, unless... well... why would you even have ONE entry point?). Every EP will have the usual X/Z coordinates, as well as a radius parameter. Arenas (not lobbies) will have a "Random Entry Point: <boolean>" setting, which will avoid uselessly loading every EP and... well, do what its name suggests.​

    Editing
    People with proper permissions will, of course, be able to edit any arena, BUT they can even do it while a game is goin' on. Although they can do that, it might be wise to disable the arena first, as this feature doesn't block incoming damage.

    Arena editors will not be prevented from using cheaty commands (such as /god, useful to block damage from annoying players), and they will be able to place and destroy blocks.

    After editing an arena, you will need to reload it (for reasonable reasons '^') before any change is made.
    Note: every arena reloads itself after a game ends, but not when it starts; if the arena is empty, you can just force-reload it.​

    I've probably got other things to explain, but I'll add them here as my ideas get clear.

    Feel free (and forced >:C) to tell me if you'd like me to add something to the list, which is why I made a post on the forums about this upcoming thingy. To clear it up, I still have to get a complete map of the changes I need to apply to incoming/outcoming damage in order to make the game balanced.
     
    Last edited:

    DreadySemicolon

    Bishop of the umi order
    'thing is, as long as the Java Garbage Collector does its job, the plugin is designed to run on the survival server. The only thing that could hog memory is the number of players of every arena, of which every player object is kept alive by the arena itself. Every player will take UP TO one kilobyte of memory, tho. I'll simplify this message when I get home :3
     

    BiGUNMAN

    Citizen
    Ultimate
    'thing is, as long as the Java Garbage Collector does its job, the plugin is designed to run on the survival server. The only thing that could hog memory is the number of players of every arena, of which every player object is kept alive by the arena itself. Every player will take UP TO one kilobyte of memory, tho. I'll simplify this message when I get home :3
    I don't expect everyone to understand this: Make it run on an instant, vote for map, no arenas, and problem solved. Then connect via networking (like via our /minigames or villager at spawn).
     

    DreadySemicolon

    Bishop of the umi order
    That's what I did, actually. Interpreting your suggestion, you want a static single arena declaration in the main class instead of a non-static array of arenas; that would be the same thing, because:
    1. An array of X objects keeps the space of the number of objects in the instantiated array: This means that an array of one X object takes the space of X itself, plus a word-long index.
    2. A static Y object, in terms of memory, equals a non-static one if it's instantiated only once.
     
    Last edited: