GameDevBench：通过游戏开发评估智能体能力 GameDevBench: Evaluating Agentic Capabilities Through Game Development
首个游戏开发基准测试，评估LLM智能体在复杂多模态游戏开发任务中的表现
前置知识
LLM智能体（LLM Agent）
以大语言模型为核心，能够自主执行复杂任务的系统。智能体通常具备代码阅读、文件操作、工具调用等能力，可以像人类开发者一样与开发环境交互。在本研究中，智能体需要在Godot游戏引擎中完成各种游戏开发任务，包括编写脚本、管理资源文件、设置场景节点等。
本文的核心研究对象就是LLM智能体在游戏开发场景中的能力边界，理解智能体的工作方式是评估其表现的前提
多模态理解（Multimodal Understanding）
指模型同时处理和理解多种类型输入（如文本、图像、视频、音频）的能力。在游戏开发中，智能体需要理解精灵图（spritesheet）中的动画帧、着色器（shader）的视觉效果、场景布局的空间关系等。这要求模型不仅能处理代码文本，还要具备视觉理解和空间推理能力。
本文发现多模态理解是当前智能体的主要瓶颈，理解2D/3D图形任务的成功率远低于纯逻辑任务
Godot游戏引擎
一个完全开源的游戏开发引擎，采用MIT许可证发布。Godot使用场景树结构组织游戏元素（节点），支持GDScript脚本语言，提供场景编辑器、脚本编辑器和多种上下文编辑器（动画、音频、着色器等）。2024年和2025年在Steam上分别有770和1185个游戏发布使用Godot。
本研究选择Godot作为评估环境，因为其开源特性便于扩展和发布，且项目可以完全用代码表示，便于智能体操作
SWE-Bench
软件工程领域的经典基准测试，用于评估智能体解决真实世界GitHub issues的能力。SWE-Bench的任务主要涉及代码修改和bug修复，是衡量智能体软件开发能力的重要参考。
本文将GameDevBench与SWE-Bench进行对比，指出游戏开发任务的复杂度是SWE-Bench的三倍以上
MCP服务器（Model Context Protocol Server）
一种为模型提供上下文信息的协议服务器。在本文中，研究者开发了一个MCP服务器来加载Godot编辑器、截取编辑器当前状态的截图，并将图像返回给智能体。这使得智能体能够获得游戏场景、节点树、节点检查器等视觉信息。
MCP服务器是本文提出的两种多模态反馈机制之一，用于验证视觉反馈对智能体性能的提升效果
研究动机
当前LLM智能体在软件开发领域取得了显著进展，但多模态智能体的发展相对滞后。一个关键挑战是缺乏能够同时结合软件开发复杂性和深度多模态理解需求的评估平台。现有的软件开发基准测试（如SWE-Bench）主要是单模态的，专注于代码修改；而前端开发基准（如Design2Code）虽然涉及多模态，但任务类型较为单一，主要集中在UI生成。游戏开发作为一个天然需要多模态理解的复杂软件开发领域，却被研究社区严重忽视。智能体需要在大型密集代码库中工作，同时操作着色器、精灵图、动画等本质上多模态的资产，但目前没有专门的基准来评估这种能力。
本文的目标是本文的目标是创建GameDevBench，这是第一个专门用于评估智能体游戏开发能力的基准测试。具体目标包括：构建多样化的游戏开发任务集（最终包含132个任务），覆盖2D图形、3D图形、游戏逻辑和用户界面等多个维度；设计可确定性验证的测试框架，避免使用LLM-as-Judge等非确定性评估方法；探索多模态反馈机制（编辑器截图和运行时视频）对智能体性能的影响；系统评估当前最先进的LLM智能体在游戏开发任务中的表现。
与已有工作不同的是，本文的独特切入角度在于将游戏开发定位为连接软件开发和计算机使用的桥梁领域。与纯软件开发任务不同，游戏开发任务本质上是多模态的，要求智能体理解图像、动画、空间布局等视觉信息；与计算机使用任务不同，游戏开发允许通过代码输出来解决问题，避免了纯动作空间的复杂性。这种双重特性使得游戏开发成为评估多模态智能体能力的理想测试平台。此外，本文采用的从在线教程自动构建任务的流水线方法，使得基准测试可以持续更新，解决了传统基准测试容易过时的问题。
核心方法
GameDevBench的构建采用了一个多阶段流水线方法，从在线教程自动构建游戏开发任务。整体思路是：首先收集Godot游戏开发教程（包括YouTube视频教程和网页文字教程），然后利用AI智能体从教程中自动构建任务，接着通过自动化检查和人工标注进行任务精炼，最后使用Godot内置测试框架进行确定性验证。这种方法的核心直觉是，游戏开发教程天然包含完整的解决方案，可以作为构建高质量任务的数据源。技术路线包括数据准备、自动任务构建、任务精炼和人工标注四个阶段，每个阶段都有明确的质量控制机制。
本文的核心创新点是将游戏开发作为评估多模态智能体能力的测试平台，这与现有基准测试有本质区别。首先，与SWE-Bench等软件开发基准不同，GameDevBench的任务本质上是多模态的，要求智能体理解精灵图、着色器、动画等视觉资产，而不仅仅是修改代码。其次，与Design2Code等前端基准不同，游戏开发任务更加多样化，涵盖游戏逻辑、2D/3D图形、用户界面等多个维度。第三，与计算机使用基准不同，游戏开发允许通过代码输出解决问题，使得评估更加确定性和可重复。最后，本文提出的两种多模态反馈机制（MCP服务器截图和运行时视频记录）为智能体提供了视觉验证能力，这是现有基准测试中较少探索的方向。
方法步骤详情
GameDevBench的构建分为四个主要阶段：阶段1是数据准备，从YouTube收集102个视频教程（平均时长29分钟），从中筛选出57个可用教程；从Godot Recipes网站收集99个网页教程，使用LLM筛选出31个适合构建任务的教程。阶段2是自动任务构建，使用Codex Agent（GPT-5系列模型）从每个教程中创建任务，要求指令遵循教程内容、任务文件基于现有仓库文件、测试只验证指令中明确要求的功能。这一阶段产生了202个初始任务，平均每个教程1.3个任务。阶段3是任务精炼，基于对41个任务的初步研究（43%无问题、50%有小问题、7%有重大问题），构建了自动检查清单来识别和修复常见错误，如场景偏离摄像机、测试断言不存在的指令、引用教程其他部分等。阶段4是人工标注，8名标注者（其中5名有游戏开发经验）审查所有任务，确保正确性和可解决性，并创建任务变体（如使用不同动画帧的精灵图），最终产生115个基础任务和17个变体任务。
技术新颖性
GameDevBench的技术新颖性体现在多个方面。首先，这是第一个专门针对游戏开发的智能体评估基准，填补了该领域的空白。其次，本文提出的从在线教程自动构建任务的流水线方法具有创新性，解决了游戏开发领域缺乏标准开源代码仓库的问题。第三，本文设计的多模态反馈机制（MCP服务器和运行时视频）为智能体提供了视觉验证能力，这在现有基准测试中较少被探索。第四，本文的任务分类方法（按技能集和编辑器类型两个维度）为理解游戏开发任务的多样性提供了新的视角。第五，本文的测试框架利用Godot内置功能进行确定性验证，避免了LLM-as-Judge的非确定性问题，同时保持了多模态任务的特性。最后，本文的基准测试可以持续更新，解决了传统基准测试容易过时的问题。
实验结果
本文的核心发现揭示了当前LLM智能体在游戏开发任务中的能力边界和改进方向。首先，游戏开发对即使是能力最强的模型也极具挑战性：在没有多模态反馈的情况下，GPT、Claude和Gemini三大商业模型家族的基线表现分别为34.1%、39.4%和46.2%。最佳智能体（Gemini 3 Pro结合视频反馈）仅解决了54.5%的任务。其次，智能体在不同技能和编辑器类别上的表现存在显著差异：在游戏逻辑任务上的平均成功率为46.9%，而在2D图形和动画任务上仅为31.6%，表明多模态理解能力是主要瓶颈。第三，多模态反馈机制持续提升智能体性能：MCP服务器使Gemini 3 Flash从47.0%提升到50.0%，视频反馈使Claude Sonnet 4.5从33.3%提升到47.7%。第四，智能体框架的选择对性能有显著影响：Claude Sonnet 4.5从原生框架的33.3%提升到OpenHands的43.2%，但Gemini 3 Flash在OpenHands上从47.0%下降到36.4%，这可能是由于工具不兼容导致的。第五，成本与性能存在权衡关系：启用多模态反馈几乎总是增加成本以换取性能提升，Gemini 3 Flash是性价比最高的模型。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| GameDevBench游戏开发任务（132个任务） | pass@1（首次通过率） | 最佳结果：Gemini 3 Pro + 视频反馈 54.5%；Gemini 3 Flash + 反馈 52.3%；Claude Opus 4.5 + 两种反馈 50.0% | 无反馈基线：Gemini 3 Pro 46.2%，Claude Opus 4.5 39.4%，GPT 5.1 Codex 34.1% | 视频反馈使Claude Sonnet 4.5从33.3%提升到47.7%（相对提升42%）；MCP反馈使Gemini 3 Flash从47.0%提升到50.0% |
| 游戏逻辑任务 | 平均成功率 | 46.9% | 2D图形任务31.6% | 游戏逻辑任务比2D图形任务成功率高15.3个百分点 |
| SWE-Bench对比 | 平均代码行数和文件修改数 | 106.2行代码，5.0个文件，3.4种文件类型 | SWE-Bench约为35行代码，2个文件 | 代码行数是SWE-Bench的3倍以上，文件修改数是2.5倍 |
局限与改进
本文的局限性主要体现在以下几个方面。首先，基准测试的规模相对有限，仅有132个任务，这可能无法完全代表游戏开发的全部复杂性。其次，所有任务都基于Godot引擎，虽然Godot与Unity相似，但可能无法完全代表其他游戏引擎（如Unreal Engine）的开发场景。第三，任务主要来源于在线教程，这可能导致任务偏向于教学性质，而非真实的游戏开发项目。第四，评估仅限于代码生成方式，虽然论文提到可以通过计算机使用方式解决任务，但没有进行相关实验。第五，多模态反馈机制（MCP和视频）增加了成本和复杂性，可能不适合资源受限的场景。第六，论文没有深入分析智能体在不同任务变体上的表现差异，任务变体（17个）相对于基础任务（115个）的比例较小。最后，论文承认智能体在多模态理解方面仍存在显著不足，特别是在处理精灵图和着色器等视觉资产时经常出错。
独立分析的弱点
本文存在几个值得关注的弱点。首先，基准测试的规模较小（132个任务），可能无法充分代表游戏开发的多样性。改进方向是扩大任务集规模，特别是增加更多来自真实游戏项目的任务。其次，任务来源主要是教程，可能导致任务过于标准化。改进方向是直接从开源游戏项目中提取任务，或与游戏开发公司合作获取真实开发场景。第三，评估仅限于代码生成，没有探索计算机使用方式。改进方向是设计支持多种解决方式的评估框架，允许智能体通过GUI操作或混合方式解决问题。第四，多模态反馈机制的实现相对简单，MCP服务器仅提供静态截图，视频记录功能有限。改进方向是开发更智能的反馈机制，如实时渲染预览、交互式调试工具等。第五，论文没有深入分析任务难度与智能体能力的关系。改进方向是建立更细粒度的任务难度评估体系，研究不同能力维度对任务成功率的影响。
未来方向
本文的未来研究方向可以从多个维度展开。首先，作者提出的多模态反馈机制可以进一步优化，例如开发能够理解游戏语义的智能反馈系统，而不仅仅是提供原始截图或视频。其次，游戏开发智能体可以与其他AI技术结合，如使用强化学习优化游戏逻辑，使用生成模型创建游戏资产。第三，基准测试可以扩展到更多游戏引擎（如Unity、Unreal Engine），以评估跨平台的泛化能力。第四，可以探索人机协作的游戏开发模式，让智能体辅助人类开发者而非完全替代。第五，可以研究游戏开发智能体的迁移学习能力，即在GameDevBench上训练的智能体能否应用于其他软件开发任务。最后，可以开发专门针对游戏开发的多模态模型，通过在游戏开发数据上微调来提升特定领域能力。这些研究方向将推动游戏开发智能体从评估走向实际应用。
复现评估
本文在可复现性方面做得较好。所有代码和任务项目文件都公开发布在GitHub上（https://github.com/waynchi/gamedevbench），这为其他研究者复现实验结果提供了便利。基准测试基于开源的Godot引擎，避免了商业引擎的许可问题。数据来源（YouTube教程和Godot Recipes网站）都是公开可访问的，任务构建流水线有详细的文档说明。评估框架使用Godot内置测试功能，结果具有确定性和可重复性。然而，复现可能面临一些挑战：首先，某些LLM API的可用性和定价可能变化；其次，Godot引擎版本更新可能影响任务的兼容性；第三，视频教程的转录质量可能因API变化而波动。总体而言，本文的开源程度较高，复现难度中等，主要需要解决环境配置和API访问问题。
论文图表
