Combat & Skill Systems

Comprehensive technical reference covering MUD combat architectures, skill/spell design patterns, group mechanics, PvP systems, and balance methodology. Compiled from ROM/Merc/Diku source code, Achaea/IRE documentation, Discworld MUD wiki, Aardwolf wiki, EverQuest emulator data, MUD-Dev archives, and mudcoders.com.

1. Combat System Archetypes

1.1 DikuMUD Auto-Attack (ROM/Merc Family)

The dominant MUD combat model. Combat is automatic and continuous once initiated — the player types kill <mob> and the game loop handles attack rounds until one side dies or flees.

Core loop (ROM 2.4):

game_loop_unix()
  → every PULSE_VIOLENCE (roughly 1.5 seconds):
      violence_update()
        → for each character in combat:
            multi_hit(ch, victim)
              → one_hit(ch, victim, TYPE_UNDEFINED)     // guaranteed primary attack
              → chance at second_attack (skill% / 2)
              → chance at third_attack (skill% / 4)
              → if hasted: bonus second_attack attempt
              → if slowed: lose one attack

Hit determination (ROM one_hit()):

1. Calculate THAC0 via level interpolation between class values thac0_00 and thac0_32
2. Apply hitroll: thac0 -= GET_HITROLL(ch) * skill / 100
3. Get victim AC for the relevant damage type (pierce/bash/slash/exotic)
4. Roll: diceroll = number_bits(5) (0-31 range)
5. Hit if diceroll >= (thac0 - victim_ac)

Damage calculation (ROM):

base_dam  = dice(weapon_dice_number, weapon_dice_size)  // e.g., 3d8
dam       = base_dam * skill% / 100
dam      += GET_DAMROLL(ch)

// Enhanced damage skill bonus:
if check_skill(enhanced_damage):
    dam += 2 * (dam * diceroll / 300)

// Backstab multiplier (Thief):
dam *= level-based multiplier (2x-5x)

// Defensive reductions:
if sanctuary:   dam /= 2
if protection:  dam -= dam / 4
if vulnerable:  dam += dam / 2
if resistant:   dam -= dam / 3
if immune:      dam = 0

// Position modifiers:
if sleeping: dam *= 2
if resting:  dam = dam * 3 / 2

// Hard cap with progressive softening:
if dam > 35:  dam = (dam - 35) / 2 + 35
if dam > 80:  dam = (dam - 80) / 2 + 80
absolute cap at 1200

Defense checks (evaluated before damage application):

• Parry: skill-based chance, requires wielded weapon, cannot parry while blinded
• Dodge: dexterity + skill based, lighter armor helps
• Shield block: requires shield equipped, flat chance from skill

Each defense completely negates the attack if successful.

1.2 Achaea/IRE Affliction-Based PvP

Iron Realms Entertainment (Achaea, Aetolia, Lusternia, Imperian) uses a fundamentally different model optimized for PvP depth.

Core concepts:

• Balance/Equilibrium: Dual cooldown tracks replace mana costs for most abilities. Physical actions consume Balance (2-5 second recovery), mental actions consume Equilibrium. Most offensive abilities require both.
• Afflictions over damage: Victory comes from stacking afflictions to create “locks” — combinations the target cannot cure fast enough — rather than pure HP damage.
• Deterministic curing: Aetolia uses “static curing” where cure priority order is fixed and known. Players can predict exactly what their target will cure next, enabling strategic affliction layering.
• No RNG dependency: Skill, knowledge, and reaction speed determine outcomes rather than dice rolls.

Affliction/curing timing:

Affliction lock example (circular dependency):

1. Apply slickness → prevents salve application
2. Apply asthma → prevents smoking (smoking cures slickness)
3. Apply anorexia → prevents eating (eating cures asthma)
4. Target is now “locked” — cannot cure any of the three without external help

Kill conditions:

