💬 NLP

GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?

本文介绍了 GameCraft-Bench，这是一个包含 140 个基于 Godot 的任务的基准测试，旨在评估编程智能体端到端生成完整、可玩游戏的能力，研究揭示了尽管当前前沿模型能够实现可识别的机制，但在实现人工制品完整性和交互连贯性方面仍面临显著困难。

原作者： Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan

发布于 2026-06-17

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan Liu, Xin Lai, Chenxin Li, Yiduo Guo, Zhexin Zhang, Xinyuan Wang, Tianyi Bai, Ziniu Li, Benyou Wang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你雇佣了一位机器人厨师，并给了它一份复杂的多道菜晚餐食谱。你不仅仅希望机器人把食谱写在纸上，你还希望它能真正把这顿饭做出来、摆好盘并端上来，这样你才能品尝到味道。

这本质上就是这篇名为 GameCraft-Bench 的论文所探讨的内容。这是一个测试，旨在观察 AI 编程智能体（AI coding agents）是否真的能从零开始“烹饪”出一款可玩的视频游戏，而不仅仅是写出它的代码。

以下是使用简单类比对该论文核心思想的拆解：

1. 问题所在：“食谱 vs. 佳肴”

过去，当我们测试 AI 的编程能力时，我们主要检查代码在纸面上看起来是否正确（就像检查食谱中的食材清单是否正确一样）。但对于视频游戏来说，仅仅看代码是不够的。一款游戏需要能够运行，图形需要显示出来，且玩家需要能够移动角色并看到反馈。

作者认为，要真正测试 AI 制作游戏的能力，我们需要三个要素：

真实的厨房（引擎落地/Engine Grounding）： AI 必须在一个真实的引擎中工作（他们使用了流行的免费工具 Godot），而不是一个虚假或简化的版本。这就像要求厨师使用真正的炉灶，而不是玩具炉灶。
完整的佳肴（产物完整性/Artifact Completeness）： AI 不能只给你提供一种食材（比如一段关于跳跃角色的脚本）。它必须交付一整个打包好的、可以随时启动的游戏。不能有任何缺失的部分。
品尝测试（交互式验证/Interactive Verification）： 你不能只看做好的菜，你必须吃掉它。游戏必须是可以被玩到的。AI 的成功是通过实际运行游戏、按下按键并观察世界是否做出正确反应来评判的。

2. 测试方法：GameCraft-Bench

研究人员建立了一个巨大的测试厨房，名为 GameCraft-Bench。

菜单： 他们创建了 140 个不同的挑战，涵盖 15 种类型的游戏（如平台跳跃、赛车、策略和恐怖游戏）。
流程：
1. 给 AI 一个自然语言描述（例如：“制作一个 2D 平台跳跃游戏，玩家可以收集金币并躲避敌人”）。
2. AI 在 Godot 引擎中构建游戏。
3. AI 还必须记录一个“演示轨迹”（demo trace）——即一段展示如何玩这款游戏的视频脚本，以证明其有效性。
4. 一个计算机系统使用该脚本“玩”游戏，记录视频，然后一个智能 AI 评委通过观看视频进行评分。

3. 结果：“擅长写食谱，不擅长做饭”

结果令人惊讶，甚至让 AI 社区感到有些汗颜。即使是最聪明、最先进的 AI 模型（如 Opus-4.7 和 GPT-5.5）也表现挣扎。

得分： 最优秀的 AI 在测试中仅获得了约 41% 的分数。大多数模型的得分低于 40%。
做得好的地方： AI 在构建“核心循环”（core loop）方面表现尚可。如果你要求一个角色可以跳跃的游戏，角色通常是可以跳跃的。它们可以构建引擎部分。
失败的地方： 它们在将所有部分整合为一个完整的体验方面遇到了困难。
- 内容缺失： 它们经常制作出的游戏过短，或者没有可以推进的关卡。
- 视觉破碎： 图形可能存在，但并不合理（例如，玩家看不见敌人，或者 UI 界面损坏了）。
- “演示”差距： 许多 AI 构建了游戏，但忘记了记录证明其有效的“演示轨迹”。这就像厨师做好了菜，却忘了为评委摆盘。

4. 关键发现（“为什么”）

论文深入探讨了 AI 失败的原因：

眼见为实： 表现最好的 AI 是那些在构建过程中会观察游戏屏幕的 AI。它们将视觉输出视为一种调试工具。如果角色看起来很奇怪，它们会修正代码。那些只写代码而不看屏幕的 AI 犯错更多。
忙碌并不代表更好： 一个 AI 模型（MiMo）编写了大量的代码并运行了许多命令，但它并没有获得更高的分数。这就像一位厨师在疯狂地切菜，却从未真正把菜煮熟。如果错过了最后一步，做更多的工作并不保证能获得更好的结果。
技能差异： 让“跳跃”机制生效（机制/Mechanics）与让游戏看起来漂亮（美术/Art）或拥有足够关卡（内容/Content）是不同的。AI 可能擅长其中一项，但在另一项上表现糟糕。它们并非全部关联在一起。

5. 结论

论文得出结论，虽然 AI 在编写代码方面变得非常出色，但端到端的游戏创作仍然是一个巨大的挑战。

目前的 AI 可以构建游戏的“碎片”或简单的原型，但它们还无法可靠地将人类的一个创意想法转化为一个精致、可玩且完整的游戏包。从“编写看起来正确的代码”到“交付一个运作良好的系统”，这之间的鸿沟依然非常宽阔。

简而言之：AI 可以写出食谱，但它仍在学习如何烹饪完整的佳肴并将其呈献给顾客。

技术摘要：GameCraft-Bench

问题定义

