---
name: game-design-theory
description: >
  Game design consulting based on Richard Rouse III's Game Design Theory and Practice.
  Use when helping with game design decisions, player psychology, gameplay systems,
  storytelling, playtesting, or evaluating fun. Provides frameworks for understanding
  what players want, creating engaging gameplay mechanics, balancing challenge and fun,
  non-linear design, in-game storytelling, and effective playtesting practices.
  NOT for coding or programming - focused on design philosophy and player experience.
---

# Game Design Theory Skill

A design consulting framework based on principles from "Game Design: Theory & Practice" by Richard Rouse III.

## When to Use This Skill

- Evaluating game concepts for player appeal
- Designing gameplay mechanics and systems
- Analyzing why a game is or isn't fun
- Balancing difficulty and challenge
- Creating non-linear experiences
- Integrating story with gameplay
- Planning and conducting playtesting
- Making design trade-off decisions

## Core Philosophy

Games are about **player experience**, not designer intention. The goal is to merge the "designer's story" with the "player's story"—allowing players to feel authorship over their experience while guided by thoughtful design.

> "Not to make something sell, something very popular, but to love something, and make something that we creators can love. It's the very core feeling we should have in making games." — Shigeru Miyamoto

## Quick Reference

### Why Players Play
1. **Challenge** - Engaging the mind, learning through problem-solving
2. **Socialization** - Shared experiences, connection with others
3. **Dynamic Solitary Experience** - Interactive engagement without social demands
4. **Bragging Rights** - Achievement, mastery, self-satisfaction
5. **Emotional Experience** - Tension, catharsis, meaningful feelings
6. **Fantasy** - Escapism, becoming someone else, safe experimentation

### What Players Expect
- A **consistent world** with predictable cause-and-effect
- Clear **understanding of boundaries** and possible actions
- **Reasonable solutions** to work (multiple paths to success)
- **Direction** without hand-holding
- **Incremental progress** toward goals
- **Immersion** maintained throughout
- A **fair chance** at success
- To **do**, not to watch
- To **not get hopelessly stuck**

### Elements of Good Gameplay
- **Emergence**: Systems interacting to create unplanned, player-discovered solutions
- **Non-linearity**: Multiple paths, solutions, orderings, and optional content
- **Appropriate Reality Modeling**: Only simulate what serves fun
- **Teaching Through Play**: First minutes make or break engagement
- **Transparent Controls**: Input that disappears into instinct

## Detailed References

For deeper guidance, consult these reference files:

- **Player Psychology**: See [references/player-psychology.md](references/player-psychology.md) for why players play and what they expect
- **Gameplay Elements**: See [references/gameplay-elements.md](references/gameplay-elements.md) for emergence, non-linearity, and system design
- **Storytelling**: See [references/storytelling.md](references/storytelling.md) for in-game narrative techniques
- **Playtesting**: See [references/playtesting.md](references/playtesting.md) for testing practices and balancing
- **Design Principles**: See [references/design-principles.md](references/design-principles.md) for focus, teaching, and I/O design

## Design Evaluation Framework

When evaluating a game design, ask:

1. **Player Motivation**: Which core motivations does this serve? (Challenge, Social, Solitary, Bragging, Emotional, Fantasy)
2. **Expectation Alignment**: Does the design honor what players expect?
3. **Emergence Potential**: Can players discover solutions the designer didn't anticipate?
4. **Non-linearity**: Are there meaningful choices in order, approach, and outcome?
5. **Learning Curve**: Can players succeed early before facing real challenge?
6. **Immersion Maintenance**: What might break suspension of disbelief?
7. **Balance Reality**: Is the simulation serving fun, or drowning in tedium?

## Common Design Pitfalls

| Pitfall | Symptom | Solution |
|---------|---------|----------|
| Overly Linear | Player feels "on rails" | Add order/approach choices |
| Anticipatory-Only Design | Only hardcoded solutions work | Build systems, not cases |
| Reality Obsession | Tedious simulation of mundane details | Model only what's fun |
| Inconsistent Rules | Same action gives different results randomly | Ensure predictable cause-effect |
| Tutorial Overload | Players skip to "real game" | Teach through safe early gameplay |
| Hidden Information | Players fail without knowing why | Provide clear feedback |
| Designer's Ego | "Players will adjust" | Playtest with fresh eyes |
| Difficulty Blindness | "It's not that hard" | Your game is too hard. Always. |

## Key Mantras

- **"Your game is too hard."** The development team is always too skilled; assume difficulty is overtuned.
- **"Show, don't tell."** In-game storytelling > cut-scenes > manuals.
- **"Less is more."** Every control added must justify its complexity cost.
- **"Players want to do, not watch."** Minimize non-interactive sequences.
- **"The player's story matters most."** Let their choices shape the experience.