Game Design Skill for Claude Code - 基于《游戏设计的100个原理》的游戏设计全流程助手 | 仅供个人学习与娱乐

character-optimization-design--optimization-examples.md

Min/Maxing Examples and Mitigations

Traditional D&D

• Problem: Players dump Charisma to boost Strength
• Mitigation: Charisma affects more mechanics (leadership, NPC reactions)
• Result: Still possible, but trade-offs are meaningful

Dark Souls

• Approach: Complex stat scaling system
• Design: Each weapon scales with different stats
• Result: Min/maxing possible, but versatile builds remain viable

World of Warcraft

• Evolution: Early allowed extreme min/maxing
• Changes: Later expansions forced balance with primary stats
• Lesson: Community feedback drives balance needs

XCOM

• Approach: Random stat growth on level up
• Design: Soldiers develop organically, not perfectly
• Result: Players adapt to soldiers, not min/max perfect builds

Civilization

• Approach: Balanced base units, minimal customization
• Design: Strategy comes from positioning and timing, not stats
• Result: Optimization happens at game level, not unit level

Multiclass Systems

• Problem: Players pick best abilities from multiple classes
• Mitigation: Diminishing returns, level requirements, synergies
• Example: Pathfinder with complex class interaction rules

character-optimization-design.md

name	description
character-optimization-design	Use when designing character creation systems, unit attributes, or stat-based progression. Applies when players can allocate points to customize characters/units, or when balancing RPG, wargame, or strategy game systems.

Character Optimization and Mitigation Design

Design character creation and progression systems that balance player optimization strategies with game integrity and role-playing experience.

When to Apply

• Designing character creation systems
• Creating stat/attribute systems
• Balancing RPG or strategy game units
• Addressing player power optimization behaviors
• Designing progression mechanics

Min/Maxing Definition

Min/Maxing is a dominant strategy where players:

• Minimize unfavorable traits
• Maximize favorable traits
• Create specialized characters/units optimized for specific tasks

Characteristics

• High power in specific skills or areas
• Reduced overall flexibility or versatility
• Dominant strategies that outperform balanced builds
• Common in: RPGs (combat stats over social/intellectual), Military games (glass cannon units)

Player Perspectives

Supporters Argue:

• Rules-compliant behavior
• Contributes to team efficiency (division of labor)
• Fits game spirit of optimization and mastery
• Satisfying to find optimal builds

Critics Argue:

• Breaks social contract of role-playing
• Ignores character realism and narrative
• Ruins non-combat experiences
• Creates unbalanced multiplayer environments
• Reduces creative expression

Designer Mitigation Strategies

Preset Values

Approach:

• Set preset, balanced attribute values
• Limit player customization to presets

Pros:

• Guaranteed balance
• Easy to design and test

Cons:

• Reduces player agency
• Limits creative expression

Random Generation

Approach:

• Randomly generate new attribute values for each new game
• Roguelike-style character creation

Pros:

• Encourages adaptability
• Prevents repetitive optimization
• Adds replay variety

Cons:

• Players may feel cheated by bad rolls
• May require re-rolling (wastes time)

Interconnected Attributes

Approach:

• Link attributes into complex systems
• Raising one stat lowers another
• Shifts focus to system optimization

Pros:

• Maintains depth
• Requires strategic thinking
• Prevents single-stat dominance

Cons:

• More complex to understand
• Still vulnerable to system optimization

Thematic Emphasis

Approach:

• Emphasize game theme and narrative
• Encourage role-playing over number-crunching
• Reward narrative choices with mechanical benefits

Pros:

• Maintains immersion
• Encourages desired playstyle
• Aligns mechanics with theme

Cons:

• May not stop pure optimizers
• Requires strong narrative

Related Design Traps

Powergaming:

• Dominant players bullying others to achieve goals
• Using any means to "win" at social play

Rule Lawyering:

• Strict adherence to rules to optimize math
• Ignoring fun and spirit of the game
• Arguing technicalities for advantage

Twinking:

• Equipping low-level characters with high-level gear
• Creates absolute advantage over natural progression
• Breaks early-game balance

Variables

• trait_values: The quantitative values of character attributes (strength, intelligence, etc.)
• optimization_level: Degree to which player is min/maxing
• flexibility_factor: How versatile the character/unit is
• system_complexity: How interconnected the stats are

Constraints

• May violate social contracts in role-playing games
• Reduces character flexibility
• Controversial player behavior—satisfying for some, frustrating for others

Design Workflow

1. Define desired balance between specialization and versatility
2. Choose mitigation strategy (or combination)
3. Implement attribute system with chosen constraints
4. Test for dominant strategies and exploits
5. Iterate based on playtesting feedback
6. Monitor live game for emerging optimization patterns

Result Template

A character/unit system that accommodates player optimization while maintaining game balance and supporting the intended playstyle.

doubling-halving-balance.md

name	description
doubling-halving-balance	Rapidly identify game balance issues by doubling or halving core game variables (movement, time limits, resources, health/damage) during prototyping and balance tuning. Use when you need to quickly validate design hypotheses or expose balance flaws.

Doubling and Halving Balance Method

When to Use

• In prototype phase to discover design issues
• During balance tuning to identify problematic variables
• Testing hypotheses about game balance
• Needing to quickly find the right range for a variable
• Internal development testing (not for external playtesters)

Core Concept

Make extreme adjustments (2x or 0.5x) to core game variables rather than fine-tuning. This quickly reveals whether a variable has meaningful impact and helps find the right balance range.

Execution Steps

1. Identify Target Variable

Select a variable that significantly impacts core game balance:

• Movement options (speed, jump height)
• Time limits (level timers, cooldowns)
• Resource allocation (ammo, mana, currency)
• Health or damage ratios
• Other programmable input values

Skip: Variables with minimal impact on game experience

2. Choose Adjustment Direction

• Double (2x): If current value seems too low or weak
• Halve (0.5x): If current value seems too high or strong
• Base direction on your testing hypothesis

3. Apply Adjustment and Test

• Modify the variable value
• Playtest to observe impact
• Record whether change produces significant difference

4. Iterate Until Impact is Found

• If no significant change: double/halve again
• Continue until you observe meaningful impact on gameplay
• Track iteration count

5. Analyze Results

• Significant change found: Variable is important; now fine-tune from this point
• No change even after extreme iterations: Variable may not matter; consider removing or redesigning
• Change reveals new issues: Adjust other related variables

6. Determine Next Action

• If balance is close: proceed to fine-tuning
• If fundamental issues exposed: consider redesign
• Document findings for future reference

Example Workflow

Problem: Player starting health is 200; game feels too easy

1. Halve health to 100
2. Playtest
3. If still too easy → halve to 50
4. If now too hard → fine-tune between 50-100
5. Result: Found meaningful range in 2 iterations vs. 20+ micro-adjustments

Constraints and Warnings

• Internal tool only: Do not use with external playtesters
• Developer knowledge required: Must understand how systems interact
• Prepare for discomfort: Extreme values will create bad experiences
• Not for A/B testing: Non-developers find extreme conditions frustrating
• Not for trivial variables: Only use for balance-critical values

Advantages

• Exposes balance flaws quickly
• Saves time compared to incremental tuning
• Reveals which variables actually matter
• Gets you close to target values fast
• Can be used throughout development until final release

dynamic-difficulty-adjustment--adjustment-examples.md

Dynamic Difficulty Examples

Adaptive Enemy AI

• Detection: Player dies 3 times to same boss
• Adjustment: Boss attacks 10% slower, telegraphs moves more clearly
• Result: Player learns pattern and succeeds

Racing Games

• Detection: Player consistently finishes last or quits mid-race
• Adjustment: Rubber banding—AI cars slow down slightly
• Result: Player stays competitive

Platformers

• Detection: 5 failed attempts at jump sequence
• Adjustment: Slightly wider platforms, more forgiving hitboxes
• Result: Player completes with satisfaction

Fighting Games

• Detection: Player loses multiple rounds to same opponent
• Adjustment: AI becomes less aggressive, blocks less frequently
• Result: Player can practice and learn

Avoid Detection

• Don't make adjustments obvious (enemies suddenly much weaker)
• Don't over-adjust (task becomes trivial)
• Don't change mechanics mid-challenge (confuses learning)
• Don't announce changes to player

dynamic-difficulty-adjustment.md

name	description
dynamic-difficulty-adjustment	Use when implementing systems to adjust game difficulty based on player performance, frustration, or failure patterns. Applies when designing boss battles, skill-based challenges, or any task where players may repeatedly fail and become frustrated.

Dynamic Difficulty Adjustment (Buster Principle)

Subtly adjust game difficulty based on player performance to maintain engagement without the player's awareness.

When to Apply

• Players attempt a task multiple times without success
• Designing boss battles or difficult challenges
• Implementing skill-based obstacles
• Balancing player frustration vs. satisfaction
• Designing adaptive game systems

The Buster Principle

Core Concept

Named after Buster Keaton (a cockatoo) who lowered game difficulty when the owner got frustrated to prolong play.

Mechanism

1. Monitor player behavior to detect frustration or excessive failure at a specific task
2. When a player obviously tries many times without success, intervene
3. Adjust the task to be slightly easier
4. Perform adjustments subtly in the background
5. Shift player emotion from frustration (throwing controller) to satisfaction (pumping fist)

Implementation Guidelines

Monitoring Player State

Metrics to Track:

• attempt_count: Number of times player tries a task
• success_rate: Player's performance metrics (accuracy, time, deaths)
• time_spent: Duration of attempts
• rage_quit_indicators: Sudden stops, button mashing, retries

Adjustment Strategies

Subtle Adjustments:

• Lower enemy health or damage by small percentages (5-10%)
• Widen timing windows for actions
• Reduce number of enemies or obstacles
• Provide additional resources (ammo, health)
• Slow down enemy attack patterns

Maintain Challenge:

• Do not make the game too easy
• Keep the task still requiring effort
• Ensure player still feels achievement

Detection Thresholds

Signs of Frustration:

• 3-5 consecutive failures on the same task
• Increasing time between attempts (hesitation)
• Rage indicators (rapid retries without improvement)
• Abandoning task and returning later

Variables

• attempt_count: Number of times player tries a task (integer)
• success_rate: Player's performance metrics (float)
• frustration_level: Derived metric from behavior patterns
• adjustment_factor: How much to reduce difficulty (0-1 scale)

Constraints

• Do not make the game too easy—this removes satisfaction
• Not applicable if goal is purely competitive fairness (e-sports)
• Keep adjustments secret—don't notify players of difficulty changes
• Apply gradually—small increments are less noticeable

Execution Workflow

1. Define baseline difficulty for each task or challenge
2. Set monitoring parameters (what counts as "trying many times")
3. Implement detection logic for frustration patterns
4. Create adjustment rules (what changes, by how much)
5. Test thoroughly—ensure adjustments feel natural, not noticeable
6. Monitor playtesting for unexpected behaviors

Benefits

• Maintains player engagement through difficult sections
• Prevents rage quitting
• Provides sense of achievement
• Accommodates varying player skill levels
• Creates personalized experience

Result Template

Task difficulty is reduced incrementally to allow player progression and satisfaction, maintaining the illusion of fixed challenge.

environmental-storytelling-technique.md

name	description
environmental-storytelling-technique	Apply environmental storytelling techniques to convey world information, character development, or narrative context through game environments instead of cutscenes or text exposition. Use when designing game worlds, levels, or narrative systems where you need to immerse players in the story without breaking gameplay flow.

Environmental Storytelling Technique

Treat the game world as a character itself, using environmental elements to convey narrative information without relying on cutscenes or lengthy exposition.

When to Use

Apply this technique when:

• Designers need to convey world information, character development, or narrative context
• You want to avoid cutscenes or lengthy text explanations
• Players need to understand political/social conflicts or story context
• You want to maintain immersion and gameplay flow

Prerequisites

• Established game world setting
• Political/social conflict or story context established
• Environmental assets available or planned

Core Principle

Treat the game world setting as a character itself—give it equal importance to any character in the story. All character development should occur within this setting.

Execution Process

1. Identify Narrative Information

Determine what information players need to understand:

• Who is in power
• Who are supporters vs. opponents
• What each faction's demands are
• Why the conflict/war is happening

2. Select Environmental Elements

Choose appropriate environmental storytelling techniques:

• Graffiti on walls: Reveal which faction represents lower-class interests, or warn of dangers the conflict may bring
• Closed doors and windows: Suggest residents' fear or imply evacuation
• Radio broadcasts: Indirectly inform players which side is winning, their goals, interests, or prohibitions—without interrupting gameplay
• NPC conversations: Pedestrians discussing shortages or problems can reveal the origins of conflict

