GAMEASG-BENCH · PAPER WALKTHROUGH

如何验证一个游戏
真的做完了

从人写规格与隐藏测试，到真实浏览器输入、严格成功率和可复现失败。

47完整浏览器游戏任务
336L1 静态检查
885L2 行为检查
55.3%最佳严格成功率
SPEC人类先写可测试的玩法契约
BUILDAgent 交付自包含 index.html
VERIFY隐藏测试复现、操作并判定
GameASG-Bench: Benchmarking Autonomous Software Generation for Game Development · arXiv:2609.21293
02 · MOTIVATION页面能打开，不代表游戏完成

常见代理指标只能覆盖某一层

01
成功加载能排除启动崩溃，无法证明交互和状态机。
02
静态截图能看一帧布局，无法证明控制、动画和终局。
03
源码关键词出现 win、ammo 或 restart 也可能只是注释和空壳。
04
Agent 自测容易只走接口捷径，漏掉真实鼠标、触摸和自然时间。

完整游戏把输入、运行时状态、渲染反馈、资源变化和终局锁连成一条因果链。评测必须沿着这条链执行。

论文 §1、§2.3、§4.6。
03 · THE ORACLE PROBLEM可复现性与实现自由度

测试既要到达罕见状态，也要避免绑定内部变量

只用 GUI 慢慢玩

  • 后期状态耗时
  • 碰撞与时序容易漂移
  • 失败难以定位到单条需求
⇄

直接改内部状态

  • 依赖对象名和数据结构
  • 同一测试难以跨实现
  • 可能绕过真正的玩法路径
legal scenario + player action + stable snapshot + invariant
论文 §2.2。GameASG-Bench 把中间层写成公开的 evaluation interface specification。
04 · RELATED WORK比较任务范围、状态准备与运行证据

GameASG-Bench 的辨识度来自“生成前固定”

工作
产物
状态准备
运行证据
评价方式
APPS / EvalPlus
函数
输入样例
返回值
预先定义测试
SWE-bench
仓库修改
仓库与 issue
项目测试
已有测试套件
WebGameBench
浏览器游戏
候选状态
真实浏览器交互
规格引导
GameCraft-Bench
Godot 项目
可回放演示
回放与多模态证据
隐藏 rubric
GameGen-Verifier
生成游戏
运行时注入
前置、交互、后置
规格抽取 keypoint
GameXpert-Bench
生成与修复
生成后汇总事件
代码与现场交互
产物池加人工审核
GameASG-Bench
单页浏览器游戏
预先声明合法场景
快照、真实输入、浏览器信号
规格和检查生成前固定
论文 §5.3。表内措辞按原文归纳。
05 · AUTHORSHIP AND VISIBILITY先回答 checks 从哪来

人类写规格、检查与优先级，Agent 写游戏

文件
作者
Agent 可见性
作用
target.md
人类开发者
可见，直接进入提示
工作区、交付协议、玩法简介
game-spec.md
人类开发者
可见
玩家可见机制和最低可玩循环
tdd.md
人类开发者
可见
场景、动作、快照、拒绝与不变量
checks.json
人类开发者
隐藏
L1 静态检查
checks.js
人类开发者
隐藏
L2 浏览器行为检查
参考实现
benchmark 团队
隐藏
人工验证后的正控制
index.html
Coding Agent
Agent 自己生成
最终交付物
论文 §2.1、§3.2、§3.3、附录 B。P0/P1/P2 在人工测试编写阶段分配。
06 · ORIGINAL TABLE 1三份公开任务文档

Agent 知道要实现什么，也知道如何暴露可测试行为

原论文 Table 1
原论文 Table 1。三份文档都在 Agent 工作区，只有 target.md 直接传给 harness。
原论文 Table 1。
07 · BENCHMARK CONSTRUCTION根据论文 §2、§3 与附录 B 重绘

测试在模型生成前就已经固定

STEP 1人工选题

完整可玩循环，可在有界浏览器执行中观察。

STEP 2写公开规格

target、game spec 和 TDD 共同定义任务。

STEP 3写隐藏检查

checks.json、checks.js 与优先级预先完成。

STEP 4验证参考实现

人工操作并跑自动检查，确认核心合规。

STEP 5Agent 生成

