从一个常见误解谈起

带过不少新人之后，我发现一个反复出现的判断："蓝图是给不会写代码的人用的，C++ 才是真正的开发"。这句话对了一半，但它的潜台词——蓝图是"低配版代码"——几乎是错的。

蓝图（Blueprint）在 UE 里的定位从来不是"C++ 的简化替代品"，而是一种面向不同读者、不同生命周期的表达方式。同样一个"角色受击后播放动画并扣血"的需求：

  • 程序员用 C++ 写，看到的是 UAnimMontage、PlayMontage 的 API 签名、属性同步的细节；
  • 策划用蓝图连，看到的是"受击事件 → 播放蒙太奇 → 扣血"这条可视化的业务流。

两者的差别不在"谁更高级"，而在谁更容易在项目的不同阶段被修改、被审查、被交接。蓝图最大的优势是可视化审查：连招表里多加一个判定帧，策划自己就能在事件图表里拖一个节点上去，截图发群里就能评审；同样的事情如果藏在 C++ 里，就需要程序员介入、编译、重启编辑器。

一个真实场景

我们做过一个项目，角色技能有 300 多个。最初所有技能逻辑都写在 C++ 的 UAbility 子类里，策划每次想调整一个技能的伤害公式或特效时机，都要排队等程序排期。后来把"数值配置 + 表现编排"上移到蓝图（能力本身仍由 C++ 驱动），策划自己就能调，程序只负责维护底层框架。迭代周期从"两天"降到"二十分钟"。

这个例子不是说明蓝图比 C++ 好，而是说明：把变化频繁的东西放在容易修改的那一层，才是混合开发的核心思想。

什么时候纯蓝图就够了

了解分工之前，先承认蓝图的适用面其实很宽：

场景 是否适合纯蓝图
原型验证、GameJam 非常适合，编译快、改起来直观
UI 的布局与动画（UMG） 适合， UI 本身就是所见即所得的领域
简单的小游戏、系统演示 适合，维护成本低
关卡内的一次性逻辑、触发器 适合
高频执行的核心逻辑（每帧、每个粒子） 不适合
需要复杂数据结构/算法的地方 不适合
需要访问引擎底层 API 的地方 看情况，很多 API 蓝图也能用

一个经验法则：如果一段逻辑一年都不会改几次，用 C++；如果它一个月要改几次，考虑蓝图或数据驱动。

什么时候必须上 C++

反过来，有些场景 C++ 是唯一合理的选择：

  1. 性能敏感路径。每帧执行成百上千次的逻辑——例如人群模拟、大量 Projectile 的移动计算、复杂的空间查询。蓝图虚拟机（Blueprint VM）的执行速度约为 C++ 的 1/10 到 1/100，节点连线本身还有额外开销。
  2. 引擎没有暴露的 API。蓝图只能调用被 BlueprintCallable 标记的函数，大量引擎内部功能（例如 UObjectHierarchy 的某些操作、渲染命令、底层序列化）蓝图的触手够不到。
  3. 需要精确控制内存与生命周期的系统。例如对象池、自定义内存分配、延迟销毁策略。
  4. 第三方库集成。接入一个 C++ 库（如 Steamworks、 physically-based 库）必须用 C++ 写胶水层。
  5. 大型项目的编译期保障。C++ 有编译器帮你查类型错误；蓝图只有运行时才暴露问题。一个 50 人的项目里，"编译能过"是一种重要的纪律。

本章小结

  • 蓝图与 C++ 不是竞争关系，而是面向不同读者、不同修改频率的两层表达。
  • 蓝图强在可视化评审、快速迭代、非程序员的参与；C++ 强在性能、能力覆盖面、编译期检查。
  • 分工的本质是：把变化频繁的东西放在容易修改的那一层。

下一页我们从执行模型的角度，把"蓝图比 C++ 慢"这件事讲具体——不说"慢 10 倍"这种笼统话，而是看开销到底花在哪。