Dungeon Checklist

Overview

Dungeon Checklist frames a good adventure site as a bundle of different player-facing verbs rather than a linear sequence of fights. The checklist is useful because it forces the referee to include multiple reasons to explore, retreat, negotiate, and experiment.

The Seven Checks

• Something to steal: treasure or equivalent value that justifies entry.
• Something to be killed: straightforward combat pressure.
• Something to kill you: visibly dangerous threats that support player choice and self-scaling play.
• Different paths: branching structure that enables retreat, mastery, and varied approaches.
• Someone to talk to: social leverage inside the dungeon instead of pure obstacle flow.
• Something to experiment with: weird machinery, magical rules, or unexplained interactions.
• Something the players probably won't find: hidden depth that preserves wonder and rewards thoroughness.

Why It Matters

The checklist is a compact OSR design heuristic because it ties dungeon quality to decision density. A site built this way supports combat, exploration, social play, and discovery without needing heavy subsystem overhead.

Practical Use

Use the checklist as both a drafting prompt and a final audit. It is especially strong when combined with procedures that reward retreat, partial information, and re-entry.

See Also

• Tekumel-style Underworld Structure - Macro-scale dungeon architecture for supporting multiple routes and scenario clusters
• Dungeon Adventuring - OSE SRD - Turn structure and default procedure stack for running those spaces at the table
• Sandbox Generator - Broader procedural toolkit for generating sites, landmarks, and factions around the dungeon

Sources

• https://goblinpunch.blogspot.com/2016/01/dungeon-checklist.html