名词对照词典:蓝图的每个东西在 Verse 里叫什么

一、卡住你的不是语法,是名字

你已经知道怎么做一扇会开的门:变量面板里加一个 Boolean 叫 IsOpen,Event BeginPlay 里 Bind 一下按钮的事件,回调里接一个 Branch,走通的那条线上挂一个 Set 节点。这套流程你闭着眼睛都能连出来。

换到 Verse,你要做的还是这件事。真正卡住你的是另一个问题:Boolean 那个类型,在下拉菜单里选什么?翻遍文档也找不到 bool —— 因为它在 Verse 里叫 logic。你不是不会,你只是不知道它改了名。

这种「我知道我要什么,但不知道它在那边叫什么」的卡顿,会在你写 Verse 的头两周里反复发生几十次。每一次都不难,但每一次都要停下来查十分钟。这一课就是把这几十次一口气解决掉:六张对照表,五十多个词,一次查清。

每张表都是三列:蓝图里的叫法 / Verse 里的叫法 / 差异。前两列是查询用的,第三列才是真正值钱的部分 —— 很多词看着是一一对应,行为却不完全一样,踩过一次才知道疼。收藏这一页,以后写代码时开着它。

二、类型与容器

先从最常查的一组开始:你在变量面板的 Variable Type 下拉里能选到的那些东西。

这张表里最值得记住的三行是 Boolean、String 和 Set。前两个是「改了名 + 行为不同」,第三个是「干脆没有」。剩下的基本可以直译过去。

三、变量与数据

第二组是变量面板本身:新建、读、写、暴露、权限。这一组的对应关系最整齐,几乎每一行都能直译。

最后一行值得单独盯一眼:蓝图里没有「不可变变量」这个概念,所有变量都能接 Set。Verse 把默认值反了过来 —— 这不是刁难,是让别人打开你的代码时一眼就能看出哪些值是死的、哪些是活的。

四、流程

第三组是执行线上的节点。这一组差异最大,因为 Verse 把「失败」当成一等公民,很多蓝图里靠 Boolean 和 Is Valid 解决的问题,在 Verse 里换了一套机制。

还有一类蓝图里根本没有的东西:同时跑几条线。蓝图要做「一边倒计时一边等玩家踩板」得靠 Timeline 或 Tick 手工拼;Verse 把 sync(全员到齐)、race(谁先谁算)、rush(先到先得但都跑完)、branch(岔一条线出去)直接做进了语言里。这一组在第七章展开。

五、函数与事件

第四组是「代码怎么被组织、怎么被触发」。Event Dispatcher 那一行是很多人迁移时最先要用到的。

六、引擎对象:今天与 UE6 的方向

这一组必须先说清状态,否则查表会查出误会。

今天(2026 年 8 月):Verse 唯一能真正跑起来的地方是 UEFN,那里的「关卡里的东西」叫 creative_device。UE6 的方向:Epic 为 UE6 做了一套全新的玩法框架 Scene Graph,它从零基于 Verse 构建,用 entity(实体)装 component(组件),在 UEFN 中已经可以使用。同时 Epic 明确表示:Actor 与 Blueprint 在 UE6 Early Access(目标 2027 年底)及早期版本中完整支持,弃用要等 Scene Graph 足够成熟,时间未定;Epic 已承诺在弃用前提供转换工具,但尚未发布。

所以下表的 Verse 一列会给两个答案:今天怎么写、UE6 的方向是什么。

这一组是全站最容易被过期文章带偏的地方。判断一篇教程新不新,看它讲不讲 entity 与 component 就知道了。Scene Graph 的完整世界观在第八章,这里只需要记住:Actor 那一行不是简单改名,是换了一种组织方式。

七、没有对应物的:那些不属于 Verse 的系统

词典查到最后一定会遇到查不到的词。查不到有两种:一种是「Verse 还没做」,另一种是「这压根不是 Verse 要管的事」。下面这五个属于第二种 —— 它们是另外的系统,不在 Verse 要替代的范围内,以后也不会有一条「Verse 里怎么写 Timeline」的答案。