干净工作区、新会话，只能读公开文档。

STEP 6独立评测

预检交付，再跑 L1、L2 与严格计分。

47 个参考实现全部通过所有 L1 和适用的 L2 P0/P1。它们用于验证测试能接受人工确认合格的实现。
本页为二次重绘，不是论文原图。来源：论文 §2.1、§3.1 至 §3.3、§4.1、附录 B。
08 · EXECUTION BOUNDARY生成和评测互相隔离

Agent 看得到契约，看不到可执行检查

生成容器

read-only: target.md read-only: game-spec.md read-only: tdd.md read-write: workspace/
  • 每次从原始任务文件开始
  • 新 agent session
  • 不挂载 checks 与 runner
→

评测容器

read-only: index.html read-only: checks.json read-only: checks.js read-only: runners/
  • 先做 delivery preflight
  • 再执行 L1 与 L2
  • 记录逐项结果和严格成功
论文 §4.1、附录 B。预检要求成功退出、常规非 symlink 文件、非空且含 </html>。
09 · PUBLIC TEST CONTRACT同一入口，任务特定语义

四个方法连接测试和真实游戏状态

window.__gameTest = {
  reset(options),
  loadScenario(name, options),
  input(action),
  getSnapshot()
}

// 返回 JSON 可序列化快照
// 状态必须驱动画面
reset清掉上一局的临时状态、弹窗和结果锁。
loadScenario准备正常游玩可达的起点，不能提前制造待测结果。
input执行玩家级语义动作，例如下单、暂停和选择目标。
getSnapshot返回稳定语义摘要，不暴露私有对象图。
论文 §2.2。方法名统一，场景、动作与快照字段由任务定义。
10 · PREPARE, ACT, OBSERVE罕见状态可达，因果链仍保留

测试可以摆好战场，仍要由玩家动作触发结果

PREPARE

合法前置状态

调整资源和位置，让后期情形可复现。初始快照必须仍然安全、非终局、未完成待测动作。

→
ACT

玩家级动作

调用公开语义动作，或发送真实鼠标、键盘与触摸输入。

→
OBSERVE

结果与不变量

检查结果、资源、HUD、render revision 与未受影响状态。

禁止：直接写胜负、血量或坐标来伪造结果；用固定快照替代真实游戏状态；让测试状态和可见玩法分叉。
论文 §2.2；Armor Alley tdd.md 的 scenario setup 与 interface integrity 约束。
11 · REAL CHECKS.JSONArmor Alley 的 L1 契约检查

静态层先确认四个方法和动作 schema 存在

{
  "id": "p0-contract-methods-reset-input-snapshot",
  "level": "P0",
  "type": "regex_all",
  "patterns": [
    "... reset ...",
    "... input ...",
    "... getSnapshot ...",
    "... loadScenario ..."
  ],
  "fix_hint":
    "Define reset, loadScenario, input,
     and getSnapshot on window.__gameTest."
}
由人类编写checks.json 在生成前完成，并且不会挂载到生成容器。
允许多种写法真实正则覆盖方法、对象属性和 Object.assign 等形式。
证据上限明确正则可能匹配注释或字符串，所以 L1 不承担玩法正确性证明。
官方仓库 tests/armor-alley/checks.json；论文 §2.3、§3.2。
12 · REAL CHECKS.JSL2 把规格写成可执行轨迹

一条行为检查同时描述输入、观察与空壳失败原因

// GDD Coverage Map
M3 weapons
  → p1-keyboard-sustained-fire-release

// Rationality Map
real action:
  browser.keyDown / browser.keyUp
independent observation:
  ammo / projectile / combat revision
empty-shell failure:
  fire flag without projectile, cost,
  or release behavior

`checks.js` 不是统一模板自动展开的壳。每道题的人类作者把具体玩法写成 task-specific JavaScript。

Armor Alley 的 checks.js 有 814 行。它覆盖启动、飞行、武器、落地补给、生产、地面战争、雷达、暂停、终局和 P2 扩展项。

官方仓库 tests/armor-alley/checks.js。行数按 2026-09-21 获取的 main 分支文件计算。
13 · ARMOR ALLEY真实 task：直升机与地面战线

测试覆盖的是完整战斗循环

