game-build

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

游戏构建执行

Game Build Execution

保护已批准的体验边界；正式生产时再保护已批准的美术边界。驱动实现模型完成真实可玩的候选，不在构建阶段重新做概念、关卡或美术方向。

读取 build-brief-contract.md 与 playable-model-contract.md。白盒阶段必须已有

GAME_DESIGN.md

；完整候选还必须已有

ART_DIRECTION.md

。缺产品决定时回对应 owner，不在 BUILD_BRIEF 就地发明。

产物语言由

PRODUCT_BRIEF.md

锁定；未锁定时跟随对话语言，不默认产出中文。

Protect the approved experience boundaries; protect the approved art boundaries during formal production. Drive the implementation model to complete a truly playable candidate, and do not rework concepts, levels, or art directions during the build phase.

Read build-brief-contract.md and playable-model-contract.md.

GAME_DESIGN.md

must be available during the whitebox phase;

ART_DIRECTION.md

must also be available for a complete candidate. When product decisions are missing, refer back to the corresponding owner instead of inventing content locally in the BUILD_BRIEF.

The product language is locked by

PRODUCT_BRIEF.md

; if not locked, follow the conversation language, and do not default to outputting Chinese.

目标与自由

Objectives and Flexibility

按 PRODUCT_BRIEF 锁定的平台、生产引擎、目标运行时、显示/输入、范围、分级和联网边界交付。目标工具链不可用时不得自动改做网页；只有 brief 已批准替代运行时才可使用，并分开记录

targetRuntime

、

testedRuntime

与未覆盖项。

正式生产继承美术方向的明度边界。非低照度题材不得在实现阶段擅自用全局黑罩、暗角、降曝光或低对比小字制造“电影感”；夜景也要保留人物、器物、行动与结果可读性。确需偏暗的界面只按已批准范围实现，并保留方向中约定的亮度或高对比 fallback。

时代题材的高风险画风先接入一张实际目标图并在目标视口确认，再批量生产。目标图已批准后，后续资产必须继承同一时代世界、表现媒介、人物成熟度、身份锚点、光色和文本留白；不得把“当代审美”擅自实现成现代服装／棚拍，也不得把“古风”擅自实现成古画旧化。用户否决方向时停止扩批，替换运行引用并清理被否决资产，不能让旧图、试验图和批准图混在同一发布包。

BUILD_BRIEF 只压缩产品边界、必须保真的体验事实、运行方式与完成证据，实现细节交给实现模型。

先声明

buildStage: whitebox|production

与

buildPath: template|custom

。已有交互语法只有在能保留原作独有动作、代价和世界回应时才采用；实时手感、空间、视线、物理或模板覆盖不了的核心动词走 custom。白盒也必须选择能验证最大风险的形态，不能把所有项目降成文游。

当前会话能编码时直接实现；外部模型不可用时只交付构建说明，不声称游戏已生成。不要发送与原型无关的完整受版权保护原文。

Deliver according to the platform, production engine, target runtime, display/input, scope, rating, and networking boundaries locked in the PRODUCT_BRIEF. Do not automatically switch to web development when the target toolchain is unavailable; only use an alternative runtime if it has been approved in the brief, and record

targetRuntime

testedRuntime

, and uncovered items separately.

Formal production inherits the brightness boundaries of the art direction. For non-low-light themes, do not arbitrarily use global black masks, vignetting, reduced exposure, or low-contrast small text to create a "cinematic feel" during the implementation phase; night scenes must also retain the readability of characters, objects, actions, and results. If a dimmer interface is truly needed, implement it only within the approved scope, and retain the brightness or high-contrast fallback agreed in the direction.

For high-risk art styles of era-themed projects, first integrate an actual target image and confirm it in the target viewport before mass production. After the target image is approved, subsequent assets must inherit the same era world, expression medium, character maturity, identity anchor, light color, and text whitespace; do not arbitrarily implement "contemporary aesthetics" as modern clothing/studio photography, nor implement "ancient style" as aged ancient paintings. When the user rejects the direction, stop mass production, replace runtime references, and clean up rejected assets; do not mix old images, test images, and approved images in the same release package.

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

First declare

buildStage: whitebox|production

and

buildPath: template|custom

. Existing interaction syntax is only adopted if it can retain the unique actions, costs, and world responses of the original work; core verbs that cannot be covered by real-time feel, space, line of sight, physics, or templates follow the custom path. The whitebox must also choose a form that can verify the greatest risk, and cannot reduce all projects to text-based games.

Implement directly when the current session can be encoded; only deliver build instructions when external models are unavailable, and do not claim the game has been generated. Do not send complete copyrighted original texts unrelated to the prototype.

按能力读取可选合同

Read Optional Contracts by Capability

语音策略不是
```
none
```
时读取 tts-production-contract.md。TTS 优先构建期生成成本地资产；运行时远程合成须在 brief 批准，密钥只留受信服务端。
实际采用动态媒体时读取 generative-media-pipeline.md。已有批准参考图时以图约束；工具与模型按当前环境选择，不写成跨项目默认。

When the voice strategy is not
```
none
```
, read tts-production-contract.md. TTS prioritizes generating local assets during the build phase; runtime remote synthesis must be approved in the brief, and keys are only stored on trusted servers.
When dynamic media is actually used, read generative-media-pipeline.md. When approved reference images are available, constrain by the images; tools and models are selected according to the current environment, and not written as cross-project defaults.

共同构建循环

Collaborative Build Cycle

