# AnarchyPhase Balance Changes
An advice & opinion

## Proposed by AlexEmmet
### Edited by xLagging & reviewed mewjo_

This was initially published as a docx, due to format changes it might be kinda cursed.

## 1 How we want to change things

A game intended to be played for two months should
also be engaging enough to be fun for two months.

The removal of any vanilla feature should be the last resort, while Mojang has added mechanics that might be game-breaking, they should not be removed but instead balanced.
We advise to keep “bugs” which are widely used in the game, as Mojang did so too.

To balance something it can either be punished, limited, blocked or empowered.
An example of punishing would be to apply damage to the player, or add damage to item durability.
An example of limiting would be only allowing a stack of a certain item in the player’s inventory.
An example of blocking would be disallowing the use of an item, it can also be temporarily, such as adding a cool-down. As the complete Blocking of any item is against our guidelines we will refrain from using it as such, & put much focus on you to do the same.
An example of empowering would be to allow for precise configuration of items the player picks up, & implement a filter of ones that shouldn’t clutter the inventory.

Any changes from vanilla must be clearly communicated to the player, it would be unwise to implement a feature that requires a UI element & not add the UI element. It would also be unwise to send messages in the Minecraft chat as the messages :
1. Message visibility will change based on player action.Opening chat will make the player see it forever, but scroll up, while keeping it closed will have the element fade out.
2. It will be inside an element that has a different primary function.
The precise numbers used in this document are with no source or testing, all balances from vanilla must be subject to further change once they have been play-tested by actual players. This document contains a multitude of possible ways to balance the discussed issues. These should be implemented in a combination of sorts.
When speaking of band-aid solutions we are speaking of solutions that only fix surface issues, but not the underlying issue. These will require additional work to be done on the issue later on. When possible avoid band-aid solutions & properly stitch up the topic to begin with.
This document also outlines how they could be implemented, giving advice on the precise boundaries of each mechanic. 

### 1.1 Source material
The source material is the video “My problem with Griefing on Minecraft SMPs - & a Server Concept that solves it.” released by MoriceMC on YouTube on the 04.03.2026. This video calls for (in no particular order): 
1. immersion, 
2. vanilla like behaviour, 
3. distance in the world to actually mean something, 
4. the ability to build & defend cool bases,
a. to remove the advantages of obsidian to incentivise building with a diverse block palette,
5. the ability to raid & destroy bases,
a. with appropriate effort,
6. no incentive for large factions to hoard resources,
7. a limited world size,
a. to meet other players,
b. & to discover bases.
We will discuss both already applied changes as well as new changes the same way considering advantages & disadvantages, though our advice will be based on vanilla not on the current state of the server.

## 2 Resource depletion
As the world size is limited, & as this limit is necessary to allow for frequent player engagements, the amount of resources in the world is limited. As many resources in vanilla are non-renewable, these will slowly be used up & become rare & unobtainable.

### 2.1 Can this be fixed?
There are many potential solutions to make all resources renewable, all come with a multitude of problems, it is unwise to apply any solution as a band-aid fix.
Possible ideas include:
1. A Farm World. The Farm World would allow for an additional, regularly renewing stream of resources. However, it would also require some way of entering & leaving. Possible ways of entering & leaving include a central portal, buildable local portals & a teleportation command.
a. A central portal would combine the ability to obtain resources with the risk of getting attacked.
b. Buildable local portals would introduce a cost to gain access to the Farm World as well as allow for finding your portal on the Farm World’s side, exposing your base.
c. A teleportation command would introduce many problems, if it is instant, it could be an easy way to get out of combat engagements, even if you can’t execute it while in combat, as unlike logging of you can regenerate, re-gear, death reset or, if the code allows you, change your position.
2. Slow regeneration of resources like ores in long unused sub-chunks. A sub-chunk being a 16x16x16 block cube world region (4096 blocks) of which 24 atop each other make up a chunk. Problems with this solution include the definition of long unused sub-chunks, the technical implementation & potential destruction of small (very small) bases.
a. A long unused sub-chunk should be a sub-chunk that was not travelled through & had no player nearby within a certain time (let’s say 30 days) & a sub-chunk that has not had a certain amount of modified blocks inside it (let’s say 64 block changes).
b. The implementation we will be considering would completely replace the sub-chunk via modifying the region file. That way a secondary java process can simply change the region while it is not used & the next time a player comes nearby the change will have been applied.

