name	emergent-gameplay-design
description	Simple rules creating complex, player-discovered behaviors and emergent gameplay

Emergent Gameplay Design: Simple Rules → Complex Outcomes

Purpose

This is the FOUNDATIONAL skill for the systems-as-experience skillpack. It teaches how to design systems where simple rules create complex, surprising, player-discovered behaviors—the essence of emergent gameplay.

Every other skill in this pack applies emergence principles to specific domains (systemic level design, dynamic narratives, player-driven economies). Master this foundational skill first.

When to Use This Skill

Use this skill when:

Designing immersive sims (Deus Ex, Prey, Dishonored style)
Building sandbox games with creative player expression
Creating simulation-driven games (Dwarf Fortress, RimWorld, Minecraft)
Designing combat/stealth/puzzle systems with multiple solutions
Players should discover tactics rather than follow instructions
You want replayability through emergent variety, not authored content
Systems should interact in surprising ways
The goal is "possibility space", not scripted experiences

ALWAYS use this skill BEFORE implementing emergent systems. Retrofitting emergence into scripted systems is nearly impossible.

Core Philosophy: Emergence as Design Goal

The Fundamental Truth

Emergent gameplay happens when simple orthogonal mechanics interact to create complex outcomes that surprise even the designer.

The goal is NOT to script every player action. The goal is to create a "possibility space" where players discover their own solutions through experimentation.

Emergence vs Scripting: The Spectrum

SCRIPTED                           HYBRID                          EMERGENT
│                                    │                                 │
│ Designer controls outcomes         │ Designer sets boundaries       │ Designer sets rules
│ Players follow intended path       │ Players choose from options    │ Players discover possibilities
│ Low replayability                  │ Medium replayability           │ High replayability
│ Predictable                        │ Somewhat variable              │ Surprising
│ High authoring cost                │ Medium authoring cost          │ Low authoring cost (per hour of play)
│                                    │                                 │
Examples:                          Examples:                        Examples:
- Uncharted setpieces              - Breath of the Wild shrines     - Minecraft redstone
- Scripted boss phases             - XCOM tactical combat           - Dwarf Fortress simulation
- QTE sequences                    - Hitman contracts               - Prey Typhon powers
- Linear puzzles                   - Portal 2 (limited toolset)     - Noita wand crafting

Your job is to choose where on this spectrum your design should live, and understand the tradeoffs.

CORE CONCEPT #1: Orthogonal Mechanics (The Multiplication Principle)

What is Orthogonality?

Orthogonal mechanics are mechanics that:

Operate on DIFFERENT dimensions of the simulation
Don't overlap in function
MULTIPLY possibilities when combined (not add them)

Non-Orthogonal (Bad) Example

Mechanics:
- Fire spell (damages enemies)
- Ice spell (damages enemies)
- Lightning spell (damages enemies)
- Poison spell (damages enemies)

Problem: All four do the same thing (damage).
Possibility count: 4 (just 4 different ways to deal damage)
Result: Redundant complexity, no emergence

Orthogonal (Good) Example

Mechanics:
- Fire: Creates persistent burning (area denial, light source, spreads)
- Ice: Changes surface friction (creates slippery surfaces, brittleness)
- Electricity: Conducts through materials (chains, disables electronics)
- Magnetism: Attracts/repels metal objects (moves objects, shields)

Why orthogonal: Each affects DIFFERENT simulation properties
Possibility count: 4! = 24 combinations (way more than 4)
Result: Combinatorial explosion of tactics

The Multiplication Test

When adding a new mechanic, ask:

"Does this mechanic create NEW interactions with existing mechanics, or does it duplicate existing interactions?"

Multiplication (orthogonal):

3 mechanics with 5 interactions each = 15 total interactions
Add 4th mechanic: Now 4 × 5 = 20 interactions (33% increase from 25% mechanic increase)

Addition (non-orthogonal):

3 damage types + 1 damage type = 4 damage types (linear growth)
No new interactions, just more of the same

Real-World Example: Breath of the Wild

Orthogonal Mechanics:

Fire: Burns wood, creates updrafts, melts ice, lights torches
Ice: Freezes water, creates platforms, brittleness when struck
Electricity: Conducts through metal/water, stuns enemies, magnetizes metal
Wind: Pushes objects, propels glider, affects projectiles
Stasis: Freezes object, stores kinetic energy
Magnesis: Moves metal objects

Why it works:

Each mechanic affects different simulation properties
6 mechanics create ~30 meaningful interactions
Players discover combinations: "Freeze enemy → strike → shatter damage bonus"

Non-Orthogonal Anti-Pattern:

If BotW had "Ice Sword (freezes), Fire Sword (burns), Thunder Sword (shocks)" = 3 mechanics, 0 interactions
Instead: Weapons can conduct elements from environment = infinite combinations

Design Process for Orthogonality

List simulation properties (not mechanics):
- Position, velocity, friction, flammability, conductivity, brittleness, density, temperature, magnetism, opacity, etc.
Design mechanics that affect DIFFERENT properties:
- Fire mechanic → changes flammability state
- Ice mechanic → changes friction coefficient
- Electricity mechanic → uses conductivity property
- Magnet mechanic → uses magnetism property
Test for overlap:
- Do any two mechanics affect the same property in the same way?
- If yes, one is redundant or they should be combined
Verify multiplication:
- Count interactions: Mechanic A + B should create 2 new interactions (A→B, B→A)
- If it doesn't, they're not orthogonal

Common Orthogonality Failures

❌ Damage type redundancy: Multiple attack types that all just "do damage" ❌ Movement ability redundancy: Double jump, dash, and teleport all "move faster" ❌ Resource redundancy: Mana, stamina, and energy all "limit ability usage"

✅ Instead:

Damage types affect different material properties (fire burns wood, electricity conducts, ice shatters)
Movement abilities affect different traversal contexts (jump = vertical, dash = speed + invincibility, teleport = through walls)
Resources gate different gameplay loops (mana = magic, stamina = physics actions, energy = time manipulation)

CORE CONCEPT #2: Interaction Matrices (The Possibility Map)

What is an Interaction Matrix?

An interaction matrix explicitly documents what happens when every mechanic/object/element combines with every other.

It's the MOST IMPORTANT TOOL for emergent design because:

Forces you to design interactions, not just mechanics
Reveals gaps (missing interactions)
Counts total possibilities (complexity budget)
Prevents dominant strategies (you can see imbalances)

Basic Interaction Matrix Format

                Fire    Water   Electric  Explosive  Oil    Glass
Fire            ✓       X        ✓         ✓         ✓      ✓
Water           X       ✓        ✓         X         X      X
Electric        ✓       ✓        ✓         ✓         ✓      ✓
Explosive       ✓       X        ✓         ✓         ✓      ✓
Oil             ✓       X        X         ✓         ✓      X
Glass           ✓       X        ✓         ✓         X      ✓

Legend:

✓ = Interesting interaction exists
X = No interaction (or neutral)

Detailed Interaction Matrix (With Rules)

For each ✓, document the rule:

Fire + Water = X (fire extinguished, steam created if hot enough)
Fire + Electric = ✓ (electric ignites fire if flammable material present)
Fire + Explosive = ✓ (explosive detonates, creates larger fire)
Fire + Oil = ✓ (oil ignites, fire spreads faster)
Fire + Glass = ✓ (glass shatters from thermal shock if cooled rapidly)

Water + Electric = ✓ (water conducts electricity, area-of-effect damage)
Water + Explosive = X (water dampens explosive, reduces blast radius)
Water + Oil = X (oil floats, doesn't mix)
Water + Glass = X (no interaction)

Electric + Explosive = ✓ (electric detonates explosive remotely)
Electric + Oil = ✓ (oil is non-conductive, insulates against electric)
Electric + Glass = ✓ (glass is insulator, blocks electric conduction)

...etc for all combinations

Interaction Count Analysis

For N mechanics, maximum interactions = N × (N-1) / 2

Examples:

3 mechanics = 3 interactions possible
6 mechanics = 15 interactions possible
10 mechanics = 45 interactions possible

Design goal: Implement 60-80% of possible interactions. 100% is over-designed, <50% means mechanics don't interact enough.

Real-World Example: Noita

Noita has ~30 materials with interaction matrix:

Sample interactions (simplified):
- Water + Lava = Steam + Obsidian
- Oil + Fire = Burning Oil + Fire Spread
- Acid + Metal = Dissolved Metal
- Polymorphine + Any Creature = Random Creature
- Teleportatium + Any Object = Teleports Object
- Worm Blood + Worm = Pacified Worm

Why it works:

30 materials × 30 materials = 900 possible interactions
~600 actually implemented (67% coverage)
Players discover interactions through experimentation
Entire game is interaction matrix + physics

Failure mode: If only 10% of interactions implemented, systems feel disconnected.

Design Process for Interaction Matrices

List all mechanics/objects/elements (rows and columns)
Fill in diagonal (self-interactions):
- Fire + Fire = bigger fire (positive feedback)
- Water + Water = more water (accumulation)
- Explosive + Explosive = chain reaction
Fill in obvious interactions first:
- Fire + Water = extinguish (classic opposition)
- Electric + Water = conduction (well-known physics)
Fill in creative interactions:
- Oil + Glass = slippery glass surface
- Magnetism + Explosive = sticky mine (attach to metal)
Identify gaps:
- Is Fire interacting with <60% of other elements?
- Are some elements isolated (no interactions)?
Prune redundant interactions:
- If Fire + Ice and Fire + Water do the same thing, combine them
Balance interaction density:
- Some elements are "hub elements" (interact with everything): Electric, Fire
- Some elements are "niche elements" (few interactions): Glass, specific chemicals
- This is OK! Creates strategy depth.

Common Interaction Matrix Failures

❌ Sparse matrix: Only 20% of interactions implemented (systems feel disconnected) ❌ Diagonal dominance: Elements only interact with themselves (no emergence) ❌ Binary interactions: A+B does something, but A+B+C doesn't add depth (no cascades) ❌ Missing documentation: Interactions exist in code but not design docs (can't reason about them)

✅ Instead:

Target 60-80% coverage
Design off-diagonal interactions explicitly
Document 3+ element chains
Make matrix accessible to entire team