先实现一个最小但完整的核心循环：启动、真实输入、状态变化、结果和重开。范围不足时修范围，不先堆审计材料。
先集中实现最小状态面与规则裁决器，再接表现层。模型可解释自由输入、提出候选动作或根据已提交结果写对白；只有规则器能提交资源、位置、知识、承诺、物件归属、胜负与事件日志。设计含
```
signature_command
```
时，先逐字继承
```
id / label / intents / slots / validators / commit
```
，管线固定为 “表述 → 有版本的候选结构 → schema/前置/知识/承诺验证 → 执行阻力 → 确定性提交 → 叙述”；含混、冲突或越界候选返回澄清/拒绝且不提交，不能让关键词命中或模型
```
effects
```
直接改状态。
固定内容/规则/存档版本、初态、seed 与输入序列；事件日志记录 action、观察者和前后状态摘要。专属命令还记录解析器版本、规范化候选、验证结果、执行轨迹和到期事项；回放消费已记录候选，不重新调用在线模型。试玩反馈定位到节点，局部 patch 后重放失败路径和相邻反例，不让未选分支进入历史。
回写实际工具链、install/build/start 命令和版本；未知值写
```
NOT_AVAILABLE: 原因
```
，不猜。

whitebox

到此只运行最窄的模型/回放检查与启动 smoke，输出结构化观察并交回 design owner；不调用

game-qa

，不写或覆盖

qa/verification.json

，也不把白盒通过冒充生产候选完成。设计修订后重放受影响路径，直到最大风险已被实际暴露或当前方向被否决。

production

继续：

提供一条权威验证命令和最小可观察状态，使
```
game-qa
```
能一次走完
```
clean start → 核心动作 → 设计结果 → restart
```
；构建阶段不预写 QA 结论或重复跑完整验收。
运行最窄的开发检查与启动 smoke，修复构建失败、阻断日志、资源失败和崩溃；替代运行时未覆盖的目标平台输入、性能、打包或设备项写入 limitation。
达到 brief 的
```
targetFinish
```
；更高完成度只处理已批准的焦点资产和招牌时刻，不制造与可玩闭环无关的发布审计。
交给
```
game-qa
```
只运行一次权威命令并写最终事实。时间、预算或生成调用用尽只会留下 FAIL/NOT_RUN，不会生成 PASS。

连续 3D、语音、生成媒体、多语言与无障碍仅在实际采用时增加项目自己的回归检查。必需异步资产加载或解码失败不得静默换灰盒仍宣称通过；可继续的 fallback 条件见 build-brief-contract.md。

First implement a minimal but complete core loop: launch, real input, state change, result, and restart. When the scope is insufficient, revise the scope instead of first accumulating audit materials.
First focus on implementing the minimal state surface and rule adjudicator, then connect the presentation layer. The model can interpret free input, propose candidate actions, or write dialogue based on submitted results; only the rule adjudicator can submit resources, positions, knowledge, commitments, object ownership, wins/losses, and event logs. When the design includes
```
signature_command
```
, first inherit
```
id / label / intents / slots / validators / commit
```
verbatim, and the pipeline is fixed as "expression → versioned candidate structure → schema/precondition/knowledge/commitment verification → execution resistance → deterministic submission → narration"; ambiguous, conflicting, or out-of-bounds candidates return clarification/rejection and are not submitted, and keyword hits or model
```
effects
```
cannot directly modify the state.
Fix the content/rule/save version, initial state, seed, and input sequence; the event log records action, observer, and summary of before-and-after states. Exclusive commands also record parser version, standardized candidates, verification results, execution traces, and due items; replay consumes recorded candidates instead of re-invoking online models. Playtest feedback is located to nodes, and after local patching, replay failed paths and adjacent counterexamples, and do not allow unselected branches to enter the history.
Write back the actual toolchain, install/build/start commands, and versions; write
```
NOT_AVAILABLE: reason
```
for unknown values instead of guessing.

For

whitebox

, only run the narrowest model/replay checks and startup smoke tests, output structured observations, and hand them back to the design owner; do not call

game-qa

, write or overwrite

qa/verification.json

, nor pass off whitebox approval as completion of a production candidate. After design revisions, replay affected paths until the greatest risk has been actually exposed or the current direction is rejected.

For

production

, continue with the following steps:

Provide an authoritative verification command and minimal observable state, enabling
```
game-qa
```
to complete
```
clean start → core action → design result → restart
```
in one go; do not pre-write QA conclusions or repeatedly run full acceptance during the build phase.
Run the narrowest development checks and startup smoke tests, fix build failures, blocked logs, resource failures, and crashes; items related to target platform input, performance, packaging, or devices not covered by the alternative runtime are written into limitations.
Reach the
```
targetFinish
```
specified in the brief; higher completion only handles approved focus assets and signature moments, and does not create release audits unrelated to the playable closed loop.
Hand over to
```
game-qa
```
to run the authoritative command only once and write final facts. If time, budget, or generation calls are exhausted, only FAIL/NOT_RUN will be left, and PASS will not be generated.

Continuous 3D, voice, generative media, multilingual support, and accessibility only add project-specific regression checks when actually adopted. Required asynchronous asset loading or decoding failures cannot silently switch to graybox while claiming approval; fallback conditions for continued operation are specified in build-brief-contract.md.

输出

Output

生成

build/BUILD_BRIEF.md

与实际候选；production 还生成权威验证入口。构建不生成最终 QA 结论。截图、录制与 raw trace 只保留调试所需的最小集合；

game-qa

是 production 完整路径与

qa/verification.json

的唯一 owner。

Generate

build/BUILD_BRIEF.md

and the actual candidate; production also generates an authoritative verification entry. The build phase does not generate final QA conclusions.

Screenshots, recordings, and raw traces only retain the minimal set required for debugging;

game-qa

is the sole owner of the production complete path and

qa/verification.json