3. Design Character Spaces

Use personal environments to reveal character traits:

• Room contents (e.g., philosophy and nature books) reveal interests
• Environmental details provide context for future interactions
• Helps players recognize character development during gameplay

4. Implement and Test

• Place elements in the environment naturally
• Ensure they require player observation/attention
• Verify information is discoverable without excessive effort
• Test that players can piece together the narrative context

Constraints

• Does NOT replace main narrative
• Cannot convey extremely complex plot points alone
• Requires player observation and attention
• Environmental elements must feel organic to the setting

Expected Outcome

Players gain substantial information about the setting without any cutscenes, avoiding exposition fatigue. Players better immerse in the game's narrative, with story gradually surfacing as gameplay progresses.

experience-pacing-structure--attention-management.md

Attention Management Techniques

Chunking Content

Example: Mario Levels

• Each level is ~3-5 minutes
• Introduces 1-2 new mechanics per level
• Builds complexity gradually

Social Games

FarmVille/Candy Crush:

• Task: Plant crop → wait 5 minutes → harvest (2-minute cycle)
• Daily bonus: Encourages return every 24 hours
• Lives system: Limits play sessions to ~15-20 minutes

Hybrid Structures

Open World with Focused Story:

• Sandbox exploration: Player-driven pacing
• Story missions: Structured 10-15 minute experiences
• Combines freedom with attention management

Warning Signs

• Players leaving game during long loads
• Tutorial abandonment before completion
• Repetitive content causing disengagement

experience-pacing-structure.md

name	description
experience-pacing-structure	Use when designing game flow, level structure, loading screens, cutscenes, or any content introduction. Applies when introducing new concepts, transitioning between scenes, managing player attention spans, or structuring sandbox vs. linear experiences.

Experience Pacing and Structure

Structure and pace game experiences to match player cognitive limits while introducing new content effectively.

When to Apply

• Introducing new game mechanics or content
• Designing loading screens or transitions
• Planning level progression or game loops
• Structuring sandbox vs. linear experiences
• Implementing attention management systems
• Creating selection menus or map systems

Advance Organizers

Advance organizers are introductory materials with higher abstraction that precede actual learning tasks, helping players:

• Connect new concepts with prior knowledge
• Place new information into context
• Prepare for upcoming information or transitions

Implementation Types

Pre-publicity:

• Use: Ads, demos, trailers, industry conferences
• Goal: Raise awareness of upcoming releases
• Technique: Alternate between reality and game content
• Outcome: Set expectations regarding genre or series

Loading Screens:

• Content: Introduce at least one game character or establish visual tone
• Indicators: Include time prompts (spinning ball, timer) to show background work
• Outcome: Signal that something new and exciting is imminent

Cutscenes:

• Use: Non-playable story sequences at start or during transitions
• Content: Provide backstory and context
• Outcome: Set expectations, suspense, and signal content/scene changes

Selection Menus:

• Design: Use visual structures (maps, not lists) to prepare players mentally
• Avoid: Simple lists which disorient

Critical Constraints

• Use ONLY when introducing new content
• Do not force long loading screens if no new content follows
• Warning: If this occurs, it indicates a technical content loading/storage issue requiring developer resolution
• Consistency: Ensure the organizer matches the game's artistic style

Game Experience Structures

Sandbox Experience Design

Definition: Provide freedom to explore/change things without specific goals.

Mechanism:

• Allow creative combination of simple, independent mechanics
• Create chain reactions from player actions

Developer Tasks:

• Prioritize obvious combinations
• Predict edge cases
• Trust system for unpredicted results

Structure: Can be a small part of a game or full open world (which hides physical boundaries)

Requirement: Simple, combinable mechanics

On Rails Experience Design

Definition: Require linear completion of experience.

Benefit: Focuses player attention on specific tasks and key moments.

Pacing Models:

Train:

• Consistent experience over time
• No twists
• Predictable rhythm

Rollercoaster:

• Sudden direction changes
• Visual stimulation
• Strategic expectation management for surprise

Requirement: Careful pacing to maintain engagement

Attention Span Management

Biological Limits

• Human Attention Span: 7-10 minutes before focus naturally shifts
• Implication: Break experiences into 7-10 minute chunks

Social Game Specifics

• Core loops: Should last 1-2 minutes
• Task completion: Must be completable in under 10 minutes

Retention Strategies

Passive:

• Show new elements/rewards every ~7 minutes
• Maintain variety to prevent boredom

Active:

• Use timers to detect inactivity (1-2 mins)
• Display help/tasks to regain attention

Variables

• content_type: Type of advance organizer (publicity, loading, cutscene, menu)
• art_style: Visual theme of the game
• new_content_available: Whether actual new content follows the organizer
• attention_span: The approximate duration (7-10 mins) a human can maintain focus
• experience_type: Sandbox or On Rails

Design Goals

• Maintain player engagement within cognitive limits
• Smoothly introduce new content without frustration
• Match structure to intended player freedom
• Respect player attention spans

Result Template

A game experience structured to match player cognitive limits and desired freedom levels.

fitts-law-ui-aiming.md

name	description
fitts-law-ui-aiming	Balance speed and precision in UI design and aiming mechanics by applying Fitts' Law principles about movement time, distance, and target size. Use when designing interactive elements that require physical input or aiming.

Fitts' Law for UI and Aiming Mechanics

When to Use

• Designing user interfaces with clickable/tappable elements
• Creating aiming mechanics for combat or interaction
• Optimizing controller or mouse input systems
• Balancing difficulty in precision-based gameplay
• Reducing user fatigue and frustration

Core Concept

Movement time depends on the distance to the target and the target's size. As speed increases, precision decreases—this is a fundamental trade-off.

Key Parameters:

• D = Distance from start point to target center
• W = Width of target along the axis of motion
• H = Height of target (critical for usability)

Execution Steps

1. Analyze the Movement Task

• Identify where the user starts (cursor position, character location)
• Identify the target (button, enemy, interactive element)
• Measure distance (D) and target size (W, H)

2. Apply UI Design Principles

Group Related Elements

• Place similar functional elements together
• Reduces travel distance between related actions
• Creates logical interaction patterns

Optimize Element Placement

• Place frequently used elements near common starting positions
• Example: Place primary actions near where cursor typically rests
• Consider screen edges and corners (effectively infinite targets)

Size Elements Appropriately

• Make frequently used elements larger
• Increase width (W) to reduce required precision
• Ensure adequate height (H)—thin targets are hard to click

Reduce Distance

• Bring UI elements closer to interaction points
• Minimize unnecessary cursor travel
• Consider radial menus for faster access

3. Apply to Combat/Aiming Mechanics

Set Difficulty Parameters

• Adjust target size (W) based on desired difficulty
• Adjust distance (D) to challenge player precision
• Balance both to create intended experience

Test Against Skilled Players

• Fastest/most skilled players set the difficulty ceiling
• If experts can't hit it, it's too hard
• If novices can't hit it, consider difficulty scaling

Consider Movement Constraints

• Player movement speed affects effective distance
• Weapon characteristics affect precision
• Environmental factors (cover, obstacles) modify D and W

4. Validate Through Testing

• Measure actual movement times
• Observe user frustration and fatigue
• Test with different input devices (mouse, controller, touch)
• Iterate based on real user performance

Common Applications

• Button Placement: Size and position based on usage frequency
• Menus: Reduce distance between sequential selections
• Combat Targets: Enemy hitboxes and engagement ranges
• Quick-Time Events: Balance timing windows with target areas
• Drag-and-Drop: Optimize drop zones and travel paths

Key Considerations

• Human physical limits apply
• Extremely small or distant targets can be impossible
• Different input devices have different precision characteristics
• Fatigue increases over time—account for extended sessions
• Accessibility: Some users have reduced motor control
• Visual feedback can help compensate for small targets

Difficulty Balancing

• Easy: Large targets, short distances
• Medium: Moderate targets and distances
• Hard: Small targets, long distances
• Expert: Very small targets, very long distances, or moving targets

flow-state-design-framework.md

name	description
flow-state-design-framework	Apply Mihaly Csikszentmihalyi's flow state principles to design game difficulty curves, tutorials, level progression, and player engagement systems that optimally balance challenge with player skill level. Use when creating or adjusting game progression systems, onboarding experiences, or difficulty mechanics.

Flow State Design Framework

When to Use This Skill

Use this skill when:

• Designing or tuning game difficulty curves
• Creating tutorial or onboarding experiences
• Planning level progression systems
• Optimizing player engagement and retention
• Balancing game challenge against player skill

Core Principles

Flow State Definition: A peak state of intrinsic motivation where players experience full immersion, concentrated focus, and enjoyment of the process itself. Characterized by complete participation, time dilation, and the feeling of being "in the zone."

Fundamental Condition: Player's skill level must match challenge difficulty:

• Challenge too high → Frustration → Player quits
• Challenge too low → Boredom → Player quits
• Ideal: Constantly fluctuate between frustration and boredom to maintain engagement

Three-Stage Player Journey

Stage 1: Introduction (Beginner)

• Player State: Zero or minimal skills in your game mechanics
• Design Action: Lower difficulty to match player skill level
• Implementation:
  • Create introductory levels and tutorials
  • Gradually introduce game mechanics
  • Provide aesthetic rewards (graphics, story, themes) to maintain motivation
• Critical Note: Beginners have no skills—don't assume prior knowledge. Still provide some challenge to avoid making the game "ridiculously easy."

Stage 2: Practice

• Player State: Attracted to the game, actively learning mechanics
• Design Action: Present tasks slightly above current skill level
• Implementation:
  • Design challenges that encourage skill development
  • Let aesthetics, operations, and mechanics support learning
  • Continue until player fully masters required skills for flow
• Duration: Players may spend significant time in this stage

Stage 3: Flow

• Player State: Fully mastered required skills
• Design Action: Balance frustration and boredom precisely
• Implementation:
  • Carefully calibrate challenge difficulty
  • Provide engaging content to maintain immersion for extended play sessions
  • Monitor player skill growth and adjust challenges accordingly

Key Design Considerations

Aesthetics as Bridge

• Use pleasing graphics, engaging stories, and attention-grabbing themes to support early-stage players
• Aesthetics act as rewards for facing new challenges
• Remember: Aesthetics attract initially but cannot sustain long-term engagement alone

Common Pitfalls to Avoid

• Underestimating introductory levels: Many designers fail to account for true beginners having zero skills
• Over-reliance on aesthetics: Visuals and story cannot replace balanced gameplay
• Static difficulty: Player skills grow—challenges must scale appropriately

Constraints

• You cannot force flow state; you can only create conditions that make it likely
• Different players have different skill levels and learning rates
• Aesthetics alone cannot sustain long-term engagement

Variables to Monitor

• player_skill_level: Current capability (beginner to expert)
• challenge_difficulty: Difficulty of current game task
• flow_state: Whether player is currently experiencing flow

Expected Outcome

Optimal difficulty progression that maintains player engagement through balanced challenge-skill matching, leading to immersive flow state experiences.

fundamental-attribution-error-testing.md

name	description
fundamental-attribution-error-testing	Identify and correct Fundamental Attribution Error bias when analyzing game testing feedback or user testing results. Use when interpreting test failures, feedback sessions, or user complaints to distinguish between actual design flaws and situational factors.

Fundamental Attribution Error in Testing

Detect and correct cognitive bias when analyzing test feedback to accurately identify design flaws vs. user-specific issues.

When to Use

• Analyzing game testing feedback
• Interpreting user test failures
• Reviewing feedback from test sessions
• Investigating why users struggle with a design

Identify the Bias Pattern

Self-Attribution (when you experience failure):

• Attribute failures to external/situational factors
• Examples: "I was late", "System lag", "Bad controller", "Interrupted"

Other-Attribution (when others experience failure):

• Attribute failures to internal/personal traits
• Examples: "They are stupid", "Incompetent tester", "Lazy user", "Not paying attention"

Apply to Testing Scenarios

For Testers

• Testers experiencing issues will blame the game ("It's broken", "Bad design")
• They rarely attribute failures to their own state (tired, hungry, distracted)

For Designers

• Designers watching failures will blame the testers ("They are incompetent")
• Or blame the test setup ("Unfinished build", "Wrong configuration")
• They often ignore the game's potential faults

Corrective Actions

When analyzing feedback:

1. Assume the product might be at fault

   • Was the tutorial icon actually visible?
   • Was the button large enough to tap easily?
   • Was the instruction clear and understandable?

2. Check situational factors first

   • Consider the testing environment
   • Evaluate the tester's physical/mental state
   • Review the build quality and stability

3. Do not dismiss feedback

   • Never label issues as "user error" without verification
   • Investigate whether design contributed to the failure
   • Look for patterns across multiple testers

