9fcfe61a0a
Some checks failed
docs-gate / docs-gate (push) Has been cancelled
折账批次1(A/B/C/D 四组并行)+ 批次2(注册表/_index/降留痕)+ 批次3(docs-gate 七检绿+旧口径 grep 清零)。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
429 lines
51 KiB
Markdown
429 lines
51 KiB
Markdown
# OpenGame 对照 · 外部标杆深读
|
||
|
||
> 🚧 **架构演进中** —— 廉价线 **gameDefinition 已废(错误路线),现行 = A-model 写真 `src/`**;tier2 富游戏自治轨建设中(0 号 spike accept)。文中结论可能随推进变化,以子树 [README](README.md) / 运行时 SoT [`agentic运行时架构图说`](agentic运行时架构图说.md) 与最新裁定为准。
|
||
|
||
> **这是什么**:绘境AI 生成引擎对外部最强开源标杆 **OpenGame** 的源码级深读,以及由此照出的复刻缺口。它回答两个问题——"**OpenGame 到底是怎么把一句话变成游戏的**",以及"**它身上哪三层东西值钱、我们还没有**"。
|
||
> **给谁看**:负责生成主线的工程师、做技术选型与对标的架构评审、想看清护城河关键路径上"我们与最强开源系统差在哪"的人。
|
||
> **怎么读**:先读 §1 的定位与一张对照全景图;§2 是主体——逐层拆 OpenGame 的真实机理(主循环 / 韧性 / 子 agent / 系统提示 / 六阶段生成 / 三大支柱);§3 落到我们的现状,把缺口分四类诚实交代。想要"往哪走、先做什么"的统一行动项,去[生成引擎 README](README.md) §6(统一演进路线现行落点)拿——本档只负责把 OpenGame 的内部机理和逐项缺口的来龙去脉讲透。
|
||
|
||
---
|
||
|
||
## 0. 先讲清楚:这份文档在体系里的位置
|
||
|
||
生成引擎子树的主文档([生成引擎 README](README.md))已经在它的 §5 用一页篇幅,概括了"对标 OpenGame 我们缺哪三层"。那是**结论**。本文档是那一页结论背后的**源**——把 OpenGame 的源码真正读穿,逐层讲清它每个机制为什么这么设计、对用便宜模型的人意味着什么,再把每一处缺口的取舍依据摆出来。
|
||
|
||
> **OpenGame 是什么**:一个把"一句话需求"变成"可玩游戏"的开源生成系统(源码在 `github.com/leigest519/OpenGame`,作者是香港中文大学 MMLab,对应论文 arXiv 2604.18394)。它是当前这一赛道最完整、最值得深读的开源对照物。本档的所有结论都锚在 clone 下来的**真源码**上,不取信于论文 README 的宣称——这个区分在 §2.7 会变得至关重要。
|
||
|
||
一句话定位:**README §5 给结论,本档给证据与机理。** 两者职责不同,不互相重复;当你只想知道"我们要做什么"时读 README,当你想知道"OpenGame 凭什么、以及我们为什么这么取舍"时读这里。
|
||
|
||
---
|
||
|
||
## 1. 一句话与一张图:两条路,同一个终点
|
||
|
||
在拆 OpenGame 之前,得先把我们自己和它摆在同一张图上,否则后面所有的"抄"与"不抄"都没有坐标系。
|
||
|
||
绘境AI 的生成主线,本质是一条**用便宜的通用模型驱动、用确定性的图编排约束控制流、用一套自动验收门兜底**的流水线。**本档是一份写作当时的对照分析,拿我方那时的基线跟 OpenGame 比**:当时的骨架是 **SAA 裸 StateGraph**(SAA = Spring AI Alibaba,阿里在 Spring 生态里的 AI 编排框架;"裸 StateGraph"指直接用它的有向状态图原语手写编排,而不是再套一层 agent 框架),一共 16 个节点,每个节点是一段实打实的 Java 代码,节点间的流转**由图预先固定**,而非由模型在运行时临场决定下一步。**2026-06-25 框架 reframe 后生成框架已统一收敛到 AgentScope(SAA 降为最低优先级、留作远期适配验证),现行编排底座以运行时 SoT [`agentic运行时架构图说`](agentic运行时架构图说.md) 为准;下文凡说"SAA 图 / SAA 节点",读作那条当时基线。要向 OpenGame 借的东西(工具层、韧性兜底、经验复利)与框架无关,收敛后照样成立。**
|
||
|
||
OpenGame 走的是另一条路:它是一个**命令式自主循环**——在一个 `while(true)` 死循环里,模型**自由决定**下一步调用哪个工具,控制流**由模型驱动**。这是和我们正交的另一种范式。
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph 我方["绘境AI 生成引擎 — 声明式有向图"]
|
||
direction LR
|
||
HG["SAA 裸 StateGraph<br/>16 节点,控制流由图固定"]
|
||
HN["九门 harness<br/>确定性机制验收(领先)"]
|
||
HM["便宜通用模型 + 门兜底<br/>不训专用大模型"]
|
||
end
|
||
subgraph 对方["OpenGame — 命令式自主循环"]
|
||
direction LR
|
||
OL["while(true) ReAct 循环<br/>控制流由模型驱动"]
|
||
OT["4 个原子游戏工具<br/>+ 六阶段 SOP 接力"]
|
||
OS["经验自进化(护城河)<br/>Template / Debug Skill"]
|
||
end
|
||
对方 -. "抄它的工具层 / 韧性兜底 / 经验复利,当零件库落进 SAA 节点内部" .-> 我方
|
||
对方 -. "不抄它的『模型自由驱动主循环』范式" .-> X["缝合设计红线"]
|
||
style X fill:#f5b7b1
|
||
style HN fill:#a9dfbf
|
||
style OS fill:#f9e79f
|
||
```
|
||
|
||
这张图先把全篇最重要的取舍钉死:**OpenGame 的控制流我们用 SAA 图来表达**(我们本来就这么做,而且对卡 80% 成功率门而言,图的确定性比口头督促更稳,这是升级不是抄);**OpenGame 的工具层、韧性兜底、防脏脚手架与经验复利机制,我们当成零件库,原样落进 SAA 节点内部**。一句话——**抄它的工具与兜底,不抄它的主循环范式**。把主循环硬塞进来,就成了项目明令反对的"缝合设计"(指把一份为 A 范式写的代码硬粘到 B 范式上当接口,而不从整体架构出发)。
|
||
|
||
带着这个坐标系,下面进入主体:OpenGame 到底是怎么运转的。
|
||
|
||
---
|
||
|
||
## 2. OpenGame 是怎么生成游戏的
|
||
|
||
### 2.1 它的出身:不是新框架,是 Qwen-Code 的二次 fork
|
||
|
||
读 OpenGame 源码,第一个、也是最重要的认知矫正是:**它不是从零写的 agent 框架,而是 `Gemini-CLI → Qwen-Code → OpenGame` 这条二次 fork 的产物。**(fork = 把别人的开源项目拷一份在其上改;"二次 fork"指它本身又是 fork 之上的 fork。)
|
||
|
||
这个判断有硬证据,不是猜的:
|
||
|
||
- `geminiChat.ts` 文件顶部注释自承是 js-genai 的 `chats.ts` 逐行拷贝改版;
|
||
- `subagent.ts` 的版权头写着 Qwen;
|
||
- 系统提示里自述"built on top of the Qwen Code agent framework by Alibaba Group";
|
||
- shell 执行时注入 `QWEN_CODE=1` 环境变量;
|
||
- MCP 客户端名还残留着 `qwen-cli-mcp-client`、OAuth 客户端名是"Gemini CLI MCP Client"。
|
||
|
||
这个出身决定了 OpenGame 的能力分布。**MCP 接入、shell 沙箱、会话持久化、配置面、OAuth——这一整套执行基座,是从上游成熟代码完整继承的。**(MCP = Model Context Protocol,模型上下文协议,一种让 agent 接外部工具/数据源的标准总线;OAuth = 第三方授权登录协议。)OpenGame 自己真正写的,只有三样:tools 层的四个游戏专用工具、一个音乐合成服务,以及一套 Phaser + Vite 工程模板(Phaser = 一个成熟的 2D HTML5 游戏引擎;Vite = 前端构建工具)。
|
||
|
||
换句话说:**"复刻 OpenGame 的引擎",本质是复刻 Qwen-Code,而不是发明什么新架构**——而我们已经选了 SAA 图这条不同的路。这一点先记下,它会贯穿整篇对照:真正属于"游戏生成"的创新,集中在那四个工具和那套模板里,其余都是继承的通用 agent 基建。
|
||
|
||
### 2.2 它的主循环:三层权力分配的 ReAct
|
||
|
||
OpenGame 的 agent 主循环,核心不是一段编排脚本,而是一个经典的 **ReAct/工具循环**(ReAct = Reason+Act,指"模型先推理、再调工具、看结果、再推理"的循环范式),但被干净地拆成三层。值得细看它的"权力是怎么分配的",因为这正是它可移植性好的原因。
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
autonumber
|
||
participant Loop as 外层 while(true)<br/>(nonInteractiveCli)
|
||
participant Client as 中层 sendMessageStream<br/>(client.ts)
|
||
participant Turn as 内层 Turn.run<br/>(turn.ts)
|
||
participant Model as 大模型
|
||
participant Tool as 工具执行
|
||
|
||
Loop->>Client: 用当前消息开一个回合
|
||
Client->>Client: 压缩历史 / 检查 token 上限<br/>注入 IDE 上下文 + system-reminder<br/>跑循环检测
|
||
Client->>Turn: 进入单回合
|
||
Turn->>Model: chat.sendMessageStream(一次)
|
||
Model-->>Turn: 流式 chunk(内容/思考/工具请求)
|
||
Note over Turn: Turn 只『发出工具请求事件』<br/>自己绝不执行任何工具
|
||
Turn-->>Loop: 事件流(含工具调用请求)
|
||
alt 这一圈有工具请求
|
||
Loop->>Tool: 逐个真正执行
|
||
Tool-->>Loop: 结果打包成 role=user 的 functionResponse
|
||
Loop->>Loop: 回灌到循环顶部,再来一圈
|
||
else 这一圈只说话、没发起工具
|
||
Loop->>Loop: 终止(收敛)
|
||
end
|
||
```
|
||
|
||
读这张时序图,抓住三层的职责切分:
|
||
|
||
- **最外层**是非交互 CLI 里的 `while(true)`(在 `nonInteractiveCli.ts`)。每一圈做四件事:用当前消息调一次流式模型;消费事件流,把模型发起的工具调用请求累积起来,把文本和思考直接打到标准输出;流结束后,如果有工具请求就逐个真正执行,把每个工具的返回打包成**一条 role 为 user 的 functionResponse 消息**回灌到循环顶部——这就是"喂回结果再循环"的本质。(functionResponse = 工具调用的结构化返回,以 user 角色塞回对话,让模型读到上一步工具产出了什么。)
|
||
- **中间一层**是 `client.ts` 的 `sendMessageStream`,负责把"一个回合"武装起来:压缩历史、检查会话 token 上限、注入 IDE 上下文增量、注入 system-reminder、跑循环检测,然后才进入真正的单回合。(system-reminder = 每轮临时注入的一段提醒文本,用于喂动态信息,不进固定的系统提示。)
|
||
- **最内层**是 `turn.ts` 的 `Turn.run`,它只负责调一次 `chat.sendMessageStream`,把模型吐出的 chunk 翻译成事件(内容/思考/工具请求/完成/错误)。**关键设计:Turn 自己绝不执行任何工具,它只发出"我要调这个工具"的请求事件。**
|
||
|
||
这个"权力分配"是整个设计的精髓:**模型回合只有发起权,执行权牢牢握在外层循环手里;工具结果统一以 user-role functionResponse 回灌。** 三层职责清晰,可移植性很好。它的**收敛条件极其朴素:模型这一回合只说话、不调工具,就算完成了。**
|
||
|
||
围绕这条主循环,它还打了好几个护栏:`MAX_TURNS=100` 硬顶、会话级回合上限、token 上限、`LoopDetectionService` 检出复读直接退出。最有意思的一个补丁叫 **`checkNextSpeaker`**——当模型说了"接下来我要做某某"却没真去发工具调用时,它会用一次额外的 LLM 判定 next_speaker(下一个该谁说话),如果判定该轮到模型,就自动注入一句"Please continue."把它顶回正轨。**这是专门用来对付"模型话痨但不动手"的早停问题的,而便宜模型恰恰最容易犯这个毛病。**
|
||
|
||
### 2.3 它的韧性:把一切错误降级成喂回模型的 functionResponse error
|
||
|
||
如果说主循环是骨架,那 **`CoreToolScheduler`**(核心工具调度器)就是让这副骨架在脏数据下不散架的关节。它把每个工具调用建模成一个状态机。
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
[*] --> validating: 收到工具调用请求
|
||
validating --> scheduled: 参数校验通过
|
||
validating --> error: 参数非法 / 幻觉工具名
|
||
scheduled --> awaiting_approval: 需 HITL 确认
|
||
scheduled --> executing: 确认门齐开
|
||
awaiting_approval --> executing: 用户批准
|
||
awaiting_approval --> cancelled: 用户拒绝
|
||
executing --> success: 执行成功
|
||
executing --> error: 执行失败
|
||
error --> [*]: 降级成 functionResponse error<br/>喂回模型,让它自己纠正
|
||
cancelled --> [*]: 同样喂回模型
|
||
success --> [*]
|
||
```
|
||
|
||
调度语义可以一句话概括:**批内并行、批间串行、确认门齐开才执行**——同一批工具调用先全部发起再一起 await(并发),但不同批次之间严格串行排队;而且要等这一批所有调用都到了 scheduled 或终态,才统一开始执行。(HITL = Human-In-The-Loop,人在环路里,指需要人工点一下"批准"的确认门。)
|
||
|
||
但对我们最有借鉴价值的,不是它的并发语义,而是它的**容错哲学**:幻觉工具名(模型编了个不存在的工具)、参数非法、被用户拒绝、工具执行失败——这些统统不让它崩溃,而是**降级成一条 functionResponse error 喂回给模型,让模型自己读着错误去纠正**。尤其当模型造了个不存在的工具名时,它会用 **Levenshtein 编辑距离**(衡量两个字符串差几个字符的算法)算出"你是不是想用 X"的建议,一并塞回去。
|
||
|
||
**便宜模型最大的问题就是输出脏——乱造工具名、参数对不上——而这一层"错误即上下文"的兜底,比模型本身更决定成败。这是 OpenGame 给所有想用便宜模型的人上的第一课。**
|
||
|
||
### 2.4 它的子 agent:一层深的"上下文隔离 + 只回吐结论"
|
||
|
||
OpenGame 的 subagent(子 agent,指主 agent 派生出去干一件子活的独立 agent)是一等公民,而且设计得很克制。主 agent 把 `task` 当成一个普通工具来调;系统提示里明确教模型"做文件搜索这类活优先用 task 工具以减少上下文占用",每轮请求前还会动态注入一段 system-reminder 把可用的子 agent 名字塞进去、怂恿模型去委派。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
Main["主 agent<br/>(完整工具集,含 task)"] -->|task_prompt 注入任务| Sub["子 agent<br/>全新 GeminiChat"]
|
||
Sub --> SubLoop["独立 while(true) mini-loop<br/>探索几十轮"]
|
||
SubLoop --> SubTools["子 agent 工具集<br/>(被裁剪,强制剔除 task 本身)"]
|
||
SubTools -. "不能再派生子 agent<br/>隔离深度只有一层" .-> NoDeep["✗ 不是任意深度 agent 树"]
|
||
SubLoop -->|"只回吐最后一轮纯文本结论"| Main
|
||
SubLoop -. "中间几十轮探索噪音<br/>全吞在自己肚子里" .-> Swallow["主 agent 上下文不被污染"]
|
||
style NoDeep fill:#f5b7b1
|
||
style Swallow fill:#a9dfbf
|
||
```
|
||
|
||
机制上,子 agent 会开一个**全新的 GeminiChat**,只继承环境历史,系统提示由模板占位符渲染(主 agent 只通过 `task_prompt` 注入任务描述),并且**自带一个独立的 `while(true)` mini-loop**。最关键的两个设计:
|
||
|
||
1. 子 agent 的工具集被裁剪,而且**强制剔除 task 工具本身**——所以子 agent 不能再派生子 agent,**隔离深度只有一层**,这不是任意深度的 agent 树。
|
||
2. 子 agent 跑完几十轮探索后,**只把最后一轮的纯文本结论回吐给主 agent**,中间过程全吞在自己肚子里。
|
||
|
||
这正好兑现了系统提示里说的"减少上下文占用":主 agent 不会被子任务的探索噪音污染。**代价是委派靠 prompt 怂恿而非硬路由,委派质量死死绑在主模型的判断力上**——便宜模型在这里大概率不会主动、聪明地委派。这是一个对我们有直接启示的取舍:我们用 SAA 图把"什么时候该分子任务"固定成边,正好绕开了"便宜模型不会自己委派"这个坑。
|
||
|
||
### 2.5 它的系统提示:静态人格 + 环境分支 + 模型方言,动态信息走 system-reminder
|
||
|
||
OpenGame 的系统提示拼装很能体现工程成熟度。一个 `getCoreSystemPrompt(userMemory, model)` 函数顺序拼接四段:
|
||
|
||
1. **可被外部 `.md` 文件整体覆盖的基座大模板**——身份、Core Mandates(核心行为准则)、强制频繁用 todo 的任务管理、软件工程的 Plan/Implement/Verify(计划/实现/验证)工作流,甚至写死了"2D 游戏用 HTML/CSS/JS、3D 用 Three.js"的技术默认。
|
||
2. **按 SANDBOX 环境变量三选一注入的沙箱段落**。
|
||
3. **按是否 git 仓库追加的 Git 守则**。
|
||
4. 然后是一个很妙的细节——**按模型名切换三套 few-shot 工具调用示例方言**(few-shot = 在提示里给几个示范例子):通用自然语言、qwen-coder 的 XML 风格、qwen-vl 的 JSON 风格,去适配不同模型对工具调用语法的偏好。
|
||
|
||
这里藏着两个对我们有用的工程判断:
|
||
|
||
- **真正每轮变化的动态信息不进系统提示**,而是作为 user 消息或 system-reminder 在每轮注入(IDE 上下文、subagent 提醒、plan-mode 提醒)——这样系统提示可以被缓存,省钱。
|
||
- **"按模型切 toolcall 方言"是支撑多便宜模型的关键工程点**。换一个便宜的 Qwen 系或别的模型,主要改的就是这套方言示例和底层的 ContentGenerator——它支持 OpenAI / Anthropic / Gemini / Vertex / Qwen 五种认证,`baseUrl` / `model` / `apiKey` 全是 env + config 双层可配,还带 `retryWithBackoff`(指数退避重试)和 429 限流回退到 flash 模型,而循环骨架完全不动。
|
||
|
||
**一句话:"用便宜通用模型"在 OpenGame 里是一等公民,开关早就铺好了。** 这和我们"便宜模型 + 门兜底"的路线判断是一致的——区别在于它用提示方言切模型,我们应当把这层做成外置的 `models.yaml` 数据契约(见 §3 与演进路线)。
|
||
|
||
### 2.6 它真正怎么把一句话变成游戏:四个原子工具 + 六阶段 SOP 接力
|
||
|
||
这是整篇分析最该被吸收的部分。OpenGame 的工具集**刻意地小,只有四个游戏专用工具,没有一个"端到端生成游戏"的大黑盒**。生成逻辑全靠 agent 用这堆原子工具,按相位一步步串起来。
|
||
|
||
最反直觉的发现是:**这条端到端流水线没有任何中央编排文件**(全仓 grep 不到驱动相位的 workflow 代码)。它是靠两样东西驱动的——一份叫 `custom.md` 的确定性 SOP 系统提示(SOP = Standard Operating Procedure,标准作业流程),以及**每个工具返回内容末尾注入的 `<system-reminder>` 接力指令**。
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
Brief["一句话需求"] --> P1
|
||
subgraph P1["Phase 1 · 物理优先分类 + 脚手架"]
|
||
C["classify_game_type<br/>归入 5 archetype 之一"]
|
||
C -->|"返回里塞 system-reminder:<br/>给出 cp 命令拷模板"| ROUTE["路由器:archetype 一旦定<br/>后面规则/资产/模板全被决定"]
|
||
end
|
||
P1 -->|"接力指令:下一步调 generate-gdd"| P2
|
||
subgraph P2["Phase 2 · 把一句话编成六节技术规格书"]
|
||
G["generate_gdd<br/>动态拼三层规则 → GAME_DESIGN.md"]
|
||
G --> RULE["三铁律:Config-First /<br/>Zero Custom Code / Hook Integrity"]
|
||
end
|
||
P2 -->|"DO NOT STOP. CONTINUE TO PHASE 3 NOW"| P3
|
||
subgraph P3["Phase 3 · 多模态资产 + 确定性贴图(最重)"]
|
||
A["generate_game_assets<br/>生成→抠图→I2V抽帧→多级回退→装配"]
|
||
T["generate_tilemap<br/>AI画3×3 + AI写ASCII<br/>+ 确定性 bitmask 自动贴图"]
|
||
end
|
||
P3 -->|接力| P5
|
||
subgraph P5["Phase 5 · 落地代码"]
|
||
E["smart_edit(注册名 edit)<br/>三级匹配 + LLM 自纠错<br/>把规格写进模板文件"]
|
||
end
|
||
P5 --> OUT["可玩游戏"]
|
||
style ROUTE fill:#f9e79f
|
||
style RULE fill:#a9dfbf
|
||
```
|
||
|
||
让我顺着这几个相位讲一遍——这是整篇最该被吸收的部分。
|
||
|
||
**Phase 1,物理优先分类 + 脚手架。** agent 调 `classify_game_type`,把用户那句话归入五个 archetype 之一:platformer(平台跳跃)、top_down(俯视)、grid_logic(网格逻辑)、tower_defense(塔防)、ui_heavy(以 UI 为主)。(archetype = 游戏原型/品类,这里指按"物理形态"划分的玩法大类。)它的分类规则刻意"不看品类名,只看物理"——重力方向、视角、移动方式,系统提示里还专门列了易错例(Terraria 是 platformer 不是 top_down)。这个工具的容错解析很务实:先剥 markdown 代码围栏,JSON 解析失败就退化成在字符串里找关键词,再不行默认 platformer。但它真正的产出不在分类结果本身,而在它返回内容里塞的一段 system-reminder——**直接给 agent 下一步要跑的 `cp` 命令**(把 `templates/core` 和 `templates/modules/{archetype}` 拷进工作区,把对应文档拷进 docs),并指示"下一步调 generate-gdd"。**这是整条链的路由器:archetype 一旦定下,后面用哪套 GDD 规则、什么视角的资产、COPY 哪套模板,全被决定了。分类错,后面全错。**
|
||
|
||
**Phase 2,把一句话编成六节技术规格书。** agent 调 `generate_gdd`(GDD = Game Design Document,游戏设计文档),它会向上递归找 docs 目录,动态拼三层规则——通用 GDD 格式、该 archetype 的设计视角规则、该 archetype 的 `template_api.md`(可用的代码能力 / hook 清单;hook = 模板预留给生成代码挂接的接口点)——找不到文件就回退到内置规则(内置规则本身极其详尽,光 grid_logic 那段就有上百行讲三相回合管线、cell 类型、undo、AI)。它真发一次 LLM 请求,产出一份六节的 `GAME_DESIGN.md`。
|
||
|
||
**这份 GDD 的精髓在于:它不是给人看的文案,而是一份"每一节都硬绑一个下游工具入参或代码文件"的契约**——Section 1 的资产表喂给 `generate_game_assets`,Section 4 的 ASCII 布局喂给 `generate_tilemap`,Section 2 的数值合并进 `gameConfig.json`,Section 3/5 去改 LevelManager 和 main.ts。它把开放式的"做个游戏"收敛成了一张结构化、可被便宜模型逐项落地的待办清单。约束便宜模型不跑飞的,是它的**三条铁律**:
|
||
|
||
- **Config-First**:数值只能进 `gameConfig`;
|
||
- **Zero Custom Code**:只用模板已有行为,不许自己写新逻辑;
|
||
- **Hook Integrity**:绝不许编造 `template_api.md` 里没有的 hook。
|
||
|
||
返回内容末尾又是一大段 system-reminder,命令 agent 存盘后逐 Phase 往下走,还专门写了"DO NOT STOP. CONTINUE TO PHASE 3 NOW"。
|
||
|
||
**Phase 3,多模态资产流水线——这是最重、最难抄的一块。** `generate_game_assets` 不是简单调个文生图,而是一整套"生成 → 抠图 → 视频抽帧 → 多级回退 → Phaser 清单装配"的流水线:
|
||
|
||
- **背景图**强制"纯场景无人物无文字";
|
||
- **角色图**文生图后过抠图服务去白底;
|
||
- **动画**是亮点——先生成 idle 基帧,然后**优先走图生视频(I2V,Image-to-Video)再用 ffmpeg 本地抽帧逐帧抠图**;如果没有 ffmpeg 或失败,**回退到图生图(I2I,Image-to-Image)逐帧编辑**;
|
||
- **音频**则是三级回退——文生视频抽音轨,失败就让模型产 ABC 记谱法再用 Python 的 symusic 库离线合成 WAV,再失败就纯程序生成占位音;
|
||
- **瓦片集**强制"先画 3×3 九宫格再扩成 7×7 blob"。
|
||
|
||
所有产物登记进一份 Phaser 能直接 `load.pack` 的 `asset-pack.json`。**这块每个模态都有降级路径保证不空手而归,但它依赖视频模型 + ffmpeg + 抠图服务——便宜的文生图模型替不了动画质量,这是真壁垒。**
|
||
|
||
**Phase 3 配套,确定性贴图——OpenGame 最聪明的工程判断之一。** `generate_tilemap` 把"AI 画不好整张地图"这个老问题,拆成了"AI 只画 3×3 材质 + AI 只写 ASCII 布局",中间用一个**确定性的 8 邻域 bitmask 自动贴图算法**(bitmask = 位掩码;根据上下左右及对角是否实心,算出 47-tile blob 里的精确瓦片 id)来补全墙体接缝和拐角。**这等于用确定性算法绕开了模型的空间推理能力**,极大降低了对模型的要求。而且它有个关键的架构判断:**只对 platformer/top_down 用瓦片地图;grid_logic/tower_defense/ui_heavy 故意走代码定义网格**,理由是这类逻辑游戏运行时 cell 会变(门会开、洞会填),用瓦片地图会造成双数据源不同步。
|
||
|
||
**Phase 5,落地代码——靠 smart_edit 把规格变成模板里的真实代码。** 前面 GDD、资产、tilemap 产的都是"规格和素材",真正把游戏代码写进模板文件,靠的是 agent 反复调 `smart_edit`(注册名就叫 edit)。它的**三级匹配**很能说明问题:精确字面替换 → 柔性匹配(逐行 trim 后比对、自动套用目标缩进)→ 正则匹配(把 token 用 `\s*` 串起来容忍空白差异);三级都不命中时,还会拿 instruction 和原始错误**喂给 LLM 重算一遍 search/replace 再试**。**这套三级匹配加 LLM 自纠错,完全是为了对抗便宜模型给出的 `old_string` 经常对不上(空白、缩进、转义不一致)**——这是"改源不改包、按 GDD 实现每个文件"这套范式能跑通的工程保障。
|
||
|
||
**把这六个相位串起来看,OpenGame 的核心洞察就清楚了:它不靠图编排,靠的是"预建模板 + archetype 路由 + GDD 把任务结构化成填空题 + system-reminder 单线接力 + 工具内置降级与自纠错"。生成质量不是来自强模型自由发挥,而是来自把开放问题收敛成填空题。** 不过这条 system-reminder 单线接力是它的软肋:它靠"DO NOT STOP"这种口头督促来推进相位,**便宜模型很容易在中途断流**。这恰恰反衬出我们用 SAA 图固定相位的价值——图的边不会"忘了继续"。
|
||
|
||
### 2.7 它的三大支柱:经验进化、专训模型、VLM 验收——以及论文与代码的落差
|
||
|
||
OpenGame 论文卖的是三大支柱,但深读源码后必须诚实区分**哪些是真代码、哪些只是 README 宣称**。这个区分是本档最重要的"防误判"产出——把论文当代码现状,会严重高估它、也会错配我们的补强方向。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph 真["✓ 真代码(仓里能跑)"]
|
||
GS["Game Skill 经验自进化<br/>= 真护城河<br/>纯本地 JSON · 零向量 · 零 embedding"]
|
||
end
|
||
subgraph 半["⚠ 只在 README / 论文"]
|
||
GC["GameCoder-27B 专训模型<br/>权重/训练码/数据都不在仓<br/>实测默认接 claude-opus-4.6"]
|
||
VB["OpenGame-Bench 三轴 VLM 验收<br/>grep 零命中,只留<br/>'will be released soon'"]
|
||
end
|
||
GS -. "真实验收只到 build + test<br/>不验证可玩性" .-> 真相["仓里真实的『验收』<br/>= driver subtype + build/test"]
|
||
半 -.-> 真相
|
||
style GS fill:#a9dfbf
|
||
style GC fill:#f9e79f
|
||
style VB fill:#f9e79f
|
||
```
|
||
|
||
**第一支柱,Game Skill 经验自进化——这是仓里真正能跑、也是真正的护城河。** 它由两套同构的离线进化机制组成,两者都遵循同一个闭环:**完成一个任务 → 抽取经验 → 去具体化 → 沉淀回持久库 → 下次先查库命中复用 → 重复达到阈值再升格成可执行规则**。而且都做成"LLM 优先 + 规则兜底"的双轨,库本身是纯本地 JSON——**零向量、零 embedding**(向量 / embedding 指把文本转成向量做相似度检索的 RAG 技术;它一概不用)。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
Task["完成一个任务"] --> Extract["抽取经验"]
|
||
Extract --> Generalize["去具体化<br/>(角色名→Player,硬编码值→config)"]
|
||
Generalize --> Store["沉淀回本地 JSON 库"]
|
||
Store --> Hit{"下次先查库"}
|
||
Hit -->|命中| Reuse["复用(整个 family / 已验证 fix)<br/>每次命中省一次 LLM 调用"]
|
||
Hit -->|未命中| Novel["LLM 兜底:诊断新错 / 归纳新模板"]
|
||
Reuse --> Count["重复计数"]
|
||
Novel --> Count
|
||
Count -->|"达阈值(如重复3次)"| Promote["升格成可执行规则<br/>救火 → 免疫"]
|
||
Promote --> Store
|
||
style Reuse fill:#a9dfbf
|
||
style Promote fill:#f9e79f
|
||
```
|
||
|
||
这套机制有两个具体实现:
|
||
|
||
- **Template Skill(模板技能)** 从一个 game-agnostic(与具体游戏无关)的 Phaser 元模板 M0 出发,每完成一个项目跑五段流水线:**Collector** 读文件树、**Classifier** 用 LLM 加启发式判物理 regime(注意它是"library-aware"的,会把库里已有家族的物理画像塞进 prompt,让 LLM 判断新项目是命中旧 archetype 还是新物种,而 archetype 是 LLM 自创的 snake_case 物理标签,不是预设枚举)、**Extractor** 纯规则抽类继承树和 hook、**Abstractor** 用 LLM 把具体代码泛化成模板(角色名→Player、硬编码值→config 引用,并给每个文件打 role:base_class 是 KEEP 不可改、copy_template 是待复制改)、**Merger** 决定建新家族还是并入旧家族。命中复用的匹配键是**物理三元组(重力 / 视角 / 移动)加 archetype 名,而不是文本相似度**;复用单位是整个 family(家族);还有个 stability 信号 = min(1, 贡献项目数 / 5),五个项目贡献过就算满稳定。**所以这套"经验记忆"本质上是 case-based reasoning(基于案例的推理),不是 RAG。**
|
||
|
||
- **Debug Skill(调试技能)** 是论文 Algorithm 1 的"REPEAT...UNTIL"实现,也是一本活协议 P。它的数据结构是 `(signature, cause, fix)` 三元组,signature(错误签名)= stage + errorCode + 正则化的 messagePattern + fileContext。协议分两类条目:**reactive**(失败后诊断用)和 **proactive**(执行前预校验用),种子里有 7 条 reactive 加 7 条 proactive 的 Phaser 常见错。它的循环是:先跑 proactive 预校验,然后 build → test,失败就 diagnose(先用 signature 加权打分匹配已知错,errorCode 权重 0.5、messagePattern 0.35、fileContext 0.15,阈值 0.8,命中就直接 applyKnownFix,未命中才走 LLM 诊断)→ repair → 重跑同 stage 验证 → 记录结果。**进化最实的一环是:reactive 的事后修复在重复出现 3 次后,会被自动升格成 proactive 的事前预校验规则——经验从"救火"升级成"免疫"。而且只有跑通验证的修复才进库,这是它唯一的质量门。**
|
||
|
||
但要诚实:这套自进化"是真的,但很轻"——**只有单调累积、计数强化、阈值升格,没有遗忘、淘汰、冲突消解**;模板冲突用"保留更长文件"这种启发式;规则一旦生成就不回收。更重要的是两个硬缺口:
|
||
|
||
1. **Template Skill 侧完全没有"这个沉淀的骨架真能编译、真可玩"的回验门**,带病的骨架可能直接沉进库;
|
||
2. **Debug Loop 只验证到 build + test 层,完全不验证可玩性。**
|
||
|
||
这两点很关键——它们恰恰是我们的强项能补上的地方(我们有真机九门),§3 会展开。
|
||
|
||
**第二支柱,GameCoder-27B 专训模型——README 宣称,但权重、训练码、数据都不在仓。** 它被描述成一个为游戏定制的 27B 代码模型,三段式训练:游戏引擎语料持续预训练 → 在引擎 API 和 bug-fix 轨迹上 SFT(Supervised Fine-Tuning,监督微调)→ 用真实可玩性当奖励信号的 execution-grounded RL(以执行结果为依据的强化学习)。但仓里只有集成点和文字描述。反过来看,这恰恰证明了**框架被刻意设计成 model-agnostic(与模型无关)**——实测代码里默认接的是 openrouter 上的 `claude-opus-4.6` 而不是 GameCoder,设个 `OPENAI_MODEL` 就能换。**专用模型不是跑通的必要条件,模型这层可以被便宜通用模型替换,质量缺口靠模板约束加 Debug Skill 兜底。**
|
||
|
||
**第三支柱,OpenGame-Bench 三轴 VLM 验收——README 宣称,但代码库里根本不存在。**(VLM = Vision-Language Model,视觉语言模型,指能"看图打分"的模型。)README 把它描述成动态启动生成的游戏、headless 浏览器执行加 VLM judging,沿 **Build Health**(能否构建运行)、**Visual Usability**(画面是否可用)、**Intent Alignment**(是否符合意图)三轴打分,跨 150 个 prompt。但 README 自己写着"evaluation pipeline will be released soon",全仓 grep `puppeteer|playwright|VLM|screenshot|judge` 在源码里零命中。**仓里真实的"验收"只有两层:生成 driver 的 success 仅取 SDK 返回的 subtype,根本不打三轴分;debug-loop 只跑 build + test。** 所谓的 headless 是 Phaser HEADLESS 类型跑在 jsdom 下,canvas 用 node-canvas 的 Image 桩,**不渲染真实像素、无真实浏览器、无 VLM。把 README 当代码现状,会严重误判。**
|
||
|
||
### 2.8 它的执行基座与 MCP:从上游继承的重型沙箱,以及一个被误读的扩展插槽
|
||
|
||
最后补两笔执行环境,它们决定了"复刻 OpenGame 要不要搬这些重家伙"。
|
||
|
||
OpenGame 的 shell 执行是**重型**的:PTY 优先(node-pty 加 @xterm/headless 把 ANSI 输出解析成结构化数据;PTY = 伪终端),拿不到 PTY 就用 child_process 兜底,detached 让命令独占进程组,中止靠对进程组发 SIGTERM 再 200ms 后 SIGKILL,还用 pgrep 回收后台子进程 PID,外加 docker / podman / seatbelt 沙箱和 HITL 白名单。**这是 agent"写代码 → 跑构建 → 看报错"闭环的物理基座,深度绑定 Node 生态。** 它之所以这么重,是因为它的自主循环要让模型自由地反复跑命令;我们走图编排,build 节点职责窄得多,MVP 阶段并不需要这么重。
|
||
|
||
至于 MCP,必须澄清一个常见误读:**OpenGame 自身零内置 MCP server。** 它的 MCP 客户端是从上游完整继承的成熟管线(四种 transport、OAuth 全套、把 MCP tools 经 `mcpToTool` 降维成 Gemini FunctionDeclaration),但 `getMcpServers` 默认是空的——没有任何硬编码的 cocos / figma / playwright server。**MCP 在 OpenGame 里只是一条"用户在 settings 里配什么就连什么"的通用扩展总线,游戏生成能力根本不来自 MCP,而来自内置确定性工具加工程模板。谁要是以为复刻 OpenGame 得复刻一堆 MCP server,就彻底读反了。**
|
||
|
||
---
|
||
|
||
## 3. 落到我们身上:要在 SAA 图上复刻 OpenGame,到底缺什么
|
||
|
||
把 OpenGame 看透之后,落到我们 SAA 配置式生成的现状上,把缺口分成四类来诚实交代:**能直接抄的设计、得换底座重写的、我们其实已有等价物的、以及我们刻意不走所以抄不动也不必抄的。**
|
||
|
||
先说一个贯穿性的范式判断,它决定了"抄"的边界——这条在 §1 已经摆过坐标系,这里把它落到具体取舍:**OpenGame 的 `client.ts`/`turn.ts` 那套主循环,我们不该嫁接进来——硬塞就成了缝合设计。** 务实的态度是:**把 OpenGame 的控制流交给 SAA 图来表达**(我们本来就这么做,而且对卡 80% 成功率门而言,图的确定性比"DO NOT STOP"的口头督促更稳,这是升级不是抄);**把 OpenGame 的工具层、韧性兜底、防脏脚手架当成零件库,原样落进 SAA 节点内部的工具执行环节。**
|
||
|
||
下面是逐项对照表,然后分四类展开。
|
||
|
||
| 能力 | OpenGame 有 | 我们的现状 | 优先级 | 能不能上 SAA 图 |
|
||
|---|---|---|---|---|
|
||
| 物理优先分类 | classify 工具 + 5 archetype + 易错例 prompt | 有 classify 节点,但 archetype 体系 / 物理优先 prompt 待补 | 高 | 直接做成 classify 节点 |
|
||
| GDD 结构化契约 | 6 节硬绑下游 + 三铁律 + 三层规则 | design 节点存在,契约化程度待补 | **最高** | 直接做成 design 节点 |
|
||
| 确定性贴图 | bitmask 自动贴图 + 3×3→7×7 | 无(且引擎是 LittleJS 非 Phaser) | 中 | 纯算法,直接搬 |
|
||
| smart_edit 自纠错 | 三级匹配 + LLM 重算 | gameDefinition(已废)曾弱化文本编辑需求;A-model 写真 src/ 后文本补丁需求回归 | 中 | 落进 modify/repair 节点 |
|
||
| Template Skill 骨架库 | 五段流水线 + family 自进化 | **完全没有** | 高 | 离线进化,SAA 外挂库 |
|
||
| Debug Skill 活协议 | (sig,cause,fix) + 升格规则 | 规划过、MVP 简化 | 高 | diagnose/repair 节点 + checkpoint |
|
||
| 资产流水线 | I2V / 抠图 / 多级回退 / 装配 | 走 mmx-cli | 中 | asset 节点接 mmx |
|
||
| 可玩性验收 | 论文宣称三轴 VLM,**代码未开源** | 机制层=九门真机 CDP(强);语义层=player 软门 M3 截图判(弱) | 机制已领先 · 语义待补强 | 机制已有;语义软门待做厚 |
|
||
| 专训模型 | GameCoder-27B(权重不在仓) | 便宜通用模型 + harness | **不抄** | 路线不同 |
|
||
|
||
> 表中名词补注:**LittleJS** 是我们选定的轻量 H5 游戏引擎(对标 OpenGame 用的 Phaser);**gameDefinition** 是廉价线最初便宜模型友好的结构化中间表示(2026-06-21 判错误路线、已废,现行 = A-model 写真 `src/`);**九门 / 九门 harness** 是我们在真浏览器里跑的九道确定性机制验收门(CDP = Chrome DevTools Protocol,用来程序化驱动真实浏览器);**player 软门** 是用视觉模型 M3 看截图打分的软性检查;**mmx-cli** 是投资人版已拍板的媒体生成命令行工具。
|
||
|
||
### 3.1 第一类:设计可直接抄进 SAA 节点(价值最高)
|
||
|
||
物理优先分类的系统提示(含易错例)加五 archetype 体系,本质就是一个 classify 节点加 JSON 容错解析,可以直接照搬。GDD 的"六节每节映射下游"契约加三铁律加按 archetype 动态拼三层规则,**是 OpenGame 最值钱的产物**——它把开放问题结构化成填空题,这正是我们用便宜模型卡 80% 成功率门最需要的杠杆,做成一个 design 节点,内置规则可以整段移植。确定性 bitmask 贴图是纯算法,与模型无关,直接搬。smart_edit 的三级匹配加 LLM 自纠错对便宜模型尤其必要,务必移植——而且现行廉价线就是 **A-model 直接写真 `src/` 多文件代码**(原先设想的"走 gameDefinition 结构化中间表示弱化纯文本编辑"这条路已于 2026-06-21 判为错误路线、废弃),所以纯文本补丁的需求并未被绕开,反而在 modify/repair 节点里实打实需要这套自纠错。
|
||
|
||
这里有个**范式级前提必须点破**:OpenGame 整条链能跑,根本前提是它有一套预建 Phaser 模板和每个 archetype 的 `template_api.md` hook 清单当"填空靶子"。**Hook Integrity 这条铁律之所以能约束便宜模型,是因为有一份明确的 API 清单让模型不能编造。** 我们要复刻,就必须**先有等价物:一份"LittleJS 增强发行版 + 插件库公开 API 清单"当我们的 `template_api`。** 没有这个,便宜模型一定会编造 API。这一块 OpenGame 抄不来、必须我们自建——而它恰好和创始人 2026-06-17 定的"游戏 = 长生命周期结构化源项目"基座、以及"玩法模板 = 品类框架"的定位是同一个东西。
|
||
|
||
### 3.2 第二类:设计可抄,但得换底座重写
|
||
|
||
Template Skill 和 Debug Skill 是我们当前最大的能力缺口,也是最该补的。
|
||
|
||
**Debug Skill 几乎可以整体移植思想**——验证驱动的 REPEAT 循环加 `(signature, cause, fix)` JSON 账本加分组阈值升格,正好对应 SAA 裸图里一个 diagnose 节点加 repair 节点加 checkpoint(检查点)持久化;签名匹配是纯算法零 LLM,便宜模型只在"诊断 novel 错"和"归纳规则"两处兜底调用,**每次命中都省一次 LLM 调用,对便宜模型尤其划算(把高频错变成确定性查表)。** 种子协议里的 Phaser 错误码要换成我们自己的 LittleJS 运行时和九门错误码,但结构原样可用。
|
||
|
||
**Template Skill 可以抄它的范式**(结构化源项目模板的 KEEP/copy/hook 分层、经验计数、离线蒸馏),但实现得整体重写两处:它的物理信号正则和 hook 命名约定死绑了 Phaser 和 OpenGame 自家模板的类名,我们是 LittleJS 加 A-model 写真 `src/` 多文件工程,得换成"对 A-model 的 src/ 模块骨架做 archetype 分类与抽取";更重要的是,**它的 Abstractor 泛化对便宜模型是质量重灾区,而原版入库前没有任何回验门,照抄会把坏骨架沉进库——我们必须给它加一道"入库前过九门 / 可构建校验"的质量门,这恰恰是我们的强项**(把我们最硬的东西用在它最弱的地方)。另外要预警一个原版的硬缺口:这套进化没有遗忘、淘汰、冲突消解,也没有向量检索,family 一多线性扫加物理三元组离散匹配会退化;等品类规模上来,我们可能需要补一层真正的检索(上 embedding 或按 archetype / src 模块特征索引)。
|
||
|
||
**资产流水线属于这一类里"换替代方案"的**:OpenGame 的 I2V 抽帧、T2V 抽音轨、抠图后端依赖视频模型加 ffmpeg,便宜文生图模型替不了动画质量——我们的 asset 节点接投资人版已经拍板的 mmx-cli 即可,大幅降级的部分(静态帧 + 程序音)也照 OpenGame 的多级回退思路兜底。
|
||
|
||
### 3.3 第三类:我们其实已有等价物、甚至更强
|
||
|
||
OpenGame-Bench 那套三轴 VLM 验收,有个必须点破的事实:**它在开源代码里根本不存在**——README 描述得很全(headless 浏览器跑生成的游戏、VLM 沿 Build Health / Visual Usability / Intent Alignment 三轴打分),但全仓 grep `VLM|screenshot|judge` 零命中,只留一句"will be released soon"。所以单比已经开源出来的东西,我们确实更硬:我们有真机 CDP 真玩的九门加 M3 截图判,OpenGame 放出来的只有 build + test、并不验证可玩性。
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph 三轴["OpenGame 论文宣称的三轴(代码未开源)"]
|
||
BH["Build Health<br/>能不能构建运行"]
|
||
VU["Visual Usability<br/>好不好看"]
|
||
IA["Intent Alignment<br/>是不是用户要的那个游戏"]
|
||
end
|
||
BH -->|"对应 · 我们确定性领先"| NG["九门 harness<br/>真机 CDP · 确定性机制判定<br/>装载/帧/输入/终态"]
|
||
VU -->|"对应 · 我们偏弱"| PS["player 软门<br/>M3 截图判 · 软 · 跑便宜模型 · 不成体系"]
|
||
IA -->|"对应 · 我们偏弱"| PS
|
||
NG -. "判不了好不好看 / 对不对" .-> 边界["别把九门当 VLM 等价物"]
|
||
PS --> 动作["正确动作:把 player 软门做厚<br/>独立交叉校验 + 离线 bench<br/>蓝本 = OpenGame 论文三轴"]
|
||
style NG fill:#a9dfbf
|
||
style PS fill:#f9e79f
|
||
style 边界 fill:#f5b7b1
|
||
```
|
||
|
||
但这里要分清两层、别就此自满——这也正是不该把"九门"简单当成 VLM Bench 等价物的原因。九门判的是**机制**:能不能装载、跑不跑帧、响不响应输入、到不到终态,全是确定性的,这一层我们确定性地领先,没有疑问。可 VLM 的另外两轴——Visual Usability(好不好看)、Intent Alignment(是不是用户要的那个游戏)——**九门根本判不了**;这两件事在我们这边对应的不是九门,而是 **player 软门(M3 视觉模型看截图)**,而 player 软门是软的、跑便宜模型、不成体系,这恰恰是我们的弱项而非强项。
|
||
|
||
所以正确的动作**不是**"把九门结果套个三轴外壳就交差"(九门产不出"好不好看""对不对"这两轴),而是**把 player 软门那条做厚**:让"是不是要的游戏、好不好看"有更系统、可复现的判定——独立于生成方的交叉校验,甚至一个离线 bench。OpenGame 论文那套三轴设计,正是这一层值得我们抄的蓝本,即便它代码并没放出来。
|
||
|
||
### 3.4 第四类:刻意不走、抄不动也不必抄
|
||
|
||
**GameCoder-27B 专训模型**——权重、训练数据、RL 代码都不在仓,而且我们的路线明确是"便宜通用模型 + harness 兜底",不自训模型。OpenGame 框架自身的 model-agnostic 设计反而印证了我们这条路走得通:专用模型不是跑通的必要条件。这一项无需复刻。
|
||
|
||
**OpenGame 的命令式自主主循环、重型 PTY 沙箱、@google/genai 的 MCP 适配层**,都是 Node/TS 生态产物,且与我们 SAA 图的控制流范式正交。主循环用 SAA 图替代;PTY 沙箱如果将来需要,Java 侧得用 ProcessBuilder/pty4j 自建等价物(工作量不小,但 MVP 阶段我们的 build 节点未必需要这么重);MCP 走 SAA v1.1.2.2 自带的 MCP 支持,别试图移植那套 JS 适配。
|
||
|
||
### 3.5 我们的 Phase 0–4 落地路线:从对照分析到带消融杠杆的执行序列(创始人 2026-06-22 历史回收判定捡回)
|
||
|
||
上面 §3.1–§3.4 把"OpenGame 哪些设计值得抄、怎么落进 SAA 节点"按价值分了四类,那是**对照分析**。2026-06-22 把另一份决策记录(`git show 8ea97234:docs/plans/2026-06-20-关闭九门判定-全面参考OpenGame-决策与Phase0-4.md`,创始人当天拍板、当天把 gamedef 做到 91.7%)的 Phase 路线回收进来,补的是分析之外的另一半——**一条有编号、有消融杠杆量化、有达标 flip 条件的执行序列**。两份口径不同:对照档回答"抄什么",这条路线回答"按什么顺序抄、每步能抬多少、抬到什么程度就切默认"。
|
||
|
||
这条路线的**起跑线**,是验收口径的一次收窄,得先讲清,否则后面的 Phase 没有立足点:生成环的硬门已从"九门全过"收窄成"只认五道客观健康门 A–E"(A_boot/B_uncaught/C_frame/D_render/E_live),G_input/H_progress/I_control 三道 driver 依赖门降为不否决生成的参考门,F_wiring 移出客观硬门、改由 VLM 看截图判其"真用引擎/有特效"的语义。这一收窄是 gamedef 从 all-9 口径下约 50% 做到 **91.7%** 的直接原因之一(细节见 [验收门-W-G1 §2.4](验收门.md))。把九门里"靠 driver 才判得了"的那几道暂时摘出生成环的否决权之后,Phase 路线要补的就是"用别的、更对的东西把那几道门的语义重新接回来"——这正是下面几个 Phase 的主线。(现行口径注:"收窄 A–E"已于 2026-07-02 随质量轨裁定历史化,现行验收 = driven 九门全量;本段只作这条路线当时的起跑线理解。)
|
||
|
||
各 Phase 与它们各自的消融杠杆(数字是 06-20 当天实测的 Build-Health 增量贡献):
|
||
|
||
- **Phase 2 · 模板-First + hook,杠杆最大(约 +10.1 BH)。** 给每个 archetype 预建一套**已验证过的 gamedef 骨架**,再让便宜模型在骨架上做 hook 覆写,而不是从零发明结构。这与 §3.1 那条"GDD 契约 + template_api 是最高价值缺口"是同一件事的执行版——预建骨架就是"填空靶子",hook 清单就是约束便宜模型不编造 API 的那份 `template_api`。它单点贡献最大,所以排在最前。
|
||
- **Phase 3 · 活调试协议 / 离线 linter(约 +6.9)。** 把生成中反复踩的坑沉淀进一个**版本化的匹配库**,在真玩之前先跑一道静态门把已知错挡掉、并回灌修复。这就是 §3.2 那条 Debug Skill 的落地——(签名,原因,修复)三元组加分组阈值升格,签名匹配纯算法零 LLM。它排第二,因为有了 Phase 2 的骨架打底,剩下的错才收敛到"可被 linter 模式化捕获"的程度。
|
||
- **模板族复用(约 +5.8)。** 对应 §3.2 的 Template Skill:把完成过的项目按物理三元组泛化成可复用的家族骨架,命中即复用整个家族。它的增量来自"同品类第二款起不必重走 Phase 2 的从头预建"。
|
||
- **Phase 4 · build-health + VLM 验证替换 driver 判定,并定 flip 达标条件。** 这一步把起跑线收窄时摘出去的 driver 门语义**正式接回来**——但不是接回 driver,而是接回"客观 build-health + VLM 看截图"两条:能不能跑用客观门 A–E 判,好不好看 / 是不是要的那个游戏用 VLM 判(对应 §3.3"player 软门做厚"和论文三轴里的 Visual Usability / Intent Alignment)。配套自修复封顶 **T=3**(同一道门最多自动修三次),达标后才 flip 成默认。(现行口径注:driver 门语义已实际接回——2026-07-02 质量轨裁定后现行验收即 driven 九门全量,此 Phase 的"接回"目标已成事实。)
|
||
|
||
**flip 达标条件(这是 Phase 路线区别于纯分析的关键)**:任何新生成口径 / 新门在统一口径下成功率真达 80% 门,才把它切成默认、并把"失败即拦截"的门翻开。在此之前默认旁路、只观测、可回退对比,绝不一上来就改放行行为。(注:原文针对的「gamedef 路切默认产线、二分收敛退役 factory 路」已随 2026-06-21 gameDefinition 废弃而 moot——现行是 A-model 写真 src/、无 factory/gamedef 双轨、也无 cutover;此处保留的是通用 flip 纪律:新门默认旁路只观测、达标再 flip。)这条 flip 纪律与生成引擎 README §6 的达标门同源,落地时挂同一个 80% 达标判据,不各立一套。
|
||
|
||
> 口径归属:这条 Phase 路线与起跑线的口径收窄,蒸馏权威源在 `.agents/skills/saa-graph-orchestration.md` §3.5 与上述决策 plan;"统一的 to-do、阶段序列、达标门"现以[生成引擎 README](README.md) §6 为单一 SoT(原 `agent-specs/生成主线架构演进路线.md` 已降留痕 SUPERSEDED)。本节把消融杠杆量化(+10.1/+6.9/+5.8)与 flip 达标条件回填进对照档,是因为这几个数字决定了"先抄哪一层最划算",而它们此前只躺在那份决策记录里、没进现行架构档。
|
||
|
||
---
|
||
|
||
## 4. 收口结论
|
||
|
||
我们和 OpenGame 走的是两条路,但**终点一致:都靠"把开放式游戏生成收敛成受控填空"来让不够强的模型也能稳定产出。** OpenGame 用命令式 agent 循环加 system-reminder 接力来收敛,我们用 SAA 图来收敛——**在这一点上我们不是落后,而是用了更确定的范式。**
|
||
|
||
真正的差距集中在三处——这三处正是 README §5 那一页结论的来源:
|
||
|
||
1. **生成约束的厚度**(物理优先分类 + GDD 契约 + template_api 清单,这是设计可直接抄的最高价值项,且与"结构化源项目"基座天然契合);
|
||
2. **经验复利层**(Template/Debug Skill,我们几乎从零,但设计可抄、且能用九门当原版缺失的质量门);
|
||
3. **资产线**(接 mmx 替代)。
|
||
|
||
至于 OpenGame 论文最响的两个卖点,得分开说。**专训 GameCoder-27B 我们刻意不走**——走便宜通用模型加 harness 兜底,而它自己框架的 model-agnostic 设计反而证明了专训模型不是跑通的必需。**VLM Bench 则要说准:它的三轴验收在开源代码里其实没放出来、只在论文里**,所以单比已开源的,我们的真机九门已经更硬;但别把"九门"当成 VLM 的等价物——九门更强的只是"能不能跑"这一层(Build Health),而 VLM 的"是不是要的游戏、好不好看"那两轴九门判不了,对应的是我们偏弱的 player 软门,那是待补强的缺口,不是已经赢了的项。
|
||
|
||
**最该立刻动手的,按优先级是:**
|
||
|
||
1. 把 **template_api**(LittleJS 插件库公开 API 清单)和 **GDD 契约**补上,这是一切约束的靶子和最高价值杠杆;
|
||
2. 把 **Debug Skill** 的"签名 → 已验证修复 → 重复升格"活协议落成 diagnose/repair 节点加 checkpoint;
|
||
3. 把 **Template Skill** 的骨架进化库按 A-model 写真 `src/` 重写,并强制加入库前过九门的质量门。
|
||
|
||
这三件做完,我们这条 SAA 配置式流水线就补齐了 OpenGame 真正值钱的那部分,而且是用我们自己更确定、更可验收的方式补齐的。
|
||
|
||
---
|
||
|
||
## 5. 源档与去向导航
|
||
|
||
| 去向 | 找什么 |
|
||
|---|---|
|
||
| [生成引擎 README](README.md) §6 | **统一演进路线的现行落点**:本档照出的三处缺口已被 README §6 吸收并 A-model 化重写,含阶段序列、关键路径、达标门——要"做什么"去那里拿。(旧「生成主线架构演进路线」已删,当时演进推理在 git) |
|
||
| [生成引擎 README](README.md) | 生成引擎子树主文档,§5 是本档的一页结论版;§3 讲"游戏 = 长生命周期源项目、LLM as 工作室"的范式原则 |
|
||
| [生成运行时架构](agentic运行时架构图说.md) | 我方 16 节点拓扑图、六条不变量、split-brain 两条治理铁律、落地接入坑清单 |
|
||
| `github.com/leigest519/OpenGame` | OpenGame 真源码本体(本档所有结论的锚点,论文 arXiv 2604.18394) |
|
||
|
||
> **纪律**:本档是 OpenGame 外部标杆的**深读参考**——回答"它的内部机理"和"逐项缺口的来龙去脉"。"我们要做什么"的统一行动项不在这里,在[生成引擎 README](README.md) §6(统一演进路线现行落点);两者职责不同,不互相重复。当行动项与本档分析冲突时,以 README §6 与运行时 SoT 的最新裁定为准。
|
||
|
||
---
|
||
|
||
> **验证状态**:本文档为架构对照参考文档,由一份已被《生成主线架构演进路线》吸收的源档(`2026-06-20-OpenGame对照分析与复刻缺口.md`,status 为"分析 · reference",该档由 5 个 agent 分片深读 clone 下来的 OpenGame 真源码后综合)重写而成,未改任何代码。承重硬事实——OpenGame = Gemini-CLI→Qwen-Code 二次 fork 的三处铁证、四原子工具 + 六阶段 SOP、三铁律(Config-First/Zero Custom Code/Hook Integrity)、`MAX_TURNS=100`、Debug Skill 加权阈值(0.5/0.35/0.15,阈值 0.8)与重复 3 次升格、stability=min(1,项目数/5)、三大支柱中仅 Game Skill 是真代码而 GameCoder-27B 与三轴 VLM Bench 只在 README、我方 SAA 16 节点 / 九门 / 80% 门 / gamedef 双证、三处复刻缺口与四类取舍——均沿用源档已抽查属实的结论;品牌已统一为"绘境AI"。
|