### 2.2 Should this be fixed?
We strongly advise against the implementation of one of the above due to the complications any fix produces. The main goal is to allow for immersion. With a growing world border resource depreciation should be slower than the discovery of new ones.
However, as new players start at the centre of the world & with new resources appearing at the new edge. This will force new players to travel through hostile lands before getting basic gear & will also be discussed in the following section. Resource dryness will enforce Faction building & resource hoarding, something explicitly stated to be unwanted in the source material. 
As a band-aid we suggest to make the spawn radius to equal the world size, so new players can find ores, or locations to build bases, etc. easier (although this would make builds like the Halfway House(-250) useless).

We advise that section 2. Resource depletion should not be implemented, unless no other later described measures are taken.

## 3 Respawning
At the moment spawning in as a new player or respawning after death allows the player to choose between a 200 block radius around spawn or, if they have, their last slept in bed. 
As stated in the above section this will cause players to gear up in & use the natural resources of that region, causing a resource drought in the area that new players will have to work with. Additionally with spawn being the centre of the world players that are searching combat frequently patrol the area. This will put new ungeared players directly into the path of old geared players, making navigation to friends & allies hard to achieve.
Respawning at your base also isn’t an option during raids as you will respawn ungeared in a currently hostile environment. If you die during a raid you must build a designated safe-room where you can re-gear, once this is breached you will be killed repeatedly until choosing to give up that base, as now you will have to re-gear yourself from spawn.
1. Blocking: Increase the spawn-radius to allow players to spawn anywhere on the map at random. This would spread players initially & allow for more even resource degradation.
2. Empowering (A): Allowing players to choose between multiple beds (maybe one per claimed region + their last slept in) would allow them to re-gear somewhere else & after travelling back, allow them to rejoin the fight. This would enforce teams building multiple bases store valuables, horses & gear sets at each of them to allow for an easier time returning, after dying during a raid.
3. Empowering (B): Allow for choosing between respawning near your last death, or respawning around spawn.
4. Empowering (C): Allow choosing the respawn distance, players that trust their skill could choose to spawn near spawn while players less confident could spawn further away, having a longer but less dangerous time getting some gear. 
These changes complement each other very well allowing for extreme fine tuning for administrators to player usage & for players to use.
We advise that from section section 3 Respawning a combination of change 2., change 3. & change 4. are implemented.

## 4 Enderpearls
The issue with enderpearls can be split into two categories: pearl spam & stasis chambers. 
Pearl spam occurs when a player uses a multitude of enderpearls to run away from a fight.
Stasis chambers are built at a base to store an enderpearl & have it be “pulled” by a team mate to immediately get a player back to their base. 
Both pearl spam & stasis chambers stem from the same core issue, an easy getaway at low cost & skill.
An attacker raiding a base should be somewhat bound to the attack & not just be allowed to flee if they miscalculated.
A defender’s running away will most likely end in them returning once they re-geared & healed to continue defending. This should come with some cost or be generally harder than it is at the moment.

