@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.
Files changed (30) hide show
  1. package/.claude/skills/game-design-theory/SKILL.md +102 -0
  2. package/.claude/skills/game-design-theory/design-principles.md +308 -0
  3. package/.claude/skills/game-design-theory/gameplay-elements.md +213 -0
  4. package/.claude/skills/game-design-theory/player-psychology.md +175 -0
  5. package/.claude/skills/game-design-theory/playtesting.md +321 -0
  6. package/.claude/skills/game-design-theory/storytelling.md +219 -0
  7. package/.claude/skills/game-feel/SKILL.md +305 -0
  8. package/.claude/skills/game-feel/references/adsr-tuning.md +271 -0
  9. package/.claude/skills/game-feel/references/classic-profiles.md +279 -0
  10. package/.claude/skills/game-feel/references/perception-thresholds.md +160 -0
  11. package/.claude/skills/game-feel/references/polish-effects.md +246 -0
  12. package/.claude/skills/game-feel/references/simulation-recipes.md +306 -0
  13. package/.claude/skills/game-feel/references/six-metrics.md +239 -0
  14. package/.claude/skills/level-design/SKILL.md +249 -0
  15. package/.claude/skills/level-design/anticipatory-play.md +223 -0
  16. package/.claude/skills/level-design/hiding-linearity.md +181 -0
  17. package/.claude/skills/level-design/indie-practices.md +286 -0
  18. package/.claude/skills/level-design/open-world-planning.md +294 -0
  19. package/.claude/skills/level-design/play-personas.md +240 -0
  20. package/.claude/skills/level-design/procedural-handmade.md +271 -0
  21. package/.claude/skills/level-design/themed-environments.md +264 -0
  22. package/README.md +9 -1
  23. package/package.json +3 -1
  24. package/scripts/install.js +16 -1
  25. package/templates/github-actions/README.md +36 -0
  26. /package/.claude/{commands/design-review → agents}/design-review-agent.md +0 -0
  27. /package/.claude/{commands/code-review → agents}/pragmatic-code-review-subagent.md +0 -0
  28. /package/{.claude/commands/code-review → templates/github-actions}/claude-code-review-custom.yml +0 -0
  29. /package/{.claude/commands/code-review → templates/github-actions}/claude-code-review.yml +0 -0
  30. /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.