@jarrodmedrano/claude-skills 1.0.1 → 1.0.3

package/.claude/skills/level-design/open-world-planning.md

@@ -0,0 +1,294 @@
+# Open-World Level Design Planning
+
+Based on Chapter 12: "Level Design Planning for Open-World Games" by Joel Burgess (Bethesda Game Studios).
+
+## The Three Elements
+
+Open-world planning requires three living documents that evolve throughout development:
+
+1. **The World Map** — Spatial visualization
+2. **The Master List** — High-level data tracking (Excel)
+3. **The Directory** — Per-location details (Wiki)
+
+---
+
+## Element 1: The World Map
+
+### Purpose
+The map is the most vital piece of design documentation. It instantly communicates setting, scale, regions, and anchor locations.
+
+### Key Questions
+- Where does the game take place? (real vs fictional)
+- What subregions exist within the map?
+- What is the scale and density?
+- What major geographical features exist?
+- What natural boundaries can you leverage?
+
+### Working with Real-World Locations
+
+**Advantages:**
+- Pre-existing history and culture
+- Geography already makes sense
+- Reference material abundant
+
+**Challenges:**
+- 100% accuracy rarely equals good gameplay
+- Must balance authenticity with playability
+- Need to understand *essence*, not just details
+
+**Fallout Approach:**
+Get relative positions and surroundings correct for landmarks. Highlight evocative elements. Omit less useful details.
+
+### Subregions
+
+Create variety within the larger world:
+- Different biomes
+- Different cultures
+- Different moods
+
+**Skyrim's Seasonal Subregions:**
+- The Rift: perpetual autumn
+- Haafinagar: bleak winter
+- Falkreath: eternal spring
+
+No actual seasons simulated—each region *is* a season.
+
+### Transitions Between Subregions
+- Leave ample room to blend
+- Use geographical features (cliffs, rivers) for sharper transitions
+- Water boundaries make rapid shifts more believable
+
+### Orienting Features
+
+Include landmarks visible from anywhere:
+- **Skyrim**: High Hrothgar at center
+- **Fallout 4**: Boston skyline (Mass Fusion building's distinctive crown)
+
+Two-point orientation systems work well (financial district + Trinity Tower).
+
+### Boundaries
+
+**Natural boundaries (preferred):**
+- Water (oceans, lakes, rivers)
+- Cliffs
+- Dense forests/marshes
+- Mountains
+
+**Artificial boundaries (avoid when possible):**
+- Invisible walls with "You cannot go that way"
+- Fences that should be climbable
+- Any barrier that draws attention
+
+**Making Boundaries Work:**
+- GTAV: Swim out far enough and sharks eat you
+- Ark: Exhaustion + marine enemies before invisible wall
+- Buffer of "boring space" before hard boundary
+
+---
+
+## Element 2: The Master List
+
+### Purpose
+A spreadsheet tracking every location with filterable, sortable data. Best tool for high-level analysis.
+
+### Basic Columns
+| Name | X | Y | Designer | Quest | Footprint |
+|------|---|---|----------|-------|-----------|
+| Diamond City | 5 | -6 | Jane | MQ101 | Lg |
+| Sanctuary | -2 | 4 | Bob | MQ001 | Md |
+
+### Coordinate System
+Use units that match your game engine. Bethesda uses "cells" consistently across games.
+
+### Plotting the Map
+
+Create a scatter graph in Excel:
+1. X/Y data from location columns
+2. Set axis bounds to match map proportions
+3. Use map image as plot background
+4. Plot points overlay on map
+
+Now you can visualize location distribution automatically.
+
+### Footprint Radii
+
+Track location sizes (Sm/Md/Lg) and visualize with different marker sizes on the scatter plot.
+
+**Note:** Footprint ≠ complexity. A tiny exterior might hide a massive underground area.
+
+### Filter Visualizations
+
+Add columns for:
+- Encounter type
+- Difficulty
+- Architectural style
+- Quest associations
+- Development status
+
+Filter columns to see distribution patterns instantly.
+
+### Quest Route Visualization
+
+Plot quest sequences as line series:
+1. Create list of locations in quest order
+2. Add as new data series
+3. Display as connected line
+
+Instantly see the physical journey players will take.
+
+---
+
+## Element 3: The Directory
+
+### Purpose
+Long-form documentation for individual locations. Where designers track detailed, evolving information.
+
+### Platform
+Wiki works best (MediaWiki recommended). Collaborative, searchable, categorizable.
+
+### Per-Location Pages Should Include:
+
+**Header Data:**
+- Designer assigned
+- Quadrant/coordinates
+- Encounter type
+- Difficulty rating
+- Quest associations
+
+**Body Sections:**
+- Overview: What is this place?
+- Goals: What experience should it deliver?
+- Walkthrough: How to test/reach it
+- Pass notes: Feedback from each iteration
+- Known issues: Current bugs and workarounds
+- To-do: Designer's personal task list
+
+### Category Tags
+Enable filtering by:
+- Designer name
+- Development pass status
+- Location type
+- Quest line
+
+### Naming Convention
+Simple codes: DN004 = Dungeon #4
+Use consistently across master list and directory.
+
+---
+
+## POI Density
+
+### Definition
+The frequency of points of interest in a given area.
+
+### The Spectrum
+
+**Sparse (Just Cause):**
+- Long drives between locations
+- Vehicles essential
+- World feels vast and empty (intentionally)
+
+**Dense (GTA cities):**
+- Compressed real-world distances
+- Something around every corner
+- Theme park feel
+
+**Non-uniform (Fallout 4, Skyrim):**
+- Urban cores dense
+- Rural areas sparse
+- Small pockets of density for towns
+
+### Consider Travel Method
+- On foot: higher density needed
+- Vehicle: can afford sparser distribution
+- Fast travel: density matters less for return visits
+
+---
+
+## Anchor Locations
+
+Locations you know must exist early:
+- Story-critical places
+- Real-world landmarks (if applicable)
+- Major navigation features
+- Key narrative beats
+
+Plot these first. Other locations fill around them.
+
+### Wish List Locations
+Ideas you'd like to include but aren't critical:
+- Minor landmarks
+- Novel encounter concepts
+- Infrastructure (power stations, farms)
+- World-building details
+
+Build wish list to roughly equal target location count.
+
+---
+
+## Iterative Development Passes
+
+### Pass Zero: Pitch
+- Complete master list exists
+- Directory template established
+- No technical requirements
+- Each location assigned to a designer
+
+### Pass One: Layout
+- Basic environment art in place
+- "Graybox" equivalent with modular kits
+- Spatial relationships established
+
+### Pass Two: Gameplay
+- Core gameplay systems available
+- Enemy placement and encounters
+- First draft of pacing and challenge
+
+### Pass Three: Content Complete
+- All content present (if rough)
+- "Ship with shame" milestone
+- Everything playable end-to-end
+
+### Art Pass
+- Lighting, atmospherics, clutter
+- Visual polish
+- Collaboration between designers and artists
+
+### Pass Four+: Polish
+- Bug fixes
+- Balance tuning
+- Additional passes for problem areas or promising locations
+
+---
+
+## Practical Wisdom
+
+### Documentation Lifecycle
+> "We ship games, not documents."
+
+Keep documentation useful but don't over-maintain. Let documents go fallow once they've served their purpose.
+
+### Metrics and Scheduling
+- Base estimates on average/below-average designers
+- Plan for worst case
+- Leave emergency time
+
+> "No plan survives first contact with the enemy."
+
+### Pride of Ownership
+Try to keep designers with their locations throughout development. Ownership motivates.
+
+### Map as Communication
+The map unifies team perception. Print large versions. Reference constantly. It's your shared mental model.
+
+---
+
+## Summary
+
+1. **Map first** — Establishes shared vision
+2. **Master list** — Tracks and visualizes high-level data
+3. **Directory** — Captures per-location detail
+4. **Iterate** — Plan for multiple passes
+5. **Density matters** — Defines exploration feel
+6. **Natural boundaries** — Beat artificial walls
+7. **Anchor then fill** — Critical locations first, then expand

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.