lili 95d34c03f5 docs(生成引擎): gamedef=废弃错误路线 reframe — 8 banner + README §3-6(opus 代理)
创始人:gamedef 已删除/失效/错误路线。opus 代理 reframe(我核验 banner+README §3-6):
- 8 个 🚧 banner:「gameDefinition→src 终态迁移(plan 2026-06-18-001)」→「gameDefinition
  已废(错误路线),现行=A-model 写真 src/;tier2 建设中」
- README(生成引擎):§3.2 终态硬约束改「gameDefinition 是已废错误路线」+ A-model 取代;
  §4 第三类「factory/gamedef 双轨债」标随 gamedef 废弃消解;§6 cutover 里程碑门标作废
  (✗ cutover 已废 → A-model 单线无双轨可切);线A/线B 能力工作对 A-model 路保留
- OpenGame/WG1/验收门/架构README banner 同改
门:全仓死链 0。(broader/沙箱档残留下一 pass)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-25 01:10:48 -07:00

39 KiB
Raw Blame History

W-G1 基准 · 20 款经典轻游戏靶集与 4 类能力缺口

🚧 架构演进中 —— 廉价线 gameDefinition 已废(错误路线),现行 = A-model 写真 src/;tier2 富游戏自治轨建设中(0 号 spike accept)。文中结论可能随推进变化,以子树 README / 运行时 SoT agentic运行时架构图说 与最新裁定为准。

这是什么:绘境AI 生成引擎用来回答一个很实在的问题的设计文档——"便宜的通用模型 + 我们当前这套引擎和插件库,到底能造出什么样的游戏、又造不出什么"。它把 20 款人人都玩过的经典轻游戏铺成一张靶集,既验证生成管线确实能端到端跑通,又拿这些游戏去压测能力上限、把引擎和插件库的短板逼出来。 给谁看:负责生成主线的工程师、想知道"哪些品类现在就能放量做、哪些还得先补能力"的产品与创始人,以及做技术尽调时想看清"生成能力真实边界在哪"的架构评审。 怎么读:先读 §1 那张图,搞清楚"靶集是什么、为什么要这么排";想看每款游戏的覆盖判定读 §3 那张大表;想看四类能力缺口的诊断与证据读 §4;想看怎么分批跑读 §5。

W-G1 是什么:它是"便宜模型造游戏"这条路线第一批真刀真枪的实测靶集(W = Wave 批次,G1 = Game 第一批)。这份文档是它的策展层主档,把一份调研产出整理成给人读的全景;它本身未改任何运行时代码,是一次只读的能力盘点。

生成引擎主文档(README.md)讲的是"一句话怎么变成一款游戏"那条技术主线,验收门文档(验收门.md)讲的是"那条主线怎么对真实用户安全开闸"。本文讲的是第三件事:开闸之后,我们到底拿什么去喂这台机器、又该期待它产出什么质量。20 款经典游戏就是那批"考题",它们的覆盖判定和暴露的缺口,直接决定了批量放量时该先做哪些品类、又该先补哪层能力。

⚠️ 实测后修订(2026-06-14 / 06-15 放量已跑完,务必先读)

本档 §3 / §4 的覆盖判定与"4 类门面缺口"是一份 实测前预判;放量实测(scale-20,14 款真跑)已把其中的门面缺口判断几乎全部证伪。 现行结论以 .agents/skills/cheap-model-game-generation.md §8§9 与 scale-20 短板量化报告 为准。三条要点:

  1. 4 类预判门面缺口几乎全部证伪:便宜模型(flash 这档)自带或自写 CCD(子步 swept,见 asteroids/multiball)、文本 HUD、网格状态机(井字棋胜负+AI、扫雷洪泛)、match-finding、手势——均非"造不出"。文本 / 网格门面价值仅剩"省 token / 一致性",而非"造不出"。
  2. 真实的唯一 L0 门面缺口 = 宿主键盘桥(getInput 早期不透 keydown/keyup,导致 2048/Tetris/Asteroids 三款键盘游戏集体挂)——已修(commit d754b71 fix(host): attachInput 补 keydown/keyup window 桥接,2026-06-14)。
  3. 下文 §1 图、§4 诊断、§5.4 的"补门面优先级预判(文本>网格>swipe>CCD)"均属预判,已被实测推翻——保留它们是为了让读者看清"预判 vs 实测"的对照,不要再据此排门面优先级。失败的真实归因是实例 bug / driver-coverage(harness 适配 driver 不够)/ 宿主键盘桥,而非模型能力(scale-20 闭口:0 个模型造不出 / 0 个 3D 硬界)。

1. 一句话与一张图:W-G1 靶集是什么、为什么这么排

W-G1 靶集的本质,是用 20 款机制各异的经典轻游戏,去给"便宜模型 + 当前引擎/插件库"这套组合做一次能力体检。这里要先把两个判断说清楚,它们决定了整份文档怎么读:

  • 靶集不是为了"做出 20 款游戏",而是为了"摸清能力边界"。 选这 20 款,是因为它们刚好铺满了轻游戏的机制谱系——从最简单的回合制点击(井字棋),到最难的连续物理与程序化生成(小行星、多球弹球)。把它们一字排开,哪一档开始崩、崩在什么能力上,就一目了然了。
  • 便宜模型是这条路线的成本前提,不是临时凑合。 这里的"便宜模型"特指 M3 / M2.7 / DS-V4 这一类低成本通用模型(M3 = MiniMax 的一档模型,DS-V4 = DeepSeek V4 系列;它们都不是为游戏代码专门训练的)。整条生成主线的判断就是用便宜模型打底、靠模板约束和验收门补质量缺口(详见生成引擎主文档 §1),所以体检也必须用便宜模型来做,而不是用强模型。

