现在就该做的 5 件事,让你的蓝图将来更好迁移

一、把逻辑从 Level Blueprint 搬进 Blueprint Class

怎么做:打开关卡蓝图,看看里面有多少条从 Event BeginPlay 拉出去的线。凡是「和这个关卡本身无关」的逻辑——计分、开门、刷怪、UI 显隐——都新建一个 Blueprint Class 装进去,关卡蓝图只留下「把这几个东西接起来」的最后几根线。理想状态是:关卡蓝图空得能一屏看完。

为什么将来好迁移:关卡蓝图是所有蓝图里最难搬的一种。它没有独立资产可以复用、它和关卡里的具体实例绑死、它的引用是「这一关的这个 Actor」。而 Blueprint Class 是一个独立、可复用、边界清楚的东西——它在 Verse 里的归宿也最清楚:一个 class,加上 Scene Graph 里由 entity 与 component 组成的实体。逻辑住在类里,迁移的单位就是类;逻辑住在关卡里,迁移的单位就是整个关卡。

今天就有的好处:关卡蓝图不能被复用、不好被别人 review、多人协作时是冲突重灾区。搬出来这一件事,你的下一个关卡就能直接受益。

二、用 Interface 解耦,而不是 Cast 到具体类

怎么做:每当你想写 Cast To BP_SomeSpecificThing 的时候,停一下,问自己:「我真正需要的是这个类,还是会做这件事的任何东西?」十有八九是后者。那就建一个 Blueprint Interface(比如 BPI_Interactable,里面一个 Interact 函数),让门、宝箱、开关都实现它,调用方只认接口不认类。

为什么将来好迁移:两个理由。第一,Cast 是一条硬引用:它把调用方和被调方焊在一起,迁移时两边必须一起动,一动就是一串。接口只是一份约定,两边可以分批迁。第二——也是更妙的一点——Blueprint Interface 在 Verse 里有几乎一一对应的东西:interface。你今天画的接口,将来基本可以照着译。

提前看一眼它译过去长什么样(现在看不懂完全没关系,这是第六章的内容,放这里只是让你安心):

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

# 这就是 BPI_Interactable:一份约定,没有实现
interactable := interface:
    Interact(Agent:agent):void

# 门实现这份约定 —— 相当于蓝图类的 Implemented Interfaces 里加一条
my_door := class(creative_device, interactable):
    Interact<override>(Agent:agent):void =
        Print("门开了")

今天就有的好处:少一堆 Cast,加载依赖链变短、编译变快、循环引用变少。这条建议在 UE6 出现之前就已经是所有 Unreal 性能指南的第一页。

三、把「数据」和「行为」分开

怎么做:把散落在蓝图里的常量掏出来——伤害值、冷却时间、价格、掉落表、文案。让它们住进 Data Asset 或 Data Table,蓝图里只留「拿到数据 → 按数据做事」的逻辑。判断标准很简单:如果策划改这个数字要来找你打开蓝图,那它就该搬出去。

为什么将来好迁移:迁移的是行为,不是数据。一个纯数据资产,不管底层框架怎么换,它的内容(一张表、一组数值)本身是稳定的,大不了重新导一次;而混在节点图里的魔法数字,会跟着节点图一起进那台转换机器,然后你得在生成出来的代码里一个个把它们认出来。分家之后,你要审读的行为逻辑量可能直接少一半。

今天就有的好处:数值调整不用编译、不用程序员参与、可以做成表格给策划。这条几乎是白赚。

四、别让事件图长成一面墙,拆成函数

怎么做:给自己定一条硬规矩:任何一段逻辑,在默认缩放下应该一屏看完。超了就折叠成函数(Collapse to Function),取一个动词开头的名字——OpenDoor、ApplyDamage、RefreshHUD。折叠成 Macro 或 Collapsed Graph 只是把面条藏起来,折叠成函数才是真的拆开。

为什么将来好迁移:这是五条里最直接的一条——函数在 Verse 里就是函数。一个有名字、有明确输入输出、一屏能看完的蓝图函数,几乎可以一比一地译成一个 Verse 函数;而一张连了两百个节点、执行线绕成毛线球的事件图,不管交给转换工具还是交给人,都会变成一场灾难。你现在每折叠出一个函数,就等于提前给未来切好了一块可以独立搬运的砖。

今天就有的好处:能取名字就能被搜索、被复用、被单独测试;新人接手时读的是一串动词,而不是一张地图。

五、给每个蓝图写一句话职责说明

怎么做:在每个蓝图类的 Class Settings 里填上 Description,或者在事件图左上角放一个注释框,写一句话:「本蓝图负责 ×××,不负责 ×××。」两个「负责」都要写,后半句往往比前半句值钱。三十秒的事。

为什么将来好迁移:回忆主课的结论——自动转换搬得动结构,搬不动设计意图。这句话反过来读就是行动指南:把设计意图从你脑子里搬到文件里,它就变成了结构。将来无论是你自己、同事,还是读你项目的 AI 助手,在面对一份机器生成的 Verse 代码时,这一句话就是判断「这段该保留、该重写、还是该直接删掉」的唯一依据。没有它,你只能靠考古。

还有一个具体到 Scene Graph 的理由:从「继承一棵 Actor 树」走向「给 entity 装 component」,最难的一步不是语法,而是把一个胖蓝图拆成几个各司其职的组件。而拆分的依据,恰恰就是「它负责什么、不负责什么」。你现在写下的每一句职责说明,都是将来那次拆分的分割线。

今天就有的好处:写不出这一句话,通常说明这个蓝图确实职责太杂了——这个练习本身就是一次免费的代码审查。

六、算一遍总账

这五条最值得说的一点是:它们不依赖任何尚未公布的信息。你不需要知道 UE6 什么时候发、转换工具能覆盖多少、可视化层长什么样——哪怕这些统统不发生,下面右边那一列的收益也照拿不误。

最后补一条不在表里的:每周挤出一点时间写 Verse。历史告诉我们(见本课的另一个拓展页),迁移最贵的从来不是工具,是「团队里没有一个人会新东西」。而你已经在这一页了,这件事其实已经开始了。

七、小测验

来源

本页的五条做法是通用工程建议,不依赖任何未公布的信息;其中涉及迁移方向的判断(Blueprint Class 与 Scene Graph、Blueprint Interface 与 Verse interface)依据 Epic 已公开的说明,见 The road to Unreal Engine 6(Epic 官方)↗。转换工具由 Epic 已承诺提供,但尚未发布,其覆盖度与形态尚未公布——本页任何关于「转换后要人工审读」的描述,依据的是历史经验(见本课第二个拓展页),不是对该工具的预告。