Mastodon Politics, Power, and Science: Design Document: DPR-Based Encounter Scaling

Saturday, December 6, 2025

Design Document: DPR-Based Encounter Scaling

J. Rogers, SE Ohio

1. The Core Concept: Balancing Budgets

At its heart, encounter balancing is about resource attrition. We can model this by comparing two key "budgets":

  1. Party Damage Budget: How much damage the party is expected to output per round (Party_DPR).

  2. Party Durability Budget: How much total damage the party can absorb before members start falling (Party_Effective_HP).

The Dungeon Instance Manager's job is to select a group of monsters whose own budgets create a specific, desired challenge level when compared to the party's budgets.

2. Refining the Party Profile

The Party Profile needs to be enhanced to store these calculated values. This calculation would be done once, perhaps in a "Party Manager" screen, not on-the-fly.

Example party_profile in campaigns.metadata:

JSON

{
  "apl": 5,
  "party_size": 4,
  "ruleset": "D&D 5e",
  
  "budgets": {
    "dpr": 65,
    "effective_hp": 220,
    "primary_save_dc_avg": 14,
    "primary_ac_avg": 17
  }
}
  
  • dpr: A simple sum of each character's expected damage per round.

  • effective_hp: The sum of all party members' HP, possibly modified by average AC/saves to represent their overall toughness.

3. Enhancing the Bestiary (monsters Table)

The monsters table must also store these budget metrics, not just a CR.

Example monsters Table Schema:

SQL

CREATE TABLE monsters (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    ruleset TEXT NOT NULL,
    cr INTEGER,
    -- Budget Metrics --
    dpr INTEGER,
    hp INTEGER,
    ac INTEGER,
    primary_attack_bonus INTEGER,
    -- Tags for searching --
    tags TEXT -- e.g., "undead,minion,ranged"
);
  

4. The Refined Instantiation Workflow

The Dungeon Instance Manager now uses a budget-matching algorithm instead of just CR.

  1. Trigger: Party enters a new dungeon.

  2. Load Blueprint & Profile: The manager loads the Dungeon Blueprint and the Party Profile.

  3. Calculate Target Budgets: The manager reads the encounter_slot from the blueprint.

    • Blueprint Rule: difficulty: "Deadly"

    • Manager's Logic: It interprets "Deadly" according to the ruleset (e.g., "An encounter is Deadly if the monsters' total dpr can down the Party_Effective_HP in 2-3 rounds").

    • Target Calculation: It calculates the target monster dpr and hp budgets for this specific fight.

      • Target_Monster_HP_Budget ≈ Party_DPR * 3 (to last 3 rounds)

      • Target_Monster_DPR_Budget ≈ Party_Effective_HP / 3 (to threaten the party in 3 rounds)

  4. The "Knapsack" Algorithm: The manager now has to solve a variation of the knapsack problem: "Find a combination of monsters from the bestiary that fits the target budgets and tags."

    • Query Bestiary: SELECT * FROM monsters WHERE ruleset = 'D&D 5e' AND tags LIKE '%undead%'

    • Select Monsters:

      • It might first select a "Leader" type to meet a portion of the budget.

      • Then, it fills the remaining HP and DPR budgets by adding "Minion" types.

      • It can intelligently mix roles: "I have enough damage, now I need a high-HP 'Brute' to absorb hits."

    • Example Outcome: To meet a Target_Monster_HP of 200 and Target_Monster_DPR of 70, it might select:

      • 1x Wight (HP: 45, DPR: 25)

      • 5x Skeletons (HP: 13 each -> 65 total, DPR: 5 each -> 25 total)

      • 2x Zombies (HP: 22 each -> 44 total, DPR: 4 each -> 8 total)

      • Total: HP: 154, DPR: 58. (This is a "Medium" encounter, not Deadly. The algorithm would continue, perhaps adding another Wight).

  5. Persistence: The resolved list of specific monsters (1x Wight, 5x Skeletons, 2x Zombies) is saved into the marker.metadata for that room. The dungeon is now "locked" with this specific, budget-balanced encounter.

5. The Role of the AI

The AI's role remains the same: it is the author of the dynamic blueprints and the bestiary.

  • Prompting the Blueprint:

    "Create a Dynamic Dungeon Blueprint... For the boss room, specify a 'Deadly' encounter with a 'Leader' and 'Minion' roles."

  • Populating the Bestiary:

    "Given the D&D 5e stat block for a 'Wight', extract its core budget metrics: HP, AC, average DPR, and attack bonus. Tag it as 'undead' and 'controller'. Return as JSON."

This creates a powerful division of labor:

  • The AI provides the creative and statistical data.

  • The Dungeon Instance Manager performs the deterministic, mathematical balancing.

  • The GM provides the high-level input (Party Profile) that drives the entire system.

No comments:

Post a Comment

h vs ℏ: A Proof That Planck's Constant Is a Coordinate Choice, Not Physics

J. Rogers, SE Ohio Abstract We prove that the choice between h (Planck's constant) and ℏ (reduced Planck's constant) represents a co...