Armor Alley

玩家驾驶直升机侦察、攻击和投放士兵，同时花钱生产坦克、导弹车、运输车与步兵。

胜利：友方运输车到达敌方基地。失败：敌方运输车突破己方基地，或有限生命模式下防御能力耗尽。
飞行

指针相对直升机中心决定持续加速度，左右与上下方向不能反转。

武器

持续射击、炸弹、制导武器与投兵都有成本、效果和拒绝路径。

经济

资金、生产队列、单位上限和战后锁必须同步。

战场

地面单位自主推进，碉堡、炮塔、危险物与雷达参与状态变化。

维护

落地补给应逐步恢复资源，落地时水平移动受限。

终局

胜负出现后普通攻击和生产不能继续改变结果，重启要清空旧状态。

官方仓库 task/armor-alley/game-spec.md。
14 · ARMOR ALLEY TDD持续射击测试的公开契约

场景只准备攻击条件，不提前产生射击结果

准备

loadScenario(
  "air_attack_with_targets"
)

phase === "playing"
result === "none"
helicopter.airborne
visibleTargets.length > 0
→

操作

keyDown("Space")
wait 650 ms
snapshot held

keyUp("Space")
wait 300 ms
snapshot released
→

观察

按住期间：
projectiles ↑
或 revision ↑
或 ammo ↓

松开之后：
增长进入平台期
场景预检失败时，检查直接 FAIL。这样可以区分“准备状态已经造假”和“玩家动作没有造成结果”。
Armor Alley tdd.md 与 tests/armor-alley/checks.js。
15 · REAL BROWSER INPUTchecks.js 原始逻辑

按下和松开都由浏览器输入通道触发

const before = setup.snap;

await browser.keyDown('Space');
await browser.sleep(650);
const held = await game.snapshot();

await browser.keyUp('Space');
await browser.sleep(300);
const released = await game.snapshot();
const afterRelease = await game.wait(550);

if (!grewWhileHeld)
  return FAIL('held fire did not create evidence');
if (!plateauAfterRelease)
  return FAIL('fire continued after release');
return PASS('real key path creates and stops fire');
不使用 contract fire rescue测试不会调用 input({type:'holdFire'}) 替代真正的 Space 键路径。
两次松开后取样先记 released，再等待 550 ms，避免只捕捉到瞬时状态。
多种等价证据允许不同实现用弹丸、revision、战斗事件或弹药表达同一行为。
官方仓库 tests/armor-alley/checks.js，p1-keyboard-sustained-fire-release。
16 · PASS AND FAIL同一需求的正向证据与停止条件

测试要看到“开始增长”和“停止增长”

按住期间

grewWhileHeld = projectileCount ↑ OR projectileRevision ↑ OR combatRevision ↑ OR ammo ↓

多个信号允许实现采用不同弹丸生命周期。只写一个 firing 布尔值不足以通过。

松开之后

plateauAfterRelease = count(afterRelease) ≤ count(released) + 1 OR projectileRevision remains unchanged

允许一个已经在途的弹丸完成，禁止持续生成。按键监听器、定时器和弹药逻辑必须接到同一状态。

官方 checks.js 中的真实布尔条件，排版仅为便于阅读。
17 · ORIGINAL TABLE 2证据层和优先级是两套标签

336 个源码检查，885 个浏览器行为检查

原论文 Table 2
原论文 Table 2。L1 包含 43 个工具检查、288 个正则和 5 个反模式。L2 包含 102 个 P0、534 个 P1 和 249 个 P2。
原论文 Table 2。
18 · L2 EXECUTION每条检查使用一个新浏览器页面

快照、真实输入与渲染信号相互校验

PAGE新页面

加载提交的游戏，隔离上一条检查的状态。

RUN单条检查

准备场景、输入、等待、读取快照和渲染证据。

CLOSE关闭页面

完成或超时后销毁，再开始下一条。

共享浏览器 hook 记录 animation frame、输入监听器、Canvas/WebGL 活动和运行时异常。

每条检查只组合它需要的信号。快照提供语义，真实输入确认玩家路径，渲染证据确认状态没有停留在隐藏变量里。

论文 §2.3。L1 失败不会阻止 L2 执行。
19 · STRICT TASK SUCCESS交付式二元指标