Constraints

• Bias is subconscious and difficult to eliminate completely
• Being aware of the bias doesn't prevent it
• Requires deliberate effort to counteract natural tendencies

game-competency-puzzle-design--competency-examples.md

Game Competency and Puzzle Design Examples

Memory Game Examples

Challenges relying on trial-and-error, memorization, and pattern recognition:

• FPS Level Layouts: Learning map geometry and spawn points.
• Platform Jump Patterns: Memorizing the timing and sequence of jumps.

Skill Game Examples

Challenges requiring physical or mental prowess:

• Billiards: Calculating angles and understanding physics.
• RPG Strategy: Planning builds and resource management.

Assist Mechanics Examples

Specific implementations to reduce frustration in skill-based games:

• Luigi Guide (Super Mario Wii): An AI character takes control to complete a difficult section.
• Tutorial Warp (Duke Nukem): Flying the player back to the first world to relearn basics.
• Visual Pathing: Flashing arrows or highlighting interactive objects.
• Environmental Exploitation: Using enemy bodies or projectiles to reach higher platforms.

game-competency-puzzle-design.md

name	description
game-competency-puzzle-design	Classifies game challenges as Memory-based or Skill-based to prevent player boredom or frustration, and provides specific rules for designing deterministic, fair puzzles. Use this when designing levels, mechanics, or puzzle systems.

Game Competency and Puzzle Design

Use this skill when designing game challenges, level mechanics, or puzzles. It guides the classification of challenges to address player psychology (boredom vs. frustration) and establishes rules for creating valid puzzles.

Procedure

1. Classify the Game Challenge Type

Determine if the challenge relies primarily on Memory or Skill. Note that many games contain elements of both.

• Memory Games: Rely on trial-and-error, memorization, pattern recognition, and mastery of the game state.
• Skill Games: Require physical or mental prowess/attributes.

2. Address Negative Player States

Based on the classification, apply specific mitigation strategies to maintain player engagement.

If Memory-Based (Combat Boredom)

• Problem: Players get bored repeating the same actions in the same areas.
• Solution: Introduce randomness to create variation while keeping core mechanics and story consistent.
• Implementation: Vary enemy locations, add moving platforms, or implement randomized loot drops.

If Skill-Based (Combat Frustration)

• Problem: Players get frustrated if they lack the required skill to proceed.
• Solution: Implement assist mechanics to bridge the gap without compromising the core design.
• Implementation:
  • Hints (e.g., NPC appearing to offer help).
  • Tutorials or help videos (e.g., warping back to a tutorial area).
  • Visual guides (e.g., flashing the correct path).
  • Environmental assistance (e.g., using enemies as stepping stones).

3. Design Puzzles by Key Principles

When designing specific puzzle mechanics, ensure they meet the following criteria:

• Difficulty: Maintain "Flow" (neither too easy nor too hard). Use "Breadcrumbs" (progressive hints) to guide the player through the solution.
• Solution Quality: Solutions must require a smart or intellectual approach, not brute force.
• Determinism: Puzzles must be deterministic once generated. The same inputs must produce the same outputs (unlike dynamic games like Tennis).
• Clarity: Goals and rules must be explicit and fair. Avoid "guess the rule" puzzles where the logic is obscured.

game-design-methodology--methodology-details.md

Detailed Design Methodology Reference

Brainstorming: Advanced Techniques

Combining Methods

For complex projects, combine multiple brainstorming methods:

1. Start with Word Bubbles for initial concept exploration
2. Transition to Tree Diagrams for feature organization
3. Use Flowcharts for mechanic flow
4. Apply Bodystorming for control scheme validation

Group Brainstorming

When brainstorming with a team:

• Assign one person to record all ideas
• No criticism during idea generation phase
• Build on others' ideas explicitly
• Set time limits to maintain energy
• Review and categorize afterward

Core Loop: Depth Analysis

Loop Duration Considerations

Duration	Type	Example
1-5 seconds	Micro-loop	Shooting a gun, jumping
5-30 seconds	Action loop	Combat encounter, puzzle
30 seconds - 5 minutes	Session loop	Level completion, match
5-30 minutes	Play session	Quest completion
Hours	Meta loop	Character progression, season

Loop Failure Modes

Mode 1: No Depth

• Loop is fun once but doesn't evolve
• Players master it quickly and get bored
• Solution: Add complexity layers, combine with other mechanics

Mode 2: No Feedback

• Player doesn't understand impact of actions
• Loop feels meaningless
• Solution: Add clear visual/audio feedback, progress indicators

Mode 3: No Flexibility

• Loop only works in one context
• Cannot extend to new scenarios
• Solution: Design modular actions that combine in multiple ways

Mode 4: No Extension

• Cannot add new actions to the loop
• Game cannot grow
• Solution: Design with hooks for future mechanics

Small Games Application

Not all games need Halo-level ambition:

• Bejeweled: Simple match-3 loop with significant repetition
• Small games can validate core loops for larger experiences
• Use as prototype tools (see Prototyping skill)

Iteration: Advanced Patterns

The Iteration Spiral

        Version 4
            ↑
    Version 3
        ↑
Version 2
    ↑
Version 1 (Prototype)

Each iteration should:

1. Add meaningful content
2. Improve existing mechanics
3. Fix identified issues
4. Move toward final vision

Iteration Scope Management

Per Iteration:

• Focus on 1-3 major additions
• Fix critical bugs from previous iteration
• Gather feedback before next iteration

Avoid:

• Adding too many features per iteration
• Changing core mechanics mid-development
• Skipping testing between iterations

Regression Testing

After each iteration:

• Test all previously working features
• New features can break old ones
• Maintain a test checklist for each iteration

Iteration in Different Game Types

Linear Games (Metroid-style):

• Player abilities iterate (grow)
• Return to previous areas with new abilities
• Each area designed for multiple ability levels

Arcade Games (Donkey Kong-style):

• Loop entire game with increased difficulty
• Same content, different parameters
• Enemy speed, spawn rate, AI aggression

Service Games (MMO, Live Service):

• Content updates as iteration
• Seasonal changes, new areas, balance patches
• Meta-game evolution over years

game-design-methodology.md

name	description
Game Design Methodology	Execute the core game design workflow from ideation through iteration. Use when brainstorming game concepts, designing core gameplay loops, or refining game mechanics through iterative development.

Game Design Methodology

When to Use

• Brainstorming game concepts or mechanics
• Designing or evaluating core gameplay loops
• Planning iterative development cycles
• Refining game mechanics based on testing
• Creating progression systems

Design Workflow

Phase 1: Brainstorming

Select method based on development stage and structure needs.

Free Thinking Methods (Early Development)

Word Bubbles & Idea Webs:

1. Write down one or more words/ideas as origin point
2. Add more words/ideas and connect to origin
3. Extend outward, connecting to origin AND other ideas
4. Result: Interconnected idea map resembling spider web

Best for: Designer has only basic game ideas or plot concepts

Structured Thinking Methods (Later Development)

Flowcharts:

1. Start with origin point like word bubbles
2. Build structure connected to origin
3. Each idea extends to next step without deviation

Best for: Conceiving ordered structure, sequential mechanics

Tree Diagrams:

1. Same starting method as flowcharts
2. Organize ideas in layered, hierarchical structure

Best for: Creating hierarchical items or actions, skill trees, progression systems

Physical Expression Methods

Bodystorming:

1. Use physical body movements to assist creative process
2. Act out character movements or control schemes
3. Especially helpful for motion control technology

Key Principle: Brainstorming should not be limited to writing - demonstrate physically

Phase 2: Core Game Loop Design

The core game loop is the KEY to long-term player satisfaction.

Definition

Core Game Loop = A player-driven behavior that feels fun and players are willing to repeat continuously.

Loop Structure

┌─────────────────────────────────────┐
│                                     │
│    Player's Action                  │
│           ↓                         │
│    Result of Action                 │
│           ↓                         │
│    Player's Reaction                │
│           ↓                         │
│    Game Requires Repeat             │
│           ↓                         │
│    Player's Action (loop)           │
│                                     │
└─────────────────────────────────────┘

Design Requirements

Core loop actions must be:

Requirement	Description
Easy to understand	Clear purpose and outcome
Easy to operate	Intuitive input/response
Enjoyable	Fun in isolation
Direct feedback	Player sees immediate result
Flexible	Adapts to different scenarios
Extensible	Can add extra actions
Combinable	Works with other actions
Evolvable	Supports other game loops

Composition

• Usually composed of a series of VERBS (more specific = better)
• Examples: Steering, Shooting, Sneaking
• Should be describable in a few short sentences
• Should clearly explain the most attractive parts of the experience

Examples

Super Mario Bros:

• Core loop: JUMPING
• Entire game built around jump action
• Other actions inserted: killing enemies, breaking bricks, switching scenes
• Stays fresh through: Various challenges, different action combinations

Halo Series - "30 Seconds of Fun":

• Extends traditional 5-10 second core loops
• Loop: Weapon sequence → Grenade throw → Close combat → Brief recovery → Next battle
• Stays impactful through: New weapons, enemies, terrain, external factors

Critical Warning

If core loop is defective → Nearly impossible to integrate other elements to create fun experience.

A core loop without depth and flexibility won't retain players for long.

Phase 3: Iterative Development

Iteration = Repeatedly performing an action, using previous result as foundation for next repetition.

Development Process

1. Start with prototype: Rough graphics (shapes and letters), minimal functionality
2. Each iteration adds:
   • More feature points
   • More game functions
   • Existing mechanics become more complex
   • Graphics and sound better represent vision
3. Result: More refined, responsive, accessible game

Iteration Types

Internal Iteration (Development):

• Each build improves on previous
• Progressive evolution from "bare bones" to "flesh and blood"

External Iteration (Player-visible):

• Annual sports game updates
• Sequels and expansions
• DLC and content updates

Gameplay Iteration (In-game):

• Tower Defense: Each wave is harder iteration
• Metroid: Player power grows, enabling return to previous areas
• Donkey Kong: Loop back to screen 1 with increased difficulty

Difficulty as Iteration

• Each difficulty level builds on previous level's foundation
• Players encounter new challenges built on previous skills
• Higher difficulty = iteration on core mechanics with increased challenge

Integration Checklist

• Brainstorming method selected based on development stage
• Core loop defined with specific action verbs
• Core loop meets all design requirements
• Iteration plan established for development
• Variety factors identified to keep loops fresh

game-design-principles-reference--principles-full-index.md

Complete Principles Index

Part 1: General Principles of Game Innovation (游戏创新的一般原理)

ID	English Title	Chinese Title
1	Game Symmetry/Asymmetry and Synchronicity	游戏的对称性/非对称性和同步性
2	A is Max, Joker is Wild	A最大，鬼万能
3	Bartle's Player Taxonomy	巴特尔的玩家分类理论
4	Cooperation and Opposition	合作与对抗
5	Fairness	公平
6	Feedback Loops	反馈循环
7	Gardner's Theory of Multiple Intelligences	加德纳的多元智能理论
8	Howard's Law of Hidden Game Design	霍华德的隐匿性游戏设计法则
9	Information	信息
10	Koster's Theory of Fun	科斯特的游戏理论
11	Lazzaro's 4 Keys to Fun	拉扎罗的4种关键趣味元素
12	Magic Circle	魔法圈
13	Taking Action	采取行动
14	MDA: Mechanics, Dynamics, Aesthetics	MDA：游戏的机制、运行和体验
15	Memory and Skill	记忆和技巧
16	Minimax and Maximin	“极小极大”与“极大极小”
17	Nash Equilibrium	纳什均衡
18	Pareto Optimality	帕累托最优
19	Payoff	得益
20	Prisoner's Dilemma	囚徒困境
21	Puzzle Design	解谜游戏的设计
22	Rock Paper Scissors	石头剪刀布
23	7 Universal Emotions	7种通用情感
24	Skinner Box	斯金纳箱
25	Social Relations	社会关系
26	Tragedy of the Commons	公地悲剧
27	Information Transparency	信息透明
28	Van den Berg's Big Five Personality Game Theory	范登伯格的大五人格游戏理论
29	Volunteer's Dilemma	志愿者困境

Part 2: General Principles of Game Creation (游戏创作的一般原理)

