香港中文大学出手:用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:07阅读更多 →
大模型记忆系统:从短期记忆到长期存储的技术演进

大模型记忆系统:从短期记忆到长期存储的技术演进

1. 大模型记忆能力概述:从"金鱼脑"到"最强大脑"的进化之路作为一名长期奋战在AI应用一线的开发者,我深刻体会过大模型"健忘"带来的困扰。去年在开发客服对话系统时,客户反复抱怨:"每次都要重新…

2026/7/24 23:17:07阅读更多 →
从「能纠错」到「算得起」:量子计算真正的考验才刚刚开始

从「能纠错」到「算得起」:量子计算真正的考验才刚刚开始

文丨恩里科 排版丨恩里科 行业动向:4200字丨12分钟阅读 内容提要 在此前的文章容错跨过门槛:微软与 Quantinuum 取得量子纠错重大进展(内附Nature下载)当中,我们讲述了纠错领域的突破:微软与 Quantinuum…

2026/7/24 23:17:07阅读更多 →
终极指南:3步轻松解锁网易云音乐NCM加密文件,实现音乐自由播放

终极指南:3步轻松解锁网易云音乐NCM加密文件,实现音乐自由播放

终极指南:3步轻松解锁网易云音乐NCM加密文件,实现音乐自由播放 【免费下载链接】ncmdumpGUI C#版本网易云音乐ncm文件格式转换,Windows图形界面版本 项目地址: https://gitcode.com/gh_mirrors/nc/ncmdumpGUI 还在为网易云音乐下载的…

2026/7/25 0:41:22阅读更多 →
猫抓视频嗅探工具:你的网页视频下载专家指南

猫抓视频嗅探工具:你的网页视频下载专家指南

猫抓视频嗅探工具:你的网页视频下载专家指南 【免费下载链接】cat-catch 猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension 项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch 在数字内容无处不在的今天,我们…

2026/7/25 0:41:22阅读更多 →
商家降本、骑手增收,诚心呈意为何是配送行业的破局答案?

商家降本、骑手增收,诚心呈意为何是配送行业的破局答案?

跑同城配送的骑手,大多有过这样的感受:路上同行的人越来越多,手里的配送单价却一降再降,想多赚点就得熬更长的时间、跑更远的路;做餐饮的商家也有苦难言:线上订单看着红火,扣完平台抽成和配送费…

2026/7/25 0:41:22阅读更多 →
Web 安全怎么学,OWASP Top 10 漏洞原理与 Burp Suite 实战详解

Web 安全怎么学,OWASP Top 10 漏洞原理与 Burp Suite 实战详解

从原理到实战:Web 核心漏洞深度剖析 很多初学者在掌握了 Linux 基础和网络协议后,面对 Web 渗透测试往往感到无从下手。要么过度依赖自动化工具“一键扫描”,要么死记硬背 Payload 却不懂其背后的运行逻辑。真正的进阶之路,在于深…

2026/7/25 0:41:22阅读更多 →
C++的并发与内存模型:从原子操作到内存屏障

C++的并发与内存模型:从原子操作到内存屏障

C11引入了标准化的内存模型和多线程支持。这不是简单地在语言层面加了几个库——它重新定义了C程序在并发环境下的行为基础。理解这个内存模型,是写出正确并发程序的前提。一、内存模型:为什么需要它多线程环境下,代码的执行顺序不是源代码顺…

2026/7/25 0:41:22阅读更多 →
D3KeyHelper暗黑3按键助手:免费开源的游戏自动化终极指南

D3KeyHelper暗黑3按键助手:免费开源的游戏自动化终极指南

D3KeyHelper暗黑3按键助手:免费开源的游戏自动化终极指南 【免费下载链接】D3keyHelper D3KeyHelper是一个有图形界面,可自定义配置的暗黑3鼠标宏工具。 项目地址: https://gitcode.com/gh_mirrors/d3/D3keyHelper 还在为暗黑破坏神3中繁琐的重复…

2026/7/25 0:39:22阅读更多 →
Go语言静态资源打包方案对比与实践指南

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

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

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

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

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

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

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

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

2026/7/24 0:58:53阅读更多 →
突破文档下载限制:kill-doc让你看到的都能保存

突破文档下载限制:kill-doc让你看到的都能保存

突破文档下载限制:kill-doc让你看到的都能保存 【免费下载链接】kill-doc 看到经常有小伙伴们需要下载一些免费文档,但是相关网站浏览体验不好各种广告,各种登录验证,需要很多步骤才能下载文档,该脚本就是为了解决您的…

2026/7/25 0:01:16阅读更多 →
C++ string类模拟实现:从深拷贝到内存管理的完整指南

C++ string类模拟实现:从深拷贝到内存管理的完整指南

1. 项目概述:为什么我们要“手撕”string类?在C的学习道路上,尤其是从C语言过渡到C的“初阶”阶段,string类绝对是一个绕不开的核心。标准库里的std::string用起来太方便了,、find、substr,几个操作符和函数…

2026/7/25 0:01:16阅读更多 →
三角洲寻宝鼠工具:高效文件搜索与资源管理实战指南

三角洲寻宝鼠工具:高效文件搜索与资源管理实战指南

1. 先搞清楚“三角洲寻宝鼠”到底是什么工具从名称来看,“三角洲寻宝鼠”更像是一个资源查找或文件检索类工具,而不是游戏或娱乐软件。这类工具的核心价值在于帮助用户快速定位特定资源,比如文档、图片、压缩包或特定格式的文件。如果你经常需…

2026/7/25 0:01:16阅读更多 →
YOLOv8推理性能优化:从1.2FPS到35FPS的全链路加速实践

YOLOv8推理性能优化:从1.2FPS到35FPS的全链路加速实践

如果你在部署 YOLOv8 时,发现推理速度只有可怜的 1-2 FPS,而别人的演示视频却能跑到 30 FPS 以上,那么问题很可能不在模型本身,而在于你的整个处理链路。很多开发者拿到一个训练好的 YOLOv8 模型后,会直接使用官方示例…

2026/7/24 23:01:03阅读更多 →
Coze与Dify对比指南:低代码AI应用开发从入门到实战

Coze与Dify对比指南:低代码AI应用开发从入门到实战

1. 从零到一:为什么你需要了解 Coze 和 Dify?如果你对 AI 应用开发感兴趣,但一看到“大模型”、“智能体”、“工作流”这些词就头疼,觉得门槛太高,那这篇文章就是为你准备的。很多开发者,包括我自己&#…

2026/7/24 19:00:40阅读更多 →
AI生图工具怎么选?2026年6月版实测对比

AI生图工具怎么选?2026年6月版实测对比

做自媒体的朋友应该都有体会:配图一直是个让人头疼的问题。2026年,AI生图工具已经非常成熟了,但工具太多反而不知道怎么选。以下是截至2026年6月我对主流AI生图工具的实测对比。Midjourney V8.1:速度之王2026年6月11日&#xff0c…

2026/7/24 19:00:40阅读更多 →