把这 20 款按"当前能不能造得出"分档,得到的全景是这样的:

flowchart TB
  subgraph 齐备["✅ 能力面齐备 · 约 12 款 · 可立即冒烟"]
    direction LR
    E1["井字棋 / Pong / Simon<br/>打地鼠 / 记忆翻牌"]
    E2["Flappy / 打砖块 / 太空侵略者<br/>Doodle Jump / 跑酷"]
    E3["扫雷 / 见缝插针 / 节奏点击"]
  end
  subgraph 半缺["🟡 半缺口 · 底层有原语但无门面 · agent 须自补层"]
    direction LR
    H1["2048 / 贪吃蛇<br/>(网格 + 文本 HUD)"]
    H2["Tetris / Match-3<br/>(网格状态机上限)"]
    H3["愤怒小鸟<br/>(拖拽手势)"]
  end
  subgraph 硬边界["❌ 真缺口 · 当前造不出 · 已主动规避"]
    X1["高速球穿透类<br/>(连续碰撞 CCD 缺失)"]
    X2["完整 Pacman 鬼 AI<br/>(寻路 A* 缺失 · 未入选)"]
  end
  齐备 -->|"批次1 验管线打通"| 结论["20 款 = 一张能力体检表<br/>暴露 4 类短板"]
  半缺 -->|"批次2/3 量化自补出错率"| 结论
  硬边界 -->|"定死引擎硬边界"| 结论

读这张图,记住三句话就够了。第一,约 12 款(井字棋、2048、Flappy、打砖块、贪吃蛇、Pong、扫雷、Simon、Snake 类……)当前插件和引擎已经直接覆盖,便宜模型在现有能力面上应该就能产出可玩件——这批先拿来做冒烟,验证管线通不通。第二,缺口集中在 4 类能力上,它们决定了 Tetris、小行星、高速打砖块、消消乐这几款难游戏的产出质量,是本基准最核心的产出。第三,真正"造不出"的硬边界只有两条——高速小目标的连续碰撞、以及敌人智能寻路,后者已经在选题时主动规避掉了。

那 4 类能力缺口,是整份文档的重点,先在这里列出名字(§4 逐个展开):

flowchart LR
  subgraph G["4 类能力缺口(本基准核心产出)"]
    direction TB
    C1["① 文本 / 分数 HUD 渲染<br/>无插件门面<br/>(最高频缺口)"]
    C2["② 网格 / 棋盘状态抽象<br/>无 grid / tilemap 门面"]
    C3["③ 连续碰撞 CCD<br/>collision 仅离散 MTV<br/>(真缺口)"]
    C4["④ 通用状态机 FSM<br/>gamefeel 仅 3 个特化计时器"]
  end
  C1 --> R["决定 Tetris / 小行星<br/>高速打砖块 / Match-3<br/>的产出质量"]
  C2 --> R
  C3 --> R
  C4 --> R

这里要钉死一个最关键的判断,它纠正了一个直觉误区:真正的短板不在于"造不出来",而在于"agent 每次都要自己重新补一层"。上面的 ①②④ 其实引擎或插件库里都有底层原语,或者本就属于"agent 写码生成"的范畴(比如引擎的 LJS.drawText 文本绘制函数是存在的,只是没被插件包装出来;网格状态本就该由 agent 自己管)。但"没有插件门面"意味着每一款游戏的便宜模型都得把这个轮子重造一遍——结果就是一致性差、token 贵、容易出错。所以本基准给出的核心建议是:W-G1 实测之后,把高频缺口(文本 HUD、网格)补成插件门面,而不是放任 20 个 prompt 各自硬写。

实测修订(2026-06-14): 上一段的"agent 每次都要重补一层、容易出错"是 实测前预判。放量实证显示:flash 这档自写文本 HUD / 网格状态机 / 子步 swept CCD 均正确,补门面的价值只剩"省 token / 一致性",而非"造不出来"。即"高频缺口补成插件门面"应理解为优化项而非必备项——详见档首"实测后修订"横幅。

这里反复出现的两个词先解释清楚。门面(façade):指插件对外暴露的那层公开 API——便宜模型只能用这层 API,看不到也碰不到引擎底层。生成域:指那些约定让 agent 自己写码实现、不归插件管的东西(玩法逻辑、美术、关卡、UI)。一个能力到底"算不算缺口",判据就是它需要的底层原语有没有门面或引擎透传面兜底(详见 §2.4)。


2. 事实基:当前能力面到底有什么(都带证据锚点)

要判断 20 款游戏能不能造出来,前提是先把"当前到底有什么能力"盘点清楚。这份盘点有一条很硬的纪律:只认源码实际导出的东西,不认"我以为有"。具体来说,覆盖判定的依据是三处源码——插件手写的 API 门面声明(api.d.ts)、插件实际的代码返回面(impl.js),以及宿主把引擎能力透传出来的那个函数(host.js 里的 makeEngineCaps())。下面每一条能力都带 文件:行号 的证据锚点,可逐条复核。

