打开UE4，短暂的兴奋过后，开始大概扫一扫UE4的编辑器，整个界面比UE3更有现代气息：
之前看其他人写的文章，虚幻4最重要的改动集中在下面几个方向上：
跨平台：
WIN和MAC平台都能使用，这就意味着必须使用两个平台都能接受的方案。
界面：
由于上述的原则，WPF界面虽然很酷，不支持MONO就只能跟好评无缘了（顺便吐槽一下微软，基于NET做了那么多东西，却总是虎头蛇尾）。因此虚幻这回是自己搞了个界面系统出来……而且更丧心病狂的是这个界面可以用在游戏里……
C++化：
不知道是因为Unreal Script在移动平台上的性能表现不给力，还是因为自己维护一套Script成本稍显浪费，无论如何，UE4开始，之前负责连接工具和逻辑、内容提供者和解决方案提供者的Unreal Script让位给了"格式化"的C++。
这个改动并不是孤立的，相应的，整个解决方案更明晰地划分为了核心层、插件、逻辑层，一方面也提高了跨平台方面的能力。
同时，围绕着这个特性，最重要的应该就是热更新功能了吧？逻辑层代码由于已经独立于核心层，所以C++编撰的逻辑层代码修改，不需要退出编辑器，就可以在编辑器中自然而然地编译并重新载入——参与过实际项目的战友们应该都明白这意味着什么。
另一方面来说，国内不少战友拿到这种国外的引擎往往是一种暴殄天物的用法，把这些引擎改得乱七八糟。所以笔者个人感觉Unity重新定义了国内的引擎用法——没代码引擎变相的"好处"——人们不再是关注与技术细节，而是关注与Workflow了，而后者才是国外引擎现在真正的核心和强大之处。笔者本人现在就深陷于一个由于改造了国外原本优秀引擎而导致满地大坑的项目中……不过想来未来会越来越好——国内的开发者如果现在再准备把引擎改得乱七八糟，是要被策划和美术同学鄙视的——人家本身这么牛逼的特性，你一弄，没了，咋回事儿？给个解释呗？
Blue Print：
其实就是之前的Kismet的强化升级版，UE3单用Kismet能做出游戏，升级版的Blue Print应该只强不差。
UPK：
不见了，资源单文件存储：争议满满的UPK终于离开历史舞台了，所有资源现在以.uassert的后缀名分散在Content文件夹下的各种场合。这也意味着之前资源包升级和DLC最大的一个拦路虎没有了。看Launcher本身就做了自动更新，想来自动更新应该是引擎本身就可以支持了吧？
大概用了用，浏览了一下它的一些例子，感觉都很不错。
如果想开始制作自己的游戏的话最好先看看Content Examples：介绍虚幻4的基本特性和用法。从头到尾浏览一遍基本上这个引擎的使用方法就都清楚了，未来这块儿的工作应该主要是美术和策划的工作，程序大体应该了解一下，特别是如果还没有接触过虚幻的同事们，这个可以让你很快明白虚幻的整个工作流。
基本上，除了蓝图（虚幻3里KISMET的增强版）、地形有些变化外，其它内容部分相对UDK并无太大变化，虚幻3玩家应该能很快就上手。
其他例子多是一些手机版的游戏例子，不过例子不在多在完整。顺便说一句，Strategy Game这个可以关注一下。当年跟很多人争辩说虚幻能用来做RTS没人信，这个例子虽然不完全是一个RTS，但是基本上可以改变"虚幻只能用来做FPS和TPS"的印象了吧？
自己建立一个例子工程，随便找了个Third Person的模板，带BP的模板是指纯Blue Print，不带任何代码的。笔者创建的是带代码的版本：
Binaries顾名思义，这个例子最后会生成一个DLL在Binaries里，然后编辑器会重新加载这个DLL。热更新的具体代码还没看，但是应该是这个路数没跑。
Config跟UE3的Config一样，项目级别的系统设置，后面详细展开，一般来说，如果要改设置的话是改这里的Config。
Content就是原来UE3的Content，美术、策划资源全在这里，不解释。
DerivedDataCache还不知道是做什么的，后面看看吧。
Intermediate是生成的临时文件，包括工程、中间文件。
Saved包括一些运行时会创建并维护的内容：备份、日志、运行期的Config，跟UE3的方法一样：这个Config不需要去改，改动的应该是根目录Config下的内容。
Source不用说就是代码了。
会自动生成SLN，打开这个SLN就可以开工了，就像Unity会自动帮你建立一个Mono Develop工程一样。
如前所述，虚幻引擎所使用的是C++，而不是C#、Java代码。有人总觉得C++会导致虚幻上手难度变高，笔者个人感觉还好，因为你用到的C++是带有一定限制的，这些C++类是需要考虑与引擎其它部分的关系，以及考虑与编辑器的关系的，再加上虚幻自己实现了垃圾回收，所以整个调用并不会比C#麻烦太多——当然，LINQ什么的特殊语法就罢了。
生成的代码包括：
ThirdPerson：模块文件，似乎是定义这个DLL模块的，追溯了一下感觉像是DLL Entry这样的东西。
ThirdPersonCharacter：第三人称模式下，控制器操作的对象。目前里面写了很多跟输入消息绑定的语句。
ThridPersonGameMode：Game Mode是UE3带过来的概念了，当前第三人称游戏的一些设置，目前这里面定义了当前游戏控制器的操作对象：
// set default pawn class to our Blueprinted character
static ConstructorHelpers::FObjectFinder<UClass> PlayerPawnBPClass(TEXT("Class'/Game/Blueprints/MyCharacter.MyCharacter_C'"));
if (PlayerPawnBPClass.Object != NULL)
{
DefaultPawnClass = PlayerPawnBPClass.Object;
}
注意这里，不是直接注册的ThirdPersonCharacter，那ThirdPersonCharacter还有什么用？
别急，我们先看看：
Class'/Game/Blueprints/MyCharacter.MyCharacter_C'
这个意思是从Content/下的Blueprints里加载MyCharacter.MyCharacter_C，并把它认成一个Class。
我们去资源里找这个BluePrint：
打开：
解释一下就是这个BluePrint是从ThirdPersonCharacter派生的……OMG
所以，写在ThirdPersonCharacter代码里的那些与输入消息的绑定才有用：因为是这个MyCharacter是从这个C++脚本派生的嘛。
但是这么一来，MyCharacter一方面可以集成程序提供的基本操作方案，另一方面，策划可以通过BluePrint为其设计一些特殊的连线流程，两全其美啊！
有些东西，不想给策划弄的，或者策划弄不了的，比如AI底层，程序来集成就好了。想给策划弄的，这么一来你自己Blue Print去吧。
这块儿笔者真心给跪了。Orz
过去的UE3的Kismet也不是不能跟对象一起用，但那如果在编辑器里操作，就是得用Prefab，本身Prefab没有任何跟代码相关的概念，基本类似于一个各种对象放一起的大组。从某类继承？对不起，没这个概念。
所以UE3里，这种情况就得自己用Unreal Script写个UC类，然后在代码里自己手动拼各个组成组件的空间关系……加上Kismet互操作的代码来进行Kismet的互操作。
现在这Blue Print完全超越了Prefab这个概念，相当于把原来Unreal Script的这个工作用图形化的方式接管过来了……难怪Unreal Script被彻底抛弃。
点
开始运行，享受了一番，在ThirdPersonCharacter的方法里断点调试了一下，与猜测基本无差。
最牛逼的是，我们把代码里Move Right代码注了，
编译，然后再跑，不关编辑器，角色的向右移动就被我们给毙掉了，只能向前冲。
这个过程稍微有点危险，笔者致挂一次，记得保存改动先。
还想继续整整，到上班点了，最近公司工作较忙，只能先放放后面弄了。
笔者现在进行的其实就是UE3以上、UE4未满的工作：策划通过图表完成自己的想法。在一个老企业中推行这种其实已经不算新，但在国内特别是北京圈还不算非常能让人接受的做法。希望这次UE4的出现能让各位大爷们好好冷静下来想想。不要老说"国内这么做游戏是有理由的"，我想说的是国外的游戏做的比你好，也是有理由的！