← 返回 2026-07-15

MAGIC：基于大语言模型生成可导航多场景游戏世界 MAGIC: Transition-Aware Generation of Navigable Multi-Scene Game Worlds with Large Language Models

Tsz Hei Fan, Choi Wing Fung, Yuxuan Wan, Shuqing Li, Michael R. Lyu 📅 2026-07-13 👍 5 2026-07-19 18:30
Unity 场景过渡 多场景生成 大语言模型 文本到3D 游戏开发
arXiv HuggingFace PDF

一条文本提示一键生成门户连通、可互相穿行的多场景3D游戏工程

前置知识

大语言模型 LLM

基于Transformer架构在海量文本上预训练的概率生成模型，能根据自然语言提示产生结构化输出（如JSON、领域描述语言）。本文用 GPT-4.1-mini-2025-04-14 作为规划与场景描述的主干，借助上下文学习与思维链把用户提示拆解为单场景描述与过渡图。

整条流水线把LLM当作'环境美术设计师'使用，理解LLM的能力边界（语义强、空间感知弱）是看懂为何要加验证循环与洪泛填充的关键。

多模态大语言模型 MLLM

在LLM基础上接入视觉编码器、能同时处理图像与文本的模型。本文在评估代理阶段用它对'环绕拍摄的门户截图'做外观判定，判断生成的物件是否与文本描述的门户形态一致。

门户匹配率(Portal Match Rate)依赖MLLM的视觉判定，理解其严格性才能解释为何该指标(0.7885)低于其他端到端指标。

文本到3D场景生成 Text-to-3D Scene

从自然语言描述合成带家具、光照、网格的三维室内场景的研究方向，代表系统有Holodeck与Scenethesis。本文复用了Scenethesis的物件抽取方法、DSL约束语言与网格合成算法作为单场景内的构建积木。

本文的核心增量不在'单场景生成'，而在'多场景连通'；不熟悉这条技术线就无法理解MAGIC到底补了什么缺口。

洪泛填充与占据栅格 Flood-fill / Occupancy Grid

把场景离散成 $G\in\{0,1\}^{r\times c}$ 二维栅格(cell大小 $s=0.05$)，障碍格记0、可行走格记1。从门户格 $g_p$ 起迭代把相邻可行走格并入可达集，当可达集大小等于全部可行走格数时门户判定为可达。

这个连通性检查是本文解决C2可导航性障碍的核心机制，也是它能在connectivity指标上达到0.9952的根本原因。

Unity引擎与场景图 Scene Graph

Unity是主流实时3D游戏引擎，工程由场景(Scene)、网格(Mesh)、脚本(如LevelLoader)、碰撞体(Collider)等资产组成。本文最终交付可运行的Unity工程，过渡通过挂载在门户对象上的LevelLoader脚本，在相机碰撞时加载目标场景实现。

理解Unity资产组织与碰撞触发机制，才能看懂Stage 3为何要把脚本绑到门户而非相机、以及为何LLM基线生成的工程全部无法运行。

领域特定语言 DSL

一种为特定领域设计的小型约束表达语言。本文沿用Scenethesis的DSL来声明物件的位置与旋转约束（如'靠墙'、'居中'），供校正模块逐条比对违反情况并驱动重新生成。

DSL让空间布局从'自然语言'变成'可验证的约束'，是把LLM输出从不确定变为可校验的关键工程手段。

研究动机

多场景导航是当代3D游戏的标志性玩法——地牢探索、密室逃脱、RPG都要求玩家在一个有界空间清完目标后，穿过一扇门、楼梯或过场动画进入下一个场景。这对设计师是双重耦合难题：每个场景必须是连贯且可通行的室内空间，而每个门户又必须两端端点一致（位置、目的地、过渡效果匹配）。设计师必须手工维护一张连接图，并让成对的门户、过渡脚本、门洞净空在众多文件中保持一致，已有游戏开发研究[2]把这种手工编写的连通性列为3D游戏制作中最耗工的部分之一。近年Holodeck[3]、Scenethesis[4]等LLM/MLLM场景生成器虽然让'单室内合成'成本骤降，但它们一次只产出一个场景，无法靠朴素重复得到一个真正连通的多场景世界。文章明确指出朴素地把单场景模型重复n次会撞上三道墙：(C1)一致性——门户是无状态跨场景的联合对象，LLM随上下文增长容易丢弃或幻觉跨场景引用；(C2)可导航性——门户命名正确不代表放完家具后玩家能走过去；(C3)评估——没有任何现成指标会真正执行一次过渡，错链的门户或损坏的过渡脚本对单场景指标完全不可见。

