JAMER：基于专业游戏引擎的项目级代码框架数据集与基准测试 JAMER: Project-Level Code Framework Dataset and Benchmark on Professional Game Engines

方法包含四个主要步骤。第一步是数据收集和预过滤，从Ludum Dare、itch.io、Global Game Jam等平台收集37,588个仓库，识别5,034个Godot引擎项目。通过分析1,872个有评分的项目发现代码行数与Ludum Dare评分的Spearman相关系数为0.445（p < 0.001），确定代码行数≥1,200行作为质量阈值。进行大规模搜索扩展候选仓库至约240,000个，应用预过滤条件（Godot 4.x、2D、代码行数≥1,200、插件依赖<1,000行）得到37,638个项目。第二步是多级验证流水线，设计四个验证级别：L1检查文件完整性（project.godot存在且目标Godot 4.x、主场景配置正确、所有引用的脚本和子场景可达、超过30%的3D内容排除），L2运行Godot headless编译捕捉语法错误、类型错误和缺失资源引用，检查必要代码模式（输入处理和游戏循环必需，碰撞检测、状态管理、场景转换推荐），L3a在headless模式下运行游戏30秒无输入注入验证无崩溃，L3b依赖eval_config注释自动生成确定性输入策略，运行游戏60秒收集多维度行为数据。第三步是结构化注释，为项目生成四个JSON文件：manifest.json通过静态分析自动提取脚本列表、场景树结构、输入映射、autoload配置、场景转换图，game_description.json通过LLM辅助生成游戏玩法描述和流派分类，eval_config.json通过LLM识别玩家节点、分数和健康跟踪机制、关键信号、菜单和游戏场景区分，asset_annotations.json使用混合方法结合VLM和基于规则的方法扫描res://引用和ext_resource声明注释资产文件。第四步是数据集划分和训练数据构建，8,133个项目按代码行数4K和15K分为三个等级（Small、Medium、Large），随机抽取S100/M100/L100共300个项目构成JamBench基准测试集，其余7,833个项目逆向工程为多轮对话训练数据作为JamSet。

技术新颖性体现在多个方面。首先，这是第一个基于专业游戏引擎的项目级游戏代码框架数据集和基准测试，填补了该领域的空白。与现有游戏代码生成工作（如V-GameGym的2,219个单文件样本、OpenGame的150个提示词、AutoUE的20个任务、GameDevBench的132个任务）相比，JamSet和JamBench在规模上有显著优势（8,133个项目），并且提供了项目级而非函数级或文件级的评估。其次，提出了四级确定性验证流水线，从文件完整性到运行时行为收集，不依赖任何LLM判断或手动注释，保证了评估的客观性和可复现性。与现有评估方法（手写测试脚本精确但昂贵、VLM/LLM评分可扩展但主观、单元测试客观但无法捕捉游戏特定行为）相比，该流水线提供了客观、可扩展且能评估游戏特定行为的评估方法。第三，提出了SCS和BAS两个评估指标，分别从静态结构和运行时行为两个维度评估游戏代码框架质量，这是第一个专门针对游戏代码框架的质量评估指标。第四，创新性地从Game Jam竞赛获取数据，这些项目具有时间约束严格、结构紧凑完整、开源共享的特点，形成了高质量的真实游戏工程实例数据。最后，通过系统评估揭示了模型能力随项目规模增加而急剧下降的"能力悬崖"现象，以及Code Agent改进局限于编译层面的发现，为游戏代码生成研究提供了重要洞察。

