蓝图与 C++ 协作

编程与脚本的划分

• 编程：定义系统的指令。例：载具系统的加速、转向等基础功能。
• 脚本：通过与现有系统交互来定义行为的指令。例：汽车、船等具体载具类型。

C++ 是编程语言，蓝图是脚本语言，但界线并不绝对：C++ 也能写行为，蓝图也能搭系统，最佳拆分取决于场景、项目与团队。

优势对比

性能：何时真正有影响

二者差异通常不显著，主要在以下场景才明显：

• 核心、底层基础设施；
• 大量使用 I/O 或计算的紧密循环；
• 处理大数据集的系统；
• 实例很多且依赖 Tick 的类；
• 能从多线程获益的场景。

官方建议：蓝图中用定时器或委托安排工作，代替 Tick（见 委托与 Tick 机制）；遇到性能问题先用 Unreal Insights 分析，优化最大瓶颈，再考虑把蓝图改写为 C++。

互相调用的方式

下图展示两个方向的调用通道。

flowchart LR
  subgraph CPP["C++ 基类"]
    P1["UPROPERTY(BlueprintReadWrite / ReadOnly)"]
    F1["UFUNCTION(BlueprintCallable / Pure)"]
    E1["UFUNCTION(BlueprintImplementableEvent)"]
    E2["UFUNCTION(BlueprintNativeEvent)<br/>+ _Implementation 默认实现"]
    L["UBlueprintFunctionLibrary 静态函数"]
  end
  subgraph BP["蓝图子类"]
    G["事件图 / 构造脚本"]
  end
  P1 -->|"读写变量"| G
  F1 -->|"调用节点"| G
  L -->|"全局节点"| G
  G -->|"必须实现"| E1
  G -->|"可选覆盖"| E2

官方示例：LightSwitchBoth

UCLASS()
class MYPROJECT_API ALightSwitchBoth : public AActor
{
    GENERATED_BODY()
public:
    UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category="Switch Components")
    class UPointLightComponent* PointLight1;

    UFUNCTION(BlueprintNativeEvent, Category="Switch Functions")
    void OnOverlapBegin(/* 重叠参数 */);
    void OnOverlapBegin_Implementation(/* 同上 */);   // C++ 默认：切换灯的可见性

    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Switch Variables")
    float DesiredIntensity;
};
// 构造函数中：Sphere1->OnComponentBeginOverlap.AddDynamic(this, &ALightSwitchBoth::OnOverlapBegin);

• 派生蓝图 LightSwitchBoth_BP 中，C++ 添加的组件显示为深蓝色图标（原生继承），蓝图新增的为浅蓝色。
• 蓝图的 OnOverlap 事件覆盖了 _Implementation，改为随机设置灯光颜色。
• 构造脚本 (Construction Script) 在 Actor 被移动或暴露的变量改变时重新执行，能即时预览；单靠 C++ 构造函数做不到。
• EditAnywhere 让每个实例可以有自己的 DesiredIntensity。
• Blueprintable 类说明符会被继承，AActor 已是 Blueprintable。

把蓝图转为 C++

用蓝图头文件视图 (Blueprint Header View) 生成包含变量与函数声明的 .h，函数实现需要手动迁移到 .cpp；引用大量需要更新时，用核心重定向 (Core Redirects) 自动重映射。

实际项目中的分工

• 程序员在 C++ 中写基类、核心系统、网络与数据结构，暴露少量清晰的属性、函数和事件。
• 策划/美术在蓝图子类中配置数值、资产引用，编写具体关卡和物件的行为。
• 官方的 Lyra 示例项目包含上述所有暴露方式的例子。

常见坑

• BlueprintPure 节点不缓存结果，每次连线取值都会重新执行，重计算会被悄悄放大。
• 蓝图里大量 Tick 是常见性能问题；用事件、定时器、委托替代。
• 首次在纯蓝图项目添加 C++ 类时，需关闭编辑器、在 IDE 中编译后重开；构建配置要与编辑器可执行文件一致。

GEA 的视角：蓝图在脚本谱系中的位置（卷 II 17.8.11、17.9）

GEA 第 17 章两次把 UE 蓝图当作例子：

• 数据通路通信系统：对象有输入/输出端口，策划用 GUI 连线，数据流（布尔、单位浮点、向量、颜色……）在端口间传递，类型不兼容时禁止连接或自动转换；GEA 说这就是"基于 GUI 的事件系统（如 UE 蓝图）的本质"。它是"简单可配置事件"与"完全自由的脚本语言"之间的中间路线，可以限定一组受控的原子操作并做错误检查。详见 事件与消息传递。
• GUI 编程的利弊：易用、学习曲线平缓、工具内帮助和大量错误检查；但开发调试维护成本高、额外复杂度可能带来恼人的 bug、策划受工具能力限制。文本脚本则更简单、可搜索替换、能用任何编辑器。这与本页"蓝图适合脚本、C++ 适合编程"的分工说法互补。
• UnrealScript 的退役：GEA 第 4 版说明 Epic 已不再支持 UnrealScript，开发者改用蓝图或 C++ 定制游戏行为；GEA 还说 UnrealScript 是他见过唯一能让脚本类无缝派生自原生类的脚本语言，而在 UE5 中这一能力由"以 C++ 类为基础构建蓝图类"承担。
• 解释执行的代价：GEA 指出虚拟机执行字节码通常比原生机器码慢得多，与本页"蓝图编译为字节码在虚拟机执行，有额外开销"一致。脚本架构的完整谱系见 游戏脚本系统。