game-world-design

Original：🇨🇳 Chinese

Translated

Design game experiences, systems, and levels. Consolidate the selected concept into a single GAME_DESIGN document that defines the player promise, core loop, world responses, essential systems, level pacing, feedback, failure states, and a fully playable prototype. This applies to designing game worlds, deepening gameplay and level design, creating game design documents, and designing branching story structures, scenes, dialogue, and narrative consequences.

14installs

Sourcezenstory-ai/novel-to-game

Added on2026-08-29

NPX Install

npx skill4agent add zenstory-ai/novel-to-game game-world-design

SKILL.md Content (Chinese)

View Translation Comparison →

Game Experience and World Design

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

Inputs must include

SOURCE_BIBLE.md

, the selected

CONCEPT.md

and

PRODUCT_BRIEF.md

. Read world-design-method.md; only read numeric-design-method.md when resources, thresholds or difficulties are involved.

For

narrative-led

or

hybrid

narrative layers, also read narrative-design-method.md and dialogue-design-method.md. When player-visible copy is needed, unify the tone according to game-writing-craft.md; do not force long dialogue for all projects.

The language of the deliverable is locked by

PRODUCT_BRIEF.md

; if not locked, follow the dialogue language, and do not default to Chinese output.

Design Principles

Protect the player promise,
```
experienceProfile
```
, and non-negotiable elements of the CONCEPT; revise upstream if scope conflicts are found.
Retain only one core system and at most two supporting systems; do not promote content that does not affect the core loop to a system.
Write rules in the structure of player action → state change → world feedback → subsequent choices; do not replace playable causality with background settings.
Organize the minimal slice using "Teach → Variant → Combine → Test → Fate Callback"; default to 10–30 minutes and do not exceed the brief's duration.
Design NPCs, factions, resources and history only to the depth that players can perceive, utilize or change.
Do not write file names, functions, storage keys, test scripts, shaders or asset pipelines; implementation structure is determined by the build phase.

Output Contract

Generate a

design/GAME_DESIGN.md

, keep it concise and include:

Experience Contract: Player identity, promise, target feelings,
```
experienceProfile
```
and first-minute goals;
Core Verbs & Loops: 3–5 verbs, short loops, long loops, major gameplay precedents, and how the original work changes action objects, order, costs and world responses;
World Rules & Essential Systems: Visible/hidden player information, action order, randomness, resources or persistent states and their reading points;
Growth & Three-Stage Arc: New engagement methods, accessible spaces or scenarios added in the exploration, growth and maturity stages, as well as observable end markers;
Representative Decisions: Use one scenario to prove that the optimal choice will flip with the situation, and clarify causality rights and settlement rights;
Space, Camera & Level Beats: How routes, landmarks, pressure, teaching, combination and testing create choices;
Feedback, Failure & Restart: Input feedback, state changes, failure reasons, areas for improvement next time and initial state definition;
Narrative Attachment: Only write scene spine, character agendas, knowledge/testimony boundaries, persistent echoes, branch convergence and ending callbacks when narrative actually carries the experience; otherwise write N/A;
Language, Culture & Handover Boundaries: Interface language, terminology, reading order, content scale, and player effects to be handed over to art and build teams;
Executable Slice Contract: Maximum design risks, prototype forms matching the risks, minimal state surface, preconditions/effects/observers of key actions, events that will be read later, as well as fixed initial state, seed, input sequence, expected state and feedback; if
```
signature_command
```
is selected in the concept, fix the six minimal structures of
```
id / label / intents / slots / validators / commit
```
, then add clarification and rejection conditions, delegation execution chain, actual results, evidence/awareness changes and expiration echoes;
Validation Slice: Scope, clear non-goals, complete path and observation results that will trigger design modifications.

Only create numerical budgets when thresholds, endings or tension truly require numerical reading; the same applies to narrative states—delete them if there is no visible reading point after writing. Prioritize expressing rules with short tables; do not duplicate them into parallel JSON, go/no-go tables or a second acceptance matrix.

Completion Check

Players can reach at least one result from the initial state through real choices and restart;
The three-stage arc changes available actions, space or scenarios, not just increases in numbers, text or collection volume;
All core states are read in subsequent steps, and major choices are clearly echoed by the world at least once;
The same initial state, rule version, seed and standardized action input sequence can be replayed to the same final state; unseen characters cannot read secrets, and unselected branches cannot contaminate history;
If exclusive commands exist, player expressions, parsing candidates, actual execution and feedback are distinguishable from each other; invalid or ambiguous inputs must not secretly submit approximate actions;
Supporting systems, branches and character content do not silently expand beyond the brief's scope;
The document does not do technical design for implementation, nor does it write fun or balance as deterministic PASS.

Submit the output back to the main entry; do not independently advance art, build or QA work.