Human-Led Gameplay Design

STAGE treats gameplay design as mixed-initiative work with explicit human direction. An agent can research, model, critique, prototype, instrument, and compare. It must not silently choose what the game should feel like and defer the first meaningful design conversation until after implementation.

This guidance applies when work originates a game or materially redefines its core loop, control model, progression, challenge structure, repeated decisions, or intended player experience. It does not add ceremony to bounded fixes, refactors, faithful implementation of an accepted design, or tuning whose intent is already settled.

The Design Sequence

1. Recover Intent

Inspect the project's existing design sources and recent human decisions. Separate:

• accepted intent that must be preserved;
• current behavior that may only be an implementation accident;
• assumptions made by previous agents or prototypes; and
• genuine decisions that remain open.

Do not treat working code, a populated backlog, or permission to keep working as evidence that the gameplay premise was approved.

2. Discuss The Highest-Leverage Unknown

Discuss one coherent decision cluster at a time. Useful questions concern:

• target player and context: who is playing, for how long, with what prior knowledge, input, attention, and social setting;
• fantasy and feeling: who the player imagines themselves to be and what emotional qualities the experience should emphasize;
• verbs and decisions: what the player repeatedly does, notices, chooses, risks, and learns;
• challenge and mastery: what changes from confusion to competence and what makes improved play possible;
• pacing and feedback: how pressure, release, consequence, progress, and recovery are communicated;
• first minute: what must become legible without developer explanation;
• short loop: the smallest repeatable sequence worth judging; and
• stop conditions: observations that should reject, simplify, or redirect the premise before it spreads.

This should be a design conversation, not a questionnaire dump. Ask the next question because its answer changes the implementation or evidence plan.

3. Compare Alternatives Honestly

When the answer is not already implied by the project's direction, offer two or three materially different alternatives. For each, state:

• the expected player consequence;
• the relevant game-design or player-research lens;
• implementation and content cost;
• likely failure modes and tradeoffs;
• assumptions being made; and
• what remains unknowable until a human plays it.

Frameworks help name relationships. They do not select the game's identity or compute fun. MDA can connect desired aesthetics to dynamics and mechanics; GameFlow can prompt questions about challenge, skill, control, goals, feedback, concentration, immersion, and social interaction; self-determination theory can prompt questions about autonomy, competence, and relatedness. None is a recipe or universal score.

4. Obtain A Human-Approved Gameplay Hypothesis

Before substantial implementation, the accountable human designer approves a small hypothesis covering:

• player fantasy and target context;
• core verbs and repeated decisions;
• intended experience;
• first-minute understanding;
• the short loop;
• recognizable success, failure, and recovery; and
• explicit stop conditions.

Keep this in the working conversation unless a recurring coordination need earns a durable brief. The optional Gameplay Design Brief is available when persistence helps.

If the human explicitly delegates invention, the agent may draft the hypothesis, label its assumptions, and recommend a direction. Approval is still required before multiplying that premise through broad systems, modes, content, or polish. Delegating implementation is not the same as delegating product intent.

5. Build And Play The Smallest Complete Loop

Use the approved hypothesis to build the thin complete loop described by the Player Experience Gate. Automate mechanical checks so the human spends attention on experience rather than avoidable defects. Then have the human play the real player surface and accept, block, or revise the premise before expansion.

For systems-heavy work, continue with Systems-Heavy Gameplay Evidence. It turns the approved premise into a player-system trace, decision-quality questions, and claim-matched checks for UI, feedback, onboarding, pacing, progression, balance, accessibility, and ethical engagement. It is a diagnostic workflow, not a formula or score for fun.

What Agents Can And Cannot Establish

The boundary is based on the claim, not on whether an agent can produce a number.

Keep five evidence classes distinct: direct mechanical, advisory proxy, human designer judgment, direct human play, and representative player research. Telemetry says what happened; it does not establish how the event felt or why the player acted.

