【UE】Blueprints vs. C++: How They Fit Together and Why You Should Use Both 课程笔记

本文为：在游戏开发中如何平衡蓝图和C++的课程笔记

原课程讲得非常好，深入浅出，还涉及很多开发的小技巧。强烈推荐！

Blueprints VS. C++ 相同点

都能够拿来实现gameplay逻辑。

如下两个例子，是蓝图和cpp实现同一段逻辑的例子：

其实可以看出其实现方式大同小异

Blueprints VS. C++ 不同特点

C++

1. 使用场景广：为编辑器添加新的模式、开发独立工具、接入外部库、添加自定义渲染代码等
2. 效率高：使用更少的CPU指令。不需要额外的栈操作和函数调用
3. 解耦方便：通过cpp的模块限制，可以将功能相对独立的部分封在一个模块中，并能从语法上约束模块之间只能单向引用
4. 不可直接观察到如mesh的位置和效果
5. 逻辑错误可能引起严重的crash
6. 支持外部库的导入
7. 差异比较和版本合并较容易：容易进行diff和merge

蓝图

1. 使用场景单一：本身就是为了Gameplay设计的，所以也只适用于写gameplay逻辑
2. 效率低：消耗更多的CPU指令。相对于C++，执行蓝图逻辑在调用原生函数之前需要从栈中取参数，调用之后需要将返回结果存入脚本虚拟机的指定位置。此外为了实现一个功能还可能多次进行栈访问，而cpp中直接使用内联一次完成。
3. 结构相对随意，不支持模块划分。
4. 可视化：可以在视口处直接看到视觉设计效果
5. 不容易引起严重的crash
6. 无法自动merge。只能对本地和远端版本进行diff，无法diff历史版本

使用建议

效率

通过下面的调用图可以看出，蓝图和C++底层调用的原生函数其实是同一个（UKismetMathlibrary;:MakeVector()）但蓝图的版本需要做一些栈操作从脚本虚拟机进行数据的传递。

虽然蓝图的效率相对较低，但除非成百上千个actor在跑这段蓝图逻辑，其开销的增大在CPU预算占比中并不算大。此外也可通过启用蓝图原生化功能，将蓝图直接编译成cpp，来消弭这个效率差。（PS：但这种方式会在项目构建的过程添加一些步骤和不稳定的复杂性

所以到底是否要因为效率修改蓝图逻辑到cpp、要修改哪些地方，也取决于具体的情况。只有在修改尽可能少的内容的前提下对系统效率提升尽可能大，才有修改的必要。

这边可以借助UEprofiler来量化寻找当前性能瓶颈

此外，在涉及到Low-Level的底层系统、大量循环运算、大量数据操作、处理大量actor的逻辑建议放在cpp。

架构设计

由于本身语法支持，cpp能够更好地进行架构设计和系统的解耦。而蓝图是无法进行模块划分的。

所以在进行核心模块架构设计的时候，推荐使用cpp

视觉设计

对于High-Level的装饰性细节，蓝图的可视化比C++要更加合适

如：时间轴的设计、animation、mesh、material parameter、particle effect、sound具体使用哪个资产及其位置调整推荐在蓝图中实现

如果逻辑上需要cpp动态控制mesh的碰撞等，可以在cpp中定义这个mesh。但若mesh只用于展示，直接在蓝图中定义即可