本文的目标是本文的目标是设计一个端到端的'提示到工程'系统：从单条自然语言提示出发，自动产出一个可运行的多场景3D游戏工程，其中场景之间由一致、可导航的过渡所连接。具体而言要同时攻克上述三道墙——用一个跨阶段共享的过渡感知中间表示(IR)来保证一致性(C1)，用一个基于2D占据栅格洪泛填充的门户可达性校验器来保证可导航性(C2)，并首次提出一个真正会'在游戏里跑一遍每个过渡'的过渡评估代理来补上评估缺口(C3)。作者希望证明：仅凭文本输入、无需GPU、在普通macOS/Windows机器上即可端到端生成功能完备的多场景世界，并在一个包含100个多场景实例的新基准上达到高精度的过渡识别。

与已有工作不同的是，本文的独特切入角度在于把多场景生成显式建模成一个程序合成与约束满足问题，而不是'多跑几次单场景生成器'。此前没有任何工作把'门户'与其'目的场景'联合生成：Genie、Narrative-to-Scene只做2D；Holodeck与Wonder家族只合成单室内或全景而不连接场景；OpenGame能产出可交互工程却不做真正的3D场景合成（见Table I，只有MAGIC同时勾选文本输入、3D合成、跨场景过渡、可交互输出四项）。作者的关键洞见是引入一个过渡感知自动机 $A=(S,P,\delta,E)$ 作为整条流水线的'单一事实源'，让规划、规格、生成、组合四个阶段都读写同一张过渡图，从而把跨文件一致性从'靠人盯'变成'靠结构保证'；同时用一个真正部署进Unity可执行文件、会模拟玩家走过去的评估代理，第一次为多场景过渡提供了可执行的度量。

核心方法

直觉上，MAGIC像一个会把'整体设计图'记在脑子里、按图施工的美术团队：先听懂用户要几个房间、房间之间怎么连通，画出一张所有人共享的'过渡图'；然后逐个房间摆家具，但每摆一件都要回头确认门户还能走通；接着把每个房间变成带网格和脚本的Unity工程；最后把所有单房间工程缝合成一个能互相穿越的整体。技术路线对应四个阶段：Stage 1 规划，LLM把用户提示拆成每场景描述(扩写到8-12个物件)加一个过渡感知自动机 $A=(S,P,\delta,E)$，其中 $\delta\subseteq S\times P\times E\times S$，因门户双向可通行故 $\delta$ 对称、每条边只存一次；Stage 2 场景规格，对每个场景提取区域、分层注入物件与连接(门窗)，用DSL约束生成初稿并由校正模块循环修正，再用洪泛填充在 $s=0.05$ 的占据栅格上验证每个门户可达；Stage 3 场景生成，按规格合成网格、生成LevelLoader过渡脚本并挂到门户碰撞体上，产出单场景可执行Unity工程；Stage 4 组合，把各单场景工程合并为引用彼此脚本的统一工程。

核心创新是把'过渡'提升为贯穿全流水线的一等公民对象，而不是事后的连接补丁。已有单场景方法的状态式提示会在上下文增长时丢失跨场景引用，MAGIC则让规划阶段产出的过渡感知自动机成为下游所有阶段共同查询与更新的数据结构，并用一个二次LLM验证循环确保每个场景描述里出现的门户数量与类型与图一致。与已有方法的本质区别有三：(1)连接对象与目的场景联合建模——门户不只标在自己场景里，而是图上带效果标签的无向边；(2)可导航性被显式校验——把场景离散成 $G\in\{0,1\}^{r\times c}$、行数 $r=(\max_z-\min_z)/s$、列数 $c=(\max_x-\min_x)/s$，从门户格洪泛扩张，连通率 $=|V|/|\{(i,j):G_{ij}=1\}|$ 必须为1才接受布局；(3)评估被做成可执行——评估代理真正跑游戏触发过渡，而不是只比像素相似度。这套'结构共享+约束校验+可执行评估'的组合是单场景生成器所完全没有的。

