01 · QUESTIONarXiv:2609.33678 · 2026-09-27

AI 能做出我们想要的游戏吗？

SWE-Game 不满足于“项目能启动”。它让评测器亲自按键、观察引擎状态，并确认胜负真的是玩家动作造成的。

41可执行 Godot 参考游戏
247五种开发任务
50.38最佳 Brief-to-Game
92.59%runtime judge balanced accuracy
来源：Abstract；Table 3；Table 51 / 14
02 · FAILURE为什么画面与胜利界面都不够

一个“看起来完成”的游戏，可能没有玩法因果

只看画面

尖刺、cell、beacon 都可以画出来，但碰撞不一定改变 health 或 progress。

只看终局

候选可能自动进入 victory。没有输入对照，就无法证明玩家完成了路线。

运行时证据

driver 执行动作，probe 读取接触、对象生命周期与状态变化，再判定行为。

同长度 no-input control 也到达 goal 时，certified route 直接记 0。

来源：Section 1；Section 3.4 Functional evaluation2 / 14
03 · CORPUS41 references → 247 tasks

同一批游戏，派生五种开发合同

41 tasksBrief

短目标 + assets + video。Agent 先写 GDD，再从头开发。

41 tasksGDD

给 reviewed GDD 和可观察 feature obligations。

41 tasksSkeleton

给 implementation-neutral scaffold，不是删掉 reference code。

83 casesRepair

注入故障、症状报告与需保留的行为。

41 tasksPorting

给 Godot 源码，原生迁移到 Unity。

24 / 172D / 3D
13玩法类别
168,335GDScript 行数
138参考录像
来源：Section 3.1–3.2；Appendix A–B。41×4+83=247。3 / 14
04 · VISIBILITY谁看得到什么

公开接口允许替代实现，隐藏 checker 保留判分权

Agent 可见

  • 按模式提供 brief、GDD、scaffold、faulty project 或 Godot source
  • assets 与 mode-dependent reference video
  • contract.json / Unity interface
  • semantic groups、actions、numeric slots
  • 必须交付的项目、GDD、demo 或 build 说明

Evaluator 独占

  • task-specific checks 与 expected outcomes
  • certified reference-input routes
  • semantic start 参数与 probe assertions
  • reference/faulty/repaired 三版本 scenario verdict
  • visual rubric host-side curves 与 deficiency caps

公开材料说明“能观察哪些角色和状态”，不会把 reference implementation 或 hidden predicate 交给 Agent。

来源：Section 3.2–3.4；Appendix B–C；Appendix H4 / 14
05 · TWO HARNESSES模型端与评测端必须分开

论文公开了 evaluation harness，却没有公开六套 Agent framework

Model-side agent harness

读任务、改代码、运行引擎、看素材与调用工具。六个模型各用自己的 framework 和 tools。

名字未知tool schema 未披露统一预算未披露
≠

Evaluation harness

校验 manifest，向工作副本注入 drivers/probes，重放输入，跑 no-input control，录制画面并聚合分数。

Godot 4.5.1Unity 6000.3.23f1sandbox

因此 Table 3 是“模型 + 各自 framework”的系统比较，不能解释成严格受控的纯模型能力排名。

来源：Section 4.1；Appendix E。论文明确承认 framework 混杂。5 / 14
06 · MODELS六个配置都跑 247 题

资源差异大到足以影响排名解释

模型BriefGDDSkeletonRepairPorting
Qwen3.8 Flash27.0037.3539.1926.1351.23
Grok4.639.0148.5540.7652.4459.04
GPT-5.6 Luna34.1852.6743.1058.0559.85
Opus550.3859.6854.0683.4672.40
GLM5.3 Flash31.0540.1834.3827.5544.33
Minimax M330.4742.5835.6927.3649.62
8.49MOpus5 Brief 平均 input tokens
2.56MGPT-5.6 Luna Brief 平均 input tokens
根据 Table 3 与 Figure 4 数据重绘。Opus5 / GPT 同项 tool calls 为 111.37 / 57.15。6 / 14
07 · INTERFACE不同代码结构怎样接受同一测试

Candidate 提交语义绑定，checker 不猜内部节点名

01Scenes

levels 与 endings 给出可启动地址。

02Entities

gb_player、hazard、enemy、goal 等角色。

03Actions

left/right/up/down、jump、action、pause、reset。

04State

progress、health、timer、score 与 device IDs。

05Inject

评测器在工作副本装入 driver 与 probe。

06Observe

位置、接触、对象状态、scene 与 outcome。

candidate: gb_levels.json + semantic groups + live numeric bindings evaluator: hidden routes + scenario parameters + expected outcomes
来源：Section 3.3；Appendix C Table 77 / 14
08 · REAL TASKBeacon Relay

