👋 在项目中使用UE4有段时间了，这篇文章也算是对项目开发中我们如何在面对在UE4中到底是该使用蓝图还是C++的一个总结，希望给更多喜欢UE的朋友一个参考。

蓝图是什么？

先解释下什么是蓝图吧，惯性思维让我们开发者一听见蓝图就感觉很高大上，但在UE中的蓝图其实就是内置的可视化脚本编程语言，为了更多让更多的创作者能轻松上手UE，并快速开发出原型进行版本迭代而开发的一套可视化工具🧰，有点类似于编程语言中的脚本语言，和我们平时使用的Javaacript、Lua等有异曲同工之妙处，相比之下蓝图入手后让没有编程语言的基础的创作者以最小的代价就可以进行产品原型的创作。蓝图就是这么强大，但针对会高级语言的人来说其实缺点也是比较明显的；逻辑上太冗余、在项目模块逐渐增多的情况下，后期维护时回溯蓝图里面的逻辑也是比较复杂的。

什么时候用C++

相比蓝图C++的运行时性能是毋庸置疑的，但开发效率确实比较低，入门门槛是指数级别的难度不容易上手，有点编程基础的小伙伴相比Java等语言还是门槛高，对于这门C++上古时期的语言来说会挡住很多人在门外。还有就是开发效率过程中的编译速度这是个C++的通病，在开发编译调试很多时候能让我们“崩溃”，如果我们在开发中，直接去掉用UE引擎中的接口包括条件判断或for语句处理逻辑也相对的简单明了。

其实看很多人都说在项目中使用蓝图和C++的比例：比如8/2，5:5或100%的蓝图等，其实这样的统计并不重要‼️重要的是适合团队的才是更好的（就是要让更多的策划或产品参与进来写蓝图）技术人员只需要提供接口和进行逻辑检查确认。（适当的 “懒 ”才是最高的效率）

我们是如何做的平衡蓝图和C++的选择呢？ 我们目前的项目团队产品和策划都还处于对蓝图的理解初级阶段还需要时间的磨炼，所以我们的蓝图和逻辑Actor都是程序在使用，规范好各种蓝图的命名规则。

蓝图的使用过程尽量多对各逻辑进行函数的归纳和对单块逻辑进行合组注释，这样做能有效降低后期维护成本，加快项目迭代过程中逻辑的回溯及对游戏逻辑的理解也有很大的帮助，这里不管是蓝图中的逻辑或C++的逻辑都可以遵循这点。

让编程人员构建整体游戏的数据结构，提供游戏过程中会用到的接口并赋予接口正确的在蓝图中读写权限；

我们所有的需要复杂的运算逻辑全部放入C++中进行处理，其中包括一个以上的branch及for全部使用蓝图中调用C++接口来进行逻辑处理；

所有的蓝图Actor都是来自于我们C++中对应的Actor类，并实现通用接口逻辑提供蓝图中调用；

先暂且总结这么多吧，后边有新的心得在开一篇。

参考

可以参考官方文档：平衡蓝图和C++