• Health depletion (straightforward damage)
• Affliction locks → class-specific finishers (e.g., Necromancy Vivisect requires all four limbs broken)
• Mana/willpower depletion → prevents defensive casting
• Class-specific: Monks build “kai energy” from absorbing enemy attacks, then unleash devastating blows (halving health, breaking all limbs)

Limb damage system:

Individual body parts (head, torso, left/right arms, left/right legs) track damage separately. Sufficient accumulated damage causes breaks with specific effects:

• Broken arms: reduced attack capability
• Broken legs: cannot flee, movement impaired
• Head damage: concussion → amnesia (skips commands every 1-2 seconds)
• All four limbs broken: enables instant-kill abilities

750+ unique abilities across classes. Combat requires client-side automation (triggers, aliases, curing systems) — “nobody can type quickly enough to keep up.”

1.3 Discworld Taskmaster System

Discworld MUD uses a skill-check-driven combat system where outcomes depend on weighted skill comparisons rather than level-based tables.

Action Point economy:

Every combat action (attack, dodge, parry, stand up after trip) costs Action Points. Combat is mostly automatic — characters attack and defend on their own based on tactics settings — but players can issue special commands that also consume AP.

Tactics system (player-configurable):

Special attacks: smash, bash, stab, pierce, slash, slice, hack, chop, plus warcry (intimidation) and feint (deception).

Riposte mechanic: After a successful parry, player can attempt a counter-attack (pierce-based, requires weapon with spike/point).

Taskmaster skill advancement:

The taskmaster system awards “TMs” (free skill advances) based on task difficulty:

• You are most likely to TM when your success chance is low but nonzero — right at the edge of your ability
• Improvement chance follows a bell curve: 4 * p * (1-p) where p is hit chance
• Peak improvement at 50% success rate
• Two check types:
  • Linear: fixed difficulty threshold
  • Decay: difficulty scales, harder to improve as skill rises
• compare_skills(): Competitive check weighing two skills, determines outcome including critical success/failure, awards possible TMs to both parties

1.4 Timing Models Compared

Typical tick rates:

• ROM PULSE_VIOLENCE: ~12 game pulses = ~1.5 seconds real-time
• ROM PULSE_TICK (regen/area updates): ~30 seconds
• LPMud heartbeat: typically 2 seconds
• Achaea balance recovery: 2-5 seconds depending on action

2. Skill & Spell System Design Patterns

2.1 Level-Gated Unlocks

The classic DikuMUD approach. Each class has a table mapping skills/spells to the level at which they become available.

// ROM-style skill table entry:
{ "fireball",    { 22, 37, 37, 37 }, ... }
//                 Ma  Cl  Th  Wa  ← level required per class
// 37 = never available to that class

Pros: Simple, predictable progression, clear class identity. Cons: Fixed path, no player choice in build, everyone of the same class is identical at the same level.

2.2 Skill Trees

Hierarchical branching where learning skill A unlocks access to skills B and C.

Discworld implementation: Skills form a deep tree:

fighting
├── melee
│   ├── sword
│   ├── axe
│   ├── dagger
│   └── ...
├── ranged
│   ├── bow
│   └── thrown
├── special
│   └── tactics
└── defense
    ├── dodging
    └── parrying

Using a parent skill has a chance to improve it, which in turn unlocks or improves child skills. Skills can also be explicitly trained with NPCs or other players.

Design principles for meaningful trees:

• Each tier should be more powerful than the previous
• Branching should force meaningful choices (can’t max everything)
• Related abilities should advance together (using a sword improves fighting.melee and fighting.melee.sword)
• Nodes should alter playstyle, not just add flat damage

2.3 Use-Based Improvement

Skills improve through active use rather than spending XP. Common in LPMud-family games.

Discworld formula:

improvement_chance = 4 * p * (1 - p)
// where p = probability of success on the current check
// Peak at p = 0.5 (50% success rate)
// Minimum near p = 0 or p = 1

This creates natural difficulty scaling — you improve fastest against appropriately challenging content and stop improving against trivial or impossible tasks.