几个专有名词先解释插件库:在 LittleJS 引擎(我们选定的轻量 H5 游戏引擎)之上加的一层能力插件,把碰撞、粒子、物理、手感等做成可复用的 API。透传:引擎本身能力很多,但插件墙只把其中一小部分"透"出来给 agent 用,没透出来的引擎能力就不构成 agent 的"能力词汇"。受控面:一组刻意收窄的底层接口(画布、输入、时钟、随机等),它是"引擎将来可替换"的边界——只要这层接口不变,底层换引擎上层无感。

2.1 插件库实际导出(7 个业务插件 + 1 个埋点插件)

这是 agent 能直接调用的能力主体。每个插件只暴露它"源码里真的会 return 出来"的那些函数:

插件 公开能力(源码实际 return 面) 证据锚点
collision(碰撞) 离散几何相交:圆碰圆 / 圆碰矩形 / 矩形碰矩形;凸多边形 SAT + MTV(SAT = 分离轴定理,判两个凸多边形相不相交;MTV = 最小平移向量,告诉你怎么把它们推开)、射线命中(RayHit)、空间哈希(SpatialHash,用均匀网格做碰撞粗筛) collision/impl.js:268/295/337/395/462/500SpatialHash:112-264;api.d.ts Manifold/RayHit:80/97
physics-lite(轻物理) 离散运动数学:抛体 + 重力、弹簧 / 临界阻尼、带约束移动、限速 / 摩擦 physics-lite/impl.js:104/127/181/194/241/268/286
particles-juice(粒子手感) 粒子发射器、命中停顿(hitStop)、屏幕震动、闪白、缩放脉冲、预设 particles-juice/impl.js:438/504/524/544/562;api.d.ts :204-240
gamefeel(手感) 输入缓冲、郊狼时间(CoyoteTimer)、连击窗(ComboWindow)、11 条 easing 标准缓动曲线(纯函数,经引擎门面) gamefeel/impl.js: InputBuffer:232/CoyoteTimer:319/ComboWindow:390;api.d.ts :108/154/196
audio-music(音频) 音效(blip/thud/chime)、BGM 播放 / 循环 / 停止、强度分层、加载曲目 audio-music/impl.js:438/455/463/467/471/481
palette-post(调色后处理) 调色板映射、HSL 色彩变换、后处理(暗角 / 抖动 / 扫描线) palette-post/impl.js:142/210/238/62/90/392/412
save-progress(存档) KV 持久化:读 / 写 / 删 / 清(命名空间隔离 + 损坏容错 + 单条上限) save-progress/impl.js:219/243/285/294
runtime-probe(取证埋点) 取证记录 / JSONL 导出 / 哈希链校验——非玩法能力,专给 e2e 证据用 runtime-probe/impl.js:330/335/340

郊狼时间(coyote time) 是个游戏手感术语:角色刚离开平台边缘的一小段时间内仍允许起跳,避免"明明踩着了却没跳起来"的挫败感。输入缓冲(input buffer) 则是提前一点点按键也能被记下来、等条件满足时生效。这两个是平台跳跃类游戏的"手感润滑剂"。

2.2 引擎透传真实粒度(createEngineCaps(),只此三面)

除了上面 7 个插件,宿主还从引擎本体直接透出了三面能力。注意:只有这三面——引擎(LittleJS)本身远不止这点(它有文本绘制 drawText、贴图绘制 drawTile、瓦片碰撞、相机等等),但插件墙内只透出这三面,其余引擎能力都不构成 agent 的能力词汇:

锚点说明: 这个能力背书工厂原是 host.js 闭包里的 makeEngineCaps,已被提升为独立可 import 模块 host-dev/engine-caps.jscreateEngineCaps()(搬运·语义零变,见 host.js:188-190 的迁移注与 engine-caps.js:8)。host-dev 与 wanglanmei-ref real 通道共用同一份。下表锚点已指向 engine-caps.js

透传面 真实粒度 证据锚点
particles(粒子) 薄包装引擎的 ParticleEmitter(全参数映射),做了像素↔世界坐标的阻抗换算 engine-caps.js:61-120(new ParticleEmitter:91)
audio.synth(音频合成) 把音效 / 音乐合成为 PCM 样本(只合成不播放,播放层另补) engine-caps.js:122-145(synthSfx:134)
math(数学) lerp 线性插值 / smoothStep 平滑步进 + 11 条等价缓动曲线(POWER/BACK/ELASTIC 族),纯函数 engine-caps.js:51-61 + engine-math.js:56-87

2.3 受控面 6 项(引擎可换边界)

这是最底层的一组接口,定义在 api.d.ts:264-304,是"引擎将来可替换"的边界:getContext2d() 取 2D 画布、onFrame() 帧回调、getInput() 归一化输入、getAudioContext() 取音频上下文、time 受控时钟、random 确定性随机。

这里有一个对触屏轻游戏特别要命的事实必须说清:输入只有 5 类原始事件(api.d.ts:218,无非是 pointer 的三态和 key 的两态),没有手势识别。也就是说,滑动(swipe)和拖拽(drag)这类手势,引擎不给现成的——agent 必须在生成域里自己把一串 pointer 序列(按下→移动→抬起)缓存起来、算出方向和距离来合成手势。这正是后面 2048、消消乐、愤怒小鸟会暴露的一处半缺口(§4)。

2.4 一条决定"什么算覆盖"的纲领

