虚幻4随笔5 使用中的一些发现

行文匆匆，有些不太明白的地方评论里有补充，如今这里抱歉了！

 

半年多没有维护博客了，一方面是媳妇怀孕，另外一方面是公司年中有一个版本……

最近闲暇时间一直在研究虚幻，目前铺开了大概六七个原型在作，作的过程当中学到了很多东西，有一些新的想法。

原本这些都是准备展开来讲的，可是如今看来，每一个话题展开都是须要大把的精力，因此仍是先写到这里。有些已经有一些结论，有些尚未展开研究，就当是挖个坑吧，在后面几个月陆续填。

目前博主所用的版本是4.4，有些结论未必在将来还继续有效，若是发现有变化，后面会单起博客说明的。

 

总论：

仍在发展中，若是是准备用来作短时间商业项目的，请合理评估风险。用来进行长期商业项目、或者以为目前的功能已经可用、或者以研究为目的的，能够考虑介入。

优势是开发架构和框架体系成熟，国内策划不作脚本不作原型的开发模式可能确实相对不易适应。说程序用BP不习惯的恭喜您说出了一句正确的使人发指的废话，BP是设计给策划和关卡设计师用的，不是给你程序员用的——话说回来，也就在中国须要去把策划的想法翻译成代码的程（Fan一声）序（Yi四声）员（Gong一声）。

再次重申，若是您但愿什么事儿都是程序给吃下来，或者您的项目被迫处于这种态势，而不是由策划负责脚本和内容的制做，那么请出门左转，找CE、Unity（大雾）或者其它引擎，虚幻这种跟欧美式开发方式深度绑定的引擎绝对不适合您。相信我，您只是在给本身找麻烦，而后回过头来大骂这是一个垃圾引擎——其实只是您项目的开发模式不是原型开发模式，仅此而已。

没有程序基础的，看几个例子应该也能够本身用BP动手作点原型了，我如今基本主要游戏逻辑都用BP作，C++给BP写节点和第三方库的整合插件。BP用熟悉了，比手写代码的开发效率高多了（编译和部署时间、调试更直观方便、并且自己拖图的效率就不比手写差太远，有些状况下反而比手写高）。

此外开放代码，比较深坑的地方能够本身修改，也能够随意整合各类C++库进来，许多细节的实现比较有参考意义，好比WeakPtr之类的。论坛里有许多C++库的整合项目的通知，能够随时关注。

缺点是上手须要必定成本，此外，平台上不支持PSV、PS三、Xbox360这些平台，手机平台不彻底支持，但愿全机种支持的要注意，目前只能考虑Unity或者MonoGame。

升级快一方面也是一种缺点，旧版本还在玩得不亦乐乎，新版本又添了一堆新东西，这不，博主还在头疼于本身扩展的自细分地表渲染插件在4.4下表现超级糟糕的问题，4.5出来直接这个问题没有了……没~有~了~，我那废寝忘食地搞了一个周末是图个啥……图~个~啥~？！……因此，换句话说，专业的事情，交给专业的团队去就行了。从新发明轮子这种事儿，十年前是时尚，十年后就是愚蠢了。

 

工程部分：

Module不能出现重名。

Build.cs和Build类名必须一致。

能够建立独立的Win32工程了，虚幻3是独立Exe，若是想用到虚幻的功能，要么是须要把虚幻按照dll模式编译加载，要么是整合在整个Launcher里，虚幻4能够建立独立的Win32工程，工程里能够只用到虚幻的某些个子集。具体可参考引擎Solution里的那些Win32工程，此外，早期版Win32的工程设置和后期版的Win32工程设置不彻底同样。可根据本身的须要选择最合适的模式。

多个项目间共享的功能，最好创建plugin工程。也能够修改UBT，添加本身的文件夹。

目前没有找到能在独立路径下创建plugin的途径，彷佛只能放到项目的Plugins文件夹里或者引擎Source下的Plugins文件夹里。

发布Plugin给发布版用，4.3彷佛是须要先找到发布版的Version.h文件，用这个文件覆盖对应Release版本Git库中的对应文件，而后再编译和发布Release。

全部虚幻的Plugin是有加载顺序的，有依赖关系的插件要注意，能够经过设定Plugin的加载阶段和Dependency来解决这个问题。

一个工程（Plugin或者游戏工程）里能够包括多个模块（Module），注意最好把核心部分和编辑器部分分开，不然发布游戏时发现依赖了一堆不须要的库，太浪费了。能够理解Plugin和工程是一个打包单元，但Module是一个组织单元。

 

