The Unlurked's Stack Management Mechanics

From Erfworld RPG Wiki
Jump to navigation Jump to search


Stack Management Mechanics are meant to be rules and modifiers for the stack itself and for basic stack interaction. There are two goals driving the development of this system. First, to make the aspects of a stack simpler than the aspects of the units in it, so that large-scale combat is much less time-consuming than managing individual units in combat. Second, to make the game play in a manner resembling the comic.

SMM should be treated similarly to rules for calculating bonuses or initiative. It's an abstract system that only vaguely resembles something from real life in order to simplify combat. Its core function is to turn a group of units into a single entity for the purpose of combat. Additional mechanics can (and should) be built on top of it or to override it as necessary, like they should for any other base system.


  • Because this is a suggested list of mechanics, the reasoning behind each mechanic is included after it.
  • Whenever division results in a decimal, always round up.
  • As these are base rules, most of the specifics in this page should be viewed as open to being overridden by rules built on top of them.


  • Square / The Square - An abstract that represents how a stack has been arranged to protect/utilize the most valuable units. Also used as a reference to the mathematical square that determines the Stack Width.
  • Complete Square - A group of units in a stack that form a perfect mathematical square (e.g. 4 [2 * 2], 9 [3 * 3], 25 [5 * 5]). Modifiers can be applied based on how many of these there are in a stack or by the largest of these in a stack.
  • Row - A horizontal line of Units in a stack relative to an Edge of the Square. Frequently used as a measurement for applying penalties or performing calculations.
  • Complete Row - Identical to a Row, except that it must be completely filled to be counted.
  • Edge - Part of the Square; one line of units. (Literally a line.) This is used to simulate how well a stack is prepared to receive an attack and which units receive damage for a stack.
    • Front - The Edge of the Square representing where a stack is best able to receive/deliver an attack from in order to protect/utilize its most important units. This is the only Edge a stack is rebuilt relative to when it gains/loses units.
    • Side(s) - The Edge(s) of the Square that aren't the Front or the Back. Represents a less than ideal direction to receive/deliver an attack from in order to protect/utilize its most important units.
    • Back - The Edge of the Square opposite the Front. Represents the worst direction to receive/deliver an attack from in order to protect/utilize its most important units.
  • Stack Width - The maximum number of units allowed in each Row in the Square relative to the Front Edge.
  • Screening - When one stack is dedicated to defending a single unit within the stack, an external unit/structure, or one Edge of another stack.
    • Defended Stack - The stack receiving a defensive bonus from Screening.
    • Screening Stack - The stack providing a defensive bonus by Screening.
  • Conflict - An on-going battle between specific stacks. Not to be confused with stacks on opposing sides still occupying the same map hex intent on killing each other.

Primary Mechanic: The Square


All units in a stack are first sorted from least to most important using some standard system, and then in a pattern to form a square (visually and mathematically). The units are added to the Square one row at a time from left to right, starting from the bottom (or "Front") and filling rows toward the top (or "Back"). The Square does not represent how units are literally arranged on the battlefield. It is an abstraction used to simplify how well a stack directs its resources and fields incoming attacks to best protect/utilize its most important units.

Sample of what a graph for managing The Square might look like. Limited to 25 for display purposes.

Players must always arrange their units in the same way, based on quantity and importance. A stack of 4 line up 2 x 2, a stack of 9 line up 3 x 3, and so on. Imperfect groups get as close to the shape of the square they should be in as possible, with the incomplete row / stray in the back edge of the square, and where the width of each row relative to the front edge is the square root of the mathematical square they are forming.


