@jarrodmedrano/claude-skills 1.0.1 → 1.0.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/skills/game-design-theory/SKILL.md +102 -0
- package/.claude/skills/game-design-theory/design-principles.md +308 -0
- package/.claude/skills/game-design-theory/gameplay-elements.md +213 -0
- package/.claude/skills/game-design-theory/player-psychology.md +175 -0
- package/.claude/skills/game-design-theory/playtesting.md +321 -0
- package/.claude/skills/game-design-theory/storytelling.md +219 -0
- package/.claude/skills/game-feel/SKILL.md +305 -0
- package/.claude/skills/game-feel/references/adsr-tuning.md +271 -0
- package/.claude/skills/game-feel/references/classic-profiles.md +279 -0
- package/.claude/skills/game-feel/references/perception-thresholds.md +160 -0
- package/.claude/skills/game-feel/references/polish-effects.md +246 -0
- package/.claude/skills/game-feel/references/simulation-recipes.md +306 -0
- package/.claude/skills/game-feel/references/six-metrics.md +239 -0
- package/.claude/skills/level-design/SKILL.md +249 -0
- package/.claude/skills/level-design/anticipatory-play.md +223 -0
- package/.claude/skills/level-design/hiding-linearity.md +181 -0
- package/.claude/skills/level-design/indie-practices.md +286 -0
- package/.claude/skills/level-design/open-world-planning.md +294 -0
- package/.claude/skills/level-design/play-personas.md +240 -0
- package/.claude/skills/level-design/procedural-handmade.md +271 -0
- package/.claude/skills/level-design/themed-environments.md +264 -0
- package/README.md +9 -1
- package/package.json +3 -1
- package/scripts/install.js +16 -1
- package/templates/github-actions/README.md +36 -0
- /package/.claude/{commands/design-review → agents}/design-review-agent.md +0 -0
- /package/.claude/{commands/code-review → agents}/pragmatic-code-review-subagent.md +0 -0
- /package/{.claude/commands/code-review → templates/github-actions}/claude-code-review-custom.yml +0 -0
- /package/{.claude/commands/code-review → templates/github-actions}/claude-code-review.yml +0 -0
- /package/{.claude/commands/security-review → templates/github-actions}/security.yml +0 -0
|
@@ -0,0 +1,239 @@
|
|
|
1
|
+
# The Six Metrics of Game Feel
|
|
2
|
+
|
|
3
|
+
A framework for measuring and comparing how games feel, enabling meaningful analysis across different games.
|
|
4
|
+
|
|
5
|
+
## Overview
|
|
6
|
+
|
|
7
|
+
| Metric | Question It Answers |
|
|
8
|
+
|--------|---------------------|
|
|
9
|
+
| **Input** | What signals enter the system? |
|
|
10
|
+
| **Response** | How do signals change the game? |
|
|
11
|
+
| **Context** | What space gives meaning to motion? |
|
|
12
|
+
| **Polish** | What effects sell the interactions? |
|
|
13
|
+
| **Metaphor** | What expectations does representation create? |
|
|
14
|
+
| **Rules** | What game rules affect moment-to-moment feel? |
|
|
15
|
+
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
## 1. Input Metrics
|
|
19
|
+
|
|
20
|
+
### Physical Device Properties
|
|
21
|
+
- **Ergonomics**: How does it feel to hold?
|
|
22
|
+
- **Button quality**: Springy, mushy, clicky?
|
|
23
|
+
- **Build quality**: Solid, cheap, premium?
|
|
24
|
+
|
|
25
|
+
### Signal Properties
|
|
26
|
+
|
|
27
|
+
| Property | Description | Example |
|
|
28
|
+
|----------|-------------|---------|
|
|
29
|
+
| **States** | How many positions? | 2 (button), 360° (stick) |
|
|
30
|
+
| **Signal type** | Boolean or continuous? | On/off vs 0.0-1.0 |
|
|
31
|
+
| **Sensitivity** | How much variance detected? | Analog stick precision |
|
|
32
|
+
| **Combination** | What can be pressed together? | Chords, simultaneous inputs |
|
|
33
|
+
|
|
34
|
+
### Signal Interpretations
|
|
35
|
+
Raw signals can be interpreted as:
|
|
36
|
+
- **Instant**: Up, Down
|
|
37
|
+
- **Over time**: Pressed, Held, Released
|
|
38
|
+
- **Duration**: How long held
|
|
39
|
+
- **Sequence**: Button combinations over time
|
|
40
|
+
|
|
41
|
+
### Input Space
|
|
42
|
+
The total possible inputs at any moment:
|
|
43
|
+
- NES controller: 8 buttons, simple combinations
|
|
44
|
+
- Modern controller: 15+ inputs, analog sticks, triggers
|
|
45
|
+
- More input space = more potential expressivity
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## 2. Response Metrics
|
|
50
|
+
|
|
51
|
+
### Mapping Types
|
|
52
|
+
|
|
53
|
+
| Type | Description | Feel |
|
|
54
|
+
|------|-------------|------|
|
|
55
|
+
| **Direct** | Input directly sets value | Responsive but limited |
|
|
56
|
+
| **Indirect** | Input modifies simulation | Expressive but complex |
|
|
57
|
+
| **State change** | Input switches behavior modes | Enables move variety |
|
|
58
|
+
|
|
59
|
+
### What Gets Modulated
|
|
60
|
+
|
|
61
|
+
Response can change:
|
|
62
|
+
- **Position** (teleport-like, stiff)
|
|
63
|
+
- **Velocity** (speed changes)
|
|
64
|
+
- **Acceleration** (force applied)
|
|
65
|
+
- **Simulation parameters** (gravity, friction)
|
|
66
|
+
- **Character state** (walking→running→jumping)
|
|
67
|
+
|
|
68
|
+
### ADSR Envelope Measurements
|
|
69
|
+
|
|
70
|
+
For any response, measure:
|
|
71
|
+
- **Attack**: Time to reach full response
|
|
72
|
+
- **Decay**: Time to settle to sustained level
|
|
73
|
+
- **Sustain**: Level maintained while input held
|
|
74
|
+
- **Release**: Time to return to neutral after input stops
|
|
75
|
+
|
|
76
|
+
### Expressivity
|
|
77
|
+
How many different outcomes are possible from the same basic action?
|
|
78
|
+
|
|
79
|
+
Low expressivity: Jump always same height
|
|
80
|
+
High expressivity: Jump height varies with button hold time
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
## 3. Context Metrics
|
|
85
|
+
|
|
86
|
+
### Spatial Relationships
|
|
87
|
+
|
|
88
|
+
| Relationship | Measure |
|
|
89
|
+
|--------------|---------|
|
|
90
|
+
| **Density** | Objects per unit area |
|
|
91
|
+
| **Spacing** | Distance between interaction points |
|
|
92
|
+
| **Scale** | Object size relative to avatar |
|
|
93
|
+
| **Variety** | How much spacing varies |
|
|
94
|
+
|
|
95
|
+
### Context-Mechanic Fit
|
|
96
|
+
|
|
97
|
+
The key question: Does the space match the avatar's capabilities?
|
|
98
|
+
|
|
99
|
+
- Jump height → Platform heights
|
|
100
|
+
- Run speed → Corridor widths
|
|
101
|
+
- Stopping distance → Gap before hazards
|
|
102
|
+
- Turn radius → Corner angles
|
|
103
|
+
|
|
104
|
+
### Collision Properties
|
|
105
|
+
- **Friction**: How much does contact slow movement?
|
|
106
|
+
- **Bounciness**: Do objects rebound?
|
|
107
|
+
- **Passability**: What can be moved through?
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## 4. Polish Metrics
|
|
112
|
+
|
|
113
|
+
### Effect Categories
|
|
114
|
+
|
|
115
|
+
| Category | Examples |
|
|
116
|
+
|----------|----------|
|
|
117
|
+
| **Particles** | Dust, sparks, debris |
|
|
118
|
+
| **Screen effects** | Shake, flash, zoom |
|
|
119
|
+
| **Animation** | Squash/stretch, anticipation, follow-through |
|
|
120
|
+
| **Sound** | Impact sounds, ambient, UI feedback |
|
|
121
|
+
| **Haptics** | Controller rumble patterns |
|
|
122
|
+
|
|
123
|
+
### Measuring Polish Quality
|
|
124
|
+
|
|
125
|
+
**Coherence**: Do effects tell the same story?
|
|
126
|
+
- Big hit = big sound + big shake + big particles
|
|
127
|
+
|
|
128
|
+
**Synchronization**: Do effects align with action?
|
|
129
|
+
- Footstep sounds sync with animation frames
|
|
130
|
+
|
|
131
|
+
**Proportionality**: Do effect intensities scale appropriately?
|
|
132
|
+
- Light impact → small effect
|
|
133
|
+
- Heavy impact → large effect
|
|
134
|
+
|
|
135
|
+
### The Three-Tier System
|
|
136
|
+
Many games use light/medium/heavy impact tiers:
|
|
137
|
+
- Each tier has distinct animation, sound, and visual effect
|
|
138
|
+
- Creates clear hierarchy of interaction intensity
|
|
139
|
+
|
|
140
|
+
---
|
|
141
|
+
|
|
142
|
+
## 5. Metaphor Metrics
|
|
143
|
+
|
|
144
|
+
### Representation Scale
|
|
145
|
+
|
|
146
|
+
| Level | Description | Example |
|
|
147
|
+
|-------|-------------|---------|
|
|
148
|
+
| **Abstract** | Shapes, no real-world analog | Geometry Wars |
|
|
149
|
+
| **Iconic** | Recognizable but stylized | Mario |
|
|
150
|
+
| **Representational** | Realistic depiction | Uncharted |
|
|
151
|
+
|
|
152
|
+
### Expectation Setting
|
|
153
|
+
|
|
154
|
+
Metaphor creates expectations about:
|
|
155
|
+
- **Weight**: Heavy things should feel heavy
|
|
156
|
+
- **Speed**: Cars should feel faster than people
|
|
157
|
+
- **Friction**: Ice should be slippery
|
|
158
|
+
- **Damage**: Fire should hurt
|
|
159
|
+
|
|
160
|
+
### Treatment Consistency
|
|
161
|
+
Does the visual style match across elements?
|
|
162
|
+
- Mario: All cartoony = unified expectations
|
|
163
|
+
- Mixing realistic and cartoony = confused expectations
|
|
164
|
+
|
|
165
|
+
### Exceed vs Meet Expectations
|
|
166
|
+
- **Exceed**: Feels better than it looks (good)
|
|
167
|
+
- **Meet**: Feels as expected (neutral)
|
|
168
|
+
- **Fail**: Looks better than it feels (bad)
|
|
169
|
+
|
|
170
|
+
---
|
|
171
|
+
|
|
172
|
+
## 6. Rules Metrics
|
|
173
|
+
|
|
174
|
+
### Rules That Affect Feel
|
|
175
|
+
|
|
176
|
+
| Rule Type | Feel Impact |
|
|
177
|
+
|-----------|-------------|
|
|
178
|
+
| **Health/damage** | Risk perception, caution level |
|
|
179
|
+
| **Lives/continues** | Tension, stakes |
|
|
180
|
+
| **Scoring** | Motivation for precision |
|
|
181
|
+
| **Unlocks** | Expanding capability |
|
|
182
|
+
| **Time limits** | Urgency, rushing |
|
|
183
|
+
|
|
184
|
+
### State-Affecting Rules
|
|
185
|
+
|
|
186
|
+
Rules that change available actions:
|
|
187
|
+
- Power-ups granting new moves
|
|
188
|
+
- Damage reducing capabilities
|
|
189
|
+
- Context-sensitive actions
|
|
190
|
+
|
|
191
|
+
### Risk/Reward Rules
|
|
192
|
+
|
|
193
|
+
Rules that create feel through consequence:
|
|
194
|
+
- High-risk maneuvers = high reward
|
|
195
|
+
- Safe play = low reward
|
|
196
|
+
- Creates reason to master difficult techniques
|
|
197
|
+
|
|
198
|
+
---
|
|
199
|
+
|
|
200
|
+
## Using the Metrics
|
|
201
|
+
|
|
202
|
+
### For Analysis
|
|
203
|
+
When analyzing an existing game:
|
|
204
|
+
1. Document each metric category
|
|
205
|
+
2. Note how they interact
|
|
206
|
+
3. Identify what creates the distinctive feel
|
|
207
|
+
|
|
208
|
+
### For Design
|
|
209
|
+
When designing new feel:
|
|
210
|
+
1. Start with desired feel description
|
|
211
|
+
2. Work backward to required metrics
|
|
212
|
+
3. Tune each category to support the goal
|
|
213
|
+
|
|
214
|
+
### For Comparison
|
|
215
|
+
Comparing two games:
|
|
216
|
+
1. Measure same metrics for both
|
|
217
|
+
2. Note where they differ
|
|
218
|
+
3. Correlate differences to feel differences
|
|
219
|
+
|
|
220
|
+
### For Debugging
|
|
221
|
+
When feel is wrong:
|
|
222
|
+
1. Identify the symptom
|
|
223
|
+
2. Check metrics in likely categories
|
|
224
|
+
3. Adjust and test
|
|
225
|
+
|
|
226
|
+
---
|
|
227
|
+
|
|
228
|
+
## Metric Interactions
|
|
229
|
+
|
|
230
|
+
The six metrics don't exist in isolation:
|
|
231
|
+
|
|
232
|
+
- **Input + Response**: How signals become actions
|
|
233
|
+
- **Response + Context**: Whether avatar fits the space
|
|
234
|
+
- **Context + Polish**: Environmental feedback
|
|
235
|
+
- **Polish + Metaphor**: Whether effects match representation
|
|
236
|
+
- **Metaphor + Rules**: Whether game logic fits the world
|
|
237
|
+
- **Rules + Input**: What actions are meaningful
|
|
238
|
+
|
|
239
|
+
The best game feel comes from all six working in harmony.
|
|
@@ -0,0 +1,249 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: level-design
|
|
3
|
+
description: >
|
|
4
|
+
Level design consulting based on "Level Design: Processes and Experiences"
|
|
5
|
+
(CRC Press). Use when helping with spatial game design, environment layout,
|
|
6
|
+
player guidance, pacing, open-world planning, hiding linearity, themed
|
|
7
|
+
environments, procedural vs handmade content, play-personas, or evaluating
|
|
8
|
+
level quality. Covers horror level design, indie game practices, and
|
|
9
|
+
AAA open-world techniques. NOT for coding - focused on design philosophy
|
|
10
|
+
and player spatial experience.
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Level Design Skill
|
|
14
|
+
|
|
15
|
+
A design consulting framework based on "Level Design: Processes and Experiences" edited by Christopher W. Totten (CRC Press, 2017).
|
|
16
|
+
|
|
17
|
+
## Core Philosophy
|
|
18
|
+
|
|
19
|
+
Level design is the **thoughtful execution of gameplay into gamespace for players to dwell in**. It sits at the intersection of programming, design, and art—implementing the game design vision while leading players through experiences without revealing the designer's presence.
|
|
20
|
+
|
|
21
|
+
> "Level designers don't merely create things for players to do. They create situations that invite players to interpret who they are." — Brian Upton
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## The Designer's Core Tasks
|
|
26
|
+
|
|
27
|
+
1. **Guide without forcing** — Lead players through intended experiences while maintaining illusion of freedom
|
|
28
|
+
2. **Teach through space** — Use environment to communicate mechanics, not tutorials
|
|
29
|
+
3. **Control pacing** — Modulate intensity through spatial rhythm and stillness
|
|
30
|
+
4. **Support narrative** — Align levels within overall game progression
|
|
31
|
+
5. **Create consistency** — Establish and honor environmental rules players can rely on
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## Quick Reference: Level Types
|
|
36
|
+
|
|
37
|
+
| Type | Key Considerations |
|
|
38
|
+
|------|-------------------|
|
|
39
|
+
| **Linear** | Hide linearity through visual choice, narrative lures, environmental storytelling |
|
|
40
|
+
| **Open-World** | POI density, anchor locations, subregions, orientation landmarks |
|
|
41
|
+
| **Horror** | Anticipatory play, corners, one-way doors, visible-but-blocked escape |
|
|
42
|
+
| **Procedural** | Horizontal vs vertical integration of handmade content |
|
|
43
|
+
| **Indie/Focused** | Expand single core mechanic through level variation |
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## Hiding Linearity
|
|
48
|
+
|
|
49
|
+
Players must feel in control even when following a predetermined path.
|
|
50
|
+
|
|
51
|
+
### Techniques
|
|
52
|
+
|
|
53
|
+
| Technique | Description |
|
|
54
|
+
|-----------|-------------|
|
|
55
|
+
| **Coerced Progression** | Time pressure, pursuing enemies—no time to question the path |
|
|
56
|
+
| **Environmental Signage** | In-world signs, color coding (Mirror's Edge red) |
|
|
57
|
+
| **NPC Guides** | Companions who lead, escort targets who follow, enemies to chase |
|
|
58
|
+
| **Narrative Lures** | Visible objectives, story hooks that pull forward |
|
|
59
|
+
| **Forced Choice Illusion** | Block one path as player approaches, making "choice" feel organic |
|
|
60
|
+
|
|
61
|
+
### What Breaks the Illusion
|
|
62
|
+
|
|
63
|
+
- Arbitrary locked doors
|
|
64
|
+
- Invisible walls
|
|
65
|
+
- Flimsy barriers (yellow police tape blocking a superhero)
|
|
66
|
+
- Clear artificial constraints without narrative justification
|
|
67
|
+
|
|
68
|
+
**See**: `references/hiding-linearity.md`
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
72
|
+
## Anticipatory Play & Horror Design
|
|
73
|
+
|
|
74
|
+
Horror isn't about jump scares—it's about **dread before the corner**.
|
|
75
|
+
|
|
76
|
+
### The P.T. Framework
|
|
77
|
+
|
|
78
|
+
- **Corners** — Hide what's ahead; players imagine horrors worse than you could show
|
|
79
|
+
- **Ratchet Doors** — One-way progress; can't retreat, must face what's ahead
|
|
80
|
+
- **Valve Doors** — Block progress temporarily; visible state reduces uncertainty about *if* blocked
|
|
81
|
+
- **Visible Escape** — Show impossible exits to amplify feeling of being trapped
|
|
82
|
+
|
|
83
|
+
### Key Principle
|
|
84
|
+
|
|
85
|
+
> "Anticipatory play requires variety—the situation must evolve so players continually reassess. Static horrors become played out."
|
|
86
|
+
|
|
87
|
+
**See**: `references/anticipatory-play.md`
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## Open-World Planning (Burgess Method)
|
|
92
|
+
|
|
93
|
+
Three living documents for large-scale world design:
|
|
94
|
+
|
|
95
|
+
### 1. The World Map
|
|
96
|
+
- Establish setting, scale, subregions
|
|
97
|
+
- Plot anchor locations (story-critical, landmarks)
|
|
98
|
+
- Include orienting features (visible from anywhere)
|
|
99
|
+
- Plan natural boundaries (water, cliffs) over artificial walls
|
|
100
|
+
|
|
101
|
+
### 2. The Master List (Excel)
|
|
102
|
+
- Every location with X/Y coordinates
|
|
103
|
+
- Columns for: designer, quest associations, footprint size, difficulty, encounter type
|
|
104
|
+
- Scatter graph overlay on map image
|
|
105
|
+
- Filter to visualize distribution patterns
|
|
106
|
+
|
|
107
|
+
### 3. The Directory (Wiki)
|
|
108
|
+
- Per-location pages with: status, goals, walkthrough, known issues, to-do
|
|
109
|
+
- Category tags for filtering (by designer, by pass, by type)
|
|
110
|
+
- Living documentation updated throughout development
|
|
111
|
+
|
|
112
|
+
### POI Density
|
|
113
|
+
|
|
114
|
+
The frequency of points of interest defines exploration feel:
|
|
115
|
+
- **High density** = Theme park feel (GTA cities)
|
|
116
|
+
- **Low density** = Vast, sparse exploration (Just Cause countryside)
|
|
117
|
+
- **Non-uniform** = Urban cores dense, rural areas sparse (Fallout 4)
|
|
118
|
+
|
|
119
|
+
**See**: `references/open-world-planning.md`
|
|
120
|
+
|
|
121
|
+
---
|
|
122
|
+
|
|
123
|
+
## Play-Personas
|
|
124
|
+
|
|
125
|
+
Model player behavior before and after implementation.
|
|
126
|
+
|
|
127
|
+
### The Process
|
|
128
|
+
|
|
129
|
+
1. **Analyze mechanics** → Derive high-level behaviors from low-level actions
|
|
130
|
+
2. **Create matrix** → Plot all behavioral combinations (2^n personas)
|
|
131
|
+
3. **Select cast** → Choose 2-3 personas aligned with design vision
|
|
132
|
+
4. **Associate affordances** → Link behaviors to spatial/ludic elements
|
|
133
|
+
5. **Orchestrate** — Modulate which personas are viable throughout level
|
|
134
|
+
6. **Validate** — Use telemetry to confirm players match expected personas
|
|
135
|
+
|
|
136
|
+
### Example: Pac-Man
|
|
137
|
+
|
|
138
|
+
High-level behaviors: Center vs periphery dwelling, early vs late pill eating, linear vs broken paths
|
|
139
|
+
|
|
140
|
+
→ 8 persona combinations including "Fraidy Cat" (periphery, early pills, linear) and "Risk Taker" (center, late pills, broken)
|
|
141
|
+
|
|
142
|
+
**See**: `references/play-personas.md`
|
|
143
|
+
|
|
144
|
+
---
|
|
145
|
+
|
|
146
|
+
## Themed Level Tropes
|
|
147
|
+
|
|
148
|
+
Classic environmental themes with established mechanics and expectations:
|
|
149
|
+
|
|
150
|
+
| Trope | Core Elements | Design Advantages |
|
|
151
|
+
|-------|---------------|-------------------|
|
|
152
|
+
| **Fire/Ice** | Environmental hazards, timing puzzles | Color variety, physics tweaks |
|
|
153
|
+
| **Dungeon/Cavern** | Tileable textures, traps, treasure | Easily repeatable, expected danger |
|
|
154
|
+
| **Factory** | Moving platforms, conveyers, gears | Repurposable mechanics, scalable difficulty |
|
|
155
|
+
| **Jungle** | Vines, branches, water, wildlife | Fluid movement, colorful outdoor |
|
|
156
|
+
| **Spooky** | Atmosphere, surprise, undead | Combines with any theme |
|
|
157
|
+
| **Pirate** | Ships, treasure, melee, water | Action-ready, clear rewards |
|
|
158
|
+
| **Urban** | Verticality, cover, vehicles | Real-world familiarity |
|
|
159
|
+
| **Space Station** | Tech hazards, airlocks, zero-G | Sci-fi dungeon equivalent |
|
|
160
|
+
| **Sewer** | Pipes, rats, rising water | Modern dungeon stand-in |
|
|
161
|
+
|
|
162
|
+
**Mexican Pizza Technique**: Combine two tropes for fresh results (fire + graveyard, jungle + urban ruins)
|
|
163
|
+
|
|
164
|
+
**See**: `references/themed-environments.md`
|
|
165
|
+
|
|
166
|
+
---
|
|
167
|
+
|
|
168
|
+
## Indie Level Design Practices
|
|
169
|
+
|
|
170
|
+
When working with limited resources:
|
|
171
|
+
|
|
172
|
+
| Practice | Description |
|
|
173
|
+
|----------|-------------|
|
|
174
|
+
| **Expand Core Mechanic** | One strong mechanic explored through level variation (VVVVVV) |
|
|
175
|
+
| **Iterative Level Design** | Rapid prototyping, playtest early and often |
|
|
176
|
+
| **Design Modes Not Levels** | Create systems that generate challenge (endless runners) |
|
|
177
|
+
| **Embrace Emergence** | Simple rules, complex interactions |
|
|
178
|
+
| **Object-Oriented Design** | Modular elements that combine predictably |
|
|
179
|
+
|
|
180
|
+
### Qualities of Good Level Design
|
|
181
|
+
|
|
182
|
+
- Maintain flow: challenge without anxiety or boredom
|
|
183
|
+
- Balance freedom with constraints (illusion of control)
|
|
184
|
+
- Enable mastery and emergent solutions
|
|
185
|
+
- Balance risk and reward proportionally
|
|
186
|
+
- Guide without being obvious
|
|
187
|
+
|
|
188
|
+
**See**: `references/indie-practices.md`
|
|
189
|
+
|
|
190
|
+
---
|
|
191
|
+
|
|
192
|
+
## Procedural vs Handmade Integration
|
|
193
|
+
|
|
194
|
+
Two integration models:
|
|
195
|
+
|
|
196
|
+
### Vertical Integration
|
|
197
|
+
Handmade thread runs through procedural content (FTL quest chains, Spelunky secrets)
|
|
198
|
+
|
|
199
|
+
**Best for**: Narrative, puzzle sequences, coherent story beats
|
|
200
|
+
|
|
201
|
+
### Horizontal Integration
|
|
202
|
+
Procedural and handmade content interchangeable in same slot (Dungeon Crawl vaults, URR buildings)
|
|
203
|
+
|
|
204
|
+
**Best for**: Ensuring specific gameplay moments, quality floors
|
|
205
|
+
|
|
206
|
+
### Key Decision
|
|
207
|
+
**Should players see which is which?**
|
|
208
|
+
- **Yes** (DCSS): Visual variety, risk/reward clarity
|
|
209
|
+
- **No** (URR): Quality perception, seamless experience
|
|
210
|
+
|
|
211
|
+
**See**: `references/procedural-handmade.md`
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## Level Evaluation Framework
|
|
216
|
+
|
|
217
|
+
When evaluating a level design:
|
|
218
|
+
|
|
219
|
+
1. **Player Guidance**: Can players find their way without obvious signposting?
|
|
220
|
+
2. **Pacing**: Does intensity modulate appropriately? Are there moments of stillness?
|
|
221
|
+
3. **Teaching**: Does the space teach mechanics before testing them?
|
|
222
|
+
4. **Consistency**: Do environmental rules remain predictable?
|
|
223
|
+
5. **Persona Fit**: Does the level support intended play styles?
|
|
224
|
+
6. **Density**: Is POI distribution appropriate for the experience?
|
|
225
|
+
7. **Linearity Illusion**: Do players feel in control of their path?
|
|
226
|
+
|
|
227
|
+
---
|
|
228
|
+
|
|
229
|
+
## Common Pitfalls
|
|
230
|
+
|
|
231
|
+
| Pitfall | Symptom | Solution |
|
|
232
|
+
|---------|---------|----------|
|
|
233
|
+
| Obvious Rails | Player comments on being "on rails" | Add visual choice, narrative justification |
|
|
234
|
+
| Empty Space | Players comment on emptiness | Increase POI density or justify sparseness |
|
|
235
|
+
| Lost Players | Players wander aimlessly | Add orientation landmarks, environmental cues |
|
|
236
|
+
| Played-Out Scares | Horror stops being scary | Keep threats evolving, limit exposure time |
|
|
237
|
+
| Arbitrary Barriers | Players frustrated by blocked paths | Use narrative-justified or natural boundaries |
|
|
238
|
+
| Tutorial Overload | Players skip to "real game" | Teach through safe early gameplay |
|
|
239
|
+
|
|
240
|
+
---
|
|
241
|
+
|
|
242
|
+
## Key Mantras
|
|
243
|
+
|
|
244
|
+
- **"Hide the designer's hand."** Players should feel they're discovering, not being led.
|
|
245
|
+
- **"Corners are always significant."** Transitions between visible and hidden create anticipation.
|
|
246
|
+
- **"POI density defines feel."** Sparse = vast exploration; dense = action-packed.
|
|
247
|
+
- **"Static threats become furniture."** Evolve dangers or limit exposure.
|
|
248
|
+
- **"The illusion of choice is enough."** Players interpret forced choices as agency.
|
|
249
|
+
- **"Mexican pizza your themes."** Combine familiar tropes for fresh experiences.
|
|
@@ -0,0 +1,223 @@
|
|
|
1
|
+
# Anticipatory Play & Horror Level Design
|
|
2
|
+
|
|
3
|
+
Based on Chapter 9: "P.T. and the Play of Stillness" by Brian Upton.
|
|
4
|
+
|
|
5
|
+
## Core Insight
|
|
6
|
+
|
|
7
|
+
Horror games are scary not because of what happens, but because of what players **imagine** will happen. The best horror level design creates **anticipatory play**—moments of stillness where players' minds race with possibilities.
|
|
8
|
+
|
|
9
|
+
> "We don't win a scary game by overcoming its challenges. We win by allowing it to thwart us."
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## The Five Principles of Anticipatory Play
|
|
14
|
+
|
|
15
|
+
### 1. Invitation
|
|
16
|
+
Create situations where players feel invited to engage with ambiguity. Visible choices with unclear outcomes.
|
|
17
|
+
|
|
18
|
+
### 2. Elaboration
|
|
19
|
+
Choices should have clear, elaborated consequences. If you take path A, you can imagine what might happen.
|
|
20
|
+
|
|
21
|
+
### 3. Predictability
|
|
22
|
+
Some outcomes should be predictable—players need anchors to build expectations from.
|
|
23
|
+
|
|
24
|
+
### 4. Uncertainty
|
|
25
|
+
But not everything predictable. The tension between knowing and not-knowing creates anticipation.
|
|
26
|
+
|
|
27
|
+
### 5. Satisfaction
|
|
28
|
+
Even in horror, players need to feel resolution is possible. "Maybe this is it!" beats "I have no idea."
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## The P.T. Level Analysis
|
|
33
|
+
|
|
34
|
+
### The Layout
|
|
35
|
+
A simple L-shaped corridor, looped infinitely:
|
|
36
|
+
- Entrance door (one-way ratchet)
|
|
37
|
+
- First half: visible, safe-feeling
|
|
38
|
+
- Corner: hides second half
|
|
39
|
+
- Second half: where bad things happen
|
|
40
|
+
- Bathroom door: sometimes open, sometimes locked
|
|
41
|
+
- Exit door (valve): blocks or allows progress
|
|
42
|
+
- Front door: permanently locked—visible escape that's impossible
|
|
43
|
+
|
|
44
|
+
### The Corner
|
|
45
|
+
|
|
46
|
+
The most important element in the entire game.
|
|
47
|
+
|
|
48
|
+
**Why corners work:**
|
|
49
|
+
- Binary: Can't see around them, then can
|
|
50
|
+
- Analog: You can peek, retreat, approach slowly
|
|
51
|
+
- Ambiguous: Anything could be waiting
|
|
52
|
+
- Controllable: Player chooses when to turn
|
|
53
|
+
|
|
54
|
+
> "Just walking toward the corner and making the turn is enough to fill us with dread. It doesn't matter that most of the time nothing at all is waiting."
|
|
55
|
+
|
|
56
|
+
**Corner vs. Door:**
|
|
57
|
+
- Doors are abrupt reveals (open/closed)
|
|
58
|
+
- Corners are gradual reveals (continuous unfolding)
|
|
59
|
+
- Corners allow hesitation; doors demand commitment
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## The Four Doors of P.T.
|
|
64
|
+
|
|
65
|
+
### 1. The Ratchet Door (Entrance/Exit)
|
|
66
|
+
One-way passage. You can only go forward.
|
|
67
|
+
|
|
68
|
+
**Purpose:**
|
|
69
|
+
- Eliminates backtracking as possibility
|
|
70
|
+
- Forces players to face what's ahead
|
|
71
|
+
- Removes problem-solving distraction ("maybe there's another way")
|
|
72
|
+
- Focuses attention entirely on dread
|
|
73
|
+
|
|
74
|
+
> "The implacable barrier of the one-way door behind us removes the temptation to treat our situation as a puzzle to be solved."
|
|
75
|
+
|
|
76
|
+
### 2. The Valve Door
|
|
77
|
+
Blocks progress sometimes. Visually obvious when locked.
|
|
78
|
+
|
|
79
|
+
**Why separate from ratchet:**
|
|
80
|
+
- Clear visual state (locked or open) from anywhere
|
|
81
|
+
- Player knows immediately if blocked
|
|
82
|
+
- No wasted time checking
|
|
83
|
+
- Keeps attention on *what to do*, not *whether blocked*
|
|
84
|
+
|
|
85
|
+
### 3. The Bathroom Door
|
|
86
|
+
Source of specific horrors. Sometimes open, sometimes locked.
|
|
87
|
+
|
|
88
|
+
**The Bathroom as Intensified Corner:**
|
|
89
|
+
- Everything bad comes from here
|
|
90
|
+
- Opening it requires crossing threshold into darkness
|
|
91
|
+
- Game trains players to fear it through early jump scares
|
|
92
|
+
- When forced inside, door closes—player feels they're *hiding*, not *trapped*
|
|
93
|
+
|
|
94
|
+
### 4. The Front Door (Impossible Escape)
|
|
95
|
+
Never opens. Permanently locked. But always visible.
|
|
96
|
+
|
|
97
|
+
**Purpose:**
|
|
98
|
+
- Reminder that escape *exists* as a concept
|
|
99
|
+
- Tantalizingly close, never achievable
|
|
100
|
+
- Amplifies horror by showing what you can't have
|
|
101
|
+
- Without it, players might forget escape is even possible
|
|
102
|
+
|
|
103
|
+
> "If you want players to feel trapped, you need to tantalize them with escape routes."
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## Repetition and Training
|
|
108
|
+
|
|
109
|
+
### The Loop Mechanism
|
|
110
|
+
P.T. sends players through the same corridor repeatedly. At first, this is boring. Then:
|
|
111
|
+
|
|
112
|
+
1. Something changes (jump scare)
|
|
113
|
+
2. Players learn: changes happen in second half
|
|
114
|
+
3. Future loops: anticipation builds before corner
|
|
115
|
+
4. The corridor itself becomes the scare
|
|
116
|
+
|
|
117
|
+
### Training Dread
|
|
118
|
+
Early loops establish expectations:
|
|
119
|
+
- First half = safe
|
|
120
|
+
- Corner = transition
|
|
121
|
+
- Second half = danger
|
|
122
|
+
- Bathroom = source of danger
|
|
123
|
+
|
|
124
|
+
Once trained, the game can scare without doing anything. The player's imagination does the work.
|
|
125
|
+
|
|
126
|
+
---
|
|
127
|
+
|
|
128
|
+
## The "Played Out" Problem
|
|
129
|
+
|
|
130
|
+
### Static Threats Lose Power
|
|
131
|
+
|
|
132
|
+
The fetus in the sink:
|
|
133
|
+
- First glimpse: genuinely horrifying
|
|
134
|
+
- After 30 seconds: unsettling
|
|
135
|
+
- After 2 minutes: just furniture
|
|
136
|
+
|
|
137
|
+
> "The longer we're trapped in the bathroom with it, the less scary the fetus becomes—it's played out as a locus of interpretive play."
|
|
138
|
+
|
|
139
|
+
### Preventing Play-Out
|
|
140
|
+
|
|
141
|
+
1. **Evolve the threat** — Movement, change, escalation
|
|
142
|
+
2. **Limit exposure** — Brief glimpses, then gone
|
|
143
|
+
3. **Keep it ambiguous** — Never fully explained
|
|
144
|
+
4. **Multiple encounters** — Same threat in different contexts
|
|
145
|
+
|
|
146
|
+
### The Lisa Ghost (Done Right)
|
|
147
|
+
- Appears in multiple places
|
|
148
|
+
- Always brief encounters
|
|
149
|
+
- Retreats into darkness before becoming familiar
|
|
150
|
+
- On balcony: visible only if you look up at right moment
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
## Architectural Horror Techniques
|
|
155
|
+
|
|
156
|
+
### Visible/Invisible Balance
|
|
157
|
+
- Balcony: Not in normal sightline, but visible if you look
|
|
158
|
+
- Creates paranoia about unseen spaces
|
|
159
|
+
- When something appears there, retroactive fear ("it was there all along")
|
|
160
|
+
|
|
161
|
+
### Darkness as Canvas
|
|
162
|
+
- Black windows in corridor
|
|
163
|
+
- Dark back of balcony
|
|
164
|
+
- These are blank spaces for imagination to fill
|
|
165
|
+
|
|
166
|
+
### Misdirection Objects
|
|
167
|
+
- Coat rack positioned to look human from corner of eye
|
|
168
|
+
- Cluttered surfaces invite close inspection (reducing peripheral awareness)
|
|
169
|
+
- Environmental details that distract from actual threats
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
## The Metaphysical Claustrophobia
|
|
174
|
+
|
|
175
|
+
Horror games thwart agency deliberately:
|
|
176
|
+
- Movement is slow
|
|
177
|
+
- Aiming is inaccurate
|
|
178
|
+
- Weapons are ineffective
|
|
179
|
+
- Escape is impossible
|
|
180
|
+
|
|
181
|
+
**This creates "possibility space claustrophobia":**
|
|
182
|
+
- Not just trapped in space
|
|
183
|
+
- Trapped in *options*
|
|
184
|
+
- All choices feel bad
|
|
185
|
+
- No good move exists
|
|
186
|
+
|
|
187
|
+
> "You feel trapped in a too-small possibility space. Your options for action all feel dangerous and uncertain."
|
|
188
|
+
|
|
189
|
+
---
|
|
190
|
+
|
|
191
|
+
## Design Framework for Horror Levels
|
|
192
|
+
|
|
193
|
+
### 1. Create Stillness
|
|
194
|
+
Reduce interactive demands. Let players think, imagine, dread.
|
|
195
|
+
|
|
196
|
+
### 2. Hide What's Ahead
|
|
197
|
+
Corners, darkness, closed doors. The unknown is scarier than the known.
|
|
198
|
+
|
|
199
|
+
### 3. Establish Then Subvert
|
|
200
|
+
Train expectations, then break them. But not too often.
|
|
201
|
+
|
|
202
|
+
### 4. Limit Exposure
|
|
203
|
+
Brief glimpses of horror, not extended encounters.
|
|
204
|
+
|
|
205
|
+
### 5. Show Impossible Escape
|
|
206
|
+
Tantalize with exits that can't be used.
|
|
207
|
+
|
|
208
|
+
### 6. Use One-Way Progress
|
|
209
|
+
Eliminate backtracking as an option.
|
|
210
|
+
|
|
211
|
+
### 7. Make Blocking Visible
|
|
212
|
+
If players can't progress, make that clear—don't waste dread on uncertainty about state.
|
|
213
|
+
|
|
214
|
+
### 8. Interpret Actions for Players
|
|
215
|
+
When players can't act, design so their inaction *feels* like a choice.
|
|
216
|
+
|
|
217
|
+
---
|
|
218
|
+
|
|
219
|
+
## Key Principle
|
|
220
|
+
|
|
221
|
+
> "Level design is not merely a matter of arranging things for players to do. It's also a matter of constructing situations that encourage players to hold still while they plan or interpret."
|
|
222
|
+
|
|
223
|
+
The scariest moments in horror games aren't jump scares. They're the seconds before the jump scare that never comes.
|