UE4随笔 二 第一印象

打开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的出现能让各位大爷们好好冷静下来想一想。不要老说"国内这么作游戏是有理由的"，我想说的是国外的游戏作的比你好，也是有理由的！