一份真实 GDD 把“送信标”写成可测试状态变化

Pickup

接触 pedestal cell 后，13 / 12 / 11 秒 fuse 启动，cell 从 green 变 amber 再变 red。

Stomp

携带 cell 从上方踩中 hostile，返还 2.5 秒并刷新 air jump；侧面接触损失 shield。

Deposit

携带 cell 与 beacon 重叠，relay progress 增加、一个 segment 点亮、fuse 停止。

三关共 11 个 cells，三类 hostile、七类 device，每关一个 heart、三格 shield。

完整普通输入路线约 6–9 分钟，固定 60 Hz，不使用 procedural randomness。

来源：Appendix B.2 Beacon Relay task GDD excerpt8 / 14
09 · VERDICT PATH从输入到 PASS / FAIL

Certified route 测行为，no-input control 测因果

1Fresh launch

冷启动候选，校验 interface 与场景。

2Replay

按 reference route 的动作时序输入。

3Probe

读取 contact、lifecycle 与 live state。

4Assert

检查 milestone、goal 与 requirement。

5Control

同长度无输入也成功，则 route 记 0。

PASS 逻辑

玩家动作触发 pickup / deposit，probe 观察到对应对象与 progress 变化，对照不发生。

解释性 FAIL

候选按时间自动增加 progress。它能显示 victory，但 no-input control 也过关，因此不给 route credit。

FAIL 由公开协议推导，不是发布的模型 log；task-specific checker code 未公开。9 / 14
10 · SELF-DEMOAgent 可以证明自己的独特实现

demos.json 补足固定 reference route 覆盖不到的功能

独立片段

每个 demo 有 id、description 与 inline ops。

统一起点

每段从第一关 cold launch，不能注入 state 或选 hidden scene。

匹配对照

每段都跑相同长度 no-input control。

不重复计分

多个 demo 证明同一 feature，也不会重复增加 coverage。

Whole-game completion 不是 feature-demo 协议的前提；没被任何 demo 实际触发的 requirement 仍算 uncovered。

来源：Section 3.4；Appendix H.2 independent demonstrations10 / 14
11 · SCORING三个聚合路径

总分先按任务内组件计算，再对 41 或 83 题取平均

Construction

S = 0.85O + 0.15V

O 合并 mechanics、content、playability，再按模式加入 design 或 scaffold。

Bug Repair

100 · r · t · p · g

restoration、retained routes、preservation、validity 在每个 case 内相乘。

Porting

35 / 25 / 15 / 15 / 10

mechanics、playability、structure、visual、stability 的百分比权重。

Repair 先乘后平均。只修好目标 bug，却破坏保留行为或构建有效性，会被乘法显著惩罚。

根据 Equation 1–3 与 Appendix D Table 9 重绘11 / 14
12 · RESULT会交付项目，不等于会实现指定玩法

三类 construction 的最佳总分仍低于 60

Brief-to-Game · Opus5
50.38
GDD-to-Game · Opus5
59.68
Skeleton · Opus5
54.06
Repair · Opus5
83.46
Porting · Opus5
72.40

Skeleton 的 Opus5 Scaffold 是 94.62，Content 只有 36.93，Mechanics 36.22。接口接上了，内容与玩法仍不完整。

根据 Table 3 重绘。分数 0–100。12 / 14
13 · JUDGE VALIDITY评测器本身也接受检验

可执行检查比视频 VLM 更会发现功能缺陷

1,200 条功能 assertions

92.59%Executable balanced accuracy
≈78.41%Video VLM balanced accuracy

Executable：411/452 正确接受，705/748 正确抓缺陷。

200 段视觉 clips

0.829Spearman ρ
0.103MAE on [0,1]

重复判断的 within-clip SD 为 0.034。

论文未披露人工 annotator 数量与 agreement，也未命名 visual judge 使用的 VLM。

根据 Table 5 重绘；balanced accuracy = 两类正确率的算术平均。13 / 14
14 · VERDICT怎样读这篇论文

它把“想要的游戏”变成动作、状态与视觉三类证据

证据支持

  • runtime checks 适合验 mechanics，VLM 适合验 presentation
  • no-input control 能排除自动成功与伪因果
  • 需求遗漏和 gameplay logic error 是主要失败来源
  • 公开 semantic contract 允许候选采用不同内部结构

仍不能确定

  • 六个 Agent framework 与工具、预算的受控差异
  • 主榜重复运行与方差
  • 人工标注协议和 visual judge 身份
  • task-specific checker 对外部复现者是否可用

截至 2026-10-08，论文未链接正式 benchmark/checker repository。最可信的结论是评测设计方向，而不是把 Table 3 当成纯模型排行榜。

SWE-Game: Can Coding Agents Build the Games We Want?14 / 14