香港中文大学出手:用AI帮你搭建一个多场景3D游戏世界,只需一句话
这项由香港中文大学计算机科学与工程系主导的研究于2026年7月13日以预印本形式发布在arXiv平台编号为arXiv:2607.11594。研究尚未正式发表于特定期刊已提交IEEE待审。有兴趣深入了解技术细节的读者可通过上述编号查阅完整论文。**当游戏世界的搭建变成一件苦差事**做过游戏的人都知道哪怕是最简单的闯关类游戏也要面对一个令人头疼的工程问题你得精心设计每一个场景还要保证从一个场景跳转到下一个场景的门两边完全对得上——目的地对、位置对、视觉特效对——哪一环出错玩家就会卡住或者穿越到一个莫名其妙的地方。更麻烦的是这种过场衔接需要手动维护大量的脚本文件和连接表格稍有疏漏整个游戏世界就会四分五裂。近年来借助大型语言模型LLM可以理解为像ChatGPT这样能读懂人类语言、并生成各种内容的AI研究者已经能够让AI自动生成单个室内场景——你告诉它帮我造一间中世纪图书馆它就能给你生成一整套带家具的三维空间。问题是这些AI每次只能生成一个场景把它反复运行几次你得到的是一堆互相不认识的孤岛根本拼不成一个玩家可以穿行其中的完整世界。香港中文大学的研究团队为此设计了一套名为MAGIC的系统——全称是Multi-scene Automated Game worlds generator with Intelligent Connectivity直译过来就是带智能连接能力的多场景自动游戏世界生成器。它的目标很直接你只需要用普通的语言描述你想要的游戏世界MAGIC就会自动帮你生成多个场景并把它们用可以正常使用的传送门连接起来最终打包成一个可以直接在Unity游戏引擎里运行的项目。---一、三块绊脚石为什么简单地重复用AI生成场景行不通要理解MAGIC解决了什么问题先得搞清楚重复生成到底会出哪些岔子。第一个麻烦是两边对不上。一扇门在A场景叫通往地牢的铁门在B场景可能根本就没有这扇门或者被叫成了完全不同的名字。这就好比你跟朋友约好从北京南站坐高铁过来结果朋友去的是北京西站两人根本碰不上面。AI在处理多个场景时随着信息越来越多很容易忘记之前说过的约定导致跨场景的门口信息对不上。第二个麻烦是门被家具堵住了。即便两个场景里的门名字一样、位置一样但等到AI把家具、桌椅、书架都摆进去之后门口可能正好被一张大沙发挡住了。玩家根本走不到门跟前场景之间的跳转就彻底失效。这个问题用现有的评估工具完全检测不出来因为那些工具只看场景好不好看、对不对题从不管门能不能走进去。第三个麻烦是没有人真的去测。目前所有评估AI生成3D场景好坏的工具都只是拿生成结果和参考图片比一比或者看看场景是否符合文字描述。没有任何工具会真正进入这个游戏世界操控角色走到门口踢一脚看看到底能不能跳转到下一个场景。所以哪怕门被堵死了、跳转脚本写错了评估系统依然可能给出优秀的成绩。MAGIC的设计目标就是把这三块绊脚石一块一块地搬开。---二、MAGIC的四步流水线一句话变成一个完整游戏项目MAGIC的工作方式可以用建筑施工来理解。建一栋大楼你需要先画总平面图再细化每个房间的图纸再按图施工最后把各楼层合并成一栋完整的建筑。MAGIC的四个阶段做的是完全类似的事情。**第一步规划阶段——画出整个世界的蓝图**用户输入一段自然语言描述比如我想要一个由图书馆、密室和地牢三个区域组成的逃脱游戏图书馆和密室之间有一扇滑动书架门密室和地牢之间有一扇铁栅栏门。MAGIC的规划模块会把这段描述拆开分别提炼出每个场景应该是什么样的同时建立一张过场地图——用数学的方式表达哪两个场景之间有门、这扇门叫什么名字、穿越时会有什么视觉特效目前支持渐入渐出和光圈收缩两种效果。这张过场地图被称为过渡感知自动机它就像建筑师手里的总平面图所有后续步骤都要参照它。为了确保这张图的准确性系统会用第二个AI模型反复校验每个场景里应有的门的数量和类型都会被统计一遍有缺漏的话就重新生成直到完全吻合。这一步直接解决了两边对不上的问题——因为所有场景都必须以这张共同的蓝图为准。**第二步场景规格化——把每个房间细化到每一件家具**有了总蓝图之后MAGIC开始针对每个场景分别展开设计。这一步相当于设计师把总平面图细化成每个房间的详细装修方案。系统首先把场景描述扩展成包含8到12件物品的详细清单然后把场景划分成若干区域比如图书馆可以分成阅览区、书架区、入口区给每个区域分配合适的家具。所有家具的摆放位置会按照一套领域专用语言可以理解为一种专门描述谁在哪里、朝哪个方向的格式化语言生成初稿再由校验模块逐条检查是否违反规则有问题就重新生成直到所有约束都满足为止。门和窗户的处理有额外讲究。系统会精确计算AI给出的门的位置和墙壁之间的距离然后把门推到离墙最近的位置再向内侧偏移半个门厚度让门看起来更自然地嵌在墙里。所有被标记为传送门的门都会被打上特殊的isPortal标签后续各阶段可以通过这个标签精准找到它们。这一步最关键的设计是用来检测门有没有被堵住的洪水填充算法。这个算法的工作原理类似于在房间地图上倒水从传送门的位置开始让水向四面八方流动经过所有没被家具占据的空格。如果水能流遍整个房间说明传送门从任何位置都能走到如果有些地方水流不进去说明那里被家具堵死了需要重新调整摆放方案。具体来说算法会把整个场景转换成一张细密的网格地图每个网格格子的边长只有0.05个单位大约是一根手指的宽度标记出哪些格子被家具占用、哪些是可以行走的空地。然后从传送门出发用广度优先搜索一种计算机找路的方式类似于水往低处流扩展可达区域。最终可到达格子数占全部可走格子数的比例就是这个场景的连通率。连通率达到100%才算通过否则系统会重新调整家具摆放直到达标或者尝试次数耗尽——耗尽时会保留连通率最高的那个方案。这一步直接解决了门被家具堵住的问题。**第三步场景生成——把图纸变成真实的3D项目**有了详细的场景规格之后MAGIC调用Scenethesis一个专门根据规格生成3D模型的系统来生成所有家具、墙壁、地板的三维网格。与此同时系统会根据场景规格里的传送门信息自动生成对应的关卡加载脚本LevelLoader script——这是Unity游戏引擎里负责当玩家走到这扇门时跳转到哪个场景的程序代码。这里有一个工程细节值得一提系统是把关卡加载脚本挂在门这个物体上而不是挂在玩家角色上。原因是如果挂在玩家角色上触发机制会变得不稳定容易出现明明走到门口了却没反应的情况。挂在门上之后只要检测到玩家的摄像机碰撞了这扇门就自动触发跳转稳定性大大提高。这个阶段用的是模板填充方式而不是让AI自由发挥写代码。这样做的好处是生成出来的脚本保证能运行不会因为AI写了个语法错误的代码而导致整个项目崩溃。**第四步整合——把散件拼成完整的游戏**前三步对每个场景分别执行一遍最终得到若干个独立的Unity项目文件。第四步做的事情就是把这些散件合并成一个完整的Unity多场景项目让场景之间的跳转脚本能够正确引用彼此。这一步本质上是文件管理和路径整合技术上相对简单但对于用户来说是最直观的——你打开最终项目就是一个可以运行、可以在场景之间穿梭的完整游戏世界。---三、那个真正进入游戏测试的评估探员MAGIC不只是生成工具研究团队还为它配套设计了一个全新的评估机制——一个真正会进入游戏、走到门口、踢一脚看看能不能过去的自动化评估探员。这个探员的工作流程分四个阶段。第一步它扫描游戏项目里所有可能是传送门的物体列出候选名单。第二步它挨个测试这些候选传送门——让游戏角色去碰一下看看有没有触发场景跳转如果有就记下跳到了哪里。第三步对于那些真实有效的传送门探员让角色从出生点出发尝试走到传送门跟前检验它在实际游戏中是否能被玩家接近同时对传送门拍一圈环绕照片把照片送给多模态大语言模型能同时理解文字和图片的AI判断这扇门的外观是不是和描述的滑动书架门或铁栅栏门相符。第四步把所有场景的测试结果汇总对照预先设定的标准答案即规划阶段生成的过场地图计算精确率、召回率、F1分数、接近率和传送门外观匹配率五项指标。这五个指标可以这样理解精确率是AI生成的传送门中有多少是真实需要的召回率是所有应该有的传送门中有多少被正确生成了F1分数是这两者的综合评分接近率是生成的传送门中有多少是玩家实际上能走到的传送门外观匹配率是传送门的长相和描述是否相符。为了验证这个探员靠不靠谱研究团队让两名人工评审员对20个测试案例逐一手动检查然后把人工结果和探员结果做对比。结果显示探员和人工判断的差距极小各项指标的平均绝对差仅为0.0299——换句话说这个探员的判断和人类几乎一致。研究团队还额外做了两组对比实验。第一组消融实验1去掉了候选传送门提取这一步直接让探员检查所有物体——结果是探员被大量无关物体淹没耗时暴增到每个场景超过1000秒而且判断准确性严重下降。第二组消融实验2保留了候选提取但把拍照送给AI看外观换成只看传送门的名字来判断外观——结果在外观匹配率上明显差于完整版探员。完整版探员每个场景只需约40秒各项指标也最接近人类判断。---四、测试场地100个多场景案例的擂台研究团队构建了一个包含100个测试案例的专用基准数据集。这些案例来自两个公开数据集的组合一个是MIT 67室内场景数据集包含厨房、卧室、图书馆、健身房等67类功能各异的室内场景另一个是MMIS多模态室内场景数据集提供了不同设计风格的室内图像和文字描述。每个测试案例是一张场景图节点是具体的室内场景边是场景之间应有的跳转关系。案例规模从单个场景到五个场景互联不等跳转模式涵盖线性、环形和树状分支等多种拓扑结构传送门类型也有统一类型和混合类型两种。最终每个结构化案例都被转化为一段自然语言描述作为MAGIC和对比方法的输入。---五、和竞争对手比MAGIC赢在哪里MAGIC在每个阶段都和两类对比方法做了比较一类是直接用GPT-4.1提问LLM基线另一类是Holodeck一个已有的单场景生成系统。在规划阶段MAGIC生成的场景描述准确率达到0.97过场地图的图结构准确率达到0.97均优于LLM基线的0.92和0.91。两者都依赖语言模型的理解能力但MAGIC额外加入了验证循环使得过场地图更加可靠。在场景规格化阶段三种方法在传送门生成的精确率上相差不大但在召回率即应该有的传送门有没有全生成出来上差距明显MAGIC的召回率达到0.95LLM基线为0.92Holodeck只有0.60。连通率即传送门有没有被家具堵死上的差距更大MAGIC达到0.9952几近完美LLM基线为0.87Holodeck最低只有0.85而且它的场景密度最高占用率接近40%说明它放了很多家具但通道却最差。MAGIC的场景密度接近28%属于不太稀疏、也不太拥挤的平衡状态。在场景生成阶段MAGIC对所有100个测试案例均成功生成了可运行的Unity项目成功率100%。LLM基线则一个都没成功——原因在于它对Unity的文件结构和脚本规范了解不足哪怕只是文件命名出了一点点差错整个项目就无法打开。此外LLM基线在将近一半的案例中生成了多余的跳转脚本导致玩家走到某个地方会意外弹到一个不该去的场景。在端到端评估中MAGIC的最终表现是精确率0.99、召回率0.95、F1分数0.96、接近率0.95、传送门外观匹配率0.79。前三项都超过了0.9说明绝大多数该有的跳转都被正确生成且几乎没有多余的错误跳转。接近率同样接近0.95意味着生成的传送门中大约95%是玩家实际上能走到的。外观匹配率稍低是因为AI的外观判断标准比较严格比如指示牌这个传送门AI生成了一块普通的板子但判断模型认为板子上没有明显的指示功能证据所以判定不匹配——这属于物体模型库覆盖范围的局限而不是流水线本身的问题。值得一提的是研究团队发现测试案例的场景数量从一个增加到五个MAGIC的各项表现并未出现明显下滑。这说明在测试范围内流水线的质量不会随着项目规模增大而急剧恶化。不过研究团队也坦诚地指出由于测试范围仅到五个场景更大规模的外推还需要更多验证。---六、MAGIC目前还做不到什么研究团队对系统的局限性做了诚实的陈述这些边界同样值得了解。目前MAGIC只支持室内场景户外或大型开放世界不在它的能力范围之内。它只能在Unity引擎上运行其他引擎如Unreal Engine尚不支持。过场特效只有两种渐入渐出和光圈收缩如果游戏设计需要更丰富的过场动画还得另外开发。输入语言只支持英文。传送门的外观受限于物体模型库的覆盖范围库里没有的东西生成出来可能形似而神不似。家具摆放是尽力而为当重试预算耗尽时系统会返回当前连通率最高的方案所以少数情况下仍可能有极小区域的遮挡。在研究方法层面测试案例的标准答案是用程序脚本自动生成的而不是由人工设计师手动创建这意味着标准答案本身可能存在一定的人工设计偏差。每个案例只跑了一遍没有重复多次取平均也没有做统计显著性检验所以给出的数字是单次运行的点估计存在一定的随机波动。人工评审只参与了20个案例的对比验证两名评审员的样本量也偏小。---归根结底MAGIC做的这件事是把一个通常需要游戏开发团队花费大量时间手工维护的工作——设计多个室内场景并保证它们之间的门全部可以正常穿行——变成了一个任何人输入一句话就能启动的自动流程。从实际效果看100个测试案例中每一个都能生成可运行的项目超过95%的该有的传送门被正确生成且绝大多数传送门都没有被家具堵死玩家能够顺利走到。这对于一个完全自动化的系统来说已经是相当可靠的表现。当然目前的版本还有不少约束只在室内、只在Unity、只有英文、只有两种特效。如果你是一位独立游戏开发者这些限制可能会让你觉得离我能直接用还有点距离。但如果你只是想快速做个游戏原型或者想看看AI能不能帮你搭出一个可以走进去转一圈的三维草稿MAGIC已经能给出一个完整的、可以打开运行的答案。未来的可能方向研究团队提到了几个支持玩家主动触发传送的动作比如按键而不只是走到门口允许人工在某个中间阶段介入修改比如调整场景规格再让后面的步骤继续执行以及把整套流程推广到室外场景和其他游戏引擎。这些方向每一个都足以支撑一篇独立的论文足见这个领域还有相当大的探索空间。对AI辅助游戏开发感兴趣的读者可以通过arXiv编号2607.11594查阅完整论文也可以访问论文中提供的代码仓库直接跑起来试一试。---QAQ1MAGIC生成的游戏场景可以直接在Unity里打开玩吗A可以。MAGIC的最终输出就是一个完整的Unity项目文件用Unity打开后可以直接运行玩家操控摄像机在场景里走动走到传送门就会跳转到下一个场景不需要额外的手动配置。在100个测试案例中每一个都成功生成了可以运行的项目。Q2MAGIC用的洪水填充算法是怎么判断门有没有被堵住的A算法把整个场景转成一张细密的网格地图把家具占用的格子标成障碍其余的标成可走。然后从传送门的位置出发像倒水一样让标记向四周扩散只能流过可走的格子。扩散结束后如果扩散覆盖了所有可走格子说明门没有被堵死如果有死角扩散不到说明有障碍挡路系统就会重新调整家具摆放。Q3MAGIC的评估探员和人工检查相比准确性怎么样A研究团队用20个测试案例做了对比让人工评审员逐场景手动检查每扇门能否正常触发跳转然后和探员的结果做对比。各项指标的平均绝对差只有0.0299说明探员的判断和人类几乎一致同时每个场景只需约40秒远比人工高效。

