From 11781882a5e57cd94865116f636d6636ae3a77a5 Mon Sep 17 00:00:00 2001 From: Bryce Date: Tue, 17 Mar 2026 20:26:33 -0700 Subject: [PATCH] Add VitePress setup for browsing puzzle documentation --- .gitignore | 4 + docs/index.md | 53 +++++++++ docs/puzzles/cross-realm-logistics.md | 66 +++++++++++ docs/puzzles/distraction-physics.md | 55 +++++++++ docs/puzzles/environmental-storytelling.md | 66 +++++++++++ docs/puzzles/information-brokerage.md | 124 +++++++++++++++++++++ docs/puzzles/memo-chain.md | 50 +++++++++ docs/puzzles/meta-puzzle-construction.md | 95 ++++++++++++++++ docs/puzzles/metaphor-literal.md | 119 ++++++++++++++++++++ docs/puzzles/multi-faceted-plan.md | 97 ++++++++++++++++ docs/puzzles/observation-replay.md | 49 ++++++++ docs/puzzles/pattern-learning.md | 88 +++++++++++++++ docs/puzzles/sensory-exploitation.md | 99 ++++++++++++++++ docs/puzzles/timed-consequence.md | 62 +++++++++++ docs/puzzles/truth-revelation.md | 67 +++++++++++ vitepress.config.js | 35 ++++++ 16 files changed, 1129 insertions(+) create mode 100644 .gitignore create mode 100644 docs/index.md create mode 100644 docs/puzzles/cross-realm-logistics.md create mode 100644 docs/puzzles/distraction-physics.md create mode 100644 docs/puzzles/environmental-storytelling.md create mode 100644 docs/puzzles/information-brokerage.md create mode 100644 docs/puzzles/memo-chain.md create mode 100644 docs/puzzles/meta-puzzle-construction.md create mode 100644 docs/puzzles/metaphor-literal.md create mode 100644 docs/puzzles/multi-faceted-plan.md create mode 100644 docs/puzzles/observation-replay.md create mode 100644 docs/puzzles/pattern-learning.md create mode 100644 docs/puzzles/sensory-exploitation.md create mode 100644 docs/puzzles/timed-consequence.md create mode 100644 docs/puzzles/truth-revelation.md create mode 100644 vitepress.config.js diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..aebdb55 --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +node_modules/ +package-lock.json +dist/ +docs/.vitepress/ diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 0000000..f731b29 --- /dev/null +++ b/docs/index.md @@ -0,0 +1,53 @@ +# Puzzle Types in Adventure Games + +A taxonomy of puzzle design patterns derived from analysis of King's Quest VI: Heir Today, Gone Tomorrow and The Secret of Monkey Island, focusing on mechanics of information conveyance and player action. + +## Table of Contents + +| # | Puzzle Type | Core Mechanic | Game Source | +|---|-------------|---------------|-------------| +| 1 | [Multi-Faceted Plan Puzzle](./puzzles/multi-faceted-plan.md) | Requirements discovered incrementally; player synthesizes complete mental model | KQVI | +| 2 | [Sensory Exploitation Puzzle](./puzzles/sensory-exploitation.md) | Character perceptual vulnerabilities exploited through item matching | KQVI/MI | +| 3 | [Metaphor-to-Literal Translation](./puzzles/metaphor-literal.md) | Abstract language interpreted as literal game mechanics | MI | +| 4 | [Information Brokerage Chain](./puzzles/information-brokerage.md) | Implicit NPC exchange network mapped through incremental interaction | KQVI/MI | +| 5 | [Timed Consequence Puzzle](./puzzles/timed-consequence.md) | Narrative urgency without mechanical deadline; consequence is permanent story change | KQVI | +| 6 | [Environmental Storytelling Discovery](./puzzles/environmental-storytelling.md) | Information hidden in environment; discovered through examination, observation | KQVI | +| 7 | [Cross-Realm Logistics Puzzle](./puzzles/cross-realm-logistics.md) | Inventory management across multiple locations/realms; rewards forward planning | KQVI | +| 8 | [Truth Revelation Mechanic](./puzzles/truth-revelation.md) | Items reveal hidden truth; truth itself is the solution | KQVI | +| 9 | [Observation Replay Puzzle](./puzzles/observation-replay.md) | Single viewing of sequence, must reproduce exactly when opportunity arises | MI | +| 10 | [Pattern Learning / Knowledge Transfer](./puzzles/pattern-learning.md) | Learn rule set in low-stakes domain; apply exhaustively under consequences | MI | +| 11 | [Environmental Memo Chain](./puzzles/memo-chain.md) | Scattered written fragments across locations; synthesize narrative to reveal solution | MI | +| 12 | [NPC Distraction Physics](./puzzles/distraction-physics.md) | Manipulate environment to break NPC blocking pattern without confrontation | MI | +| 13 | [Meta-Puzzle Construction](./puzzles/meta-puzzle-construction.md) | Sequential interdependence; each step's output becomes next step's input | MI | + +--- + +## Core Principles + +These puzzle types share common characteristics that define adventure game puzzle design: + +### Limited Actions, Unlimited Combinations +The standard adventure game action set (LOOK, TALK, USE, WALK, TAKE) is applied in novel ways. The puzzle emerges from the *combination* of actions, not from complex input systems. + +### Information as Puzzle Element +The puzzle is often "what does the game know that I need to find out?" rather than "what do I need to do?" Information discovery is the primary mechanic. + +### Failure as Feedback +Failed attempts reveal information about what's missing or wrong. The puzzle teaches through consequences, not explicit instruction. + +### Synthesis Over Collection +The solution often requires combining information from multiple sources. No single action completes the puzzle—player must synthesize. + +--- + +## Documentation Structure + +Each puzzle type document contains: +- **Information Architecture**: How information is conveyed to the player +- **Player Action Pattern**: What the player does with that information +- **Core Mechanic**: The underlying puzzle logic +- **Variations**: Different ways this type can manifest +- **Adventure Game Implementation**: How limited actions (LOOK, TALK, USE, WALK) map to the puzzle +- **Example Structure**: Generic template showing how the puzzle works +- **Game Examples**: Concrete instances from walkthroughs (KQVI or MI) +- **Related Types**: Cross-references to similar puzzle mechanics diff --git a/docs/puzzles/cross-realm-logistics.md b/docs/puzzles/cross-realm-logistics.md new file mode 100644 index 0000000..7d93739 --- /dev/null +++ b/docs/puzzles/cross-realm-logistics.md @@ -0,0 +1,66 @@ +# Cross-Realm Logistics Puzzle + +## Mechanic Definition + +The player must manage items across multiple locations/worlds/states—transporting items between places, combining ingredients from different sources, or ensuring items survive transitions. The puzzle tests spatial and temporal thinking about inventory: what to carry, what to acquire, and when. + +"Realms" can be literal (dimensions, afterlife, parallel worlds) or figurative (factions, time periods, game states). + +## Information Architecture + +**Conveyance Method**: Requirement discovery through exploration +- Player learns what ingredients are needed through books, dialogue, or failed attempts +- Player must discover where each ingredient is located across different realms +- Player must determine how to transport/combine items appropriately + +**Player Action Pattern**: +1. Learn what's needed (through text or failed attempts) +2. Determine where each component is located +3. Travel to each location and acquire items +4. Transport items to combination point +5. Execute combination → solution achieved + +**Core Mechanic**: The puzzle tests forward planning and spatial awareness. Players must remember what they'll need in future locations while managing limited inventory space. + +## Design Rationale + +- Rewards planning—thinking ahead about future requirements +- Creates world interconnection—realms feel connected through items flowing between them +- Adds strategic depth—inventory management becomes meaningful +- Enables payoff moments—items from early exploration save you later + +## Why It's Effective + +The satisfaction comes from "just in time" inventory management—having the right item when you need it because you planned ahead. This rewards thorough exploration without punishing missed content. + +## Mechanic Variations + +| Variation | Realm Type | Logistics Challenge | +|-----------|-----------|-------------------| +| Dimensional | Parallel worlds | Items may not exist in all realms | +| Temporal | Time travel | Items must be retrieved before they're "taken" | +| Faction-based | Political states | Items must be traded between hostile groups | +| State-based | Game states | Items only available in certain conditions | + +## Generic Example Structure + +**Goal**: Complete [Crafting/Activation] requiring [Ingredients] + +**Information Flow**: +- Player learns through text: "The spell requires coal, egg, and hair" +- Player discovers locations: Coal at [Location A], Egg at [Location B], Hair at [Location C] +- Player must travel to each location and collect items +- Player must transport items to [Location D] for combination +- Player executes combination → spell complete + +**The puzzle**: Managing items across locations with limited inventory space and no explicit tracking of what's needed. + +## Adventure Game Implementation + +The limited action set creates specific challenges: +- WALK between realms—travel has cost/time +- Inventory management—limited space forces decisions +- USE items in correct sequence/location +- The puzzle rewards players who explore thoroughly early + +This puzzle tests: "Can I think spatially about where items are and plan my inventory accordingly?" diff --git a/docs/puzzles/distraction-physics.md b/docs/puzzles/distraction-physics.md new file mode 100644 index 0000000..0e5699c --- /dev/null +++ b/docs/puzzles/distraction-physics.md @@ -0,0 +1,55 @@ +# NPC Distraction Physics + +**Information Architecture**: NPC follows patrol/behavior pattern that blocks access to location or item. Blocking condition is *physical/spatial* rather than dialogue-based: line-of-sight, proximity triggers, or path obstruction. Solution requires manipulating environment to break the blocking condition without direct confrontation. + +**Player Action Pattern**: Observe NPC behavior loop. Identify environmental object/action that can exploit timing, physics, or AI limitations. Execute action to divert/obstruct/block NPC's attention or movement. Access previously blocked element during distraction window. + +**Core Mechanic**: Spatial/temporal manipulation creates opportunity window. Unlike Sensory Exploitation (direct vulnerability attack like tickle/sleep), DNP exploits *environment* + *NPC pathfinding/routine*. Player becomes environmental engineer, creating puzzle in 3D space using standard actions. + +**Variations**: +- Pull lever/activate object that NPC must investigate, breaking patrol pattern +- Create physical obstruction (object on tracks, blocking door) +- Redirect NPC attention via object manipulation (pull totem nose → monkey hangs there → NPC path rerouted) +- Timing puzzle: wait for patrol cycle gap + execute grab action in short window + +**Adventure Game Implementation**: +- LOOK at environment to spot interaction point that affects NPC behavior +- Standard WALK/USE/PULL/PUSH actions on environmental objects +- Observe NPC AI pattern (patrol route, reaction triggers) +- Trigger environmental change → NPC reroutes or becomes occupied → access granted + +**Example Structure**: + +``` +Blockage Phase: +→ Target [ITEM] protected by [NPC_GUARD] with patrol loop to [OBJECT] +→ Direct theft impossible ("Can't steal while watched!") + +Solution Phase: +→ Examine [ENVIRONMENTAL_OBJECT] within guard's patrol path/range +→ Realize action will divert NPC attention or alter movement pattern: + - USE object on [TRIGGER_POINT] creates distraction + - PULL [OBJECT] physically obstructs NPC path + - TIME window when NPC is investigating/occupies alternate location + +Execution Phase: +→ Activate environment while NPC distracted → Access [ITEM] during vulnerability window +→ Distraction must be sustained or timed precisely +``` + +**King's Quest VI Parallel**: None identified in walkthrough. + +**Monkey Island Example**: +- **Totem Pole / Monkey Blockade**: + - Goal: Enter Giant Monkey Head interior (blocked) + - Problem: Monkey guards it, standing on totem pole nose + - Solution: Pull Nose down → Monkey follows and hangs from pulled-down nose → Monkey physically occupies space away from gate → Access granted + - Distraction + spatial displacement = access + +--- + +## Related Types + +- **Sensory Exploitation**: Attacks NPC directly via vulnerability; DNP attacks NPC indirectly via environment +- **Timed Consequence**: Both use timing, but TC is about *narrative urgency deadline* while DNP creates player's own timing window +- **Multi-Faceted Plan**: DNP often uses simpler "one action breaks blockage" vs MFP's multi-requirement synthesis diff --git a/docs/puzzles/environmental-storytelling.md b/docs/puzzles/environmental-storytelling.md new file mode 100644 index 0000000..8d2236d --- /dev/null +++ b/docs/puzzles/environmental-storytelling.md @@ -0,0 +1,66 @@ +# Environmental Storytelling Discovery + +## Mechanic Definition + +The puzzle solution is knowledge, not items. Information is hidden within the game environment—through object examination, eavesdropping, spatial observation, or noticing changes between visits. The player must actively seek information rather than receive it through dialogue. + +## Information Architecture + +**Conveyance Method**: Environmental traces +- Objects contain hints when examined closely +- Eavesdropping reveals hidden conversations +- Spatial patterns across locations reveal connections +- Changes in environment between visits indicate time passage + +**Player Action Pattern**: +1. Notice something worth examining (LOOK, EXAMINE) +2. Discover information through close inspection +3. Synthesize information with other discovered facts +4. Use synthesized knowledge to determine next action + +**Core Mechanic**: The puzzle is about finding information the game doesn't explicitly tell you. There's no dialogue that says "the password is X"—you must discover it through environmental interaction. + +## Design Rationale + +- Rewards observation—players who examine carefully are rewarded +- Creates detective feel—the player becomes an investigator +- Integrates story and gameplay—learning the story IS the puzzle +- Avoids exposition dumps—information emerges organically + +## Why It's Effective + +The satisfaction comes from "stumbling" onto information. Finding something unexpected feels like discovery, not task completion. The world feels "lived in"—containing traces of what happened before the player arrived. + +## Mechanic Variations + +| Variation | Information Location | Discovery Method | +|-----------|---------------------|-------------------| +| Object-based | Items, furniture, documents | Close examination | +| Eavesdrop-based | Through walls, behind doors | Hidden conversation listening | +| Spatial | Pattern of locations, accessible routes | Mapping environment | +| Temporal | Changes between visits | Returning at different times | +| Synthesis | Multiple sources | Combining partial facts | + +## Generic Example Structure + +**Goal**: Learn [Information] + +**Information Flow**: +- Player notices locked door with no visible mechanism +- Player searches environment for how door might open +- Player finds secret passage through unusual interaction (examining object) +- In passage, player can eavesdrop on guards discussing half the information +- Player finds different location containing second half through examination +- Player synthesizes: [Half 1] + [Half 2] = [Complete Information] + +**The puzzle**: Information is never given explicitly—always discovered through environmental interaction. + +## Adventure Game Implementation + +The limited action set drives this puzzle entirely: +- LOOK/EXAMINE objects to find hidden information +- LISTEN for overheard conversations +- The puzzle exists in the environmental interaction, not in UI +- Player must remember what they found—external note-taking often required + +This puzzle tests: "Can I find information the game doesn't explicitly tell me?" diff --git a/docs/puzzles/information-brokerage.md b/docs/puzzles/information-brokerage.md new file mode 100644 index 0000000..e069e94 --- /dev/null +++ b/docs/puzzles/information-brokerage.md @@ -0,0 +1,124 @@ +# Information Brokerage Chain + +## Mechanic Definition + +The game world contains an implicit exchange network where NPCs trade items, services, and information—but the player must discover who trades what, and navigate the dependencies between trades. Nothing is free; everything requires something in return, often from a different source. + +The player acts as a broker: facilitating exchanges between parties who cannot or will not directly interact. + +## Information Architecture + +**Conveyance Method**: Demand discovery through interaction +- NPCs state what they want when asked or offered something +- The player must discover the network by attempting trades +- Information about what someone wants is often obtained from a third party + +**Player Action Pattern**: +1. Talk to NPC → learn what they want/offer +2. Determine if player has it OR knows someone who does +3. If not, find that person and learn their wants +4. Trace chain until player can fulfill a start-point +5. Execute trades in sequence → acquire target item/knowledge + +**Core Mechanic**: The puzzle is mapping an implicit dependency graph. No NPC tells you the full network—you discover it through incremental interaction. + +## Design Rationale + +- Creates a "living world" feel—NPCs have relationships beyond serving the player +- Rewards exploration—finding *who* has what matters as much as *where* it is +- Generates multiple valid paths—different items can satisfy the same demand +- Integrates narrative—trades tell stories about the world's economics + +## Why It's Effective + +The satisfaction comes from the "mapping moment"—realizing how everything connects. This is distinct from linear item acquisition because the player must understand the network, not just follow steps. + +## Mechanic Variations + +| Variation | Trade Discovery | Network Complexity | +|-----------|-----------------|-------------------| +| Linear | Each NPC points to next | Simple chain (A→B→C) | +| Branching | Multiple NPCs can provide same item | Tree structure | +| Cyclic | Items flow in a circle | Must bootstrap from nothing | +| Hidden | Some trades only appear after certain events | Progressive revelation | + +## Generic Example Structure + +**Goal**: Acquire [Item] from [NPC Final] + +**Information Flow**: +- NPC Final: "I'll give you [Item] for [Something]. Talk to [NPC A] about that." +- NPC A: "I need [Thing 1]. The only one who has it is [NPC B]." +- NPC B: "I'll trade [Thing 1] for [Thing 2]. Try the [Location]." +- Player finds [Thing 2] through exploration +- Returns to NPC B → gets [Thing 1] +- Returns to NPC A → gets [Something] +- Returns to NPC Final → gets [Item] + +**The puzzle**: Mapping the trade dependency graph through incremental discovery. + +## Adventure Game Implementation + +The limited action set drives the mechanic: +- TALK to NPCs to learn what they want/offer +- GIVE/USE items on NPCs to attempt trades +- The network is discovered through failed attempts ("I don't want that") +- Player must remember what each NPC said—external note-taking often required + +## Game Examples + +### Monkey Island I: Prisoner Exchange Chain + +**Network Structure**: +``` +Player → [Breath Mints] → Otis (Prisoner) +Otis → [Gopher Repellant] → Player +Player → [Gopher Repellant] → Otis +Otis → [Cake with hidden File] → Player +Player → [File] → Escape rope underwater +``` + +**Discovery Process**: +1. Prison has "chronic halitosis" problem → player hypothesizes: what cures bad breath? +2. Shop sells Breath Mints → acquire for 1 Piece of Eight +3. Give mints to Otis → he trades Gopher Repellant (seemingly unrelated) +4. Player must infer repellant's purpose through word association ("gophers" + "piranhas guard mansion") +5. Use repellant on poodles earlier OR give back to Otis → he gives Cake containing File + +**Why It's Brokerage**: Player doesn't directly buy the File from anyone; they facilitate a multi-step exchange chain by satisfying each NPC's needs in sequence. + +### Monkey Island I: Meat/Poodle/Governor Mansion Chain + +**Network Structure** (simplified): +``` +Butcher → [Meat] → Player +Player + Yellow Petal → [Meat with Condiment] +[Meat with Condiment] → Piranha Poodles → Daze them +Unblocked door → Access Governor's Mansion +``` + +**Discovery Process**: +1. Cook mentions "piranhas won't let me pass but they LOVE meat" +2. Player has raw meat from butcher earlier (seemingly useless at that time) +3. Yellow petal found on fork path → player experiments: What if meat + condiment = better bait? +4. Combination dazes poodles long enough to bypass + +**Why It's Brokerage**: Requires understanding NPC "tastes" as part of the trade network—poodles won't accept raw meat but will for prepared dish. Information flows through overheard dialogue about character preferences. + +### Monkey Island II: Map Piece Acquisition (Meta Network) + +Each map piece requires completing a different sub-trade chain with the Antiques Dealer as hub: +- **Rapp Scallion**: Need key to Weenie Hut → need reanimated corpse → need ashes + Ash-2-Life recipe from library → voodoo lady forgot recipe → find book → return +- **Young Lindy**: Trade monkey head → locate shipwreck coordinates from library → charter Kate's boat (cost: 6000 gold) → earn money through spitting contest scam +- **Mister Rogers**: Need to bypass waterfall → need monkey to operate pump → need banana + metronome to distract parrot → enter tunnel + +All branches converge at Wally the cartographer who assembles the final map. + +--- + +## Related Types + +- **Multi-Faceted Plan**: Both involve multiple requirements, but MFP is about parallel discovery (ingredient A AND B AND C) while Brokerage emphasizes chained dependencies (Item A gets you Thing B which trades for Target) +- **Pattern Learning/Knowledge Transfer**: KT teaches a reusable *system*; Brokerage is one-off network mapping per puzzle instance + +This puzzle tests: "Can I map the implicit exchange network through incremental interaction?" diff --git a/docs/puzzles/memo-chain.md b/docs/puzzles/memo-chain.md new file mode 100644 index 0000000..ad334cb --- /dev/null +++ b/docs/puzzles/memo-chain.md @@ -0,0 +1,50 @@ +# Environmental Memo Chain + +**Information Architecture**: Written fragments (notes, memos, signs) distributed across multiple locations in the game world. Each fragment contains piece of larger narrative or set of instructions. Information is presented as background "worldbuilding" but collectively encodes puzzle solution. + +**Player Action Pattern**: Collect scattered written items through exploration. Read/compare contents mentally or against notes taken while exploring. Synthesize connections between seemingly unrelated memos to deduce location, character motive, or required item/action. + +**Core Mechanic**: Distributed text fragments → player-assembling narrative → puzzle answer revealed through reading comprehension + spatial mapping. No single memo contains full solution; meaning emerges from combination. + +**Variations**: +- Comic interoffice memos between game characters (complaints about each other) +- Trail notes left by previous adventurers +- Scattered diary pages out of chronological order +- Cryptic signs/inscriptions requiring reordering or cross-referencing + +**Adventure Game Implementation**: +- LOOK at scattered items across world (piles of paper, bulletin boards, ground litter) +- Text is collected as inventory or viewed in situ and remembered +- Player must map memo locations + connect content themes +- Standard exploration actions; puzzle is in reading comprehension + memory + +**Example Structure**: + +``` +Discovery Phase: +→ Explore Location A: LOOK at note → "Don't leave key here - [CHAR_B] will find it" +→ Explore Location B (unrelated): LOOK at memo → "[CHAR_A], I stole your backdoor entrance!" +→ Explore Location C: LOUK at sign → "Restricted area: Monkey Head Base" + +Synthesis Phase: +→ Compare all fragments mentally +→ Deduce relationship between characters, location hierarchy, item flow +→ Solution emerges: [KEY] was hidden in [MONKEY_HEAD] by [CHAR_A] to hide from [CHAR_B] +``` + +**King's Quest VI Parallel**: None identified in walkthrough. + +**Monkey Island Example**: +- **LeChuck Base Discovery**: Three memos scattered across different screens: + - Beach memo: "Please return our key to the Monkey Head" (Cannibals warning) + - River Fork memo: Complaint about LeChuck's noisy activities in Sacred Monkey Head area, saw him taking woman with scarf there + - Pond memo: LeChuck warns Cannibals not to enter Monkey Head, calls it his "secret base of operations" + - **Synthesis**: Monkey Island = LeChuck's hideout; must investigate the Giant Monkey Head interior + +--- + +## Related Types + +- **Environmental Storytelling**: Broader category; memo chains are text-specific subset +- **Multi-Faceted Plan**: Memo chains often INFORM multi-faceted plans, but the memo system itself is distinct in its distribution + synthesis mechanic +- **Information Brokerage**: Both involve information gathering, but memo chains are environmental (world-to-player) vs NPC-to-player exchanges diff --git a/docs/puzzles/meta-puzzle-construction.md b/docs/puzzles/meta-puzzle-construction.md new file mode 100644 index 0000000..f59e4f9 --- /dev/null +++ b/docs/puzzles/meta-puzzle-construction.md @@ -0,0 +1,95 @@ +# Meta-Puzzle Construction / Sequential Interdependence + +**Information Architecture**: Puzzle components are chained linearly where Step N's OUTPUT becomes Step N+1's INPUT. Unlike Multi-Faceted Plan's parallel requirement gathering (A AND B AND C independently found), Meta-Construction requires sequential execution—each action creates the resource needed for the next action. Cannot reorder steps; cannot pre-gather all components. + +**Player Action Pattern**: +1. Complete Step 1 → receive Output Item A +2. Use Item A in context of Step 2 → produce Output Item B +3. Repeat until final step produces Target Solution +4. Backtracking required if wrong interpretation leads to dead-end output + +**Core Mechanic**: The puzzle is a *production line* where the player crafts their way through. Each action's product is only valuable within the specific chain—it has no other use. This creates "no-branch" progression: exactly one valid sequence exists. + +--- + +## Variations + +| Type | Interdependence | Branching Allowed? | Example | +|------|----------------|--------------------|---------| +| **Linear Chain** | N's output = N+1's sole input | No | Dinky Island Water Filtration | +| **Branched Assembly** | Multiple paths to same output item | Yes, converges later | Some crafting puzzles | +| **Conditional Branching** | Output determines which branch unlocks | Depends on output value | Code-cracking sequences | +| **Resource Accumulation** | Each step produces partial completion | No, accumulative | Multi-stage recipes requiring mixing | + +--- + +## Game Examples + +### Monkey Island II: Dinky Island Water Filtration System + +**Complete Chain**: +1. Pick up Bottle (empty, capped) +2. Use Bottle on Rock → Broken Bottle + Crowbar +3. Use Crowbar on Barrel → Cracker #1 revealed +4. Feed Cracker #1 to Parrot → Direction 1 ("East of pond to dinosaur") +5. Note: To activate still for distilled water, need more crackers +6. Use Broken Bottle as funnel into Still → creates distillation capability +7. Obtain Glass O' Water from ocean → use with Still → Distilled Water +8. Find empty Box (low-sodium cracker mix) on jungle path +9. Use Distilled Water on Box → produces Cracker #2 AND #3 +10. Feed remaining crackers to Parrot → Directions 2 & 3 + +**Final Synthesis**: Three directions from parrot = navigation map to X marks the spot + +**Why It's Meta-Construction (Not Multi-Faceted Plan)**: +- Cannot gather all 3 crackers in parallel—must sequence production +- Broken Bottle is only useful for crowbar extraction; crowbar only for barrel opening +- Each intermediate state has exactly one valid forward move +- Back-tracking creates dead-ends ("Can't make more crackers without water, can't get water without still access, still needs broken bottle as funnel") + +### Monkey Island II: Rat Trap → Job Acquisition Chain (Hard Mode Only) + +``` +1. Collect String (Voodoo Lady's skull) + Stick (Beach) + Cheese Squiggles (Inn bowl) +2. Assemble trap at Mad Marty's Laundromat: Box + Sticking on stick + cheese bait +3. Trap activates → Captured Rat in box +4. Enter Bloody Lip kitchen, throw rat into Vichyssoise stew +5. Cook fired for contaminating food (barkeeper dialogue) +6. New job position opens: Kitchen assistant, 420 Pieces of Eight salary advance +7. Money enables chartering Captain Dread's boat +``` + +**Key Feature**: Player *creates* an opportunity by engineering a job vacancy through cascading consequences. + +--- + +## Distinction from Related Types + +| Type | Structure | Why Meta-Construction is Different | +|------|-----------|------------------------------------| +| **Multi-Faceted Plan** | Parallel requirements (A + B + C) | MFP = assemble pieces; MC = sequential assembly line | +| **Pattern Learning** | Same rules apply to Domain A then B | MC = each step has unique mechanic, no transfer | +| **Observation Replay** | Watch once, reproduce exactly | MC = create new output at each step, not repeat input | + +--- + +## Design Considerations + +**Advantages**: +- Clear progression—easy for designers to scope difficulty curve +- Player feels like "master craftsman" building solution piece by piece +- Satisfying when chain completes after multiple steps + +**Risks**: +- Backtracking frustration if player misses a step's output +- Feels like "fetch quest lite" if intermediate items have no flavor/usefulness +- Can become tedious without narrative justification for the sequence + +**Best Practice**: Each intermediate output should be *thematically meaningful* (bottle → crowbar makes sense physically; cracker mix + water = crackers follows real-world logic) rather than arbitrary ("Magic Stone #3" → "Magic Portal Key"). + +--- + +## Related Types + +- **Multi-Faceted Plan**: When requirements discovered in parallel, not sequence +- **Recipe Discovery**: When puzzle is learning the correct combination formula, not executing fixed steps diff --git a/docs/puzzles/metaphor-literal.md b/docs/puzzles/metaphor-literal.md new file mode 100644 index 0000000..7a4c17b --- /dev/null +++ b/docs/puzzles/metaphor-literal.md @@ -0,0 +1,119 @@ +# Metaphor-to-Literal Translation + +## Mechanic Definition + +The game presents abstract language—idioms, metaphors, poetic descriptions, or symbolic phrases—as puzzle instructions. The player must interpret figurative language as literal game mechanics: what would this phrase look like if it could physically exist in the game world? + +## Information Architecture + +**Conveyance Method**: Text-based symbolic language +- Phrases appear in dialogue, item descriptions, book text, or environmental signage +- The solution requires "translating" the metaphor into concrete game objects/actions +- No explicit instruction—the player must recognize the symbolic nature + +**Player Action Pattern**: +1. Encounter metaphorical phrase in text +2. Identify what the phrase would mean if taken literally +3. Locate or create the literal equivalent in the game world +4. Execute literal action → solution achieved + +**Core Mechanic**: The puzzle tests linguistic creativity—can the player imagine what "wallflowers" literally looks like in a game with flowers? + +## Design Rationale + +- Creates world coherence—language manifests physically, making the world feel internally consistent +- Rewards literary thinking—players who engage carefully with text are advantaged +- Generates memorable moments—literalized metaphors become distinctive visual/cognitive landmarks +- Avoids generic solutions—each phrase has unique literal translation + +## Why It's Effective + +The "aha" moment is distinct: recognizing that a phrase is symbolic rather than descriptive. This requires active reading rather than passive scanning—a skill that distinguishes engaged players. + +## Mechanic Variations + +| Variation | Text Type | Literal Translation Approach | +|-----------|-----------|------------------------------| +| Idiom | Common sayings | Identify physical objects that represent the idiom's meaning | +| Poetic | Descriptive verse | Visualize the imagery as actual game elements | +| Symbolic | Heraldic/mythic language | Map symbols to game objects through cultural knowledge | +| Invented | Game-specific phrases | Learn the game's symbolic vocabulary through context | + +## Generic Example Structure + +**Puzzle Text**: "You will need salt water not from the sea to complete the binding." + +**Information Flow**: +- Player reads text → recognizes metaphorical instruction +- Player asks: "What could 'salt water not from the sea' literally be?" +- Options: tears (salty), magical solution, mineral water +- Player examines game world: Are there crying things? Plants with "tears"? +- Player discovers: A patch of "baby's tears" plants that can be made to cry +- Player finds: A way to make them cry (give milk to one, others cry in sympathy) +- Player collects: The literal "tears" + +**The puzzle**: Translating "salt water not from the sea" → "plant tears" through symbolic interpretation. + +## Adventure Game Implementation + +The limited action set maps directly to this puzzle: +- LOOK at text contexts (signs, books, dialogue) where phrases appear +- EXAMINE objects referenced in phrases—do they have literal counterparts? +- USE items that match the literal interpretation +- The puzzle is fundamentally about mapping text to world + +## Game Examples + +### Monkey Island I: Troll's Red Herring Riddle + +**Metaphor**: "I want something that will attract attention but have no real importance" + +**Literal Translation Chain**: +1. Player reads riddle as abstract requirement +2. Interprets: "What object is literally known for 'attracting attention' yet being 'unimportant'?" +3. Identifies idiom: "red herring" — distracting but irrelevant detail in storytelling/mystery +4. Searches inventory: What's a literal RED HERRING? → Fish (which are often painted red as decoration) +5. Execute: Give the Fish to Troll +6. Troll's confirmation: "Ah! A red herring!" reveals the idiom was intentionally chosen + +**Design Elegance**: The phrase exists simultaneously as genuine puzzle instruction AND as a common English metaphor—the player wins by recognizing both layers. + +### Monkey Island II: Bone Maze Navigation Song + +**Metaphor (from dream sequence)**: +``` +The HEAD bone is connected to the RIB bone. +The RIB bone is connected to the LEG bone. +The LEG bone is connected to the HIP bone. +``` + +**Literal Translation Chain**: +1. Player experiences bizarre song during near-death dream state +2. Later faces maze of "Ugly Bone Things" — wall panels with different bone carvings +3. Recognizes: Song lyrics describe physical connections between bones +4. Translation rule emerges: Each verse maps to one passage; push the FIRST three bones mentioned (fourth is irrelevant noise) +5. Execute sequence: HEAD → RIB → LEG passages, ignoring HIP each time +6. Result: Passageway opens, progress granted + +**Key Distinction**: This is metaphor-to-literal because the song (poetic/abstract encoding) describes a PHYSICAL system (bone maze walls). Not "learn pattern" but "decode artistic encoding into mechanical solution." + +--- + +## Common Misidentifications + +| Apparent Metaphor | Why It's Different | +|------------------|--------------------| +| Dance map = navigation instructions (MI1 fake map) | These are LITERAL dance moves applied as path choices, not metaphorical language | Pattern Learning / Code Translation | +| Voodoo doll categories ("something of the Thread") | Categories are literal requirements, not symbolic phrases being decoded | Multi-Faceted Plan | + +**Test**: Is the text *figurative* (requires linguistic creativity to interpret) or *literal instructions in disguised form* (requires pattern recognition)? Metaphor-to-Literal requires the former. + +## Adventure Game Implementation + +The limited action set maps directly to this puzzle: +- LOOK at text contexts (signs, books, dialogue) where phrases appear +- EXAMINE objects referenced in phrases—do they have literal counterparts? +- USE items that match the literal interpretation +- The puzzle is fundamentally about mapping text to world + +This puzzle type tests: "Can I imagine what this phrase would look like if the game world took it literally?" diff --git a/docs/puzzles/multi-faceted-plan.md b/docs/puzzles/multi-faceted-plan.md new file mode 100644 index 0000000..65b4dac --- /dev/null +++ b/docs/puzzles/multi-faceted-plan.md @@ -0,0 +1,97 @@ +# Multi-Faceted Plan Puzzle + +## Mechanic Definition + +The player receives requirements for a solution incrementally—some explicit, some implicit—through failed attempts, character dialogue, and world state observation. The puzzle is "solved" not by executing a single action, but by assembling a complete mental model of what's needed. + +## Information Architecture + +**Conveyance Method**: Partial disclosure +- Initial contact: Player learns *something* is needed, but not what +- Failed attempts: Reveal what is missing through character reactions or internal monologue +- Synthesis: Player combines scattered clues to form complete requirements + +**Player Action Pattern**: +1. Attempt solution → fails → learn gap +2. Address gap → attempt again → learn next gap +3. Repeat until complete mental model assembled +4. Execute complete plan + +**Core Mechanic**: The puzzle exists in the player's notebook/information management, not in the UI. No checklist is provided. + +## Design Rationale + +- Rewards deep world engagement—talking to NPCs, exploring thoroughly +- Creates "designer collaboration" feeling—the player feels they built the solution +- Avoids "fetch quest" feel by requiring synthesis, not collection +- Failure is informative, not punitive + +## Why It's Effective + +The satisfaction comes from the synthesis moment—realizing "I need all three of these" after discovering each requirement in different contexts. This is distinct from "collect 3 items" because the player *must* infer the collection list themselves. + +## Mechanic Variations + +| Variation | Information Conveyance | Solution Discovery | +|-----------|----------------------|-------------------| +| Dialogue-driven | NPCs mention missing components indirectly | Player must connect separate conversations | +| Environmental | World state changes after partial completion | Player notices what's now accessible | +| Trial-and-error | Failed attempts explicitly state what's missing | Player iterates through gaps | +| Deduction | Partial info requires logical inference | Player pieces together from clues | + +## Generic Example Structure + +**Initial State**: Player faces obstacle. Attempting to overcome fails with feedback. + +**Information Flow**: +- Character A mentions needing "something from the east" +- Character B mentions "I haven't seen [item] since [location]" +- Examining [location] reveals [item] is present but requires [action] +- Completing [action] provides [item] +- Returning to obstacle with [item] reveals *another* requirement + +**Player synthesizes**: The complete solution is never stated; player builds it from fragments. + +## Game Examples + +### Monkey Island II: Voodoo Doll Construction (Largo) + +**Requirement Discovery**: +1. Talk to Voodoo Lady → Learn 4 categories needed: Thread, Head, Body, Dead +2. **No single source explains all four sub-requirements**; player must explore each category + +**Incremental Solution Assembly**: +- **Thread**: Access Largo's room (requires innkeeper distraction via escaped alligator) → laundry ticket → trade at laundromat for pearly-white bra +- **Head**: Same room access → pick up toupee with lice +- **Body**: Bar scene shows Largo spitting on wall → collect paper from cartographer → absorb spit +- **Dead**: Cemetery exploration → find ancestor tombstone → dig grave with shovel (torn from signpost) + +**Synthesis**: Player must track 4 categorical requirements, each solved by distinct sub-puzzles. No explicit checklist; discovery through failed assumptions ("I can't get his clothes directly" → "Maybe laundry works?"). + +### King's Quest VI: [Pending walkthrough re-analysis] + +--- + +## Related Types + +- **Pattern Learning/Knowledge Transfer**: Both involve multi-step processes, but KT is about *same system in different domain* whereas MFP is about *different requirements for single goal* +- **Meta-puzzle Construction (below)**: Distinct from pure Multi-Faceted Plan by requiring sequential interdependence rather than parallel requirement gathering + +## Meta-puzzle Construction Variation + +A subtype of Multi-Faceted Plan where component puzzles must be COMPLETED in sequence, each enabling the next. Unlike standard MFP's parallel track gathering: + +| Standard MFP | Meta-puzzle Construction | +|--------------|-------------------------| +| Four ingredients can be found in any order | Each step unlocks next puzzle state | +| Synthesis = all requirements assembled | Synthesis = correct sequence discovered | +| Example: Voodoo doll (all 4 gathered independently) | Example: Dinky Island water filtration | + +**Dinky Island Water Filtration (MI2)**: +1. Find bottle → break on rock to get crowbar +2. Open barrel with crowbar → obtain cracker +3. Feed cracker to parrot → receive still activation clue +4. Use broken bottle as still intake → produce distilled water +5. Use water + box of cracker mix → more crackers for remaining directions + +Each component *depends* on previous step's output; parallel gathering impossible. diff --git a/docs/puzzles/observation-replay.md b/docs/puzzles/observation-replay.md new file mode 100644 index 0000000..3a78eaf --- /dev/null +++ b/docs/puzzles/observation-replay.md @@ -0,0 +1,49 @@ +# Observation Replay + +**Information Architecture**: Game presents a procedural sequence once, under observation-only conditions (guard present, locked door, NPC interference). Player cannot interact during the demonstration. + +**Player Action Pattern**: Watch and memorize the exact sequence of actions or values. Return when guard/interference is absent. Replay sequence precisely to unlock new access. + +**Core Mechanic**: Single viewing + exact reproduction = reward. Information is presented in correct order once; puzzle difficulty emerges from memory load plus opportunity management. + +**Variations**: +- Numeric sequences (safe combinations, door codes) +- Action sequences (push/pull patterns, dance moves) +- Visual patterns (light arrangements, color orders) + +**Adventure Game Implementation**: +- NPC performs action while blocking player interaction +- Cutscene triggers once, cannot be rewound +- Player must note sequence through observation alone +- Return later when conditions allow replication +- Standard actions (USE TALK LOOK) applied in memorized order + +**Example Structure**: + +``` +Player needs: Access to [LOCKED_LOCATION] + +Discovery Phase: +→ Approach [LOC] and observe [NPC] perform exact sequence: + "Watch as guard opens safe: PULL-15, PUSH-3, PULL-27" +→ Blocked from interacting ("Can't touch while watched!") + +Return Phase: +→ Create opportunity (distract NPC, wait for departure) +→ Apply memorized sequence to [OBJECT] with same standard actions: + USE safe → PULL handle 15 times... +→ Reward unlocked +``` + +**King's Quest VI Parallel**: None identified in walkthrough. + +**Monkey Island Examples**: +- **Safe Combination**: Storekeeper opens safe while player watches (notes combination). Later, when storekeeper leaves shop unsupervised after going to find Sword Master, player returns and enters exact PULL/PUSH sequence he observed. + +--- + +## Related Types + +- **Multi-Faceted Plan**: Requires synthesis of multiple requirements discovered at different times +- **Timed Consequence**: Both involve missing opportunities, but OR is about *memory* + *timing* while TC is about narrative urgency +- **Information Brokerage**: Both involve NPCs as information sources, but OR focuses on *action sequences* not exchange networks diff --git a/docs/puzzles/pattern-learning.md b/docs/puzzles/pattern-learning.md new file mode 100644 index 0000000..61a8b65 --- /dev/null +++ b/docs/puzzles/pattern-learning.md @@ -0,0 +1,88 @@ +# Pattern Learning / Knowledge Transfer + +**Information Architecture**: Game teaches a complete mechanical system in a low-stakes domain, then requires application of exact same rules in higher-stakes domain against different target. The tutorial IS the training—no explicit instruction, only pattern discovery through interaction. + +**Player Action Pattern**: Engage with training instances exhaustively to discover full rule set. Internalize cause/effect mappings (insult A → retort B). Face final application where mechanics are identical but consequences escalate (more rounds, permanent failure state, critical plot progression). + +**Core Mechanic**: The learning domain and application domain share IDENTICAL underlying rules. Player success depends on recognizing that Domain A was never a different puzzle—it WAS the solution manual for Domain B. This is NOT "practice makes perfect" through repetition; it's "this system you just learned operates elsewhere." + +**Variations**: +- Combat dialogue systems (insult/retort pairs) +- Construction/crafting frameworks (ingredient categories → application recipe) +- Code/password mechanics where training example uses same algorithm as lock + +**Adventure Game Implementation**: +- Tutorial or "optional" early-game puzzles that teach full system +- Standard TALK/USE actions reveal mechanical rules through trial/error +- Later puzzles invoke same mechanic with different flavor/text/skins +- Player must recognize: the framework hasn't changed, only the context + +--- + +## Example Structure + +### Swordfight Combat System (MI1) + +``` +Learning Phase: +→ Encounter 4 types of roaming pirate NPCs with combat mini-game +→ Each duel reveals subset of insult/retort rule mappings +→ Exhaust all 16 combinations: learn every insult → correct retort pair +→ Rule: If opponent uses wrong retort, you win point; if they use right one, they win + +Application Phase: +→ Sword Master fight introduces NEW insult text (20+ different lines) +→ BUT: Same 16 retort rules apply to mapped insults +→ Pattern recognition critical: "My tongue is sharper" → maps to feather-duster rule +→ First to 5 points wins (vs training's first-to-3) +``` + +### Voodoo Doll Construction Framework (MI2) + +``` +Learning Phase (Act I - Largo): +→ Voodoo Lady explains 4 ingredient categories for curse doll: + 1. Something of the Thread (clothing) + 2. Something of the Head (hair/hairpiece) + 3. Something of the Body (bodily fluids) + 4. Something of the Dead (ancestor bone/remains) +→ Player gathers these 4 types for Largo doll successfully +→ Complete doll construction = working framework learned + +Application Phase (Part IV - LeChuck): +→ After explosion, discover same Juju Bag mechanic +→ Framework from Act I applies: need Thread/Head/Body/Dead components +→ New instances of each category: Skull (Head), Beard Bits (Body), + Underwear (Thread), Used Hanky (fluid) +→ Apply same construction recipe → empowered doll works on LeChuck +``` + +--- + +## Key Identifiers + +1. **Same mechanic, different skin**: Not "I learned to make Largo's curse" but "I learned the voodoo doll system" +2. **Exhaustible rule space**: Finite complete system can be discovered (16 insults, 4 categories) +3. **Domain transfer**: Learning happens in Domain A, application in Domain B, mechanics identical +4. **No new teaching**: Application phase provides zero tutorials; assumes player recognized the system + +--- + +## Related Types + +- **Multi-Faceted Plan**: Both gather across multiple steps, but MFP has different *categories* of requirement (key+code+distracter), not one unifying *system* +- **Observation Replay**: OR reproduces exact sequence verbatim; KT applies rules to new targets +- **Environmental Storytelling**: KT often includes world text, but puzzle is the mechanic transfer, not narrative connection + +--- + +## Common Misidentifications (NOT Knowledge Transfer) + +| Apparent Similarity | Why It's Different | Actual Type | +|--------------------|---------------------|-------------| +| Password game: learn finger-counting logic → apply to 3 doors | Single-domain application, no mechanical transfer | Pattern Recognition / Logic Puzzle | +| Parrot directions: feed crackers → get navigation clues | Information collection, not system learning | Multi-Faceted Plan (direction synthesis) | +| Spitting contest: watch wind timing → spit in window | Observation + execution of single puzzle | Environmental Timing Puzzle | +| Bone maze dream: song lyrics → corridor mapping | Cryptic message decoding | Metaphor-to-Literal Translation | + +**Critical Test**: Could you describe the solution as "I learned [SYSTEM] that applies to both [CONTEXT A] and [CONTEXT B]"? If not, it's not Knowledge Transfer. diff --git a/docs/puzzles/sensory-exploitation.md b/docs/puzzles/sensory-exploitation.md new file mode 100644 index 0000000..39a4e56 --- /dev/null +++ b/docs/puzzles/sensory-exploitation.md @@ -0,0 +1,99 @@ +# Sensory Exploitation Puzzle + +## Mechanic Definition + +A character or obstacle has a defined perceptual vulnerability. The player must determine what sense the character trusts, then provide a counter-stimulus that exploits that specific perception. The solution is never "use force"—it's "become the thing their perception accepts." + +## Information Architecture + +**Conveyance Method**: Character self-disclosure + trial +- Characters explicitly state their dominant sense (e.g., "I trust only what I hear") +- The solution item must match what that sense would recognize +- Wrong items reveal failure but don't teach the correct answer + +**Player Action Pattern**: +1. Talk to character → learn dominant sense +2. Determine what that sense would accept as "safe" +3. Find item matching that sensory profile +4. Use item on character → passes through + +**Core Mechanic**: The puzzle is a two-step inference: +- What sense? (explicitly stated) +- What would that sense trust? (player must deduce from item properties) + +## Design Rationale + +- Creates character depth through defined perception profiles +- Rewards observation—players must listen to what characters say about themselves +- Avoids violence entirely—the solution is always cognitive, not confrontational +- Enables "identity transformation" through items—you become what the obstacle accepts + +## Why It's Effective + +The puzzle teaches players to treat NPCs as individuals with specific vulnerabilities, not generic obstacles. The satisfaction comes from matching the right sensory input to the right sensory receiver—a pattern recognition that scales across multiple characters. + +## Mechanic Variations + +| Variation | Information Conveyance | Solution Approach | +|-----------|----------------------|-------------------| +| Self-declaring | Character states their sense explicitly | Player matches item to stated sense | +| Observed | Player watches other characters pass/fail | Player deduces from observed solutions | +| Inferred | Character describes world through one sense | Player identifies which sense by language | +| Progressive | Each character reveals next challenge's sense | Player builds inventory for sequence | + +## Generic Example Structure + +**Obstacle**: A guardian who only allows those they trust to pass. + +**Information Flow**: +- Guardian: "I judge all who enter by sound alone. The rhythm of your heart tells me if you are true." +- Player deduces: Need something that produces the "right sound" +- Player examines inventory: Which items produce sound? +- Player selects: Wind-up toy, musical instrument, recorded voice +- Player uses on guardian → passes or fails + +**The puzzle**: Matching item property (sound-producing) to character sense (hearing-based trust). + +## Adventure Game Implementation + +The limited action set creates specific interaction patterns: +- TALK reveals what sense the character uses +- LOOK examines item properties (color, texture, sound, smell) +- USE applies item to character—failure provides feedback but not solution +- The solution requires cross-referencing character dialogue with item properties + +## Game Examples + +### Monkey Island II: Parrot's Visual Fixation + +**Vulnerability**: Visual/rhythmic obsessions (parrots attracted to repetitive movement) + +**Exploitation Chain**: +1. Player observes Jojo the parrot fixated on metronome at Bloody Lip bar +2. Hypothesis: Parrots can't resist rhythmic visual stimuli +3. Find Banana → use on Metronome → parrot becomes entranced watching banana swing +4. While distracted, player captures Jojo from cage + +**Key Distinction**: This is sensory exploitation because the player identifies and manipulates a specific perceptual vulnerability (rhythmic visual fixation) rather than applying generic distraction. + +### Monkey Island I: Piranha Poodle Food Attraction + +**Vulnerability**: Olfactory/gustatory—poodles cannot resist certain food scents + +**Exploitation Chain**: +1. Cook's dialogue reveals: "Piranha poodles love meat!" +2. Player has raw Hunk of Meat (from earlier fetch) +3. Discover Yellow Petal = edible condiment when combined with meat +4. Use Meat + Petal → Meat with Condiment +5. Give to Poodles → they're knocked out by overeating + +**Why It's Sensory Exploitation**: Player exploits the poodles' sensory weakness (gluttony/food obsession) by providing an irresistible stimulus, not through combat or stealth. + +--- + +## Related Types + +- **Distraction Physics**: Both create temporary access, but DNP uses environmental manipulation while SE directly targets character perception +- **Information Brokerage**: Both involve NPC needs/wants, but IB is about trade/exchange while SE is about vulnerability exploitation + +The puzzle tests: "Can I translate what this character perceives into what I can provide?" diff --git a/docs/puzzles/timed-consequence.md b/docs/puzzles/timed-consequence.md new file mode 100644 index 0000000..eb7939b --- /dev/null +++ b/docs/puzzles/timed-consequence.md @@ -0,0 +1,62 @@ +# Timed Consequence Puzzle + +## Mechanic Definition + +Urgency is conveyed through narrative consequence rather than mechanical time limits. The player learns that failure will result in permanent story change, but there's no visible countdown, progress bar, or explicit mechanical deadline. The pressure is diegetic—existing within the story world, not imposed by the game interface. + +## Information Architecture + +**Conveyance Method**: Threat of consequence through dialogue/narrative +- NPCs explicitly state what will happen if player doesn't act +- The consequence is always permanent and story-altering +- No UI element tracks the deadline—the player must infer urgency from narrative + +**Player Action Pattern**: +1. Learn threat through dialogue/story event +2. Understand what the consequence is (permanent story change) +3. Determine what actions prevent the consequence +4. Execute actions with appropriate urgency +5. If successful, consequence avoided; if not, permanent change occurs + +**Core Mechanic**: The puzzle is about managing urgency without visible metrics. The player must internalize the threat and act accordingly. + +## Design Rationale + +- Maintains immersion—no UI elements break narrative +- Creates emotional stakes—the threat of permanent loss matters more than "game over" +- Rewards urgency without stress—players feel pressure without countdown anxiety +- Allows variable pacing—skilled/experienced players can take more time + +## Why It's Effective + +The tension is narrative rather than mechanical. Failing doesn't mean "game over and restart"—it means the story changes permanently. This creates real stakes without punishing exploration. + +## Mechanic Variations + +| Variation | Urgency Signal | Consequence Type | +|-----------|---------------|------------------| +| Dialogue-stated | Character says "you have limited time" | Permanent transformation/death | +| Environmental | World visibly changes (emptying city, rising fire) | NPCs become unavailable | +| Progressive | Character relationships degrade over time | Missing story content | +| Celestial | Described event (alignment, eclipse) approaches | One-time opportunity lost | + +## Generic Example Structure + +**Information Flow**: +- Character: "You have until [event] to [action]. After that, [consequence]." +- Player understands consequence: Permanent story change, not restart +- Player determines required actions: What needs to be done before event +- Player acts with urgency but can still explore +- If completed before event: Normal continuation +- If not: [Consequence] occurs—game continues but fundamentally altered + +**The puzzle**: Internalizing urgency without visible metrics and acting accordingly. + +## Adventure Game Implementation + +Limited actions become urgent: +- TALK to NPCs quickly—some become unavailable after consequence +- WALK between locations—with purpose, not exploration +- The puzzle isn't about speed, it's about priority + +This puzzle tests: "Can I internalize narrative urgency and act with appropriate priority without mechanical feedback?" diff --git a/docs/puzzles/truth-revelation.md b/docs/puzzles/truth-revelation.md new file mode 100644 index 0000000..66b2a75 --- /dev/null +++ b/docs/puzzles/truth-revelation.md @@ -0,0 +1,67 @@ +# Truth Revelation Mechanic + +## Mechanic Definition + +An item or action reveals hidden truth—disguising what's false, exposing hidden identity, or showing what lies beneath the surface. The solution is not combat or force but *seeing through* deception. The truth itself is the key that unlocks the puzzle. + +This differs from "evidence collection" puzzles: the item doesn't just *prove* something, it actively *shows* something. + +## Information Architecture + +**Conveyance Method**: Item-based revelation +- Player obtains a "revealing" item through gameplay +- Using the item on a target reveals hidden information +- The reveal is diegetic—within the game world, not a UI popup + +**Player Action Pattern**: +1. Obtain revelation item through normal gameplay +2. Identify suspect/obstacle that might be disguised +3. Use revealing item on target +4. Information revealed → player knows truth +5. Use truth to solve puzzle (unlock path, prove guilt, etc.) + +**Core Mechanic**: The puzzle isn't about finding evidence—it's about revealing what's hidden. The item is a probe, not a weapon. + +## Design Rationale + +- Rewards observation—player must suspect something is hidden before investigating +- Creates dramatic reveals—unmasking is inherently theatrical +- Avoids violence—solution is cognitive, not confrontational +- Integrates with narrative—revealing truth advances the story + +## Why It's Effective + +The reveal moment is satisfying because it's active discovery, not passive proof-gathering. The player uses a tool to learn something, not collects documents to prove something. + +## Mechanic Variations + +| Variation | Revelation Method | Information Revealed | +|-----------|-------------------|---------------------| +| Optical | Special item shows true form | Identity, disguise | +| Chemical | Substance reveals hidden marks | Truth, lies, secret writing | +| Physical | Object breaks concealment | Hidden rooms, mechanisms | +| Temporal | Time reveals truth | History, past events | +| Emotional | Truth triggers response | Deception, intentions | + +## Generic Example Structure + +**Goal**: Identify the [Imposter/Truth/Hidden Thing] + +**Information Flow**: +- Player obtains [Revealing Item] through normal exploration +- Player suspects something is not as it seems (through dialogue contradictions, visual anomalies) +- Player uses [Revealing Item] on [Suspect/Object] +- Game shows what's actually there (not what appears) +- Player uses revealed truth to solve puzzle + +**The puzzle**: Player must both obtain the revealing item AND correctly identify what to use it on. + +## Adventure Game Implementation + +Limited actions drive this puzzle: +- LOOK at suspects carefully—visual anomalies suggest hidden truth +- TALK to NPCs—contradictions in dialogue suggest deception +- USE revealing item on suspected target +- The solution is the revealed truth, not the item itself + +This puzzle tests: "Can I identify what's hidden and use the right tool to reveal it?" diff --git a/vitepress.config.js b/vitepress.config.js new file mode 100644 index 0000000..1ba98db --- /dev/null +++ b/vitepress.config.js @@ -0,0 +1,35 @@ +import { defineConfig } from 'vitepress' + +export default defineConfig({ + title: 'Puzzle Design KB', + description: 'A handbook documenting puzzle design patterns from classic point-and-click adventure games', + lastUpdated: true, + cleanUrls: true, + + themeConfig: { + nav: [ + { text: 'Index', link: '/' }, + ], + + sidebar: [ + { + text: 'Puzzle Types', + items: [ + { text: 'Cross-Realm Logistics', link: '/puzzles/cross-realm-logistics' }, + { text: 'Distraction Physics', link: '/puzzles/distraction-physics' }, + { text: 'Environmental Storytelling', link: '/puzzles/environmental-storytelling' }, + { text: 'Information Brokerage', link: '/puzzles/information-brokerage' }, + { text: 'Memo Chain', link: '/puzzles/memo-chain' }, + { text: 'Metaphor-to-Literal', link: '/puzzles/metaphor-literal' }, + { text: 'Meta-Puzzle Construction', link: '/puzzles/meta-puzzle-construction' }, + { text: 'Multi-Faceted Plan', link: '/puzzles/multi-faceted-plan' }, + { text: 'Observation Replay', link: '/puzzles/observation-replay' }, + { text: 'Pattern Learning', link: '/puzzles/pattern-learning' }, + { text: 'Sensory Exploitation', link: '/puzzles/sensory-exploitation' }, + { text: 'Timed Consequence', link: '/puzzles/timed-consequence' }, + { text: 'Truth Revelation', link: '/puzzles/truth-revelation' }, + ], + }, + ], + }, +})