论文

GameCraft-Bench: 智能体能否在真实游戏引擎中端到端构建可玩游戏?

GameCraft-Bench: 智能体能否在真实游戏引擎中端到端构建可玩游戏?

游戏生成是编码智能体的新兴应用,要求模型将自然语言规约转化为可玩的交互式系统。与传统的编码任务不同,游戏生成发生在游戏引擎中,脚本、场景、资产、渲染和运行时交互必须协同产生连贯的游戏体验。 我们将端到端游戏生成形式化为生成完整游戏制品的问题,该制品通过在目标环境中可观测的玩家-游戏交互来实现规约。我们主张评估该场景需要三个必要条件:引擎接地、制品完整性和交互验证。我们提出一个基于交互的评估框架,通过重放演示和规则引导的多模态评判来评估可执行游戏玩法。 我们以GameCraft-Bench实例化该框架,这是一个包含140个Godot任务(涵盖15个游戏家族)的基准测试。对前沿编码智能体的评估表明,端到端游戏生成仍然极具挑战:最强智能体仅达到41.46%,大多数智能体得分低于40%。进一步分析显示,尽管智能体经常实现可识别的机制,但它们在提供包含足够内容、功能性视觉反馈和连贯呈现的完整游戏方面存在困难。 详情请参见 https://tongxuluo.github.io/gamecraft-bench-website 以获取演示、代码和数据。

论文精读

TL;DR GameCraft-Bench 是一个基于 Godot 引擎的端到端游戏生成基准,通过交互验证评估编码代理构建可玩游戏的能力,当前最强代理仅获 41.46% 得分。

问题

游戏生成是 coding agents 的新兴应用方向,要求模型将自然语言规范转化为可玩的交互系统。当前领域关注如何自动化构建完整的游戏,涵盖脚本、场景、资产、渲染与运行时交互的协同生产。

现有 benchmark(如 HumanEval、SWE-bench)聚焦于函数级代码生成或软件工程任务,评估指标仅为静态代码正确性,无法覆盖 game generation 的三个核心需求:(1) Engine Grounding(引擎落地)——代理必须在真实游戏引擎环境中运行,而非孤立代码;(2) Artifact Completeness(产物完整性)——需要交付一个完整的、可直接启动的游戏包,而非碎片代码;(3) Interactive Verification(交互验证)——评估应基于玩家与游戏的动态交互,而非文本匹配。这些局限使现有方法不能衡量代理是否真正制作了“可玩的游戏”。

端到端游戏生成极具挑战,因为代理需整合多种异质能力:理解抽象规范、编写引擎专用代码(如 Godot 的 GDScript)、管理二维/三维资产,并处理渲染与物理交互。评估也格外困难——必须在一个特定目标引擎中实际运行游戏,并捕捉重放演示中的交互,这需要多模态评判。同时,业界对 AI 驱动游戏开发、程序化内容生成(PCG)和交互式代理的兴趣持续增长,然而 frontier coding agents 在该基准上的最高得分仅 41.46%,表明游戏生成的自动化远未解决。

类似自动驾驶必须在真实道路测试,游戏生成代理也必须在目标游戏引擎中接受交互验证,代码级测试不足以证明其能力。

核心洞察

  • 游戏生成作为端到端工件生产:评估必须超越代码正确性,涵盖可执行游戏性和交互验证。传统编码基准(如 HumanEval)仅检查函数级输出,而 GameCraft-Bench 要求代理产出在真实 Godot 引擎中可运行的完整游戏,并通过重放演示进行多模态评分,直接量化玩家体验。这揭示了将代码生成应用于完整软件产品时的核心工程挑战。
  • 当前代理在实现可识别游戏机制上取得一定进展,但无法保证内容完整性、视觉反馈和连贯呈现,导致最终得分不足。这一瓶颈表明,从生成独立功能到交付可用的完整游戏之间,存在关键的工程鸿沟:代理缺乏对项目结构、资源管理和运行时调试的全局理解。这提示未来工作需为代理配备系统集成与迭代验证能力,而非仅提升代码生成精度。