本文探讨了端到端游戏生成（end-to-end game generation）的挑战，其定义为自主智能体将自然语言游戏规范 ( $s$ ) 转化为特定开发与运行环境 ( $E$ ) 内的可玩交互式系统 ( $G$ ) 的过程。与传统的以代码正确性或单元测试为衡量标准的编程任务不同，游戏生成要求产出一个连贯、可启动的成品，并能对玩家输入做出实时响应。

作者认为，现有的评估方法未能捕捉到这一任务的完整复杂性。目前的基准测试通常侧重于：

基于 Web 的游戏，缺乏真实引擎环境的复杂性。
对现有项目的局部编辑，而非完整的构建。
对代码或资产进行静态检查，这无法验证实际的游戏玩法行为。

为了解决这些问题，论文将端到端游戏生成形式化为映射 $(s, E) \mapsto G$ ，并确定了有效基准测试的三个关键设计准则（desiderata）：

引擎落地（Engine Grounding）： 开发必须在具有原生文档、资产和运行时约束的真实游戏引擎中进行。
产物完整性（Artifact Completeness）： 智能体必须交付一个完整的、可启动的游戏项目（包括元数据、场景、脚本和资产），而非仅是部分代码或原型。
交互式验证（Interactive Verification）： 评估必须基于观察到的游戏交互（玩家动作与系统响应），而非静态代码分析。

方法论：GameCraft-Bench

作者通过 GameCraft-Bench 在 Godot 4 引擎中实例化了这些设计准则，该基准测试旨在评估编程智能体。

1. 任务套件

规模： 涵盖 15 个不同游戏家族（如平台跳跃、策略、肉鸽、视觉小说、经营类）的 140 个任务。
任务结构： 每个任务 $\tau = (s, E, \rho)$ $τ = (s, E, ρ)$ 由以下部分组成：
- $s$ ：描述玩家幻想、核心循环和机制的自然语言规范。
- $E$ ：提供工作空间、工具链和共享资产的基于 Godot 的环境。
- $\rho$ ：由验证器使用的隐藏评估细则。

2. 评估流水线

该基准测试采用了一个五阶段流水线（图 5）：

任务打包： 智能体接收规范和环境。
智能体生成： 智能体生成一个完整的 Godot 项目 ( $G$ ) 和一组可重放的交互轨迹 ( $\Pi$ )，其中包含定时键盘/鼠标事件。
构建门槛（Build Gate）： 验证器尝试启动项目。如果构建失败或轨迹无法解析，则得分为零。
重放： 验证器在无头（headless）Godot 实例中重放轨迹，记录游戏视频并采样帧（2 FPS）。
评分： 多模态评判员根据隐藏细则，从四个维度对游戏证据进行评分：
- 核心机制 (M)： 规则、状态转换和目标。
- 内容深度 (D)： 进度、多样性和运行范围。
- 功能性视觉 (V)： 可读性、反馈和 UI 稳定性。
- 艺术与呈现 (A)： 美学连贯性和“创作感”。
- 最终评分公式： $Score = BUILD \times (w_M M + w_D D + w_V V + w_A A)$ ，权重优先考虑内容深度和呈现效果。

3. 引擎选择

选择 Godot 是因为它具有开源特性、轻量化设置、原生的 2D 工作流、基于文本的场景文件以及命令行/无头执行能力，这些对于实现可重复的自动化评估至关重要。

关键结果

作者在完整的基准测试上评估了七种前沿编程智能体配置（包括 Claude Code, Codex, Kimi Code 和 Code Buddy）。

整体表现： 端到端游戏生成仍然是一个尚未解决的问题。表现最强的智能体（Claude Code 配搭 Opus-4.7）取得了 41.46% 的总分。大多数其他智能体的得分低于 40%，部分（如 DeepSeek-V4-Pro）得分仅为 2.15%。
类别细分：
- 机制： 智能体在此方面的表现相对较好（例如 Opus-4.7 得分为 55.34%），通常能创建可识别的局部交互循环。
- 内容与呈现： 在内容深度和艺术/呈现方面的得分显著下降，表明智能体难以将机制组装成完整、精致且连贯的系统。
执行 vs. 可玩性： 虽然许多智能体实现了较高的“构建通过率”（成功启动游戏），但它们经常无法提供有效的重放轨迹，或者未能通过轨迹实现预期的游戏玩法，从而导致最终得分较低。

诊断发现

视觉反馈至关重要： 利用渲染屏幕检查（如 Kimi-K2.6）的智能体展现出更好的调试能力，能够纠正仅靠源代码无法察觉的问题，如 UI 对齐错误或关卡布局损坏。
工具使用 $\neq$ 质量： 高频次的工具调用（尤其是 Shell 命令）与高分之间并不相关。成功取决于能否闭环完成“构建、提供演示轨迹、确保可玩性”的过程。
部分分解（Partial Factorization）： 机制、内容和视觉的表现之间仅存在中度相关。一个智能体可以生成一个机制功能完备但缺乏内容深度或视觉润色的游戏。

重要性与主张

论文声称 GameCraft-Bench 通过将关注点从代码正确性转向交互式系统正确性，为评估创意型智能体建立了新标准。

基准测试契约： 它定义了一个要求智能体在真实引擎中操作、交付完整产物并通过交互进行评判的基准测试契约。
当前局限性： 结果表明，当前的前沿智能体虽然能够生成类似游戏的软件“片段”，但尚无法可靠地将自然语言规范转化为完整、连贯且视觉一致的可玩游戏体验。
评估范式： 该研究认为，评估可执行的创意系统需要基于交互的评估（可玩性），这超越了单纯的静态代码检查、构建成功率或视觉合理性。

作者强调，尽管目前该基准测试局限于 2D Godot 游戏和视觉评估（不包括音频），但它提供了一个严谨的框架，用于诊断当前智能体在构建复杂交互系统方面的具体差距。