方法步骤详情

Stage 1 规划：用户提示→LLM分离单场景描述(每场景扩到8-12物件)并输出过渡感知自动机 $A=(S,P,\delta,E)$，门户双向故每边只存一次；二次LLM循环校验门户数量/类型与图匹配，效果未指定时按相邻场景风格差在FadeInOut/IrisWipe间选。Stage 2 场景规格：逐场景从自动机预处理出门户，分连接门户(通outside的门、isPortal为真的窗)与物件门户；提取区域→分层注入物件(先列全清单再逐层填属性)→连接用移位算法贴墙并内移半个厚度 $T$→对每区域取栅格 $G$ 从门户格 $g_p$ 迭代扩张算连通率，不达1则重摆至迭代上限、返回连通率最高布局。Stage 3 场景生成：从规格取门户→匹配自动机边得(目的场景、门户名、效果)三元组→用Scenethesis算法合成网格→填预定义LevelLoader脚本模板→物件加刚体防穿透→LevelLoader挂到门户碰撞体(而非相机)避免触发不可预测→建Unity工程目录写入资产脚本。Stage 4 组合：丢弃多余中间产物，把各单场景Unity工程合并为最终可运行多场景工程。

技术新颖性

技术新颖性体现在三处工程化创新叠加。第一，过渡感知自动机作为'单一事实源'：它既是规划产物也是下游查询更新的图结构，强制要求图连通(每个场景可达)、门户对称双向，把跨文件一致性从经验问题变成结构不变量——这是相对Holodeck等'各场景独立生成再硬拼'方法的本质进步。第二，洪泛填充可达性校验把'放完家具后门户是否还能走'这一单场景指标看不见的失败(C2)首次显式量化，并嵌入生成循环做拒绝采样式重摆，而非事后告警。第三，过渡评估代理是首个'真正在打包好的Unity工程里把每个过渡跑一遍'的度量，它先扫描所有可能是门户的对象逐个碰撞测试、再扮演玩家从出生点导航到门户验证可达性、再用MLLM对环绕截图判外观，输出Precision/Recall/F1/Approach Rate/Portal Match Rate——填补了像素级指标(SSIM)与深度指标(CLIP)从不执行过渡的评估空白。三者在Table I中使MAGIC成为唯一同时满足四项能力的系统。

The MAGIC pipeline and the elements that produce scene transitions, organized by the four stages: planning, scene specification, scene generation, and combination.
Fig. 1: The MAGIC pipeline and the elements that produce scene transitions, organized by the four stages: planning, scene specification, scene generation, and combination.
The transition-focused evaluation agent.
Fig. 2: The transition-focused evaluation agent.

实验结果

Stage 1(Table III)：MAGIC场景得分0.9672、图得分0.9711，高于LLM基线0.9239/0.9089，验证循环主要拉高图准确率。Stage 2 门户识别(Table IV)：MAGIC精度0.8333/召回0.9487/F1 0.8709，召回最高几乎不漏真实门户；Holodeck最弱(0.7350/0.6026/0.6390)。Stage 2 连通性(Table V)最亮眼：MAGIC连通率0.9952近完美可达、占用0.2802适中，而LLM连通0.8718却占用仅0.1010过稀疏，Holodeck占用0.3971却连通最低0.8545摆得密但堵路。Stage 3：MAGIC全部用例生成可执行工程，LLM基线0%可运行且近一半用例生成多余LevelLoader使过渡不可预测。端到端(Table VI)：精度0.9871/召回0.9481/F1 0.9637/Approach 0.9486/Portal Match 0.7885，场景数1-5不随规模退化；Portal Match Rate偏低主要因MLLM判定严格且网格数据集覆盖有限。