看清这条边界,能省掉大量焦虑。「蓝图作者的技能会不会作废」这个问题,在这张表面前有一半答案是现成的:你在材质、动画、特效、序列上积累的一切,和 Verse 完全无关,也就完全不受影响。Verse 要替代的只是「游戏逻辑」那一块 —— 而那正是这本词典前六张表覆盖的范围。

八、把词典用起来:一段代码里的每个词

光看表记不住。下面这台设备就是开头那扇门,十九行,把上面查到的词几乎全用上了。点「运行下一步」,每一步都会告诉你「这一行在蓝图里叫什么」。

using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }

door_device := class(creative_device):

    @editable
    OpenButton:button_device = button_device{}

    var IsOpen:logic = false

    OnBegin<override>()<suspends>:void =
        OpenButton.InteractedWithEvent.Subscribe(OnPressed)

    OnPressed(Agent:agent):void =
        if (IsOpen?):
            Print("门已经是开的")
        else:
            set IsOpen = true
            Print("门开了")

回头数一数:class、@editable、对象引用、var、logic、OnBegin、Subscribe、回调方法、if、?、set、Print —— 十二个词,全部能在前面的表里查到。这就是这本词典的用法:遇到不认识的,回去查那一行的第三列。

九、三个陷阱:同名不同物

查表最危险的不是查不到,是查到了一个长得一样的词,但它不是那个意思。三个必须提前知道的陷阱:

陷阱一:Verse 的布尔不叫 bool,而且不能直接当条件。它叫 logic,只有 true 和 false 两个值 —— 到这里都和 Boolean 一样。但 if 不收它:Verse 的 if 问的是「这一步走不走得通」,不是「这个值是不是真」。所以要在后面加一个问号:if (IsOpen?)。少写这个问号是新手第一天最常见的报错,而报错信息不会告诉你「你少了个问号」。

陷阱二:Verse 的 = 是比较,不是赋值。蓝图作者不容易踩这个坑(蓝图里没有等号可写),但只要你看过任何一门其它语言的代码,手就会自己敲出 Score = 100。在 Verse 里这行的意思是「问一句:Score 等于 100 吗?」—— 而且 Verse 根本没有 ==。三个符号必须分清::= 是第一次声明,set … = 是改值(对应 Set 节点),单独的 = 是提问。以后编译报错里蹦出「failure context」,先回头看是不是漏了 set。

陷阱三:Scene Graph 的 component 与蓝图的 Actor Component 名字一样,模型不一样。两边都叫「组件」,都是「挂在某个东西上的一块功能」。但蓝图的世界里,主角是 Actor:它自己是一个可以被派生的类,自己也能写一堆逻辑,组件只是它的配件。Scene Graph 的世界里,entity 几乎是个空壳,所有数据和行为都住在组件里,「这个东西是什么」由「它装了哪些组件」决定,而不是由「它继承自哪个类」决定。同一个词,一边是配件,一边是全部 —— 这个差别大到值得单开一页,见文末拓展。

十、命名风格:大小写也要翻译

还有一层对照容易被忽略:名字本身的写法。UE 有一套前缀体系(BP_、S_、E_),Verse 没有前缀,但它对大小写有明确分工。

一句话记法:类型小写带下划线,其余首字母大写。看到 my_door 就知道那是一个类型,看到 MyDoor 就知道那是一个值或函数 —— 这条规则让 Verse 代码不用看上下文就能读懂一半。完整的改名对照与练习在拓展页 x3。

蓝图对照

整整一课都是对照表,这一节讲的是「怎么查」。一个词查下去,只会落到三种结果之一:直译(换个名字照抄)、近似(概念在,写法和边界都不同)、无对应(它属于另一个系统)。判断落在哪一类,比记住译名更重要。

为什么会有「近似」这一类?因为 Verse 不是把蓝图节点一个个翻译成文字,它是另一套设计:失败被做成了控制流、不可变被做成了默认、并发被写进了语言。凡是碰到这三件事的词,对照关系就一定不是一对一的。

查表的正确姿势因此是三步:一,先看第一列找到你要的东西;二,看第二列拿到写法;三,一定要读第三列。跳过第三列,你会写出「能编译但行为不对」的代码 —— 那比编译不过难查得多。

关卡挑战

词典翻完了,来三道查表题。答对拿星星 ★,答错可以一直重试,零惩罚。

拓展阅读