最后这条是判定的总纲,直接决定了 §3 那张表里每一格的 / 🟡 / 怎么打。技术决策里有一条终裁(tech-decisions.md:38):玩法、美术、关卡、UI = agent 写码的生成域;插件 = 能力 API。由此推出覆盖判定的口径:

  • 某个机制所需的能力,只要有插件门面或引擎透传面兜底,就算覆盖;
  • 纯玩法逻辑(回合制、计分、棋盘状态机)是 agent 自写域,不算缺口——
  • 除非它需要的底层原语(比如文本渲染、网格抽象)根本没有门面。那才是真正要补的地方。

换句话说:本基准从来不把"agent 要写代码"当缺口(那本就是 agent 的活),它只把"agent 想写代码却连底层原语都没有门面可调"当缺口。


3. 20 款经典轻游戏靶集表

下面这张表是靶集的主体。每一款游戏给出它的核心机制、所需能力、当前覆盖判定、工程难度档,以及一句话生成种子(就是喂给便宜模型的那句话)。

覆盖判定的三档含义是: 表示插件或引擎透传面已覆盖;🟡 表示引擎有底层原语、或属生成域但没有门面(agent 得自己补层,如果高频就建议补门面); 表示真缺口(没门面、且 agent 自写成本高 / 易错)。难度档则是: = 单机制 + 静态或网格; = 2-3 机制叠加 + 实时; = 多机制 + 连续物理 / 程序化 / 高频碰撞。

# 游戏 核心机制 当前覆盖判定 难度 一句话生成种子
1 井字棋 3×3 落子 / 胜负判定 🟡 网格 + 文本🟡、输入、AI = 纯逻辑 3×3 棋盘点击落子 X,AI 落 O,三连判胜
2 2048 网格滑动合并 / 数字 🟡 网格 + 文本🟡(高频缺口)、swipe = 合成、合并 = 纯逻辑 4×4 数字方块,滑动合并同值,生成新块,显分
3 贪吃蛇 网格移动 / 自增长 / 自碰撞 🟡 网格 = agent 自管、输入、碰撞 = 网格逻辑、计分文本🟡 蛇沿网格吃食物变长,撞墙 / 撞自己结束
4 Flappy Bird 重力跳跃 / 管道避障 / 无尽 physics 抛体 :104、collision aabbVsAabb:337、输入;文本🟡 点击让小鸟上跳,重力下落,穿随机高度管道
5 打砖块 Breakout 弹球反弹 / 挡板 / 砖块网格 collision circleVsAabb:295 + MTV 反弹、physics 限速;高速球🟡 挡板接弹球击碎砖阵,球随挡板位置改反弹角
6 Pong 双挡板 / 弹球 / 简单 AI collision / physics / 输入;AI = 纯逻辑 左玩家右 AI 各控挡板,漏球对方得分
7 扫雷 网格揭示 / 数字提示 / 标记 🟡 网格 + 文本🟡、输入、洪水填充 = 纯逻辑 点击揭示显周围雷数,右键标记,踩雷结束
8 Simon 记忆 序列记忆 / 颜色按钮 / 渐进 audio playSfx:481、gamefeel 计时、输入;序列 = 纯逻辑 四色按钮按序闪烁播音,玩家复现,逐轮加长
9 记忆翻牌 翻牌配对 / 网格 easing :205 / 输入;网格🟡、图案 = agent 绘 牌面朝下,翻两张配对,全配对获胜
10 太空侵略者 波次敌阵 / 射击 / 碰撞 collision AABB + SpatialHash :112、particles 爆炸;文本🟡 炮台左右移动射击,敌阵整体平移下压,清屏过关
11 俄罗斯方块 Tetris 下落方块 / 网格堆叠 / 消行 🟡 网格堆叠 = agent 自管(高频痛点)、输入、文本🟡 七种方块下落,旋转堆叠,满行消除,逐级加速
12 小行星 Asteroids 惯性飞船 / 任意角度 / 程序化碎裂 collision satVsPolygon:395 + RayHit、physics applyFriction:286;高速子弹 CCD 飞船惯性漂移射击,大陨石击中裂小块,屏幕环绕
13 消消乐 Match-3 网格交换 / 三连消除 / 下落填充 🟡 网格 + 文本🟡(高频痛点)、swipe = 合成、消除 = 逻辑、easing 8×8 宝石网格,交换凑三连消除,上方填充连锁
14 跳跃者 Doodle Jump 垂直无尽 / 平台跳 / 重力 physics 抛体 :104、collision AABB、coyote :319;相机 = 受控面、文本🟡 持续上跳踩平台,左右移动,平台程序化生成
15 愤怒小鸟(简版) 抛射弹道 / 拖拽蓄力 / 碰撞倒塌 🟡 physics 抛体 / 弹簧、collision MTV;拖拽 = agent 合成 pointer 链 拖拽弹弓蓄力发射,抛物线击中结构使其倒塌
16 跑酷 Runner 横向无尽 / 跳跃滑铲 / 障碍 physics 跳、collision AABB、buffer :232 + coyote;swipe = 合成、文本🟡 自动向右跑,点击跳跃避障,距离计分,逐渐加速
17 打地鼠 随机出现 / 限时 tap / 计分 random、collision 点 / 圆判、particles 命中;文本🟡 地鼠随机洞口冒出,限时点中得分,超时消失
18 见缝插针 旋转 / 时机 tap / 碰撞检测 math 角度、collision raycastCircle:462、particles;文本🟡 中心圆持续转,点击射针,针不能相撞,逐根加针
19 节奏点击 时间窗判定 / 节奏 / 连击 ComboWindow:390 + InputBuffer、audio、easing;文本🟡 音符落判定线时点击,perfect / good 分级,连击加成
20 弹球变体(多球) 多球 / 道具掉落 / 物理反弹 collision 圆 + AABB、physics 限速、particles shakeScreen:524 / flashScreen:544;高速多球 CCD🟡 挡板接多球击砖,砖落道具(增球 / 扩板),命中屏震闪白