CORE CONCEPT #3: Feedback Loops (The Stabilization Principle)

What are Feedback Loops?

Feedback loops determine whether emergence is:

Stable (interesting equilibrium)
Explosive (runaway chaos)
Dampened (boring stagnation)

Every emergent system has feedback loops. Your job is to balance them.

Positive Feedback (Runaway Growth)

Positive feedback: Output amplifies input, creating exponential growth

Examples:

Fire spreads to adjacent tiles → more fire → spreads more → runaway
Player gets powerful weapon → kills enemies easier → gets more loot → gets more powerful → trivializes game
More creatures → more food → more reproduction → more creatures → overpopulation

When to use positive feedback:

Creating tension: "Fire is spreading, act fast!"
Snowball effects: "If you succeed early, you dominate"
Epic moments: "Chain reaction destroyed entire level"

Danger: Without negative feedback, positive feedback makes systems unplayable.

Negative Feedback (Self-Correction)

Negative feedback: Output reduces input, creating stability

Examples:

Fire spreads → consumes fuel → less fuel → fire slows → stops
Player is powerful → faces harder enemies → dies more → becomes appropriately leveled
Many creatures → consume all food → starvation → population crashes → equilibrium

When to use negative feedback:

Preventing runaway states: "Fire eventually stops"
Rubber-banding difficulty: "Losing players get help, winning players face challenges"
Resource management: "Use it all → scarcity → conservation"

Danger: Too much negative feedback creates stagnation (nothing ever changes).

Balanced Feedback (Dynamic Equilibrium)

Best emergent systems have BOTH:

Example: Fire Spread System

Positive feedback: Fire spreads to adjacent flammable tiles (growth)
Negative feedback: Fire consumes fuel, reducing flammability (depletion)
Negative feedback: Smoke reduces oxygen, slowing spread (environmental limit)
Negative feedback: Player can extinguish with water (player intervention)

Result: Fire creates tension (grows), but eventually stabilizes or stops. Player has agency to influence equilibrium.

Real-World Example: Dwarf Fortress Ecosystem

Positive Feedback:

More dwarves → more labor → more food production → supports more dwarves
Cats reproduce → more cats → more hunting → more food for cats → more reproduction

Negative Feedback:

More dwarves → more food consumption → eventually exceeds production → starvation
Too many cats → overhunted vermin → no food for cats → cats starve → population crashes
Player must manage breeding → controls population → prevents runaway

Result: Dynamic equilibrium where player must actively manage systems.

Feedback Loop Analysis Process

Identify loops:
- Trace paths: A increases B, B increases C, C increases A (positive loop)
- Trace negative paths: A increases B, B decreases A (negative loop)
Classify each loop:
- Positive (reinforcing): →+→+→+ or →−→−→+ (even number of negatives)
- Negative (dampening): →+→− or →−→+→− (odd number of negatives)
Count loop strength:
- Strong positive + weak negative = runaway (bad)
- Strong negative + weak positive = stagnation (bad)
- Balanced = dynamic equilibrium (good)
Add dampening to strong positive loops:
- Fuel consumption limits fire spread
- Enemy reinforcements have delay (time-based negative feedback)
- Loot quality diminishes with player power (rubber-banding)
Add amplification to strong negative loops:
- Player abilities counter stabilization (keeps things dynamic)
- Random events perturb equilibrium (prevents stagnation)

Common Feedback Loop Failures

❌ Runaway snowball: Player who gets early lead trivializes game ❌ Stagnation: Systems stabilize into unchanging state (boring) ❌ Rubber-band overcompensation: Losing player gets so much help they always win ❌ Oscillation: Systems wildly swing between extremes (no control)

✅ Instead:

Design both positive and negative loops
Test for runaway conditions (what if player does X repeatedly?)
Add player agency (player can influence loops)
Tune time constants (slow loops = strategy, fast loops = tactics)

CORE CONCEPT #4: Cascade Chains (The Surprise Principle)

What are Cascade Chains?

Cascade chains are sequences where one action triggers a second, which triggers a third, creating surprising outcomes.

Formula: A → B → C → D

The longer the chain, the more surprising the outcome (but also harder to predict).

Cascade Length vs Predictability

Chain Length 1 (Deterministic):
- Shoot enemy → enemy dies
- Result: Completely predictable

Chain Length 2 (Tactical):
- Shoot barrel → barrel explodes → enemy dies
- Result: Predictable with planning

Chain Length 3 (Strategic):
- Shoot light → darkness → enemy can't see → you flank
- Result: Requires setup and understanding

Chain Length 4+ (Emergent):
- Shoot chandelier → falls → breaks floor → water floods → electrified water → multiple enemies shocked → domino effect
- Result: Surprising even to designer

Design goal: Enable chains of 3-5 steps. Longer chains are rare, shorter chains are predictable.

Cascade Dampening (Preventing Infinite Chains)

Without dampening, cascades become infinite:

Explosion hits barrel → barrel explodes → hits another barrel → explodes → infinite chain

Dampening mechanisms:

Energy loss: Each step reduces effect (explosion damage decreases with distance)
Probability decay: Each step has chance to stop (80% → 64% → 51% → 41%)
Cooldowns: Same object can't trigger twice in short time
Fuel depletion: Chain stops when resources exhausted

Real-World Example: Breath of the Wild

Common Cascade:

Player shoots fire arrow at grass
Grass burns
Fire creates updraft
Updraft lifts player in paraglider
Player gains altitude to reach high area

Why it works:

5-step chain
Each step uses different mechanic (projectile → fire → air → movement → traversal)
Dampening: Fire eventually stops, updraft dissipates
Player-initiated: Cascade is deliberate, not random

Anti-pattern: If fire never stopped spreading, entire world would burn (no dampening).

Cascade Design Process

Design individual mechanics with clear inputs/outputs:
- Fire: Input = ignition source, Output = heat + light
- Water: Input = container break, Output = fluid spread
- Electricity: Input = power source, Output = current through conductors
Define trigger conditions:
- Fire output (heat) can be input to explosives (ignition source)
- Water output (fluid) can be input to electricity (conductor)
- Electricity output (current) can be input to mechanisms (power)

Map cascade paths:

Fire → (heat) → Explosives → (blast) → Structure → (falls) → Water → (floods) → Electric → (shocks) → Enemies

Add dampening at each step:
- Fire: Burns for 10 seconds, then stops
- Explosives: One-time effect, doesn't chain without fuel
- Structure: Falls once, can't re-trigger
- Water: Finite volume, spreads until area filled
- Electric: Dissipates in water over time
Test cascade length distribution:
- Most cascades should be 2-3 steps (tactical)
- Some cascades reach 4-5 steps (strategic)
- Rare cascades hit 6+ steps (surprising)
Ensure player agency:
- Player should INITIATE cascades
- Cascades shouldn't happen randomly
- Player can predict at least first 2-3 steps

Common Cascade Failures

❌ No cascades: Every action is single-step (predictable, boring) ❌ Infinite cascades: Chain never stops (uncontrollable, frustrating) ❌ Random cascades: Player can't predict or control (feels unfair) ❌ Required cascades: Puzzle has only one solution via specific cascade (not emergent)

✅ Instead:

Design 3-5 step cascades as baseline
Add dampening at every step
Make cascades player-initiated
Enable multiple cascade paths to same goal

CORE CONCEPT #5: Systemic Solutions (The Multiple-Paths Principle)

What are Systemic Solutions?

Systemic solutions are when players solve problems using the simulation, not designer-intended mechanics.

Scripted solution: "Use key to open door" Systemic solution: "Shoot door with explosive, hack lock, teleport through wall, or stack boxes to climb over"

The hallmark of emergent gameplay is that players discover solutions you DIDN'T DESIGN.

Systemic vs Scripted Design

Scripted Design:

Designer creates problem: "Door is locked"
Designer creates solution: "Find key"
Player follows designer's path
One solution, predictable

Systemic Design:

Designer creates constraints: "Door has lock (hackable), hinges (destructible), walls (solid)"
Designer creates mechanics: "Explosives destroy objects, hacking opens electronics, glue climbs surfaces"
Player discovers solutions: "Blow hinges, hack lock, climb wall, or use physics to bypass"
Multiple solutions, unpredictable

The Systemic Solution Checklist

For every challenge, ask:

Can physics solve it? (Stack boxes, use momentum, throw objects)
Can chemistry solve it? (Burn, freeze, melt, dissolve)
Can abilities solve it? (Teleport, time stop, invisibility)
Can AI manipulation solve it? (Distract, lure, possess)
Can environment solve it? (Use existing objects, terrain, hazards)

If answer is "yes" to 3+, you have systemic design. If only 1, it's scripted.

Real-World Example: Deus Ex

Challenge: Reach a building's upper floor

Scripted game would have: "Find keycard, use elevator"

Deus Ex systemic solutions:

Front door: Hack security, use legitimate keycard
Break-in: Lockpick side door, blow open vent with LAM
Stealth: Find hidden window entrance, use multitool on lock
Social: Convince guard to let you in (dialog)
Vertical: Stack crates, jump from adjacent building
Aggressive: Kill everyone, walk in freely

Why it works:

No "intended" solution
Each solution uses different systems (hacking, explosives, lockpicking, social, physics, combat)
Player chooses based on playstyle and resources
Designer didn't script "crate stacking solution"—it emerged from physics

Systemic Solution Design Process

