Code2Games：在预建的 Blender 场景中组织玩法与演示
Revio ·
基础场景已经提前在 Blender 中完成建模。Code2Games 在已有环境上进行场景分析、规则规划、对象放置、路径和镜头动画组织；结合完整论文与官方演示，说明其方法及当前公开代码的实现范围。
先说清楚 Code2Games 的起点：地形、树林、峡谷等基础场景已经提前完成建模，并保存为 Blender 的 .blend 文件。系统接手时，这个世界就已经存在。论文采用 Code2Worlds 提供与任务配对的基础世界，因此“提前建模”指输入阶段已有场景，并不意味着所有场景都由人工手工制作。
在当前公开的 Blender 流程中，AI 与配套脚本负责相机提取、视觉场景分析、规则规划、候选位置选择、资产计划与生成、角色放置、路径构建，以及最终的镜头和动画渲染。本文聚焦这些工作怎样在预建场景里组织玩法和演示；基础场景与资产的建模方法、制作质量等资产问题不在本文的讨论范围内。
即使环境已经准备好，要把它变成一项任务，仍有不少连接工作：敌人要放在能抵达的位置，枪击要改变目标状态，通讯设备要在条件满足后激活，任务完成还要有明确判定。Code2Games 研究的正是场景、规则与执行之间怎样保持对应。论文进一步描述了接入 Unreal Engine 5 后的重建与反馈修复，这部分与当前公开 Blender 代码的实现范围不同，后文分别说明。
论文《Code2Games: Enabling Coding Agents for Gaming World Generation》由北京大学计算机学院与拉筹伯大学的研究者合作完成，作者为 Wei Wu、Ziyang Xu、Zeyu Zhang、Yang Zhao 和 Hao Tang，2026 年 10 月 4 日提交 arXiv v1。可以查看 论文摘要与作者信息 和 论文 HTML 全文。
这项工作值得看的地方，是它怎样把“这里有什么”“玩家要做什么”和“程序里哪个对象负责这件事”对应起来。
论文 Figure 3：从场景分析、玩法规划到世界生成和引擎适配，各阶段共享场景与玩法的对应关系。图片来源：Code2Games 作者。
先把场景和任务变成能对照的数据
Code2Games 的输入包含两部分：一段玩法意图，以及与它配对的预建 Blender 基础世界。系统先读取已有场景，再把任务所需的对象和行为安排进去。这使场景中的区域、障碍和可通行空间成为规划依据。
系统分工给四类智能体。场景分析智能体提取空间区域、语义类别、可达性和可交互条件；玩法规划智能体把文字拆成目标、角色、游戏元素和交互规则；世界生成智能体在空间约束下实现这些元素；游戏引擎定制智能体负责将结果重建成引擎里的对象和逻辑。论文第 3 节
以一项射击任务为例，“消灭守卫后激活通讯设备”至少包含守卫、玩家、通讯设备，以及一条有先后关系的规则。系统需要明确：谁触发交互，触发前要满足什么条件，触发后修改哪个状态。这样，通讯设备是否可用就能依赖任务状态，而不只是场景里摆着一个外形像终端的模型。
这套对应关系还要跨过 Blender 和 Unreal 两个环境。论文为游戏元素保留持久 ID，并关联它的类型、Blender 中的实现、Unreal 中的实现、参与的交互和负责执行的逻辑单元。某个触发器出问题时，系统可以找到它对应的任务规则和场景实体，修改相关部分。资产外形、逻辑对象和规则不必靠名字猜测彼此的关系。
其中一个实用区分，是把看得见的物体与逻辑区域分别处理。宝箱需要网格和材质，出生点、撤离区或检查点可以只需要坐标与触发范围。把每个游戏元素都当成“生成一个 3D 模型”，既会多做资产，也容易把规则遗漏在美术之外。
放置物体时，让几何检查先筛掉坏位置
智能体能理解“把补给箱放在营地旁边”，却未必能仅凭一张图给出可靠的三维坐标。物体可能悬空、嵌进地形、堵住路线，或落在角色到不了的地方。
Code2Games 将放置拆成两步。系统先按照区域语义产生候选位置，用射线检测支撑表面，检查包围盒碰撞，并在论文所述流程中检查导航可达性。通过这些检查的位置，才交给视觉语言模型结合俯视图和任务需求挑选。模型从已有的候选编号中选择，后续程序使用对应坐标实现放置。
这意味着几何程序负责“这个位置能不能用”，模型负责“这些可用位置中，哪个更适合任务”。如果候选全部失败，就返回问题继续修复，而不是默认采用模型给出的一个坐标。
后续资产计划与生成沿用已确定的位置、尺寸和元素 ID，再把对象放回已有环境。这里关注的是对象与场景、任务规则如何对应，具体资产制作不展开讨论。需要查看原始约束与输入格式，可以阅读 论文附录 G 的完整提示词。
接入引擎之后，还要把任务跑一遍
Blender 中的结果进入游戏引擎后，需要重新建立 Actor、触发体、材质、灯光和玩法逻辑。论文使用 Unreal Engine 5，并根据共享表示把对象与规则重新绑定。随后编译工程、启动场景、执行测试路线，检查目标是否按预期变化。
反馈分成两类。引擎反馈处理编译失败、对象缺失、工程无法启动等问题；玩法反馈处理任务触发错误、状态没有更新或行为违背规则等问题。修复针对对应的对象和逻辑继续进行，直到测试成功或达到预算。作者报告，实验项目在最多五轮修复内达到可执行状态。
这一步也在消融实验中体现出来。论文 Table 3 中，初始重建的 Build 得分是 78.5，加入引擎反馈修复后升到 88.7，再加入玩法反馈后达到 97.7。与此同时，交互符合度从 58.0 提高到 75.8，物理符合度从 54.0 提高到 73.9。引擎修复首先改善“能否启动执行”，玩法修复进一步改善“执行出来的行为是否符合设计”。这些都是作者在其评测协议下报告的结果。论文消融实验
20 段演示里，哪些玩法已经能看见？
项目主页展示了十类场景，每类两段视频，另有一段首页混剪。逐项查看这些视频，能看到任务面板、角色动作、可收集物和完成提示已经出现在同一段流程里。本文的观察来自官方录像，采用覆盖整段视频的每秒抽帧并放大查看关键画面，没有亲自操作这些工程。官方演示主页
水下探索是一个较直观的例子。《Coral Reef Survey》中，潜水员在珊瑚与沙地之间游动，界面同时显示声呐、深度、样本和调查点。录像结尾可以看到样本 3/3、调查点 2/2，以及完成撤离的提示。另一段《Blackwater Survey》采用更暗的水下环境，角色靠近大型设备时也出现了明显的镜头遮挡。
《Coral Reef Survey》约 59 秒：画面显示采样、调查与撤离任务完成。截图来自作者的官方演示视频。
战斗类包含第一人称射击、第三人称射击、怪物狩猎和弓箭任务。FPS 视频能看到武器视角、射击效果、弹药变化和目标倒地；TPS 视频加入第三人称角色、林地移动、补给与设备。弓箭演示把侦察、跃上掩体、观察目标、拉弓、射击串成一个短流程，《Desert Assassination》约 37 秒出现击杀确认，目标列表也随之更新。这些片段展示了动作和任务提示的配合，但敌人决策的丰富程度、玩家偏离路线后的表现，还需要实际工程测试。
移动类包含赛车、滑雪、穿越障碍和低空飞行。赛车可以看到速度界面、第三人称跟随和加速效果；滑雪围绕旗门与终点推进。飞行演示尤其容易读懂状态变化：《Summit Intercept》中，界面从激活飞行单元逐步推进到 4/4，随后出现山顶目标解锁与完成提示。
《Summit Intercept》约 49 秒：飞行单元达到 4/4，界面显示任务完成。主页类别沿用 Wingsuit 名称，实际视频中的主体是 F-104 飞机。
另外两段方块角色演示分别展示峡谷采集和林地资源探索，能看到收集特效、挥斧动作、生命值与物品栏。这里的 Minecraft-style、Assassin's Creed-style 等名称描述了风格和任务参考，演示没有覆盖这些商业游戏的完整系统。
视频也保留了一些原型痕迹。障碍穿越使用未充分修饰的角色，狩猎和林地视频存在枝叶挡住镜头的时刻；滑雪视频后段能看见地形边缘，结尾的大部分场景画面变黑，HUD 仍保留。它们适合展示一个短任务怎样落到场景里，整体完成度还需要继续打磨。
论文的分数该怎样读？
主实验覆盖十个游戏任务。每个生成结果执行两条不同的预定义动作路线，先在同一个游戏内平均，再对十个游戏等权平均。这里的两条路线共享同一个生成工程，因此主实验的二十条录像不能当成二十个独立游戏样本。主页的二十个命名演示，也不宜直接与主实验的二十条评测录像逐一等同。实验设置与附录 E
指标分为视觉质量、交互符合度、多模态生成质量和可玩结果质量，共十五项。视觉部分包含图像质量、光流动态和帧间运动指标；任务与交互部分结合描述、控制轨迹和录像评判；可玩结果还看机制、内容深度、功能性视觉与美术表现。
下面按相同基座模型摘取 Table 1 的三项分数，便于看出流程带来的变化。所有数字都来自论文，并非本文复现。
| 论文中的基座模型与比较对象 | 交互符合度：直接编码 → Code2Games | Build：直接编码 → Code2Games | Human：直接编码 → Code2Games |
|---|---|---|---|
| Qwen3.8-Max：Qwen Code → Code2Games | 60.8 → 70.6 | 93.3 → 94.1 | 51.5 → 68.0 |
| GPT-5.6 Sol：Codex → Code2Games | 67.8 → 76.2 | 94.2 → 95.9 | 64.2 → 75.5 |
| Claude Opus 5：Claude Code → Code2Games | 66.0 → 75.8 | 94.5 → 97.7 | 63.8 → 77.5 |
其中，97.7 是标准化构建与运行检查的通过率，检查包含编译、工程启动、场景加载和路线执行。Human 则来自十五位评分者观看匿名、随机排列的录像后打分，关注机制、深度、功能性视觉和美术。这两个数分别说明指定检查下的可靠性与录像中的体验表现，不能据此直接得出商业游戏的完成率或玩家实玩满意度。
从消融实验看，去掉场景表示、玩法规格或空间约束，相关指标都会下降：缺少场景表示主要影响环境与任务的匹配，缺少玩法规格主要影响交互，缺少空间约束主要影响物理符合度。它们与方法设计之间形成了较清楚的对应。与此同时，十个任务的规模仍然有限，论文没有给出足够的成本、耗时与统计不确定性信息，适合将结果理解为这套生成流程的初步实验支持。
当前公开代码，能复现到哪一步？
截至 2026 年 10 月 8 日，GitHub 仓库公开了一条从 Blender 场景到演示视频的流水线。入口脚本依次执行相机提取、视觉场景分析、规则规划、候选位置选择、资产计划与生成、角色放置、路径构建，以及最终的镜头和动画渲染。README 要求准备 Code2Worlds 场景、带动画的人形 FBX、Blender、模型服务及相关凭据。公开代码与运行说明
检查该版本的入口与最终渲染代码，可以看到角色和相机通过关键帧驱动，输出为 gaming_world.blend 和 gameplay.mp4。该快照中没有找到论文所述的 Unreal 工程重建、引擎编译与玩法反馈修复实现。因此，公开源码目前可供研究的重点，是场景理解、规则结构化、受约束的放置和 Blender 演示生成；论文的完整可交互引擎流程仍需要更多实现材料。本文没有运行这些生成服务或进行 Unreal 复现。
GameCode4D 数据卡列出了二十条任务描述。2026 年 10 月 8 日采集的文件树中能找到十六个 .blend 场景文件，按各文件标注尺寸相加约 45 GB。准备研究公开流程时，需要将任务描述与实际场景文件对照。GameCode4D 数据集
对做 AI 游戏工具的人来说，Code2Games 提供了一个具体的实现思路：让场景语义约束任务，把任务拆成可以执行的状态变化，给资产与逻辑保留稳定的对应关系，再用运行结果指导修改。下一步最有价值的公开材料，是与这些录像对应的可交互工程和反馈测试代码。它们能让开发者直接检查：当玩家绕开预设路线、重复触发任务，或者在不同条件下接近同一个物体时，这套生成出来的规则还能否正常工作。