Claim class	Agent or automation contribution	Required human evidence
Rules and state	Directly test transitions, invariants, completion, failure, reset, reachability, and softlocks	Balance or meaning may still require play
Curves and distributions	Compute progression curves, expected values, spawn/map distributions, and sensitivity under declared assumptions	Decide whether the resulting experience is desirable
Strategy space	Search encoded policies for exploits, dominant strategies, bottlenecks, and unreachable states	Judge whether actual players perceive, learn, or enjoy those strategies
Presentation mechanics	Check prompts, focus, mappings, overflow, contrast thresholds, frame time, and latency	Judge discoverability, readability in motion, comfort, and accessibility
Telemetry	Summarize actions, failures, time, retention within a session, and observed paths	Observation and self-report are needed to interpret how and why it felt that way
Theory-based critique	Identify likely clarity, pacing, fairness, balance, novelty, repetition, or accessibility risks	Treat these as hypotheses until direct play supports them
Product intent	Offer vocabulary, examples, alternatives, and tradeoffs	Human designer chooses audience, fantasy, desired feeling, priorities, identity, and acceptable compromises
Lived experience	Prepare a stable build and questions	Human play is required for comprehension, control feel, perceived fairness, boredom, frustration, engagement, emotional tone, delight, motion comfort, and desire to continue
Audience claim	Help recruit, structure, and analyze a study	Representative target players are required; owner acceptance alone cannot establish novice, audience, market, or general-usability claims

A synthetic player establishes behavior for the utility function, policy, observations, and action space it encodes. It can explore the game efficiently and still miss human misunderstanding, embodied control feel, emotional response, cultural meaning, novelty, fatigue, and unexpected play. Treat simulation as mechanical evidence and hypothesis generation.

Fun is not an agent-computable acceptance metric. Neither a theory checklist, telemetry dashboard, code-quality score, nor successful automated playthrough can replace direct human judgment.

Human Roles And Claim Scope

For a personal game, the owner can validly decide, “this is the game I want to make” or “I enjoy this enough to continue.” That is sufficient to direct the project. It is not proof that first-time players understand it or that a target audience will enjoy it.

Keep these roles distinct:

• Human designer/owner: chooses intent and accepts personal product direction.
• Human playtester: reports and demonstrates an experienced interaction with a specific build and context.
• Representative target player: supports claims about a named population.
• Agent/research assistant: prepares alternatives, mechanics evidence, instruments, observations, and bounded analysis without widening the claim.

One person may hold several roles, but the evidence does not become broader because the roles share a person.

Research Basis And Limits

This guidance synthesizes established lenses rather than claiming a new science of fun:

• Hunicke, LeBlanc, and Zubek's MDA framework connects mechanics, runtime dynamics, and desired player aesthetics, and encourages experience-driven rather than feature-driven design.
• Sweetser and Wyeth's GameFlow model integrates enjoyment heuristics around concentration, challenge, skill, control, goals, feedback, immersion, and social interaction. It is a useful review lens, not an objective acceptance score.
• Ryan, Rigby, and Przybylski's self-determination theory studies of games connect autonomy, competence, and relatedness with human-reported enjoyment and future play.
• Abeele et al.'s Player Experience Inventory is a validated human-report instrument covering functional and psychosocial consequences of play. Its constructs require player responses.
• Medlock et al.'s RITE method supports rapid iteration from observed human usability problems and empirical rechecking of fixes.
• Holmgard et al.'s procedural-persona playtesting shows how synthetic agents can explore encoded archetypal strategies. Its value and limitations both follow from the utility functions supplied.
• Microsoft's Applied User Research in Games describes games user research as adapting social-science methods to improve usability and enjoyability.

These sources support structured reasoning, iteration, and evidence triangulation. They do not prove STAGE's exact dialogue sequence, nor do they make an agent a representative player. The strongest local evidence for this correction remains the owner rejection of two technically healthy dogfoods and the more productive human-agent correction loop in The Circussy One.