Define constraints, not solutions:
- ❌ "Door needs key" (scripted)
- ✅ "Door has lock (hackable), hinges (destructible), walls (climbable)" (systemic)
Give objects properties, not functions:
- ❌ "Keycard opens door" (single function)
- ✅ "Keycard has RFID signature, doors check RFID" (property-based)
- Result: Players can clone RFID, spoof signature, steal card—not just "use key"
Make challenges orthogonal to mechanics:
- If you have 5 mechanics and 5 challenges, each challenge should be solvable by 3+ mechanics
- This prevents 1:1 mapping (which is just scripted with extra steps)
Playtest for unintended solutions:
- If playtesters solve challenge differently than you designed: GOOD
- If every playtester uses same solution: BAD (it's scripted)
- Track "solution diversity" metric: How many different solutions do players discover?
Resist the urge to "fix" creative solutions:
- If player uses barrels to climb wall you wanted them to hack: Feature, not bug
- Only patch solutions that trivialize ALL challenges (dominant strategy)

Common Systemic Solution Failures

❌ Lock-and-key design: Every challenge has exactly one solution item ❌ Hard-coded solutions: "Only explosives open this door" (ignores physics, hacking, etc.) ❌ Invisible walls: "You can climb walls, but not THIS wall" (breaks consistency) ❌ Required scripted sequence: "You must hack the terminal" (removes player choice)

✅ Instead:

Every challenge has 3+ solutions using different systems
Properties, not hard-coded gates
Consistent rules (if climbable surface, always climbable)
Optional hints, never required paths

CORE CONCEPT #6: Emergence Testing Methodology

How Do You Know If Emergence is Happening?

Emergence is hard to measure, but you can test for it:

Test 1: Solution Diversity Test

Method:

Give 10 playtesters the same challenge
Don't tell them how to solve it
Count unique solutions

Scoring:

1-2 unique solutions: Scripted (failed)
3-5 unique solutions: Systemic (good)
6+ unique solutions: Highly emergent (excellent)

Example: Hitman contracts

"Eliminate target"
Players discover: Sniper, poison, disguise, accident, distraction + snipe, etc.
Result: 10+ solutions per contract (highly emergent)

Test 2: Designer Surprise Test

Method:

Watch playtesting footage
Count times you think: "I didn't know you could do that!"

Scoring:

0 surprises: Scripted (failed)
1-3 surprises: Some emergence (ok)
5+ surprises: Highly emergent (excellent)

Example: Breath of the Wild

Designers were surprised by: Minecart launching, shield surfing combat, using metal boxes as elevators
Result: High emergence

Test 3: Interaction Coverage Test

Method:

Count total possible interactions in your matrix (N × N)
Count actually implemented interactions (M)
Calculate coverage: M / (N × N) × 100%

Scoring:

<30% coverage: Disconnected systems (failed)
30-50% coverage: Some interaction (ok)
60-80% coverage: High interaction (excellent)
90% coverage: Over-designed (diminishing returns)

Example: Noita

~30 materials = 900 possible interactions
~600 implemented = 67% coverage (excellent)

Test 4: Cascade Length Distribution Test

Method:

Instrument code to track action chains
Measure how many actions trigger secondary actions
Plot distribution of chain lengths

Scoring:

Ideal distribution:
- 1-step chains: 40% (direct actions)
- 2-step chains: 30% (tactical combinations)
- 3-step chains: 20% (strategic setups)
- 4+ step chains: 10% (emergent surprises)

Bad distribution:
- 1-step chains: 95% (no emergence)
- 2+ step chains: 5% (rare)

Test 5: Dominant Strategy Test

Method:

Identify optimal strategy (math or playtesting)
Measure how often players use it
Measure win rate with optimal strategy

Scoring:

Optimal strategy used >80% of time: Dominant (failed)
Optimal strategy used 50-70% of time: Balanced (ok)
No clear optimal strategy: Rich meta (excellent)

Example: Rock-Paper-Scissors

No dominant strategy (33% each in balanced play)
Compare to "Gun-Knife-Fist" where Gun always wins (dominant)

Test 6: Runaway Condition Test

Method:

Identify positive feedback loops
Test: "What if player does X repeatedly?"
Measure: Does system stabilize or explode?

Scoring:

System explodes (infinite growth): Failed (needs dampening)
System stabilizes within 10 iterations: Good (negative feedback working)
System oscillates predictably: Good (dynamic equilibrium)

Example: Fire spread

Without fuel depletion: Infinite spread (failed)
With fuel depletion: Stops after consuming local fuel (good)

Emergence Testing Checklist

Before shipping emergent system, verify:

Solution Diversity: 3+ solutions to most challenges
Designer Surprise: 5+ unintended solutions discovered in playtest
Interaction Coverage: 60-80% of interaction matrix implemented
Cascade Distribution: 20%+ of actions trigger 3+ step chains
No Dominant Strategy: Optimal strategy used <70% of time
Runaway Dampening: All positive feedback loops have negative counterparts
Consistency: Rules apply uniformly (no special cases)
Documentation: Interaction matrix documented and accessible

DECISION FRAMEWORK #1: Scripted vs Emergent (Control vs Surprise)

The Core Tradeoff

Every design decision involves choosing:

Control: Designer dictates experience (scripted)
Surprise: Players discover experience (emergent)

You can't maximize both. Choose deliberately.

When to Choose Scripted

Choose scripted when:

Story beats must happen: "Hero confronts villain" can't be skipped or done wrong
Tutorial sequences: New players need hand-holding
Pacing critical: "Calm before storm" requires designer control
One-time spectacles: Setpiece moments (building collapses, epic entrance)
Budget constraints: Emergent systems cost more upfront dev time

Example: Uncharted

Heavily scripted setpieces (train crash, building collapse)
Why: Story-driven, cinematic experience
Tradeoff: Low replayability, but strong narrative

When to Choose Emergent

Choose emergent when:

Replayability is goal: Players will play 100+ hours
Player expression valued: "Play your way" philosophy
Sandboxes or simulations: Open-ended goals
Competitive depth: Meta-game evolution
Content creation cost high: 100 hours of scripted content = expensive, 100 hours of emergent play = cheaper per hour

Example: Minecraft

Highly emergent (redstone, building, exploration)
Why: Infinite replayability from simple rules
Tradeoff: No strong narrative, requires player creativity

Hybrid Approach (Best for Most Games)

Most games use hybrid:

Scripted structure: Main story missions, key moments
Emergent gameplay: Moment-to-moment tactics, side content

Example: Breath of the Wild

Scripted: Four Divine Beasts quest structure, Ganon confrontation
Emergent: Shrine solutions, combat tactics, exploration routes
Why: Best of both worlds (narrative + replayability)

Decision Process

For each game system, ask:

1. What is the player's goal?

Clear goal (reach exit) → Can be emergent
Specific outcome (witness betrayal) → Must be scripted

2. How often will player experience this?

Once → Can be scripted (high authoring cost ok)
100+ times → Should be emergent (need variety)

3. Does player need agency?

Yes (core fantasy) → Emergent
No (spectator moment) → Scripted

4. Can failure be interesting?

Yes (learn and retry) → Emergent
No (frustrates story) → Scripted with retry checkpoints

Example Decision Table

System	Goal	Frequency	Agency	Failure	Decision
Combat	Defeat enemies	1000+ times	High	Interesting (tactics)	Emergent
Boss intro cutscene	See villain	1 time	None	N/A (no failure)	Scripted
Boss fight	Defeat villain	5-20 times (retries)	High	Learn patterns	Hybrid (phases scripted, tactics emergent)
Side quests	Complete objectives	50+ times	Medium	Interesting	Emergent (systemic solutions)
Ending	Story resolution	1 time	None (watch)	N/A	Scripted

Common Decision Failures

❌ Scripting emergent moments: "You must use explosive to open door" (but player has 5 other tools) ❌ Emergent story beats: "Boss might die to random fire before cinematic" (breaks pacing) ❌ Hybrid confusion: "Game teaches scripted solutions, then expects emergent creativity" (mixed signals)

✅ Instead:

Separate emergent gameplay from scripted story moments
Teach emergent thinking early (tutorials show multiple solutions)
Use scripting for pacing, emergence for variety

DECISION FRAMEWORK #2: Constraint Tuning (Goldilocks Zone)

The Constraint Paradox

Too constrained: No emergence (players follow single path)
Too open: No strategy (random outcomes, no skill)
Goldilocks zone: Constrained enough for strategy, open enough for creativity

Your job: Find the Goldilocks zone.

The Constraint Spectrum

OVER-CONSTRAINED                 GOLDILOCKS                     UNDER-CONSTRAINED
│                                    │                                 │
│ One solution per puzzle            │ 3-5 solutions per puzzle       │ Infinite solutions, all equally valid
│ Linear progression                 │ Multiple paths forward         │ No clear progression
│ No experimentation                 │ Experimentation rewarded       │ Experimentation required (trial/error)
│ High control                       │ Balanced freedom               │ Overwhelming freedom
│                                    │                                 │
Examples:                          Examples:                        Examples:
- Portal 1 (exact solutions)        - Prey (many solutions)          - Garry's Mod (no goals)
- Linear tutorials                  - Hitman (many paths)            - Minecraft creative (no constraints)
- Lock-and-key design              - Breath of the Wild             - Sandbox with no objectives

Over-Constrained Warning Signs

Players discover creative solution, you patch it out ("not intended")
Every challenge has one item that solves it (lock-and-key)
Playtesters all use same solution (no diversity)
"Correct" and "incorrect" solutions (rather than effective/ineffective)
Hidden collectibles are required, not optional
Tutorials force specific actions (no room to experiment)

Example: Bioshock (2007)

Over-constrained hack minigame (pipe puzzle with one solution)
Contrast with Prey (2017): Multiple ways to overcome locked doors
Result: Prey feels more emergent

Under-Constrained Warning Signs

Players are confused what to do
Random experimentation is only strategy (no skill)
Outcomes feel arbitrary (no cause-effect)
"Anything goes" means no interesting choices
Too many options = choice paralysis
Lack of feedback (did that work? no way to tell)

Example: Early survival games

Too many crafting recipes (hundreds of useless items)
No guidance what matters
Result: Wiki-required gameplay

Finding the Goldilocks Zone

Method 1: Constraint Counting

For each challenge:

Count possible solutions
Count effective solutions (solutions that work reasonably well)
Count optimal solutions (best solutions)

Scoring:

Possible solutions: 10+
Effective solutions: 3-5
Optimal solutions: 1-2

Result: Goldilocks (many options, few are good, encouraging experimentation)

Compare:

Over-constrained:
Possible solutions: 2
Effective solutions: 1
Optimal solutions: 1
(No room for creativity)

Under-constrained:
Possible solutions: 100
Effective solutions: 95
Optimal solutions: 90
(No meaningful choice)

Method 2: Playtesting Diversity

Watch 10 players solve same challenge
Count unique approaches
Measure success rate per approach

Goldilocks:

5-8 unique approaches (high diversity)
All approaches have 40-80% success rate (no dominant strategy, but some are better)

Over-constrained:

1-2 approaches (low diversity)
One approach has 100% success, others 0% (forced solution)

Under-constrained:

10+ approaches, all succeed 100% (no differentiation, no mastery)

Real-World Example: Dishonored

Goldilocks Zone Achieved:

For "Eliminate target" mission:

Possible solutions: 20+ (high creativity)
Effective solutions: 6-8 (varied playstyles)
- Direct combat
- Stealth lethal
- Stealth non-lethal
- Possess NPC to reach target
- Engineer accident (chandelier, poison)
- Social (frame someone else)
Optimal solutions: 2-3 (ghost non-lethal, or speed kill)

Why Goldilocks:

Many options encourage experimentation
Some options clearly harder/riskier (stealth vs combat)
Mastery is choosing right tool for situation
Players feel creative ("I solved it my way")

Constraint Tuning Process

Start over-constrained (easier to loosen than tighten):
- Design one intended solution first
- Playtest: Does it work?
Add alternative solutions (expand constraint):
- "What if player has different tools?"
- "What if player uses physics?"
- Implement 2-3 alternatives
Playtest for diversity:
- Are players discovering different solutions?
- Are some solutions never used? (Too weak or non-obvious)
Balance effectiveness:
- If one solution always wins, it's dominant (bad)
- Make alternatives competitive, not equal
Test for confusion:
- Are players stuck? (Too constrained)
- Are players overwhelmed? (Too open)
Iterate toward Goldilocks:
- Add constraints if players are confused
- Remove constraints if players are frustrated

Common Constraint Failures

❌ Binary gating: "You must have X to proceed" (over-constrained) ❌ Everything is optional: "All collectibles are cosmetic" (under-constrained, no stakes) ❌ Fake choices: "Three dialogue options that all lead to same outcome" (illusion of freedom) ❌ Overwhelming tutorials: "Here are 50 mechanics, good luck" (under-constrained onboarding)

✅ Instead:

Multiple paths, clear consequences
Optional content provides advantages (not cosmetic, not required)
Choices lead to different outcomes (real agency)
Tutorials introduce mechanics gradually (constrained early, open late)

DECISION FRAMEWORK #3: Exploit Handling (Feature vs Bug)

The Core Question

When players discover unintended tactics:

"Is this a feature or a bug?"

Wrong answer → Patch emergent gameplay, anger players Right answer → Embrace creativity, enrich game

The Feature vs Bug Criteria

Factor	Feature (Keep It)	Bug (Patch It)
Skill Required	High skill ceiling	No skill (trivial)
Consistency	Uses game rules consistently	Breaks game rules
Depth	Adds strategic depth	Removes strategic depth
Counterplay	Can be countered	Uncounterable
Scope	Solves some challenges creatively	Trivializes all challenges
Fun	Players excited to share	Players feel dirty using it

Feature Examples (Kept by Designers)

Rocket Jumping (Quake):

Unintended: Explosions damage player, explosions apply physics force → player can launch self
Why feature: High skill (timing, aim), adds mobility depth, fun to master
Result: Became core mechanic in games (TF2, etc.)

Combos (Street Fighter II):

Unintended: Animation canceling allows multi-hit chains
Why feature: High skill ceiling, adds competitive depth, exciting to watch
Result: Combo system became fighting game standard

Bunny Hopping (Quake/CS):

Unintended: Strafe + jump preserves momentum, allowing speed gain
Why feature: High skill (timing, mouse control), can be countered (predict path), fun movement skill
Result: Became competitive mechanic (some games keep it, others remove it based on design philosophy)

Bug Examples (Patched by Designers)

Infinite Money Glitches:

Unintended: Duplication exploit creates infinite currency
Why bug: No skill, trivializes all progression, breaks economy
Result: Always patched

Invincibility Exploits:

Unintended: Animation glitch makes player immune to damage
Why bug: No counterplay, removes all challenge, not fun
Result: Always patched

Out of Bounds Skips:

Unintended: Player clips through wall, skips entire level
Why bug (sometimes): If it trivializes game for casual players (bad onboarding)
Why feature (sometimes): If speedrunning community values it (adds depth to competitive play)
Result: Context-dependent (Zelda OOT keeps some skips for speedruns, patches gamebreaking ones)

The Decision Process

When exploit discovered:

Step 1: Can it be countered?

Yes → Likely feature (adds meta-game)
No → Likely bug (removes strategy)

Step 2: Does it require skill?

Yes → Likely feature (rewards mastery)
No (trivial) → Likely bug (no depth)

Step 3: Does it affect all players or just experts?

Just experts → Likely feature (optional advanced technique)
All players forced to use it → Consider patching (removes diversity)

Step 4: Does it trivialize intended challenges?

Some challenges → Likely feature (creative solution)
All challenges → Likely bug (breaks game)

Step 5: Are players excited or guilty?

Excited (sharing videos) → Likely feature
Guilty (feels like cheating) → Likely bug

Step 6: Does it align with design philosophy?

Philosophy: "Player creativity" → Likely feature
Philosophy: "Balanced competitive play" → Might be bug
Philosophy: "Accessible to all" → Might be bug

Real-World Example: Prey (2017)

GLOO Cannon Climbing:

Unintended: GLOO creates platforms → player can shoot GLOO upward → climb to reach any height
Designer decision: FEATURE
Why:
- Requires skill (aim, resource management)
- Opens creative exploration
- Fits "immersive sim" philosophy
- Can be countered (limited ammo, enemy interruption)
- Doesn't trivialize all challenges (just traversal)
Result: Became beloved mechanic, community shares creative uses

Typhon Power Stacking:

Unintended: Certain power combinations create near-invincibility
Designer decision: BUG (later patched)
Why:
- No skill (just combo selection)
- Trivializes combat for rest of game
- No counterplay
- Breaks intended difficulty curve
Result: Balanced in patches

Exploit Handling Process

Document exploit (repro steps, impact, skill required)
Playtest with and without:
- Have testers use exploit deliberately
- Measure: Fun? Skill? Trivialization?
Check community sentiment:
- Are players sharing it excitedly?
- Are players complaining it's required?
Make decision:
- Feature → Document it, maybe hint at it, balance around it
- Bug → Patch ASAP with explanation
Communicate decision:
- If keeping: "This is creative use of mechanics, intentionally kept"
- If patching: "This removed strategic depth, patched to preserve variety"

Common Exploit Handling Failures

❌ Patching all emergent tactics: "Not intended = must be bug" (kills creativity) ❌ Keeping gamebreaking exploits: "Players should just not use it" (breaks game for everyone who discovers it) ❌ Inconsistent enforcement: "Exploit A is feature, exploit B is bug" with no clear criteria (confuses players) ❌ Knee-jerk patching: Patch immediately without community input (angers creative players)

✅ Instead:

Use criteria table (skill, depth, counterplay)
Consult community before patching beloved exploits
Communicate reasoning ("Why this is feature/bug")
Balance, don't remove (nerf exploit, don't delete it)