### 4.1 Pearl spam
1. Blocking (A): A higher timer on enderpearl usage throws will slow down movement with them, allowing for an easier chase after the fleeing player.
2. Blocking (A, I): A fixed time increase on the usage block of enderpearls (In discussions 30 secs is often asked for (we suggest a maximum time of 10s as this is reasonable while not really getting in the way of PvP & still prevents pearl spam) ).
3. Blocking (A, II): A dynamic time increase on the usage block of enderpearls. This will result in a mathematical function to balance the issue. This will run after every pearl throw.
Where v & w are flexible factors to balance in testing, 
where b is the base time of enderpearl usage blocking, 
where t is the time in ticks between the last two throws, 
where nx is the amount of enderpearls used in the last x minutes,
& where p is the punishment time in ticks applied, in which no other enderpearl can be used again.
p = b + t / v + nx × w
4. Blocking (B): A timer after teleportation will increase the time it takes for a player to reach their destination, keeping them in combat for longer & making the throw more active.
5. Limiting (A) / Blocking (C): Disable enderpearl throws while one of the players enderpearls is still alive or killing the players last enderpearl when a new one is thrown. This would remove quick bi-directional throws. This would also interfere with stasis chambers & we do not believe this is the correct approach.
6. Limiting (B): Limiting the amount of enderpearls a player can carry in their inventory would stop long pearl spam. But would also make farming pearls, transport or sustainment harder & generally annoying.
7. Punishing (A): Additional Damage to a player that teleports will increase the risk of using pearls.
8. Punishing (B): Adding a particle trail or an impact marker would allow others to more easily follow an enderpearl.
We advise that from section 4.1 Enderpearls – Pearl spam change 3. is implemented with either change 7. & / or change 8. if not sufficient.
### 4.2 Stasis chambers
A Stasis teleport is technically speaking a teleport further than a certain distance, for example more than 750 blocks, afterwards additionally to normal teleportation debuff the stasis debuffs should apply.
1. Punishment (A): Enderpearls deal a fixed amount of hearts on stasis teleportation no matter armour.
2. Punishment (B): When you die through enderpearl teleportation, loot should drop where you teleported from, not where you teleport to. That way stasis teleporting out of fight when low just to preserve gear won’t work.
3. Blocking (A): Upon stasis teleportation
a. Some visual / auditory indicator so others who are nearby can re-engage combat.
b. The teleport will take a certain time to activate,
i. which is calculated based on distance.
c. If you enter combat, or are in combat the timer will stop, freeze & will restart afterwards.
d. To communicate this to the player, they will see a "Teleporting in ..." timer in the action bar.
4. 2.1 Pearl spam, 5.: 
Limiting (A) / Blocking (C): Disable enderpearl throws while one of the players enderpearls is still alive or killing the players last enderpearl when a new one is thrown. [...]
This would disallow the usage of a stasis chamber in combination with enderpearls used for combat or travel. As well as disallow the usage of more than one stasis chamber.
We advise that from section 4.2 Enderpearls – Stasis chambers a combination of change 1., change 2. & change 3. are implemented.

## 5 Riptide tridents
The issues with riptide tridents are, that they allow for extreme manoeuvrability & speed with a simple water bucket or even for flight during rain. 
Please note that a maxed-out horse navigates terrain faster than a riptide trident when it’s not raining. Additionally effects like speed & jump boost can be applied to horses via potions to even further strengthen their on land & no rain advantage.
1. Blocking (A): Disable rain, totally removing rain seems a little extreme, however you could disable rain during the AnarchyPhase. Personally we would support it if rain would start right after the AnarchyPhase due to the aesthetic. 
2. Blocking (B): Disable the ability to use riptide in rain, same as above, simply changing the dynamic so that rain can still appear during AnarchyPhase.
We advise that from section 5 Riptide tridents change 1. is implemented.

## 6 Spears
The idea behind the spear, & how we believe it should be used is to be an underdog. Its primary purpose is to allow some way for new players to defend against very stacked ones. 
The current change as we know is that spears are capped to do a maximum of 20 HP before armour, this would be 0.6 HP on perfect armour, completely disabling the underdog functionality it was meant to serve.
1. Limiting (A): Limiting the amount of damage the spear can do before armour (currently this is 20HP).
2. Limiting (B): Limiting the amount of damage the spear can do after armour (for example 5HP)
We advise that from section 6 Spears both change 1. & change 2. with the higher damage cap applying dynamically.

## 7 More logical block breaking times
Outside claims:
1. Normal mining time,
2. Normal tool damage.
Inside claims, Unclaimed blocks:
1. Normal mining time,
2. Additional damage to the tool when breaking blocks.
Inside claims, Claimed blocks:
1. A default mine time. 
a. The default mine time should be set arbitrarily for each category of blocks (wood | axe, stone | pickaxe,
dirt | shovel, leaves | sword, hay | hoe) decreasing with the player’s tool quality (iron, gold, diamond...) & enchantments.
b. Water-logging everything should not be the meta. So waterlogged blocks should always be mined like normal.
2. Additional damage to the tool when breaking blocks.

A claimed block is a block placed by the player or in a certain radius around blocks placed by the player.
A block is only claimed after the current AnarchyPhase. As otherwise tunnelling & running into walls would always guarantee a way out for defenders that can’t be followed by attackers.
We advise that all changes from section 7 More logical block breaking times are implemented.

## 8 Nether claims
Nether claims are a widely suggested addition to the claim system. This allows for building larger, more complex farms. Allowing for a steady blaze rod & gunpowder supply on the server. 
1. Limiting (A): Decrease the max 200 chunks claim count at a multitude of the default rate for any claim in the nether. This would make nether claims costly as you could have fewer overworld claims.
2. Limiting (B): Nether claims could be subject to different cost. Such as netherite scraps instead of diamonds.
We advise that from section 8 Nether claims change 2. is implemented, as the player is already using a region to establish the claim in another dimension.

