行文匆匆，有些不太明确的地方评论里有补充，如今这里抱歉了！
半年多没有维护博客了，一方面是媳妇怀孕，还有一方面是公司年中有一个版本号……
近期闲暇时间一直在研究虚幻，眼下铺开了大概六七个原型在做，做的过程中学到了不少东西，有一些新的想法。
本来这些都是准备展开来说的，可是如今看来，每一个话题展开都是须要大把的精力，所以还是先写到这里。有些已经有一些结论，有些还没有展开研究，就当是挖个坑吧，在后面几个月陆续填。
眼下博主所用的版本号是4.4，有些结论未必在未来还继续有效，假设发现有变化，后面会单起博客说明的。
总论：
仍在发展中，假设是准备用来做短期商业项目的，请合理评估风险。用来进行长期商业项目、或者认为眼下的功能已经可用、或者以研究为目的的，能够考虑介入。
长处是开发架构和框架体系成熟，国内策划不做脚本不做原型的开发模式可能确实相对不易适应。说程序用BP不习惯的恭喜您说出了一句正确的令人发指的废话，BP是设计给策划和关卡设计师用的，不是给你程序猿用的——话说回来，也就在中国须要去把策划的想法翻译成代码的程（Fan一声）序（Yi四声）员（Gong一声）。
再次重申，假设您希望什么事儿都是程序给吃下来，或者您的项目被迫处于这样的态势，而不是由策划负责脚本和内容的制作，那么请出门左转，找CE、Unity（大雾）或者其他引擎，虚幻这样的跟欧美式开发方式深度绑定的引擎绝对不适合您。相信我，您仅仅是在给自己找麻烦，然后回过头来大骂这是一个垃圾引擎——事实上仅仅是您项目的开发模式不是原型开发模式，仅此而已。
没有程序基础的，看几个样例应该也能够自己用BP动手做点原型了，我如今基本主要游戏逻辑都用BP做，C++给BP写节点和第三方库的整合插件。BP用熟悉了，比手写代码的开发效率高多了（编译和部署时间、调试更直观方便、并且本身拖图的效率就不比手写差太远，有些情况下反而比手写高）。
此外开放代码，比較深坑的地方能够自己改动，也能够任意整合各种C++库进来，很多细节的实现比較有參考意义，比方WeakPtr之类的。论坛里有很多C++库的整合项目的通知，能够随时关注。
缺点是上手须要一定成本，此外，平台上不支持PSV、PS3、Xbox360这些平台，手机平台不全然支持，希望全机种支持的要注意，眼下仅仅能考虑Unity或者MonoGame。
升级快一方面也是一种缺点，旧版本号还在玩得不亦乐乎，新版本号又添了一堆新东西，这不，博主还在头疼于自己扩展的自细分地表渲染插件在4.4下表现超级糟糕的问题，4.5出来直接这个问题没有了……没~有~了~，我那废寝忘食地搞了一个周末是图个啥……图~个~啥~？！……所以，换句话说，专业的事情，交给专业的团队去就好了。又一次发明轮子这样的事儿，十年前是时尚，十年后就是愚蠢了。
project部分：
Module不能出现重名。
Build.cs和Build类名必须一致。
能够创建独立的Win32project了，虚幻3是独立Exe，假设想用到虚幻的功能，要么是须要把虚幻依照dll模式编译载入，要么是整合在整个Launcher里，虚幻4能够创建独立的Win32project，project里能够仅仅用到虚幻的某些个子集。详细可參考引擎Solution里的那些Win32project，此外，早期版Win32的project设置和后期版的Win32project设置不全然一样。可依据自己的须要选择最合适的模式。
多个项目间共享的功能，最好建立pluginproject。也能够改动UBT，加入自己的目录。
眼下没有找到能在独立路径下建立plugin的途径，似乎仅仅能放到项目的Plugins目录里或者引擎Source下的Plugins目录里。
公布Plugin给公布版用，4.3似乎是须要先找到公布版的Version.h文件，用这个文件覆盖相应Release版本号Git库中的相应文件，然后再编译和公布Release。
全部虚幻的Plugin是有载入顺序的，有依赖关系的插件要注意，能够通过设定Plugin的载入阶段和Dependency来解决问题。
一个project（Plugin或者游戏project）里能够包含多个模块（Module），注意最好把核心部分和编辑器部分分开，否则公布游戏时发现依赖了一堆不须要的库，太浪费了。能够理解Plugin和project是一个打包单元，但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就好，还能够在不同的project之间重用。
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做项目，眼下一定要记得多备份，最好自己架SVNserver，改一点測一下就上传一次，特别是跟接口和改名相关的场合。博主为此浪费了两天左右的时间。
眼下Blueprint创建的Actor基类，其基类中指定的Component是无法被子类改动的，并且其属性无法直接作为Actor的參数来改动。解决方法是在Actor中添加相应属性，并在Construct图中，修正Actor的相应属性。
不带函数返回值的BP函数，重载时须要在Event Graph里进行操作。带函数返回值的BP函数，则是右键重载。改动函数原型时，要注意有可能会发生改动前是个右键函数重载，改动后是个Event图重载。
改动与BP合作的Interface调用型的时候，BP的重载实现有可能会发生找不到或是其它情况，要小心，改之前记得备份。
全局方法和静态方法怎么办？能够做到BPFunctionLibrary里。
读表尽管有DataTable什么的支持，但须要代码介入，感觉不是非常舒服，推荐自己整合读表、读文件功能到BP中，一劳永逸，代码能够參考它Json解析和Csv解析部分。
UI
类似WPF，熟悉WPF的人应该非常easy上手，数据绑定什么的基本都是WPF那套概念，对我这种WPF的铁杆支持者简直是如沐甘露。数据绑定也是那种上手非常困难，但一旦上手就认为其他全部UI系统都好Low啊这种东西……当然，这玩意儿对性能的负面影响也是客观存在的。一定程度下，性能跟系统的扩展和方便程度成反比，永远不要想着鱼与熊掌都能兼得，要能的话，早有人做出来了。
并不是唯一选择，Coherent UI什么的也有插件提供了，并且Coherent也支持Unity和CE3，商业项目能够考虑。