ID	English Title	Chinese Title
30	80/20 Rule	80/20法则
31	Brainstorming Methods	头脑风暴的方法
32	Consumer Surplus	消费者剩余
33	Core Game Loop	核心游戏循环
34	Defining Problems	定义问题
35	Design by Committee	委员会设计
36	Environmental Storytelling	环境叙事
37	Experience Design	体验设计
38	Flow	心流
39	4 Creative Methods	4种创意方法
40	Game Genres	游戏体裁
41	Core of the Game	游戏的核心
42	Game Conventions	游戏中的“约定俗成”
43	Gestalt Principle	格式塔原理
44	Supplemental Rules	补充规则
45	Iteration	迭代
46	Magic Wand	魔杖
47	Metagame Thinking	超游戏思维
48	Objects, Attributes, States	对象，属性，状态
49	Attention-Grabbing Methods	吸引注意力的方法
50	Paper Prototyping	纸上原型
51	Pick Two: Fast, Cheap, Good	三选二：快速，便宜，优质
52	Playtesting	游戏测试
53	Barriers to Problem Solving	解决问题的障碍
54	Prototyping	原型
55	Risk Assessment	风险评估
56	Supply and Demand	供需关系
57	Synergy	协同效应
58	Theme	主题
59	Time and Money	时间和金钱
60	User-Centered Design	以用户为中心的设计
61	Wayfinding	路径指示

Part 3: General Principles of Game Balance (游戏平衡的一般原理)

ID	English Title	Chinese Title
62	Addiction Pathways	成瘾途径
63	Attention and Perception	注意与感知
64	Balance and Debugging	平衡和调试
65	Details	细节
66	Doubling and Halving	加倍和减半
67	Economies of Scale	规模经济
68	Player Errors	玩家的错误
69	Unpunished Errors	不被惩罚的错误
70	Hick's Law	希克定律
71	Interest Curve	兴趣曲线
72	Learning Curve	学习曲线
73	Loss Aversion	损失规避
74	Maslow's Hierarchy of Needs	马斯洛需求层次理论
75	Min/Maxing	最小/最大化
76	Punishment	惩罚
77	Sandbox vs. Rails	沙盒与导轨
78	Sustained Attention	持续注意力
79	Variable Rewards	可变奖励

Part 4: General Principles of Problem Solving (解决问题的一般原理)

ID	English Title	Chinese Title
80	Advance Organizers	先行组织者
81	Affordance Cues	功能可见性暗示
82	Buster Principle	巴斯特原则
83	Cognitive Biases	认知偏差
84	Dominant Strategy	占优策略
85	Fitts' Law	菲兹定律
86	Fundamental Attribution Error	基本归因错误
87	Golden Ratio	黄金比例
88	Disruptors	破坏者
89	Pre-Publicity	前期宣传
90	Instant vs. Delayed Gratification	即时满足与延迟满足
91	Don't Make Me Think - Krug's First Law	别让我思考——克鲁克的可用性第一定律
92	Music and Dopamine	音乐与多巴胺
93	Rhythm	节奏
94	Problem-Solving Methods	解决问题的方法
95	Satisficing vs. Optimizing	满意与优化
96	Sense of Accomplishment	成就感
97	Spatial Perception	空间感知
98	Time Dilation	时间膨胀
99	Working Memory	工作记忆
100	Zero-Sum Game	零和博弈

game-design-principles-reference.md

name	description
Game Design Principles Reference	Navigate and apply the 100 Principles of Game Design framework. Use when seeking specific game design principles by number or topic, exploring design knowledge structure, or needing inspiration/reference for game design problems.

Game Design Principles Reference

When to Use

• Navigating the 100 Principles of Game Design document structure
• Locating specific principles by ID number (1-100)
• Seeking design knowledge by topic category (Innovation, Creation, Balance, Problem Solving)
• Finding inspiration or solutions during game development
• Understanding relationships between design principles

Document Structure

The 100 principles are organized into 4 thematic parts:

Part 1: General Principles of Game Innovation (Principles 1-29)

Core theory: player psychology, game theory, and fundamental design concepts.

Part 2: General Principles of Game Creation (Principles 30-61)

Practice-focused: development processes, prototyping, and production methods.

Part 3: General Principles of Game Balance (Principles 62-79)

System design: player engagement, learning curves, and reward structures.

Part 4: General Principles of Problem Solving (Principles 80-100)

Usability and UX: cognitive psychology, interface design, and player feedback.

Usage Strategies

Mode Selection Based on Need

1. Random Inspiration: Flip to a random principle when brainstorming stalls
2. Concept Review: Reference specific principles to recall complex concepts
3. Learning: Read unfamiliar sections to gain new insights
4. Problem Diagnosis: Use interconnections between principles to identify root causes
5. Problem Solving: Consult the Appendix for structured problem-solving methods

Navigation Conventions

• Orange text in quotes: Cross-reference to another principle (treat as hyperlink)
• Blue text: Designer name associated with the concept
• Layout: Text explanation on left page, illustrative image on right

Scope Considerations

• Principles are categorized for organization but apply across ALL development stages
• Each principle is a 2-page introduction, not exhaustive treatment
• Use terminology and keywords for deeper web searches

Quick Reference by Topic

Topic Area	Principle Range	Key Concepts
Player Types & Psychology	1-11, 23-28	Bartle Taxonomy, Koster's Fun Theory, Skinner Box
Game Theory	15-22	Nash Equilibrium, Prisoner's Dilemma, Minimax
Development Process	30-61	80/20 Rule, Core Loop, Iteration, Prototyping
Balance & Engagement	62-79	Addiction Pathways, Interest Curve, Loss Aversion
UX & Usability	80-100	Fitts's Law, Affordance, Don't Make Me Think

External Resources

• Website: www.gamedesignprinciples.com
• Appendix contains: Problem-Solving Methods, Contributor Biographies

game-development-planning--planning-examples.md

Detailed Planning Examples

Game Pillars: Innovation Assessment

Risk Assessment for Pillars

When defining pillars, assess originality vs. risk:

• ALL pillars identical to another game → Players recognize patterns → Seen as clone
• Extend, improve, or uniquely mix pillars → Originality without excessive risk

Pillar Cascading Effects

Each pillar affects multiple development areas:

Example: "Accessibility" as a Pillar

• UI Design: Clear, large text and buttons
• Puzzle Design: No trial-and-error mechanics (would violate accessibility)
• Difficulty: Multiple difficulty levels or adaptive difficulty
• Controls: Remappable controls, simple input schemes

If you design trial-and-error puzzles while claiming accessibility as a pillar, you disappoint players who enjoyed other accessible elements.

Problem Statement: Progressive Specificity

Level 1 (Too Broad)

"How do I design a turn-based strategy game for the public?"

Problems:

• No specific audience definition
• No platform constraints
• No scope boundaries
• Results will be too generic

Level 2 (Better)

"How do I design an 8-bit retro side-scrolling fighting game for tablets with F2P business model?"

Improvements:

• Visual style defined (8-bit retro)
• Genre defined (side-scrolling fighting)
• Platform defined (tablets)
• Business model defined (F2P)

Level 3 (Very Specific)

"How do I build an advanced enemy patrol AI?"

Considerations:

• Good for specific technical problems
• May exclude unconventional solutions
• Best used within established project context

80/20 Rule: Common Pitfalls

Pitfall 1: Confusing with Pareto Optimality

• 80/20 Rule (Principle 30): Resource allocation heuristic
• Pareto Optimality (Principle 18): Game theory concept about efficient outcomes
• These are DIFFERENT principles

Pitfall 2: Treating 80/20 as Exact Math

• The ratio is a heuristic, not a precise measurement
• Actual distribution may be 70/30 or 90/10
• The insight matters: minority of features drive majority of engagement

Pitfall 3: Ignoring the "Unimportant" 80%

• Non-core features still need to work
• Polish the 20% first, then ensure the 80% doesn't break the experience
• A buggy menu system ruins even the best core gameplay

Project Constraints: Advanced Scenarios

Scenario 1: Fixed Deadline (Fast required)

Given: Publisher deadline is immovable Trade-off: Must sacrifice either Cheap or Good

• Sacrifice Cheap: Hire contractors, pay overtime
• Sacrifice Good: Cut features, reduce scope

Scenario 2: Limited Budget (Cheap required)

Given: Indie team with limited funds Trade-off: Must sacrifice either Fast or Good

• Sacrifice Fast: Extended development timeline
• Sacrifice Good: Accept lower production values, focus on core mechanics

Scenario 3: Quality Mandate (Good required)

Given: Building reputation, flagship title Trade-off: Must sacrifice either Fast or Cheap

• Sacrifice Fast: Long development cycle
• Sacrifice Cheap: Significant investment in talent and tools

The Mythical Man-Month Principle

From Fred Brooks: "Adding manpower to a late software project makes it later."

Implication: Some constraints cannot be solved by throwing resources at them.

• 9 women cannot have a baby in 1 month
• Some tasks have inherent minimum timelines
• Communication overhead increases with team size

game-development-planning.md

name	description
Game Development Planning	Define game pillars, problem statements, and resource allocation for game projects. Use when starting a new game project, prioritizing development resources, defining project scope, or making strategic trade-offs between speed, cost, and quality.

Game Development Planning

When to Use

• Starting a new game project or pitching to publishers
• Prioritizing development resources and features
• Defining design goals and project scope
• Making strategic project management decisions
• Communicating project direction to team or stakeholders

Planning Workflow

Step 1: Define Game Pillars

Game pillars are high-level, action-focused concepts that guide all development decisions.

Requirements:

• Define 3 pillars (6 is too many)
• Each pillar MUST relate to player ACTIONS, not just art/theme
• Combine into ONE SENTENCE for communication

Brainstorming Questions:

• What if we combine best elements from two genres?
• What if we modify a failed mechanic from another game?
• What if we extend current gameplay to allow new behaviors?
• What if we replicate experiences from other media?

Example - "Fluid Movement" as a Pillar:

• Camera: Third-person (highlights movement advantages)
• Character Design: Tall/thin fits better than short/stout
• Combat: Must extend fluid movement to combat
• World Design: Architecture must communicate climbability
• Animation: Requires many transitions (plan workload)

Step 2: Create Problem Statement

The problem statement is the FIRST and MOST IMPACTFUL step in the creative process.

Three Required Components:

1. Specific Focus - Determine scope: entire game? a system? a specific mechanism?
2. Quantifiable Result - Must yield actionable data
3. Clear Communication - Test by explaining to another designer

Scope Calibration:

Level	Example	Issue
Too Broad	"How do I design a turn-based strategy game?"	Wastes time, insufficient detail
Appropriate	"How do I create a fighting game with light RPG elements and weapon forging?"	Clear boundaries, measurable goal
Too Narrow	"How do I build an advanced enemy patrol AI?"	May exclude unconventional solutions

Validation Method: Explain to a collaborating designer familiar with the problem and methodology.

Step 3: Apply 80/20 Rule for Resource Allocation

Players spend ~80% of time using only ~20% of game features.

Strategic Actions:

• Identify the 20% core features (basic actions: jumping, fighting, leveling)
• Focus development effort on perfecting these core features
• Avoid over-optimizing flashy but rarely-used features

Application Examples:

• Zelda: Players spend 80% of time moving/attacking - prioritize smooth core mechanics
• WoW Movement: Map traversal is frequent - optimize movement speed to prevent frustration
• WoW Endgame: Players spend 80% of endgame effort on raids (20% of content)
• Game Start: Beginning is replayed more than ending - invest accordingly

Step 4: Manage Project Constraints

Use the Fast-Cheap-Good triangle to make explicit trade-offs.

The Constraint Triangle:

        Fast
        /\
       /  \
      /    \
     /      \
   Good ----- Cheap

You can only pick TWO:

Choice	Result	Strategy
Fast + Cheap	Not Good	Prototyping, feasibility checks
Fast + Good	Not Cheap	Hire more staff/experts
Cheap + Good	Not Fast	Independent development, long timeline

Scope Management: Reduce scope (fewer features) to maintain quality without disproportionate time/cost increases.

Warning: It IS possible to have Slow, Expensive, AND Bad - avoid this outcome.

Integration Checklist

• 3 action-focused pillars defined and communicated
• Problem statement has specific focus, quantifiable result, clear communication
• Core 20% features identified for priority development
• Two constraints prioritized, third explicitly managed
• Scope adjusted to match available resources

game-prototyping-testing.md

name	description
Game Prototyping and Testing	Validate game designs and identify issues through prototyping and testing methodologies. Use when validating game concepts, finding bugs, testing player experience, or ensuring game quality before full development.

Game Prototyping and Testing

When to Use

• Validating a game concept before full development
• Finding bugs and usability issues
• Testing player experience and fun factor
• Ensuring game communicates clearly
• Verifying server stability for online games

Prototyping Methods

Paper Prototyping

Best for: UI design, card games, board games, early concept validation

Materials: Paper, scissors, pens

Advantages:

• Fastest and cheapest method
• Immediate iteration
• Easy to modify

Techniques:

