GameCraft-Bench 深度拆解：AI 游戏生成的「最后一公里」有多难？

论文： GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?
作者： Tongxu Luo 等（港中文深圳、腾讯混元、上海交大、新加坡国立等）
链接： https://arxiv.org/abs/2606.17861
项目网站： https://tongxuluo.github.io/gamecraft-bench-website

一、一句话定位

GameCraft-Bench 是首个要求 coding agent 在真实游戏引擎（Godot）中，从零构建完整可玩游戏，并通过实际交互验证可玩性的基准测试。它像一面照妖镜，照出了当前最强 AI 在游戏生成这件事上的真实能力边界——最好的 agent 也只有 41.46% 的通过率。

二、为什么要做这个基准？

现有基准的「三宗罪」

论文尖锐地指出，现有的游戏生成基准都只在某个维度上达标，但没有一个同时满足三个核心要求：

问题本质： 游戏不是普通代码。它的正确性不能通过单元测试或静态检查来验证——玩家按下一个键，世界有没有正确响应？ 这才是游戏的本质。

三、三大评估准则（Desiderata）

论文提出了评估游戏生成基准的「黄金三准则」：

1. Engine Grounding（引擎落地）

游戏必须在真实的游戏引擎中开发和运行。

为什么重要？因为游戏行为不是由源代码单独定义的，而是由引擎级语义共同决定的：场景层级、脚本生命周期、资源加载、输入分发、物理系统、渲染管线、项目配置……

脱离真实引擎的评估，本质上是在做一个「看起来像游戏的编程练习」，而不是真正的游戏开发。

GameCraft-Bench 的选择： Godot 4

• ✅ 开源免费
• ✅ 轻量、命令行/无头模式友好
• ✅ 原生 2D 工作流
• ✅ 场景文件是文本格式（便于 agent 编辑）

2. Artifact Completeness（产物完整）

评估单元必须是完整可启动的游戏项目，而不是零散的代码片段。

一个可玩的游戏需要：项目元数据、入口场景、脚本、资源、UI 元素、输入映射、配置文件……缺一不可。

GameCraft-Bench 的强制机制： 如果项目无法启动，Build=0，最终得分为零。这防止了 agent 通过提交「看起来像游戏的部分组件」来刷分。

3. Interactive Verification（交互式验证）

游戏必须通过实际交互来判断可用性，而非静态检查。

许多关键失败在运行前是不可见的：

• 控制无响应
• 碰撞检测错误
• 敌人不活动
• 目标无法到达
• UI 反馈缺失
• 状态转换损坏
• 视觉场景在游玩时变得无法辨识

GameCraft-Bench 的做法： agent 提交游戏项目 + 可重放的交互 traces（录制的鼠标和键盘事件）。Verifier 在固定 1280×720 视口中重放这些 traces，记录游戏视频和采样帧，然后用多模态 judge 评分。

四、五阶段评估 Pipeline

┌─────────────┐     ┌──────────────┐     ┌──────────┐     ┌─────────┐     ┌────────┐
│ 1. 任务打包  │ ──→ │ 2. Agent生成 │ ──→ │ 3. 构建门 │ ──→ │ 4. 重放 │ ──→ │ 5. 评分 │
└─────────────┘     └──────────────┘     └──────────┘     └─────────┘     └────────┘
   游戏规格+环境        Godot项目+traces    能否启动？        交互视频+帧       多模态评分

Stage 1: 任务打包

每个任务包含三个对象：

• 公开的游戏规格（自然语言描述）：玩家幻想、核心循环、机制、目标、内容范围、视觉风格
• Godot 开发环境：可编辑工作区、运行时、共享资源、文档、辅助工具
• 隐藏的评分 rubric：将同样意图分解为可观察的需求标准（agent 看不到）

Stage 2: Agent 生成

Agent 在工作区中构建 Godot 项目，可以：

• 创建场景、编写脚本、配置输入
• 使用共享资源、运行项目、检查截图
• 迭代调试

提交物 = 完整 Godot 项目 G + 可重放交互 traces Π

Stage 3: 构建门（Build Gate）

Verifier 检查：

• 项目结构是否完整
• 能否在 Godot 运行时启动
• traces 是否能被解析