Object Core

反射实现很经典，不必定优美，可是很实用。博主以前试图实现过一个C++版的反射，template绝对用得比它好（从boost mpl继承过来的），就是由于缺了它那个分析代码获得Meta数据的东西，致使维护Meta起来太复杂了……再次说明牛逼的技术不是在那里玩技术玩语法，而是在玩工做流……

类和模块更名了，致使以前作的资源失效？Config文件中的redirector能够帮助你。

但不是万能的，BP重命名要当心，彷佛BP类名改过来了，可是里面的内容没有改过来……

资源更换文件夹后，本地仍然留有一个1k左右的"尾巴"？这也是redirector的"功劳"。请使用fix up清理。

虚幻的各个Ptr的实现很精彩。RefCount对象可走SharedPtr，此外还有WeakPtr等。

官方推荐琐碎而单位时间比较小的异步功能，能够考虑TaskGraph。时间较长的异步功能能够本身写Runnable。TaskGraph还没太搞明白怎么回事。

 

Actor - Component

Movement拆出去了，UE3的Movement是整合在Actor体系内的，从新实现不一样的Movement会比较费劲。如今好了，从新作一新的Movement就好，还能够在不一样的工程之间重用。

Component具备父子关系了！不只仅是SkeletalMesh对其它Component的父子关系，其它全部的Component都有父子关系了。

Actor的Tick貌似如今是多线程了，具体尚未跟。

 

Player – Controller

输入如今多了一个InputComponent，输入消息由Controller截获后，有可能会先发给激活的Pawn的InputComponent和其它InputComponent。能够运行时动态切换输入所操控的对象。UE3只能由PlayerController发布全部的指令消息。

Component挂接，UE3的Attach/Detach已经更名为Register/Unregister，在Register以前，须要先把root设置好。与UE3稍微有点不太同样的是，Actor没有显式Register接口（FinishAndRegister作了一些附加的逻辑，调用前须要先评估是否是本身须要的），Register All什么的在Component数量多的时候很是昂贵。目前对部分Component的Register操做，经实验是可使用的。

 

渲染核心

Renderer如今有两个：ForwardShadingRenderer和DeferredShadingRenderer，4.5的变化还未跟踪。

默认是不开远裁剪面的，若有需求得本身主动在View里面设置远裁剪面。

虽然多线程的调用型改了，但主体流程与UE3的渲染线程模型基本没有变化，UE3的全部渲染扩展方式，仍然基本可用，主要须要注意的是对其余设备的向下兼容性（主要关注Shader里的那些宏便可）。

 

Blueprint

目前主要用来开发原型，几个版本的细节修改仍是挺多的。

总而言之，首先须要提醒的是，用BP作项目，目前必定要记得多备份，最好本身架SVN服务器，改一点测一下就上传一次，特别是跟接口和更名相关的场合。博主为此浪费了两天左右的时间。

目前Blueprint建立的Actor基类，其基类中指定的Component是没法被子类修改的，并且其属性没法直接做为Actor的参数来修改。解决方法是在Actor中增长对应属性，并在Construct图中，修正Actor的对应属性。

不带函数返回值的BP函数，重载时须要在Event Graph里进行操做。带函数返回值的BP函数，则是右键重载。修改函数原型时，要注意有可能会发生修改前是个右键函数重载，修改后是个Event图重载。

修改与BP合做的Interface调用型的时候，BP的重载实现有可能会发生找不到或是其余状况，要当心，改以前记得备份。

全局方法和静态方法怎么办？能够作到BPFunctionLibrary里。

读表虽然有DataTable什么的支持，但须要代码介入，感受不是很舒服，推荐本身整合读表、读文件功能到BP中，一劳永逸，代码能够参考它Json解析和Csv解析部分。

 

UI

相似WPF，熟悉WPF的人应该很是容易上手，数据绑定什么的基本都是WPF那套概念，对我这种WPF的铁杆支持者简直是如沐甘露。数据绑定也是那种上手很困难，但一旦上手就以为其它全部UI系统都好Low啊这样的东西……固然，这玩意儿对性能的负面影响也是客观存在的。必定程度下，性能跟系统的扩展和方便程度成反比，永远不要想着鱼与熊掌都能兼得，要能的话，早有人作出来了。

并不是惟一选择，Coherent UI什么的也有插件提供了，并且Coherent也支持Unity和CE3，商业项目能够考虑。