前面的回答都是建立在蓝图逻辑的编写上，对于一些不会c 的个人开发者来说比较有用。

　　但是作为规范化的项目开发流程，在蓝图连线和节点封装的基础要求上，更加应该考虑什么逻辑写在c 里，什么逻辑写在蓝图里。

　　或者说，蓝图的使用力度是什么样的?

　　当然，这个问题是没有标准答案的。

　　从我个人角度出发，蓝图的使用上有几个原则：

　　1)把蓝图-当作-低性能脚本语言

　　我不是说蓝图的性能很差(此处不要抬杠)，只是在开发中评估蓝图使用性能的时候要默认是一个比c 差百倍的工具，来评估能不能写在蓝图里。

　　所以如果写一个功能有性能顾虑，那就直接c 。比如看到tick的逻辑或者高频率的timer，那么就不要再考虑蓝图实现了。

　　2)把蓝图作为功能向外界的窗口(面向策划快速原型，面向其他功能的快捷使用)

　　很多习惯于c 的程序会进入一个误区，就是我只管我c 功能写完，蓝图是个什么xx玩意儿(划掉)，其实这么做就完全利用不到蓝图带来的便利性了。

　　我们的c 类中是否需要把一些函数抛出给蓝图使用，是否可以让蓝图重载我们的一些函数，这些都是需要考虑到的点，然后完成快速的功能协作开发。

　　3)把蓝图作为灵活迭代的工具

　　我们在c 封装函数的时候应该尽可能考虑到后续版本迭代带来的修改可能，利用nativeevent或者implementationevent来将一些可扩展的功能抛出到蓝图中，这样一旦有需求修改，可以快速的在蓝图上实现一版体验效果，后续再考虑是否要移植回c 里，避免了一个功能细节反复修改带来的麻烦。

　　4)baac(blueprint as a config)(对就是我编的)把蓝图作为配置

　　ue4给了我们datatable来配置数据，但是蓝图是更为灵活的配置工具。

　　除了修改属性的默认值以外，通过继承可以实现可变化的配置，通过cdo(class defualt object)可以快速地在不实例化对象的时候就获取我们配置的默认值。而且蓝图还可以实现功能上的扩展，实在是比datatable这种方式的配置灵活太多。

　　弘成it教育致力于互联网it人才的培养，精心打造并推出零基础入门、高手进阶、推荐就业为一体的课程体系，全面提升学员的个人素质能力和团队协作能力。欢迎咨询!