IMPLEMENTATION PATTERN #1: Orthogonal Mechanic Design

Step-by-Step Process

Step 1: List Simulation Properties

Before designing mechanics, list properties your simulation tracks:

Example (Immersive Sim):

Position (x, y, z)
Velocity (vector)
Mass (kg)
Temperature (celsius)
Flammability (0-1)
Conductivity (0-1)
Brittleness (0-1)
Opacity (0-1)
Friction (coefficient)
Magnetism (ferrous/non-ferrous)

Step 2: Design Mechanics That Affect Different Properties

Each mechanic should modify 1-2 properties, NOT the same properties as other mechanics:

Fire Mechanic:
- Affects: Temperature, Flammability
- Does NOT affect: Position, Conductivity (other mechanics handle these)

Ice Mechanic:
- Affects: Temperature, Friction
- Does NOT affect: Flammability (Fire handles this)

Electricity Mechanic:
- Affects: Conductivity (creates current through conductive materials)
- Does NOT affect: Temperature (unless through resistance heating)

Magnetism Mechanic:
- Affects: Position (of ferrous objects), Magnetism
- Does NOT affect: Temperature, Flammability

Step 3: Verify No Overlap

Create property matrix:

            Position  Velocity  Mass  Temp  Flamm  Conduct  Brittle  Opacity  Friction  Magnet
Fire           -        -        -     ✓      ✓       -        -        ✓        -        -
Ice            -        -        -     ✓      -       -        ✓        -        ✓        -
Electric       -        -        -     -      -       ✓        -        -        -        -
Magnetism      ✓        ✓        -     -      -       -        -        -        -        ✓
Gravity        ✓        ✓        -     -      -       -        -        -        -        -
Explosion      ✓        ✓        -     ✓      ✓       -        ✓        -        -        -

Rule: Each column should have 1-2 checkmarks (property affected by 1-2 mechanics). If 3+ mechanics affect same property in same way, they're redundant.

Step 4: Define Cross-Property Interactions

Once mechanics are orthogonal, define how properties interact:

High Temperature + High Flammability → Ignition
Low Temperature + High Water Content → Freezing (Brittle state)
High Conductivity + Electric Current → Current flows through object
High Magnetism + Ferrous Material → Attraction force applied to Position

Step 5: Test Multiplication

Count interactions:

5 mechanics × 10 properties = 50 possible mechanic-property pairs
If 30 pairs are implemented = 60% coverage (good)

Step 6: Implement Mechanics as Property Modifiers

Code pattern:

class FireMechanic:
    def apply(self, object):
        object.temperature += 50  # Raise temperature
        if object.temperature > object.ignition_point:
            object.flammability = 1.0  # Fully flammable
            object.on_fire = True
            object.opacity -= 0.3  # Smoke reduces visibility

class IceMechanic:
    def apply(self, object):
        object.temperature -= 100  # Lower temperature
        if object.temperature < 0:
            object.friction *= 0.1  # 10× more slippery
            object.brittleness += 0.5  # More likely to shatter

Why this works: Mechanics don't know about each other, they just modify properties. Interactions emerge from property relationships.

IMPLEMENTATION PATTERN #2: Interaction Matrix Creation

Step-by-Step Process

Step 1: List All Elements