相关新闻

东南大学、华东师范与港科大等追问:AI科学家真的准备好了吗?

东南大学、华东师范与港科大等追问:AI科学家真的准备好了吗?

这项由东南大学、华东师范大学与香港科技大学联合开展的研究,以预印本形式发表于2026年7月,论文编号为arXiv:2607.11079,有兴趣深入了解的读者可通过该编号查询完整原文。科学研究的核心,说白了就是"从数据里找答案"。一…

2026/7/24 23:19:16 阅读更多 →
港科大研发“图表怀疑论者“:让AI不再被骗人图表忽悠的新框架

港科大研发“图表怀疑论者“:让AI不再被骗人图表忽悠的新框架

这项由香港科技大学(HKUST)及香港科技大学广州分校联合开展的研究,于2026年7月发表在预印本平台arXiv上,论文编号为arXiv:2603.28583v2。感兴趣的读者可通过该编号查询完整原文。你有没有被这样一张图表骗过:折线图的走…

2026/7/24 23:19:16 阅读更多 →
Nintendo Switch终极破解指南:大气层系统Atmosphere完整教程

Nintendo Switch终极破解指南:大气层系统Atmosphere完整教程

Nintendo Switch终极破解指南:大气层系统Atmosphere完整教程 【免费下载链接】Atmosphere-stable 大气层整合包系统稳定版 项目地址: https://gitcode.com/gh_mirrors/at/Atmosphere-stable 想要完全解锁你的Nintendo Switch游戏主机吗?大气层系统…