Qualitative examples of transition effects in generated scenes, comparing FadeInOut, IrisWipe, and no transition across representative cases.
Fig. 3: Qualitative examples of transition effects in generated scenes, comparing FadeInOut, IrisWipe, and no transition across representative cases.
查看结构化数据
任务指标本文基线提升
端到端跨场景过渡识别(100例多场景基准) Precision / Recall / F1 0.9871 / 0.9481 / 0.9637 无直接端到端基线(单场景方法不产出连通世界) 首个把过渡做到F1>0.96的可执行系统，100%用例产出可运行工程
Stage 2 单场景门户连通性(可达率) Connectivity(越高越好,1为完全可达) 0.9952 LLM基线 0.8718 / Holodeck 0.8545 洪泛填充校验使连通率接近完美，比次优LLM高12.3个百分点
Stage 2 门户召回(不漏真实门户) Recall 0.9487 LLM基线 0.9188 / Holodeck 0.6026 召回三者最高，比Holodeck高34.6个百分点，降低断链风险
Stage 3 可执行Unity工程产出率 工程可运行比例 100% LLM基线 0% 模板化脚本生成与资产组装使工程必然可运行
评估代理与人工判断一致性(20例) MeanAbsDiff(越小越准) 0.0299 AB1(无门户候选抽取) 0.2187 / AB2(仅语义) 0.0361 门户候选抽取+MLLM外观判定使代理最贴近人工，且每场景仅40.70秒
Stage 1 规划图准确率 Average Graph Score 0.9711 LLM基线 0.9089 验证循环使过渡图得分提升6.2个百分点

局限与改进

作者承认：MAGIC仅面向室内场景、仅支持Unity引擎、只提供FadeInOut与IrisWipe两种过渡效果、只接受英文提示；门户外观受限于物件网格数据集覆盖——当最接近的网格缺语义线索(如'directory board'只有普通板子)时，MLLM判官会正确拒绝从而压低Portal Match Rate(0.7885)，但这并非流水线故障；物件摆放是尽力而为，预算耗尽时返回连通率最高的布局，仍有少数门户可能被堵。Threats to Validity进一步指出：基准是程序化生成的100个合成室内用例(1-5场景)、仅单一引擎与单一模型族评估，未测户外或大规模世界；流水线与基线都依赖随机LLM，所有数字来自每例单次运行、无重复实验与方差、无显著性检验，点估计可能偏乐观；代理可靠性研究仅20例、两位标注者，统计强度有限。我的观察：connectivity近满分部分因场景物件偏少(占用率仅0.28)，密集真实场景下洪泛填充未必仍能保持；Portal Match Rate(0.79)与端到端精度(0.99)的巨大落差说明'过渡能触发'与'门户长得对'是两回事。

独立分析的弱点

第一，过渡效果种类过少(仅FadeInOut/IrisWipe)，难表达'开门动画''电梯升降''传送门旋涡'——改进方向是把效果也建模成可由LLM选择+模板化生成的脚本资产。第二，仅室内且仅Unity，泛化受限——户外地形、Unreal/Godot引擎需把Stage 3组装层抽象成可插拔'引擎后端'。第三，Portal Match Rate(0.7885)与精度(0.99)落差暴露门户外观短板，根因是网格数据集覆盖不全——可引入文生3D单物件扩散模型动态补全缺失门户资产。第四，预算耗尽后仍有少数门户被堵(连通0.9952而非1.0)——可引入更强约束求解器(如SAT/线性规划布局)或主动'让路'重摆。第五，数字为单次运行无方差、代理可靠性仅20例——应做多次重复实验报告置信区间。第六，仅文本输入，无法表达'此门正对落地窗'等精确空间意图——可加草图/参考图等多模态输入。

未来方向

作者在结论中明确提出三个方向：(1)多模态输入与显式门户激活动作，以拓宽可表达设计的范围；(2)人在环的阶段间干预(例如在Stage 3前编辑场景规格)，以提高一次满意的成功率；(3)扩展到室内之外、增加更多过渡效果、支持Unity以外引擎，以检验方法的泛化性。基于本成果还可延伸若干方向：把过渡感知自动机 $A=(S,P,\delta,E)$ 升级为带状态/条件的有限状态机(如'需要钥匙才能开此门')，从而支持解谜与进度门控；把洪泛填充校验从2D占据栅格推广到3D(考虑跳跃、攀爬)，支撑动作类游戏的垂直导航；将过渡评估代理改造为RL训练环境，用'过渡可触发+可达+外观匹配'作为奖励信号微调生成策略，把当前的事后校验变成在线优化；探索从玩家行为日志反推过渡图缺失边的主动学习，自动发现'玩家走到死路'的断链场景并触发再生成。

复现评估

