Turn the selected concept into a realizable player experience; do not write a worldbuilding encyclopedia, engineering plan, or art direction.
The input must include SOURCE_BIBLE.md, the selected CONCEPT.md and PRODUCT_BRIEF.md. Read
world-design-method.md; read numeric-design-method.md only when there are indeed resources, thresholds, or difficulty.
numeric-design-method.md。
Read when narrative actually carries the experience narrative-design-method.md, and do not force long dialogue for every project.
The output language is locked by PRODUCT_BRIEF.md ; when not locked, follow the conversation language and do not default to producing Chinese.
Design principles
- Protect CONCEPT's player promise,
experienceProfileand non-negotiables; when a scope conflict is found, go back upstream to revise. - Slice duration and system scope obey the brief, with exposing the greatest design risk as the criterion, and do not presuppose duration or number of systems.
- Do not write file names, functions, storage keys, test scripts, shaders, or asset pipelines; the implementation structure is decided by the build phase.
Output contract
Generate one design/GAME_DESIGN.md, keep it compact, and include:
- Experience and loop contract: player identity, promise, target feeling,
experienceProfile, core actions and loop, and main gameplay precedents, as well as how the original work changes the objects, order, costs, and world responses of actions; - World rules and progression: player-visible/hidden information, action order, randomness, resources or persistent state and their read points; situations, ability, or understanding changes suited to this project, and observable end markers, without forcing growth stages;
- Decisions and level beats: how key situations require players to act or make trade-offs, and what kind of causal power and resolution power players have;
- Feedback, failure, and restart: input feedback, state changes, failure causes, what can be changed next time, and defining the initial state;
- Narrative attachment: write the scene spine, character agendas, knowledge/testimony boundaries, persistent echoes, branch convergence, and ending payoff only when narrative actually carries the experience; otherwise write N/A;
- Language, culture, and handoff boundaries: interface language, terminology, reading order, content scale, and the player effects handed off to art and build;
- Executable slice contract: greatest design risk, matching prototype form, minimum state, action preconditions/effects, and initial state, input path,
expected state, and feedback; fix the seed when randomness is relevant, and add observers and events only when information asymmetry or event playback is relevant; if the concept chooses
signature_command, complete the structure according to the method "identity-exclusive commands and deferred echoes"; - Validation slice: scope, explicit non-goals, complete path, and observations that would trigger design changes.
Rules should preferably be expressed in short tables; do not copy them into parallel JSON, go/no-go tables, or a second acceptance matrix.
Completion check
Following world-design-method, walk backward through the executable loop, world echoes, design progression, replay, and scope; when narrative or exclusive commands exist, then check according to the corresponding method that knowledge, branches, character actions, resolution candidates, and actual execution are not crossed. Deliver only the design contract, do not choose technology for implementation, and do not write fun or balance as a deterministic PASS.
Return the output to the main entry point; do not advance art, build, or QA on your own.