@jarrodmedrano/claude-skills 1.0.2 → 1.0.4

package/.claude/skills/level-design/play-personas.md

@@ -0,0 +1,240 @@
+# Play-Personas for Player-Centered Level Design
+
+Based on Chapter 13: "Play-Personas" by Alessandro Canossa (Northeastern University).
+
+## Core Concept
+
+Play-personas are **patterns of preferential interaction and navigation attitudes** that help designers:
+1. Pre-figure player behavior before implementation (metaphor)
+2. Evaluate actual player behavior after release (lens)
+
+> "Level designers are designing spaces for players to act. Games must be played to fully exist."
+
+---
+
+## Why Play-Personas?
+
+### The Problem of Scale
+In a simple Pac-Man maze, there are 24 decision points with 2 choices each = 16,777,216 possible low-level behaviors.
+
+**Solution:** Group low-level actions into high-level behaviors.
+
+### High-Level Behaviors Example (Pac-Man)
+
+| Low-Level | High-Level Behavior |
+|-----------|---------------------|
+| Move up/down/left/right | Center vs Periphery dwelling |
+| Eat pills timing | Early vs Late pill eating |
+| Direction changes | Linear vs Broken path |
+
+Three binary high-level behaviors = 8 personas (2³)
+
+---
+
+## The Two Modes
+
+### Play-Persona as Metaphor (A Priori)
+**Before** the game exists or is playable:
+- Hypothesize how players will behave
+- Design levels to accommodate target behaviors
+- Select which personas to design for
+
+### Play-Persona as Lens (A Posteriori)
+**After** players can be observed:
+- Validate hypotheses with telemetry
+- Discover unexpected behavioral clusters
+- Evaluate if design supports intended personas
+
+---
+
+## The Six-Step Process
+
+### Step 1: Gameplay Analysis
+List all low-level mechanics, then abstract into high-level behaviors.
+
+**Example: Left 4 Dead**
+
+Low-level mechanics:
+- Primary attack (ranged)
+- Secondary attack (melee)
+- Crouch-shooting
+- Jump, reload, run
+- Use items (flashlight, medkit, pills, Molotov, pipe bomb)
+- Change weapons
+
+Abstracted to high-level behaviors:
+- Aggressive vs Defensive playstyle
+- Team-oriented vs Solo
+- Resource-conserving vs Resource-spending
+- Leading vs Following
+
+### Step 2: Create Permutation Matrix
+
+Plot all combinations of high-level behaviors:
+
+| Profile | Aggressive? | Team? | Resource? |
+|---------|-------------|-------|-----------|
+| 1 | Yes | Yes | Conserving |
+| 2 | Yes | Yes | Spending |
+| 3 | Yes | No | Conserving |
+| 4 | Yes | No | Spending |
+| 5 | No | Yes | Conserving |
+| 6 | No | Yes | Spending |
+| 7 | No | No | Conserving |
+| 8 | No | No | Spending |
+
+### Step 3: Select the Cast
+Choose 2-3 personas that:
+- Align with design vision
+- Represent meaningfully different experiences
+- Are achievable given level constraints
+
+**Don't design for all personas.** A fraidy-cat persona doesn't belong in late-game difficulty.
+
+### Step 4: Associate Affordances with Behaviors
+
+Build a thesaurus linking:
+
+**Ludic affordances** (what players can do):
+- Combat opportunities
+- Resource locations
+- Risk/reward placements
+
+**Aesthetic affordances** (what players perceive):
+- Color coding
+- Architectural cues
+- Sound design
+- Lighting
+
+**Example associations:**
+- Bonus items near danger = rewards aggressive personas
+- Safe routes with fewer rewards = supports cautious personas
+- Team-required obstacles = enforces cooperative play
+
+### Step 5: Orchestrate Throughout Level
+
+Modulate which personas are viable at different points:
+- Early game: Multiple personas viable
+- Challenge sections: Specific personas rewarded
+- Recovery sections: Safe personas viable again
+
+**The designer controls** which behavioral profiles are available at any given time.
+
+### Step 6: Validate with Telemetry
+
+After playtesting, analyze:
+- Do players cluster into expected personas?
+- Did unexpected personas emerge?
+- Are intended persona pathways actually used?
+
+---
+
+## Example: Pac-Man Personas
+
+### The Matrix
+| # | Center/Periphery | Pill Timing | Path Style |
+|---|------------------|-------------|------------|
+| 1 | Center | Early | Linear |
+| 2 | Center | Early | Broken |
+| 3 | Center | Late | Linear |
+| 4 | Center | Late | Broken |
+| 5 | Periphery | Early | Linear |
+| 6 | Periphery | Early | Broken |
+| 7 | Periphery | Late | Linear |
+| 8 | Periphery | Late | Broken |
+
+### Named Personas
+
+**Fraidy Cat** (Profile 5):
+- Periphery dweller
+- Eats pills early (security)
+- Linear path (predictable)
+- Avoids ghosts at all costs
+
+**Risk Taker** (Profile 4):
+- Center dweller
+- Delays pills (maximizes points)
+- Broken path (responsive)
+- Embraces ghost proximity
+
+### Designing for Both
+
+**For Fraidy Cat:**
+- Safe peripheral routes
+- Pills accessible from edges
+- Escape paths from center
+
+**For Risk Taker:**
+- Bonus items in center
+- Delayed rewards for pill timing
+- Complex navigation challenges
+
+---
+
+## From Cooper's Personas
+
+Traditional HCI personas (Alan Cooper) describe:
+- Demographics
+- Goals and motivations
+- Behaviors and attitudes
+- Fictional narrative details
+
+### Play-Personas Differ
+
+| Traditional | Play-Persona |
+|-------------|--------------|
+| Narrative description | Parametric model |
+| Static profile | Dynamic behavior pattern |
+| Pre-design only | Pre and post-design |
+| Qualitative | Quantifiable |
+
+---
+
+## Practical Applications
+
+### During Design
+1. Identify core mechanics
+2. Abstract to high-level behaviors
+3. Generate persona matrix
+4. Select target personas
+5. Design affordances supporting those personas
+6. Orchestrate persona viability through level
+
+### During Testing
+1. Instrument telemetry for high-level behaviors
+2. Cluster player data
+3. Compare to expected personas
+4. Identify gaps between design intent and actual play
+
+### Communication Tool
+Personas provide shared language:
+- "This section is designed for Risk Takers"
+- "We need a Fraidy Cat path through here"
+- "The telemetry shows most players are Profile 3"
+
+---
+
+## Benefits
+
+1. **Avoid self-referential design** — Designers aren't the target players
+2. **Enable diversity** — Design for multiple valid playstyles
+3. **Focus effort** — Can't please everyone; pick meaningful personas
+4. **Validate intent** — Telemetry confirms or refutes hypotheses
+5. **Communicate clearly** — Shared vocabulary for team discussions
+
+---
+
+## Limitations
+
+1. **Subjectivity** — Different designers derive different high-level behaviors
+2. **Combinatorial explosion** — Many behaviors = many personas
+3. **Selection bias** — Choosing which personas to design for shapes experience
+4. **Telemetry requirements** — Validation requires instrumentation
+
+---
+
+## Key Insight
+
+> "Play-personas represent means to imply metaphorically players during the design phase and also serve as lenses to evaluate finished levels."
+
+The same framework works for planning AND evaluation—connect design intent to measurable player behavior.

