SMP plugins: build the mechanics your server is missing

What an SMP actually is

SMP is short for survival multiplayer: a shared world where a group of players build, fight and trade over weeks or months. Vanilla survival gives you the world. What turns a world into a server people log back into is the set of extra rules on top of it.

Those rules are the whole product. Two servers can run the same version, the same map generator and the same difficulty, and feel nothing alike, because one of them makes death permanent and the other makes it a nuisance. The rules also decide the drama: a mechanic that takes something away from the loser is what makes a clip worth watching.

And every one of those rules is code. Minecraft has no setting for stolen hearts, no setting for a rank ladder, no setting for a claim you cannot break into. A plugin listens to what happens in the world, decides what it means, stores the consequence, and applies it the next time the player logs in.

• The world is vanilla, the rules are yours
• Rules that take something away are what make an SMP memorable
• Nothing in this page exists in the game by default, all of it is a plugin

Stolen hearts: the mechanic that defines the genre

The rule is simple to say: kill another player and you take one of their hearts. Lose all of yours and you are out. It is simple to say and it is the single most requested SMP mechanic, because it makes every fight cost something permanent.

What has to happen server-side is less simple. Maximum health in Minecraft is an attribute on the player, not a number you can leave lying around: the plugin sets it, and it has to be reapplied on every join, because a fresh session gives the player the default twenty back. So the true value lives in your own storage, keyed to the player, and the attribute is only ever the reflection of it.

Then come the cases that decide whether the mechanic feels fair. Death by lava, fall or a mob is not a kill, so nobody should gain a heart from it. A player at the maximum should not gain more. A player killed by someone they already killed twice in a row should probably not keep feeding them, unless farming is the point. And you need a floor: at zero hearts, does the player get banned, turned into a spectator, or sent back with a single heart?

• Store the heart count yourself, then reapply it on every join
• Only a player kill moves hearts, never a fall or a mob
• Set a cap and a floor, and say what the floor does
• Decide what a repeat kill on the same victim is worth

Limited lives and a way back in

A close cousin of stolen hearts, and often paired with it: every player starts the season with a fixed number of lives, and a death spends one. The tension comes from the last life, when a careless jump ends a month of building.

Server-side this is a counter per player that has to survive restarts, plus a decision about what a spent life looks like. Most servers want a lock rather than a kick: the player stays connected, watches, and cannot interact. That means intercepting respawn, changing game mode, and refusing the actions you consider playing.

The interesting half is the way back. A revival item, crafted from something expensive, that a living player can use on a dead one, turns elimination into a community event instead of an exit. That item needs its own recipe, its own use handler, and a rule about whether the revived player comes back with one life or a full set. It also needs to work on a player who is offline, which means the revival is recorded and applied at their next join.

• A life counter that survives restarts, per player
• A clear state for a player out of lives: spectator, lock, or ban
• A revival item with its own recipe and its own rules
• Revival on an offline player, applied at their next login

Ranks that are earned, not sold

A ranked SMP puts a visible label on every player: a tag in chat, a colour in the tab list, sometimes a division that moves up and down with results. It is one of the most searched SMP mechanics because it makes progress readable at a glance, without anyone having to explain the server.

The permission side of this is well covered by existing permission plugins, and there is no reason to rewrite it. What is specific to your server is the ladder: what counts as a result, how many points a win is worth against a stronger or weaker opponent, whether points decay when you stop playing, and where the cutoffs between divisions sit.

So the plugin to build is the one that owns the score. It reacts to the events you consider results, updates a number, decides which division that number falls into, and then either formats the chat itself or hands the rank over to the permission plugin you already run. Say which one you use in your description and the code will be written to talk to it.

• Decide what counts as a result before you decide the points
• Points against a stronger opponent should not equal points against a weaker one
• Divisions are cutoffs on a single number, keep them few and readable
• Let an existing permission plugin keep the permissions, own the score yourself

Levels and progression

An SMP built on levels gives players a number that only goes up, and ties small permanent bonuses to it. It is the gentlest form of progression: nobody loses anything, and there is always a next step visible.

The design work is choosing what earns experience. Time online alone rewards idling. Kills alone rewards the strongest players and bores everyone else. Most servers end up with a mix: blocks mined, mobs killed, distance travelled, quests finished, each with a different weight, so several playstyles have a route up.

Server-side, the two things that matter are the curve and the cost of counting. A flat curve makes level 50 meaningless, a steep one stalls new players in the first week, so the amount needed per level usually grows. And counting has to be cheap: incrementing a number in memory on a block break is free, writing it to disk on every block break is how you drop the tick rate. Keep the running total in memory, save it on a timer and on quit.

• Several sources of experience, so several playstyles can climb
• A growing cost per level, otherwise the ladder flattens
• Count in memory, write to disk on a timer and on quit
• Rewards that add, never rewards that take away, or it stops being progression

Land claims and protection

The moment an SMP has more than a handful of players, somebody loses a build. A claim system is what keeps the server alive past that first incident: a player marks an area, and inside it only the people they trust can build, break or open a container.

The core of this is a lookup that has to be fast, because it runs on every block break, every block place, every container open, every bucket pour, and on a busy server that is thousands of checks per minute. A list of claims scanned one by one will do at ten claims and will hurt at a thousand, so claims are usually indexed by chunk: the plugin finds the chunk, and only then looks inside it.