2026/7/24 23:18:16 阅读更多 →

最新新闻

一张图看懂TOGAF元模型主要实体之间的关系

一张图看懂TOGAF元模型主要实体之间的关系

本文对TOGAF 元模型的主要实体元素之间的关系进行解读,并对元模型中提及的重要概念进行名词解释或者举例说明。为保证语言通俗易懂,用一家加工螺丝钉的生产企业“螺丝霸王”为例举例说明,以便降低理解难度。(图片来源:…

2026/7/24 23:25:19 阅读更多 →
Benchmark 与 GPT 5.6:大模型评测体系与 AI 工作方式的范式转移

Benchmark 与 GPT 5.6:大模型评测体系与 AI 工作方式的范式转移

文章目录一、Benchmark:大模型的"高考"1.1 什么是 Benchmark?1.2 为什么需要 Benchmark?1.3 核心 Benchmark 详解(1)MMLU —— 综合知识(2)GPQA Diamond —— 顶级推理(3&…

2026/7/24 23:25:19 阅读更多 →
中兴光猫终极解锁指南:3步免费开启工厂模式与Telnet权限

中兴光猫终极解锁指南:3步免费开启工厂模式与Telnet权限

中兴光猫终极解锁指南:3步免费开启工厂模式与Telnet权限 【免费下载链接】zteOnu A tool that can open ZTE onu device factory mode 项目地址: https://gitcode.com/gh_mirrors/zt/zteOnu 你是否曾经因为无法深度配置中兴光猫而感到困扰?想优化…

2026/7/24 23:25:19 阅读更多 →
深度 | AI军备竞赛「集体失血」:谷歌特斯拉同日现金流转负,$1.65万亿隐形债务浮出水面

深度 | AI军备竞赛「集体失血」:谷歌特斯拉同日现金流转负,$1.65万亿隐形债务浮出水面

核心观点:2026年7月23日,Google和Tesla同日报告自由现金流转负,揭开了全球AI基础设施军备竞赛的财务真相——四大云商年耗$6,950亿、表外隐藏$1.65万亿债务,而中国AI模型以1/36的价格正在从底层摧毁这一投资逻辑的定价基础。2026年…

2026/7/24 23:25:19 阅读更多 →
AI 芯片简报 07.21-07.24:NVIDIA Vera 亮剑、AMD 2nm GPU、Google 叛逃 CoWoS

AI 芯片简报 07.21-07.24:NVIDIA Vera 亮剑、AMD 2nm GPU、Google 叛逃 CoWoS

每期覆盖 3-4 天的 AI 芯片动态。个人视角,不追求面面俱到——只讲我认为重要的。周二、五更新。7 月 21 日到 24 日这四天,AI 芯片行业发生的事,放在任何一个正常的年份,都够写一个季度的头条。NVIDIA、AMD、Intel 三巨头在 72 小…

2026/7/24 23:25:19 阅读更多 →
Excel行高调整全攻略:从基础操作到批量处理技巧

Excel行高调整全攻略:从基础操作到批量处理技巧

这次我们来看一个Excel表格行高调整的实用技巧。很多人在处理Excel表格时都会遇到行高不一致的问题,手动逐行调整既费时又难以保证统一性。本文将介绍几种快速调整表格所有行高的方法,从基础操作到批量处理技巧,帮助你在几秒钟内完成整个表格…

2026/7/24 23:24:19 阅读更多 →

日新闻

用Highcharts 创建可拖拽三维散点立方体3D图表

用Highcharts 创建可拖拽三维散点立方体3D图表

该案例基于Highcharts scatter3d 三维散点图实现空间立方体散点可视化,核心特色:三维 X/Y/Z 三轴空间,所有散点分布在 0~10 立方体空间内;散点使用径向渐变实现立体 3D 圆球质感;支持鼠标 / 触屏拖拽画布,…

2026/7/24 0:00:29 阅读更多 →
AppCertDlls:进程创建路径上的 DLL 入口

AppCertDlls:进程创建路径上的 DLL 入口

AppCertDlls:进程创建路径上的 DLL 入口 AppCertDlls 位于 HKLM\System\CurrentControlSet\Control\Session Manager\AppCertDlls。本文的程序功能是只读列出这个键在 64 位和 32 位注册表视图中的全部值,并显示每条值的来源、名称、类型和可安全显示的数…

2026/7/24 0:00:29 阅读更多 →
我的编程之路:第一篇博客

我的编程之路:第一篇博客

大家好,我是一名编程初学者,同时这也是我编程学习之路上的第一篇博客。在这里,我想要向大家介绍我的一些想法和规划。a.自我介绍我是一个刚刚接触编程的新手,目前在学习c语言,我对编程世界充满了强烈的好奇。当然&…

2026/7/24 0:00:29 阅读更多 →

周新闻

Go语言静态资源打包方案对比与实践指南

Go语言静态资源打包方案对比与实践指南

1. 项目背景与核心需求在Go语言开发中,我们经常需要处理静态资源文件的打包问题。无论是Web应用的模板文件、前端资源,还是配置文件、证书等,都需要随程序一起分发。传统做法是将这些文件与编译后的二进制文件放在同一目录下,但这…

2026/7/24 3:59:20 阅读更多 →
Go语言实现高性能LDAP认证服务的架构与实践

Go语言实现高性能LDAP认证服务的架构与实践

1. 项目背景与核心价值LDAP(轻量级目录访问协议)作为企业级身份认证的黄金标准,已经服务了超过80%的财富500强公司。我在金融科技领域实施统一认证体系时,发现传统Java方案存在启动慢、内存占用高等痛点。而Go语言凭借其协程并发模…

2026/7/24 1:23:39 阅读更多 →
【AI面试官实战指南】:用ChatGPT模拟10类高频技术岗面试,3天提升应答精准度92%

【AI面试官实战指南】:用ChatGPT模拟10类高频技术岗面试,3天提升应答精准度92%

更多请点击: https://intelliparadigm.com 第一章:AI面试官实战指南的核心价值与适用场景 AI面试官并非替代人类HR的“黑箱工具”,而是以可解释、可审计、可迭代的方式,赋能招聘全链路的关键基础设施。其核心价值在于将主观经验沉…

2026/7/24 18:52:18 阅读更多 →

月新闻