game-build

Game build execution

Protect the approved experience boundaries; protect the approved art boundaries only during formal production. Drive the implementation model to produce a genuinely playable candidate; do not redo concept, level, or art direction during the build phase.

Read build-brief-contract.md. The whitebox phase must already have GAME_DESIGN.md; a complete candidate must also already have ART_DIRECTION.md. When a product decision is missing, go back to the corresponding owner; do not invent it in place in BUILD_BRIEF.

The artifact language is locked by PRODUCT_BRIEF.md ; when not locked, follow the conversation language, and do not default to producing Chinese.

Goals and freedom

Deliver according to the platform, production engine, target runtime, display/input, scope, rating, and networking boundaries locked by PRODUCT_BRIEF. When the target toolchain is unavailable, do not automatically switch to building a web page; it may be used only if the brief has approved an alternative runtime, and record separately targetRuntime、testedRuntime and uncovered items.

Formal production inherits ART_DIRECTION.md 's observable visual constraints and approved target images, and verifies focal assets in actual runtime.

BUILD_BRIEF compresses only product boundaries, experience facts that must be preserved faithfully, run methods, and completion evidence; implementation details are left to the implementation model.

First declare buildStage: whitebox|production and buildPath: template|custom. Existing interaction grammar is adopted only when it can preserve the original work's unique actions, costs, and world responses; core verbs that real-time feel, space, line of sight, physics, or templates cannot cover go custom. The whitebox must also choose a form that can verify the greatest risk, and must not reduce every project to a text game.

When the current session can encode, implement directly; when an external model is unavailable, deliver only build instructions and do not claim the game has been generated. Do not send complete copyrighted original text unrelated to the prototype.

Read optional contracts by capability

• When Blender has been chosen to create or modify editable 3D assets, read blender-asset-workflow.md; do not adopt Blender by default or install MCP just because the project is 3D.
• When adopting generative free input, knowledge permissions, event replay, save migration, or signature_command , read the relevant parts of playable-model-contract.md .
• When the voice strategy is not none , read tts-production-contract.md。
• When dynamic media is actually adopted, read generative-media-pipeline.md。

Co-build loop

1. First implement a minimal but complete core loop: startup, real input, state changes, results, and restart. When scope is insufficient, fix the scope; do not pile up audit materials first.
2. Implement GAME_DESIGN's states, actions, and results; when using a generative model, the model only interprets input and results, and the rules engine holds commit authority. When signature_command exists, then execute the optional contract's dedicated boundaries.
3. Preserve the initial state and input path that can reproduce the issue; when randomness is involved, fix the seed; after revision, replay the failure path and adjacent counterexamples.
4. Write back the actual toolchain, install/build/start commands, and versions; for unknown values write NOT_AVAILABLE: 原因, and do not guess. When the actual candidate does not match the factual descriptions in GAME_DESIGN and ART_DIRECTION, hand it back to the corresponding owner for revision or mark the conflict in BUILD_BRIEF; do not leave behind documents that describe gameplay, presentation, or sound that no longer exists.

whitebox From here, run the narrowest check according to build-brief-contract "completion evidence" and hand back to the design owner; after design revision, replay the affected paths until the greatest risk has actually been exposed or the current direction is rejected.

production Continue:

1. Provide one authoritative verification command and the minimal observable state, so that game-qa can complete one pass clean start → 核心动作 → 设计结果 → restart。
2. Run the narrowest development checks and startup smoke, fix build failures, blocking logs, resource failures, and crashes; for target platform inputs, performance, packaging, or device items not covered by the runtime, write them into limitation.
3. Reach the brief's targetFinish; higher completeness only handles approved focus assets and signature moments, and does not create release audits unrelated to the playable loop.
4. Hand off to game-qa; for diagnosis, reruns, and source-of-truth rules, see the contract "Completion Evidence".

Output

Generate build/BUILD_BRIEF.md and the actual candidates; production also generates the authoritative verification entry point. Screenshots, recordings, and raw traces retain only the minimal set needed for debugging.