Code2Games：让编码智能体生成游戏世界 Code2Games: Enabling Coding Agents for Gaming World Generation

第一步，场景分析智能体把 Blender 底座场景解析为区域集合 $S=\{q_j\}_{j=1}^M$，每个区域 $q_j=(\tau_j, b_j, \rho_j, \alpha_j)$ 依次是语义类别、空间边界、按导航网格判定的可达性、交互可供性集合。第二步，玩法规划智能体从意图 $u$ 和 $S$ 产出声明式规范 $D=(g,\mathcal{A},\mathcal{E},\mathcal{I})$：$g$ 是目标与胜负条件，$\mathcal{A}$ 是角色，$\mathcal{E}$ 是玩法元素（每个元素带持久标识符、功能描述、类型 $\kappa_e$ 与放置约束 $C_e$），$\mathcal{I}$ 中每条交互 $\iota_k=(P_k,t_k,c_k,\Delta s_k)$ 描述参与者、触发事件、前置条件和状态更新。第三步，世界生成智能体做约束放置：先取语义兼容且可供性匹配的区域 $J_e$，从其边界采样候选点，再过滤掉不满足 $C_e$、无有效支撑（向下射线检测）、有碰撞（包围盒求交）或不可达（导航网格寻路）的点；对幸存候选构建俯视观测 $T_e$，用 VLM 按 $p^*_e=\arg\max_{p\in P_e}s_{\mathrm{VLM}}(e,p,T_e)$ 选出语义最合适的点；随后实例化资产或区域标注，并把每条交互编译为逻辑单元 $\ell_k=(bc_k, ba_k)$（条件检测加动作执行），经持久标识符绑定到参与者。第四步，引擎定制智能体重建 UE5 工程：物理元素还原为 Actor、逻辑区域还原为触发体积，视觉配置 $V$ 翻译为材质与灯光，逻辑单元绑定运行时条件与动作，组装出初始工程 $U^{(0)}=\mathrm{Assemble}(W,D)$。第五步，执行引导修复：编译运行收集 $F^{(t)}=(F^{(t)}_{\mathrm{engine}}, F^{(t)}_{\mathrm{game}})$，用 $C^{(t)}=\mathrm{Localize}(F^{(t)},\{\mu(e)\}_{e\in\mathcal{E}})$ 定位受影响组件并局部修复，迭代直到玩法目标通过或预算耗尽（实验中所有项目最多 5 轮内达到可运行状态）。

技术新颖性体现在四点。第一，表示层面：把“场景-玩法持久对应”形式化为 $\mu(e)$ 记录，明确连接声明元素、Blender 实现、Unreal 实现与逻辑单元，这在智能体游戏生成文献中是新的——此前工作要么没有场景对应（纯代码生成），要么停在场景层不接玩法。第二，放置层面：把“几何合法性”与“语义合适性”解耦为两级过滤——射线检测、包围盒、导航网格先做硬过滤，VLM 再对候选做语义排序，比纯规则或纯端到端生成更可靠，消融（表 4）显示两类约束解决的是互补的失败模式。第三，修复层面：执行引导重建不是简单的“报错重试”，而是用对应记录做错误定位，只修受影响组件，并区分引擎级反馈（编译/运行时）与玩法级反馈（目标断言、脚本化交互轨迹），消融证明两者贡献不同。第四，评测层面：GameCode4D 用同一意图配对生成底座世界与游戏世界，首次把视觉、交互、工件、可玩性四维指标和无人干预构建成功率 Build 组合成统一协议。整体属于系统集成创新而非单点算法突破，但工程闭环完整、可检验性强。

(1) 裁判与被评对象同源：LLM-as-a-Judge 用 Qwen3.8-Max 打分，而它也是一个被测骨干，可能存在自我偏好；改进方向是引入多裁判集成（不同厂商模型 + 人工校准子集）并报告裁判间一致性。(2) 评测动作路线是预定义的：每局两条约 50 秒 rollout 走固定路线，只能覆盖设计者预想的交互，无法发现未测试路径上的坏玩法；可引入随机探索智能体或 LLM 玩家做开放测试并统计异常率。(3) 视觉适配损耗：材质与着色器翻译目前是规则管线，作者自己指出会丢色彩、透明度和氛围；可以学习 Blender→UE 的材质映射模型，或用渲染校准网络做后处理对齐。(4) 逻辑单元粒度：交互被编译为“条件+动作”对 $\ell_k=(bc_k,ba_k)$，难以表达持续行为（巡逻 AI、物理谜题、多阶段剧情）；可扩展为行为树/状态机的结构化生成，并让对应记录追踪状态机节点。(5) 资产质量瓶颈：Image 分数仅约 30，说明 Hunyuan3D 资产与场景光照的整合仍是短板；可引入资产检索库或针对游戏风格微调资产生成模型。(6) 缺乏成本分析：论文未报告生成一个游戏的 token 消耗、模型调用次数与端到端时间，而“四智能体+多轮修复”的成本可能显著高于直接生成基线，性价比论证不足。

作者明确提出的方向是改进材质翻译与渲染校准，缩小 Blender→UE5 的视觉差距。在此基础上有几条自然延伸：(1) 把执行引导修复变成学习信号——五轮内的编译、运行时和玩法反馈本质上是免费的环境奖励，可用于强化学习微调代码生成模型，减少对提示工程和多智能体编排的依赖；(2) 扩展玩法复杂度：引入 NPC 行为树生成、多阶段任务、存档与经济系统，检验持久对应表示在长程状态管理下是否仍然有效；(3) 多引擎与跨引擎一致性：把 UE5 定制智能体泛化到 Unity/Godot，研究同一世界表示 $W$ 自动适配多引擎并量化视觉/行为漂移；(4) 基准扩展：GameCode4D 目前只有 10 个提示，可程序化生成“提示-底座场景”对，形成更大规模、复杂度可控的评测集，并补充修复轮数、token 成本等效率指标；(5) 与 world model 结合：用生成的可执行游戏作为 world model 的数据飞轮或验证环境，两个方向互补；(6) 交互式迭代创作：让用户在生成的世界里标注不满意之处，通过对应记录反推到声明式规范做局部修改，形成人机协同的游戏创作循环。

复现条件中等偏上。有利因素：论文附有网站与代码链接，附录完整公开了 10 个基准提示原文（表 5）、约 50 秒双 rollout 的录制与聚合协议、全部 LLM 裁判的 rubric 与提示模板（含 Setting/Inter./Physics、Code/Image/Video、M/D/V/A 的逐条评分标准和封顶条件），以及各智能体的系统提示（附录 G），透明度很高。技术栈明确：Blender 4.2.0 Python API 做场景理解与放置、Qwen 系列做语言/视觉推理、Hunyuan3D 生成资产、UE5 作为执行后端。门槛在于：(1) 需要多个商业闭源模型 API——Qwen3.8-Max、GPT-5.6 Sol、Claude Opus 5，生成与裁判都要花 API 费用；(2) 需要能无人干预编译和运行 UE5 工程的环境，UE 项目自动化构建对机器配置和脚本要求较高；(3) 依赖同组的 Code2Worlds 生成底座场景，需一并部署。无 GPU 训练需求（纯推理+规则检查），单机可跑，但端到端复现完整评测（10 游戏 × 20 视频 × 多裁判 × 多方法）预计需要数百美元级 API 开销与较强的工程调试能力。