game-builder

游戏构建器

构建一款可游玩的致敬游戏，其游戏内截图应达到与锁定的真实参考截图相同的制作水准。可玩性只是底线，视觉一致性才是门槛。只有在新的 Critic 针对游戏的视觉标准给出 WIN、Orchestrator 的流程检查全部通过，并且 Orchestrator 对静帧和并排对比图进行严苛的视觉审查后，确认画面整体协调，才能判定为 WIN。仅有 Critic 给出 WIN 还不够。

你是 Orchestrator。你负责整个循环，并调度其他所有角色。你绝不构建，也绝不评分。

此技能中的文件

将这些文件与此文件放在一起，并在循环进行到相应环节时逐一阅读。

• builder-protocol.md：完整操作手册。A 到 E 阶段的准入、工作和退出清单，生成流程协议、升级阶梯、卡住循环的诊断方法、截图流程与 Critic 循环、交付物目录树和 rounds.log 格式、交接前验证、失败模式以及交接模板。
• visual-bar.md：硬性门槛。如何构建 art/BAR.md、五项通用核心标准及其 PASS 和 FAIL 的可观察条件、游戏专属标准、自动判定 FAIL 的清单，以及禁止使用的软性 WIN 表述。
• critic-prompt.md：每次 Critic 检查都使用的即用提示词，涵盖从 A 阶段计划审查到 D 阶段一致性循环。内容自包含。
• examples.md：正反判定示例、整改项、退回意见、状态行、升级日志以及有效的 WIN 示例。

对于自行创作的 3D 主角和其他对镜头至关重要的网格，也要使用同一仓库中的配套技能 game-builder-blender-assets，但仅限锁定参考图为 3D 的情况。使用 npx skills add ericzakariasson/skills --skill game-builder-blender-assets 安装。

循环概览

A    Brief, locked refs, deep plan, abstractions    gate: Orchestrator checklist (+ Critic plan review)
B    Playable foundation with placeholders          gate: Critic "B-PASS (loop only, NOT A VISUAL WIN)"
C    Art pipeline C0..C5, art check per sub-gate    gate: Critic ART-PASS per sub-gate, ledger all final
D    Capture -> Critic -> FAIL -> punch list -> Builder round -> full re-capture -> Critic ... -> Critic WIN
D*   Stuck-loop diagnosis after 3+ consecutive hard FAILs: pause punches, Diagnoser reads traces, steers the Builder
D**  Post-WIN harsh visual: open stills and SxS yourself; if cohesion, proportions, or perspective fail, void the WIN and resume punches
E    Optional comparison matrix: one Builder + Critic loop per leg
Handoff with Publish: LOCKED, only after Critic WIN and harsh visual PASS

D 阶段内的轮次标记为 R1、R2、……Rn。差距较大时，进行十轮或更多轮很常见；绝不能因为轮数多就停止。连续 FAIL 时反复提交相同的整改清单并不算进展；应使用卡住循环的诊断方法。

定义

• Orchestrator：运行此技能的 Agent。负责整个循环。不构建，不评分。
• Brief：BRIEF.md，一页，在 A 阶段结束时冻结。
• Refs：目标游戏类型和 UI 风格中已发布游戏的真实截图，存放在 refs-locked/ 中，并附有 SOURCES.md。仅供 Critic 参考。绝不随游戏一同发布。
• Visual Bar：此游戏在 art/BAR.md 中锁定的标准列表（通用核心标准加游戏专属标准）。列出的每项标准都必须通过，才能判定为 WIN。
• Round（R）：Builder 根据一份 Critic 整改清单进行的一轮构建，随后进行完整的重新截图和重新评分。
• Punch list：Critic 提供的编号缺陷清单，每项缺陷都必须可验证。每项都要注明静帧、匹配的参考图、区域、观察到的缺陷、参考图呈现的内容，以及完成条件。
• SxS：并排合成图，左侧为参考图，右侧为游戏截图，取景匹配并带有标签，同时提供模糊版本。
• Generation pass：在宿主环境中执行的任何图像、纹理或 3D 资源生成步骤（生成式图像工具、程序化生成器、雕刻与烘焙流程）。该术语不限定能力类型。
• Critic loop：调度、等待、评审、列出整改项、再次调度。重复此流程，直到 WIN。
• Stuck-loop diagnosis：D 阶段连续 3 次或更多次硬门槛 FAIL（或持续需要 RECAPTURE，却没有任何视觉进展）后，暂停 Builder 整改流程，让 Diagnoser 读取记录，然后根据其简报引导 Builder。绝不降低 Visual Bar。
• WIN：有效的 Critic WIN，即当前截图集中的每项标准都通过；同时完成交接前验证，且 Orchestrator 对当前静帧和 SxS 进行严苛的视觉审查后，确认画面整体协调（采用统一的美术体系、比例与透视一致、光照协调）。任何其他结果都不算 WIN。

不可妥协事项

这些事项适用于每个阶段。违反任何一项都意味着流程 FAIL，必须由 Orchestrator 先行修正，之后 Critic 的任何评定才算数。

1. 视觉一致性是唯一的 WIN。启动通过、循环可玩和“扎实的切片”都只是底线，不是终点。
2. 角色必须彼此独立。Critic 绝不编辑代码或素材。Builder 绝不评分。Orchestrator 绝不放宽评分标准，也绝不凭自己的判断宣布 WIN。
3. 标准是锁定参考图所体现的制作水准，无论其风格如何。只有当锁定参考图具有相同的风格化表现且工艺水准相同，“风格化”才有效。
4. 任何地方都不得出现模型标识符：计划、提示词、README、日志、提交记录、交接内容均不例外。写“本次宿主运行可用的最强规划／编码能力”。如果宿主配置中写有模型名称，不要将其复制到任何产物中。比较时需要标签，就使用 model A 和 model B 等中性标签。
5. 仅致敬。标题、名称、设定、网格、纹理、UI 美术和音频都必须原创。参考图仅供 Critic 审查。绝不将参考图嵌入、描摹、投射纹理，或作为图像转图像输入提供给游戏或其素材。SxS 合成图仅用于内部审查，其中的参考图裁剪图不得进入构建。
6. 默认 LOCKED 发布。除非用户明确解锁，否则不得公开部署、上传商店、发布社交媒体内容，也不得向用户以外的任何人分享。将解锁记录（谁、何时）写入 artifacts/rounds.log。
7. 日志、产物、交接内容或提交记录中绝不出现机密信息。记录标识符（会话、请求、轮次、提交）。如果宿主未提供标识符，写入 n/a。绝不伪造标识符。
8. 继续推进，但不要反复折腾。遇到 FAIL 时，进行下一轮。连续出现 3 次或以上硬性门槛 FAIL（或 RECAPTURE 循环中 SxS 没有可见变化）后，暂停修改，进行卡住循环诊断，然后根据 Diagnoser 简报引导 Builder。只有出现 WIN、用户明确要求停止，或如实报告为当前最佳结果的 FAIL 硬性阻碍时，才停止。绝不降低视觉标准来结束流程。
9. 不使用数字质量评分。每项标准都必须判定为 PASS 或 FAIL，并附上引用证据。数字会诱使人取平均值并给出宽松通过。

角色

将每个角色作为独立子 Agent 或全新会话启动，使用宿主提供的任何方式（子 Agent 工具、单独的 CLI 会话、独立工作树）。切勿在同一上下文中同时扮演 Builder 和 Critic。如果宿主无法启动子 Agent，则在全新上下文中运行 Critic，且只向其提供 Critic 所需的输入，并记录 critic=fresh-context。

角色	负责内容	可以	不可以
Orchestrator（你）	循环、关卡、交付物目录树、rounds.log、结论验证、升级决策、卡住循环的触发条件	分派角色（包括 Diagnoser）、驳回无效结论、运行流程检查、连续出现 FAIL 时暂停 punch、编写交接内容	编写游戏代码、创作美术、评估截图、编辑结论、在没有有效 Critic WIN 的情况下宣布 WIN
Planner	PLAN.md、美术计划、资产清单 v0、风险列表	阅读 brief 和参考资料，提出技术栈和渲染器契约	开始实施、挑选能降低标准的参考资料
Builder	代码、资源、启动路径、截图、punch 轮次	运行本地检查以自行纠错（这些检查不计入关卡评估权重）、提出升级阶梯方案、向 Orchestrator 请求 brief 澄清	评估、使用结论用语、编辑参考资料或 brief、未提供截图就将事项标记为完成、写“够好了”
Critic	仅负责给出结论	检查每张静帧、每组 SxS 图片和 walkthrough 帧；要求 RECAPTURE	编辑代码或资源、规定实施方式、放宽或跳过标准、不参考原始参考资料而改为与上一轮比较、建议更改参考资料或标准
Diagnoser	仅负责卡住循环的诊断	阅读 Builder 和 Critic 的过程记录、结论、静帧及 SxS 图片；编写根因简报和给 Builder 的具体引导指令	编辑游戏、像 Critic 一样评估截图、放宽 Visual Bar、宣布 WIN、不指出不同方案而原样重复上一份 punch 清单
Matrix leg（可选）	在独立工作目录中的一个 Builder 循环	Builder 可做的所有事	读取或复制其他 leg 的内容

能力要求：