表里反复出现的 AABB,是 axis-aligned bounding box(轴对齐包围盒)的缩写,指那种边沿和坐标轴对齐的矩形碰撞框——绝大多数 2D 碰撞都用它,因为判定最快。


4. 四类能力缺口诊断(本基准的核心价值)

这一节是 W-G1 真正要回答的东西。20 款游戏合计考到的能力维度里,绝大多数都有插件或透传面兜着(),它们能立即冒烟;真正暴露问题的,是下面这 4 类(再加 2 条已规避的硬边界)。缺口判定全部用"源码证伪法"——不是按名字臆断"应该有",而是 grep 搜关键原语全空、再加上插件 impl.js 自述的能力边界,两头夹住才下结论。

先用一张图把它们的性质分清楚: 是"真造不出"的硬缺口,🟡 是"造得出但每款重造轮子"的半缺口。两者的应对动作完全不同:

flowchart TB
  subgraph 真缺口["❌ 真缺口:无门面 + agent 自写成本高/易错"]
    CCD["① 连续碰撞 CCD(swept)<br/>暴露:#5 高速球 / #12 子弹 / #20 多球<br/>后果:高速小球穿砖穿墙(tunneling)"]
    PATH["寻路 A* / 导航<br/>已主动规避(完整 Pacman 鬼 AI 未入选)<br/>→ 明确的引擎硬边界"]
  end
  subgraph 半缺口["🟡 半缺口:底层有原语/属生成域,但无门面 → 每款重造轮子"]
    TEXT["② 文本 / 分数 HUD 渲染<br/>暴露:几乎全部(~15/20 款)<br/>→ 最高频缺口,W-G1 后第一优先补门面"]
    GRID["③ 网格 / 棋盘状态抽象<br/>暴露:#1/2/3/7/9/11/13<br/>→ 2048/Tetris/Match-3 核心难度"]
    GEST["手势识别(swipe / 拖拽)<br/>暴露:#2/13 swipe / #15 拖拽 / #16<br/>→ 触屏轻游戏刚需,宜并入 gamefeel"]
    FSM["④ 通用状态机 FSM<br/>暴露:#8 Simon / #11 Tetris / 回合制类<br/>→ 属生成域,优先级最低"]
  end
  真缺口 -->|"批次3已跑(06-14/15)<br/>结论:门面非必需"| DECIDE["决策:补哪个门面<br/>预判优先级(已被实测推翻)<br/>文本 > 网格 > swipe/拖拽 > CCD swept"]
  半缺口 -->|"已量化:flash 自写多正确"| DECIDE

实测修订(2026-06-14 / 06-15): 上图的"补门面优先级预判(文本>网格>swipe>CCD swept)"已被放量实测推翻——这四类经放量验证均非缺口、不需补门面(文本/网格门面价值仅剩"省 token/一致性")。下文 §4.1§4.6 逐条诊断同属实测前预判,每条已就地标注实测反证;现行结论以 .agents/skills/cheap-model-game-generation.md §9 与 scale-20 报告 §六/§八为准。真实的唯一 L0 门面缺口=宿主键盘桥(已修 d754b71)。

4.1 真缺口之一:连续碰撞 CCD(高速小目标会穿透)

CCD(Continuous Collision Detection,连续碰撞检测;也叫 swept,扫掠碰撞)指的是这样一种能力:当一个物体一帧之内移动得太快、跨度超过了目标的厚度时,普通的"逐帧看现在有没有重叠"会漏判——物体在两帧之间就"穿"过去了(术语叫 tunneling,隧穿)。CCD 的做法是检查整段移动轨迹有没有掠过目标,而不只看落点。

  • 性质:我们的 collision 插件只有离散的 MTV / 穿透判定(circleVsAabb:295),没有 swept / toi(toi = time of impact,碰撞时刻)。grepswept|ccd|continuous|toi|tunnel 全空,impl.js:21 也自述能力止于"MTV / 穿透 / RayHit"。
  • 后果(预判):高速小球会穿砖、穿墙,便宜模型多半会产出"球偶尔卡进砖里 / 直接穿透"的 bug 件。暴露这个缺口的是 #5 高速打砖块、#12 小行星子弹、#20 多球弹球
  • 绕法与建议:agent 可以用射线 raycastAabb:500 沿速度向量手做一个粗糙的 toi(可行,但每款都得重写、容易错)。如果实测发现高频,就给 collision 补一个 swept 门面。是否本期补,建议等批次 3 实测数据再拍,不预先投入。
  • ★ 实测反证(2026-06-14 / 06-15,批次 3 已跑):这条"造不出 / 易穿透"的预判未成立——asteroids 子弹、multiball 弹球的源码经审计已是子步 swept CCD、本体正确,便宜模型自写正确。multiball 的 latch 未过是 driver-coverage(9s 内既清不完砖又护不住末球),asteroids 早期挂在宿主键盘桥(已修);均非 CCD 能力缺口。故"碰撞穿透门 J / swept 门面"已非急需。

