跨国深谈← 返回←下一代游戏引擎不会有使用手册

下一代游戏引擎不会有使用手册

关联

人物 Arturo Nunez

公司 Nereu · Unity

概念 资产标签系统 · 实体组件系统 · 智能体 · LLM · 细节层级 · 视觉模型 · 世界模型 · Claude Code

这一集要聊的是：为什么下一代游戏引擎不会有使用手册。说这话的人叫 Arturo，他在 Unity（知名游戏引擎公司）工作了将近 10 年，见过太多人做游戏时一遍又一遍地在同样的事情上挣扎——所以他自己做了一个叫 Nereu 的工具。

开场他先演示了它现在的样子：他对着助手说「我想添加一个机器人」，工具就从资产库里找出符合条件的机器人模型；再说「让它用 WASD 移动、加上动画」，角色就能动了；接着描述「加一些建筑」「下点雨」「加一个跟随角色的摄像机」——几分钟后，一个能玩的游戏场景就成了。全程没写一行代码，没导入一个模型，只用了「玩过游戏的人都懂」的语言来描述自己想要什么。

为什么做游戏这么难

用常规工具做到演示里那一步非常难。做游戏需要懂编程、3D 建模、渲染、音乐、动画等一大堆技能：要么有一个互相补足的大团队，要么每个人身兼多职——而说实话，很难找到一个人既擅长游戏设计、又擅长渲染、还擅长实时镜头构图。

而且技术上行还不够：游戏必须好玩，不好玩就没人玩。Arturo 认为乐趣应该既属于玩家、也属于开发者，但近年来行业越来越偏向「生产更多、卖更多」，而不是做游戏本身的手艺。他想让更多人不用沮丧、不用花两三年做出东西才发现卖不出去，就能享受做游戏的过程——对很多人来说，做游戏只是一种创意出口，就像玩乐高。

现在明明有强大的引擎（Unreal、Unity），也有强大的 LLM 和智能体，为什么依然难？他的判断是：我们只是在两个世界之间搭了一座桥，这并不最优——你仍然得用引擎的词汇、代码的词汇去提问，否则 LLM 就会失控乱来、一遍遍重复造轮子。比如「我想要一个跟随角色的镜头」，结果本质每次都一样，但 LLM 每次都从头造一遍。

资产标签系统（ATS）：把上下文从引擎翻转到游戏设计

他的解法是把这个理念翻转过来：默认上下文不该在游戏引擎上，而该在游戏设计上。在当前引擎里，想控制一个角色，你需要导入 mesh、配置渲染器、动画器、刚体、碰撞体、音源，再写移动逻辑和游戏规则——其中大部分是市面上每个游戏、每个角色都有的样板代码，但开发者还得去读懂那些组件和成百上千个滑块是干嘛的。

Nereu 的目标则是：一切都只是资产。一切都要渲染、大多数时候都有物理，而你只需要加标签来描述资产在游戏中的意图——「我要这个成为角色、能被动画化、能二段跳」「收集金币时增加分数」。这正是新手教程里那种语言：「按 A 跳跃，空中再按一次做二段跳」——他认为那就该是我们做游戏该用的语言。

这套东西叫 ATS（资产标签系统，Asset Tag System），源自游戏开发里的实体组件系统（Entity Component System，一种面向数据的设计：用组件描述对象，再由系统去查询并处理所有带某组标签的对象）——比如系统查询所有同时带 vehicle、player、drivable 标签的对象，让它们可以被驾驶。妙处在于可以复用：一栋建筑本来不动，但没什么能阻止你给它加上 vehicle 和 drivable 标签，于是你就有了一栋能开的车，可以放进马里奥赛车风格的游戏里。

AI 助手（叫 Bibi）的作用就是帮你摆脱卡壳：你问「怎么让车动起来」，它知道有哪些可用的工具和标签，直接应用到资产上。实现上，用户输入查询，系统用场景上下文加上额外信息（游戏里的资产类型、用户描述的想做的游戏类型）构建 prompt，然后智能体执行调用、增删标签。引擎里故意不内置脚本系统——虽然它就是跑在浏览器里的 JavaScript，想扩展的人可以扩展，但对大多数用户不该需要。

最难的部分是什么？Arturo 说，是把各种游戏分解成这些标签和系统——游戏类型太多、同一个游戏有很多种描述方式，还有「情绪氛围」这类东西：想做平台跳跃但有恐怖感？

那就牵扯到后期处理效果和光照。这些就是他们正在分解、用来驱动引擎的东西。

他怎么用 AI 造出这个引擎

