【3D 场景生成】AutoUE: Automated Generation of 3D Games in Unreal Engine via Multi-Agent Systems
AutoUE：基于多智能体系统在虚幻引擎中自动化生成3D游戏
原文链接：https://arxiv.org/abs/2603.07106
代码开源地址：https://github.com/Pluto156/AutoUE
发表：ACL finding -2026
摘要
在商用游戏引擎中自动化生成3D游戏仍是一项极具挑战性的任务，该过程涉及场景、蓝图、代码等资源生成所需的复杂引擎工作流。为应对这一挑战，本文提出一种全新的多智能体系统AutoUE，该系统通过协同多个智能体实现3D游戏的端到端生成，覆盖模型检索、场景生成、游戏玩法与交互代码合成，以及用于评估的自动化游戏测试环节。为缓解大语言模型在工具使用过程中的幻觉问题，本文引入检索增强生成机制，为智能体提供虚幻引擎（Unreal Engine, UE）相关工具文档作为事实依据。此外，本文在代码生成过程中融入游戏设计模式与引擎约束条件，确保生成代码的正确性与鲁棒性。进一步地，本文设计了一套自动化试玩流程，可生成并执行运行时测试指令，实现对游戏动态行为的系统化评估。最后，本文构建了游戏生成数据集并开展一系列实验，结果验证了AutoUE端到端生成3D游戏的能力，同时证明了上述设计的有效性。
1 引言
数字游戏作为最具影响力的交互式媒介形式之一，在娱乐与仿真领域发挥着重要作用。由于需要设计复杂的视觉环境与系统逻辑，游戏创作仍是一项兼具创造性与劳动密集型的工作。
近年来，大语言模型（Large Language Models, LLMs）与生成式模型的发展，推动了基于自然语言描述的自动化游戏生成研究，旨在降低游戏开发门槛。一个极具前景的研究方向是将大语言模型与游戏引擎相结合，生成引擎内可用资源，该方案为游戏开发提供了更优的可控性、可编辑性与实用价值。
图1：游戏场景与游戏玩法示例
尽管相关研究取得了一定进展，在游戏引擎中自动化生成3D游戏仍面临严峻挑战。与2D游戏或简易游戏场景相比，3D游戏需要更复杂的空间布局、游戏玩法行为，以及多子系统间的协同配合。现有研究已将大语言模型与虚幻引擎、Unity等商用引擎结合，用于生成3D场景、游戏玩法逻辑与引擎代码。然而，此类工作大多聚焦于独立的单一组件，难以端到端生成完整可玩的3D游戏。
为解决上述问题，本文提出AutoUE，一种全新的多智能体系统，通过协同模型检索、场景生成、游戏玩法代码、交互对象与自动化试玩五大智能体，在虚幻引擎中生成完整的3D游戏。
具体而言，模型检索智能体基于85.8万个3D模型构建嵌入数据库，实现相关模型资源的高效语义检索。场景生成智能体基于检索到的模型，利用虚幻引擎内置的程序化内容生成（Procedural Content Generation, PCG）工具，生成可视觉编辑的布局图，进而构建连贯的3D场景。游戏玩法代码智能体遵循通用游戏开发设计模式并遵守引擎特定约束，生成模块化的游戏玩法C++代码。交互对象智能体基于上述模块推导对象交互流程并实现对应C++代码，使场景内实体可提供符合描述的玩家交互功能。最后，自动化试玩智能体自动生成并执行运行时测试指令，完成对场景与游戏玩法行为的评估。各智能体通过结构化规范传递上下文信息，保障系统整体的一致性。
本系统的创新点如下：
- 相较于其他引擎，虚幻引擎提供了完备的内置工具以支撑高效游戏开发。为缓解大语言模型的工具使用幻觉问题，本文提出基于检索增强生成（Retrieval-Augmented Generation, RAG）的机制，从工具文档中检索相关信息，为智能体提供精准的使用指导。
- 现有方法常忽略游戏开发中的设计模式，导致生成代码无约束、难以维护与扩展。为解决该问题，本文生成功能化的游戏玩法模块代码，并基于行业通用实践设计模块管理框架，使系统可生成可复用、可组合的游戏玩法代码，供交互对象受控调用。
- 现有研究通过人工检查或静态检测评估生成的资源，而完整游戏的核心是动态的游戏玩法与交互行为，无人工参与的客观评估难度较大。本文引入自动化试玩流程，生成测试指令并实现模型上下文协议（Model Context Protocol, MCP）以在运行时执行指令，实现自动化、系统化的评估。
最后，本文构建了包含20个游戏生成任务的数据集，实验结果表明本文方法生成的3D场景质量优于现有方法。同时，本文基于生成的游戏玩法、交互代码与运行日志，设计了多项评估动态游戏玩法行为的指标，为游戏引擎中端到端3D游戏生成提供了基准。
总体而言，本文的贡献总结如下：
- 提出一套实用的端到端多智能体系统，用于在虚幻引擎中生成3D游戏。该系统协同构建连贯的3D场景、合成鲁棒的游戏玩法与交互代码，并执行自动化试玩评估。
- 设计检索增强生成机制为智能体提供工具使用指导，降低大语言模型的幻觉问题。在代码生成过程中融入游戏设计模式与引擎约束，提升生成代码的可维护性与可扩展性。
- 构建游戏生成数据集并搭建自动化试玩流程，为3D游戏生成领域提供基准。该工作为多智能体游戏生成奠定了坚实基础，整体系统为后续研究提供了可扩展的基础设施。
2 相关工作
现有将智能体应用于游戏的研究可分为两类：
2.1 作为游戏游玩智能体的大语言模型
该研究方向将大语言模型作为游戏游玩智能体，以游戏为测试平台提升智能体处理复杂观测信息的能力。早期研究主要聚焦于文本类游戏：Hausknecht等人提出交互式小说评估框架，并采用基于模板的动作空间降低任务复杂度。近期研究进一步将大语言模型应用于开放世界3D游戏。DEPS方法基于环境反馈与子目标选择进行规划，稳健完成《我的世界》中的多样化任务。Voyager方法结合不断扩展的技能库与反馈驱动的迭代循环，实现《我的世界》中的开放式探索。此外，近期研究还探索了智能体在多种游戏类型中的应用，包括竞技类与动作类游戏。最新研究通过大规模游戏玩法数据训练基础模型，实现对未知游戏的泛化适配。
2.2 作为游戏生成智能体的大语言模型
该研究方向利用大语言模型生成游戏内容，包括基于文本/视频的游戏生成与引擎融合式游戏生成。前者以文本叙事、脚本化交互或类视频内容的形式生成游戏体验，此类游戏易于端到端合成，但缺乏自由形式的空间交互与开发者可编辑内容。因此，近期研究将大语言模型与游戏引擎结合，为现代游戏开发生成引擎内可用资源。Sketch2Scene方法利用扩散模型将用户草图转化为等距2D场景引导图，再将引导图输入程序化生成流程构建3D游戏场景。3Dify方法利用检索增强生成与模型上下文协议调用Blender、Unity、虚幻引擎等工具，结合用户迭代反馈创建3D场景。UnrealLLM方法借助多模态资源检索与专家知识驱动的程序化内容生成，在虚幻引擎中实现自动化高质量3D场景生成。Hassan方法解析游戏设计文档并微调大语言模型，生成模块化、可编译且符合设计规范的Unity C#游戏模板原型。UniGen方法搭建多智能体框架生成Unity C#代码，将代码挂载至组件并支持迭代调试。上述研究均聚焦于流程中的单一阶段，而游戏引擎工作流具有强耦合特性，各组件难以简单组合。DreamGarden方法通过分层规划向端到端生成迈进，在虚幻引擎中迭代构建游戏原型。但其生成结果的整体质量仍有限，面对复杂需求时鲁棒性不足，凸显了研发更可靠、贴合工作流的完整3D游戏生成系统的必要性。
3 方法论
3.1 系统概述
图2：本文提出的多智能体系统AutoUE的整体框架。蓝色箭头表示工作流。
图2展示了本文提出的多智能体系统框架，该系统由5个大语言模型智能体组成：(1) 模型检索智能体、(2) 场景生成智能体、(3) 游戏玩法代码智能体、(4) 交互对象智能体、(5) 自动化试玩智能体。
本文采用模型上下文协议作为智能体与虚幻引擎之间的标准化接口。当智能体生成需要集成至虚幻引擎的结构化规范时，会通过本文实现的模型上下文协议调用引擎工具或开放代码，将输出导入项目并执行对应应用工作流。由于模型上下文协议主要作为工程集成层，本文后续章节不再赘述其实现细节。
3.2 问题形式化
给定游戏描述 x x x，本文的目标是构建完整的虚幻引擎游戏 G G G，其包含连贯的3D场景、可执行的游戏玩法代码、交互对象逻辑与自动化测试指令。
由于
x
x
x 通常将场景内容与游戏玩法意图交织描述，模糊了应构建内容与应发生行为的边界，可能误导下游智能体。因此，本文首先将
x
x
x 分解为场景描述
D
e
s
c
S
Desc_{S}
DescS 与游戏玩法描述
D
e
s
c
G
Desc_{G}
DescG：
D
e
s
c
S
,
D
e
s
c
G
=
D
e
c
o
m
p
o
s
e
(
x
)
(
1
)
Desc_{S}, Desc_{G}=Decompose(x) \quad (1)
DescS,DescG=Decompose(x)(1)
其中，
D
e
s
c
S
Desc_{S}
DescS 定义场景上下文与关键对象，
D
e
s
c
G
Desc_{G}
DescG 定义游戏玩法机制与玩家交互；
D
e
c
o
m
p
o
s
e
Decompose
Decompose 表示用于查询大语言模型的提示词，提示词细节见附录图7。
3.3 模型检索智能体
场景对象作为游戏世界的基础实体，不仅对视觉呈现至关重要，更是交互建模的核心依据。本文基于
D
e
s
c
S
Desc_{S}
DescS 生成关键场景对象列表及其关联属性，形式化表示为：
L
i
s
t
[
A
t
t
r
s
O
b
j
]
=
G
e
n
e
r
a
t
e
O
b
j
(
D
e
s
c
S
)
(
2
)
List[Attrs_{Obj}]=\mathcal{G}enerate_{Obj}(Desc_{S}) \quad (2)
List[AttrsObj]=GenerateObj(DescS)(2)
其中，对象属性
A
t
t
r
s
O
b
j
Attrs_{Obj}
AttrsObj 包含名称、类别、描述与空间放置指导；
G
e
n
e
r
a
t
e
O
b
j
\mathcal{G}enerate_{Obj}
GenerateObj 的提示词细节见附录图8。
上述对象属性将应用于本文的检索流程，该流程基于TexVerse构建——TexVerse是包含Sketchfab平台超85.8万个文本描述3D模型的资源库。为高效检索相关模型，本文使用文本编码器为模型描述构建嵌入数据库。
由于模型数量庞大，本文首先根据
A
t
t
r
s
O
b
j
Attrs_{Obj}
AttrsObj 中的类别，利用Sketchfab的18个类别进行预过滤，缩小检索范围。随后，计算对象描述编码与过滤后模型嵌入的余弦相似度，检索前k个模型，形式化表示为：
L
i
s
t
[
M
]
=
S
o
r
t
(
[
S
i
m
(
e
D
e
s
c
O
b
j
,
e
D
e
s
c
M
i
)
]
i
=
1
m
)
[
:
k
]
(
3
)
List[M]=Sort\left(\left[Sim\left(e_{Desc_{Obj}}, e_{Desc_{M_{i}}}\right)\right]_{i=1}^{m}\right)[:k] \quad (3)
List[M]=Sort([Sim(eDescObj,eDescMi)]i=1m)[:k](3)
其中，
L
i
s
t
[
M
]
List[M]
List[M] 为前k个检索模型的描述与相似度分数列表，
S
o
r
t
Sort
Sort 为降序排序函数，
S
i
m
Sim
Sim 为余弦相似度函数，
e
D
e
s
c
O
b
j
e_{Desc_{Obj}}
eDescObj 与
e
D
e
s
c
M
i
e_{Desc_{M_{i}}}
eDescMi 分别为对象描述与第i个模型描述的嵌入向量，
m
m
m 为预过滤后的模型数量。
随后，本文基于 A t t r s O b j Attrs_{Obj} AttrsObj 利用大语言模型对 L i s t [ M ] List[M] List[M] 重新排序，重排序后的top-1模型作为该对象的最终检索3D模型。
3.4 场景生成智能体
检索到高质量3D对象模型后，本文基于这些资源稳健构建连贯的虚幻引擎场景。本文不生成硬编码坐标，而是借助程序化内容生成工具合成场景布局。程序化内容生成将场景构建表示为可视觉配置的图，连接支持表面采样、点变换、边界修改等功能的模块化节点。这些节点使程序化内容生成天然适配 D e s c S Desc_{S} DescS，可满足大部分抽象放置意图，并能扩展以满足额外需求。
3.4.1 程序化内容生成图规划
本文基于
D
e
s
c
S
Desc_{S}
DescS 与
L
i
s
t
[
A
t
t
r
s
O
b
j
]
List[Attrs_{Obj}]
List[AttrsObj]，为每个场景对象生成一条程序化内容生成节点链。每条节点链由带显式编辑器坐标的有序节点类型列表描述，形式化表示为：
L
i
s
t
[
N
o
d
e
(
x
,
y
)
]
=
P
l
a
n
N
o
d
e
(
D
e
s
c
S
,
A
t
t
r
s
O
b
j
)
(
4
)
List[Node_{(x,y)}]=\mathcal{P}lan_{Node}(Desc_{S}, Attrs_{Obj}) \quad (4)
List[Node(x,y)]=PlanNode(DescS,AttrsObj)(4)
其中，
L
i
s
t
[
N
o
d
e
(
x
,
y
)
]
List[Node_{(x,y)}]
List[Node(x,y)] 表示程序化内容生成节点链，每个元素为位于编辑器坐标
(
x
,
y
)
(x,y)
(x,y) 的节点；
P
l
a
n
N
o
d
e
\mathcal{P}lan_{Node}
PlanNode 的提示词细节见附录图9。
实际应用中，无约束的程序化内容生成图会导致不稳定或难以调试的程序化行为。因此，本文将对象放置分为两类标准程序化内容生成模式，分别覆盖高频生产需求：
- 大型对象（如建筑）需要稳定采样与间距控制。节点链在修剪与边界控制后直接执行生成步骤，避免重叠与越界放置。
- 小型散射对象（如树木、岩石）需避免与主要角色相交。本文添加排除节点以剔除禁止区域，提升碰撞规避能力与视觉连贯性。
该设计实现了工业级稳定性，通过密度、边界等参数提供灵活性，并可通过扩展模式满足更广泛的需求。
3.4.2 基于检索增强生成的节点规范
规划得到的列表仅指定节点类型，缺少参数与引脚连接信息。为避免生成此类信息时出现幻觉，本文对完整文档语料库采用检索增强生成：将所有可用文档分割为统一文本块，为每个目标节点检索最相关的文本块。实际应用中，原始材料可能包含跨文档、跨章节的交叉引用。严格的索引方案维护成本高、对新节点扩展性差，且可能在生成时引入过多上下文。因此，本文采用语义检索获取每个节点所需的最小指导信息，形式化表示为：
L
i
s
t
(
C
)
=
S
o
r
t
(
[
S
i
m
(
e
N
o
d
e
,
e
C
i
)
]
i
=
1
n
)
[
:
c
]
(
5
)
List(C)=Sort\left(\left[Sim\left(e_{Node}, e_{C_{i}}\right)\right]_{i=1}^{n}\right)[:c] \quad (5)
List(C)=Sort([Sim(eNode,eCi)]i=1n)[:c](5)
A
t
t
r
s
N
o
d
e
=
G
e
n
e
r
a
t
e
N
o
d
e
(
N
o
d
e
(
x
,
y
)
,
L
i
s
t
(
C
)
)
(
6
)
Attrs_{Node}=\mathcal{G}enerate_{Node}(Node_{(x,y)}, List(C)) \quad (6)
AttrsNode=GenerateNode(Node(x,y),List(C))(6)
其中，
n
n
n 为文本块数量，
C
i
C_{i}
Ci 为第i个文本块，
e
N
o
d
e
e_{Node}
eNode 与
e
C
i
e_{C_{i}}
eCi 分别为节点
N
o
d
e
(
x
,
y
)
Node_{(x,y)}
Node(x,y) 与文本块
C
i
C_{i}
Ci 的嵌入向量，
L
i
s
t
(
C
)
List(C)
List(C) 为检索得到的前c个文本块，
A
t
t
r
s
N
o
d
e
Attrs_{Node}
AttrsNode 为节点
N
o
d
e
(
x
,
y
)
Node_{(x,y)}
Node(x,y) 的参数与连接信息；
G
e
n
e
r
a
t
e
N
o
d
e
\mathcal{G}enerate_{Node}
GenerateNode 的提示词细节见附录图10。
检索增强生成知识库保障了程序化内容生成可稳健创建场景，同时通过新增文档即可便捷引入新节点功能。最终，本文开发模型上下文协议工具，将所有 A t t r s N o d e Attrs_{Node} AttrsNode 转换至虚幻引擎程序化内容生成编辑器。该方法也可扩展至其他游戏开发工具，因其通常采用模块化设计并在文档中提供必要的使用信息。
3.5 游戏玩法代码智能体
为实现可执行的游戏玩法逻辑，本文采用规划式生成流程：系统先分析
D
e
s
c
G
Desc_{G}
DescG，规划所需的功能逻辑模块，再生成对应的虚幻引擎C++实现代码，形式化表示为：
L
i
s
t
[
A
t
t
r
s
M
]
=
P
l
a
n
C
o
d
e
(
D
e
s
c
G
)
(
7
)
List[Attrs_{M}]=\mathcal{P}lan_{Code}(Desc_{G}) \quad (7)
List[AttrsM]=PlanCode(DescG)(7)
f
o
r
M
i
∈
S
o
r
t
M
(
L
i
s
t
[
A
t
t
r
s
M
]
)
:
C
o
d
e
M
i
=
G
e
n
e
r
a
t
e
C
o
d
e
(
M
i
,
D
e
p
s
M
i
)
(
8
)
for\ M_{i} \in Sort_{M}(List[Attrs_{M}]): Code_{M_{i}}=\mathcal{G}enerate_{Code}(M_{i}, Deps_{M_{i}}) \quad (8)
for Mi∈SortM(List[AttrsM]):CodeMi=GenerateCode(Mi,DepsMi)(8)
其中，
L
i
s
t
[
A
t
t
r
s
M
]
List[Attrs_{M}]
List[AttrsM] 为规划得到的模块属性列表，
M
i
M_{i}
Mi 为第i个模块，
S
o
r
t
M
Sort_{M}
SortM 基于模块依赖关系执行拓扑排序，
C
o
d
e
M
i
Code_{M_{i}}
CodeMi 为模块
M
i
M_{i}
Mi 的C++实现代码，
D
e
p
s
M
i
Deps_{M_{i}}
DepsMi 为模块
M
i
M_{i}
Mi 依赖模块的生成代码；
P
l
a
n
C
o
d
e
\mathcal{P}lan_{Code}
PlanCode 与
G
e
n
e
r
a
t
e
C
o
d
e
\mathcal{G}enerate_{Code}
GenerateCode 的提示词细节分别见附录图11与图12。
具体而言，
A
t
t
r
s
M
Attrs_{M}
AttrsM 包含设计用途、使用方式与依赖模块，为代码生成提供更丰富的上下文。本文在
G
e
n
e
r
a
t
e
C
o
d
e
\mathcal{G}enerate_{Code}
GenerateCode 中还提供代码模板与引擎相关约束（如导出/注册宏、头文件白名单、日志记录、跨模块访问），提升代码生成稳定性。此外，遵循通用游戏开发实践，本文为模块代码设计通用模块管理框架作为模型上下文协议。上述设计共同保障游戏玩法逻辑可被引擎内交互稳健触发，同时保持可扩展性并贴合虚幻引擎规范。
3.6 交互对象智能体
生成的模块（如背包模块、对话模块）在对象交互实现方法内被调用，以执行具体游戏玩法逻辑（如拾取、对话）。为实现交互功能，本文首先推导需调用的模块及其方法调用顺序，形式化表示为：
L
i
s
t
[
A
t
t
r
s
I
n
t
]
=
P
l
a
n
I
n
t
(
L
i
s
t
[
A
t
t
r
s
O
b
j
]
,
L
i
s
t
[
C
o
d
e
M
]
)
(
9
)
List[Attrs_{Int}]=\mathcal{P}lan_{Int}(List[Attrs_{Obj}], List[Code_{M}]) \quad (9)
List[AttrsInt]=PlanInt(List[AttrsObj],List[CodeM])(9)
其中，
A
t
t
r
s
I
n
t
Attrs_{Int}
AttrsInt 表示交互对象属性，包括交互描述、模块依赖、交互流程，以及是否需要调用战斗、导航插件等外部系统；
P
l
a
n
I
n
t
\mathcal{P}lan_{Int}
PlanInt 的提示词细节见附录图13。
基于上述推导的属性，本文为每个交互对象生成C++代码：
C
o
d
e
I
n
t
=
G
e
n
e
r
a
t
e
I
n
t
(
A
t
t
r
s
I
n
t
,
L
i
s
t
[
C
o
d
e
M
]
)
(
10
)
Code_{Int}=\mathcal{G}enerate_{Int}(Attrs_{Int}, List[Code_{M}]) \quad (10)
CodeInt=GenerateInt(AttrsInt,List[CodeM])(10)
其中，
C
o
d
e
I
n
t
Code_{Int}
CodeInt 为交互对象生成的C++代码；
G
e
n
e
r
a
t
e
I
n
t
\mathcal{G}enerate_{Int}
GenerateInt 通过模块上下文与交互流程保障交互逻辑的一致性，其提示词细节见附录图14。
3.7 自动化试玩智能体
生成交互代码后，本文完成了完整虚幻引擎游戏的构建。但
D
e
s
c
S
Desc_{S}
DescS 与
D
e
s
c
G
Desc_{G}
DescG 存在多种实现方式，生成内容的评估成为挑战。为解决该问题，本文通过生成并执行测试指令搭建评估环境，形式化表示为：
L
i
s
t
[
C
m
d
]
=
G
T
e
s
t
(
D
e
s
c
S
,
D
e
s
c
G
,
L
i
s
t
[
C
o
d
e
M
]
,
L
i
s
t
[
C
o
d
e
I
n
t
]
)
(
11
)
List[Cmd]=\mathcal{G}_{Test}(Desc_{S}, Desc_{G}, List[Code_{M}], List[Code_{Int}]) \quad (11)
List[Cmd]=GTest(DescS,DescG,List[CodeM],List[CodeInt])(11)
其中，
L
i
s
t
[
C
m
d
]
List[Cmd]
List[Cmd] 为评估游戏
G
G
G 所用的测试指令；
G
T
e
s
t
\mathcal{G}_{Test}
GTest 的提示词细节见附录图15。
测试指令分为两类：移动至对象、执行特定交互。本文通过模型上下文协议在虚幻引擎运行时环境中自动执行这些指令。运行时截图、执行日志、 L i s t [ N o d e ( x , y ) ] List[Node_{(x,y)}] List[Node(x,y)]、 L i s t [ C o d e M ] List[Code_{M}] List[CodeM]、 L i s t [ C o d e I n t ] List[Code_{Int}] List[CodeInt] 与中间规范将用于生成游戏 G G G 的最终评估，实现全面评测。
4 实验
本文从五个维度评估所提出的多智能体游戏生成系统AutoUE，对应前文提出的核心论点：
- Q1：AutoUE能否端到端生成完整、可玩的虚幻引擎游戏，生成游戏的整体质量如何？
- Q2：与现有场景生成基线方法相比，AutoUE生成的场景在美学质量上是否更优？
- Q3：基于检索增强生成的节点规范对生成有效程序化内容生成图的影响如何？
- Q4：游戏设计模式对生成的游戏玩法代码质量的影响如何？
4.1 实验设置
4.1.1 数据集
本文构建了包含20个游戏生成任务的基准数据集（记为PlayGen-20）。这些任务覆盖游戏设计中的常见交互（如拾取、开启、对话、检视、战斗）。任务细节见附录图4、图5与图6。
图3：与SceneX方法的视觉对比。第一列为SceneX生成的场景；第二列为AutoUE生成的对应场景；第三、四列为AutoUE在各场景中的交互效果。
为在不同游戏设计复杂度下更好地评估AutoUE，本文根据场景复杂度与交互复杂度，将PlayGen-20划分为三个难度类别：
- 简单（5个游戏）。此类任务聚焦新手引导与基础交互练习，设计包含单一或低复杂度交互、反馈清晰且失败代价低。该类别适用于评估端到端可玩度与基础交互正确性。
- 中等（7个游戏）。此类任务聚焦更多探索与收集玩法，设计包含多个交互对象，节奏较慢以鼓励玩家与环境进行更广泛的交互。该类别适用于评估组织多样化交互对象、丰富场景内容与实现更广泛交互覆盖的能力。
- 困难（8个游戏）。此类任务引入明确的流程约束与更强的交互依赖，设计具备更清晰的状态转换，场景对象与游戏玩法逻辑间耦合更紧密。该类别适用于评估复杂交互流程下的鲁棒性，包括依赖正确性与生成代码的可靠性。
表1：PlayGen-20数据集上的游戏评估结果
4.1.2 实验参数设置
所有实验均在虚幻引擎5中开展，该引擎是目前最先进、应用最广泛的游戏引擎之一。大语言模型方面，本文使用QwenPlus作为生成与评估的默认基座模型。在Q2实验中，仅为对齐基线方法使用GPT-4o进行评估。
4.2 整体游戏评估（Q1）
为客观评估AutoUE端到端生成的虚幻引擎游戏的整体质量，本文采用大语言模型评判评估方法，并精心设计评估提示词（提示词细节见附录图16）。
大语言模型从三个维度对每个游戏打分，分数范围均为1–10分：(1) 场景维度：基于构建日志与程序化内容生成节点链，评估程序化内容生成的正确性；(2) 游戏玩法维度：基于游戏玩法/交互属性与代码，评估游戏玩法与交互逻辑是否按预期运行；(3) 视觉维度：基于场景与交互截图，评估游戏与描述的视觉连贯性。三个维度分数按0.35、0.35、0.3的权重加权得到最终游戏总分。
值得注意的是，场景与游戏玩法维度重点评估构建是否成功，用于判断AutoUE能否端到端生成完整、可玩的游戏；而视觉维度用于评估游戏的生成质量。
如表1所示，AutoUE取得优异性能，表明该系统可稳健地端到端生成可玩的虚幻引擎游戏。
在场景维度，困难难度游戏得分高于中等难度游戏，原因是困难任务涉及更复杂的程序化内容生成图，成功构建此类图可获得更高分数。这也证明AutoUE可稳健处理更复杂的场景生成需求。
在视觉维度，简单难度游戏得分低于中等难度游戏，因内容约束限制了视觉丰富度；困难难度游戏得分最低，主要因交互行为与预期的偏差降低了视觉质量。这表明视觉指标对游戏生成质量敏感。
总体而言，游戏总分与游戏玩法分数符合预期的难度趋势，说明高难度下的核心挑战源于游戏玩法与交互逻辑的复杂度。
4.3 场景生成评估（Q2）
为进一步评估AutoUE生成场景的质量，本文沿用UnrealLLM的评估设置。具体而言，UnrealLLM采用GPT美学评分（GPT Aesthetic Score, GAS），通过评估构图、色彩和谐度、光照、材质与纹理保真度、细节丰富度、整体连贯性与艺术感染力等因素量化美学质量。
如表2所示，AutoUE取得最优GAS分数7.8，超越生成式与程序化基线方法，表明AutoUE生成的场景具备更高的美学质量。
表2：场景生成评估结果
与生成式基线方法相比，程序化方法的得分更稳定，说明程序化工具具备更强的结构先验与可控性，可更一致地生成高质量场景。然而，Infinigen、3D-GPT与SceneX在Blender等建模环境中合成场景，未充分利用游戏引擎内的程序化内容生成工具链。相比之下，UnrealLLM将程序化生成直接落地于虚幻引擎程序化内容生成图，取得7.71的高GAS分数，凸显引擎原生程序化内容生成流程在组织场景布局中的优势。
尽管AutoUE相较于UnrealLLM的提升有限，但需注意GAS是主观指标且存在明显的饱和效应。本文实证评估发现，获得8分以上的评分难度极大，接近8分的分数通常代表艺术质量已达到较高水平。此外，如图3所示，AutoUE生成的场景相较于SceneX具备更丰富的对象组合与更具可操作性的交互提示，形成更连贯的面向游戏玩法的布局。
4.4 程序化内容生成图评估（Q3）
为验证本文定义的程序化内容生成模式与基于检索增强生成的节点规范的有效性，本文在PlayGen-20数据集上开展消融实验。具体而言，本文设计三种变体与四项评估指标：
- 无模式（W/o patterns）：移除两类预定义的程序化内容生成节点链（大型对象与小型散射对象），自由构建程序化内容生成图。
- 无参数（W/o params）：从程序化内容生成文档语料库中移除所有程序化内容生成节点的参数内容。
- 无连接（W/o conns）：从程序化内容生成文档语料库中移除所有程序化内容生成节点的引脚连接内容。
S
N
o
d
e
S_{Node}
SNode：节点创建成功率，即节点是否为已定义的程序化内容生成节点。
S
P
a
r
a
m
S_{Param}
SParam：节点参数填充成功率。
S
P
i
n
S_{Pin}
SPin：节点引脚连接成功率。
S
P
C
G
S_{PCG}
SPCG：大语言模型评判的程序化内容生成图质量分数，分数范围1–10，提示词见附录图17。
如表3所示，AutoUE在所有难度下的节点创建、参数填充、引脚连接均达到100%成功率，并取得最高的
S
P
C
G
S_{PCG}
SPCG分数8.42，证明其可稳健生成高质量的程序化内容生成图。同时，每种变体均导致对应指标显著下降。无模式变体将
S
N
o
d
e
S_{Node}
SNode与
S
P
i
n
S_{Pin}
SPin大幅降至79.6%与64.0%，说明预定义模式为构建程序化内容生成图提供了关键的结构先验。无参数变体保持图结构可用，但
S
P
a
r
a
m
S_{Param}
SParam骤降至55.2%，同时
S
P
C
G
S_{PCG}
SPCG显著下降，证明检索到的参数语义对正确的程序化生成行为至关重要。无连接变体主要影响接线正确性：
S
P
i
n
S_{Pin}
SPin降至80.4%，
S
P
C
G
S_{PCG}
SPCG降至5.02，证实检索增强生成提供的引脚连接知识提升了程序化内容生成图连接的可靠性。
表3：程序化内容生成图评估结果
综上，实验结果证明本文定义的程序化内容生成模式与基于检索增强生成的节点规范，对在虚幻引擎中稳健构建程序化内容生成图具有重要意义。
4.5 游戏玩法代码评估（Q4）
为验证游戏玩法代码生成中游戏开发设计的有效性，本文同样设计三种变体与四项评估指标：
-
无依赖（W/o dependencies）：在 P l a n C o d e \mathcal{P}lan_{Code} PlanCode与 G e n e r a t e C o d e \mathcal{G}enerate_{Code} GenerateCode中移除模块依赖知识。
-
无代码模板（W/o code templates）：在 G e n e r a t e C o d e \mathcal{G}enerate_{Code} GenerateCode的提示词中移除代码模板。
-
无引擎约束（W/o engine constraints）：在 G e n e r a t e C o d e \mathcal{G}enerate_{Code} GenerateCode的提示词中移除引擎约束。
-
模块分析得分（Module Analysis Score, MAS）：评估规划的模块属性列表质量。
-
模块代码得分（Module Code Score, MCS）：评估生成的游戏玩法模块代码质量。
-
交互集成得分（Interactive Integration Score, IIS）：评估交互与模块集成的有效性。
-
游戏玩法代码得分（Gameplay Code Score, GCS）：评估游戏玩法代码生成的整体质量，计算公式为 0.3 × M A S + 0.3 × M C S + 0.4 × I I S 0.3×MAS+0.3×MCS+0.4×IIS 0.3×MAS+0.3×MCS+0.4×IIS。
上述指标由大语言模型评判，提示词见附录图18。若编译成功，MAS、MCS、IIS分数范围为1–10；否则MCS与IIS设为0。
如表4所示，三种变体均无法通过编译，导致GCS分数大幅下降。这表明移除模块依赖、代码模板或引擎约束，会严重破坏生成可编译虚幻引擎游戏玩法代码的能力。总体而言，实验结果验证了本文在游戏玩法代码生成中融入的游戏开发设计，对端到端生成可编译游戏玩法代码至关重要。
表4：游戏玩法代码评估结果
5 结论
本文提出一种全新的多智能体系统AutoUE，用于在虚幻引擎中自动化生成完整的3D游戏。通过结合检索增强生成、游戏设计模式与引擎特定约束，AutoUE可高效协同各智能体生成连贯场景、鲁棒的游戏玩法代码与交互对象，并通过自动化试玩实现游戏动态行为的评估。实验结果验证了AutoUE可生成高质量3D游戏。本工作也为未来自动化游戏开发的研究提供了可扩展的基础设施。
伦理分析
本工作不存在伦理相关问题。AutoUE是一款用于在虚幻引擎中自动化生成3D游戏的工具，旨在帮助开发者加速游戏开发流程。用于模型检索的数据集仅包含公开可获取的3D模型，游戏生成任务基于预定义描述，不涉及任何敏感信息或个人数据。
局限性
本文工作存在一定局限性：由于DreamGarden（一款基于虚幻引擎的先进3D游戏生成系统）尚未开源，本文无法将AutoUE与其进行对比。此外，尽管系统在各类任务中表现良好，但本文评估数据集的范围可能无法完全覆盖真实游戏开发场景的复杂度。因此，在更广泛的任务集与更具挑战性的游戏场景中开展进一步评估，将有助于验证AutoUE的可扩展性与鲁棒性。
思考
RAG + 专业工具文档的范式：不只是简单的检索增强，而是针对 UE PCG 做"节点类型 → 语义搜索 → 参数/引脚填充"三层 RAG。这种将工具文档做语义索引的思路可直接迁移到任何需要 LLM 调用专业工具的场景。
MCP 作为 Agent-Engine 统一桥梁：用 MCP 统一所有 Agent 与 UE 的交互，消除了每个 Agent 独立实现通信层的问题。可推广到"Agent + 专业软件"的任何场景。
附录
图4：所有简单难度游戏的描述与截图
图5：所有中等难度游戏的描述与截图
图6：所有困难难度游戏的描述与截图
图7：3.2节中分解操作的提示词细节
图8：3.3节中对象生成操作的提示词细节
图9：3.4.1节中节点规划操作的提示词细节
图10：3.4.2节中节点生成操作的提示词细节
图11：3.5节中代码规划操作的提示词细节
图12：3.5节中代码生成操作的提示词细节
图13：3.6节中交互规划操作的提示词细节
图14：3.6节中交互生成操作的提示词细节
图15：3.7节中测试生成操作的提示词细节
图16：4.2节中整体游戏评估的提示词细节
图17：4.4节中程序化内容生成图评估的提示词细节
图18：4.5节中游戏玩法代码评估的提示词细节
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
7
0- 0
已为社区贡献20条内容
所有评论(0)