UE引擎C++编程学习

  大家好，我是阿赵。
  之前我写了一些关于UE各项功能的介绍，包括了各种基础引擎用法和各种美术资源的使用。接下来按道理应该是开始介绍蓝图怎样使用才对。
  蓝图的确是UE引擎的一个比较有意思的东西，他可以不需要编写代码而达到了编写功能的目的。作为一个程序员，我非常努力的去尝试适应蓝图这种开发方式，也学了不少用法了。接下来我想说一下接下来为什么不是继续学习蓝图的用法，而是转为开始介绍UE的C++编程。
  首先，蓝图的确是可以做到大部分的功能，但我个人感觉，编写蓝图的过程耗时比写代码要多很多。如果我们写代码，在了解了API接口的用法，就可以很有目的性的去编写自己需要的功能。而大部分的API，在自己没有接触到的时候，是完全不需要去了解用法的。但蓝图不一样，蓝图功能里面有很多重复名字或者名字相近的节点，经常会遇到需要一个功能，但不知道实际需要哪个节点，找来找去的情况。而且有一点非常难受的是，一些很明确有C++调用方法的解决方案，但同样的API名称或者函数名称，就是找不到对应的蓝图节点来使用。
  对比起代码，蓝图的可阅读性其实是比较差的，一个不是很复杂的功能，往外需要连接很多个节点。虽然可以用备注模块来整理，但对于程序代码来说，蓝图的可阅读性真的并不是很高。
  然后，一些功能在现有的节点没有支持的情况下，还是需要用C++来编写。从灵活性来说，蓝图还是比较僵硬，不如C++编写那么随心所欲。然后蓝图的运行效率也没有C++那么高。
  当然，蓝图对比起C++也并不是一无是处的，优点也还是很多。
  比如，蓝图作为一种资源，它是可以热更新的，而C++是需要编译的。然后，C++编译得很慢，蓝图编译得很快。最后，蓝图可以作为和资源之间的一种纽带作用，可以在资源端实现一定的功能。这些都是蓝图比C++要方便的地方。
  所以，我个人对于蓝图和C++之前的关系，是这样看的：应该两者结合着使用，而不要为了完全不需要写代码这种奇怪的目的而痴迷于蓝图，也不能用纯粹程序员的眼光去苛求蓝图，想抛弃蓝图完全用C++来编写。
  对于游戏的架构、规则、业务逻辑，我觉得还是用C++或者其他的脚本语言实现，这样方便功能的维护和功能的扩展。然后蓝图也是必不可少的，比如一些和资源相关的地方，如动画蓝图等，还是很有用的，可以实现一些所见即所得的效果，并且带有一定的逻辑性在里面。
  基于这样的原因，所以我觉得蓝图可以作为引擎功能补充，而在使用各种引擎和资源相关的功能制作时，一边学习蓝图怎样使用。而UE的C++编程，还是不能绕开的。
  不过，由于UE的C++编程有很多并不是标准的C++，有很多UE自己魔改的地方，所以在使用UE的C++编程之前，有必要先熟悉一下它的用法。
  接下来会写几篇关于UE的C++编程的基础学习笔记，来记录一下这个学习的过程。