方法

GameCraft-Bench 采用 交互驱动的端到端游戏生成评估框架,输入为自然语言游戏规格说明,输出为在真实游戏引擎(Godot)中可运行的完整游戏制品。方法分为五个阶段:

  1. 任务打包:将规格说明与初始场景、资源、评分标准打包成标准化的 Godot 工程模板。
  2. 代理生成:允许任意编程代理(如基于 LLM 的 coding agent)在 Godot 环境中编写脚本、添加场景和资产,生成可构建的游戏项目。
  3. 构建门:对代理输出的项目进行编译/构建检查,通过后才进入评估,确保只评测可运行的游戏。
  4. 重放:使用预定义的输入序列对构建成功的游戏进行自动游玩,记录屏幕、日志等运行时证据。
  5. 评分与聚合:基于重放证据,由 多模态评判器(结合规则与视觉模型)从玩法实现度、内容完整性、视觉反馈等维度打分,并汇总为游戏质量分数。

该流程严格满足三个设计准则:引擎落地(Engine Grounding),即直接依赖 Godot 的渲染、物理等运行时行为;制品完整性(Artifact Completeness),要求交付包含场景、脚本、资源的完整工程;交互验证(Interactive Verification),通过重放玩家操作并评判实际画面输出,而非静态代码审查。

与传统的代码生成或文本游戏基准不同,GameCraft-Bench 是首个在商用级游戏引擎中要求 可玩性交互验证 的端到端评测集,其评估信号来自游戏运行时,而非仅对源码的相似度匹配。

实验

实验设计

GameCraft-Bench 包含 140 个 Godot 任务,覆盖 15 个游戏家族(如平台跳跃、弹幕射击等)。每个任务要求编码代理从自然语言规格出发,在真实的 Godot 引擎中产出可运行的完整游戏,涵盖脚本、场景、素材与交互逻辑。评估采用 交互验证框架:代理提交工程后经构建门(build gate)编译通过,再回放预录的玩家操作演示,由基于评分准则的 多模态评判器 对实机画面和表现打分,确保满足 引擎接地工件完整性交互验证 三大要求。

关键发现

所有参测前沿编码代理的最高得分仅 41.46%,多数低于 40%。

  • 优势:代理通常能实现可辨识的核心机制(如移动、射击)。
  • 短板无法交付完整的游戏内容——关卡长度不足、视觉资产缺失、UI 反馈异常,且难以协调多文件间的一致性;运行时错误自修复能力弱。
  • 诊断分析
    • 代理会使用引擎渲染画面作为反馈信号,但更多工具(如额外代码搜索)并未带来明显提升。
    • 评判器在固定证据上重复打分稳定性高,与人工校准后尚存细微偏差。
    • 游戏生成能力可分解为编码实现、资产协调、交互设计等维度,代理在跨维集成上暴露明显瓶颈。

基线对比与解读

相比在 HumanEval 等传统编程基准上 pass@1 可达 80%+ 的表现,前沿模型在 GameCraft-Bench 上的断崖式下滑揭示了从代码片段生成到完整交互系统构建的巨大鸿沟。传统基准只评估孤立的函数级正确性,而真实游戏引擎要求代理同时处理脚本、资源管线、实时渲染闭环与运行时状态,任何模块的脱节都会导致游戏不可玩。现有代理架构缺乏长程规划与多轮自检能力,无法有效探索设计空间和修复复杂运行错误,暴露了当前编码代理在工程完整性上下文保持上的关键缺陷。

行业影响

落地场景

GameCraft-Bench 所代表的端到端游戏生成评估范式,可落地于多个需要自动化交互式内容生产的领域:

  • 游戏开发原型加速:产品经理或策划用自然语言描述玩法,AI 在 Godot 中直接输出可玩原型,缩短从概念到可试玩版本的时间。
  • 教育/培训模拟生成:教案编写者描述一个物理实验或流程模拟,AI 生成可交互的 3D 场景,用于教学或员工 onboarding。
  • UGC 内容平台赋能:为 Roblox、Minecraft 等创作平台提供自然语言到可玩游戏的一键转换,降低创作门槛。
  • 自动化 QA 与回归测试:在游戏引擎版本迭代时,批量生成测试用例并重放验证,代替部分人工 QA。