Skill decay: Some systems reduce neglected skills. If you don’t cast a spell for N game-days while training other skills, proficiency degrades. This prevents characters from being masters of everything simultaneously.

MudCoders Guild evolution:

One designer progressed through multiple iterations:

1. Traditional XP + levels → felt arbitrary
2. Played Discworld → adopted use-based advancement
3. Split XP into “short-term memory” (lost on death) and “long-term memory” (permanent). Sleeping converts short→long, creating incentive for rest mechanics.
4. Final iteration: removed all visible numbers. Skills improve through use, observation (watching others fight), and interconnected advancement (arm-based skills advance together). Character capability telegraphed through behavior and equipment rather than stat sheets.

2.4 Cooldowns vs. Mana

Mana pool (traditional DikuMUD):

• Spells cost mana from a finite pool
• Pool regenerates over time (faster while resting/sleeping)
• Higher-level spells cost more mana
• Mana consumed on cast attempt regardless of success (in most implementations)
• Creates resource management tension: burst vs. sustain

Cooldown-based (Achaea Balance/Equilibrium):

• No mana cost for most abilities — cooldown is the only limiter
• Balance (physical) and Equilibrium (mental) recover independently
• Recovery times vary per ability (2-5 seconds typical)
• No resource to deplete — sustain is theoretically infinite
• Tension comes from timing and decision-making, not resource management

Hybrid (Aardwolf V3):

• Mana pool exists but many attack spells are “nofail” — they always cast but effectiveness scales with practice percentage
• A 50% practiced fireball does 50% damage but never fizzles
• Eliminates frustrating whiff sequences while preserving skill differentiation

Cooldown implementation (MudBytes snippet):

// Per-skill cooldowns, e.g., "lay on hands" once per game day
skill_cooldowns[ch][gsn_lay_hands] = current_time + COOLDOWN_DURATION
// Bug note: cooldowns must be saved/loaded or players can relog to reset them

2.5 Combo Systems

Some MUDs chain abilities into combo sequences for bonus effects.

Achaea Monk (Tekura):

Martial arts abilities chain in specific sequences. Building a combo correctly amplifies damage or adds afflictions that individual strikes wouldn’t cause. Incorrect sequences waste balance time without bonus effects.

General combo patterns:

• Opener → Builder → Finisher: Classic 3-step combo. Opener enables the sequence, builders stack a resource or condition, finisher spends it for a big effect.
• Branching combos: After an opener, different follow-ups lead to different effects. Creates decision trees mid-combat.
• Stance-based: Certain abilities only available in certain stances. Using ability A puts you in stance B which unlocks ability C.

2.6 Passive vs. Active Abilities

Passive skills:

• Always active once learned
• Activated on login or on learning
• Implementation: activate(player) — single argument, applies persistent modifier
• Examples: enhanced damage (bonus to all melee), fast healing (improved HP regen), meditation (improved mana regen), haggle (better shop prices)
• ROM passive combat skills: parry, dodge, shield block — checked automatically on each incoming attack

Active skills:

• Require explicit command to use
• May have cooldowns, mana costs, balance costs, or situational requirements
• Must handle failure conditions: Can it be used in combat? Out of combat? While sitting? While blind?
• Examples: bash (knockdown attempt), kick (bonus damage), backstab (must be hidden, target not fighting), disarm (knock weapon from opponent’s hands)

Spellups (buff category):

Persistent beneficial spells cast before combat. Aardwolf categorizes these with filters:

• Spells that add AC
• Spells that add stats
• Spells that add combat modifiers (hitroll, damroll)

If two spellups are mutually exclusive (sanctuary vs. biofeedback), the system casts only one. Refreshing a buff resets its duration rather than stacking.

3. Specific Combat Mechanics Deep Dive

3.1 Auto-Attack Tick by Tick (ROM)

A detailed walkthrough of one combat round in ROM 2.4:

Frame 1: violence_update() fires (every PULSE_VIOLENCE)