• Use color/texture to distinguish elements
• Create multiple versions quickly
• Test with actual players immediately

Digital Prototyping

Best for: Video game mechanics, control schemes, timing-sensitive gameplay

Tools: Touch screens, middleware, game engines

Advantages:

• Faster iteration after initial setup
• Easy sharing with remote team
• More accurate representation of final experience

General Prototyping Principles

Purpose: Create representative models to test:

• Feasibility (can we build this?)
• Usability (can players understand this?)
• Market demand (will people want this?)

Warning: Never skip prototyping to save time in early stages.

Testing Methods

Kleenex Test

Definition: One-time use per test subject.

Purpose: Validates first impressions and initial learning curve.

Process:

1. Bring in fresh player who has never seen the game
2. Observe their first interaction
3. Record where they struggle or get confused
4. Do NOT reuse the same player for this test type

Best for: Tutorial design, first-time user experience, onboarding

Black Box Testing

Definition: Subject knows nothing about the design.

Purpose: Reveals natural player behavior vs. designer intent.

Process:

1. Give player the game with no instructions beyond basic controls
2. Observe how they naturally approach the game
3. Note where their assumptions differ from design intent
4. Identify UI/UX issues that mislead players

Best for: Discovering unintended gameplay, finding confusing elements

White Box Testing

Definition: Subject follows a script or specific path.

Purpose: Finds specific bugs and logic errors.

Process:

1. Create test script covering specific features
2. Guide player through predetermined actions
3. Document any bugs or unexpected behavior
4. After fixes, perform Regression Testing

Regression Testing: Re-test all previously working features after bug fixes.

Best for: QA, bug hunting, feature verification

Load Testing

Definition: Simulate thousands of players simultaneously.

Purpose: Check server stability and performance.

Application: MMOs, online multiplayer games, live service games

Process:

1. Simulate expected player load
2. Monitor server performance
3. Identify bottlenecks and failure points
4. Test beyond expected load for safety margin

Best for: Online games before launch, major updates

Testing Goals

Ensure the game is:

Goal	Validation Method
Fun	Kleenex test, observe emotional reactions
Clear	Black box test, track confusion points
Functional	White box test, bug reports
Stable	Load test, performance metrics

Testing Cycle

┌─────────────────────────────────────┐
│                                     │
│    1. Prototype                     │
│           ↓                         │
│    2. Test                          │
│           ↓                         │
│    3. Analyze Results               │
│           ↓                         │
│    4. Iterate                       │
│           ↓                         │
│    Return to Step 2                 │
│                                     │
└─────────────────────────────────────┘

Quick Reference

Method	When to Use	What It Reveals
Paper Prototype	Early concept, UI/board games	Core mechanics viability
Digital Prototype	Video game mechanics	Feel, timing, controls
Kleenex Test	First-time experience	Onboarding, tutorials
Black Box Test	Natural behavior	UX issues, assumptions
White Box Test	Bug hunting	Technical issues
Load Test	Online games	Server stability

game-team-management.md

name	description
Game Team Management	Manage diverse game development teams and balance creative vision with collaborative processes. Use when leading a game development team, resolving creative conflicts, establishing shared vision, or improving team communication.

Game Team Management

When to Use

• Leading a diverse game development team
• Resolving creative conflicts between team members
• Establishing or communicating project vision
• Improving team communication and collaboration
• Balancing individual expertise with team coherence

The Committee Design Challenge

Core Tension

Balancing practical game development issues with creative pioneering spirit.

This balance is difficult for one person, sometimes even for a team.

The Diversity Paradox

Individual Limitations:

• One designer's passion may focus on: core loops, interest curves, dominant strategies, narrative, visual syntax, skill evolution, or music
• No one can be expert in ALL areas
• Deep expertise in one area = sacrifice of curiosity in others (24 hours/day constraint)

Diversity Benefits:

• More diverse team = greater potential for unique, non-formulaic design
• Can appeal to broader audience
• Stronger experiences = more memorable

Diversity Risks:

• Lack of consistency and unity
• Game becomes strange patchwork
• Committee design = creative blessing but organizational nightmare

Management Strategies

1. Development Process Structure

Implement structured methodologies:

• Waterfall: Sequential phases, clear milestones
• Agile: Iterative sprints, regular reassessment

Benefits:

• Improved consistency
• Reliable development schedules
• Better planning

2. Leadership Structure

Establish reliable, experienced managers as:

• Team leads
• Producers
• Project managers
• Directors

Purpose: Effectively organize game development process

3. Shared Vision

Leader Functions:

• Communicate final vision
• Make fully informed decisions
• Gatekeep for quality and standards

Shared Vision Benefits:

• Elevates game Theme
• Accelerates design decisions
• Curbs committee design chaos
• Gives team members ownership sense
• Shows how to make useful contributions

Effective Application: When used by trusted leader, shared vision:

• Motivates and unites team
• Establishes expectation of results
• Helps answer team member questions
• Serves as test standard for design process

Leadership vs Committee Balance

Key Recognition

• Conflict is possible but not always irreconcilable
• Some projects need strong decision-maker
• Following one person's vision may not be best approach
• Can be painful for other team members
• Depends on how leader treats team members

Decision Framework

Situation	Recommended Approach
Clear creative lead with strong vision	Strong decision-maker
Collaborative culture, experienced team	Collaborative
Mixed experience levels	Balanced with clear final authority
Multiple stakeholders (publisher, licensor)	Structured approval process

Team Communication Principles

Role Functions

• Constructive criticism
• Sincere listening
• Running effective meetings

Communication Standards

Most important factor in creative fields.

When conveying messages (good or bad):

• Be fair
• Be accurate
• Consider perspective of entire team AND audience

Key Recognition: Everyone in the room has personal stake in the discussion.

EMPATHY is essential.

Ideal Outcome

A group of experts working together under shared vision:

• Creates unified, coherent whole
• Result is better than any individual could create alone

Quick Reference

Challenge	Solution
Inconsistent design	Establish shared vision early
Slow decisions	Clear leadership structure
Team conflict	Communication standards, empathy
Creative chaos	Development process structure
Lack of ownership	Include team in vision development

golden-ratio-design.md

name	description
golden-ratio-design	Use the Golden Ratio (Phi = 1.618) to create naturally pleasing proportions in UI layouts, architecture, environment art, and rectangular elements. Apply when designing spatial elements or proportions to create aesthetic comfort or deliberate tension.

Golden Ratio (Phi) in Design

When to Use

• Designing UI layouts, game boards, or rectangular elements
• Creating architectural proportions or environment art
• Needing to establish naturally pleasing or attractive proportions
• Wanting to create deliberate discomfort or tension through proportion violation

Core Concept

The Golden Ratio (Phi, φ = 1.61803398875) is a mathematical proportion found throughout nature and used in design since ~450 BC.

Formula: (a + b) / a = a / b

• a = larger quantity
• b = smaller quantity
• a + b = whole

Execution Steps

1. Define Your Proportions

• Identify the dimensions you're working with (width, height, spacing)
• Determine which dimension represents the larger quantity (a) and smaller (b)

2. Apply Golden Ratio for Positive Experience

• Set proportions so that (a + b) / a = 1.618
• For rectangles: Short side = a, Long side = a + b
• Use Fibonacci sequence (1, 1, 2, 3, 5, 8, 13, 21, 34...) as a progressive approach
• Apply to UI element sizing, layout grids, or spatial relationships

3. Apply for Negative Experience (Tension)

• Deliberately violate the Golden Ratio to create subconscious discomfort
• Useful for unsettling environments, horror games, or specific narrative moods
• Consider how deviation from 1.618 affects player/user perception

4. Validate Through Testing

• Observe user/player reactions to the proportions
• Adjust based on feedback and intended emotional response

Common Applications

• UI Design: Button sizes, layout grids, element spacing
• Architecture: Building facades, room proportions, window placement
• Environment Art: Natural formations, structures, landscape composition
• Game Boards: Board game layouts, card dimensions, play areas

Key Considerations

• The ratio can be approximated (1.6 is often sufficient)
• Context matters—cultural and design conventions may override mathematical perfection
• Use as a guideline, not a rigid rule
• Consider accessibility and usability alongside aesthetics

hicks-law-decision-optimization.md

name	description
hicks-law-decision-optimization	Optimize user interfaces, game menus, and navigation systems by applying Hick's Law to estimate decision time based on number of choices. Use when designing choice interfaces to reduce cognitive load and prevent decision paralysis.

Hick's Law Decision Optimization

When to Use

• Designing user interfaces with multiple options
• Creating game menus or navigation systems
• Presenting lists of similar, ordered choices
• Users must make a selection from available options
• Wanting to reduce decision time and cognitive load

Core Concept

Decision time increases logarithmically as the number of choices increases. Too many options can cause decision paralysis and abandonment.

Formula: T = a + b × log₂(n)

• T = Reaction time
• n = Number of choices
• a = Base time for non-choice cognitive processes
• b = Time per bit of information processing

Execution Steps

1. Count Your Choices

• Identify all options available to the user
• Determine if choices are similar/ordered or unrelated

2. Estimate Decision Impact

• More choices = logarithmically longer decision time
• Too many choices = higher probability of abandonment
• Unrelated/unordered choices = linear (worse) time growth

3. Apply Design Strategies

Limit Options (Primary Strategy)

• Aim for 3-6 items for optimal decision speed
• Remove unnecessary options
• Consolidate similar choices

Group Similar Options

• For complex lists (e.g., large inventories), create categories
• Each category reduces effective 'n' for that decision
• Example: Amazon groups products by type, brand, price range

Structure Menus Hierarchically

• Fewer main options with more sub-options
• Avoid many main options with few sub-options
• Use progressive disclosure

4. Handle Exceptions

Customization Scenarios

• If user has specific pre-existing preferences (e.g., character appearance)
• Provide more options but organize into categorized sub-menus
• Allow filtering and sorting

Expert Users

• Power users may prefer more options visible
• Consider providing both simple and advanced modes

5. Validate Through Testing

• Prioritize playtesting over strict mathematical calculation
• Human cognitive limits may override theoretical predictions
• Example: 4 million options is not just "30x harder" than 4—it's overwhelming
• Measure actual decision time and abandonment rates

Common Applications

• Main Menus: Keep options minimal and clear
• Settings Menus: Group related settings together
• Inventory Systems: Use categories, filters, and search
• Dialog Trees: Limit branch complexity at each node
• Skill Trees: Organize into logical groups

Key Considerations

• The law applies best to similar, ordered choices
• Context matters—expert users handle more complexity
• Visual design can mitigate cognitive load (icons, grouping)
• Always test with real users
• Balance between choice and decision paralysis

index.md

# Game Design & Development Skills Collection

This collection contains a comprehensive set of skills derived from professional game design literature. It covers core methodologies, user experience (UX) principles, psychology, mechanics, level design, and production management. These skills enable Claude to assist with tasks ranging from initial concept ideation and team leadership to specific mechanic balancing, UI optimization, and player testing analysis.

## Available Skills