Elements = Objects, materials, abilities that can interact

Example:

Fire, Water, Ice, Electricity, Oil, Wood, Metal, Glass, Explosive, Acid

Step 2: Create Empty Matrix

           Fire  Water  Ice  Elec  Oil  Wood  Metal  Glass  Explo  Acid
Fire        ?     ?     ?     ?    ?     ?      ?      ?      ?     ?
Water       ?     ?     ?     ?    ?     ?      ?      ?      ?     ?
Ice         ?     ?     ?     ?    ?     ?      ?      ?      ?     ?
Elec        ?     ?     ?     ?    ?     ?      ?      ?      ?     ?
Oil         ?     ?     ?     ?    ?     ?      ?      ?      ?     ?
Wood        ?     ?     ?     ?    ?     ?      ?      ?      ?     ?
Metal       ?     ?     ?     ?    ?     ?      ?      ?      ?     ?
Glass       ?     ?     ?     ?    ?     ?      ?      ?      ?     ?
Explo       ?     ?     ?     ?    ?     ?      ?      ?      ?     ?
Acid        ?     ?     ?     ?    ?     ?      ?      ?      ?     ?

Step 3: Fill Diagonal (Self-Interactions)

Fire + Fire = Bigger fire (accumulation)
Water + Water = More water (pooling)
Ice + Ice = Larger frozen area
Electricity + Electricity = Higher voltage (stronger effect)
Oil + Oil = Larger slick
...etc

Step 4: Fill Obvious Opposites

Fire + Water = Extinguish (fire out, steam produced)
Fire + Ice = Melt (ice becomes water)
Electricity + Water = Conduction (electrified water)

Step 5: Fill Material Interactions

Fire + Wood = Wood burns (flammable material)
Fire + Metal = Metal heats up (not flammable, but conducts heat)
Fire + Glass = Glass shatters (thermal shock if cooled rapidly)
Electricity + Metal = Conducts (metal is conductor)
Electricity + Wood = No conduction (insulator)
Acid + Metal = Dissolves (chemical reaction)

Step 6: Fill Creative Interactions