4.2 真缺口之二:寻路 A* / 导航(已主动规避)

  • 性质:grepastar|pathfind|navmesh 全空;那个 SpatialHash 只做碰撞粗筛,不是寻路
  • 结论:任何需要敌人智能寻路的品类,当前都造不出——这是引擎和插件库一条明确的边界。正因为如此,本基准在选题时就主动规避了完整的 Pacman(吃豆人鬼魂寻路)。真要做,得新增一个寻路插件。

4.3 半缺口之一:文本 / 分数 HUD 渲染(最高频)

HUD(Heads-Up Display,抬头显示)指叠在游戏画面上的那层信息——分数、生命、计时之类。这是 20 款里最高频的能力需求,却恰恰没有门面:

  • 性质:没有任何文本渲染门面(grepdrawText|renderText 全空)。引擎的 LJS.drawText 是存在的,但没经插件透出,引擎能力背书工厂(createEngineCaps)那三面也不含文本(host-dev/engine-caps.js:51-145)。
  • 后果:每个游戏的便宜模型都得自己去 ctx.getContext2d().fillText 手画 HUD——结果就是风格各异、字体和对齐到处出错。
  • 判定:这是最高频缺口,20 款里约 15 款需要文本。所以强烈建议补一个 text / HUD 门面插件,作为 W-G1 实测后的第一优先

4.4 半缺口之二:网格 / 棋盘状态抽象

  • 性质:没有 grid / tilemap 门面(greptilemap|gridMap 全空)。网格状态本属 agent 生成域,但"坐标↔索引转换、邻接查询、遍历、合并"这些操作每款都得重写。
  • 后果(预判):2048、Tetris、Match-3 的网格状态机正是它们的核心难度所在,便宜模型自管很容易出"合并方向错 / 消行错 / 连锁错"的 bug。暴露这个缺口的是 #1/2/3/7/9/11/13
  • 建议:W-G1 重点观察便宜模型自写网格的出错率;如果高,就补一个 grid 工具门面。
  • ★ 实测反证(2026-06-14):flash 这档自写网格状态机正确——井字棋(3×3 状态机+胜负+AI)、扫雷(洪水填充+雷数文本)、Match-3(score 0→40 真消除)均跑通。2048/Tetris 早期挂在宿主键盘桥(键盘没透出 → 棋盘零变化 / 重力假性锁定),修键盘桥(d754b71)后 Tetris 整盘翻绿、2048 真合并;根因是键盘桥、非网格能力。故 grid 门面价值降为"省 token / 一致性",非"造不出"。

4.5 半缺口之三:手势识别(swipe / 拖拽)

  • 性质:受控面 getInput 只给 5 类原始事件(api.d.ts:218),没有 swipe / drag 的合成。
  • 后果(预判):agent 必须自己缓存 pointerdown→move→up 这串序列、算出方向和距离;愤怒小鸟那种拖拽蓄力尤其容易错。暴露这个缺口的是 #2 / #13(swipe)、#15(拖拽)、#16
  • 建议:swipe / drag 是触屏轻游戏的刚需,可以补进 gamefeel 插件——它本就管输入缓冲,手势识别归它最自然。
  • ★ 实测反证(2026-06-14 / 06-15):手势"易错"的预判未成立——Match-3 的盲态 swipe 交换凑三连真消除(本体正确),愤怒小鸟的拖拽蓄力本体弹道正确(F_wiring 过);二者的 score 缺口是 harness 适配 driver 覆盖(固定盲拖打不准 / 关卡 tuning),经 enrich 导出 launch 物理常数 + 加 drag-aiming driver 后愤怒小鸟 0→20 清场根因是可测性 / driver,非模型合成手势的能力。

4.6 半缺口之四:通用状态机 FSM

FSM(Finite State Machine,有限状态机)指那种"在若干个明确状态之间按规则切换"的逻辑结构,序列记忆、关卡阶段、回合流转都用得上。

  • 性质:gamefeel 只有 3 个特化计时器,没有通用 FSM 原语。
  • 后果:多状态玩法自己写状态切换容易乱。暴露这个缺口的是 #8 Simon、#11 Tetris 及回合制类。
  • 判定:它属生成域,优先级低于文本 / 网格——因为纯逻辑这块,便宜模型相对擅长。

4.7 一句话审计结论

把上面六条合起来,审计结论是这样的:20 款里约 12 款能力面齐备(),可以立即冒烟;余下 8 款集中暴露 4 类短板。最痛的不是"造不出",而是"文本 HUD + 网格状态"这两个高频能力没有门面——便宜模型 20 个 prompt 各造一遍轮子,在一致性、token、出错率三个维度上三重受损。真正"造不出"的硬边界只有两条:连续碰撞 CCD(高速穿透)与寻路(已规避)。

下面这张表把"谁兜每一类能力、覆盖状态如何"汇总成一览(行号为证据锚点):