| Skill | Description | Use When |
|-------|-------------|----------|
| [user-centered-design](user-centered-design/SKILL.md) | Apply ISO 9241-210 User-Centered Design principles when designing interfaces, systems, or games. | You need to ensure your design is optimized for specific target users' needs, goals, and tasks. |
| [game-prototyping-testing](game-prototyping-testing/SKILL.md) | Validate game designs and identify issues through prototyping and testing methodologies. | Validating game concepts, finding bugs, testing player experience, or ensuring game quality before full production. |
| [environmental-storytelling-technique](environmental-storytelling-technique/SKILL.md) | Apply environmental storytelling techniques to convey world information, character development, or narrative context through game environments. | Designing game worlds where narrative must be shown through the environment rather than cutscenes or text. |
| [game-competency-puzzle-design](game-competency-puzzle-design/SKILL.md) | Classifies game challenges as Memory-based or Skill-based to prevent player boredom or frustration, and provides specific rules for designing deterministic, fair puzzles. | Designing levels, puzzles, or challenges and needing to balance difficulty and player competency. |
| [hicks-law-decision-optimization](hicks-law-decision-optimization/SKILL.md) | Optimize user interfaces, game menus, and navigation systems by applying Hick's Law to estimate decision time based on number of choices. | Designing choice interfaces to reduce cognitive load and improve decision-making speed. |
| [fundamental-attribution-error-testing](fundamental-attribution-error-testing/SKILL.md) | Identify and correct Fundamental Attribution Error bias when analyzing game testing feedback or user testing results. | Interpreting test failures, feedback sessions, or user complaints to distinguish between player error and design error. |
| [game-team-management](game-team-management/SKILL.md) | Manage diverse game development teams and balance creative vision with collaborative processes. | Leading a game development team, resolving creative conflicts, establishing shared vision, or improving collaboration. |
| [dynamic-difficulty-adjustment](dynamic-difficulty-adjustment/SKILL.md) | Use when implementing systems to adjust game difficulty based on player performance, frustration, or failure patterns. | Designing boss battles, skill-based challenges, or tasks where player skill varies widely. |
| [player-psychology-decisions](player-psychology-decisions/SKILL.md) | Use when designing game mechanics, challenges, puzzles, or decision systems that involve player choice, problem-solving, or risk assessment. | You need to account for cognitive biases, probability assessment, and player decision-making patterns. |
| [character-optimization-design](character-optimization-design/SKILL.md) | Use when designing character creation systems, unit attributes, or stat-based progression. | Players can allocate points to customize characters/units, or when balancing RPG, wargame, or strategy systems. |
| [golden-ratio-design](golden-ratio-design/SKILL.md) | Use the Golden Ratio (Phi = 1.618) to create naturally pleasing proportions in UI layouts, architecture, environment art, and rectangular elements. | Designing spatial elements or proportions that require aesthetic harmony and visual appeal. |
| [flow-state-design-framework](flow-state-design-framework/SKILL.md) | Apply Mihaly Csikszentmihalyi's flow state principles to design game difficulty curves, tutorials, level progression, and player engagement systems. | Designing systems that optimally balance challenge with player skill levels to maintain engagement. |
| [reinforcement-feedback-systems](reinforcement-feedback-systems/SKILL.md) | Use when designing punishment mechanics, reward systems, or player feedback loops. | Structuring win/lose conditions, combat systems, progression mechanics, or systems shaping player behavior. |
| [synergy-thematic-design](synergy-thematic-design/SKILL.md) | Use when defining game narrative tone, combining game mechanics, or ensuring design cohesion across all game elements. | Creative direction, narrative design, or mechanics integration needs to align with a unified theme. |
| [game-design-methodology](game-design-methodology/SKILL.md) | Execute the core game design workflow from ideation through iteration. | Brainstorming game concepts, designing core gameplay loops, or refining game mechanics through iterative development. |
| [fitts-law-ui-aiming](fitts-law-ui-aiming/SKILL.md) | Balance speed and precision in UI design and aiming mechanics by applying Fitts' Law principles about movement time, distance, and target size. | Designing interactive elements that require physical interaction, such as buttons or crosshair targeting. |
| [game-development-planning](game-development-planning/SKILL.md) | Define game pillars, problem statements, and resource allocation for game projects. | Starting a new game project, prioritizing development resources, defining project scope, or making strategic decisions. |
| [visual-player-guidance](visual-player-guidance/SKILL.md) | Use when designing visual elements that need to guide player interaction, focus attention, or facilitate navigation in UI/HUD, game environments, or puzzles. | Players need to intuitively understand where to go or what to interact with without explicit instructions. |
| [doubling-halving-balance](doubling-halving-balance/SKILL.md) | Rapidly identify game balance issues by doubling or halving core game variables (movement, time limits, resources, health/damage) during prototyping and balance tuning. | You need to quickly validate balance issues or tune core game variables. |
| [game-design-principles-reference](game-design-principles-reference/SKILL.md) | Navigate and apply the 100 Principles of Game Design framework. | Seeking specific game design principles by number or topic, exploring design knowledge structure, or needing inspiration. |
| [player-error-handling](player-error-handling/SKILL.md) | Classify and design responses for player errors in games. | Analyzing player behavior issues, designing error-tolerant systems, improving user experience, or creating helpful feedback. |
| [experience-pacing-structure](experience-pacing-structure/SKILL.md) | Use when designing game flow, level structure, loading screens, cutscenes, or any content introduction. | Introducing new concepts, transitioning between scenes, managing player attention spans, or structuring narrative delivery. |

## Quick Navigation

### Core Design & Methodology
- **game-design-methodology**: Execute the core workflow from ideation to iteration.
- **game-design-principles-reference**: Navigate the 100 Principles of Game Design framework.
- **game-development-planning**: Define pillars, problem statements, and resource allocation.
- **user-centered-design**: Apply ISO 9241-210 principles to optimize for target users.

### Game Mechanics & Balance
- **dynamic-difficulty-adjustment**: Adjust difficulty based on player performance and frustration.
- **reinforcement-feedback-systems**: Design punishment, reward, and feedback loops.
- **flow-state-design-framework**: Balance challenge and skill to maintain player engagement.
- **character-optimization-design**: Design character creation and stat-based progression systems.
- **doubling-halving-balance**: Rapidly identify and fix balance issues by adjusting variables.

### Level Design & Puzzles
- **game-competency-puzzle-design**: Design fair puzzles using Memory vs. Skill classification.
- **environmental-storytelling-technique**: Convey narrative through game environments.
- **experience-pacing-structure**: Manage game flow, transitions, and content introduction.
- **visual-player-guidance**: Guide player attention and navigation intuitively.

### UX, UI & Interaction
- **hicks-law-decision-optimization**: Reduce cognitive load in choice interfaces.
- **fitts-law-ui-aiming**: Optimize speed and precision for interactive elements.
- **player-error-handling**: Classify errors and design error-tolerant systems.
- **game-prototyping-testing**: Validate designs and identify issues through testing.

### Psychology & Player Behavior
- **player-psychology-decisions**: Account for biases and risk in decision-making mechanics.
- **fundamental-attribution-error-testing**: Correct bias when analyzing user feedback.

### Visual & Aesthetic Design
- **golden-ratio-design**: Create pleasing proportions using the Golden Ratio.
- **synergy-thematic-design**: Ensure cohesion between narrative, mechanics, and visuals.

### Production & Team Management
- **game-team-management**: Lead teams and balance creative vision with collaboration.

## How to Use
To invoke a specific skill, reference the skill name or path when asking Claude to perform a task. For example: *"Use the `flow-state-design-framework` skill to help me balance the difficulty curve for Level 3."* Claude will then load the specific instructions and context relevant to that domain to assist you effectively.

player-error-handling.md

name	description
Player Error Handling	Classify and design responses for player errors in games. Use when analyzing player behavior issues, designing error-tolerant systems, improving user experience, or creating helpful feedback for player mistakes.

Player Error Handling

When to Use

• Analyzing player behavior during playtesting
• Designing error-tolerant game systems
• Creating feedback for player mistakes
• Improving user experience and accessibility
• Debugging player flow issues

Error Classification System

Level 1: Primary Categories

┌─────────────────────────────────────┐
│        Player Errors                │
└─────────────┬───────────────────────┘
              │
    ┌─────────┴─────────┐
    ▼                   ▼
Motor Control       Behavioral
Errors               Errors

Motor Control Errors

Definition: Errors stemming from player coordination, mastery, or application of input devices.

Examples:

• Simple: Accidentally pressing wrong button
• Complex: Failing to time a boss fight action correctly
• Physical: Accidentally knocking over chess pieces

Design Responses:

• Understand target audience capabilities
• Conduct playtesting to predict and control these errors
• Consider player age or physical condition limitations
• Example: Board games for children shouldn't use tiny pieces
• Console games must consider controller familiarity

Level 2: Behavioral Error Subtypes

┌─────────────────────────────────────┐
│        Behavioral Errors            │
└─────────────┬───────────────────────┘
              │
   ┌──────────┼──────────┐
   ▼          ▼          ▼
Procedure  Omission   Wrong
Errors     Errors     Action

Procedure Errors

Definition: Adding extra, unwanted steps to a procedure.

Example: Player thinks they need to return to main menu to find map, when current screen has access.

Causes:

• Confusing interface design
• Inattentional blindness

Design Response: Improve UI clarity, reduce unnecessary navigation paths

Omission Errors

Definition: Failing to complete one step in an action sequence, missing something important.

Design Responses:

• Keep action sequences short and direct
• Ensure step information is obvious, logical, or intuitive
• Balance learning curve appropriately

Wrong Action Errors

Definition: Executing wrong action in a situation - should do one thing but did another.

Design Response: Apply "Unpunished Errors" principle

Provide:

• Entertaining failure states
• Witty, clever hint messages
• Opportunities to recover without major penalty

Design Response Framework

General Principles

1. Predict possible error types for your game
2. Prepare countermeasures in advance
3. Provide helpful hint text
4. Guide players back to correct direction
5. Make occasional mistakes amusing, not frustrating

Error Severity Response Matrix

Severity	Response
Minor	Subtle visual/audio cue
Moderate	Clear feedback, easy recovery
Major	Explicit guidance, minimal penalty
Critical	Auto-save, checkpoint, or undo option

Target Audience Considerations

Audience	Motor Control Focus	Behavioral Focus
Children	Large UI elements, simple inputs	Short sequences, obvious steps
Casual	Forgiving timing, clear prompts	Guided tutorials, hints
Hardcore	Precise challenges accepted	Complex sequences allowed
Accessibility	Alternative input methods	Extended time limits

Quick Reference

Error Type	Key Characteristic	Primary Design Response
Motor Control	Input coordination	Know audience, playtest
Procedure	Extra unwanted steps	Clear UI, reduce paths
Omission	Missing step	Short sequences, obvious info
Wrong Action	Incorrect choice	Entertaining failure, recovery

Integration with Related Principles

• Principle 63 (Attention and Perception): Understand why players miss information
• Principle 64 (Balance and Debugging): Error handling as part of balance
• Principle 69 (Unpunished Errors): Design philosophy for forgiving gameplay

player-psychology-decisions--bias-examples.md

Real-World Bias Examples in Games

Confirmation Bias

• Scenario: Player believes enemy type is weak to fire
• Result: Ignores evidence showing ice works better, only notices fire successes

Availability Heuristic

• Scenario: Player has one bad experience with a mechanic
• Result: Avoids that mechanic despite it being statistically good

Anchoring

• Scenario: First weapon has damage value of 10
• Result: All subsequent weapons judged against that baseline (15 feels strong, 5 feels weak)

Functional Fixedness Example

• Game: Zelda series
• Problem: Player only uses bombs for breaking walls
• Solution: Later puzzles require using bombs as projectiles, stunning enemies, or clearing water
• Design: Early scenarios show varied uses to prevent fixedness

player-psychology-decisions.md

name	description
player-psychology-decisions	Use when designing game mechanics, challenges, puzzles, or decision systems that involve player choice, problem-solving, or risk assessment. Applies when you need to account for cognitive biases, prevent player frustration, or structure risk-reward scenarios.

Player Psychology in Decision Making

Design game systems that account for cognitive biases, problem-solving obstacles, and risk-reward decision patterns.

When to Apply

• Designing puzzles or challenges
• Creating combat or strategic systems
• Implementing risk-reward mechanics
• Structuring player choices
• Analyzing player behavior and feedback

Cognitive Biases Affecting Player Perception

Players interpret game events through psychological filters, not objective reality.

Confirmation Bias

• Pattern: Players notice and believe information matching pre-existing beliefs; ignore contradictory evidence
• Impact: Players may reject game facts that don't fit their mental model
• Design Consideration: Provide overwhelming evidence when challenging player assumptions

Availability Heuristic

Negativity Bias:

• Negative/emotional experiences are easier to remember than neutral ones
• Example: Players remember bad Scrabble hands more than good ones

Recency Bias:

• Recent events are weighted more heavily than historical data
• Can create false perceptions of trends from random events

Anchoring

• Pattern: Players relate all new information to an initial "anchor" (e.g., sale price vs. original price)
• Application: First impressions strongly shape subsequent interpretations

Framing/Kuleshov Effect

• Pattern: How information is packaged (wording, UI, context) changes interpretation
• Kuleshov Effect: Players derive context from surrounding information to fill in ambiguous signals
• Example: Random AI bark may be interpreted as intelligent based on surrounding cues

Problem-Solving Obstacles

Design challenges while recognizing why players get stuck:

Common Cognitive Blocks

Functional Fixedness:

• Player knows a function (break brown box) but can't apply it to variation (blue box)
• Mitigation: Provide visual/audio cues linking similar interactions

Irrelevant Information:

• Too much detail obscures the solution
• Example: Picking up knife when holding guns
• Mitigation: Focus player attention on relevant elements

Assumptions:

• Player assumes impossibility without trying (e.g., jump distance)
• Mitigation: Visual/audio cues, generous save points, low-risk testing areas

Mental Set:

• Stuck in previous habits
• Example: Contra controls changing in 3D section
• Mitigation: Gradual transition, clear tutorial for new patterns

Risk Assessment and Decision Making

Cost-Benefit Analysis

Players weigh failure risk against reward value:

Triangularity:

• Offer choices between:
  • Low Risk / Low Reward paths
  • High Risk / High Reward paths
• Engages strategic decision-making

