SuperAPI AI Directory

game-world-design

Design & creation

View repository

Updated 10-16 09:30

About this skill

Gameplay Experience and World Design

Turn the selected concept into an achievable player experience; do not write setting encyclopedias, engineering plans, or art direction.

The input must include SOURCE_BIBLE.md, the selected CONCEPT.md and PRODUCT_BRIEF.md. Read world-design-method.md; only read when there are indeed resources, gates, 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,experienceProfile and non-negotiables; when a scope conflict is found, revise upstream.
  • The slice duration and system scope obey the brief, based on exposing the greatest design risk, and do not presuppose duration or the 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 stage.

Output Contract

Generate a design/GAME_DESIGN.md, keep it compact and include:

  1. Experience and Loop Contract: player identity, promise, target feelings,experienceProfile, core actions and loop, and main gameplay precedents, as well as how the original changes the action object, order, cost, and world response;
  2. World Rules and Progression: player-visible/hidden information, action order, randomness, resources or persistent states and their read points; the situations, abilities, or understanding changes suited to this project, and observable end markers, without forcing growth stages;
  3. 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;
  4. Feedback, Failure, and Restart: input feedback, state changes, failure causes, what can be changed next time, and the defined initial state;
  5. Narrative Appendix: only write the scene spine, character agendas, knowledge/testimony boundaries, persistent echoes, branch convergence, and ending payoff when narrative actually carries the experience; otherwise write N/A;
  6. Language, Culture, and Handoff Boundaries: interface language, terminology, reading order, content rating, and the player effects handed off to art and build;
  7. Executable Slice Contract: the greatest design risk, the matching prototype form, the minimal state, action prerequisites/effects, and the initial state, input path, expected state and feedback; fix the seed when randomness is involved, and add observers and events only when there is information asymmetry or event playback; if the concept selected signature_command, complete the structure according to the method "identity-exclusive commands and deferred echoes";
  8. Validation Slice: scope, explicit non-goals, the complete path, and observations that would trigger design changes.

Rules should preferably be expressed in short tables, not copied into parallel JSON, go/no-go tables, or a second acceptance matrix.

Completion Check

Walk backward through the executable loop, world echoes, design progression, replay, and scope according to world-design-method; when narrative or identity-exclusive commands exist, then check knowledge, branches, character actions, resolution candidates, and actual execution according to the corresponding method without crossing wires. 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.