能力维度 由谁兜 覆盖状态
离散几何碰撞(圆 / AABB / 多边形 MTV) collision :268-431
射线命中 / 空间粗筛 collision :462 / SpatialHash:112
抛体 / 重力 / 摩擦 / 限速 / 弹簧 physics-lite :104/286/194
输入缓冲 / 郊狼 / 连击窗 / easing 11 条 gamefeel :232/319/390/205
粒子 / 屏震 / 闪白 / 命中停顿 particles-juice :438/504/524 + 透传
音效 / BGM / 强度分层 audio-music :455-481 + 透传
tap / 方向键输入 · 确定性随机 受控面 getInput:218 / random
文本 / 分数 HUD 渲染 无插件门面(引擎 drawText 未透出) 🟡 缺门面(最高频)
网格 / 棋盘状态抽象 无 grid / tilemap 门面 🟡 缺门面
连续碰撞 CCD(swept) collision 仅离散 MTV 真缺口
手势识别(swipe / 拖拽) 无门面(agent 合成 pointer 序列) 🟡 自合成
通用状态机 FSM (gamefeel 仅 3 特化计时器) 🟡 agent 自写
寻路 A / 导航* (grep astar/pathfind 全空) 硬边界(已规避)

5. 分批分档执行建议

有了上面的判定,W-G1 就不该 20 款一拥而上,而应先用能力面齐备的易档验通管线(冒烟),再用中 / 难档加缺口款去压测能力上限、量化便宜模型在缺口处的产出质量。据此分成三批,逐批加难:

实测进度(2026-06-14 / 06-15,本分批计划已执行完毕): 三批均已实跑,结论已出——主力批 flash 实过 7/8(flappy 唯一未过=driver-coverage 非模型);压测批 6 款 0 个"造不出",3 款键盘游戏集体挂于同一处宿主键盘桥(已修 d754b71,修后 Tetris 翻绿 / 2048 真合并 / asteroids 解冻),multiball / 愤怒小鸟挂在 driver-coverage(重生成 / 增强 driver 后翻绿,愤怒小鸟 0→20)。下文各批的验收口径保留原文;"等批次 3 再拍"一类的待办均已闭口,结论见 scale-20 报告cheap-model-game-generation.md §9。

flowchart LR
  B1["批次1 · 冒烟批<br/>6 款 · 全 ✅ · 难度易<br/>Pong / Simon / 打地鼠<br/>记忆翻牌 / 贪吃蛇 / 节奏点击"]
  B2["批次2 · 主力批<br/>8 款 · ✅ 为主 · 难度中<br/>Flappy / 打砖块 / 太空侵略者<br/>Doodle Jump / 跑酷 / 扫雷<br/>见缝插针 / 井字棋"]
  B3["批次3 · 压测批<br/>6 款 · 含 ❌ / 难 🟡 · 难度难<br/>Tetris / Match-3 / 小行星<br/>愤怒小鸟 / 多球弹球 / 2048"]
  B1 -->|"验管线零阻塞<br/>≥4/6 过好玩基线"| B2
  B2 -->|"量化文本/网格/swipe<br/>三个高频🟡出错率<br/>≥6/8 可玩"| B3
  B3 -->|"不强求高通过率<br/>重点产缺口实证报告"| OUT["喂决策:<br/>是否补 text/grid/swipe/swept 门面"]

  style B1 fill:#a9dfbf
  style B2 fill:#f9e79f
  style B3 fill:#f5b7b1

5.1 批次 1 · 冒烟批(验管线打通)— 6 款 · 全 · 难度易

入选:#6 Pong / #8 Simon / #17 打地鼠 / #9 记忆翻牌 / #3 贪吃蛇 / #19 节奏点击

理由是这 6 款能力面 100% 齐备、机制单一。这一批的目标不是出多好的游戏,而是证明"便宜模型 + 插件库 + new-api 网关 + harness 门"这条链端到端能跑通、能产出可玩件。(new-api = 绘境AI 内部统一管理模型 key 与计费的网关;harness = 把生成产物放进真实运行环境自动检验的测试夹具。)验收标准:管线零阻塞 + 至少 4/6 款通过好玩基线评估门

5.2 批次 2 · 主力批(验常见机制覆盖)— 8 款 · 为主 · 难度中

入选:#4 Flappy / #5 打砖块 / #10 太空侵略者 / #14 Doodle Jump / #16 跑酷 / #7 扫雷 / #18 见缝插针 / #1 井字棋

理由是这一批覆盖了物理、碰撞、波次、程序化、网格这些主流机制,并带少量 🟡(文本 / 网格 / swipe)。它的核心产出是一组决策数据:量化文本 HUD、网格、swipe 这三个高频 🟡 缺口的便宜模型自写出错率——这正是"到底要不要补门面"那个决策的依据。验收标准:至少 6/8 款可玩;并逐款记录 agent 在 🟡 缺口处是怎么补层的、出了哪些 bug。

5.3 批次 3 · 压测批(测能力上限 + 暴露缺口)— 6 款 · 含 / 难 🟡 · 难度难

入选:#11 Tetris / #13 Match-3 / #12 小行星 / #15 愤怒小鸟 / #20 多球弹球 / #2 2048

理由是每款都压一到多个短板——Tetris / Match-3 / 2048 压网格状态机上限,小行星 / 多球弹球压CCD 缺口,愤怒小鸟压拖拽手势缺口。它的核心产出是证实 §4 的缺口判定:便宜模型在 CCD / 网格 / 拖拽处的产出质量到底如何(会不会穿透?消行对不对?蓄力准不准?),给创始人一张"引擎短板实测画像"。验收标准比较特殊:不强求高通过率(本批就是测上限的);重点是产出缺口实证报告,去喂"是否补 text / grid / swipe / swept 门面"那个决策。