Oil + Fire = Burning oil (spreads fire faster)
Oil + Water = Oil floats (doesn't mix, creates slippery surface on water)
Oil + Electricity = Insulator (non-conductive)
Ice + Explosive = Ice shards (frozen shrapnel)
Electricity + Explosive = Remote detonation
Glass + Sound = Shatter (resonance frequency)

Step 7: Mark Non-Interactions

Water + Wood = X (water doesn't significantly affect wood structurally)
Ice + Metal = X (metal doesn't change when cold)
Wood + Glass = X (no meaningful interaction)

Step 8: Calculate Coverage

Total cells: 10 × 10 = 100 Implemented interactions: ~65 Coverage: 65% (Good: Target 60-80%)

Step 9: Document Rules

For each interaction, write explicit rule:

Fire + Water:
- If Fire.intensity < Water.volume: Fire extinguished
- If Fire.intensity >= Water.volume: Water evaporates (steam)
- Steam: Reduces visibility (opacity), deals minor heat damage

Fire + Oil:
- Oil ignites immediately
- Burning oil spreads at 2× rate of normal fire
- Oil cannot be extinguished by water (oil floats)

Step 10: Implement Interaction System

Code pattern:

class InteractionMatrix:
    def __init__(self):
        self.rules = {}

    def register(self, element_a, element_b, rule_func):
        key = (element_a, element_b)
        self.rules[key] = rule_func

    def interact(self, obj_a, obj_b):
        key = (obj_a.element_type, obj_b.element_type)
        if key in self.rules:
            return self.rules[key](obj_a, obj_b)
        else:
            return None  # No interaction

# Usage:
matrix = InteractionMatrix()
matrix.register("Fire", "Water", lambda f, w: extinguish_fire(f, w))
matrix.register("Fire", "Oil", lambda f, o: ignite_oil(o))
matrix.register("Electricity", "Water", lambda e, w: electrify_water(w))

# At runtime:
matrix.interact(fire_object, water_object)  # Calls extinguish_fire

IMPLEMENTATION PATTERN #3: Feedback Loop Balancing

Step-by-Step Process

Step 1: Identify All Feedback Loops

Trace system paths:

Example (Fire Spread):

Fire increases Temperature
Temperature increases Fire Spread Rate
Fire Spread Rate increases Fire Area
Fire Area increases Temperature (of adjacent tiles)
LOOP: Fire → Temp → Spread → More Fire → More Temp → ...

Step 2: Classify Loop Type

Positive loop (each arrow is positive, or even number of negatives):

Fire → (+) Temp → (+) Spread → (+) More Fire
Positive feedback = Runaway growth

Step 3: Add Negative Feedback

To balance positive loop, add negative feedback:

Fire → Consumes Fuel → (-) Available Fuel → (-) Fire Duration → Fire Stops
Fire → Produces Smoke → (-) Oxygen Level → (-) Fire Intensity

Now:

Positive feedback: Fire → Temp → Spread (growth)
Negative feedback: Fire → Fuel Depletion → Stop (limit)

Step 4: Model Equilibrium

Where do loops balance?

Positive growth rate: +10 area/second (fire spreads)
Negative depletion rate: -2 area/second (fuel consumed)
Net growth: +8 area/second initially

As fire grows:
- More area = more fuel consumption
- Eventually: Consumption rate = Spread rate
- Equilibrium: Fire stops growing, maintains size

Step 5: Tune Time Constants

Time constant = How long until equilibrium?

Too fast: System stabilizes immediately (boring, no emergence) Too slow: System runs away before stabilizing (uncontrollable)

Good range: 10-60 seconds for most gameplay systems

Step 6: Add Player Agency

Player should be able to influence feedback loops:

Player can extinguish fire (adds negative feedback)
Player can add fuel (adds positive feedback)
Player can create firebreaks (limits spread)

Step 7: Implement Dampening Mechanisms

Code pattern:

class Fire:
    def __init__(self):
        self.area = 1.0  # Current fire size
        self.fuel = 100.0  # Available fuel
        self.spread_rate = 1.0  # Base spread rate

    def update(self, dt):
        # Positive feedback: Fire spreads based on temperature
        growth = self.spread_rate * self.area * dt

        # Negative feedback: Consumes fuel
        fuel_consumption = self.area * 0.5 * dt
        self.fuel -= fuel_consumption

        # Negative feedback: Spread rate decreases as fuel depletes
        fuel_factor = self.fuel / 100.0  # 0.0 to 1.0
        actual_growth = growth * fuel_factor

        self.area += actual_growth

        # Stabilization: Fire stops if no fuel
        if self.fuel <= 0:
            self.area -= self.area * 0.1 * dt  # Fire dies out

Step 8: Test for Runaway

Simulation test:

# Worst-case test: Infinite fuel
fire.fuel = float('inf')
for i in range(1000):
    fire.update(dt=1.0)
    assert fire.area < MAX_REASONABLE_SIZE, "Fire runaway detected"

If test fails, add more negative feedback or reduce positive feedback strength.

Step 9: Test for Stagnation

Simulation test:

# Best-case test: Optimal conditions
fire.fuel = 1000.0
fire.spread_rate = 2.0
for i in range(100):
    fire.update(dt=1.0)
assert fire.area > 1.0, "Fire never grows (over-dampened)"

If test fails, reduce negative feedback or increase positive feedback strength.

IMPLEMENTATION PATTERN #4: Cascade Chain Design

Step-by-Step Process

Step 1: Define Event Types

Events = Things that can trigger other things

Example:

Impact (collision)
Ignition (fire starts)
Explosion (blast force)
Electric current
Water flow
Object break

Step 2: Define Trigger Conditions

For each object, define what events it emits and what events trigger it:

class ExplosiveBarrel:
    def on_impact(self, force):
        if force > 50:
            self.emit(ExplosionEvent(self.position, damage=100))

    def on_ignition(self):
        self.emit(ExplosionEvent(self.position, damage=100))

    def on_electric_current(self, voltage):
        if voltage > 20:
            self.emit(ExplosionEvent(self.position, damage=100))

class WoodObject:
    def on_ignition(self):
        self.emit(FireEvent(self.position, intensity=10))

    def on_impact(self, force):
        if force > 100:
            self.emit(BreakEvent(self.position, debris=5))

class GlassObject:
    def on_impact(self, force):
        if force > 20:
            self.emit(ShatterEvent(self.position, shards=10))

    def on_fire(self, temperature):
        if temperature > 500:
            self.emit(ShatterEvent(self.position, shards=10))

Step 3: Define Event Propagation

Events affect nearby objects:

class ExplosionEvent:
    def propagate(self, world):
        nearby_objects = world.get_objects_in_radius(self.position, radius=10)
        for obj in nearby_objects:
            force = calculate_force(self.damage, distance(obj, self.position))
            obj.on_impact(force)
            obj.on_ignition()  # Explosions create fire

class FireEvent:
    def propagate(self, world):
        nearby_objects = world.get_objects_in_radius(self.position, radius=2)
        for obj in nearby_objects:
            if obj.flammable:
                obj.on_ignition()

Step 4: Add Dampening

Each step in cascade has probability to continue:

class ExplosionEvent:
    def propagate(self, world):
        nearby_objects = world.get_objects_in_radius(self.position, radius=10)
        for obj in nearby_objects:
            force = calculate_force(self.damage, distance(obj, self.position))

            # Dampening: Force decreases with distance
            if force > obj.impact_threshold:
                obj.on_impact(force)

            # Dampening: Only 50% chance to ignite at distance
            ignition_chance = 1.0 / (1 + distance(obj, self.position))
            if random() < ignition_chance:
                obj.on_ignition()

Step 5: Instrument Cascade Tracking

Track cascade chains for metrics:

class EventSystem:
    def __init__(self):
        self.cascade_depth = 0
        self.max_cascade_depth = 0

    def emit(self, event):
        self.cascade_depth += 1
        self.max_cascade_depth = max(self.max_cascade_depth, self.cascade_depth)

        event.propagate(self.world)

        self.cascade_depth -= 1

    def get_metrics(self):
        return {
            "max_cascade_depth": self.max_cascade_depth,
            "cascade_distribution": self.cascade_histogram
        }

Step 6: Test Cascade Lengths

def test_cascade_distribution():
    world = World()
    # Setup: 100 explosive barrels in grid

    # Trigger: Explode one barrel
    world.explode(barrel_0)

    metrics = world.event_system.get_metrics()

    # Assert: Most cascades are 2-4 steps
    assert metrics["max_cascade_depth"] >= 3, "No cascades happening"
    assert metrics["max_cascade_depth"] < 20, "Infinite cascade detected"

Step 7: Add Cascade Cooldowns

Prevent same object from triggering twice in short time:

class ExplosiveBarrel:
    def __init__(self):
        self.last_trigger_time = 0
        self.cooldown = 1.0  # seconds

    def on_impact(self, force, current_time):
        if current_time - self.last_trigger_time < self.cooldown:
            return  # Ignore impact (cooldown active)

        if force > 50:
            self.emit(ExplosionEvent(self.position, damage=100))
            self.last_trigger_time = current_time

IMPLEMENTATION PATTERN #5: Systemic Solution Architecture

Step-by-Step Process

Step 1: Define Challenges as Constraints, Not Solutions

Bad (scripted):

class LockedDoor:
    required_item = "RedKey"

    def attempt_open(self, player):
        if player.has_item(self.required_item):
            self.open()
        else:
            self.show_message("You need the Red Key")

Good (systemic):

class Door:
    def __init__(self):
        self.has_lock = True
        self.lock_strength = 50  # Hacking difficulty
        self.hinge_strength = 100  # Explosive damage required
        self.is_open = False

    def attempt_open(self, player):
        if not self.has_lock:
            self.is_open = True

    def on_hack_attempt(self, skill):
        if skill > self.lock_strength:
            self.has_lock = False

    def on_explosive_damage(self, damage):
        self.hinge_strength -= damage
        if self.hinge_strength <= 0:
            self.is_open = True
            self.emit(DebrisEvent())  # Door blown off hinges

    def on_unlock_spell(self):
        self.has_lock = False

Why better: Player can solve with hacking, explosives, magic—not just finding key.

Step 2: Give Objects Properties, Not Functions

Bad (hard-coded):

class Keycard:
    def use(self):
        return "OpensDoor"

Good (property-based):

class Keycard:
    def __init__(self):
        self.rfid_signature = "ABC123"
        self.physical_properties = {
            "flammable": False,
            "conductive": True,
            "mass": 0.01
        }

class Door:
    def __init__(self):
        self.required_rfid = "ABC123"

    def check_rfid(self, item):
        if hasattr(item, 'rfid_signature'):
            return item.rfid_signature == self.required_rfid
        return False

Why better: Now players can clone RFID, spoof signature, steal card, or use physics to bypass door.

Step 3: Query Simulation State, Don't Script Triggers

Bad (scripted AI):

class EnemyAI:
    def update(self):
        if self.state == "PATROL":
            self.patrol_route()
        elif self.state == "ALERT":
            self.search_for_player()
        elif self.state == "COMBAT":
            self.attack_player()

Good (simulation-query AI):

class EnemyAI:
    def update(self):
        # Query simulation
        visible_threats = self.vision_system.get_visible_objects(type="Threat")
        nearby_fire = self.environment.query(type="Fire", radius=5)
        nearby_cover = self.environment.query(type="Cover", radius=10)

        # Decide based on simulation state
        if visible_threats:
            if nearby_cover:
                self.move_to_cover(nearby_cover[0])
            self.attack(visible_threats[0])
        elif nearby_fire:
            self.flee_from(nearby_fire[0])
        else:
            self.patrol()

Why better: AI reacts to fire, explosions, physics objects—not just player. Emergent tactics appear.

Step 4: Use Verb System, Not Item System

Bad (item-centric):

class Player:
    def use_item(self, item):
        if item.type == "Key":
            self.unlock_door()
        elif item.type == "Explosive":
            self.place_explosive()
        elif item.type == "Medkit":
            self.heal()

Good (verb-centric):

class Player:
    def attach(self, item, target):
        # General-purpose verb
        if item.can_attach_to(target):
            target.add_attachment(item)

    def ignite(self, target):
        # General-purpose verb
        if target.flammable:
            target.on_ignition()

    def throw(self, item, direction, force):
        # General-purpose verb
        item.apply_force(direction * force)

Why better: Players discover combinations: attach explosive to object → throw object → detonate mid-air.

Step 5: Make Challenges Orthogonal to Mechanics

Design N mechanics and M challenges such that each challenge can be solved by multiple mechanics.

Example:

Mechanics: [Hacking, Explosives, Stealth, Physics, Social]
Challenges:
  - Reach Upper Floor: [Physics (stack boxes), Stealth (climb vent), Explosives (blow floor), Social (convince guard)]
  - Disable Security: [Hacking (terminal), Explosives (destroy cameras), Stealth (avoid cameras), Social (bribe guard)]
  - Obtain Keycard: [Stealth (pickpocket), Social (convince NPC), Hacking (clone RFID), Physics (loot from distance)]

Orthogonality check: Each challenge solvable by 3+ mechanics? Yes. → Good.

COMMON PITFALL #1: Over-Constraint (No Emergence Possible)

Symptom

Players discover creative solution, you patch it out
Every puzzle has one intended solution
Playtesters all use same approach
"You must do X to proceed" gates

Why It Happens

Designer wants control over pacing and story
Fear of sequence breaking
Lack of confidence in systemic design
Easier to script one solution than design multiple

Example

Game: Bioshock (2007) Pitfall: Hacking minigame is pipe puzzle with one solution Result: Player must solve specific puzzle (no creativity), breaks immersion

Contrast: Prey (2017) Solution: Hacking is one option among many (GLOO climb, Mimic into vent, break window, possess NPC) Result: Player chooses method based on playstyle

How to Avoid

Constraint audit: For each challenge, list 3+ solutions BEFORE implementing
Playtest for diversity: Do different players solve it differently?
Remove binary gates: Replace "must have key" with "lock can be picked/blown/hacked/bypassed"
Embrace sequence breaking: If player skips content creatively, that's a feature

How to Fix

If already over-constrained:

Identify bottlenecks: Where are players forced into single path?
Add alternative mechanics: Can physics/chemistry/abilities solve this differently?
Replace keys with properties: "Lock strength 50" instead of "requires Red Key"
Test again: Did solution diversity increase?

COMMON PITFALL #2: Under-Constraint (Chaos Without Depth)

Symptom

Players confused what to do
Random experimentation is only strategy
No skill development (outcomes feel arbitrary)
Too many options = choice paralysis

Why It Happens

"More options = more emergent" fallacy
No clear goals or feedback
Mechanics don't have meaningful differences
No constraints to push against

Example

Game: Early Minecraft (Alpha) Pitfall: No goals, no progression, just "build whatever" Result: Some players loved it, many quit (no direction)

Solution: Minecraft added:

Survival mode (constraint: stay alive)
The End (goal: defeat Ender Dragon)
Achievements (guided progression)

Result: Constraints gave players direction while maintaining creative freedom.

How to Avoid

Clear goals: Even sandbox games need goals (player-chosen or designer-provided)
Feedback loops: Players need to know if their actions are effective
Tiered complexity: Start constrained (tutorial), open up gradually
Meaningful differences: Each option should have clear tradeoffs

How to Fix

If already under-constrained:

Add goals: Short-term, medium-term, long-term objectives
Add feedback: Visual/audio cues when mechanics interact
Add progression: Unlock mechanics gradually (not all at once)
Reduce redundancy: Remove mechanics that don't add meaningful choices

COMMON PITFALL #3: Dominant Strategies (Optimization Kills Diversity)

Symptom

One strategy is always optimal
Players use same tactic repeatedly
Meta-game stagnates
Variety exists but is suboptimal (players feel "forced" to optimize)

Why It Happens

Balancing is hard
Some combinations unintentionally overpowered
No counterplay to optimal strategy
Playtesting didn't test for optimization

Example

Game: Skyrim (2011) Pitfall: Stealth archery is overwhelmingly powerful Result: Even melee-focused players switch to stealth archery (dominant strategy)

Why dominant:

High damage (sneak attack multiplier)
Safe (range keeps player out of danger)
No counterplay (enemies can't effectively counter stealth archery)

Solution needed: Nerf damage OR add counterplay (enemies with stealth detection, archers with shields, etc.)

How to Avoid

Test for dominance: Have competitive players try to break your game
Counterplay design: Every strategy should have a counter-strategy
Scissors-Paper-Rock: Multiple strategies with circular counters
Balance by situational strength: Strategy A is best in situation X, Strategy B is best in situation Y

How to Fix

If dominant strategy exists:

Identify why it's dominant: Damage? Safety? Resource efficiency?
Add counterplay: Enemies that specifically counter dominant strategy
Nerf gently: Reduce effectiveness 10-20% at a time (iterate)
Buff alternatives: Make other strategies more attractive (better than nerfing fun strategy)

Example fix for Skyrim:

Add enemies with "Sixth Sense" perk (detect stealth archers)
Add enemies with shields (block arrows)
Add enemies that close distance quickly (negate range advantage)
Buff melee with crowd control (makes melee more fun)

COMMON PITFALL #4: Non-Interacting Systems (Isolated Mechanics)

Symptom

Physics doesn't affect AI
Chemistry doesn't affect physics
Systems run in parallel, not in interaction
"Integration tests" mentioned but not designed

Why It Happens

Systems built by different teams
Architecture doesn't support cross-system communication
Each system designed in isolation
"Integration" is left to end of project (never happens)

Example

Baseline response in RED test:

PhysicsEngine (separate)
ChemistryEngine (separate)
AIController (separate)

Why this fails: How does AI react to chemistry? How does physics trigger chemical reactions? Architecture prevents interaction.

How to Avoid

Shared simulation state: All systems read/write to common world state
Event system: Systems emit events, other systems listen
Design interactions first: Before implementing systems, design interaction matrix
Integrate early: Week 1 should have basic versions of all systems interacting

How to Fix

If systems are isolated:

Add event system:

class EventBus:
    def emit(self, event_type, data):
        for listener in self.listeners[event_type]:
            listener.handle(data)

# Physics emits events
physics.emit("Collision", {objA, objB, force})

# Chemistry listens
chemistry.on_collision(objA, objB, force)

Create interaction layer:

class InteractionSystem:
    def __init__(self, physics, chemistry, ai):
        self.physics = physics
        self.chemistry = chemistry
        self.ai = ai

    def update(self):
        # Check for interactions
        for fire in self.chemistry.get_fires():
            self.ai.notify_fire(fire.position)
            self.physics.apply_heat(fire.position, fire.temperature)

Refactor architecture: Move from isolated engines to unified simulation.

COMMON PITFALL #5: Prescribing Solutions (Telling Instead of Enabling)

Symptom

Tutorial says "Use fire to melt ice"
Loading screen tips: "Shoot explosive barrels to kill grouped enemies"
Designer has already solved puzzles for player
Players follow instructions instead of experimenting

Why It Happens

Fear players won't discover mechanics
Playtester says "I didn't know I could do that" → designer adds tutorial
Desire to showcase mechanics
Lack of trust in player creativity

Example

Bad: Tutorial popup: "Use GLOO gun to climb walls!" Better: Player sees GLOO creates platforms, experiments, discovers climbing Best: Level design encourages experimentation (high ledge with GLOO ammo nearby, no popup)

How to Avoid

Show, don't tell: Environmental storytelling (NPC using mechanic, visual cues)
Trust players: Players will experiment if mechanics are intuitive
Reward discovery: Players feel smart when they discover solutions
Resist tutorial creep: Not every mechanic needs explanation

How to Fix

If already prescribing solutions:

Remove explicit tutorials: Delete "Do X to solve Y" instructions
Add environmental hints: NPC corpse surrounded by ice + nearby fire source = implicit hint
Reward experimentation: Achievement for discovering creative solutions
Playtest with zero guidance: Can players discover mechanics without help?

REAL-WORLD EXAMPLE #1: Breath of the Wild (Physics + Chemistry Emergence)

What Makes It Emergent

Orthogonal Mechanics:

Fire: Burns wood, creates updrafts, melts ice, lights torches, scares animals
Ice: Freezes water (platforms), creates slippery surfaces, brittleness (shatter damage)
Electricity: Conducts through metal/water, stuns enemies, magnetizes metal (Magnesis rune)
Wind: Affects glider, pushes objects, extinguishes fire, affects projectiles
Stasis: Freezes object in time, stores kinetic energy, released when unfrozen
Magnesis: Moves metal objects, creates platforms, weaponizes objects

Interaction Matrix (Sample):

Fire + Wood = Burns (damage over time, light source)
Fire + Ice = Melts (ice becomes water)
Fire + Updraft = Glider lift (traversal)
Ice + Water = Freezing (platform creation)
Ice + Weapon = Frozen weapon (brittleness bonus)
Electricity + Metal = Conduction (chain damage)
Electricity + Water = Electrified water (area damage)
Stasis + Hit = Kinetic energy storage (launch objects)
Magnesis + Metal = Manipulation (puzzles, combat, traversal)

Cascade Chains:

Player shoots fire arrow at grass
Grass burns, fire spreads
Fire creates updraft (hot air rises)
Player uses paraglider in updraft
Gains altitude to reach high platform

Length: 5 steps, highly emergent

Systemic Solutions:

Challenge: Reach high platform

Solution 1: Climb wall (stamina required)
Solution 2: Fire updraft + glider
Solution 3: Stasis boulder, hit it, launch up
Solution 4: Magnesis metal box, stack, climb
Solution 5: Ice pillar from water, climb

Result: 5+ solutions, all emergent (not explicitly taught)

Key Lessons

Simple rules, complex outcomes: 6 core mechanics, 30+ interactions
Consistent physics: Fire always burns wood, ice always melts from fire
Environmental design: Levels designed to hint at interactions without prescribing
Trust players: No tutorial says "Burn grass for updraft", players discover it

REAL-WORLD EXAMPLE #2: Dwarf Fortress (Simulation Depth)

What Makes It Emergent

Simulation Properties (Hundreds):

Each dwarf: Personality traits, relationships, skills, injuries, mental state, needs
Each material: Melting point, sharpness, density, value, color
Each creature: Body parts, can bleed, can feel pain, can rage
World simulation: Weather, seasons, civilizations, history generation

Interaction Matrix (Massive):

Water + Magma = Obsidian + Steam
Alcohol + Dwarf (trait: alcoholic) = Happiness boost
Injury (severed leg) + Dwarf = Reduced mobility + bleeding
Cat + Vermin = Hunt (food source)
Too many cats + Vermin depletion = Cat starvation

Emergence Examples:

The Cat Cascade:
- Player adopts cats for vermin control
- Cats breed rapidly
- Too many cats deplete vermin population
- Cats starve, corpses rot
- Dwarves depressed by dead cats
- Fortress falls to unhappiness cascade
The Unfortunate Alcohol Incident:
- Dwarf walks through spilled alcohol
- Alcohol on dwarf ignites near torch
- Dwarf catches fire
- Runs through barracks
- Ignites bedding
- Barracks burns down
The Artifact Obsession:
- Dwarf becomes obsessed (personality trait + mood)
- Demands specific materials for artifact
- Materials unavailable
- Dwarf goes insane
- Kills other dwarves (berserk)
- Fortress in chaos

Feedback Loops:

Positive: More dwarves → more labor → more resources → support more dwarves
Negative: More dwarves → more consumption → resource depletion → starvation
Player manages equilibrium

Key Lessons

Deep simulation creates emergent stories: Players share stories of disasters and triumphs
Feedback loops drive drama: Cascading failures are memorable
Complexity from properties: Hundreds of properties = thousands of interactions
Unintended interactions are features: Cat cascade wasn't designed, but became legendary

REAL-WORLD EXAMPLE #3: Minecraft (Simple → Complex Combinatorics)

What Makes It Emergent

Simple Core Mechanics:

Place blocks
Break blocks
Blocks have properties (solid, flammable, conductive)
Redstone transmits signal

Emergent Complexity:

From 4 simple mechanics, players created:

Logic gates (AND, OR, NOT)
Arithmetic circuits (adders, multipliers)
Memory (RAM, registers)
Computers (functioning CPUs)
Games within game (Pong, Snake)

Interaction Matrix (Redstone):

Redstone + Block = Signal transmission
Redstone + Torch = NOT gate (inverter)
Redstone + Repeater = Signal delay + amplification
Redstone + Piston = Mechanical movement
Redstone + Hopper = Item transport
Redstone + Comparator = Signal comparison (branching logic)

6 core redstone components × 6 = 36 interactions → Infinite computational complexity

Cascade Example:

Button press → Redstone signal → Piston extends → Pushes block → Triggers pressure plate → Opens door → Activates hopper → Drops item → Triggers comparator → Loops back

Length: 9 steps, player-designed

Key Lessons

Turing completeness from simple rules: Redstone is Turing-complete (can compute anything)
Combinatorial explosion: 6 components → infinite possibilities
No prescriptive tutorials: Players discovered redstone computers organically
Community-driven emergence: Players teach each other discoveries

REAL-WORLD EXAMPLE #4: Deus Ex (Systemic Solutions)

What Makes It Emergent

Design Philosophy: "One game, many paths"

Core Systems:

Combat (lethal/non-lethal)
Stealth (vision cones, sound propagation)
Hacking (computers, security)
Social (dialogue, persuasion)
Augmentations (player abilities)
Environment (destructible, climbable, manipulable)

Systemic Solution Example:

Challenge: Reach NSF headquarters upper floor

Solution 1 (Combat): Fight through front door, kill all guards Solution 2 (Stealth): Side entrance, lockpick door, avoid patrols Solution 3 (Hacking): Hack security, disable cameras, waltz in Solution 4 (Social): Convince guard to let you in (dialogue skill) Solution 5 (Physics): Stack crates, jump from adjacent building Solution 6 (Augmentations): Cloak augmentation, walk past guards Solution 7 (Hybrid): Tranquilize guard, steal keycard, use front door

Result: 7+ solutions, all viable, players choose based on playstyle and resources

No Dominant Strategy:

Combat is loud (attracts reinforcements)
Stealth is slow (time pressure in some missions)
Hacking requires skill investment
Social requires previous dialogue choices
Physics is unpredictable (crates fall)

Tradeoffs ensure no one solution always wins.

Key Lessons

Systems orthogonal to challenges: 6 systems, each challenge solvable by 3+ systems
No "intended" solution: Designer supports all approaches equally
Resource constraints create choices: Limited ammo/energy forces variety
Playstyle expression: Players develop personal playstyle (ghost, rambo, hacker)

REAL-WORLD EXAMPLE #5: Prey (2017) (Typhon Powers Emergence)

What Makes It Emergent

Orthogonal Powers:

Mimic: Transform into any object (infiltration, hiding, traversal)
Lift Field: Create gravity well, lift objects (combat, traversal, physics puzzles)
Kinetic Blast: Explosive force (combat, move objects, break structures)
Electrostatic Burst: Electric damage + EMP (combat, disable electronics)
Thermal: Fire damage (combat, melt ice, ignite objects)
Phantom Shift: Teleport (combat, traversal, stealth)

Interaction Matrix:

Mimic + Small object = Infiltrate vents
Mimic + Physics = Bypass "object weight" gates
Lift Field + Combat = Levitate enemies (disable, fall damage)
Lift Field + Traversal = Levitate self on object
Kinetic Blast + Lift Field = Launch objects at high velocity
Electrostatic + Water = Electrified area
Thermal + Ice = Melt frozen paths
Phantom Shift + Combat = Tactical repositioning

Emergent Solution Example:

Challenge: Reach high area, door locked from inside

Solution 1 (Intended): Find keycard elsewhere Solution 2 (GLOO gun): Shoot GLOO upward, climb platforms (emergent) Solution 3 (Mimic): Transform into small object, go through vent Solution 4 (Lift Field): Levitate on object (trash can), float upward Solution 5 (Recycler Charge): Throw charge near door, suck door inward (physics exploit)

Designer Decision: GLOO climbing was unintended but kept as feature (fits immersive sim philosophy)

Key Lessons

Embrace unintended solutions: GLOO climbing became beloved mechanic
Physics as mechanic: Consistent physics enables creative solutions
Orthogonal powers: Each power opens different possibilities
Immersive sim philosophy: "If player is creative, it's a feature"

CROSS-REFERENCES

Prerequisites (Learn These First)

From bravos/simulation-tactics (Pack 3):

simulation-vs-faking: Foundational skill for when to simulate vs fake
physics-simulation-patterns: Physics interactions underpin emergence
ai-and-agent-simulation: AI must react to emergent simulation state

Why these matter: Emergence requires simulation. Without simulation, you have scripted content. These skills teach how to build simulation foundations.

Building on This Skill (Learn These Next)

From bravos/systems-as-experience (Pack 4 - this pack):

systemic-level-design: Apply emergence principles to level design
dynamic-narrative-systems: Emergent storytelling from player actions
player-driven-economies: Economic emergence from trading/production systems
emergent-ai-behaviors: AI that creates emergent squad tactics
procedural-content-from-rules: Generate content from emergent rules

Why these matter: This skill teaches foundational emergence concepts. Other Pack 4 skills apply these concepts to specific domains.

Related Skills (Complementary Knowledge)

From ordis/security-architect (Pack 1):

threat-modeling: Emergence can create unintended security vulnerabilities
defense-in-depth: Layered defenses parallel layered emergence dampening

From muna/technical-writer (Pack 2):

documentation-structure: Document interaction matrices clearly
clarity-and-style: Explain emergence to team without ambiguity

TESTING CHECKLIST: How to Verify Emergence

Before shipping emergent system:

1. Orthogonality Tests

Property matrix filled: Each mechanic affects different properties (60%+ off-diagonal)
Multiplication verified: N mechanics create N×(N-1)/2 interactions (60-80% implemented)
No redundancy: No two mechanics do "the same thing"

2. Interaction Tests

Interaction matrix documented: All N×N interactions documented (60-80% implemented)
Cross-system interactions work: Physics + Chemistry + AI all interact
Cascade chains possible: 3-5 step chains happen regularly, 6+ steps rare

3. Feedback Loop Tests

Positive loops identified: All growth/snowball loops documented
Negative loops implemented: All positive loops have negative counterparts
Runaway test passed: No infinite growth in worst-case scenario
Stagnation test passed: Systems grow under optimal conditions
Equilibrium reached: Systems stabilize within 10-60 seconds

4. Solution Diversity Tests

Multiple solutions exist: Each challenge has 3+ solutions
Playtest diversity: 10 players find 5+ unique solutions
Designer surprise: Playtesters discover 5+ unintended solutions
No forced path: No challenge requires specific item/ability

5. Dominant Strategy Tests

Optimal strategy identified: Math or playtesting reveals best strategy
Usage < 70%: Optimal strategy used <70% of time
Counterplay exists: Every strategy has counter-strategy
Situational strength: No strategy is best in all situations

6. Constraint Tests

Not over-constrained: Playtest shows high solution diversity (5+ solutions)
Not under-constrained: Playtest shows players aren't confused
Goldilocks zone: 3-5 effective solutions, 1-2 optimal solutions per challenge

7. Architecture Tests

Systems interact: Physics, Chemistry, AI communicate via events or shared state
No silos: Systems aren't isolated modules
Consistent rules: Same rules apply everywhere (no special cases)

8. Documentation Tests

Interaction matrix accessible: Team can read and update matrix
Feedback loops documented: All loops identified and classified
Cascade examples documented: Sample 3-5 step chains written out
No prescriptive solutions: Docs don't say "Use X to solve Y"

9. Performance Tests

Cascade dampening works: No infinite cascades causing lag
Feedback loops stabilize: No runaway systems causing performance collapse
Interaction count manageable: Not checking N² interactions every frame

10. Player Experience Tests

Players feel creative: Post-playtest surveys show "I felt creative/clever"
Replayability high: Players want to replay to try different approaches
Emergent stories shared: Players naturally share "cool thing that happened"
No frustration: Players aren't confused or overwhelmed

ANTI-PATTERNS: What NOT to Do

Anti-Pattern #1: "Emergent" as Marketing Buzzword

Symptom: Claim game has "emergent gameplay" but it's actually scripted with random elements.

Example: "Emergent AI" that's just random behavior selection, not simulation-driven.

Why bad: Players feel deceived, "emergent" moments are actually scripted RNG.

Fix: Only claim emergence if systems truly interact to create surprising outcomes. Random ≠ Emergent.

Anti-Pattern #2: Emergence Without Constraints

Symptom: "Players can do anything!" but no goals, feedback, or consequences.

Example: Garry's Mod with no objectives (fun for some, overwhelming for others).

Why bad: Emergence without constraints is chaos, not gameplay.

Fix: Provide clear goals, feedback loops, and constraints to push against.

Anti-Pattern #3: Patching Emergent Tactics

Symptom: Players discover creative solution, designer patches it out as "unintended".

Example: Speed-running games patching glitches that speedrunners love.

Why bad: Kills player creativity, signals "don't experiment".

Fix: Use feature vs bug criteria. Only patch if trivializes ALL challenges or has no skill requirement.

Anti-Pattern #4: Interaction Matrix with 10% Coverage

Symptom: Many mechanics listed, but they don't actually interact (isolated systems).

Example: Baseline RED test response (Physics, Chemistry, AI separate).

Why bad: No emergence if systems don't interact.

Fix: Target 60-80% interaction matrix coverage. If <50%, systems are too isolated.

Anti-Pattern #5: Prescriptive Tutorials Killing Discovery

Symptom: Tutorial says "Use fire to melt ice", "Shoot barrels to kill enemies", etc.

Example: Loading screen tips that pre-solve puzzles.

Why bad: Players follow instructions instead of experimenting.

Fix: Show examples via environment (NPC using mechanic), don't tell explicitly.

FINAL NOTES: The Emergence Mindset

Design for Discovery, Not Instruction

Players feel smartest when they discover solutions themselves
Your job: Create possibility space, not guided tour
Resist urge to "help" players by prescribing solutions

Simple Rules, Complex Outcomes

3 mechanics with 10 properties each > 10 mechanics with 3 properties each
Depth from interaction, not number of features
Test: Can you explain core mechanics in 1 minute? If no, simplify.

Trust Player Creativity

Players will surprise you (this is good!)
"I didn't intend that" is a feature, not a bug (if it adds depth)
Best emergent games have designer humility: "I don't control outcomes, I set rules"

Balance is Ongoing

Emergence means meta-game evolves
Dominant strategies will emerge (that's ok)
Your job: Add counterplay, not remove strategies

Embrace Failure

Some interactions will be overpowered (patch them)
Some interactions will be useless (remove them)
Emergence is iterative, not one-shot design

WHEN YOU'RE READY

Once you've mastered emergent gameplay design, you can apply these principles to specific domains:

Systemic level design: Levels as possibility spaces
Dynamic narratives: Stories that emerge from player actions
Player-driven economies: Markets that self-balance
Emergent AI: Squad tactics from individual behaviors
Procedural generation: Content from rules, not templates

All of these build on the foundation you've learned here: Simple orthogonal rules → Complex emergent outcomes.

Remember: Emergence is not a feature you add. It's an architecture you design.

Install Skill

SKILL.md

Emergent Gameplay Design: Simple Rules → Complex Outcomes

Purpose

When to Use This Skill

Core Philosophy: Emergence as Design Goal

The Fundamental Truth

Emergence vs Scripting: The Spectrum

CORE CONCEPT #1: Orthogonal Mechanics (The Multiplication Principle)

What is Orthogonality?

Non-Orthogonal (Bad) Example

Orthogonal (Good) Example

The Multiplication Test

Real-World Example: Breath of the Wild

Design Process for Orthogonality

Common Orthogonality Failures

CORE CONCEPT #2: Interaction Matrices (The Possibility Map)

What is an Interaction Matrix?

Basic Interaction Matrix Format

Detailed Interaction Matrix (With Rules)

Interaction Count Analysis

Real-World Example: Noita

Design Process for Interaction Matrices

Common Interaction Matrix Failures

CORE CONCEPT #3: Feedback Loops (The Stabilization Principle)

What are Feedback Loops?

Positive Feedback (Runaway Growth)

Negative Feedback (Self-Correction)

Balanced Feedback (Dynamic Equilibrium)

Real-World Example: Dwarf Fortress Ecosystem

Feedback Loop Analysis Process

Common Feedback Loop Failures

CORE CONCEPT #4: Cascade Chains (The Surprise Principle)

What are Cascade Chains?

Cascade Length vs Predictability

Cascade Dampening (Preventing Infinite Chains)

Real-World Example: Breath of the Wild

Cascade Design Process

Common Cascade Failures

CORE CONCEPT #5: Systemic Solutions (The Multiple-Paths Principle)

What are Systemic Solutions?

Systemic vs Scripted Design

The Systemic Solution Checklist

Real-World Example: Deus Ex

Systemic Solution Design Process

Common Systemic Solution Failures

CORE CONCEPT #6: Emergence Testing Methodology

How Do You Know If Emergence is Happening?

Test 1: Solution Diversity Test

Test 2: Designer Surprise Test

Test 3: Interaction Coverage Test

Test 4: Cascade Length Distribution Test

Test 5: Dominant Strategy Test

Test 6: Runaway Condition Test

Emergence Testing Checklist

DECISION FRAMEWORK #1: Scripted vs Emergent (Control vs Surprise)

The Core Tradeoff

When to Choose Scripted

When to Choose Emergent

Hybrid Approach (Best for Most Games)

Decision Process

Example Decision Table

Common Decision Failures

DECISION FRAMEWORK #2: Constraint Tuning (Goldilocks Zone)

The Constraint Paradox

The Constraint Spectrum

Over-Constrained Warning Signs

Under-Constrained Warning Signs

Finding the Goldilocks Zone

Real-World Example: Dishonored

Constraint Tuning Process

Common Constraint Failures

DECISION FRAMEWORK #3: Exploit Handling (Feature vs Bug)

The Core Question

The Feature vs Bug Criteria

Feature Examples (Kept by Designers)

Bug Examples (Patched by Designers)

The Decision Process

Real-World Example: Prey (2017)

Exploit Handling Process