1. Iterate through all characters with ch->fighting != NULL
2. Skip if character is in a wait state (lag from previous command like bash/trip)
3. Call multi_hit(ch, ch->fighting)

Frame 2: multi_hit() resolves attacks

1. Primary attack: Always attempted via one_hit(ch, victim, TYPE_UNDEFINED)
   • TYPE_UNDEFINED means use equipped weapon’s damage type, or default hand-to-hand
2. Second attack check: number_percent() < get_skill(ch, gsn_second_attack) / 2
   • A character with 80% second attack skill has a 40% chance
3. Third attack check: number_percent() < get_skill(ch, gsn_third_attack) / 4
   • A character with 80% third attack skill has a 20% chance
4. Haste bonus: If hasted, get another second_attack check
5. Slow penalty: If slowed, skip one attack from the sequence

Frame 3: Each one_hit() resolves independently

1. Check if attacker can see victim (blind penalties)
2. Determine weapon and damage type
3. Calculate hit/miss (THAC0 vs AC)
4. If hit: calculate damage, apply modifiers, call damage()
5. damage() checks for kill, applies death handling if HP <= 0

Frame 4: Victim’s turn

The victim gets their own multi_hit() call when their entry in the character list is reached. Combat is essentially simultaneous within the same tick.

3.2 Dual Wielding

In ROM-family MUDs, dual wielding adds an extra attack per round from the off-hand weapon:

// In multi_hit(), after primary weapon attacks:
if (get_eq_char(ch, WEAR_SECONDARY)):
    one_hit(ch, victim, TYPE_UNDEFINED)  // uses secondary weapon
    // Some implementations: off-hand attacks at reduced hitroll
    // Some implementations: off-hand damage reduced (no strength bonus)

Common dual wield rules across MUDs:

• Requires the dual wield skill
• Off-hand weapon must be lighter than primary
• Off-hand attacks typically have reduced accuracy (penalty to hit)
• Some systems: off-hand damage doesn’t add strength/damroll bonus
• Shields cannot be used while dual wielding
• Two-handed weapons preclude dual wielding

3.3 Spell Casting Mechanics

ROM-style casting:

1. Player types cast 'fireball' <target>
2. System checks: mana sufficient? Spell known? Target valid?
3. Mana deducted immediately (consumed even if interrupted in some systems)
4. Wait state applied: WAIT_STATE(ch, skill_table[sn].beats) — prevents further actions for N pulses
5. Spell effect function called: spell_fireball(level, ch, victim, TARGET_CHAR)
6. Damage calculated per spell function, then passed to damage()

Casting interrupts (EverQuest model):

• Cast-time spells can be interrupted by taking damage during casting
• Interrupted spells do NOT consume mana
• Global cooldown is cancelled on interrupt, allowing immediate recast
• Movement during casting (except turning) always interrupts
• Some spells are “instant cast” and cannot be interrupted

Saving throws (Alter Aeon model):

Seven save categories: spell, poison, breath, fire, cold, zap, normal.

// Effective defense level calculation:
effective_level = char_level + (saving_spell / 5)
// Example: 50% spellsave = +10 effective levels of defense

// Spell resistance (different from magic resistance):
// Reduces incoming spell level before effect calculation
effective_spell_level = spell_level - (spell_resistance * 0.35)
// A level 100 fireball with 50 resistance hits as level 65

// Magic resistance (percentage-based):
// Roll against magic_resist% — if successful, spell fails entirely
// Drawback: also blocks beneficial spells (heals, buffs)

Damage variance:

Before saves are applied, magical damage gets a random multiplier of 0.5 to 1.5. This creates damage spread even on identical casts.

3.4 Flee and Rescue

Flee:

do_flee(ch):
    if ch in wait_state: fail ("You can't flee — you're still recovering!")
    pick random exit from current room
    if exit exists and is open:
        50-75% base success chance (varies by implementation)
        modified by: dexterity, level difference, encumbrance
        if success:
            stop_fighting(ch)
            move_char(ch, random_exit)
            lose 25-50 XP (death tax lite)
        if fail:
            "You failed to flee!"
            lose attacks this round