论文的弱点之一是数据集仅专注于Godot游戏引擎，虽然Godot正在快速增长，但Unity和Unreal等主流引擎在游戏行业中占据更大市场份额。这意味着论文的发现可能无法直接推广到其他游戏引擎，限制了工作的普适性。改进方向是在未来的工作中扩展数据集以覆盖Unity、Unreal等其他主流引擎，构建跨引擎的游戏代码框架数据集和基准测试。第二个弱点是评估指标可能不够全面。虽然SCS和BAS从静态结构和运行时行为两个维度评估游戏质量，但游戏质量还包括可玩性、难度平衡、用户界面设计、音效协调性等多个方面，这些方面论文未涉及。改进方向是扩展评估指标体系，纳入游戏设计维度的评估，可能需要结合人类评估和VLM/LLM评分等方法。第三个弱点是数据集可能存在选择偏差。由于验证流水线的严格性，只有8,133个项目从240,000个候选仓库中通过筛选，这意味着数据集可能偏向于具有特定特征的游戏项目，例如结构清晰、文档完善、遵循标准工程实践的项目，而那些创新但不规范的项目可能被排除。改进方向是分析被排除项目的特征，并在适当情况下放宽某些筛选条件，以增加数据集的多样性。第四个弱点是论文的模型训练探索较为初步。虽然微调实验验证了JamSet的有效性，但未进行彻底的消融实验来理解哪些数据特征对模型改进最重要，也未尝试不同的训练策略或模型架构。改进方向是进行系统的消融实验，探索不同的数据子集、训练策略和模型架构对性能的影响。

作者提出的未来工作方向包括：首先，通过项目变体扩展数据集，修复未通过验证的项目以扩大数据规模。这包括收集更多Game Jam项目，以及将现有项目进行变体扩展，例如修改游戏主题、调整游戏参数或添加新机制，从而增加数据集的规模和多样性。其次，在扩大的数据集基础上训练领域特定的专家模型，专门用于游戏工程。当前实验仅使用基础模型进行微调，未来可以探索从头训练专门用于游戏代码生成的大型语言模型，可能针对Godot引擎的特定语法和模式进行优化。第三，将基准测试扩展到其他游戏引擎，包括Unity和Unreal等主流引擎。这需要为每个引擎设计相应的验证流水线和评估指标，考虑到不同引擎的项目格式、脚本语言和架构模式的差异。第四，改进Code Agent的设计，使其能够超越语法层面的修复，触及架构设计层面的质量问题。当前的Agent反馈信号主要是"是否编译通过"，未来可以扩展反馈信号以包括"是否遵循领域工程实践"，例如场景组织范式、跨文件接口契约、全局状态管理习惯等。基于论文成果可延伸的方向包括：探索游戏代码生成的跨模态评估，结合视觉和音频资产的评估；研究游戏代码生成的可解释性，理解模型如何学习和应用游戏工程知识；开发针对特定游戏流派（如平台游戏、射击游戏、解谜游戏）的专用代码生成模型；探索生成游戏代码与生成游戏美术资产的协同，实现端到端的游戏生成系统。

论文的复现性评估如下。开源情况：论文承诺将公开发布完整的数据集、评估框架和工具代码，这将有助于研究社区复现实验和扩展研究。数据来源：所有游戏项目均来自Ludum Dare、itch.io、Global Game Jam等平台上的开源仓库，仅包含开源许可证的项目。数据集不包含个人隐私信息，所有项目元数据都已删除开发者身份标记。算力需求：微调Qwen3.5-27B-SFT使用了8块NVIDIA H200 GPU（141GB），采用LoRA rank 8在所有线性层上训练3个epoch，使用FlashAttention-2和ZeRO-3优化。这个算力需求对大多数研究团队来说可能较高，但微调是可选的，评估现有模型不需要大量算力。评估流程：四级验证流水线完全自动化且确定性，不依赖任何模型判断或手动注释，这保证了评估的可复现性。同一个eval_config总是产生相同的input_strategy和运行时行为。难度：从技术角度来看，复现论文的实验主要需要（1）获取公开数据集和评估框架代码，（2）使用Godot headless模式运行验证流水线，（3）调用待评估模型的API进行代码生成。这些步骤对于有游戏开发和机器学习背景的研究团队来说应该是可行的。主要挑战可能在于算力需求（如果要进行微调）和时间成本（如果要运行完整的实验）。总体而言，论文在复现性方面表现良好，公开数据集和代码、确定性评估流水线、详细的技术描述都有助于复现。