实测结果(2026-06-14 / 06-15,本批已跑完): 实证画像与 §4 预判相反——便宜模型不会穿透(asteroids/multiball 子弹已是子步 swept CCD)、消行/网格对(Tetris 修键盘桥后整盘翻绿、Match-3 真消除)、蓄力准(愤怒小鸟本体弹道正确)。6 款失败 0 个"造不出":3 款键盘款挂宿主键盘桥(已修 d754b71)、multiball / 愤怒小鸟挂 driver-coverage(增强 driver 后翻绿)。喂决策的结论 = text / grid / swipe / swept 四类门面均非必需(若补,价值在省 token / 一致性)。详见 scale-20 报告 §六/§八。

5.4 跨批观测项(W-G1 真正要回答的三个问题)

不管哪一批,W-G1 全程要盯着三个问题——它们才是这次实测真正的产出:

  1. 便宜模型在三档的产出质量梯度:M3 / M2.7 / DS-V4 从易到难,哪一档开始崩?这定下能力天花板。
  2. 四类短板各拖垮多少款:文本 / 网格 / CCD / 拖拽各自影响几款,据此排补门面的优先级。预判是:文本 HUD > 网格 > swipe / 拖拽 > CCD swept⚠️ 此优先级已被 06-14 scale-20 实测推翻:这四类经放量验证均非缺口、门面非必需(便宜模型自带或自写正确)——真实唯一 L0 门面缺口=宿主键盘桥(已修 d754b71);不要再据此预判排门面优先级。
  3. harness 门的判定有效性:那套门能不能稳定逮住"穿透 / 消行错 / 不可玩"?门兜底是便宜模型路线的命门——门不硬,整条路线就立不住。

6. 风险与假设(诚实标注)

最后把这份基准的证据强度和未决项诚实标清楚,免得把推断当成实测、把假设当成结论:

  • [已验证] 全部覆盖判定都基于源码导出(api.d.ts + impl.js 的 return 面 + host.jsmakeEngineCaps()),证据锚点见 §2§4 各处的 文件:行号。缺口判定用的是"源码证伪法"(关键原语 grep 全空 + impl.js 自述能力边界),不是按预期名字臆断。
  • [推断] "便宜模型能产出 款的可玩件"是推断,不是实测——这恰恰是 W-G1 要验的。本基准只确证了"能力面齐备",不预断模型的产出质量。
  • [推断] 难度档(易 / 中 / 难)是按"机制数 × 实时性 × 缺口数"做的工程推断,不是用户体感难度。
  • [假设] 好玩基线的具体判据未在本次检索中定位到原文,验收门的精确判据需在 W-G1 开工前从评估门 spec 取齐。
  • [未决] 20 款的最终取舍可由创始人按"想优先验证的机制谱系"调整。CCD 与寻路这两条硬边界是否本期补门面,建议等批次 3 实测数据再拍,不预先投入。

7. 源档导航

本文档是 W-G1 基准的策展层主档,把一份只读调研产出整理成了这份给人读的全景。要看更深的逐款分析、能力盘点的完整证据链与决策史,从下面进去:

去处 回答什么
.agents/skills/cheap-model-game-generation.md 便宜模型造游戏的 worker loop、九门真玩 harness、design-agent 自产 gatespec、成本与模型选择、5 个坑(深落地权威源)
.agents/skills/game-e2e-cdp-harness.md Canvas 游戏 e2e 证据 harness:编排形态、driver 六规则、ship 红线、四件套证据(W-G1 复用)
生成引擎主文档 "一句话怎么变成一款游戏"的生成主线全景(本文的上游)
验收门-W-G1 这条主线"对外开闸"要先架的 6 道门 + 两道开闸前置验证
引擎与运行时 LittleJS 增强发行版、插件库分层、运行时沙箱与边界模型

纪律:本档是 W-G1 基准的策展层 SoT——读它 = 当前真相。逐款落地与证据链在 .agents/skills/,决策史在 git 与带日期的源档里;两者职责不同,不互相重复。当现行真相与某份带日期的源档冲突时,以本档与它引用的最新裁定为准。


验证状态:本文档为架构策展文档,由 W-G1 基准调研产出(只读盘点)改写而成,本身未改任何运行时代码。承重硬事实分两类:(a) 仍成立的事实基——7 插件 + 引擎三透传面 + 受控面 6 项、各能力的 文件:行号 证据锚点(makeEngineCaps 已迁 host-dev/engine-caps.js,见 §2.2)、三批分档(冒烟 6 款 / 主力 8 款 / 压测 6 款)及源码证伪法纪律,均沿用源档已抽查属实的结论。(b) 已被实测推翻的预判——§3 / §4 的覆盖判定、"4 类能力缺口(文本 HUD / 网格 / CCD / FSM)"、"约 12 款 可立即冒烟"、"补门面优先级预判(文本 > 网格 > swipe / 拖拽 > CCD swept)"均属实测前预判;2026-06-14 / 06-15 放量(scale-20,14 款真跑)已将其中的门面缺口判断几乎全部证伪(便宜模型自写正确),真实唯一 L0 门面缺口=宿主键盘桥(已修 d754b71),现行结论以档首"实测后修订"横幅及其引用的 cheap-model-game-generation.md §8§9 / scale-20 报告 为准。品牌统一为"绘境AI",无旧名残留。