复现友好度较高。代码已开源在 https://github.com/sereneee1201/MAGIC/ ，论文给出主干模型(GPT-4.1-mini-2025-04-14)、基线(GPT-4.1)、温度(0.7)、栅格cell大小($s=0.05$)、物件数(8-12)等关键超参，并说明无需GPU、在macOS与Windows上即可运行，每场景中位耗时33.35分钟(均值46.36分钟)，右偏分布表明少数用例很慢。基准由MIT Indoor 67与MMIS两数据集经过程化脚本合成100例，覆盖单场景、环路、分支、单一/混合门户类型，并附Stage 1评估提示词(Appendix A)为模板。不利因素：过渡效果依赖固定物件网格数据集(未完全公开)、最终产物绑定Unity工程结构与Scenethesis的DSL/合成算法，迁移到其他引擎需重写Stage 3；所有结果单次运行无方差、未做显著性检验；评估代理依赖MLLM判官且严格度可调，复现时需对齐系统提示。总体难度中等：有Unity与LLM API经验者可按README跑通，但要完整复现端到端数字需仔细对齐数据集采样与提示词。

论文图表

Table I: Comparison of different scene generation methods.

该表沿四项能力(文本输入/3D场景合成/多场景过渡/可交互输出)对比Genie、Holodeck、Narrative-to-Scene、OpenGame、UniGen、WonderTurbo/Verse/World与MAGIC。只有MAGIC在四列全部打勾，其余系统各自只覆盖部分能力。

这是论文定位的核心证据，一眼说明MAGIC填补的正是'多场景过渡'这一无人覆盖的交叉缺口，是理解研究动机的关键。

Table II: Agreement of MAGIC's evaluation agent and two ablations (AB1, AB2) with human judgment, together with per-scene cost.

该表在20例上对比评估代理及两个消融与人工判断的签差Δ=Human-Method(越接近0越好)。MAGIC代理MeanAbsDiff最低(0.0299)、每场景40.70秒；AB1(去掉门户候选抽取)耗时暴涨到1081.61秒且∆Precision -0.5273；AB2(只用语义线索不看图)MeanAbsDiff 0.0361但在Portal Match Rate上偏差更大。

它证明评估代理本身可靠且高效，是端到端评估结果(Table VI)可信度的基石，也说明'门户候选抽取+MLLM外观判定'两步缺一不可。

Table III: Results of MAGIC and the LLM baseline after passing the planning stage.

该表给出Stage 1规划阶段的平均场景得分与平均图得分：MAGIC为0.9672/0.9711，LLM基线为0.9239/0.9089。

它量化了规划阶段验证循环的增益(图得分提升6.2个百分点)，证明'共享过渡感知中间表示'从源头就比朴素LLM更准，是回答RQ1的直接证据。

Table IV: Precision, recall, and F1 of the three methods.

该表给出Stage 2三方法在门户识别上的精度/召回/F1：LLM 0.8825/0.9188/0.8863、Holodeck 0.7350/0.6026/0.6390、MAGIC 0.8333/0.9487/0.8709。MAGIC召回最高(几乎不漏真实门户)，精度略低于LLM因偶有额外门户。

它回答RQ2中'门户是否生成正确'的部分，并说明MAGIC在召回-精度间选择了'宁多勿漏'的权衡(漏门户会导致断链，危害更大)。

Table V: Connectivity and occupancy of the three methods.

该表给出连通率与占用率：LLM 0.8718/0.1010、Holodeck 0.8545/0.3971、MAGIC 0.9952/0.2802。MAGIC连通率近乎完美且占用率适中(约30%)，而LLM过于稀疏、Holodeck摆得过密却堵路。

这是本文最亮眼的结果，直接证明洪泛填充校验有效解决了C2可导航性障碍，是MAGIC区别于单场景生成器的核心量化证据。

Table VI: Performance of MAGIC in the end-to-end evaluation.

该表给出端到端评估：精度0.9871、召回0.9481、F1 0.9637、Approach Rate 0.9486、Portal Match Rate 0.7885。前三项均超0.9，Portal Match Rate偏低主要因MLLM严格且网格数据集覆盖有限。

这是论文最终战绩，直接回答RQ5，是判断MAGIC整体有效性的决定性数字；同时其与精度的落差也提示了门户外观这一开放短板。