任一失败 → Build=0 → 最终得分=0

Stage 4: 交互重放（Replay）

对每个有效 trace：

• 启动全新 Godot 实例
• 在 1280×720 视口中重放鼠标和键盘事件
• 录制游戏视频（用于人工检查）
• 采样帧（2fps，用于 judge 评分）

为什么需要 agent 提交 traces？

如果没有 traces，verifier 必须先推断每个游戏应该怎么玩，才能把验证变成自主探索问题。不同 verifier 的探索策略会导致分数差异。通过让 agent 提交「标准操作流程」，评估聚焦于agent 能否构建一个能按预期响应的游戏，而非 verifier 的探索能力。

Stage 5: 多模态评分

使用 GPT-5.5 作为多模态 judge，基于采样的游戏画面帧和隐藏 rubric 评分。

四个评分维度（权重分配）：

权重设计意图： 优先 Content Depth 和 Art & Presentation，因为完整的游戏应该超越最小可玩原型。

最终得分公式：

Score = BUILD × (0.15×Mechanics + 0.35×Depth + 0.15×Visuals + 0.35×Art)

五、任务集：140 任务 × 15 游戏家族

质量控制： 每个任务由 12 名有丰富游戏经验的标注员创作。标注员需要：

1. 撰写自然语言游戏规格
2. 设计隐藏评分 rubric
3. 编写一个最小可玩的「oracle solution」来验证任务一致性

如果 oracle 无法达到预期游戏状态，或 rubric 某项缺乏重放证据支持，则修订规格和 rubric 直至一致。

六、实验结果：41.46% 的天花板

7 个 frontier agent 配置

关键观察

1. 即使是最好的 agent，也只有 41.46%

这意味着当前 frontier coding agent 距离可靠的端到端游戏生成还很远。它们能产出「可识别的游戏机制」，但无法稳定地将这些机制组装成完整的、有足够内容深度和视觉呈现的游戏。

2. Core Mechanics > Content Depth > Visuals > Art

所有 agent 都呈现相同的模式：核心机制得分最高（~55%），内容深度次之（~39%），功能视觉和美术表现最低。

这说明：做一个「能动的游戏原型」容易，做一个「完整的游戏」很难。

3. 构建通过率 ≠ 游戏质量

大多数强 agent 能通过构建门（项目能启动），但最终得分仍然很低。这说明「能跑起来」和「是个好游戏」之间有巨大鸿沟。

4. DeepSeek-V4-Pro 的异常

DeepSeek 的构建通过率和有效 trace 率之间存在巨大差距——它经常忽略或违反演示 trace 的要求，导致大量零分任务。

七、深度分析：Agent 的成败模式

成功信号：视觉反馈是调试的关键

游戏生成最难的是调试。很多失败只有渲染后才能发现：错误的相机取景、不可读的 UI、缺失的视觉反馈、损坏的关卡布局……

Kimi-K2.6 的案例：

• 140 个任务中，共截屏检查 2,998 次（平均每任务 21.41 次，中位数 19 次）
• 只有 4 个任务没有使用截图
• 相比之下，GPT-5.5 仅使用 268 次（1.91/任务）

图 7 展示了 Kimi 在 Strategy-Skirmish 中的典型调试过程：

1. 检查渲染帧 → 发现单位位置不对
2. 检查渲染帧 → 发现选择高亮缺失
3. 调整网格和回合指示器布局
4. 再次检查确认修复

结论：视觉交互将游戏生成从「一次性代码合成」转变为「感知引导的迭代」。

失败信号：工具调用量 ≠ 质量

MiMo-V2.5-Pro 的模式：

• 「先写后调」策略：快速搭建完整文件集，然后进入漫长的调试阶段
• Shell 命令占总工具调用的 56.3%
• 代码读写和编辑仅占 16.5%
• 中位数 128 次工具调用/任务

但工具调用量与任务质量几乎无关（r = +0.016）：

零分任务的共同特征：构建了有效项目，但没有提交 demo traces → 所有 rubric 维度都无法评分。

核心问题： MiMo 的「先写后调」策略前端加载了代码生成，但经常错过了关闭评估循环的 demo trace 交付。