package/.claude/skills/level-design/procedural-handmade.md

@@ -0,0 +1,271 @@
+# Procedural and Handmade Level Design Integration
+
+Based on Chapter 11: "Integrating Procedural and Handmade Level Design" by Mark R. Johnson.
+
+## The Two Approaches
+
+### Procedural Content Generation (PCG)
+Algorithmic creation of game content: levels, items, enemies, stories.
+
+**Strengths:**
+- Massive replay value
+- Reduced development time per unit content
+- Surprise even for developers
+- Adaptive difficulty potential
+
+**Weaknesses:**
+- Can feel same-y across generations
+- Difficult to guarantee specific experiences
+- Narrative hard to generate
+- Quality floors vary
+
+### Handmade Content
+Designer-crafted levels and experiences.
+
+**Strengths:**
+- Precise control over experience
+- Guaranteed quality
+- Narrative coherence
+- Specific memorable moments
+
+**Weaknesses:**
+- Time-intensive
+- Limited replay value
+- Players eventually memorize content
+- Scaling difficult
+
+---
+
+## Why Integrate?
+
+Neither approach alone serves all needs. Integration strategies leverage strengths of both.
+
+### What PCG Struggles With
+- Coherent multi-step narratives
+- Meaningful puzzle design
+- Guaranteed dramatic moments
+- Consistent thematic experience
+
+### What Handmade Adds
+- Narrative anchors
+- Quality guarantees
+- Specific gameplay challenges
+- Memorable set pieces
+
+---
+
+## Two Integration Models
+
+### Vertical Integration
+A handmade thread runs *through* procedural content.
+
+**Characteristics:**
+- Linear progression of handmade elements
+- Procedural content surrounds the thread
+- Players encounter handmade content in sequence
+- Thread spans significant portion of game
+
+**Best for:**
+- Narrative sequences
+- Multi-step puzzles
+- Quest chains
+- Story progression
+
+**Examples:**
+- FTL: Quest nodes distributed through procedural star map
+- Spelunky: Secret item chain requiring precise sequence
+
+### Horizontal Integration
+Procedural and handmade content are *interchangeable* in the same slot.
+
+**Characteristics:**
+- Either type can appear in any given location
+- Modular substitution
+- No linear progression requirement
+- Same slot, different fill
+
+**Best for:**
+- Room-by-room variety
+- Guaranteed gameplay instances
+- Quality floors
+- Encounter variation
+
+**Examples:**
+- Dungeon Crawl Stone Soup: Vaults among procedural rooms
+- Ultima Ratio Regum: Handmade variants mixed with procedural
+
+---
+
+## Case Study: FTL (Vertical)
+
+### Structure
+- Nodes on a star map
+- Most nodes procedural
+- Some nodes are quest-specific (handmade)
+- Quest nodes appear in sequence across sectors
+
+### Integration
+- Procedural: Combat encounters, shops, empty space
+- Handmade: Multi-part quests, story events, special encounters
+
+### Player Experience
+- Procedural nodes provide variety
+- Quest nodes provide narrative progression
+- Players choose path but hit quest nodes as they progress
+
+---
+
+## Case Study: Dungeon Crawl Stone Soup (Horizontal)
+
+### Structure
+- Procedurally generated dungeon floors
+- "Vaults" are handmade rooms/areas
+- Vaults appear among procedural content
+
+### Integration
+- Procedural: Standard dungeon rooms, corridors
+- Handmade: Vaults with curated enemy/loot combinations
+
+### Visibility
+DCSS makes the difference **obvious**:
+- Vaults visually distinct
+- Players recognize human design
+- Creates risk/reward choice ("explore vault?")
+
+### Purpose
+- Visual variety
+- Gameplay pacing
+- Optional challenge/reward
+
+---
+
+## Case Study: Spelunky (Vertical)
+
+### Structure
+- Procedurally generated platformer levels
+- Hidden secret sequence spans entire game
+- Specific items must be collected in order
+
+### The Secret Chain
+1. Find key + chest in Mines → get Udjat Eye
+2. Udjat Eye reveals Black Market → get Ankh
+3. Die with Ankh near Moai → get Hedjet
+4. Kill Anubis → get Scepter
+5. Use Scepter in Temple → access City of Gold
+6. Get Book of Dead → reveals Hell entrance
+
+### Integration
+- Procedural: Level geometry, enemy placement, item locations
+- Handmade: The sequence itself, specific item interactions
+
+### Player Experience
+- Most players never see the secret
+- Skilled players work toward it
+- Each step is procedurally placed but handmade in design
+
+---
+
+## Case Study: Ultima Ratio Regum (Horizontal, Hidden)
+
+### Philosophy
+Blur the line between procedural and handmade so players can't tell which is which.
+
+### Implementation
+- Most systems can output procedural OR handmade content
+- Same slot might get generated altar or preset altar
+- Player cannot distinguish source
+
+### Goals
+1. Handmade might be perceived as procedural (quality validation)
+2. Procedural perceived as handmade (quality achievement)
+3. Guaranteed interesting content without telegraphing it
+
+### Example: Buildings
+- Cathedrals: Highly procedural (few constraints, sprawling)
+- Mansions: More handmade (many required rooms, specific layouts)
+- Constraint level determines procedural/handmade ratio
+
+---
+
+## Key Design Questions
+
+### Should Players Know?
+
+**Make it obvious (DCSS approach):**
+- Visual variety
+- Risk/reward signaling
+- Gameplay pacing tool
+- Player can choose engagement level
+
+**Hide it (URR approach):**
+- Seamless experience
+- Quality perception uniform
+- No "content type" metagaming
+- Procedural must meet handmade quality bar
+
+### What Should Be Handmade?
+
+**Vertical model uses handmade for:**
+- Narrative threads
+- Puzzle sequences
+- Story progression
+
+**Horizontal model uses handmade for:**
+- Quality guarantees
+- Specific gameplay moments
+- Variety injection
+
+---
+
+## Practical Considerations
+
+### Procedural Constraints
+The more constraints on generation, the more similar outputs become.
+
+**High constraints = handmade-like results**
+- May need to shift toward handmade
+- Example: Mansions require many rooms → layouts converge
+
+**Low constraints = high variety**
+- Procedural works well
+- Example: Cathedrals with few requirements → high variety
+
+### Development Timeline
+- Procedural systems: High upfront cost, low marginal cost
+- Handmade content: Linear cost per unit
+- Integration requires both investments
+
+### Testing Considerations
+- Procedural needs testing across many generations
+- Handmade needs testing of specific content
+- Integration needs testing of transitions/interactions
+
+---
+
+## Future Directions
+
+### What's Hard to Generate
+- Multi-node narratives
+- Complex puzzles
+- Coherent story progression
+
+These remain primarily handmade.
+
+### What's Improving
+- Room-level generation
+- Enemy placement
+- Loot distribution
+- Environmental variety
+
+Integration will likely expand as generation quality improves.
+
+---
+
+## Summary
+
+1. **Neither pure approach is sufficient** — Integration leverages both
+2. **Vertical integration** — Handmade thread through procedural space (narrative, quests)
+3. **Horizontal integration** — Interchangeable modules (rooms, encounters)
+4. **Visibility is a design choice** — Obvious vs hidden integration serves different goals
+5. **Constraints determine ratio** — More constraints → more handmade needed
+6. **Quality bars matter** — Procedural must meet handmade standards for hidden integration