## 9 Attribute swapping
This assumes the usage of keybinds by the player.
Attribute swapping is a bug that has been in the game since version 1.6.2 & is widely seen as a feature by the Minecraft PVP community. Due to this bug being used by many players Mojang has kept it in the game since 2013.
Attribute swapping is performed by holding an Item (which has to have no attack cool-down active since 1.9) & swapping to another item in the same tick. This takes the cool-down, range & damage of the first item while using the attributes of the second.
Attribute swapping is for example used to disable shields & allow for spear dashing.
Shield disable attribute swaps work by switching to the axe the moment you hit with your sword. This allows for shield breaking mid combo.
Spear dashing is performed by switching from a empty slot (or an item with no cool-down) allowing to use lunge with close to no cool-down.
The biggest problem with papers attribute swapping fix is that it can create ghost items when dropping & switching to another item.
Currently attribute swapping sometimes does work. As the Paper software only partially fixes the issue. At the moment it can create ghost items when dropping items while swapping to another item creating ghost items in the player inventory. It can still be used in combat when paired with automatic tools such as macros or hacked clients. 
We recommend to re-enable it, as it is in the vanilla game & in it’s current state might encourage the use of external tools to get an unfair advantage through more consistency. 
We advise due to the reasons of section 9 Attribute swapping the paper settings are changed to allow for vanilla like attribute swapping.

## 10 Tendency to build underground bases
The tendency to build underground bases is due to the inability to properly defend them. Underground bases come with defences in the form of walls & are naturally hidden.
The advantages of a surface base are the ability to spot attackers from a distance & to hold the high-ground in combat, this must be paired with active players to defend the base during attacks.

### 10.1 Instant damage arrows
These are a great way to defend a base & especially in combination with walls have great stalling potential. We advise minimal change of these to make them a vital part of defence.
1. Blocking: Adding an effect limit applied through attacker arrows, for example a poison or instant damage 2 arrow would only apply the effect at level one. This would be a subtle but effective change to shift the odds in favour of the defenders.
2. Empowering: Generally raise the damage done by arrows shot by defenders.

### 10.2 Exploding firework rockets
Exploding firework rockets are a good way to keep attackers from scaling walls switching to instant damage arrows when they get close. Unlike tipped arrows, exploding firework rockets do allow for splash damage & as such allow for an automatic defence via redstone.
1. Empowering (A): Raise the damage done through firework rockets. 
2. Empowering (B): Raise the damage done to armour done through firework rockets.
3. Empowering (C): Allow for easier gunpowder production. Three max firework rocket costs seven gunpowder, making them far too expensive to use effectively. (Supportive of changes described in Section 7)

### 10.3 About TNT
TNT is a great way to remove the imbalance between underground & surface bases, as bombing inside a cave is more effective than on the surface.
1. Empowering (A): Raise the effect TNT has on the world.
2. Empowering (D): Increase TNT destruction lower in the world. This would incentivise building higher than the increased TNT destruction.
3. Empowering (B): Make it treat Obsidian like any other block.
4. Empowering (C): Allow for easier gunpowder production. At the moment TNT is far too expensive to use effectively. (Supportive of changes described in Section 7)

### 10.4 Minimap 
1. If you were to allow NPC's on the minimap, you would also remove the visibility gap between surface & underground bases without affecting combat too much.


To allow for proper defending of surface bases we advise the following changes:
– Section 10.1 Instant damage arrows change 1.
– Section 10.2 Exploding firework rockets change 1. & change 3.
– Section 10.3 About TNT change 1., change 3. & change 4.
– Section 10.4 Minimap could be used as a last measure if other changes don’t add enough support for surface bases.

## 11 Development limitations
Any changes from vanilla must be clearly communicated to the player [...].

Properly communicating some changes might be complicated to convey, a potential solution would be to publish a video discussing the applied changes and the reasoning behind them.

The precise numbers used in this document are with no source or testing, all balances from vanilla must be subject to further change once they have been play-tested by actual players. [...]

Additional play-testing and potential redevelopment of already developed solutions after negative test results might take a lot of time.

The development of Section 2 Resource depletion potential option 2. regeneration of the world would require careful binary operations that should be subject to stress-tests before implementation.