@jarrodmedrano/claude-skills 1.0.2 → 1.0.3

package/.claude/skills/game-design-theory/player-psychology.md

@@ -0,0 +1,175 @@
+# Player Psychology
+
+Understanding why players play and what they expect is fundamental to good game design.
+
+## Why Do Players Play?
+
+### 1. Challenge
+
+Players enjoy games because they provide challenges that engage the mind differently than other media. Like solving a Rubik's Cube, games force players to:
+- Think actively
+- Try different solutions
+- Understand game mechanisms
+- Learn through experimentation
+
+**Key insight**: Players are enriched by the learning that follows overcoming challenges. They may apply problem-solving methods to work, use improved spatial skills in life, or learn greater empathy through role-playing.
+
+### 2. Socialization
+
+Gaming arose as a communal activity millennia ago. Most non-computer games require a social group to function—chess, Monopoly, bridge, Scrabble. The social element is more important than many designers realize:
+
+- **Multi-player action games**: Even in high-velocity games like Quake, players still try to chat, demonstrating the desire to socialize
+- **Persistent worlds**: MUDs and MMOs draw players primarily for social interaction—many players would never play single-player games
+- **The human advantage**: Human opponents are unpredictable and challenging, but more importantly, they make the experience social
+
+### 3. Dynamic Solitary Experience
+
+Sometimes players want interactive engagement without social demands:
+- Friends aren't available
+- Tired of talking to people
+- Want something that reacts like a human without the annoyances
+- Always in control—can start and stop at any time
+
+**Key insight**: Single-player games "fake" the interesting part of human interaction while letting players remain in control.
+
+### 4. Bragging Rights
+
+Particularly in multi-player gaming, players play to win respect:
+- High score tables in arcades
+- Being able to defeat all your friends
+- Sense of self-satisfaction from victory
+- Proving they can do something well
+
+**Key insight**: Players who may not excel at sports or academics can find mastery and pride in games.
+
+### 5. Emotional Experience
+
+Players seek emotional payoff:
+- **Simple emotions**: Adrenaline rush, tension of action games
+- **Complex emotions**: Loss when a companion character sacrifices themselves
+- **Catharsis**: Tragedy and despair can be compelling (arcade games are "lessons in defeat")
+
+**Key insight**: Many games' emotional range is limited to excitement/tension, despair at failure, and elation at success. There's vast unexplored emotional territory.
+
+### 6. Fantasy
+
+Games enable escapism and role-playing:
+- Become someone more exciting
+- Live glamorous lives without mundane details (no eating, sleeping, bathroom breaks)
+- Engage in socially unacceptable behavior safely (being a criminal in a game)
+- See the world through someone else's eyes
+- Explore "what if" scenarios (historical what-ifs)
+
+**Key insight**: The level of fantasy immersion is heightened by interactivity—players don't just watch adventures, they have them.
+
+---
+
+## What Do Players Expect?
+
+Once players start playing, they have gameplay expectations. Failing to meet these causes frustration.
+
+### Consistent World
+
+Players must be able to predict what actions produce what results:
+- Same cause → same effect
+- If a kick works in one situation, it should work in similar situations
+- Failure should have perceivable reasons
+
+**Example**: In fighting games, if a kick misses, it must be because the opponent jumped, blocked, or was too far away—reasons the player can perceive.
+
+**Pinball problem**: Novice players can't see the connection between their actions and outcomes, so they call it "luck" and stop playing.
+
+### Understanding the Game-World's Bounds
+
+Players need to know what actions are possible vs. impossible:
+- In Doom, players know they can't negotiate with demons
+- Don't introduce entirely new mechanisms late in the game
+- Players learn "how this game works" and expect that to remain true
+
+**Violation example**: If Doom suddenly required befriending a monster through conversation, players would be frustrated—that's completely outside the established scope.
+
+### Reasonable Solutions to Work
+
+Once players understand the game, their reasonable solution attempts should succeed:
+- Real-world problems have multiple solutions
+- Games modeling reality should too
+- The designer provides one solution, but must anticipate alternatives
+
+**Key insight**: Every "You can't do that" or failed reasonable attempt breaks immersion and frustrates players.
+
+### Direction
+
+Players need goals and some idea how to achieve them:
+- Without a goal, there's no game
+- Without knowing the goal, might as well not have one
+- Need direction without feeling hand-held
+
+**SimCity exception**: Players impose their own goals based on real-world understanding of "what makes a good city." The game's grounding in reality provides implicit direction.
+
+### Incremental Accomplishment
+
+Players want to feel progress:
+- Provide sub-goals along the way
+- Reward achievement of sub-goals proportionally
+- Without positive reinforcement, players will abandon the correct path
+
+### Immersion
+
+Anything that reminds players they're "just playing a game" damages the experience:
+- Bugs and crashes
+- Puzzles with solutions that don't work (even if reasonable)
+- Characters they can't identify with
+- UI elements that feel artificial
+
+**Character identification**: Mario works because he's a blank slate. Characters with annoying personalities constantly remind players they're not in control.
+
+### Failure is Expected
+
+Players expect to fail sometimes—it's part of the challenge. But failure should feel fair.
+
+### Fair Chance
+
+Players expect the game to give them an opportunity to succeed:
+- Difficulty should come from the challenge, not hidden information
+- Don't require precognition
+- Provide tools and information needed to make progress
+
+### Not Repeating Themselves
+
+Players hate redoing completed work:
+- Save systems should be generous
+- Don't punish players by making them replay large sections
+- Respect the player's time
+
+### Not Getting Hopelessly Stuck
+
+Players need escape routes:
+- Multiple solutions prevent dead ends
+- Hints for struggling players
+- "Non-linearity is about preventing players from getting stuck"
+
+### To Do, Not Watch
+
+Players play games for interactivity:
+- Every non-interactive moment is time they could be playing
+- Cut-scenes should be skippable
+- The more passive content, the less it's a game
+
+**Key insight**: Players who wanted passive entertainment would have watched a movie.
+
+---
+
+## Player Types: The Audience Consideration
+
+Not all players want the same thing. Consider your target audience:
+
+| Player Type | Primary Motivation | Design Consideration |
+|-------------|-------------------|----------------------|
+| Hardcore Gamer | Challenge, Mastery | Complex systems, high difficulty |
+| Social Player | Connection | Multi-player, sharing features |
+| Casual Player | Relaxation, Fantasy | Simple controls, forgiving difficulty |
+| Explorer | Discovery | Hidden content, non-linear worlds |
+| Achiever | Completion | Clear goals, rewards, collections |
+| Storyteller | Narrative | Rich characters, meaningful choices |
+
+**Critical insight**: You cannot please everyone. Better to delight some players deeply than satisfy all players marginally.