Width   -3--][------------------4--------------][------5--------
         9  |  10  |  11  |  12  |  13  |  16  |   17  |  20   |
            |      |      |      | M    | MNOP | PQ    | PQRST |
        GHI | IJ   | IJK  | IJKL | IJKL | IJKL | KLMNO | KLMNO |

A = Weakest, Z = Strongest

The way this abstraction works is that a stack is always assumed to be in the optimal formation. Each "Edge" of the square is used to represent a stack's ability to coordinate its units rather than literally representing which direction everyone is facing. The Front, Side, and Back Edges of The Square represent situations where the formation succeeds or fails to perform as well as it could.

A stack's Front Edge represents situations where the stack is best able to receive or launch attacks. The bottom of The Square is the Front Edge, and units are always placed relative to it when building or rebuilding a stack. The Back Edge is opposite the Front and represents situations where a stack is least able to launch/field an attack from, and is used for representing things like being ambushed or having to attack while completely unprepared. The other two Edges are called "Sides", and while they represent disadvantageous positions to attack or defend from that aren't as critical as the Back.


The main purpose behind The Square is to prevent players from endlessly resorting their stacks as units are added/removed without making them feel like they have been forbidden something critical. It is irrelevant if units are literally arranged like this on the battle map or they are maintained on some other medium while a marker represents their position on the battle map. The sole purpose of The Square is to determine how the rest of the mechanics are applied to the units in a stack, and to simplify all of the Secondary Mechanics built on top of it. This may sound strange when you're reading it, but it could be very easily managed on graph paper and/or with simple tokens. Plus it's immediately obvious when someone's Square is off and requires adjustment.

Secondary Mechanics

Unit Value Calculation

Currently, this is subject to change, as large parts of what it is dependent upon are still in flux.


A unit's value determines its place in the Square and may be used outside the scope of this document for other things. Please note that acting warlords in the Stack have their position in The Square determined by a unique mechanic. The calculations below are more for speeding things up if they get shifted into a Stack under the command of another Warlord and for outside uses of Value.

To make things easier, proceed as follows until all of your units' Values have been determined:

  1. If one of the units is a Ruler or Heir, they are the most Valuable unit (with the Ruler being more Valuable than the Heir). Barring line-of-succession, if one of the units is Attuned, they are the most Valuable unit. If none of those three cases applies, you will begin keeping a score for your units. You may stop as soon as you break all ties for the Stack...
  2. Whichever unit has the highest calculated Upkeep is considered the most valuable. In the case of units who have zero Upkeep, it is what you would have otherwise pay in Upkeep for the Unit if some mechanism (Decryption, Rands, Hunting) had not obviated the payment. Decrypted Units are more Valuable than other units with the same calculated Upkeep.
  3. For ties in Upkeep, add Level to the unit's score.
  4. For ties in Upkeep and Level, add 1 point for being a Warlord. Then add 10 points for being a Royal, 6 for being a Noble, and 3 for being a Caster. If a Caster is giving the Stack a bonus due to their magic discipline (e.g. Croakamancer with uncroaked, Dirtamancer with Golems), add that bonus to their score as well.
  5. If you're still in a tie, add the unit's base stats together (Attack, Defense, Hits, Move) without regard to their current state, then multiply their sum by the number of Specials a unit has.
  6. For identical units or an otherwise unbreakable tie, arrange by remaining hit points. If you're still in a tie you can arrange the tied units in whatever order you want.

Once your Units have been sorted by Value into the Square, no further calculations should be needed unless the Stack receives new Units.


Much like the purpose of the Square, Value is determined using math rather than tactics to keep players from bogging the game down endlessly trying to optimize where Units are.

Basic Damage Reception


By default a stack is treated as a single unit for the purpose of taking damage. When a stack is attacked, the Edge of the stack being attacked is where units are lost from as the stack loses HP. Damage is applied to each unit from left-to-right relative to the edge of the stack being attacked. Since stacks will be next to each other and facing their enemies, this means the Front of a stack will typically be receiving and dealing out attacks.

How this works out in battle is that stacks attacked on the Front Edge (abstract for ideal combat) will always lose units in order of least importance to most importance. Being attacked on either Side Edge (abstract for disadvantageous combat) will potentially cost a stack units of mixed importance. Being attacked on the Back Edge (abstract for worst-cast scenario) will cause a stack to lose its most important units first.


This takes a lot of the effort out of enforcing things via mechanics, which will be necessary with even small-scale battles. Erfworld involves a lot of specialized units and modifiers, and mostly based around numerous stack engaged in conflicts.

Special Note

Which Edge of a stack is being attacked will be determined by mechanics outside the scope of this document.



Stacks engaged in on-going combat are organized into Conflicts. Any given battle will likely have multiple Conflicts starting and ending within it until the battle is finally resolved. During a battle round, each Conflict has one round of combat resolved, then stacks and units not lumped into a Conflict each perform their actions. Conflicts mostly get applied to organizing melee combat, as only ranged units can have two-way ranged battles with each other.

A Conflict continues as long as there are opposing stacks still able to fight in it. A stack or unit is considered removed from a conflict if it successfully flees, is no longer able to participate in combat (meaning it can neither engage nor be engaged in hostile actions), or successfully disengages (requires all other units/stacks in the conflict to do the same). Stacks may join an on-going Conflict after that Conflict's combat round has been completed in the current battle round.

Conflicts should be resolved from left-to-right and top-to-bottom, relative to the first player, to avoid missing a Conflict.


Having layers in the conflict with distinct beginnings and ends allows some level of granularity in these rules for saying when things should happen. At the same time, it avoids getting bogged down in super fine details. I also needed to define this so the rest of the combat details I'm about to get into aren't open to misinterpretation.

Basic Stat Calculations


Unless otherwise stated, stat calculations are performed for all participants in a Conflict under three situations:

  • At the beginning of a Conflict
  • At the end of a combat round during a Conflict
  • Upon a new stack entering an on-going Conflict

Each unled stack is treated like an individual entity in the following manner:

  • The attack power (AP) is the average of all of its units' AP.
  • The defense power (DP) is the average of all of its units' DP.
  • The attack damage (Dmg) is the sum of all of its units' Dmg.
  • The damage resistance (DR) is the sum of all of its units' DR.
  • Initiative (Init) is the sum of all units in a stack and is only calculated at the beginning of Conflict. It is not recalculated until a new stack enters the Conflict or the Conflict ends.
  • Movement (Move) is the lowest unit's Move. Move is recalculated as-needed, immediately before initiating movement. This only happens if units in the stack have been gained, lost, or otherwise have had their Move affected since the last time Move was recalculated.

All stacks alive at the beginning of a round of Conflict act during that round, in order of Initiative. Each stack acts even if it is eliminated before it logically should have been able to act unless a situational modifier prevents it from doing so. Initiative also comes into effect for determining when certain modifiers should affect the stack.

Melee on a Side Edge incurs a -[complete squares] penalty to AP and DP for that stack. Melee on the Back Edge incurs a -[complete squares * 2] penalty to those same stats for that stack.

No individual calculations for units in a stack (e.g. experience gains, leveling up) are permitted while a stack is engaged in Conflicts. Once a stack is no longer engaged in any Conflict, it is to immediately have any pending calculations for its units and itself performed, as well as any necessary rearrangement of The Square performed.


The AP and DP being averaged makes it so the larger a stack is, the more mediocre its power becomes.

The damage decisions make it so combat scales easily. A 4-vs-4 engagement would resolve in roughly the same number of turns as a 25-vs-25 with the same rolls and same stats.

Initiative is only recalculated upon a change in conflict participation because it will get confusing very, very quickly if every round of combat causes the stacks to change fight order. Realistically, these units will be swinging at each other back and forth, not slowing down because some guy 4 columns to the right got croaked.

Recalculations are not performed immediately because doing math every single time someone rolls a hit will become very cumbersome, and because when you're swinging at enemies they will likely be swinging back. This will allow for situations where units effectively kill each other at the same time. Likewise, maintaining higher damage will resolve battles a little more quickly.


Unless there is a stat for reducing damage that scales alongside damage, squads become more prone to turning each other into spaghetti sauce as their unit count goes up. Determined this mathematically while testing.

Warlord/Escort Calculations

Any unit with Leadership who is actively leading a Stack is considered a Warlord in this section.

Stack Postures

A led stack can be on offensive, defensive, screening, or neutral posture.

When in offensive posture, the warlord's attack power in melee is added to the AP after the rest of the stack's power is divided. So if a 4 x 4 stack's total attack power is 100 and the Warlord has 25 AP, the stack's attack becomes 25 after the edge calculation, and then 50 after adding the Warlord. The Warlord's defense is calculated normally.

When in defensive posture, the Warlord's defense is added to the stack's after the edge calculation, and the attack is treated normally.

In screening posture, any unit, structure, or other stack is given a defensive bonus of some kind by the stack. For rules on one stack screening another stack, see <a href="#Screening>Stack Screening</a>. For all other cases:

  • When the target being screened is a unit within the stack, the stack receives no bonus (unless otherwise specified) from the screened unit but also receives no penalty.
  • When the target being screened is outside of the stack, the screening stack receives a -50% attack penalty.

In either case, the screened target cannot be harmed by melee combat until every unit in the screening stack has been croaked.

No special rules are applied when a led stack is in neutral posture. The Warlord's stats are calculated as if it was a normal member of the stack.


This makes warlords valuable beyond their stack bonuses, so that they are not watered down by adding them to a stack. Alternately, this could be their bonus. These rules also provide a way for players to better control their stacks without allowing them to mess with the ordering of The Square.

Stacked Warlord Calculations


When a led stack is attacked in melee, the posture determines the odds of the Warlord getting hit, as a Warlord's position is relative to the "posture". On offensive posture, roll 1d20. A roll of any number between [20 - Complete Rows] and 20 makes the Warlord a part of the edge that was hit by the attack. Yes, in a large enough stack the Warlord may always part of the damaged edge. On defensive posture, treat the Warlord as being in the dead center of the stack and immune to defensive melee penalties.


This adds a mechanic favoring cutting off stacks at 8 as well as intrinsic value to keeping stack sizes small for attack purposes, as offensive Warlords suffer less danger in smaller stacks. Likewise, this represents the realistic greater ability of someone to quickly retreat from the front when there are less dense troops behind them. It also allows the player to give a massive benefit to a warlord they're just trying to keep alive by dedicating a large stack to their total defense.

Reforming / Rotating Stacks


At the beginning of a Conflict round, all stacks that have lost/gained units must be reformed into an appropriate Square for their quantity in the appropriate order for their importance. There is no cost for this and it cannot interfere with any other action occurring.

As a free action, neighboring stacks can be merged using the same mechanic for reforming stated above this one.

A stack may rotate (presumably to retreat or to face its Front Edge to an attacker/target) before performing a normal action. This incurs a -[(complete rows * number of rotations)] penalty to the stack for the remainder of the Conflict round. On a hex, a 180 degree turn would require 3 rotations.


Because the Square is an abstract, reforming and merging are without cost. They amount to bookkeeping done by the players rather than something the units are literally doing. Players have no control over the order for the same reason they didn't when initially forming the Square. Namely so players don't spend all of their time trying to decide who goes where.

Rotation represents all of the units turning another direction and rebuilding their formation once there. The penalty represents time lost and confusion from scrambling into new positions. The penalty is designed to favor 8-unit stacks.

Screening Other Stacks


Similar to screening units or structures, a stack can aid another stack's defense. To avoid confusion, the stack performing the defense will be called the Screening Stack, and the stack receiving defense will be called the Defended Stack. A stacks can only screen one stack at a time, only stacks in immediately adjacent hexes, and screening only applies to one edge of the Defended Stack.

A Screening Stack can only screen an Edge to the left or right of its Front Edge, unless it has some kind of modifier that gives it an exception to this rule (e.g. screens against attacks from above). This is not a rule that can be broken with Carnymancy. It's a common sense rule that you can't protect something going on behind you or that's happening to the opposite side of the thing you're defending.

A Screening Stack cannot be screened.

To determine the bonus, calculate the attack and defense power for the Screening Stack as if it is in Neutral Posture. As long as it is screening, the Defended Stack will receive a defense bonus equal to half the Screening Stack's defense power, and the Screening Stack will only have half of its attack power.


This allows for what we've observed in the comic to have a sensible mechanic in the game. Namely, specialized stacks (e.g. heavy offense, tunneling) and stacks of general units to defend them, rather than important units in the same stack as expendable meat shields.

We calculate the defense and offense first to avoid massive confusion of screening stacks with different numbers of rows from the screened stack.

Screening Stacks can't be screened because that would easily lead to players losing track of which stack should be losing what unit when neighboring Screening Stacks are attacked.

Melee Screening

Damage Reception

This follows the same rules as Basic Damage Reception, with one exception: once a unit croaks, you jump to another stack before applying more damage. Start with the Defended Stack, then rotate through each applicable Screening Stack clockwise relative to the Defended Stack's Front Edge. Once each of the stacks have lost a unit, if there is still damage to apply, jump back to the Defended Stack and repeat this process until all of the damage has been distributed.


This allows the Screening Stacks to absorb some of the damage without creating a scenario when the Defended Stack is unrealistically hard to kill even when attacked head-on.

Penalty Multipliers

Abstract Mechanic

This is a guideline for customizing penalties that impact a stack based on its size:

  • Minor penalties applied to a stack should be multiplied by the total number of Complete Squares (minimum: 1).
  • Moderate penalties should be multiplied by the total number of Rows (minimum: 1).
  • Major penalties applied to a stack should be multiplied by the largest Complete Square (minimum: 1).

Sample stack-size penalty multipliers:

Stack Size Minor Moderate Major
3 1x 1x 1x
4 1x 2x 4x
5 1x 2x 4x
6 1x 2x 4x
7 1x 2x 4x
8 1x 2x 4x
9 2x 3x 9x
10 2x 3x 9x


This simplifies the process of figuring out how to make smaller stacks more tactical, as well as favoring a stack of 8 over a stack of 9.


Please use the Discussion Tab.