| name | game-design-framework |
| description | Methodology reference for rigorous mechanic and system design. Covers the 5-Component Relevance Filter, Numbers Policy for evidence-based balancing, State Machine Checklist for player actions, and playtest scenario templates. Use alongside the game-designer persona when evaluating whether a feature earns its place or when designing a balance pass from first principles. |
| license | MIT |
| compatibility | Portable reference skill for agents that support markdown skills or prompt files. Works best alongside design docs, tuning spreadsheets, and playtest notes. |
| disable-model-invocation | true |
| metadata | {"owner":"game-delivery","version":"2.0.0","language":"en-GB","category":"game-design","tags":["game-design","mechanics","balance","playtesting","state-machine","systems","methodology"],"intents":["mechanic-evaluation","balance-from-first-principles","action-specification","playtest-design"],"output_types":["relevance-filter-verdict","numbers-policy-table","state-machine-spec","playtest-scenario"]} |
Game Design Framework
Methodology reference for mechanic evaluation, balance, and state design. Use when you need a structured decision tool — not just intuition — to determine whether a mechanic earns its place, how to set numbers, or whether a player action has been fully specified.
1. The 5-Component Relevance Filter
Before adding or keeping any mechanic, system, or feature, run it through all five components. A mechanic that fails more than one should be cut or reshaped — not patched.
The guiding principle: Relevance over completeness. A game with 10 relevant mechanics is better than one with 20 loosely related ones.
Component 1 — Clarity
Does the player know what this mechanic is asking of them, and does the outcome match their expectation?
Questions to answer:
- Can a new player understand the mechanic's core contract without explanation?
- Is the feedback (visual, audio, haptic) legible at game speed?
- Are the failure states distinct from success states?
- If the player fails, do they know why?
Failure signal: Players repeatedly attempt the wrong action, or succeed without understanding how.
Component 2 — Motivation
Does the player want to engage with this mechanic, and does the desire persist?
Questions to answer:
- What is the fantasy this mechanic delivers? (power, mastery, expression, discovery)
- Does the mechanic remain motivating once the novelty fades?
- Is there a skill ceiling worth reaching?
- Does progression through the mechanic feel meaningful?
Failure signal: Players engage once then avoid the mechanic, or treat it as a chore.
Component 3 — Response
Does the mechanic react to the player in a way that feels satisfying and proportionate?
Questions to answer:
- Is the response timing correct? (input latency, animation commitment, hit pause)
- Is the response magnitude appropriate? (too subtle = unsatisfying, too extreme = disorienting)
- Is the response consistent across similar inputs?
- Does the response communicate the state change clearly?
Failure signal: The mechanic feels "floaty", "sticky", "unresponsive", or "spongy" — player-reported feel complaints almost always originate here.
Component 4 — Satisfaction
Does the mechanic produce a rewarding emotional beat at its climax?
Questions to answer:
- Is there a clear moment of resolution? (the hit lands, the puzzle solves, the combo completes)
- Are the juice elements (screen shake, sound, particle, slow-mo) proportionate to the action's weight?
- Does the satisfaction loop repeat cleanly, or does it degrade on repetition?
- Does the player feel capable at the mechanic's resolution?
Failure signal: The mechanic works but feels hollow. Players describe it as "fine" or skip the climax animation.
Component 5 — Fit
Does this mechanic belong in this game, with this audience, at this moment in the session?
Questions to answer:
- Does the mechanic reinforce the game's pillars and fantasy statement?
- Is the mechanic appropriate for the target skill curve at the point it is introduced?
- Does it interact safely with other mechanics already in the game?
- Would its removal make the game less coherent, or less cluttered?
Failure signal: The mechanic feels imported from a different game. It works in isolation but fights the tone, pace, or systems around it.
2. Numbers Policy
All tuning numbers must have a source. "It felt about right" is not a source — it is a starting point. The Numbers Policy defines a minimum standard of evidence before a value is considered stable.
The three tiers of number confidence
| Tier | Source | Status |
|---|
| Derived | Calculated from a model, formula, or target curve | Hypothesis — must be playtested |
| Observed | Set or confirmed by playtest data or telemetry | Provisional — review on scope change |
| Validated | Confirmed across multiple playtests or cohorts | Stable — flag before changing |
Numbers should move up the tiers, never down without cause.
Naming numbers before setting them
Before assigning a value, name what the number controls:
Number: Player dash cooldown
Affects: Defensive availability, rhythm of combat, skill expression ceiling
Target feel: Dash feels like a meaningful resource — not spammable, not punishing
Starting value: 0.8 s (derived: two attacks at standard cadence = one dash window)
Test signal: Players use dash defensively at least 30% of the time in combat encounters
Tier: Derived → Observed (after first playtest)
Every balance table entry should have this shape before it goes into the build.
The three numbers to always set explicitly
Regardless of mechanic type, always specify:
- Floor — the minimum value that keeps the mechanic functional (below this, it breaks or becomes trivial)
- Target — the value that delivers the intended feel at the expected skill level
- Ceiling — the maximum value a skilled player could push the mechanic to (above this, the mechanic becomes degenerate)
Example — enemy health (normal difficulty):
Floor: 40 HP (below this, enemies die before the player can read their attack)
Target: 120 HP (2–3 full combos for a competent player)
Ceiling: 200 HP (max before combat becomes attrition)
Balance red flags
Immediately revisit numbers when:
- Players are consistently choosing one option exclusively (strategy dominance)
- Players are never choosing a specific option (strategy irrelevance)
- Session length exceeds target by >20%
- Players report the game as "too easy" and completion rates are below 60% (indicates a specific difficulty spike, not global calibration)
- A single number change required to fix a feel problem is >50% of its current value (indicates a design problem, not a tuning problem)
3. State Machine Checklist
Every player action that modifies world state or player state must be fully specified as a state machine before it goes into production. This checklist ensures nothing is left implicit.
Required states for any player action
Run through this list for every action (move, attack, interact, ability, etc.):
[ ] Idle — what state does the player enter before this action is possible?
[ ] Startup — how many frames/ms before the action takes effect?
[ ] Active — what is the window in which the action has effect?
[ ] Recovery — how long after the active window before the player regains control?
[ ] Cancel windows — can the action be cancelled? Into what? From what?
[ ] Interrupt conditions — what external events cut the action short?
[ ] Success state — what changes in the world and player state on hit/completion?
[ ] Failure state — what happens if the action misses or is interrupted?
[ ] Repeat rule — can the action chain into itself? Under what conditions?
[ ] Animation commitment — is the full animation required, or can it blend out?
[ ] Resource cost — does it consume stamina, cooldown, ammo, mana?
[ ] Resource recovery — does cancelling the action refund the cost?
Movement sub-checklist
For all locomotion (walk, run, dash, jump, climb, swim):
[ ] Ground → Air transition (takeoff)
[ ] Air → Ground transition (landing — is there a landing lag?)
[ ] Directional change responsiveness (turn radius or snap-to?)
[ ] Ceiling collision
[ ] Slope behaviour (slide, grip, max angle)
[ ] Edge handling (coyote time? snap to ledge?)
[ ] Speed cap (per state)
[ ] Stack behaviour (can multiple movement actions queue?)
Combat sub-checklist
For all attacks:
[ ] Hitbox active frames (start, end)
[ ] Hurtbox modification during attack (invincibility frames?)
[ ] Hit pause duration (attacker and target)
[ ] Knockback direction and magnitude
[ ] Hitstun duration
[ ] Combo window (time after hit where next input is buffered)
[ ] Counter-hit state (does it change the above?)
[ ] Block/parry interaction
[ ] Multi-hit behaviour (does each hit re-trigger stun?)
4. Playtest Scenario Templates
Use these templates to generate structured playtest scenarios that produce actionable data rather than general impressions.
Template A — Mechanic viability
Use when testing whether a new mechanic works at all.
Scenario name: [Mechanic] First Contact
Question: Can a player with no prior context understand and use [mechanic] within [time]?
Setup: Present the mechanic with no tutorial. Record first 5 minutes.
Success signal: Player attempts correct action within [X] seconds of first encountering trigger
Player can describe the mechanic contract after the session
Failure signal: Player ignores mechanic, uses incorrect approach, or expresses frustration >2×
Data to collect: Time to first correct use / Number of failed attempts / Player verbal description
Session length: [20–30 min]
Next decision: If success → move to balance testing. If failure → redesign teach plan or mechanic contract.
Template B — Balance confidence
Use when testing whether numbers deliver the target feel.
Scenario name: [Feature] Balance Pass [N]
Question: Do the current numbers deliver [target feel] at [skill tier]?
Target feel: [State specifically — e.g. "combat feels tense but learnable; player rarely one-shot"]
Participant: [Skill tier: novice / intermediate / advanced]
Setup: Session A uses current values. Session B uses proposed values (if A/B).
Success signal: Players at target skill tier describe feel as [target adjective]
Completion rate for [challenge encounter] is within [X%–Y%] range
Failure signal: Players consistently use one dominant strategy
Players report [specific complaint] unprompted >30% of the time
Data to collect: Completion rate / Deaths per encounter / Strategy chosen / Unprompted feel comments
Session length: [45–60 min for combat-heavy sessions]
Next decision: Accept / adjust ceiling-floor range / flag as design problem
Template C — Fit validation
Use when testing whether a mechanic belongs in the game at its current position.
Scenario name: [Mechanic] Fit Check — [Context]
Question: Does [mechanic] feel like it belongs in this game at [session moment]?
Setup: Play [session segment] with mechanic present. Remove it in a second pass.
Success signal: Players notice its absence unprompted in the removed version
Players describe the mechanic using the game's own language / tone
Failure signal: Players do not notice removal
Players describe the mechanic as "different" from the rest of the game
Data to collect: Mechanic engagement rate / Unprompted mentions / Tone mismatch comments
Session length: Matches target segment length
Next decision: Keep / reframe / remove
Quick-reference checklist
Before finalising any mechanic for production:
