game-build
GitHub将批准的游戏设计与美术方向压缩为构建简报,驱动强模型实现网页原型。通过灰盒验证、品类保真自查及视觉迭代,确保核心玩法与体验达标,并生成可运行的游戏代码及完整证据链。
触发场景
安装
npx skills add worldwonderer/novel-to-game --skill game-build -g -y
SKILL.md
Frontmatter
{
"name": "game-build",
"description": "Build the game. Compress the approved GAME_DESIGN and ART_DIRECTION into a minimal BUILD_BRIEF, hand it to the current coding agent or another strong model to implement a fully playable web prototype, and iterate against real runs and screenshots. Use for implement the approved game design, build the game prototype, turn this design into a running game. 游戏构建执行。把批准后的 GAME_DESIGN 与 ART_DIRECTION 压缩成最小 BUILD_BRIEF,交给当前编码智能体、Kimi K3、Claude Fable 5 或其他强模型实现可完整游玩的网页游戏原型,并通过真实运行和截图迭代。用于把批准的游戏方案实现成可运行游戏。"
}
游戏构建执行
保护已批准的游戏设计并驱动强模型完成,不用教程限制模型本来就会的实现能力。
读取 build-brief-contract.md。必须已有
GAME_DESIGN.md 和 ART_DIRECTION.md;缺少产品决策时回到设计阶段。
产物语言由 PRODUCT_BRIEF.md 锁定;未锁定时跟随对话语言,不默认产出中文。
可玩交付始终是网页可玩的垂直切片,但要按 PRODUCT_BRIEF.md 的目标平台惯例来做:竖屏或
横屏、单局时长、控制方式、小程序/移动的轻量与即开即玩、分级对应的内容边界。原型是目标
形态的可玩证明,不因"反正是网页"就套用桌面网页的默认布局。
引擎按 PRODUCT_BRIEF.md 的两层决定:生产引擎是成品方向,原型这一趟落到网页零构建
切片(vanilla / Phaser / Three,或生产引擎的 Web 导出)。原型层的具体 web 实现(选哪个库、
文件拆分、渲染细节)仍由实现模型在既定引擎与平台意图内决定,但不得静默改掉 PRODUCT_BRIEF
锁定的生产引擎方向与目标形态。
构建说明
只固定:成品目标、核心体验、类型契约中会改变结果的不变量、视觉锚点、原型范围、 非目标和完成证据。框架、架构、文件拆分、渲染技术和资产制作由实现模型根据环境决定。
同时固定首发界面语言和已批准的其他语言。玩家可见文案必须集中、可替换,不把文字 烙进图片;第一版只实现策划明确要求的语言,不擅自扩大本地化范围。
把 GAME_DESIGN.md 定的文案声口与去AI味标准写进构建说明,要求实现模型照它写所有
玩家可见文本(标题、引导、按钮、提示、事件、对话、结算、结局)。文案是核心体验面,
晦涩、书面、AI 腔的文本第一屏就让玩家出戏——它和玩法、美术一样是完成标准,不是收尾附属。
若 GAME_DESIGN.md 未定义声口标准,视为缺产品决策,回设计阶段补齐(最低含各角色声口
一句 + 禁用 AI 腔句式清单)后再开工,不得留白施工。
当前会话能编码时直接实现;需要外部模型服务时发送同一份批准设计。外部模型服务 不可用时只交付完整构建说明,不声称游戏已经生成。不要发送与原型无关的完整受版权 保护原文。
可复用技法见 production-techniques.md:灰盒先行 + 皮肤层(资产可替换)、可复现的种子随机、把实现模型当导演对象驱动、多视角试玩 → 设计期 品类保真门、手感打磨(juice) 清单(按类型取用、动效可关)、批量资产受管子流程(视觉键 清单 + 一致性审查),以及行为保护式文案重构与存档迁移。
BUILD_BRIEF 含动态媒体(视频过场 / 环境循环 / 关键帧驱动演出)时,默认生产链为
Codex imagegen(gpt-image-2)产角色 / 场景 / 关键帧图 → Seedance 2.0 图生视频 /
多模态参考生视频,已有可用图片不得退回纯文生视频。完整生产线(最小生产包、参考图
职责、API 提交轮询下载、逐镜证据与连续性门)见
generative-media-pipeline.md。
完成循环
- 用灰盒实现最小但完整的核心循环,先验证规则和范围。
- 启动真实游戏并修复浏览器控制台、资源和运行错误。
- 前提与品类自查(排在美术打磨之前):灰盒能完整游玩时,先起一个不给任何策划 / 构建
文档的干净上下文子代理,只喂常速冷启动第一分钟按序截取的画面,让它回答四问:我是什么 /
我要什么 / 什么会终结这一局 / 这是哪一类游戏(我主要在反复做什么、像我玩过的哪款游戏)。
前三问任一答不出,或第四问的答案既不与 BUILD_BRIEF「同玩法动词清单」重合、也不出现
CONCEPT.md选定方向的子类型或同玩法先例作品名(后者是 QA「前提传达门」的判据,成品 画面上会按它复跑),回设计改,不进美术打磨——打磨只能 把已经成立的东西变好看,救不了没人看得懂的东西。逐字回答落build/evidence/,交 QA 复跑。 - 核心规则走通后再补批准的视觉方向:对照
ART_DIRECTION.md的招牌时刻清单与功能色 / 构图规则逐帧核对,每张招牌画面从真实游玩状态触发并截一张干净证据帧记入构建证据, 到不了或不符的按缺陷修复;一轮核对零新缺陷即停,证据帧随构建完成记录交 QA 复核。 - 操作核心路径、设计要求的结果和重开;根据证据修复并重复。
游戏必须提供一种可重复核心路径和足够的可观察状态,但具体使用界面、网址参数、 测试接口或自动演示由实现模型决定。
输出
生成 build/BUILD_BRIEF.md 和实际游戏。构建说明在完成后补充运行命令、验证结果与已知
限制。构建证据(测试输出、证据帧、招牌帧、导出清单)必须落在工作区内 qa/evidence/ 或
build 目录下的持久路径(本阶段默认 build/evidence/),BUILD_BRIEF 用相对路径引用,
不得只留在系统临时目录。这一条要落到生成的测试脚本本身:脚本里的截图 / 输出目录
默认值必须是工作区内的相对路径(可用环境变量覆盖),不能默认写 /tmp——写测试脚本时
默认临时目录太顺手,实测两个示例都在这里犯过同一个错,而 qa 契约把临时目录路径视为
无证据,对应检查项一律不得记通过。截图存 JPEG 而非 PNG:同一批画面 PNG 七十多兆、
JPEG 十兆量级,判读不受影响。成人向内部验收截图放在项目内不进 README / 公开清单的子目录,
并在导出清单标注。实现若降级任何「必须提供」项,必须写进构建完成记录的已知限制并回
设计确认,不得静默省略。只有可运行路径和构建证据存在时才交回总入口进入质量验证,
不自行调用下一阶段。
版本历史
-
470e35d
当前 2026-07-31 13:49
修复了合并合同引入的8个缺陷:统一了前提自查门的提问措辞以避免误判;修正了先例组计数规则以防止死锁;解决了动词列表缺失、构建与QA标准不一致、时间批次定义模糊及字符串匹配失败等问题。
- 827fb80 2026-07-30 20:19