这是他第一次以这样的速度构建这种规模的东西，基本每天和 AI 一起工作（用 Claude Code 或类似工具）：把脑子里的想法和 Claude 讨论；专注做光照时，就去找行业内专注光照的朋友提问，把答案带回来再构建工具；然后大胆做减法——「我觉得我们不需要这个设置、这个功能，我没见过多少用户用它」——以此简化引擎。构建的同时，他们把每个新工具的定义喂给助手，所以助手始终知道所有可用工具。产品现在处于封闭 Alpha 阶段，一批用户在用、给反馈，然后回到起点迭代。

一个值得分享的工程细节是上下文的组装。资产库有大约 6000-7000 个资产，不可能手动打标签——他只有名字和 3D 文件，所以对每个资产截图，用视觉模型来描述打标。

日常则主要靠 LLM。问题是整个场景喂给 LLM 上下文会爆炸：演示场景里约有 100 个资产，其中大部分是可以忽略的草。他们借用了一个游戏开发圈众所周知的思路——细节层级（Level of Details，游戏里离镜头近的物体用高精度模型渲染、太远的就用一个立方体代替，玩家察觉不到）：用户点击骑士时，它周围的东西优先级高，就把它们的标签和标签上的具体设置值完整喂给模型；稍远的东西只说「这个位置有个玩家」，不发送全部上下文；用户继续移动和修改时再动态更新。

一键生成不是目标；世界模型是另一种媒介

收尾时他明确了一个边界：他不想一键生成没人会玩的游戏，觉得那没有意义——行业里确实有那种需求，但 Nereu 的理念是让人们享受制作过程、把游戏分享给家人朋友，并在过程中学会游戏设计的语言（不一定是编程——有用户说因此理解了以前不懂的编程概念，但那不是最初目标）。

对于用世界模型（即时生成游戏画面的另一类技术路线）做游戏，他的判断是：那会是一种不同的媒介，即使我们也叫它电子游戏——如今游戏必须每秒渲染 60 帧，要用世界模型在 4K 分辨率下实时做到、还要模拟物理，他认为还很遥远。但他觉得正在发生的一切很令人兴奋。

最后他说，做这个工具本身非常有趣：想测试什么时，就拉进来一个宇航员和一只恐龙让它们到处走走——这像极了大约 20 年前把他带入游戏开发行业的那种乐趣。职业生涯里他曾越来越失望，觉得「这不再有趣了」，现在他又找回了乐趣，想分享给更多人。

本集带走

• 换掉提问的词汇：别用引擎和代码的词汇跟 LLM 对话（否则它反复造轮子），用玩游戏的人本来就会的语言描述意图——「能二段跳」「吃到金币加分」「镜头跟着角色」。
• 用标签替代样板配置：把每个资产只是当「资产」，用意图标签（player/vehicle/drivable/animated…）描述它，系统层负责查询和执行——标签可自由组合，随时能造出「能开的建筑」这种意外玩法。
• 上下文按距离分级：借鉴游戏里细节层级的思路，用户正在操作的对象给完整标签和设置值，远处对象只给一句话摘要，动态更新——避免整个场景撑爆 LLM 上下文。
• 视觉模型批量打标：几千个资产不用手动标注，截图喂给视觉模型生成描述即可。
• AI 时代的做减法：和 Claude 讨论方案、向领域专家要输入、构建后把工具定义同步给助手，同时果断砍掉没用户用的设置来简化引擎。

近年来,我觉得这变得更像是生产更多、试图卖得更多,而不是做游戏的手艺本身。
In recent years, I think it’s become more about producing more and trying to sell more rather than the craft of making games.
—— Arturo Nunez · [06:26]

之所以难,是因为我觉得我们只是在两个世界之间搭一座桥,而这并不是最优的,你仍然需要知道该用什么词汇去问,用引擎的词汇、用代码的词汇。
It’s hard because I think we’re just building a bridge between two worlds, and it’s not optimal, and you still need to know kind of like what to ask in the vocabulary of an engine, in the vocabulary of code.
—— Arturo Nunez · [07:04]

默认情况下,上下文是在游戏引擎上,而不是在游戏设计这部分,而我认为我们应该把这个理念翻转过来。
By default, the context is on the game engine rather than on the game design part, and I think we should flip that idea.
—— Arturo Nunez · [07:42]

我不想让我们去一键生成没人会玩的游戏,我觉得那没有意义。
I don’t want us to one-shot games that nobody is going to play, and I don’t see the point in that.
—— Arturo Nunez · [16:49]