@jarrodmedrano/claude-skills 1.0.2 → 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/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,181 @@
|
|
|
1
|
+
# Hiding Linearity in Level Design
|
|
2
|
+
|
|
3
|
+
Based on Chapter 10: "The Illusion of Choice" by João Raza and Benjamin Carter.
|
|
4
|
+
|
|
5
|
+
## Core Principle
|
|
6
|
+
|
|
7
|
+
A successful narrative-driven game must sustain the illusion of free will. The designer's job is to hide the contrivances of level design—go down *this* corridor, open *this* door—without making players feel their hand is forced.
|
|
8
|
+
|
|
9
|
+
> "The illusion of motion in film is a trick of the brain that works every time. Hiding the artifice in a game depends on distraction and psychological suggestion."
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Coerced Progression
|
|
14
|
+
|
|
15
|
+
The simplest approach: give players no time to question their path.
|
|
16
|
+
|
|
17
|
+
### Time Pressure
|
|
18
|
+
- Scrolling screens that push players forward (Super Mario Bros. 3 airship levels)
|
|
19
|
+
- Collapsing environments
|
|
20
|
+
- Pursuing enemies (Half-Life 2 opening)
|
|
21
|
+
|
|
22
|
+
### The Call of Duty Stalingrad Technique
|
|
23
|
+
Players queue for ammunition but are pushed onto the battlefield unarmed. Retreat means death from commanding officers. Players are too busy surviving to question direction.
|
|
24
|
+
|
|
25
|
+
**Key insight**: When players are struggling to stay alive, they don't debate whether to backtrack.
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## Environmental Guidance
|
|
30
|
+
|
|
31
|
+
### Signage Systems
|
|
32
|
+
- Painted arrows, floor markings
|
|
33
|
+
- Color-coded paths (Mirror's Edge red highlights)
|
|
34
|
+
- In-world signs that make sense contextually
|
|
35
|
+
|
|
36
|
+
### Half-Life Approach
|
|
37
|
+
Opening sequence has players navigate benign corridors. Security guards provide narrative excuses for blocked paths ("You don't have clearance"). Players follow painted lines to destinations—feeling like navigation, not railroading.
|
|
38
|
+
|
|
39
|
+
### Highway 17 (Half-Life 2)
|
|
40
|
+
The level is literally a road. Players know the destination is at the end of Highway 17. The road always leads forward. Simple, elegant, invisible guidance.
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## NPC-Based Guidance
|
|
45
|
+
|
|
46
|
+
### Escort Missions
|
|
47
|
+
Vulnerable NPCs guide players while needing protection:
|
|
48
|
+
- NPCs unlock doors players cannot (Half-Life retinal scanners)
|
|
49
|
+
- NPCs know the route and lead the way
|
|
50
|
+
- Players feel protective, not led
|
|
51
|
+
|
|
52
|
+
### Companion Characters
|
|
53
|
+
- Alyx Vance (Half-Life 2) guides without feeling like a guide
|
|
54
|
+
- Ellie (The Last of Us) comments when players idle too long or explore pointlessly
|
|
55
|
+
- Companions create social pressure to move forward
|
|
56
|
+
|
|
57
|
+
### The Chase
|
|
58
|
+
Instead of following a guide, chase an enemy:
|
|
59
|
+
- Mirror's Edge: Faith chases an equally-capable enemy
|
|
60
|
+
- Creates urgency without pursuit threat
|
|
61
|
+
- Tarrying means losing the target
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## Narrative Lures
|
|
66
|
+
|
|
67
|
+
### Visual Objectives
|
|
68
|
+
- Distant landmarks that players want to reach
|
|
69
|
+
- Lit areas drawing attention through darkness
|
|
70
|
+
- Unique architecture standing out from environment
|
|
71
|
+
|
|
72
|
+
### Architectural Hierarchy
|
|
73
|
+
Important paths should be:
|
|
74
|
+
- More visually interesting
|
|
75
|
+
- Better lit
|
|
76
|
+
- More open
|
|
77
|
+
- Feature unique elements
|
|
78
|
+
|
|
79
|
+
Dead ends should be:
|
|
80
|
+
- Visually less interesting
|
|
81
|
+
- Darker
|
|
82
|
+
- Narrower
|
|
83
|
+
- More generic
|
|
84
|
+
|
|
85
|
+
### The Door Metaphor
|
|
86
|
+
- Open doors invite
|
|
87
|
+
- Locked doors close off
|
|
88
|
+
- But make sure locked doors have narrative justification
|
|
89
|
+
|
|
90
|
+
---
|
|
91
|
+
|
|
92
|
+
## What Breaks the Illusion
|
|
93
|
+
|
|
94
|
+
### Arbitrary Barriers
|
|
95
|
+
| Bad Example | Why It Fails |
|
|
96
|
+
|-------------|--------------|
|
|
97
|
+
| Yellow police tape | A superhero can't cross tape? |
|
|
98
|
+
| Waist-high walls | Player can jump buildings but not fences |
|
|
99
|
+
| Locked doors without context | Why is this door special? |
|
|
100
|
+
| Invisible walls | No explanation at all |
|
|
101
|
+
|
|
102
|
+
### Better Alternatives
|
|
103
|
+
- Natural barriers (cliffs, water, fire)
|
|
104
|
+
- Narrative barriers (guards, lockdowns, collapsed structures)
|
|
105
|
+
- Overwhelming force (too many enemies in wrong direction)
|
|
106
|
+
- Environmental hazards (radiation, toxic air)
|
|
107
|
+
|
|
108
|
+
---
|
|
109
|
+
|
|
110
|
+
## The Forced Choice
|
|
111
|
+
|
|
112
|
+
When there's only one real option, design the moment so players interpret constraint as choice.
|
|
113
|
+
|
|
114
|
+
### P.T. Bathroom Example
|
|
115
|
+
The player is trapped in the bathroom. The door is mechanically locked—player can't open it. But because the handle rattles as if something's trying to get in, players feel like they're *hiding*, not *trapped*.
|
|
116
|
+
|
|
117
|
+
> "The game creates a situation where there's a particular action we want to take. It then responds as though we had done what we wanted to do, even though there's no way for us to do it."
|
|
118
|
+
|
|
119
|
+
### RPG Main Quests
|
|
120
|
+
Players feel they *choose* to storm the castle and rescue the princess. In reality, there's no other option. The illusion of agency is enough.
|
|
121
|
+
|
|
122
|
+
---
|
|
123
|
+
|
|
124
|
+
## Branching Illusions
|
|
125
|
+
|
|
126
|
+
### The Fork Technique
|
|
127
|
+
1. Present players with two paths
|
|
128
|
+
2. As player approaches one, block it (enemies appear, door locks, explosion)
|
|
129
|
+
3. Player "chooses" the remaining path
|
|
130
|
+
4. Both paths lead to the same destination anyway
|
|
131
|
+
|
|
132
|
+
### The Hub-and-Spoke
|
|
133
|
+
Players can explore "freely" but:
|
|
134
|
+
- All paths return to a central hub
|
|
135
|
+
- True progress gates require specific items/actions
|
|
136
|
+
- Exploration feels optional but forward path is singular
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## Audio and Attention Cues
|
|
141
|
+
|
|
142
|
+
### Sound Design
|
|
143
|
+
- Distant sounds draw attention toward objectives
|
|
144
|
+
- Ambient audio creates "safe" vs "dangerous" zones
|
|
145
|
+
- Music intensifies toward correct paths
|
|
146
|
+
|
|
147
|
+
### Lighting
|
|
148
|
+
- Brighter areas feel more inviting
|
|
149
|
+
- Players naturally move toward light
|
|
150
|
+
- Use darkness to discourage wrong paths
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
## Testing Linearity Hiding
|
|
155
|
+
|
|
156
|
+
### Player Observation
|
|
157
|
+
Watch for:
|
|
158
|
+
- Players commenting on feeling "on rails"
|
|
159
|
+
- Players attempting to go backward or off-path
|
|
160
|
+
- Frustration at barriers
|
|
161
|
+
- Questions about why paths are blocked
|
|
162
|
+
|
|
163
|
+
### Successful Hiding
|
|
164
|
+
Players should:
|
|
165
|
+
- Feel like they're exploring
|
|
166
|
+
- Not notice most blocked paths
|
|
167
|
+
- Accept narrative barriers without question
|
|
168
|
+
- Report feeling "in control"
|
|
169
|
+
|
|
170
|
+
---
|
|
171
|
+
|
|
172
|
+
## Summary Framework
|
|
173
|
+
|
|
174
|
+
1. **Time pressure** eliminates questioning
|
|
175
|
+
2. **Environmental cues** guide without forcing
|
|
176
|
+
3. **NPCs** provide social and narrative direction
|
|
177
|
+
4. **Narrative lures** pull players forward
|
|
178
|
+
5. **Forced choices** feel like agency
|
|
179
|
+
6. **Barriers need justification**—narrative or natural
|
|
180
|
+
|
|
181
|
+
The goal isn't to give players freedom—it's to make them *feel* free while experiencing your intended sequence.
|
|
@@ -0,0 +1,286 @@
|
|
|
1
|
+
# Level Design Practices for Independent Games
|
|
2
|
+
|
|
3
|
+
Based on Chapter 6: "Level Design Practices for Independent Games" by Fares Kayali and Josef Ortner.
|
|
4
|
+
|
|
5
|
+
## The Contemporary Retro Game
|
|
6
|
+
|
|
7
|
+
Independent games often feature:
|
|
8
|
+
- 2D content with retro aesthetic
|
|
9
|
+
- Strong, innovative core mechanics
|
|
10
|
+
- Modern, focused gameplay
|
|
11
|
+
- Limited team/budget resources
|
|
12
|
+
|
|
13
|
+
The level designer operates at the intersection of programming, design, and art—distilling ideas into workable games while leading players through experiences without revealing the designer's presence.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Qualities of Good Level Design
|
|
18
|
+
|
|
19
|
+
### 1. Maintain Flow
|
|
20
|
+
Balance difficulty and challenge. Avoid:
|
|
21
|
+
- **Anxiety** (too hard)
|
|
22
|
+
- **Boredom** (too easy)
|
|
23
|
+
|
|
24
|
+
Keep players in the "flow channel."
|
|
25
|
+
|
|
26
|
+
### 2. Balance Freedom and Constraints
|
|
27
|
+
Give players the illusion of control while ensuring:
|
|
28
|
+
- Continuity
|
|
29
|
+
- Fluent play
|
|
30
|
+
- Guided experience
|
|
31
|
+
|
|
32
|
+
### 3. Enable Mastery and Emergence
|
|
33
|
+
- Allow recombination of game elements
|
|
34
|
+
- Support elusive mastery
|
|
35
|
+
- Create emergent gameplay
|
|
36
|
+
- Incentivize replay
|
|
37
|
+
|
|
38
|
+
### 4. Balance Risk and Reward
|
|
39
|
+
Every level should include:
|
|
40
|
+
- Easier options (lower rewards)
|
|
41
|
+
- Harder options (higher rewards)
|
|
42
|
+
- Proportional reward scaling
|
|
43
|
+
|
|
44
|
+
### 5. Drive Narrative
|
|
45
|
+
Ensure individual levels align with:
|
|
46
|
+
- Overall game progression
|
|
47
|
+
- Asset revelation schedule
|
|
48
|
+
- Story pacing
|
|
49
|
+
|
|
50
|
+
### 6. Guide the Player
|
|
51
|
+
Use environmental cues:
|
|
52
|
+
- Mirror's Edge: Red marks climbable objects
|
|
53
|
+
- Lighting draws attention
|
|
54
|
+
- Architecture suggests paths
|
|
55
|
+
|
|
56
|
+
---
|
|
57
|
+
|
|
58
|
+
## Five Level Design Practices
|
|
59
|
+
|
|
60
|
+
### 1. Expand on Strong Core Mechanics
|
|
61
|
+
|
|
62
|
+
**Example:** VVVVVV
|
|
63
|
+
> "You cannot jump—instead, you reverse your own gravity at the press of a button. The game focuses on playing with this mechanic in a variety of interesting ways."
|
|
64
|
+
|
|
65
|
+
**The approach:**
|
|
66
|
+
- One simple, strong core mechanic
|
|
67
|
+
- Entire game explores variations
|
|
68
|
+
- Constraints force creativity
|
|
69
|
+
- Each level finds new applications
|
|
70
|
+
|
|
71
|
+
**VVVVVV specifics:**
|
|
72
|
+
- Input: Left, right, flip gravity
|
|
73
|
+
- Exploration: Moving platforms from below, ceiling walking, gravity timing puzzles
|
|
74
|
+
- Difficulty through variety, not complexity
|
|
75
|
+
|
|
76
|
+
**Design principle:** Constrain to create depth. Less mechanics = more exploration of each.
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
### 2. Iterative Level Design
|
|
81
|
+
|
|
82
|
+
**The Process:**
|
|
83
|
+
1. Rapid prototyping
|
|
84
|
+
2. Playtest early
|
|
85
|
+
3. Iterate based on feedback
|
|
86
|
+
4. Repeat until fun
|
|
87
|
+
|
|
88
|
+
**Key insight:** Level design should happen *alongside* mechanic development, not after.
|
|
89
|
+
|
|
90
|
+
**Radio Flare Redux case:**
|
|
91
|
+
- Music-based game (each level is a song)
|
|
92
|
+
- Level design tightly connected to music
|
|
93
|
+
- All events quantized to beat
|
|
94
|
+
- Level files read like musical scores
|
|
95
|
+
|
|
96
|
+
**Lesson learned:** Starting level design late meant:
|
|
97
|
+
- Fewer enemy patterns
|
|
98
|
+
- Less variety
|
|
99
|
+
- Good ideas lost in the process
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
### 3. Design Game Modes, Not Levels
|
|
104
|
+
|
|
105
|
+
**Example:** Hue Shift
|
|
106
|
+
|
|
107
|
+
**Original approach:** Designed levels with completion goals
|
|
108
|
+
- Problem: Constant player speed meant maximum high score
|
|
109
|
+
- Result: No motivation to improve
|
|
110
|
+
|
|
111
|
+
**New approach:** Endless, self-generated level
|
|
112
|
+
- Play until mistake
|
|
113
|
+
- No maximum score
|
|
114
|
+
- Active high score competition
|
|
115
|
+
|
|
116
|
+
**Implementation:**
|
|
117
|
+
- 50 predefined blocks (easy/medium/hard)
|
|
118
|
+
- Random combination
|
|
119
|
+
- Early blocks easy, difficulty increases
|
|
120
|
+
- Each block designed to connect to any other
|
|
121
|
+
|
|
122
|
+
**Benefits:**
|
|
123
|
+
- Short development time
|
|
124
|
+
- High replay value
|
|
125
|
+
- Player motivation through randomization
|
|
126
|
+
|
|
127
|
+
**The trade-off:** Some frustration from difficult random combinations, but hope for better luck keeps players trying.
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
### 4. Sandboxes and Emergent Gameplay
|
|
132
|
+
|
|
133
|
+
**Definition:** Create systems that generate interesting situations rather than authored content.
|
|
134
|
+
|
|
135
|
+
**Elements:**
|
|
136
|
+
- Simple, consistent rules
|
|
137
|
+
- Interacting systems
|
|
138
|
+
- Player creativity enabled
|
|
139
|
+
- Unpredictable outcomes
|
|
140
|
+
|
|
141
|
+
**Level design role:**
|
|
142
|
+
- Provide the sandbox
|
|
143
|
+
- Set initial conditions
|
|
144
|
+
- Let emergence happen
|
|
145
|
+
|
|
146
|
+
**Example scenarios:**
|
|
147
|
+
- Physics puzzles with multiple solutions
|
|
148
|
+
- Enemy AI with emergent behaviors
|
|
149
|
+
- Environmental interactions
|
|
150
|
+
|
|
151
|
+
---
|
|
152
|
+
|
|
153
|
+
### 5. Object-Oriented Level Design
|
|
154
|
+
|
|
155
|
+
**Concept:** Modular elements that combine predictably.
|
|
156
|
+
|
|
157
|
+
**Implementation:**
|
|
158
|
+
- Design reusable "objects" (platforms, enemies, hazards)
|
|
159
|
+
- Define clear interaction rules
|
|
160
|
+
- Combine objects to create levels
|
|
161
|
+
- Objects work regardless of combination
|
|
162
|
+
|
|
163
|
+
**Benefits:**
|
|
164
|
+
- Rapid level creation
|
|
165
|
+
- Consistent player expectations
|
|
166
|
+
- Easy difficulty scaling
|
|
167
|
+
- Efficient development
|
|
168
|
+
|
|
169
|
+
**Hue Shift application:**
|
|
170
|
+
- 50 blocks with 2-6 platforms each
|
|
171
|
+
- Any block connects to any other
|
|
172
|
+
- Combination rules ensure solvability
|
|
173
|
+
|
|
174
|
+
---
|
|
175
|
+
|
|
176
|
+
## Core Mechanics Definition
|
|
177
|
+
|
|
178
|
+
### Järvinen's Definition
|
|
179
|
+
> "Game mechanics are the means through which the players carry out certain rule-based actions aiming at the game goals."
|
|
180
|
+
|
|
181
|
+
### MDA Framework
|
|
182
|
+
> "Mechanics are the various actions, behaviors and control mechanisms afforded to the player within a game context."
|
|
183
|
+
|
|
184
|
+
### Core Mechanics
|
|
185
|
+
The essential play activity performed repeatedly throughout the game.
|
|
186
|
+
|
|
187
|
+
**VVVVVV core mechanic:** Gravity reversal
|
|
188
|
+
**Pac-Man core mechanics:** Movement, eating, avoiding
|
|
189
|
+
|
|
190
|
+
---
|
|
191
|
+
|
|
192
|
+
## Rhythm and Music Integration
|
|
193
|
+
|
|
194
|
+
### Radio Flare Redux Approach
|
|
195
|
+
|
|
196
|
+
**Process:**
|
|
197
|
+
1. Listen to song repeatedly
|
|
198
|
+
2. Identify sections, themes, recurring elements
|
|
199
|
+
3. Quantize events to beat
|
|
200
|
+
4. Match level structure to musical structure
|
|
201
|
+
|
|
202
|
+
**Level file structure:**
|
|
203
|
+
- Time indexed by bars and beats
|
|
204
|
+
- Events synchronized to rhythm
|
|
205
|
+
- Sound effects blend with music
|
|
206
|
+
|
|
207
|
+
**Benefits:**
|
|
208
|
+
- Tight audiovisual sync
|
|
209
|
+
- Immersive experience
|
|
210
|
+
- Clear structure
|
|
211
|
+
|
|
212
|
+
**Drawbacks:**
|
|
213
|
+
- Linear, static experience
|
|
214
|
+
- Limited emergent gameplay
|
|
215
|
+
- Late development constraints
|
|
216
|
+
|
|
217
|
+
---
|
|
218
|
+
|
|
219
|
+
## Resource Constraints as Design Tools
|
|
220
|
+
|
|
221
|
+
### Limited Time
|
|
222
|
+
- Focus on core mechanic
|
|
223
|
+
- Cut feature scope, not quality
|
|
224
|
+
- Iterative refinement over breadth
|
|
225
|
+
|
|
226
|
+
### Limited Budget
|
|
227
|
+
- Retro aesthetics require less art
|
|
228
|
+
- Procedural generation reduces content needs
|
|
229
|
+
- Modular design maximizes asset reuse
|
|
230
|
+
|
|
231
|
+
### Limited Team
|
|
232
|
+
- Designer as programmer, artist, level designer
|
|
233
|
+
- Communication overhead reduced
|
|
234
|
+
- Vision consistency easier
|
|
235
|
+
|
|
236
|
+
---
|
|
237
|
+
|
|
238
|
+
## Player Expectation Management
|
|
239
|
+
|
|
240
|
+
### The Carrot on a Stick
|
|
241
|
+
Always provide clear incentive for forward progress.
|
|
242
|
+
|
|
243
|
+
### Subverting Expectations
|
|
244
|
+
Consciously fulfill *and* subvert player expectations when designing levels.
|
|
245
|
+
|
|
246
|
+
**Balance:**
|
|
247
|
+
- Enough fulfillment for comfort
|
|
248
|
+
- Enough subversion for surprise
|
|
249
|
+
- Pattern recognition rewarded
|
|
250
|
+
- Complacency punished
|
|
251
|
+
|
|
252
|
+
---
|
|
253
|
+
|
|
254
|
+
## Contemporary vs Retro
|
|
255
|
+
|
|
256
|
+
### Retro Elements
|
|
257
|
+
- Low-end graphics
|
|
258
|
+
- Limited input (2-3 buttons)
|
|
259
|
+
- Clear rules
|
|
260
|
+
- High difficulty
|
|
261
|
+
- Chunked level design
|
|
262
|
+
|
|
263
|
+
### Contemporary Elements
|
|
264
|
+
- Short session times (5-8 minutes)
|
|
265
|
+
- Procedural generation
|
|
266
|
+
- Endless modes
|
|
267
|
+
- Social features (leaderboards)
|
|
268
|
+
- Mobile-friendly design
|
|
269
|
+
|
|
270
|
+
### The Synthesis
|
|
271
|
+
Contemporary retro games:
|
|
272
|
+
- Look old
|
|
273
|
+
- Play modern
|
|
274
|
+
- Respect player time
|
|
275
|
+
- Enable mastery
|
|
276
|
+
|
|
277
|
+
---
|
|
278
|
+
|
|
279
|
+
## Summary
|
|
280
|
+
|
|
281
|
+
1. **Core mechanic first** — Build everything on a strong foundation
|
|
282
|
+
2. **Iterate constantly** — Playtest early and often
|
|
283
|
+
3. **Consider endless modes** — Sometimes no levels is better
|
|
284
|
+
4. **Embrace emergence** — Systems create more than content
|
|
285
|
+
5. **Design modularly** — Object-oriented thinking speeds development
|
|
286
|
+
6. **Constraints enable creativity** — Limited resources force focus
|