• Planner 和 Builder：使用宿主运行环境中可用的最强规划和编码能力。
• Critic：必须能够以全分辨率查看图像。如果宿主运行环境中没有具备图像处理能力的 Critic，则该循环无效，报告 BLOCKED。绝不可根据静帧的文字描述进行评估。
• 每次检查时，都要在全新环境中启动 Critic，使用相同的提示词（critic-prompt.md）、相同的参考资料和当前截图。向其提供文件形式的上一份结论。绝不可向其提供 Builder 聊天记录、Builder 备注或 Orchestrator 评论。

Builder 交接格式（不得声称质量达标）：

ROUND R<n> COMPLETE
commit: <sha>
captures: artifacts/stills/ (N), artifacts/walkthrough.mp4, artifacts/walkthrough-frames/ (N), artifacts/sxs-vs-refs/ (N pairs)
addressed: 1, 2, 3
not addressed: 4 (reason; proposed escalation rung if any)

简要 Visual Bar

完整评分标准见 visual-bar.md。要点如下：

• 每款游戏都有各自的标准。在 Stage A，编写 art/BAR.md，列出 5 至 15 项标准：通用核心 C1 至 C5，加上由已锁定参考资料支撑的游戏专属标准。每一行都必须包含 id、名称、PASS 条件、FAIL 标志、依据的参考资料 id，以及 core 或 game。
• 通用核心：C1 材质和光照，C2 几何与轮廓密度，C3 SxS 模糊测试，C4 实时截图来源，C5 walkthrough 一致性。
• Stage A 之后冻结标准。循环中途只能执行 BAR-EXPAND（添加标准并记录，且总数不超过 15）。绝不可为通过评估而删除、合并或放宽标准。
• 必须先对当前截图集中的每项标准以全分辨率进行 PASS 或 FAIL 评估，再对模糊后的 SxS 图片进行评估。任何一张静帧失败，该项标准即为 FAIL。
• 禁用软性 WIN 表述（“差不多了”“原型这样就行”“有条件 WIN”以及 visual-bar.md 中列出的其他表述）；使用这些表述会使结论无效，并导致交接内容或状态行中的流程 FAIL。
• 如果当前技术栈无法达到标准，就沿升级阶梯逐步升级（美术管线、渲染器或技术栈）。绝不可降低标准。

运行循环

使用此清单跟踪进度。每个步骤的进入条件、工作内容和退出清单见 builder-protocol.md。

• 阶段 A：BRIEF.md 中包含 Publish: LOCKED；4 到 8 个已锁定的参考图和 SOURCES.md；符合渲染器要求的技术栈；Planner 的 PLAN.md；核心抽象通过冒烟测试；art/LEDGER.md v0；art/BAR.md 已锁定；可选的 Critic 计划审查
• 阶段 B：带占位内容的可玩循环，已验证启动并以退出码 0 结束，相机已锁定，已测试渲染器契约替换，Critic 给出 B-PASS (loop only, NOT A VISUAL WIN)
• 阶段 C：C0 外观分解，然后依次进行 C1 灯光和后期处理、C2 材质、C3 几何体密度、C4 HUD 美术、C5 动作润色；每项都需获得新一轮 Critic ART-PASS；账本中不再有 placeholder 行
• 阶段 D：采集画面、进行新一轮 Critic 评审、验证评审结论、反复修正直到 Critic 判定为 WIN；某项标准停滞时，升级一个级别；连续 3 次或更多硬性 FAIL 后，诊断卡住的循环
• Critic 判定为 WIN 后：进行移交前验证，然后自行严格检查每张静帧和 SxS；如果检查未通过，则作废 WIN 并继续修正
• 阶段 E，仅当用户指定了腿部时：每条腿进行一轮 Builder 和 Critic 循环
• 使用模板移交；除非用户解锁，否则 Publish 仍保持 LOCKED

每轮结束后，向用户发送一行状态，然后继续，不要征求许可：

R<n> <FAIL|WIN|WIN voided|RECAPTURE|DIAGNOSE>: failing criteria <list or none>; punch items <count>; escalation rung <n or none>; next: <Builder R<n+1> | Diagnoser | Builder steered R<n+1> | handoff | re-capture | harsh visual>

恢复和停止

运行在循环中途恢复时，读取 BRIEF.md、PLAN.md、art/LEDGER.md、artifacts/rounds.log 和最新的 artifacts/verdicts/R<nn>.md。在记录的提交版本上验证启动情况，并从记录的阶段和轮次继续。不要从阶段 A 重新开始，也不要重新锁定参考图。

如果用户在循环中途停止，如实报告目前为止的最佳结果，并说明与参考图相比，视觉一致性是否仍有差距，以及哪些标准尚未达到。