Hoarding Behavior:

• Players save powerful items (bombs) "just in case"
• Perceived risk of not having them later > current benefit
• Design Response: Make items feel necessary or abundant enough to use

Design Goals

• Force frequent decisions to maximize engagement
• Balance challenge to avoid frustration
• Provide clear feedback on decision outcomes

Variables

• obstacle_type: Category (Fixedness, Irrelevant Info, Assumption, Mental Set)
• risk_level: Probability and cost of failure
• reward_value: Benefit of success
• bias_type: Cognitive bias affecting perception

Constraints

• Biases operate subconsciously—players may not be aware of them
• Different individuals may vary, but general patterns apply
• Poorly designed obstacles cause frustration

Result Template

Player engages in strategic decision-making or overcomes a cognitive block through thoughtful design.

reinforcement-feedback-systems--reward-systems.md

Reward System Examples and Patterns

Fixed Reward Progression

RPG Quests:

• Quest 1: 100 gold, 50 XP
• Quest 2: 150 gold, 75 XP
• Quest 3: 200 gold, 100 XP
• Result: Players know what to expect, can plan builds

Variable Reward Patterns

MMO Loot Drops:

• Boss always drops items (fixed component)
• Item rarity and stats vary (variable component)
• Legendary drop: 1% chance
• Result: Players farm bosses repeatedly

Gacha Games:

• Fixed cost per pull
• Variable reward rarity
• "Pity" system guarantees rare item after X pulls
• Result: High engagement, high monetization

Hybrid Systems

World of Warcraft:

• Quests: Fixed gold/XP (predictable income)
• Dungeons: Variable loot drops (excitement)
• Raids: Tiered rarity (progression + surprise)

Destiny:

• Activities: Fixed currency
• Engrams: Variable quality items
• Balance: Players know they'll get something, but quality varies

Punishment Examples

Mario Series:

• Lose life → Restart level checkpoint
• Game over → Restart from beginning
• Design: Punishment creates stakes but is forgiving

Dark Souls:

• Die → Lose all currency, restart at bonfire
• Can recover currency if you reach death spot
• Design: High stakes, second chance mechanic

Hearthstone:

• Lose arena match → One less win remaining
• Design: Punishment limits progression, not resources

Withering Systems

Animal Crossing:

• Turnips rot after 1 week
• Flowers wilt without watering
• Design: Encourages regular check-ins, not punishing

Neopets:

• Pets get hungry/sick over time
• Design: Creates engagement loop without major consequences

reinforcement-feedback-systems.md

name	description
reinforcement-feedback-systems	Use when designing punishment mechanics, reward systems, or player feedback loops. Applies when structuring win/lose conditions, combat systems, progression mechanics, or any system where player behavior needs to be shaped through consequences and incentives.

Reinforcement Systems (Punishment and Rewards)

Design feedback systems that shape player behavior through operant conditioning principles—using punishment to discourage failure and rewards to encourage engagement.

When to Apply

• Designing combat or challenge systems
• Structuring player progression
• Implementing win/lose conditions
• Creating loot or reward distribution
• Designing retention or engagement mechanics

Punishment Models (Negative Reinforcement)

Lives and Game Over Systems

Lose Life:

• Player loses a life or health segment
• Consequence: Restart from last checkpoint
• Severity: Low to medium
• Use: Standard platformers, action games

Continue:

• Player exhausts all lives
• Consequence: Restart from current level start
• Severity: Medium
• Use: Classic arcade games

No Continue (Permadeath):

• Single life only
• Consequence: Restart from game beginning
• Severity: High
• Use: Hardcore modes, roguelikes

Wither Mechanisms

Definition: Attributes degrade over time due to lack of interaction.

Examples:

• Tamagotchi: Health drops if not fed
• Farmville: Crops wither if not harvested

Design Considerations:

• Creates urgency and regular engagement
• Can cause player stress or resentment if too punishing
• Requires balanced timing windows

Permadeath

Mechanism: Single life only. Death is permanent.

Consequences:

• Loss of character, items, and world progress
• Examples: Minecraft Hardcore, hardcore roguelikes

Risk Assessment:

• High player disengagement due to loss of invested time
• Creates intense, meaningful experiences
• Appeals to specific player niche
• Mitigation: Meaningful progression within single run

Reward Systems

Fixed Rewards

Characteristics:

• Known time, type, and quantity
• Example: 50 gold for completing a quest

Player Behavior:

• Clear goal setting
• Predictable effort
• Reduced surprise or discovery
• Efficient grinding

Best For:

• Tutorial progression
• Guaranteed milestones
• Player trust and predictability

Variable Rewards

Characteristics:

• Randomness involved in outcome
• Example: Random loot drops, treasure chests

Player Behavior:

• Stimulates pattern seeking (Skinner box effect)
• Adds surprise and emotional variation
• Encourages repetition of actions (grinding)
• Encourages exploration of space (opening unknown chests)

Design Note:

• Often appears random but is backed by data tables
• Can be manipulated with weighted probabilities

Best For:

• Encouraging exploration
• Extending engagement
• Creating excitement and anticipation
• Replayability

Variables

• failure_state: Type of failure triggered (Life Loss, Wither, Permadeath)
• reward_variance: Whether the reward is fixed or variable (boolean)
• punishment_severity: Impact of failure (Low, Medium, High)
• reward_frequency: How often rewards are distributed

Design Principles

Balance Considerations

• Permadeath risks player disengagement—use carefully
• Fixed rewards lack surprise—mix with variable rewards
• Too harsh punishment causes frustration and quitting
• Too generous rewards reduce sense of achievement

Psychological Basis

Based on Skinner Box / Operant Conditioning:

• Positive reinforcement: Reward desired behavior
• Negative reinforcement: Remove punishment for desired behavior
• Positive punishment: Add punishment for undesired behavior
• Negative punishment: Remove reward for undesired behavior

Execution Workflow

1. Define desired player behaviors to encourage/discourage
2. Select punishment models appropriate to game tone
3. Design reward mix (fixed vs. variable ratios)
4. Set appropriate severity for failures
5. Implement probability tables for variable rewards
6. Test balance—adjust based on player behavior
7. Monitor live data for unexpected player strategies

Result Template

Consequence (loss/progression) or incentive (item/surprise) driving desired player behavior through psychological reinforcement patterns.

skill.md

name	description
game-design	游戏设计全流程助手。基于《游戏设计的100个原理》体系，覆盖从概念到上线的完整游戏开发流程。当用户讨论游戏设计、关卡设计、机制平衡、玩家体验、UI/UX 优化、团队管理等话题时触发。

Game Design Assistant

基于《游戏设计的100个原理》(Wendy Despain) 构建的游戏设计知识体系，覆盖 6 大维度、22 个专项能力。

触发词

• "帮我设计一个游戏"
• "游戏设计"、"关卡设计"、"机制设计"
• "游戏平衡"、"难度曲线"
• "玩家体验"、"玩家心理"
• "/game-design"

---

工作模式

根据用户需求自动切换：

模式	触发场景	做什么
从零开始	"我想做一个游戏"	走完整设计流程
专项咨询	"怎么设计难度曲线"	调用对应专项知识
诊断修复	"玩家反馈太难了"	定位问题 → 给方案
评审优化	"帮我看看这个设计"	用原理体系做 review

---

一、完整设计流程

当用户要从零开始设计游戏时，按此流程推进：

Phase 1: 概念定义

1. 定义 3 根支柱 — 用动作动词描述核心玩法（不是美术/主题）

   • 组合成一句话："这个游戏是 ___"
   • 例：流畅移动 + 精准射击 + 策略选择

2. 写问题陈述 — 三要素：具体焦点 + 可量化结果 + 清晰表达

   • 太宽：浪费时间；太窄：排除好方案
   • 验证：能向合作者解释清楚

3. 80/20 法则 — 玩家 80% 时间用 20% 功能

   • 集中资源做核心 20%
   • 别在冷门功能上过度投入

4. 约束三角 — 快、便宜、好，只能选两个

   • 砍范围 > 砍质量

Phase 2: 核心循环设计

核心循环 = 玩家愿意反复做的有趣行为

玩家行动 → 行动结果 → 玩家反应 → 游戏要求重复 → 玩家行动(循环)

核心循环必须满足：

• 易懂、易操作、有直接反馈
• 有趣（单独玩也好玩）
• 可扩展、可组合、可进化

用动词描述：跳跃、射击、潜行、建造……

• Mario = 跳跃；Halo = 30 秒战斗循环

警告：核心循环有缺陷 → 其他元素无法补救。

Phase 3: 机制与平衡

难度设计（心流框架）

三阶段玩家旅程：

阶段	玩家状态	设计要求
入门	零技能	降低难度、渐进教学、美学奖励维持动力
练习	主动学习	略高于当前能力的挑战
心流	完全掌握	精确平衡挫败感与无聊感

• 挑战太高 → 挫败 → 退出
• 挑战太低 → 无聊 → 退出

动态难度调整（Buster 原则）

暗中调整，玩家不能感知：

• 监控指标：连续失败次数、成功率、耗时、放弃率
• 触发阈值：3-5 次连续失败 / 犹豫增加 / 快速重试
• 调整手段：降低敌人血量/伤害 5-10%、放宽时间窗口、提供资源
• 关键：不能让游戏变得太简单，保留成就感

快速平衡法（加倍/减半）

开发期快速定位问题：

• 对核心变量做 2x 或 0.5x 极端调整
• 变化大 = 这个变量重要（精调它）
• 没变化 = 不重要（忽略它）
• 暴露新问题 = 需要重新设计

奖惩系统

类型	机制	风险
生命/Game Over	低中惩罚	太轻无压力
属性衰退	制造紧迫感	过度则沮丧
永久死亡	高惩罚	高流失风险
固定奖励	可预期、建立信任	缺乏惊喜
随机奖励	刺激探索和刷	斯金纳箱效应

角色/属性系统

防止 min/max 破坏平衡的策略：

• 预设值（安全但少自由度）
• 随机生成（鼓励适应但可能不爽）
• 属性关联（防单属性碾压但增加复杂度）
• 主题引导（鼓励叙事而非数值优化）

Phase 4: 关卡与体验

挑战分类

类型	依赖	防无聊
记忆型	试错/记忆/模式识别	引入随机性
技能型	身体/心智能力	提供辅助机制

谜题设计原则

• 保持心流；用渐进提示（面包屑）
• 要求巧妙思路，非暴力穷举
• 确定性：相同输入 = 相同输出
• 清晰性：目标明确、规则公正

节奏控制

• 人类注意力极限：7-10 分钟
• 社交游戏：1-2 分钟核心循环，<10 分钟完成任务
• 每 ~7 分钟展示新元素
• 不活跃 1-2 分钟 → 显示帮助

体验结构

• 沙盒型：自由探索/改变，系统需简洁可组合
• 线性型：专注关键时刻，一致(火车)或变化(过山车)节奏

环境叙事

不用过场动画讲故事：

• 涂鸦、关闭的门窗、广播、NPC 对话、角色私人空间
• 世界本身就是一个角色

Phase 5: 视觉与交互

视觉引导（不用文字教玩家）

• 可供性：视觉暗示交互方式（按钮用阴影/凸起，圆形=可点击）
• 注意力捕获：面孔 > 运动 > 意外 > 吸引力
• 寻路：地标定向、远处目标吸引、通道制造张力/释放、光线引导

Fitts 定律（UI/瞄准）

• 移动时间 = f(距离, 目标大小)
• 常用元素：放近、放大
• 难度缩放：Easy=大目标短距离 → Expert=小目标远距离移动目标

Hick 定律（选择优化）

• 决策时间随选项数对数增长
• 最优：3-6 个选项
• 多选项时：分组 > 层级 > 过滤
• 专家用户可提供高级模式

黄金比例（Φ = 1.618）

• UI 布局、建筑比例、环境艺术
• 制造不安感时故意违反比例
• Fibonacci 序列(1,1,2,3,5,8,13...)作为渐进近似

Phase 6: 玩家心理

认知偏差清单

偏差	影响	应对
确认偏差	拒绝冲突信息	用压倒性证据
可得性/近因/消极偏差	情绪体验扭曲感知	平衡正负反馈
锚定效应	第一印象锚定后续判断	精心设计首次体验
框架效应	上下文决定解读	控制信息呈现方式

决策设计

• 三角性：低风险低回报 vs 高风险高回报路径
• 囤积行为：玩家会囤积珍贵道具 — 设计要平衡这点
• 解题障碍：功能固着、无关信息、错误假设、心理定势

错误处理

