Game Design

What makes this experience worth having, and how does the design deliver it?

Establish the promise

Use the player's intended experience, audience, play context and production constraints to guide decisions. Ask only when an unresolved intention would change the direction. Otherwise make a concrete recommendation with explicit assumptions and continue the authorised work.

Fun can mean mastery, discovery, tension, humour, expression or comfort. A finite story can succeed without replay. Quietness and uncertainty can serve the experience. Do not replace the stated intention with retention, constant challenge, quick rewards or a larger possibility space.

For a new concept, describe a specific moment or sequence worth experiencing before listing features. Invent from rules, fiction, physical activities and references. A creative bet does not require a prior complaint or metric. Scope discipline serves that bet: keep the complexity, content and presentation needed to demonstrate its appeal.

Use the relevant design method

Read the matching reference before the substantive design work. Use only the routes the task needs; this is not a checklist to run on every request.

Make the design executable

Explain what the player can do, what they know, what changes and why that could produce the intended experience. An evocative title or list of systems does not specify play.

Treat supplied rules and constraints as the starting contract. Separate them from assumptions and proposed additions. Do not quietly rewrite a supplied rule or relabel it as provisional to make a set piece work.

Check the pivotal sequence with a short before / action / after trace. Account for costs, automatic effects, elapsed time and the terminal condition. Then try to break the promise: what does the same rule imply one action earlier, at expiry, or if the player does nothing? Repair the rule or the sequence before presenting it. Include the decisive trace in the recommendation; narrative prose alone can conceal an impossible move.

Mark invented tuning values as provisional. When the first slice omits part of the promise, name the narrower question it answers and what the integrated slice still needs. A claim to preserve balance needs more than an unchanged damage number or timer; geometry and opportunities to apply damage also matter.

For creation, recommend a direction and the next buildable situation. For critique, identify the strongest part worth preserving and the most consequential weakness. For an implementation request, make the design decision and deliver the requested change. Do not substitute a research programme for authorised work or reproduce this protocol as paperwork.

Separate judgement from evidence

Describe predicted reactions as intentions or hypotheses. A book, admired game or successful simulation does not establish what this game's players experience. Feedback establishes the report; investigate its cause. Put uncertainty beside the causal claim, not in a disclaimer after a confident diagnosis. A design proposal can stand on its own merits without inventing a defect to justify it. Choose observations that could change the next decision, without inventing universal timing or pass-rate thresholds.

Inspect available gameplay, state and source when diagnosing an existing game. When studying another game, identify the relevant version, mode and context; verify the mechanics your argument depends on through available primary sources or observation. Do not claim to have played or measured it when using an interview or footage. Keep useful examples self-contained; named references are optional.

Boundaries

This skill owns experience and rule-design decisions. Existing architecture, testing, accessibility, art-production and performance skills own their technical implementation. An agreed technical fix does not need a new game-design review.

Keep any created playable prototype available with controls, launch instructions, its design question and known limits. Do not delete a playable build as eval cleanup unless the user explicitly requests it.

evals/evals.json and evals/README.md support maintaining this skill; they are not instructions to run evaluations during an ordinary game task.