package/.claude/skills/game-design-theory/playtesting.md

@@ -0,0 +1,321 @@
+# Playtesting
+
+Playtesting is where average games become excellent. It's not optional polish—it's essential design work.
+
+> "The common denominator, I would guess, is passion. Everyone says, 'Well, why aren't games better—why aren't there more really good games?' And I think that the answer is that what this industry doesn't do, amazingly, is play the games it makes. We create a game, we ask the teams to work all the hours God sends, and we don't give them time to play the game. That's really what makes the difference—sitting down and playing for hours and hours and hours." — Peter Molyneux
+
+## Playtesting vs. Debugging
+
+**Debugging**: Finding and fixing code problems (crashes, broken features, graphical glitches). A programming task.
+
+**Playtesting**: Evaluating whether the game is *fun* and finding faults in game mechanics. A design task.
+
+Examples of playtesting concerns:
+- Unit too powerful, dominates game
+- Enemy AI behaves illogically
+- Controls feel unintuitive
+- Difficulty spike too severe
+- Puzzle solutions unclear
+
+---
+
+## Types of Testers
+
+### 1. Development Team
+- Should play constantly throughout development
+- Know the game intimately, motivated to improve it
+- **Drawbacks**: Too close to be objective, too skilled from practice, personal attachments to their own work
+
+### 2. Traditional Testers
+- Start at alpha, continue until ship
+- Mix of bug hunting and gameplay feedback
+- Full-time, paid employees who love games
+- **Drawback**: Skewed toward hardcore gamer perspective
+
+### 3. First-Impression Testers
+- Fresh players who have never seen the game
+- Single-session testing (30-60 minutes)
+- "Kleenex testers"—use once, discard
+- **Purpose**: Test learnability, initial experience, control intuitiveness
+
+### 4. Fellow Game Designers
+- Designers from other projects
+- Can look past obvious early-stage problems
+- Provide insight on fundamental design issues
+- Best for early prototypes and "is this fun?" questions
+- **Drawback**: Too busy to test extensively
+
+### 5. Non-Gamers
+- People who don't play games regularly
+- High intolerance for traditional game problems
+- Expose fundamental usability issues
+- "The guy who fixes the coffee machine"
+- **Drawback**: Can't provide constructive solutions
+
+---
+
+## Who Should NOT Test
+
+### Your Boss
+- Tester must feel free to speak honestly
+- Boss has different goals (budget, timeline)
+- Power dynamic corrupts feedback
+
+### Marketing
+- Believes they know what anonymous audiences want
+- Second-guessing based on market trends
+- Often wrong as often as right about gameplay
+
+### Close Friends/Family
+- Want to strengthen relationship, not criticize
+- Will sugarcoat opinions
+- Can work if relationship is brutally honest
+
+### Idiots
+- Say idiotic things with idiotic opinions
+- Identify early, isolate, ignore
+
+### Would-Be Designers
+- Want to change things to "how I would do it"
+- Suggestions based on personal preference, not improvement
+- Try to design through you
+
+---
+
+## When to Test
+
+### Phase: Early Prototype
+**Who**: Fellow game designers, development team
+**Focus**: Is the core concept fun? Does it show promise?
+**Expectations**: Game will crash, art is placeholder, features incomplete
+
+### Phase: Alpha
+**Who**: Traditional testers, first-impression testers
+**Focus**: Gameplay evaluation, interface testing
+**Expectations**: Most features complete, significant bugs remain
+
+### Phase: Beta
+**Who**: Traditional testers, extensive first-impression testing
+**Focus**: Final polish, difficulty balancing
+**Expectations**: Feature-complete, bug-fixing priority
+
+**Warning**: Don't bring in testers too early expecting to accelerate by finding bugs before alpha. Testers will find obvious bugs you already know about, wasting everyone's time. The game needs to be playable first.
+
+---
+
+## How to Test
+
+### Watch, Don't Coach
+
+The temptation: "Go over there," "Use strafe buttons," "Try the power-foozle!"
+
+**The problem**: Designer can't ship in the box with the game.
+
+**Correct approach**: 
+- Sit behind tester, silent
+- Watch their natural play
+- Note where they struggle
+- Resist urge to teach
+
+If the player gets stuck or can't master controls, ask: "What's causing this?" not "Let me show you."
+
+### Listen Honestly
+
+Common designer defenses when hearing criticism:
+- "That tester is a fool"
+- "Not our target audience"
+- "Just complaining for the sake of it"
+
+**Reality check**: When multiple testers raise the same issue, there's a problem. Period.
+
+### Guided vs. Unguided Testing
+
+**Guided**: "Please test the new inventory system"
+- Useful for specific features
+- Risk: Miss larger problems elsewhere
+
+**Unguided**: "Play the game however you want"
+- Reveals problems designer overlooked
+- Tests game holistically
+- Essential complement to guided testing
+
+**Best practice**: Do both. Note off-topic feedback for later even if focusing on specific system.
+
+---
+
+## Balancing
+
+Only possible when most of the game is complete. Balancing incomplete games wastes effort—everything changes when remaining features are added.
+
+### The Balancing Loop
+1. Make a pass adjusting values
+2. You and testers play the game
+3. Gather feedback
+4. Adjust values
+5. Repeat until shipping
+
+### System Attributes
+
+Break gameplay into tunable numbers:
+
+**Weapon example** (baseball bat):
+- Damage per hit
+- Attack speed
+- Durability (hits before breaking)
+- Cost
+- Hands required
+
+**Enemy example**:
+- Health
+- Damage
+- Movement speed
+- Detection range
+- Aggression level
+
+### Interconnected Systems
+
+Changing one value affects others:
+- Making one weapon stronger might break a later combat encounter
+- Adjusting enemy health changes pacing of entire game
+
+**Requirement**: Playtest every change across entire game, not just locally.
+
+### Accessibility
+
+Balancing data must be editable without programmer intervention:
+- Configuration files
+- Level editor tools
+- Designer-accessible formats
+
+---
+
+## Your Game Is Too Hard
+
+This is not a guess. This is a law.
+
+### Why It's Always True
+
+1. Development team has played for 9-18 months
+2. Team is in top 10% of skill for this game
+3. To stay entertained, team tuned game challenging for themselves
+4. 90% of eventual players are worse than the team
+
+### The Denial Cycle
+
+1. Testers say "This game is too hard"
+2. Designer thinks "They'll get better"
+3. Testers DO get better over 3 months
+4. Testers stop thinking it's hard
+5. Game ships brutally difficult
+
+### Counter-Measures
+
+**The Marathon Technique** (Jason Jones):
+- Can development team beat entire game on hardest setting using only the fist weapon?
+- If yes, normal players with guns on normal difficulty have a fair chance
+
+**The Handicap Principle**:
+- If designer can win with both arms tied behind back, regular players can win normally
+
+**Explicit Difficulty Awareness**:
+- Assume difficulty is overtuned
+- Bias toward "too easy" (players rarely complain about this)
+- Multiple difficulty settings as safety valve
+
+---
+
+## Focus Groups vs. Playtesting
+
+### Focus Groups
+- "Off the street" participants
+- 1-2 hour presentation on multiple games
+- Often can't play (games not developed yet)
+- Hear descriptions, say if they'd buy
+- Run by marketing
+
+### Playtesting
+- Known testers with established trust
+- Play actual games
+- Provide actionable feedback
+- Run by development team
+
+### Why Focus Groups Are Dangerous
+
+Imagine a focus group for:
+- Pac-Man
+- Tetris  
+- Civilization
+- The Sims
+
+Will Wright: The Sims focus group went so poorly the game was nearly canceled. It became one of the best-selling games of all time.
+
+**Focus groups favor safe, uninnovative games.** They're designed to find the lowest common denominator, not to recognize innovation.
+
+---
+
+## The Artistic Vision
+
+### You Can't Please Everyone
+
+With enough testers, someone will dislike everything.
+
+**Wrong approach**: Try to make everyone happy → Game everyone thinks is "OK," no one loves
+
+**Right approach**: Delight some players deeply → Passionate fans
+
+### Not Design By Committee
+
+You don't have to implement every suggestion. Some ideas are reasonable but don't fit *your* game.
+
+> In the end, if every single playtester tells you some part of the game must change, but you feel, in your gut, as an artist, that you do not want to change that portion of the game, then leave it as it is.
+
+A committee cannot have the unity of vision a single person maintains.
+
+---
+
+## Tester Relationship Management
+
+### Know Your Testers
+
+Different testers have different biases:
+- **Whiners**: Complain about everything, even things that work
+- **The Shy**: "Maybe look at X" means "Obviously X is broken"
+- **The Expert**: Forgets what it's like to be new
+- **The Perfectionist**: Wants changes that don't improve the game
+
+Understanding personality helps weight feedback appropriately.
+
+### The Ideal Tester
+
+Provides feedback like: "When fighting the twelfth clown on level three, I thought he was too hard. I had no idea what I was supposed to do or whether my attacks were working. I tried rolling the boulder at him but couldn't figure out how."
+
+- Specific problem identification
+- Detailed explanation of confusion
+- Notes what they attempted
+
+**These testers are rare. Treasure them.**
+
+---
+
+## Playtesting Checklist
+
+Early development:
+- [ ] Core concept tested with trusted fellow designers
+- [ ] Team playing regularly
+
+Alpha:
+- [ ] Traditional testers onboarded
+- [ ] First-impression testing for controls/interface
+- [ ] Feedback documented, not dismissed
+
+Beta:
+- [ ] Multiple balancing passes completed
+- [ ] Difficulty tested with handicap methods
+- [ ] Both guided and unguided testing performed
+- [ ] Non-gamer testing for accessibility
+- [ ] Problems from early testing re-verified as fixed
+
+Throughout:
+- [ ] Designer watches testers play silently
+- [ ] All feedback recorded, even if not immediately addressed
+- [ ] Multiple testers raising same issue = real problem