错误类型	例子	设计回应
运动控制	按错键/时机不对	放宽窗口、加大目标
流程错误	UI 混乱导致多余步骤	简化流程
遗漏错误	漏掉序列中的步骤	提示/高亮
错误行动	选了错误操作	有趣的失败 + 恢复机制

测试中的归因偏差

• 测试者：把自己的失败归因于外部（自利归因）
• 设计师：把测试者的失败归因于测试者（基本归因错误）
• 原则：先假设产品有问题，验证后再排除

Phase 7: 原型与测试

方法	用途	特点
纸面原型	UI/卡牌/桌游/早期概念	最快最便宜
数字原型	操作手感/时机/控制	可分享迭代

测试类型	发现什么
一次性测试(Kleenex)	首次印象、新手引导
黑盒测试	自然行为 vs 设计意图
白盒测试	Bug 和逻辑错误
压力测试	服务器稳定性

循环：原型 → 测试 → 分析 → 迭代

Phase 8: 团队管理

• 共享愿景：领导者传达最终愿景，质量把关
• 多样性悖论：多样 = 更独特，但也 = 更难统一
• 流程选择：瀑布(顺序) vs 敏捷(迭代冲刺)
• 沟通原则：建设性批评、真诚倾听、高效会议、共情

---

二、主题一致性检查

每个设计决策都要回答：这支持核心主题吗？

• 主题 ≠ 题材（恐怖是主题，太空是题材）
• 所有元素（机制/视觉/叙事/音频）必须服务同一主题
• 协同效应(1+1>2)：机制组合、合成系统、涌现玩法

---

三、专项知识索引

需要深入某个专项时，加载对应 reference：

专项	Reference 文件	何时用
用户中心设计	references/user-centered-design.md	定义目标用户
核心循环设计	references/game-design-methodology.md	设计/评估核心循环
心流框架	references/flow-state-design-framework.md	难度曲线调优
动态难度	references/dynamic-difficulty-adjustment.md	实现自适应难度
奖惩系统	references/reinforcement-feedback-systems.md	设计奖惩机制
角色属性	references/character-optimization-design.md	属性/数值系统
谜题设计	references/game-competency-puzzle-design.md	关卡/谜题设计
快速平衡	references/doubling-halving-balance.md	原型期调参
环境叙事	references/environmental-storytelling.md	世界观叙事
节奏控制	references/experience-pacing-structure.md	游戏节奏设计
主题协同	references/synergy-thematic-design.md	主题一致性
视觉引导	references/visual-player-guidance.md	引导玩家注意力
Fitts 定律	references/fitts-law-ui-aiming.md	UI/瞄准优化
Hick 定律	references/hicks-law-decision-optimization.md	选择界面优化
黄金比例	references/golden-ratio-design.md	美学比例
玩家心理	references/player-psychology-decisions.md	认知偏差/决策
错误处理	references/player-error-handling.md	容错设计
归因偏差	references/fundamental-attribution-error.md	测试反馈分析
原型测试	references/game-prototyping-testing.md	测试方法论
团队管理	references/game-team-management.md	团队协作
项目规划	references/game-development-planning.md	项目管理
原理索引	references/game-design-principles-reference.md	按编号查原理

---

四、输出规范

• 建议时引用具体原理名称
• 给出可执行的下一步，不空谈
• 用表格对比方案利弊
• 诊断问题时先定位是哪个维度的问题（心理/机制/体验/视觉/管理）
• 复杂问题拆解为检查清单

synergy-thematic-design--theme-examples.md

Successful Theme Examples

Dark Souls

Theme: Despair and perseverance through impossible odds

• Mechanics: High difficulty, death as learning
• Visuals: Decay, ruin, oppressive environments
• Narrative: Fragmented, depressing lore
• Result: Cohesive, challenging experience

Journey

Theme: Transcendence and connection

• Mechanics: Simple movement, anonymous multiplayer
• Visuals: Beautiful, vast, flowing
• Music: Emotional, swelling, responsive
• Result: Powerful emotional journey

Papers, Please

Theme: Bureaucracy dehumanizes

• Mechanics: Repetitive inspection, time pressure, moral choices
• Visuals: Stark, paper-like aesthetic, depressing colors
• Result: Player feels the crushing weight of the system

Portal

Theme: Science gone wrong, dark humor

• Mechanics: Puzzle solving, physics manipulation
• Narrative: GLaDOS's passive-aggressive commentary
• Result: Unique, memorable identity

synergy-thematic-design.md

name	description
synergy-thematic-design	Use when defining game narrative tone, combining game mechanics, or ensuring design cohesion across all game elements. Applies when creative direction, narrative design, or mechanics integration needs to support a unified theme or create emergent gameplay depth.

Synergy and Thematic Design

Create cohesive game experiences where mechanics and narrative reinforce a central message, and element combinations create depth beyond individual parts.

When to Apply

• Defining the central theme or message of the game
• Combining multiple game mechanics or systems
• Ensuring narrative and gameplay alignment
• Reviewing overall game cohesion
• Designing crafting or combo systems
• Making creative direction decisions

Synergy (1+1 > 2)

Synergy occurs when combined elements produce a stronger effect than the sum of individual parts.

Implementation Approaches

Mechanic Combos:

• Allow players to combine moves for powerful results
• Example: Light+Light+Heavy attack combo creates special move
• Creates depth beyond individual button presses

Crafting Systems:

• Combine items to create new, valuable items
• Examples:
  • Resident Evil: Herb combinations
  • Minecraft: Resource crafting
  • Zelda: Cooking recipes
• Players discover combinations through experimentation

Emergent Play:

• Players use tools in unintended ways
• Example: Tony Hawk 'King of the Hill' using physics in creative ways
• Requires flexible, combinable systems
• Encourages player creativity

Design Principles

• Start with simple, independent mechanics
• Ensure combinations feel natural, not forced
• Prioritize obvious combinations for accessibility
• Allow space for emergent discoveries
• Test for edge cases and exploits

Theme

Theme is the central idea or message the game conveys—distinct from genre.

Core Principles

Universal Application:

• Every design decision must support the theme
• Art, music, mechanics, narrative—all aligned

Clarity:

• Theme should be identifiable by players
• "War is Horrible" vs "War is Glorious" should be clear

Consistency:

• Do not mix conflicting themes
• Example: Glory music over Horror visuals creates dissonance

Flexibility:

• A theme can fit multiple settings
• Example: "Love conquers all" works in 1850s or Modern War

Thematic Alignment Examples

Horror Theme (War is Horrible):

• Emphasize civilian casualties
• Show trauma and psychological impact
• Dark, unsettling visuals
• Uncomfortable moral choices
• Mechanics that create tension and helplessness

Glory Theme (War is Glorious):

• Emphasize heroism and patriotism
• Triumphant, inspiring music
• Noble sacrifices and victories
• Mechanics that empower the player

Variables

• theme: Central message or feeling the game conveys
• synergy_factor: The bonus effect from combining elements
• mechanic_type: Categories of systems to combine (combat, movement, resource)

Constraints

• Incoherent theme breaks immersion
• Conflicting messages confuse players
• Overly complex combinations reduce accessibility

Design Workflow

1. Define the core theme before detailed design begins
2. Identify key mechanics that support the theme
3. Design combination systems for synergy
4. Review all elements (art, audio, mechanics, story) for thematic alignment
5. Test player perception—do they understand the intended theme?
6. Iterate to strengthen weak connections

Result Template

A game where mechanics and narrative reinforce a central message, and combinations create depth beyond individual parts.

user-centered-design.md

name	description
user-centered-design	Apply ISO 9241-210 User-Centered Design principles when designing interfaces, systems, or games. Use when you need to ensure your design is optimized for specific target users' needs, goals, tasks, and environment constraints.

User-Centered Design (UCD)

Apply the ISO 9241-210 UCD framework to create designs optimized for your specific users.

When to Use

• Designing new interfaces or systems
• Redesigning existing products based on user needs
• Creating game interfaces or interaction systems
• Establishing a user-focused design process

Core ISO 6 Elements

1. User involvement throughout - Engage users at every stage of the design process
2. User-centered evaluation - Let user testing drive iterative design decisions
3. Whole user experience - Address the complete experience, not just isolated features
4. Multidisciplinary perspectives - Combine insights from various domains

Key Questions to Answer

• Who is the user? Define age, gender, experience level, background
• What are their goals and tasks? Understand what they want to accomplish
• What is their environment? Consider context (mobile vs PC, noisy vs quiet, public vs private)
• What are their limitations? Account for learning curve, physical constraints, accessibility needs

Process Workflow

1. Create User Personas

   • Develop fictional identities representing real-world user types
   • Include demographics, behaviors, motivations, and goals

2. Develop Scenarios

   • Describe the context and environment where users interact with the system
   • Establish the situation, conditions, and circumstances of use

3. Define Use Cases

   • Break down possible user actions and expected results
   • Map interaction flows step by step

4. Validate with Real Users

   • Test predictions about behavior and learning curves
   • Iterate design based on actual user feedback

Constraints

• UCD can be time-consuming and expensive
• Requires access to target users for research and testing
• Needs clear definition of target audience upfront

visual-player-guidance--affordance-examples.md

Affordance Cue Examples

UI/HUD Examples

• Button: Inset shadow, rounded corners → implies pushable
• Slider: Horizontal track with handle → implies dragging
• Toggle: Switch appearance → implies flip/rotate

Environment Examples

• Chest with handles: Implies opening
• Lever: Implies pulling/pushing
• Pressure plate: Implies standing on it

Puzzle Progression Example

1. Show basic quadrilateral chest (low affordance)
2. Add color highlight (medium affordance)
3. Add shadow/depth (higher affordance)
4. Add visible handles (maximum affordance → clear interaction)

Touch Interface Example

My Horse Game: Circular indicator requiring finger tracing—maximizes affordance by showing exact gesture path.

visual-player-guidance.md

name	description
visual-player-guidance	Use when designing visual elements that need to guide player interaction, focus attention, or facilitate navigation in UI/HUD, game environments, or puzzles. Applies when players need to intuitively understand how to interact with objects or where to go without explicit instructions.

Visual Player Guidance

Design visual elements that intuitively convey interaction possibilities and guide player attention without requiring tutorials or explicit instructions.

When to Apply

• Designing interactive UI/HUD elements
• Creating game environments requiring player navigation
• Designing puzzles with physical or virtual objects
• Implementing touch/tablet gesture systems
• Building levels that need wayfinding support

Core Principles

Affordance Cues

Affordance cues are visual or physical characteristics that intuitively convey how to interact with an object.

Key Rule: Cues must match the designer's intended action. A button meant to be pushed must look pushable, not pullable.

Application Areas

UI/HUD Design:

• Use bevels, shadows, and shapes (e.g., circles) to imply clickability
• Design elements that appeal to senses (tasty, tactile) to increase interaction urge
• Ensure form follows function—dials should cue circular gestures

Touch/Tablet Interfaces:

• Map natural actions (swiping, tapping) to visual cues
• Use visual indicators that guide finger movement (e.g., circular tracing paths)

Environments and Puzzles:

• Use clear paths (roads, carpets) to guide player movement
• Design objects with handles or features implying correct behavior
• Start with basic shapes, then add cues (color, shadow) to clarify interaction

Attention Capture

Use innate psychological triggers to focus player attention on specific elements.

For Marketing/UI:

• Faces: Humans instinctively recognize and focus on faces
• Motion: Flashing, bouncing, or animated elements draw the eye
• Surprise: Break patterns in familiar interfaces to create interest
• Appealing Imagery: Food, attractive characters trigger basic desires

For Wayfinding (Level Design):

• Landmarks: Unique objects at decision nodes for orientation
• Weenies: Large, distant landmarks that attract players
• Birth Canals: Funnel-shaped spaces leading to open areas (tension/release)
• Structured Paths: Visual lines (roads, cleared forest) guiding movement
• Light: Players instinctively move toward light; warm = comforting, cold = daunting

Execution Workflow

1. Identify the intended player action for each interactive element
2. Select appropriate visual cues that match the intended action (push, pull, rotate, etc.)
3. Test intuitiveness: Can players understand interaction without instructions?
4. Apply attention capture techniques to highlight important elements
5. Implement wayfinding cues for navigation in environments
6. Verify consistency: Ensure cues match throughout the game

Variables

• visual_cue: Shape, shadow, bevel, or color indicating usage
• intended_action: The specific behavior the designer wants the user to perform
• cue_type: Category (Face, Motion, Landmark, Light, etc.)
• goal: Attention capture or Navigation

Benefits

• Reduces time spent on tutorials/instructions
• Directs players to correct behaviors intuitively
• Prevents gameplay from becoming a "logical disaster"
• Guides player focus without explicit instructions

专项知识索引下的那些 md 文件是不是没有上传呀？