评分系统的可靠性

稳定性测试： 固定游戏证据，重复运行 GPT-5.5 judge 10 次

• Kimi-K2.6：Card Game 标准差 0.0037，Simulation 标准差 0.0038
• Opus-4.7：标准差 0.0050 和 0.0036

结论：评分足够稳定，排名对 judge 噪声具有鲁棒性。

人工校准： 在 3 个家族上对比 judge vs 人类评分

Judge 整体略宽容，尤其在 Content Depth 和 Art & Presentation 上。Functional Visuals 上反而更严格。

能力分解：游戏生成不是单一能力

四个 rubric 维度之间的相关性分析（Kimi-K2.6）：

• Mechanics ↔ Depth: r=0.61
• Mechanics ↔ Visuals: r=0.53
• Art ↔ Visuals: r=0.11 ⚠️

结论：美术表现和功能视觉是弱耦合的。 一个机制上可玩的游戏，不自动等于视觉连贯、风格统一的游戏。

八、与相关工作的对比

九、局限性与未来方向

当前局限

1. 仅 2D + Godot： 不覆盖 3D 游戏、Unity、Unreal、多人系统
2. 音频评估缺失： 节奏、恐怖、体育游戏的音频部分仅通过视觉行为间接评估
3. Judge 偏差： 多模态 judge 仍可能有模型偏差、API 漂移、视觉理解限制
4. 不衡量「好玩」： 只衡量是否遵循规格、实现机制，不衡量主观趣味性

未来方向

1. 3D 游戏支持： 扩展到 Unity/Unreal，覆盖更复杂的游戏类型
2. 音频评估： 引入音频感知的多模态 judge
3. 长期游戏： 评估数小时级别的游戏进度和经济平衡
4. 人机协作： 评估 agent 与人类设计师的协作能力
5. 多引擎对比： 同一游戏规格在不同引擎中的实现对比

十、核心启示

对 AI 游戏生成的启示

1. 「能写代码」≠「能做游戏」

游戏是交互系统，不是代码集合。当前 agent 在代码层面的能力已经相当强，但在系统设计、内容编排、视觉呈现、交互打磨上还有巨大差距。

2. 视觉反馈是必需品，不是锦上添花

Kimi 的高截图使用率和其相对较好的表现，证明了感知-行动循环对游戏生成的重要性。未来的 agent 架构应该原生支持视觉感知。

3. 任务完成度是瓶颈

MiMo 的案例说明，努力不等于结果。agent 需要学会「什么时候算做完了」——提交完整的 traces、确保所有评估维度都被覆盖。

4. 游戏生成是复合能力

Mechanics、Content、Visuals、Art 是弱耦合的。未来的 agent 可能需要专门的能力模块来处理不同维度，而非单一通用模型。

对 Benchmark 设计的启示

1. 交互式验证不可替代

静态检查、单元测试、代码审查都无法捕捉游戏的本质。必须通过实际交互来验证。

2. 完整产物是必要条件

评估单元必须是可启动的完整项目，否则 agent 会投机取巧。

3. 隐藏 rubric 防止过拟合

如果 agent 能看到评分标准，它可能会针对性地刷分。隐藏 rubric 迫使 agent 真正理解游戏规格。

总结

GameCraft-Bench 是 AI 游戏生成领域的一个重要里程碑。它首次建立了一个严格、可复现、端到端的评估框架，并揭示了当前 frontier agent 的真实能力边界。

41.46% 的分数不是失败，而是一个诚实的起点。 它告诉我们：AI 游戏生成还有很长的路要走——不仅是写更多代码，而是学会设计完整的交互体验。

最有价值的可能是它的方法论： 三大 desiderata 不仅适用于游戏生成，也适用于任何交互式创意系统的评估——从交互式小说到虚拟世界，从教育软件到沉浸式体验。

" evaluating executable creative software systems requires interaction-grounded assessment beyond static code inspection, build success, or visual plausibility alone."
— 论文结论

参考：arXiv:2606.17861 | tongxuluo.github.io/gamecraft-bench-website
#GameGeneration #CodingAgent #Godot #Benchmark #AI #小凯