Level design
A level is a sequence of intentional experiences delivered through space.
Good level design is a process: define the metrics movement is built on, block
out geometry with primitives, play it, then dress it — never the reverse. This
skill is the engine-neutral practice; use godot-tilemap/unity-tilemap-2d to
lay out 2D grids and gridmaps for 3D.
When to use
- Use to plan a level's structure: critical path, pacing, gating, encounters,
and where the player learns vs is tested.
- Use the blockout → test → iterate → dress workflow to build a level that
plays well before any art exists.
- Use to derive level metrics from the character's movement so geometry is
reachable and fair.
When not to use: to generate levels algorithmically, use procedural-gen
(authored and procedural design are complementary). For the engine's tile/grid
painting tools, use godot-tilemap / unity-tilemap-2d. For the movement
abilities the metrics come from, that's the engine movement skill + input-systems.
Core workflow
- Derive metrics first. Measure the character: max jump height and distance,
run speed, reach, camera range. Every gap, ledge, and corridor is sized in
these units. Lock them before building geometry.
- Blockout (whitebox/greybox). Build the whole level from untextured
primitives at correct scale. Validate flow, sightlines, and reachability while
changes are cheap. No art yet.
- Define the critical path (start → goal) and the golden path you expect
most players to take. Layer optional/secret paths off it.
- Pace the experience. Alternate tension and rest in a deliberate curve;
don't run combat-combat-combat. Give the player room to breathe and to
anticipate.
- Teach, then test. Introduce each mechanic in a safe space, let the player
practice, then test it under pressure. Difficulty rises in a sawtooth, not a
straight line.
- Gate with intent. Use locks/keys, abilities, and one-way drops to control
order and pacing; guide with light, lines, and landmarks rather than walls.
- Playtest and iterate. Watch real players: where do they get lost, stuck,
bored, or killed unfairly? Fix the blockout; only dress when it plays well.
Patterns
1. Player metrics drive every dimension
# Measure the character ONCE, then size geometry in these units. If the jump
# changes, gaps must be re-derived — never eyeball reachability.
const RUN_SPEED := 240.0 # px/s (or m/s in 3D)
const MAX_JUMP_H := 96.0 # peak height of a full jump
const MAX_JUMP_DIST := 200.0 # horizontal distance of a running jump
const SAFE_GAP := MAX_JUMP_DIST * 0.7 # comfortable, not pixel-perfect
const HARD_GAP := MAX_JUMP_DIST * 0.95 # a deliberate skill check
# Build platforms so required jumps use SAFE_GAP; reserve HARD_GAP for optional reward.
A reachable level falls out of honest metrics. A platform placed MAX_JUMP_DIST + 1 away is impossible; one at SAFE_GAP is fair. Keep these constants beside the
level data so designers and code agree.
2. Encounter / pacing as data (a tension timeline)
# Author the level as a sequence of beats with an intended intensity (0..1).
# This makes the pacing curve explicit and reviewable before you build rooms.
const BEATS := [
{ "room": "entry", "type": "teach", "intensity": 0.1 },
{ "room": "hall_1", "type": "combat", "intensity": 0.5 },
{ "room": "vista", "type": "rest", "intensity": 0.1 }, # breather + reward
{ "room": "gauntlet", "type": "combat", "intensity": 0.8 },
{ "room": "save_room", "type": "rest", "intensity": 0.2 }, # before the boss
{ "room": "boss", "type": "climax", "intensity": 1.0 },
]
# Read the intensity column top-to-bottom: it should rise overall but dip for rests
# (a sawtooth), never flatline high. Drive spawns/music intensity from this.
3. Gating and the critical path (a small graph)
# Model the level as rooms + gated connections. Validate that the goal is
# reachable with the keys/abilities the player can actually obtain in order.
const ROOMS := {
"entry": { "exits": [ { "to": "hall_1" } ] },
"hall_1": { "exits": [ { "to": "vista", "needs": "double_jump" },
{ "to": "side_room" } ] }, # optional branch
"side_room": { "exits": [ { "to": "hall_1" } ], "grants": "double_jump" },
"vista": { "exits": [ { "to": "boss", "needs": "red_key" } ] },
}
# Validation (do this!): from "entry", can the player reach "boss" given that
# "double_jump" is granted in "side_room" before "vista" requires it? A flood
# fill that only traverses an exit when its `needs` is already satisfiable
# proves the critical path isn't soft-locked.
Pitfalls
- Dressing before it plays. Detailing a blockout you haven't validated wastes
the most expensive work on a layout you'll change. Greybox and test first.
- Geometry that ignores metrics: gaps the jump can't clear, ledges below
reach, corridors narrower than the camera needs. Size everything in player units.
- Flat pacing. Wall-to-wall combat (or wall-to-wall calm) numbs the player.
Alternate tension and rest; place a breather and a save before the climax.
- Testing a mechanic before teaching it. Players meet a hazard for the first
time in a lethal spot. Introduce safely, let them practice, then test.
- Soft-locks and dead ends. A gate needs an ability/key obtainable only past
the gate. Validate the critical path's key/ability order, not just connectivity.
- No readability / guidance. Players get lost when nothing draws the eye. Use
light, leading lines, color, and landmarks to point toward the path.
- One-way drops with no signposting strand or surprise players. Telegraph
irreversible moves.
- Confusing procedural with authored. Generation gives variety, not
authored pacing. Use
procedural-gen for variety; hand-author for intent.
References
references/pacing-and-flow.md — the difficulty/tension curve in depth,
teaching-loop design (introduce→develop→twist→test), readability and guidance
techniques, 2D vs 3D layout considerations, and a blockout review checklist.
Related skills
godot-tilemap, unity-tilemap-2d — paint 2D level grids; gridmaps for 3D.
procedural-gen — generate variety to complement authored structure.
game-ai — encounter enemies that navigate the space you build.
platformer, puzzle, roguelike — genres that compose this skill.
1---2name: level-design3description: Design and build playable levels — the blockout/whitebox-to-playable workflow, player metrics and grid layout, pacing and flow (tension/rest curve), gating and the critical path, and encounter design. Engine-neutral practice. Use when the user mentions level design, blockout/whitebox/greybox, level layout, level pacing, encounter design, or the critical path through a level.4---5
6# Level design
7
8A level is a **sequence of intentional experiences** delivered through space.
9Good level design is a *process*: define the metrics movement is built on, block
10out geometry with primitives, play it, then dress it — never the reverse. This
11skill is the engine-neutral practice; use `godot-tilemap`/`unity-tilemap-2d` to
12lay out 2D grids and gridmaps for 3D.
13
14## When to use
15
16- Use to plan a level's structure: critical path, pacing, gating, encounters,
17 and where the player learns vs is tested.
18- Use the **blockout → test → iterate → dress** workflow to build a level that
19 plays well before any art exists.
20- Use to derive level **metrics** from the character's movement so geometry is
21 reachable and fair.
22
23**When *not* to use:** to *generate* levels algorithmically, use `procedural-gen`
24(authored and procedural design are complementary). For the engine's tile/grid
25painting tools, use `godot-tilemap` / `unity-tilemap-2d`. For the movement
26abilities the metrics come from, that's the engine movement skill + `input-systems`.
27
28## Core workflow
29
301. **Derive metrics first.** Measure the character: max jump height and distance,
31 run speed, reach, camera range. Every gap, ledge, and corridor is sized in
32 these units. Lock them before building geometry.
332. **Blockout (whitebox/greybox).** Build the whole level from untextured
34 primitives at correct scale. Validate flow, sightlines, and reachability while
35 changes are cheap. No art yet.
363. **Define the critical path** (start → goal) and the **golden path** you expect
37 most players to take. Layer optional/secret paths off it.
384. **Pace the experience.** Alternate tension and rest in a deliberate curve;
39 don't run combat-combat-combat. Give the player room to breathe and to
40 anticipate.
415. **Teach, then test.** Introduce each mechanic in a safe space, let the player
42 practice, then test it under pressure. Difficulty rises in a sawtooth, not a
43 straight line.
446. **Gate with intent.** Use locks/keys, abilities, and one-way drops to control
45 order and pacing; guide with light, lines, and landmarks rather than walls.
467. **Playtest and iterate.** Watch real players: where do they get lost, stuck,
47 bored, or killed unfairly? Fix the blockout; only dress when it plays well.
48
49## Patterns
50
51### 1. Player metrics drive every dimension
52
53```gdscript
54# Measure the character ONCE, then size geometry in these units. If the jump
55# changes, gaps must be re-derived — never eyeball reachability.
56const RUN_SPEED := 240.0 # px/s (or m/s in 3D)
57const MAX_JUMP_H := 96.0 # peak height of a full jump
58const MAX_JUMP_DIST := 200.0 # horizontal distance of a running jump
59const SAFE_GAP := MAX_JUMP_DIST * 0.7 # comfortable, not pixel-perfect
60const HARD_GAP := MAX_JUMP_DIST * 0.95 # a deliberate skill check
61# Build platforms so required jumps use SAFE_GAP; reserve HARD_GAP for optional reward.
62```
63
64A reachable level falls out of honest metrics. A platform placed `MAX_JUMP_DIST +
651` away is impossible; one at `SAFE_GAP` is fair. Keep these constants beside the
66level data so designers and code agree.
67
68### 2. Encounter / pacing as data (a tension timeline)
69
70```gdscript
71# Author the level as a sequence of beats with an intended intensity (0..1).
72# This makes the pacing curve explicit and reviewable before you build rooms.
73const BEATS := [
74 { "room": "entry", "type": "teach", "intensity": 0.1 },
75 { "room": "hall_1", "type": "combat", "intensity": 0.5 },
76 { "room": "vista", "type": "rest", "intensity": 0.1 }, # breather + reward
77 { "room": "gauntlet", "type": "combat", "intensity": 0.8 },
78 { "room": "save_room", "type": "rest", "intensity": 0.2 }, # before the boss
79 { "room": "boss", "type": "climax", "intensity": 1.0 },
80]
81# Read the intensity column top-to-bottom: it should rise overall but dip for rests
82# (a sawtooth), never flatline high. Drive spawns/music intensity from this.
83```
84
85### 3. Gating and the critical path (a small graph)
86
87```gdscript
88# Model the level as rooms + gated connections. Validate that the goal is
89# reachable with the keys/abilities the player can actually obtain in order.
90const ROOMS := {
91 "entry": { "exits": [ { "to": "hall_1" } ] },
92 "hall_1": { "exits": [ { "to": "vista", "needs": "double_jump" },
93 { "to": "side_room" } ] }, # optional branch
94 "side_room": { "exits": [ { "to": "hall_1" } ], "grants": "double_jump" },
95 "vista": { "exits": [ { "to": "boss", "needs": "red_key" } ] },
96}
97# Validation (do this!): from "entry", can the player reach "boss" given that
98# "double_jump" is granted in "side_room" before "vista" requires it? A flood
99# fill that only traverses an exit when its `needs` is already satisfiable
100# proves the critical path isn't soft-locked.
101```
102
103## Pitfalls
104
105- **Dressing before it plays.** Detailing a blockout you haven't validated wastes
106 the most expensive work on a layout you'll change. Greybox and test first.
107- **Geometry that ignores metrics**: gaps the jump can't clear, ledges below
108 reach, corridors narrower than the camera needs. Size everything in player units.
109- **Flat pacing.** Wall-to-wall combat (or wall-to-wall calm) numbs the player.
110 Alternate tension and rest; place a breather and a save before the climax.
111- **Testing a mechanic before teaching it.** Players meet a hazard for the first
112 time in a lethal spot. Introduce safely, let them practice, then test.
113- **Soft-locks and dead ends.** A gate needs an ability/key obtainable only past
114 the gate. Validate the critical path's key/ability order, not just connectivity.
115- **No readability / guidance.** Players get lost when nothing draws the eye. Use
116 light, leading lines, color, and landmarks to point toward the path.
117- **One-way drops with no signposting** strand or surprise players. Telegraph
118 irreversible moves.
119- **Confusing procedural with authored.** Generation gives variety, not
120 authored pacing. Use `procedural-gen` for variety; hand-author for intent.
121
122## References
123
124- `references/pacing-and-flow.md` — the difficulty/tension curve in depth,
125 teaching-loop design (introduce→develop→twist→test), readability and guidance
126 techniques, 2D vs 3D layout considerations, and a blockout review checklist.
127
128## Related skills
129
130- `godot-tilemap`, `unity-tilemap-2d` — paint 2D level grids; gridmaps for 3D.
131- `procedural-gen` — generate variety to complement authored structure.
132- `game-ai` — encounter enemies that navigate the space you build.
133- `platformer`, `puzzle`, `roguelike` — genres that compose this skill.