SWE-Game：编程智能体游戏开发能力评测基准 SWE-Game: Can Coding Agents Build the Games We Want?
以41个可执行参考游戏构建247个任务，用运行时证据加视觉评审评测六大模型的游戏开发能力
前置知识
SWE-bench 与可执行软件工程基准范式
将代码模型评测从静态用例转向'仓库级修改+回归测试'的可执行任务：给智能体一个真实代码库和任务描述，让它在沙箱中导航、编辑、运行代码，由自动化测试判定补丁是否正确。范式由 SWE-bench 开创，Terminal-Bench、SWE-Marathon 等扩展到交互式项目与长周期工作流。
SWE-Game 正是这一范式在游戏开发领域的延伸，把'游戏'当作可执行项目来评测。理解该范式才能明白本文的任务契约、行为保持检查与'模型-评测器交互协议'的设计动机和贡献定位。
Godot 与 Unity 游戏引擎
两个主流游戏引擎：Godot 开源，用 GDScript 写脚本、场景树组织对象、InputMap 管理输入；Unity 商业，用 C# 与组件系统构建。本文参考游戏用 Godot 4.5.1 实现，移植任务目标为 Unity Editor 6000.3.23f1。
论文的任务构造与插桩接口深度绑定引擎机制——场景路径、场景树分组、InputMap 动作、节点属性。不懂这些概念，就无法理解 gb_levels.json 声明、语义分组绑定以及移植任务为何要求'原生 Unity 实现'。
游戏设计文档（GDD）
描述目标体验、操作方式、核心机制、成败条件、内容范围与资产用途的设计规约。本文的 GDD 把每条机制写成'动作触发的状态改变 + 视听反馈'，例如 Beacon Relay 中拾取能量电池启动 13/12/11 秒引信、踩踏敌人反弹并返还 2.5 秒等精确规约。
五种任务模式的本质差别就是提供了多少设计信息：一句话简报、完整 GDD、还是半个骨架代码。GDD 既是 Mode 1 要求智能体自己先写出的交付物，也是 Mode 2/5 的实现规约和评测依据，是整个基准的任务规约载体。
语义插桩接口（instrumentation interface）
独立实现的游戏对象命名和场景结构各异，评测器无法直接读懂。该接口要求提交方把对象绑定到语义角色（gb_player、gb_hazard 等分组）、标准动作（gb_jump 等）与数值槽（health、progress、score），评测器据此用自有驱动器执行动作、用探针观测引擎状态。
这是本文实现'跨独立实现评测'的关键基础设施：提交方只提供绑定，检查逻辑与预期结果全在评测方手里。理解它才能理解论文如何解决'等价对象识别'这一核心难题。
VLM 视觉评审与评分量规（rubric）
视觉语言模型能阅读截图或视频帧并按自然语言标准打分；rubric 是预写的逐条评分条款，规定满分标准、部分分与缺陷封顶。本文为 41 个游戏写了 658 条专属条款，分四组按 0.10/0.18/0.27/0.45 加权，视觉分占构建类总分 15%。
游戏的'呈现质量'（画面是否传达了机制、反馈、进度）无法用引擎状态断言衡量，视觉评审用于补充功能检查并占构建类总分的 15%。理解 rubric 结构才能看懂视觉分与消融实验。
平衡准确率与 Spearman 相关系数
平衡准确率是正确接受率与缺陷检出率的未加权平均，适合判定任务中两类样本不均衡的情况；Spearman ρ 度量两组评分的秩相关，衡量自动分数与人类打分的单调一致性，不要求线性刻度一致。
4.5 节用这两个指标验证自动评测器本身的可信度——可执行检查 92.59% 对视频 VLM 判定 78.41%，视觉量规 ρ=0.829。这些数字是全文'评测方法有效'这一主张的定量支撑。
研究动机
现有游戏开发评测在任务覆盖与评估粒度上都有明显缺口。任务侧，GameDevBench 和 JamBench 偏向项目编辑、生成与补全，GameEngineBench 只考察 Unreal 内的 C++ 集成，GameCraft-Bench、V-GameGym 等专注从头生成，没有一个基准把构建、补全、修复、跨引擎迁移放到同一批参考项目上统一考察，也就无法回答'同一个智能体在不同开发活动中的能力差异'。评估侧，多数工作依赖 VLM 判分或粗粒度规则测试，无法捕捉交互中的动态响应与逻辑一致性：一个平台跳跃游戏可以把尖刺显示得完全正确、也能正常到达胜利画面，但玩家实际上能穿过尖刺不受伤，胜利还可能是绕过了必需交互达成的——这类'看起来对、玩起来错'的缺陷，静态代码检查、模型主观打分或'到达终点即得分'式检查都抓不住。此外，依赖执行反馈的迭代修复也未必改善结果：突变测试生成的研究表明，科学式调试提示需要比普通迭代提示更多轮次却只换来相近成功率，说明评测必须针对明确要求检验最终行为，而不是只看迭代轮数或表面可玩。
本文的目标是本文要回答的问题是：当给定角色、环境、道具等资产和一段目标玩法演示时，编程智能体能否把这些材料转化为正确的机制、进程与呈现，并在项目被补全、修复、迁移时保持目标玩法？为此作者构建 SWE-Game：以 41 个可执行 Godot 参考游戏（24 个 2D、17 个 3D、13 类玩法）为根基派生 247 个任务，覆盖简报到游戏、GDD 到游戏、骨架补全、83 例注入故障修复与 Godot 到 Unity 移植五类开发活动；用共享插桩接口让评测方拥有的驱动器与探针能够操作独立实现的游戏，从引擎状态检查、认证输入回放与智能体自证演示三个层面收集行为证据；对构建类任务再用 658 条游戏专属视觉量规评估呈现质量；最后用 1200 条人工标注断言和 200 段人工评分片段系统量化自动评测与人类判断的一致性。
与已有工作不同的是，本文的独特切入是用'可执行参考游戏'同时充当任务素材源和评测真值锚点，把'要求的玩法'与'检查的行为'直接连接：任务规约（简报、GDD、骨架、故障报告、移植契约）说明要复现或保留什么，参考游戏的实际运行则定义了具体可检验的行为目标。针对独立实现间对象命名和场景结构各异的问题，论文提出语义插桩接口，让提交方把对象绑定到 gb_player、gb_hazard 等语义角色与标准动作、数值槽上，评测器据此跨实现定位玩家与危险物、观测接触并检查血量变化——正如尖刺例子中评测器能确认'接触后是否掉血或重生'。评估设计上引入'认证路由回放 + 匹配无输入对照 + 智能体自证演示'三层运行时证据，确保得分真正依赖玩家动作而非动画表演。更少见的是，作者把评测器本身作为验证对象，用人工标注比较可执行检查与视频 VLM 判定的准确率，把'自动评测可信吗'从假设变成测量。
核心方法
直觉上，评测'能否做出我们想要的游戏'需要两样东西：明确的'想要'（任务规约）和可信的证据（运行时行为加视觉呈现）。技术路线分四步。第一步构建参考语料：基于授权公开资产，按'目标—操作—机制—成败条件—内容范围—资产角色'写 GDD，在 Godot 4.5.1 中实现并经运行时检查与人工试玩修订，最终得到 24 个 2D 与 17 个 3D 游戏，合计 168,335 行 GDScript、1,587 个场景与 138 段玩法录像。第二步派生任务：构建与移植模式每游戏一题（各 41 个），修复模式注入 83 个故障案例，共 247 个。第三步接入与评测：提交方经 gb_levels.json 把场景、结局、语义分组与数值槽绑定到统一接口，评测器校验后对工作副本插桩，运行认证路由回放、无输入对照、演示回放与状态探针。第四步评分：构建类 $S = 0.85O + 0.15V$（客观 85%+视觉 15%）；修复用乘法 $S^{\text{repair}}_i = 100\, r_i t_i p_i g_i$；移植按五组件加权，报告 0–100 分。
核心创新是把'任务规约—行为目标—运行时证据'连成闭环。与 GameCraft-Bench 等靠 VLM 主观判分、WebGameBench 靠 agent judge 不同，本文的行为证据来自引擎内部状态与在参考游戏上编排验证过的输入序列：评测器拥有全部检查和预期结果，提交方只提供语义绑定，双方信息隔离，'要求什么'直接决定'检查什么'。匹配无输入对照是点睛之笔——一条路由或一段演示只有在'同样时长不给输入就到不了目标'时才计分，把'完成依赖玩家动作'变成可判定的因果陈述，直接封死'录一段自动演出的动画糊弄评测'的捷径。修复评测则在参考、缺陷、修复三个版本上运行相同场景，用四因子乘积 $r \cdot t \cdot p \cdot g$ 同时要求恢复故障行为（restoration）、保留原有可用路径（retained routes）、维持无关行为契约（preservation contracts）并通过有效性门控（validity gates），'删掉坏功能了事'这种修法拿不到分。这套设计与静态代码检查、粗粒度规则或纯模型打分有本质区别。
方法步骤详情
流程：Mode 1（Brief-to-Game）只给设计简报、资产包与参考视频，智能体须先自写 GDD；Mode 2（GDD-to-Game）给评审过的完整 GDD；Mode 3（Skeleton Completion）给实现中立的最小骨架（入口场景、占位关卡、InputMap 绑定、player 适配器），须保留公共集成面、补齐玩法；Mode 4（Bug Repair）给注入故障的项目、玩家症状报告与需求，故障跨脚本/场景/资源并混有可疑无害编辑；Mode 5（Porting）给净化 Godot 源码、GDD、资产、视频与 Unity 工作区，要求可构建 Player。提交与插桩：Godot 提交 gb_levels.json 声明关卡、结局、gb_* 语义分组与数值槽，评测器校验后运行驱动器与探针。功能评测：认证路由在参考游戏上编排验证，仅当无输入对照未达标才计分；演示逐段冷启动回放并与等长无输入对照比较；修复任务在参考/缺陷/修复三版本跑同场景，按 $S = 100\,rtpg$ 聚合。最后 VLM 依 658 条量规为评测器录制的帧打分。
技术新颖性
新颖性体现在五个方面。其一，五种开发契约（生成、按规约实现、补全、修复、移植）共享同一批参考项目，使能力对比可以跨开发活动横向展开，此前没有基准做到。其二，语义插桩接口把'等价对象识别'问题显式化并给出工程解：评测器用统一词汇（角色、动作、状态槽）操作结构互异的实现——VERIGAME 的状态注入只查局部关键点，GameLogicBench 的引擎断言停留在补丁级，都未系统解决跨实现评测。其三，无输入对照把因果依赖纳入评分，是有明确防作弊语义的运行时验证设计。其四，修复分数用 $r \cdot t \cdot p \cdot g$ 乘法聚合，任一因子趋零则整题归零，显式编码了软件维护中'行为保持'的语义。其五，作者对评测器本身做人工验证并报告平衡准确率（92.59%）与 Spearman $\rho$（0.829），把自动评测的有效性变成测量结果而非假设，这在游戏开发基准中几乎未见先例。
实验结果
六模型跑满 247 任务。Opus5 在全部五类任务拿下最高总分——Brief 50.38、GDD 59.68、Skeleton 54.06、修复 83.46、移植 72.40，但三类构建任务的最佳分均未过 60，可见'可玩'与'忠实实现机制'间仍有显著鸿沟。第二名随任务而变（Brief 为 Grok4.6，余为 GPT-5.6 Luna）。组件层面：Skeleton 的 Content 分仅 11.97–36.93，内容实现是普遍短板；修复任务 Restoration 跨度 35.27–90.18 而 Retained routes 普遍高于 96，可见找对根因难；Opus5 的高分伴随 3.3 倍于 GPT Luna 的 token 消耗。GPT 的头号问题是需求遗漏（56.4%）与引擎集成（17.3%），GLM 以玩法逻辑错误为主（52.2%）。参考视频主要提升视觉呈现而内容构成反降。评测有效性：可执行检查达 92.59% 平衡准确率（411/452 接受、705/748 检出），视频 VLM 判定仅 78.41%；视觉量规与人工评分 Spearman $\rho=0.829$。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Brief-to-Game（简报到游戏，41 题） | 总分（0–100） | Opus5 50.38 | 次优 Grok4.6 39.01 | +11.37 |
| GDD-to-Game（设计文档到游戏，41 题） | 总分（0–100） | Opus5 59.68 | 次优 GPT-5.6 Luna 52.67 | +7.01 |
| Skeleton Completion（骨架补全，41 题） | 总分（0–100） | Opus5 54.06 | 次优 GPT-5.6 Luna 43.10 | +10.96 |
| Bug Repair（注入故障修复，83 例） | 总分（0–100） | Opus5 83.46 | 次优 GPT-5.6 Luna 58.05 | +25.41 |
| Godot-to-Unity Porting（跨引擎移植，41 题） | 总分（0–100） | Opus5 72.40 | 次优 GPT-5.6 Luna 59.85 | +12.55 |
| 功能判定有效性（100 个智能体构建游戏、1200 条人工标注断言） | 平衡准确率（%） | 可执行检查 92.59 | 视频 VLM judge 78.41 | +14.18 个百分点 |
| 视觉质量评估（200 段游戏录像人工对比） | 与人工评分的 Spearman ρ | 量规 VLM 0.829 | 无对照基线（另报 MAE 0.103、重复打分 SD 0.034） | — |
局限与改进
作者承认三点局限：参考游戏仅 41 个，对大型项目和长期开发的覆盖有限；每个模型只搭配一个智能体框架，结果反映的是模型与框架的联合能力而非模型本身；Godot 到 Unity 的移植只是对引擎迁移的初步研究。我的补充观察：其一，参考游戏全部是单机、确定性（GDD 明确写'无程序随机性'）、中小规模（每游戏 1,153–11,024 行、中位 3,367 行、场景中位 32 个），与真实商业游戏的网络同步、存档系统、程序生成相距甚远；其二，插桩接口依赖提交方诚实且正确地绑定 gb_* 语义，错误或投机绑定可能系统性扭曲功能得分，论文未讨论防对抗鲁棒性；其三，视觉分占构建类总分 15%、其中 Visual Presentation 组权重高达 0.45，却依赖身份未披露的 VLM judge，且 ρ=0.829 距离完美一致仍有可观测差距；其四，论文未讨论训练数据污染风险——2026 年的前沿模型可能见过 Kenney 资产包与常见 Godot 平台跳跃模板；其五，83 个修复案例的故障全部为人工注入（状态未跨关重置、读写不一致等），分布上有别于真实项目缺陷。
独立分析的弱点
独立分析出五个弱点。第一，无输入对照只能验证'演示结果依赖输入'，无法保证规约的全部机制都被实现——而需求遗漏恰是最大错误类别（GPT 56.4%、Opus 36.9%），说明当前证据采样仍不足；改进方向是从 GDD 自动推导必需行为清单，做覆盖度审计并要求智能体自报未实现项。第二，模型与框架捆绑评测且缺乏等算力控制：Opus5 消耗约 3.3 倍于 GPT Luna 的输入 token 才取得领先，缺少'同预算谁最强'的结论；应增加固定预算对比。第三，视觉评审可信度上限明显：Visual Presentation 组权重 0.45 却只有 ρ=0.829、重复打分 SD 0.034，噪声不可忽略；可引入多人标注与置信区间，或把部分视觉条款改造成可执行检查。第四，移植任务的 Visual 分极低（GPT Luna 31.60、GLM 12.13），暴露跨引擎资产与动画迁移工具链缺失，但论文未给出失败细节，无法指导工具建设。第五，修复故障由人工注入且类型集中（状态未重置、读写不一致），在此之上训练的'修复能力'可能过拟合干净合成故障；应引入从真实项目 issue 挖掘的缺陷。
未来方向
作者明确提出四个方向：扩充游戏集合、在受控预算下比较不同智能体框架、评测更长期的开发工作流、扩大人工评估以细化视觉量规并厘清自动分数与玩家体验的关系。基于本文成果还能进一步延伸：第一，把 247 个确定性任务用作强化学习环境——认证回放加状态断言天然适合做奖励信号，可训练专门的游戏开发智能体；第二，把错误分析揭示的三类问题转化为智能体工作流内的自动检查清单：需求覆盖跟踪（治需求遗漏）、触发条件演练与状态检查（治玩法逻辑错误）、脚本-场景-资源连接检查（治引擎集成错误）；第三，扩展到多人、存档、程序生成等动态玩法，研究无输入对照在非确定性设定下的变体；第四，增加 Unity 到 Godot 的逆向移植与引擎版本升级迁移，把'行为保持'研究推向更一般的软件演化场景；第五，沿 Figure 4 的资源-分数前沿研究测试时算力分配与成功率的 scaling 规律。
复现评估
复现门槛较高。论文未给出公开代码或数据仓库链接，247 个任务依赖一整套人工构建的语料：41 个 Godot 游戏（合计 168,335 行 GDScript、1,587 个场景、138 段录像）、83 个经参考-缺陷行为差校验的注入故障案例、658 条游戏专属视觉量规，以及在参考游戏上逐一编排验证的认证路由库。运行环境需要 Godot 4.5.1 与 Unity Editor 6000.3.23f1 双引擎加沙箱化的智能体工作区。好消息是附录规格相当完整：接口 schema（附录 C）、各模式评分标准与组件权重（附录 D，构建类客观 85% + VLM 15%、修复乘法聚合）、资源核算规则（附录 E）与全部 agent/VLM prompt 原文（附录 H）均有披露，理论上可照此重建评测器。算力成本主要在 API 调用：单配置单任务平均消耗 2.5–8.5M 输入 token，六模型 × 247 任务的完整复现估计需要数十亿 token 预算。对个人或课程项目，现实的路径是按照其方法论构建 5–10 个游戏的小型子集来验证想法，而非复刻全量基准。
论文图表
总览图：中央是智能体利用提供的资产与玩法演示，通过编码与试玩复现目标外观和行为的工作流；外围展示五种任务模式（简报生成、GDD 实现、骨架补全、缺陷修复、跨引擎移植）如何从同一参考材料变化出不同的要求与起始项目。
一图看懂整个基准的设定：任务从哪里来、智能体拿到什么材料、要交付什么、评测什么，是理解论文范围的最快入口。