Wimpy (auto-flee):

• wimpy 50 → character automatically attempts to flee when HP drops below 50
• Only triggers if character is NOT in a wait state (not lagged from bash/trip/spell)
• Flushes the command queue when triggered
• Does not guarantee successful flee
• “May take you from the frying pan into the fire” — random exit selection

Rescue:

do_rescue(ch, victim):
    // ch attempts to take over as tank for victim
    if victim not fighting anyone: fail
    if ch not in same room: fail

    success_chance based on:
        - rescue skill percentage
        - level comparison (ch vs attacker)
        - dexterity comparison

    if success:
        attacker->fighting = ch      // mob now targets rescuer
        ch->fighting = attacker       // rescuer engages mob
        victim stops being primary target
        "You rescue {victim}!"
    if fail:
        "You fail the rescue!"
        WAIT_STATE applied (can't try again immediately)

Rescue is the foundational group combat mechanic — it’s how tanks maintain aggro in DikuMUD-family games that lack formal threat tables.

3.5 AOE in Room-Based Systems

MUD rooms are atomic spatial units — there’s no position within a room. This creates interesting AOE design constraints.

Common approaches:

1. Room-wide AOE: Spell hits all valid targets in the room. fireball in ROM damages every non-grouped mob in the room. Drawback: can accidentally aggro neutral mobs.

2. Group-targeted AOE: Spell hits all members of the target’s group. More precise but less spatially intuitive.

3. Cone/directional: Hits targets in a specific exit direction. Rare in traditional MUDs but used in spatial combat systems.

Aardwolf area attack behavior:

“Most [area attacks] still initiate combat with immune mobs since the caster attempted harm.”

This is a significant design consideration — AOE spells can start fights with powerful monsters you didn’t intend to engage.

ROM area_attack pattern:

for each character in room:
    if is_safe(ch, vch): skip
    if is_same_group(ch, vch): skip
    if vch == ch: skip
    // apply spell effect
    spell_function(level, ch, vch, TARGET_CHAR)

3.6 Damage Types and Resistances

ROM damage type categories:

Resistance/vulnerability flags (ROM):

Each mob/player can have three flag sets per damage category:

These stack with other reductions (sanctuary, protection) multiplicatively.

Aardwolf evolution — curve-based resistances:

Aardwolf replaced binary flags with a continuous resistance scale. Resistance operates “on a curve” — doubling resistance points doesn’t double protection. This prevents stacking gear to achieve immunity and creates meaningful tradeoffs in equipment selection.

Aardwolf damage types: slash, pierce, bash, fire, acid, magic, shadow, disease, poison.

4. Group Combat

4.1 The Tank/Healer/DPS Trinity

Originated in DikuMUD, codified by EverQuest, inherited by every major MMO.

How it works in MUDs:

• Tank: First to attack (target mob attacks whoever hit it first). High HP and AC. Uses rescue to pull aggro from squishier members.
• Healer (Cleric): Casts healing spells on the tank. Must manage mana for sustained fights. Healing generates minimal aggro in most systems.
• DPS: Deals damage without drawing mob attention. Rogues backstab, mages cast damage spells, warriors use enhanced attacks.

Why the trinity emerges:

“EverQuest, inspired by a text MUD based on D&D, had a class design that borrowed heavily from the older D&D system. The core trinity of roles rose to prominence in high end raiding: a character tanked the boss, healers had to keep the tank alive, and other players hurt the boss without drawing too much attention to themselves.”

Criticism and limitations:

• Forces specific group compositions — groups without a healer or tank may be unable to function
• Players of underrepresented roles gain social power; overrepresented roles get excluded
• “If every encounter is balanced with the assumption of having a specific group composition, then the players may feel restricted”
• Solo play becomes difficult for tank/healer classes designed around group synergy

4.2 XP Sharing

EverQuest formula (Project 1999):

Solo XP = mob_level^2 * zone_modifier    // zone_modifier typically 75-100

Group XP bonus per member:
    2 members: +2%
    3 members: +6%
    4 members: +10%
    5 members: +14%
    6 members: +20%

// XP pie split proportionally by each player's total lifetime XP
// Players with similar XP totals get roughly equal shares
// Large XP gaps (high + low level) reduce efficiency

Group level range limit:
    min_level >= max_level * 0.667 (rounded up)
    OR: max_level <= min_level * 1.5 (rounded down)
    Minimum 5-level spread always allowed

Class/race XP modifiers (EQ):

These multiply the XP requirement, not the gain:

• Warrior: +10% bonus (levels faster)
• Rogue: +9%
• Monk: -20% penalty (levels slower)
• Paladin/Shadowknight/Ranger/Bard: -40% penalty
• Troll race: -20% penalty

ROM-style group XP:

Simpler — XP from kill divided equally among group members in the room. Level difference between killer and mob affects base XP. Some implementations add a small bonus per group member to incentivize grouping.

4.3 Aggro / Threat Management

EverQuest hate list system:

NPCs maintain a hate table ranking all players by numerical threat. The player with the highest value is the primary attack target.

Threat generation sources:

Taunt mechanics (EQ):

“A successful taunt will jump to the top of the aggro list + 1 above whatever that Hate value was. If the Hate generated was 1000, a successful taunt would put the caster at 1001 Hate instantly, even if they were only at 600 prior.”

Taunt skill level determines success percentage.

Proximity aggro:

• Players within melee range have hate compared directly
• Distance reduces effective hate value
• Beyond 1300 units: hate resets to zero for that player
• Sitting increases detection range significantly

Hate reduction abilities:

• Feign Death: drops off hate list entirely if mob doesn’t resist
• Hide/Sneak: reduces aggro radius
• Concussion/Cinder Jolt: direct hate reduction abilities

4% rule:

“Once the 4.0%+ threshold is passed, the MT [main tank] can freely move the mob around with no chance of it swapping to a new target.”

This creates a stability buffer — once a tank establishes solid aggro, minor fluctuations don’t cause target swaps.

4.4 Group Formation

DikuMUD group command:

group <player>     // leader adds a follower to their group
follow <leader>    // player follows the leader

// Group members:
// - Share XP from kills
// - Can rescue each other
// - Are excluded from AOE friendly fire
// - See group status via 'group' command (HP/mana of all members)

Formation/position systems (some MUDs):

• Front row / back row positioning
• Front row takes melee hits; back row cannot be melee’d until front row is down
• Ranged attacks and spells can target any row
• Tanks in front, casters in back — spatial representation of the trinity

5. PvP Design

5.1 Consent Systems

Aardwolf OPK (Open PK) flag:

• Voluntary toggle — flagged players can attack other OPK players anywhere outside safe rooms
• Incentives: +10% XP bonus on all kills, enhanced campaign rewards
• Can be turned off, but with a cooldown before it deactivates

PK flag anti-abuse measures:

• “In combat” status persists 15 seconds after last PvP damage given/received
• Logging out during combat = character death (prevents combat logging)
• Anti-spawn-camp: newly respawned players with empty inventory are protected
• Level range restrictions: can’t attack players significantly below your level

5.2 Arenas

Dedicated zones where PvP is always allowed regardless of flagging status.

Design patterns:

• Open arenas: Enter freely, fight anyone present. Usually no death penalty.
• Matched duels: Request sent, opponent accepts, teleported to arena. Spectators can watch.
• Tournament brackets: System-managed elimination brackets. Entry fees, prize pools.
• Team battles: Group vs. group in arena settings.
• Capture objectives: Control points, flag capture adapted to room-based geography.

5.3 Ranking / Ladder Systems

Elo-based systems:

Standard Elo (from chess) can be adapted for MUD PvP:

Expected score:  E_A = 1 / (1 + 10^((R_B - R_A) / 400))
New rating:      R_A' = R_A + K * (S_A - E_A)
// K = volatility factor (higher for new players, lower for established)
// S_A = actual score (1 for win, 0 for loss, 0.5 for draw)

WoW Arena evolution: Started with Elo, moved to Glicko-2, now uses TrueSkill-like system. Each approach handles uncertainty and volatility differently.

Customization per arena:

Different K-factors, starting ratings, or decay rates per arena tier create varied competitive environments — some more volatile (quick ranking changes), others more stable (grinding consistency).

5.4 Balance Approaches for PvP

Achaea philosophy:

Combat is treated as a sport. Mastering it requires “the ability to think quickly, react quickly, as well as innovate in terms of strategy.” Hundreds of abilities create emergent complexity rather than balanced simplicity.

Aetolia “static curing”:

All curing follows deterministic priority rules. No RNG means the better-prepared and faster-thinking player wins consistently. This is explicitly a design choice to reward skill over luck.

Armageddon approach (RP-heavy):

PvP is “political” — actual combat is a “ceremonial coup de grace” following extensive in-character setup. Mechanical combat skill matters less than social maneuvering.

5.5 Griefing Prevention

• Safe rooms: Recall points, guild halls, cities — no PvP possible
• Level range restrictions: Cannot attack players far below your level
• Death penalties: Reduced or eliminated in PvP (no XP/item loss)
• Bounty systems: Repeated killers accumulate bounties, becoming targets themselves
• Cooldowns: Cannot attack the same player again within N minutes
• GM intervention: Report systems, PvP logs for admin review
• Consequences: Criminal flags, stat corruption, restricted access to services

6. Balance Methodology

6.1 Theoretical Frameworks

Transitive balance (cost curves):

Every ability/item has a cost and a benefit. Balance means the cost-to-benefit ratio is consistent across all options.

// Magic: the Gathering approach:
// Reduce every cost and benefit to a single comparable number
power_rating = sum(all_benefits) / sum(all_costs)
// All items should have similar power_ratings

Linear cost curves: double the power = double the cost. Works for simple systems but can be gamed by finding undercosted combinations.

Nonlinear curves: increasing returns create “break points” where certain thresholds become dramatically more valuable (e.g., enough damage to one-shot a common mob).

Intransitive balance (Rock-Paper-Scissors):

Classes that are strong against some and weak against others. No single class dominates.

// Can be formally solved using matrices and linear algebra
// For 3 strategies with payoff matrix M:
// Find probability vector p where p * M * p^T = 0
// Optimal mixed strategy in zero-sum game

Caveat: RPS balance only works if the meta-game ensures all “types” are present. “Fire wizards being weak to purple means nothing in a campaign where no purple wizards appear.”

Fruity balance (incomparable):

Some abilities are so unique they resist numerical comparison. A teleport spell and a fireball serve entirely different purposes. Balance here requires “excessive playtesting” — there’s no formula.

6.2 Class Balancing

Power budget approach:

Each class gets the same total “budget” of power distributed differently:

Cells must sum to roughly the same total across rows.

Asymmetric matchup design:

Rather than making every class equally effective against every other class, intentionally create favorable and unfavorable matchups:

• Warriors beat Thieves (armor negates sneak attacks)
• Thieves beat Mages (interrupts, spell disruption)
• Mages beat Warriors (magical damage bypasses armor)
• Clerics are neutral/supportive against all

Aardwolf resistance curves:

Flat bonuses are easier to balance but boring. Curve-based resistances ensure diminishing returns on stacking — you can’t just pile on fire resistance gear until you’re immune. This keeps gear choices interesting and prevents degenerate builds.

6.3 Power Curves and Scaling

Linear scaling:

damage = base_damage + (level * coefficient)
hp = base_hp + (level * hp_per_level)

Simple, predictable, but high-level combat feels identical to low-level combat with bigger numbers.

Exponential scaling:

damage = base_damage * (1 + growth_rate) ^ level
xp_to_level = base_xp * level ^ exponent

Creates dramatic power gaps between levels. Low-level players feel helpless against high-level ones. Can create “treadmill” feelings.

Soft caps and diminishing returns:

// ROM damage softening:
if dam > 35: dam = (dam - 35) / 2 + 35
if dam > 80: dam = (dam - 80) / 2 + 80

// Effect: damage beyond 35 is halved, damage beyond 80 is quartered
// A "raw" 200 damage hit becomes: 35 + (45/2) + (120/4) = 35 + 22.5 + 30 = 87.5
// This prevents one-shot kills while preserving damage differentiation

EverQuest class XP modifiers as balance tool:

Rather than making all classes equal in combat power, EQ gives weaker-in-combat classes faster leveling:

• Warriors (strong combat): +10% XP rate
• Paladins (versatile): -40% XP rate

This balances total time-to-power rather than moment-to-moment combat effectiveness.

6.4 Item Power Budgets

Slot-based budgets:

Each equipment slot gets an allowance of total stat points:

// Example budget per slot:
Weapon:  15 points (can be hitroll, damroll, damage dice, procs)
Shield:  10 points (AC, saves, HP)
Armor:   12 points (AC, stats, resists)
Ring:    8 points (stats, saves, minor effects)

// Conversion rates:
1 hitroll = 1 point
1 damroll = 1.5 points  (damage is more valuable)
10 HP = 1 point
1 AC = 0.5 points
1 stat point = 2 points
Special proc = 3-8 points (depending on effect)

ROM item flags:

Items can have flags like GLOW, HUM, ANTI_EVIL, ANTI_GOOD, MAGIC, NO_DROP. These serve as soft restrictions — ANTI_EVIL prevents evil characters from using a holy sword, creating class/alignment-specific gear without explicit class restrictions.

6.5 Testing Methodology

Rule of 2:

“When uncertain about value direction, double or halve — not for precision but for discovery through large-scale testing.”

If you’re not sure whether a spell does too much or too little damage, try doubling it. The extreme result will quickly reveal which direction is correct.

Monte Carlo simulation:

Use spreadsheets with RAND() to simulate thousands of combat encounters:

• Track win rates between all class pairs
• Identify dominant strategies
• Find degenerate item combinations

Adversarial playtesting:

“Instruct testers to exploit and win, identifying dominant strategies.”

The goal is to break the game intentionally. If playtesters can’t find an exploit, the system is probably well-balanced. If they can, fix it before players do.

Metrics to track:

• Time-to-kill (TTK) across level ranges
• Win rates in class vs. class PvP
• XP per hour by class and level range
• Heal throughput vs. damage throughput
• Flee success rates
• Average combat duration

Sources

• DikuMUD Wiki: Combat Mechanics
• ROM 2.4 QuickMUD Source (fight.c)
• BaseMUD (ROM overhaul)
• AchaeaWiki: Combat Overview
• Aetolia PvP Combat
• Discworld MUD Wiki: Combat
• Discworld MUD Wiki: Taskmaster
• Discworld MUD Wiki: Tactics
• Discworld MUD Wiki: Skills
• Aardwolf Wiki: Attributes
• Aardwolf V3 Skills & Spells
• Aardwolf OPK Blog Post
• Aardwolf Wiki: Damage Types
• Project 1999 Wiki: Experience
• Project 1999 Wiki: Aggro
• EQEmulator: Hate List Logic
• Alter Aeon: Saving Throws & Resistances
• ROM Damage Type Table
• MUD-Dev Mailing List Archives
• MUD-Dev: Combat Discussion (1999)
• Mud Coders Guild: Combat
• Mud Coders Guild: Progression
• Muds Wiki: Tank
• Gamedeveloper: Rethinking the Trinity
• Game Design Concepts: Level 16 — Balance
• Gamedeveloper: RPS Design in Strategy Games
• Elo Rating System (Wikipedia)
• A Moment in Tyme: Combat Design
• Armageddon MUD: Combat Design Discussion
• Gammon Forum: Skill Systems
• rec.games.mud.admin: Skill-Based Systems