商业价值

当前最强编码代理在 GameCraft-Bench 得分仅 41.46%,多数在 40% 以下,意味着纯 AI 生成的游戏尚无法直接交付,但作为辅助工具仍有明确降本路径

  • 降低多角色协作成本:一个可玩原型通常需要程序、美术、策划协作数天,AI 生成初稿可将此压缩至小时级,尤其适合独立团队。
  • 加速创意验证与 A/B 测试:快速产出多个玩法变体,通过重放和自动评分筛选出高互动时长或完成度的版本,提升游戏留存与 LTV。
  • 非游戏行业的互动内容增效:在教育、医疗仿真等领域,自动生成定制化交互场景可减少定制开发费用,提升用户参与度。

与现有产品/工作流的接口

该基准背后的评估管线可直接集成到现有游戏开发工具链:

  • IDE 插件形式:在 Godot/Unity 编辑器中嵌入“自然语言→可玩场景”的代理,辅助生成脚本与场景,并调用评估模块实时给出完整度/可玩性评分。
  • CI/CD 管道集成:将 build gate → replay → scoring 流程集成到版本管理流中,每次提交自动生成并评估游戏构建,确保功能不退化。
  • 与现有 AI 编码助手互补:作为 GitHub Copilot 或专门游戏编码模型的评测后端,指导模型微调方向(如提升视觉反馈、内容量等薄弱项)。

具体落地 Use Case

  1. 企业培训内容自动化:一家企业培训平台提供商,为不同客户定制安全演练交互场景。培训师用自然语言描述“化工厂泄漏应急处理”流程,AI 代理生成包含角色移动、物品交互、倒计时等机制的 Godot 游戏,由平台自动化评分管道评估交互完整性与教学逻辑一致性,通过后直接部署到学员端,将单个场景的开发周期从 2 周降至 1 天。
  2. 独立游戏众筹前原型验证:独立开发者在 Kickstarter 前,用 AI 快速生成关卡原型(如“2.5D 平台跳跃,有双跳、收集宝石、限时门”),通过 GameCraft-Bench 风格的自动重放与评判获得可玩性报告,据此优化玩法设计再投入美术资源,降低方向性失败风险。

局限

  • **引擎单一性限制泛化评估**:基准完全基于 **Godot** 引擎构建,虽然其开源特性与丰富功能适合研究,但游戏工业中 **Unity** 与 **Unreal** 占据主流,不同引擎在资产管线、渲染流程、脚本范式上差异显著。代理在 Godot 上习得的能力可能无法直接迁移,导致评估结果不能代表通用游戏生成水平。此外,任务使用的 **GDScript** 语言生态远小于 Python/JavaScript,限制了可接入的代码代理范围,可能低估了多语言代理的真实上限。
  • **交互验证的粒度与主观性平衡不足**:评估通过回放演示与多模态评分准则实现,但“可玩性”仅靠规则清单与单一轨迹判断,难以区分“勉强可交互”与“体验良好的游戏”。例如,机械满足碰撞检测但无视觉反馈可能仍获部分分数,而关卡设计、节奏控制、沉浸感等核心体验维度完全未涉及。这种简化虽保证自动化,却导致高分游戏未必符合人类直觉,且代理可能过度优化表面指标而非内在品质,形成评估偏差。
  • **任务规模与多样性受限**:**140** 个任务覆盖 **15** 个游戏家族,每个家族平均不足 10 个变体,对于需要泛化到未见规格的游戏生成任务而言,任务数量偏少。且家族设计偏向街机/休闲类型(如平台跳跃、弹球),缺少叙事驱动、开放世界或重度物理模拟等复杂游戏形态,可能使基准无法充分暴露代理在结构编辑、状态管理、资源调度等深层工程能力上的缺陷,限制了结论的代表性。
论文Tongxu Luo2026-06-16原文

相关内容