全部必需检查通过，任务才记为成功

P0

启动、测试接口和最低运行条件。共 102 个 L2 检查。

P1

核心机制、交互、不变量和配套接口。共 534 个 L2 检查。

P2

高级机制与体验完整度。单独报告，不进入严格成功。

success = valid delivery × completed evaluation × all L1 pass × all applicable L2 P0/P1 pass

39/40 个必需检查通过，任务仍记为 0。平均通过率回答“差多少”，严格成功率回答“能不能交付”。计划内未交付和未完成评测也进入分母。

论文 §2.4、公式 (1)。当前 runner 没有限制 P1 返回 NOT_APPLICABLE。
20 · ORIGINAL FIGURE 147 个任务的组成

12 类游戏，32 个 2D，15 个 3D

原论文 Figure 1
原论文 Figure 1。技术标签描述参考实现，并不限制 Agent 的实现。
原论文 Figure 1。论文只有这一张正式编号 Figure。
21 · ORIGINAL TABLE 3九个 agent stack 的端到端结果

最佳严格成功 26/47，平均 L2 已达 93.2%

原论文 Table 3
原论文 Table 3。高平均通过率与未完成任务同时存在。每个 task-configuration 组合只运行一次。
原论文 Table 3。GPT-6-Astra + Codex CLI：26/47，55.3%。
22 · ORIGINAL TABLE 4产物大小、token 与报告成本

更多 token 和更大文件没有稳定换来更多严格成功

原论文 Table 4
原论文 Table 4。成本按各 stack 报告口径统计，不能只靠 token 量解释完成度。
原论文 Table 4、§4.2。
23 · ORIGINAL TABLES 5 AND 6DeepSeek-V4-Flash · Claude Code

完整工具提高 P1，短预算先截断交付

原论文 Table 5
Table 5。完整工具 18/47，受限工具 6 至 9/47。
原论文 Table 6
Table 6。30、60、120 turns 完成评测 10、32、47 个任务。
原论文 Tables 5、6。30 turns 的条件成功率 70.0%，全体成功率 14.9%。
24 · ORIGINAL TABLES 7 AND 8同分不代表相同行为

High 成功更多，两个 harness 只共享 10 道成功题

原论文 Table 7
Table 7。High 为 19/47，Max 为 18/47。High 少用 26.9% reasoning tokens。
原论文 Table 8
Table 8。两种 harness 都是 18/47，只有 10 道题共同成功。
原论文 Tables 7、8。结果来自单次运行，不能据此建立稳定的绝对排名。
25 · ORIGINAL TABLE 9总榜背后的可复现缺口

失败发生在输入、场景与自然时间的组合处

原论文 Table 9

Diner Dasher

GPT-6-Astra + Codex CLI
  1. 加载带正确餐点的托盘。
  2. 读取物品和顾客屏幕边界。
  3. 发送真实鼠标与触摸拖拽。
  4. 服务进度和收入都不增加。
L1、L2 P0/P2 通过，P1 核心交互失败。

Turbo Smash Beast

DeepSeek-V4-Flash + Claude Code
  1. 加载场景会开启 test mode。
  2. test mode 关闭自然时间模拟。
  3. 真实驾驶输入因此无法推进车辆。
分开的自测都通过，组合轨迹暴露冻结。
原论文 Table 9、§4.6、附录 A.1。
26 · TAKEAWAYS读完后应该带走的判断

这套 benchmark 的贡献是一条可复跑的行为证据链

人类固定契约和隐藏检查，Agent 自由实现内部结构，评测器用合法场景、真实输入、稳定快照和渲染信号复核因果链。

93.2%最佳平均 L2
55.3%最佳严格成功率

适合回答

单页浏览器游戏是否满足一组预先写好的核心行为要求。

仍需谨慎

47 题、每配置一次运行、无后端和多人系统。P1 的 NOT_APPLICABLE 仍有计分漏洞。参考实现通过也不等于规格覆盖完备。

可迁移的方法

为交互式应用设计 prepare、act、observe 与 invariant，并让语义状态和可见行为共用同一底层状态。

论文 · 代码与 47 个任务 · 解读与重绘：ChrisDing Blog
封面 1 / 26