A roguelike is not a game with levels. It is a game with runs — and a run is a unit of design with its own length, its own difficulty ramp, its own climax and its own failure state. Design one as a linear campaign chopped into randomised chunks and you get the classic failure: the first eight minutes are great, the middle sags, and players quit on floor three without ever seeing the content you spent four months building.
Here is a workflow for designing the run itself: its length, its pressure curve, where power comes from, and how death reads as a result rather than a punishment.
Pick the run length first, and derive everything from it
Run length is the load-bearing number. Stage count, encounters per stage, how fast power compounds and how much meta-progression you need all fall out of it.
Pick a target from how your players actually play:
| Target run | Fits | Design consequence |
|---|---|---|
| 10–15 min | Mobile, arcade, party, "one more go" on a laptop | Power spikes must land in the first 2 minutes; almost no room for build-crafting |
| 20–30 min | The indie default; a lunch break or a stream segment | 3–5 stages, one clear mid-run pivot, a readable final fight |
| 45–60 min | Deck-builders, tactics, heavy builds | Needs mid-run save/suspend, and a second difficulty ramp |
| 90 min+ | Traditional roguelikes, survival sims | Requires persistent world state or players will not finish a single run |
Write the number down as a constraint, not an aspiration: "a winning run is 24 ± 4 minutes." Then make it falsifiable — log run start, stage clear, death and victory with timestamps and read the medians after your next playtest round. If your median death lands at minute 6 of a 24-minute design, your early game is doing something you did not intend, and late-game content will not fix it.
A useful decomposition for a 24-minute target:
- 4 stages × 5 minutes of play = 20 minutes
- 3 inter-stage choice screens × 40 seconds = 2 minutes
- ~2 minutes of overhead (menus, loading, the odd pause)
Now every stage has a budget. Five minutes is roughly 6–9 combat encounters, or 3 rooms plus a miniboss, or 2 puzzle chambers. That constraint is far more useful than "make a stage".
Shape the pressure curve, don't just stack difficulty
Difficulty that rises monotonically reads as grind. A run needs a sawtooth: pressure climbs, drops sharply at a safe beat, then climbs higher from a higher floor. Sketch it as a 0–10 intensity value per encounter for one ideal run. A workable 4-stage shape:
- Stage 1 (2 → 4): teach the stage's one new threat. No build decisions that can brick a run.
- Stage 2 (3 → 6): introduce an enemy that punishes your previous dominant strategy. First real choice with a downside.
- Stage 3 (5 → 8): combine threats from stages 1 and 2. This is where the run is actually decided.
- Stage 4 (6 → 10): no new mechanics, only mastery of what the player has already seen. Boss at 10.
Note the drops: each stage starts below the previous peak. That dip is where the shop, the campfire or the choice screen goes — the 40 seconds of breathing room that makes the next climb feel like a climb. Cut those drops to save time and players report the game as "exhausting" without being able to say why.
A pressure curve is also the cleanest thing to hand to a level designer. If you keep your stage layouts in GameDesignerX's Levels module, pin the target intensity value on each room alongside the layout notes — the designer then has a brief ("this room should read 7, after a 5") instead of a vibe.
Split power into three buckets
In run-based games, three kinds of power push on the same difficulty curve:
- In-run power — items, upgrades, levels gained this run. Lost on death.
- Meta-progression — permanent unlocks bought with run currency. Never lost.
- Player skill — the thing you actually want to be the deciding factor.
Decide the split explicitly. A defensible target for a skill-forward game: in-run power is roughly 60% of a winning run's effective strength, meta-progression 15–20%, player skill the rest. If meta-progression does 50% of the work, early players lose to a number rather than a mistake, and veterans win on autopilot.
Two guardrails worth writing into the doc:
- Meta-progression unlocks options, not multipliers. "New starting weapon" ages better than "+5% damage, 20 times." Percentages must keep scaling and eventually trivialise stage 1; options add variety at a fixed power level.
- Cap compounding. If an item grants +15% attack speed and four copies can drop, you have designed a 75% swing you must balance stage 4 around. Cap stacks at 2–3, or convert copies into something else.
Multiplicative items are where run-based balance goes to die. Keep the stacking math in a sheet — base value, max stacks and resulting best case per item — and check the worst-case product before it reaches a playtest. GameDesignerX's Balance and Economy sheets exist for this kind of table; what matters is having one place where the compounding is visible.
Make the choice screens carry the variety
Players do not remember rooms, they remember decisions. If a run offers 40 upgrade pickups and every one is strictly good, the run contained zero decisions. Three patterns that reliably create them:
- Two good options, one resource. Pick a weapon upgrade or a heal. Both correct, depending on the run's state.
- Power with a cost. +30% damage, −20% max health. Players argue about these for years; that argument is the game.
- Branch with known risk. The map shows "elite enemies, better reward" versus "safe, smaller reward." The information must be available before the commit, or it is a coin flip rather than a choice.
Target a decision roughly every 60–90 seconds of play. Count them in a real run — most prototypes come in far lower than their designers assume.
Design the death screen as content
A run ends dozens of times before it ends well. The death screen is therefore one of the most-viewed screens in your game, and in most prototypes it is a placeholder reading "You Died — Retry?"
Checklist for a death flow that keeps players:
- Name the cause specifically ("Killed by Ember Hound, stage 3") — not just "defeated".
- Show the run's shape: time survived, stage reached, best previous result.
- Show what the run earned permanently, even on a bad run. Zero-reward deaths are the main driver of quitting.
- Offer restart in one input, no unskippable animation. Measure death to next run's first input; above ~8 seconds, players close the game instead.
- Surface one thing learnt where you honestly can — a new enemy, a recipe seen, a lore entry unlocked.
Validate with a run ledger
For the next five playtests, log one row per run: tester, run number, result, duration, stage reached, cause of death, and the two or three biggest items taken. Twenty rows answer questions argument cannot:
- Does run duration converge on your target, or sit 40% under it?
- Is one item in the top two of every winning run? (Then it is not an option, it is a requirement.)
- Does stage 3 account for most deaths? That is either your difficulty cliff or your best encounter — testers' faces tell you which.
Keep the ledger with your session notes — GameDesignerX's Playtesting module will hold the per-session rows if you want them queryable later, but a shared spreadsheet works fine. The discipline is the point: one row per run, filled in during the session, not reconstructed afterwards.
The short version
Fix the run length. Decompose it into stages with time budgets. Draw the sawtooth and build rooms to hit numbers on it. Split power into in-run, meta and skill, and write down the ratio you intend. Put a real decision every 60–90 seconds. Treat the death screen as a core screen. Then log runs until the data agrees with the design — and when it does not, trust the ledger.