The rest is the rules around the edges, and that is where servers differ. Can a claim overlap another? Does it protect against explosions, against fire spread, against pistons pushing in from outside, against mobs? Does it expire when the owner stops logging in? Is there a limit on how much land one player can hold, and does that limit grow with their level? Write those answers down, because they are what your plugin has to enforce.

• Index claims by chunk, or the lookup becomes the bottleneck
• Decide about explosions, fire, pistons and mobs, not only players
• A trust list per claim, with roles if you want more than yes or no
• A limit on claimed area, and a rule for inactive owners

An economy players actually use

An SMP economy is worth building only if there is something to want. A balance with nothing behind it is a number that goes up. What makes it work is a sink: a shop that sells something scarce, an auction where players compete, a tax that removes coins from circulation.

Technically, the ledger itself is the easy part, and most servers plug into an existing economy service so that every other plugin can read the same balance. What takes the work is player to player trade: a chest shop that reads a sign, checks the stock, moves the item and the money in one operation, and does not lose either if the buyer logs out mid transaction.

The failure mode to design against is duplication. Any path where money is credited before the item is removed, or the item is given before the money is taken, will be found and abused within a week. Do the whole exchange in one step, and refuse it entirely if any part of it cannot be satisfied.

• A sink matters more than the balance itself
• Plug into the economy service your other plugins already read
• Every trade is one operation, all of it or none of it
• Log transactions, or you will never be able to settle an argument

Powers, souls and ritual altars

Beyond the survival rules, the mechanic that gives an SMP its flavour is usually the one that hands out abilities. The shapes vary: a soul dropped on death that grants a power to whoever picks it up, an altar block where you sacrifice rare items for a permanent trait, a random ability rolled once per player and kept for the season.

What all of these share server-side is a per player state that is not part of the game: a list of abilities owned, a cooldown for each, and a hook on the events where the ability should fire. The ability itself is usually small, a few lines that add an effect or cancel damage. The bookkeeping around it is what takes the code.

Two things are worth deciding early. Whether abilities stack, because two effects that both modify the same value will interact in ways you did not plan. And whether an ability can be lost, because a power that can be taken from you by another player is a far better story than one you keep forever.

• A state per player: abilities owned, cooldowns, and how they were obtained
• Decide whether abilities stack before you write the second one
• An ability that can be lost creates more play than one that cannot
• Keep the ability small and the bookkeeping strict

Bounties, teams and the end of a season

The last group of mechanics is about giving the middle of a season something to do. A bounty lets a player put money on somebody else, which turns a grudge into a public event. Teams give players a name to defend and a shared claim to build in. A season leaderboard turns everything above into a final scoreboard.

Bounties are mostly a matter of guarding against the obvious abuse: two friends trading kills to farm the pot. A minimum bounty, a delay before a bounty can be claimed, and a refusal to pay out on the same victim twice in a row cover most of it.

A season reset is the piece most servers forget until the day they need it. Wiping progress by hand is how you lose a leaderboard nobody had exported yet. Decide up front what a reset clears, what it keeps, and where the final standings are written before anything is erased.

• Bounties need a minimum, a delay, and a rule against repeat victims
• Teams need a name, a member list, and a shared claim
• A season reset is a feature, and it runs after the export, never before

How to describe an SMP plugin so it comes out right

The prompts above are starting points, not recipes. The version that fits your server is the one where you replaced the numbers, the command names and the messages with yours. Nothing improves a generated plugin faster than being specific about the parts you already have an opinion on.

Write the rule as a sequence of events: what the player does, what the server checks, what changes, what everyone sees. Name your commands exactly as you want them typed, say who is allowed to run each one, and write the chat messages in the words your players should read. Name your Minecraft version and your platform, Spigot, Paper, Bukkit or Folia, so the code is written against the right API.

Then build in passes. One mechanic at a time, tested, then the next. A single description that asks for hearts, lives, ranks, claims and an economy at once produces a plugin that does five things approximately. Five descriptions produce five plugins that each do one thing properly, and they can be installed side by side.

• Replace every number, command and message with yours
• Describe the rule as a sequence of events, not as a feature name
• State your Minecraft version and your server platform
• One mechanic per plugin, one plugin per pass

Play it before you open the season

An SMP rule is judged in game, not in source. A heart counter that reads correctly in the code and forgets itself on restart is a broken season, and you will only find that out by joining, dying and rejoining.

That is why the compiled .jar can be launched online on a real server: you join, run your commands, trigger the rule, disconnect, come back, and check that what should have persisted actually did. Persistence is the failure that hurts most, so test it first, before the balance of the numbers.

Once it behaves, download the .jar, drop it in your plugins folder and restart. The source is yours to read and change, and if a rule needs adjusting, send the description back with the correction rather than editing around the problem.

• Test persistence first: trigger the rule, reconnect, check it held
• Then test the edge cases: mob deaths, offline targets, players at the cap
• Only then argue about the numbers

Frequently asked questions

Ready to build your Minecraft plugin?

Describe it in plain English, get a compiled .jar. Free. No Java required.