虚幻4随笔7 未知的未来

虚幻都免费了，再不说句话似乎就有点过分了。

在此首先向一直关注的诸位网友道个歉，这几个月笔者稍微遇到点事儿，首先是当爸爸了，所以占了很大的精力。

然后，对于未来的选择和定位、职业发展方向上，笔者这几个月也是颇为纠结的。去年底，最终决定要离职了，要从当前的生活模式和状态中暂时地退出来，去折腾一下自己所希望的未来。所以心思多少也不在研究上了，而且，既然做出了这样的决定，就需要把手头本身计划做到今年中旬的业务，集中压缩在离职前做完，所以这段时间也是蛮折腾的。

最后就是，这几个月自己研究方面的东西乏善可陈……一个3D宇宙的解决方案遇到一系列的坎儿，一个Noise编辑器也是越弄越崩溃，本来计划的对Task Graph的研究、对Kinect的集成也始终没有完成。确实没有什么太多能拿得出手来的东西能跟大家分享，所以，千言万语，到最后还是很抱歉的。

其实最近一直有关注论坛和Q群，不开心的时候，看看Q群里一帮坚持着理想的战友各自都有很大的进步，就会觉得自己这小九九简直就不叫事儿。无论如何，接下来应该是可以慢慢把虚幻再捡起来了，一起努力吧，为了每个人自己的梦想。

虚幻其实学习应该不能算困难的，发现的很多问题，其实都是官网文档库和Content Examples里都有的，建议想接触的朋友一定要先把Content Examples看完，看Example的时候，参考相应的文档库文档。然后再看看官方其他的示例，比如ShooterGame之类的。最后是多看看论坛、wiki，里面有很多人讨论一些问题的制作方法。这么一套下来，基本应该是差不多能开始做东西了，剩下的问题就是做的过程中遇到问题，查问题，问问题之类的了。

 

正如一开头所说，虚幻引擎免月租费了，之前是每个月6碗拉面钱，现在连这6碗拉面都给省了，兴奋的我决定接下来连吃一周兰州拉面。当然，抽成还是要的，觉得自己能赚很多的项目，也有支持更好的商业买断的版本。虚幻引擎在国内一直是一个不算很大众的引擎，它的前身UDK，在中国也不温不火，远不如在国外的热度。而最难逃开的问题，所有UE群都必然爆发过的，就是"真理的大讨论"——UE与Unity的PK。

说实话，个人感觉，这俩PK就跟XBO跟PS4去PK似的，其实没啥必要。引擎归结到底也就是个工具，做什么游戏用什么工具——如果要做经典FPS，那首推UE4、CE；如果要做手游，首推Unity、Cocos；如果要做英雄联盟——那就啥都一样了，因为最大的制作成本是发生在设计AI上……当然这么说就太简化了，挑选引擎有时候也没那么多讲究，多数人往往是有权挑项目，无权挑引擎的。到现在为止，笔者都是参与项目之前就有人帮我订好了引擎，从未能自己去挑选引擎。其实，这种程序人员在游戏项目中的尴尬地位，比起到底是UE好还是Unity好要更深刻地伤害着我们这个游戏行业。更可怕的是，引擎优秀与否的标准竟然是只看图形效果是否牛掰……所以经常感觉Unity的火爆其实从各个方面都是一种好事——最重要的是应该会让那些依然关注图形的人们好好想想，究竟什么对于引擎才是最重要的？

每个引擎，都有自己的特质。Unity 4是没法自定义Mesh Stream结构的（5没有来得及跟），这就会限制很多高级效果的引入；而UE在手机上的优化需要做的工作太多，追求短平快的也不是个好的选择。对于项目而言，悲剧的是拿了水果刀去切猪骨，或者拿剁骨刀去削苹果皮……工具的追求上，都了解了解会比较好。当然，如果只是为了找工作拿好点的工资，页游火那阵一开始做网页的很多人都赚了，但是那会儿开始着急忙慌学网页开发的有多少找到好工作了？能做到别人做不到的，自然就有人来找你，做不到别人能做到的，自然也就只能给人打工，祝好运吧。

其实说实话，Unity和UE4在上层部分的构架没有那么大的不同。记得最有意思的一个例子，就是有网友说，他的前辈告诉他，虚幻没法做RTS那种在地上放建筑的系统——然而正好两周前笔者做了一个类似的系统，而且是完全用蓝图，一行代码没写……UE目前"做不了"的东西确实是有，比如资源的全面动态加载，这个我们项目之前针对UE3做了一套解决方案，但是前后折腾了很长时间。但上层部分……笔者个人是没想到。引擎只是工具，策划的需求如何用工具去表达出来，这是程序的功底和价值。我遇到过太多"这个做不了，那个很麻烦"的程序，这种遇到事情先放弃的心态，只怕比选择什么引擎带来的问题更加可怕吧……

 

现在的时代，共享已经成为了主流，这也是符合社会化大生产进一步进化的要求的。生产更加社会化，就导致每个人所需关注的点少了。曾经制作游戏的人，一个程序往往需要把从图形到状态机到AI到声音的所有步骤都能给Hold住，那个时代对我们而言，就像是在听希腊神话里那些神祗的故事一样。但是随着游戏项目规模几何级数的增加，到现在为止，就算有一个人能够把从引擎到客户端到服务器整套东西都能做出来，他也没有时间把这些都做出来，因为时间完全是无法承受的重量。所以这个时代，最重要的技能是去Github和stackoverflow里面寻找各种巨人的肩膀，从一个巨人的肩膀上跳到另一个巨人的肩膀上。同样，自己做的东西也可以扔到上面去，共享给别人，让别人看，让别人给你调错，给你找Bug，发现你的问题，让你提高，同时把你的东西越改越好——所以你看，Unity商店、插件的机制，从小到大，但他选择的这条路正好是符合这个时代的特征的。时代的变迁，生产力的进化，完成了它的必然性的构成，而Unity本身中庸而全面的特性，完成了它偶然性的构成，结果就是今天Unity的地位。其实同时代的国内有不少自研引擎也走到了这一步的门槛，但是封闭让我们错失了这个机会。特别是虚幻开放之后，才发现开放这招非但没有对自己造成不良的后果，反而全世界的开发者帮你查Bug，挑问题，基于你的系统来做第三方接入，慢慢构建起一套生态系统。……开源，真的一点都没有吃亏啊！

时代已经变了，现在，已经没有一家公司能够完全地掌握所有先进的东西。共享、合作、分担、共同进步……虽然在国内不常能感觉到，但是它们确实是在发生并且影响着我们的。用Unity却从未下过插件，啥东西都是自己搞出来的，有几个呢？虽然我们可能以为这是天经地义的，但它毕竟脱胎于那个不是那么天经地义的时代。

新的时代来临了，各自都要做出应对，而Epic的应对，就是UE4——一个在UE3之上，全面增强模块化和扩展性的解决方案。

其实UE应该很早就意识到这个问题了，UE3的集成度和扩展度其实一直是很高水平的，基于反射体系构建编辑器、自动序列化，Actor/Component构型，07年的时候我就从UE中学到了，那一批看UE的国内程序同事们应该很多人都写过类似的文字。在整合第三方库方面，UE也还是蛮简单的——相对于同时代的其它引擎而言。Beast、Scaleform……我们自己随便搞搞，也能往里面很方便的就把自己的服务器框架什么的整合进去。UE3商业授权的话，也能够拿到其它项目的示例，战争机器、剑灵、Atlas……还是很让人受益匪浅的。UDK在国外的讨论也是一直很火（国内可能很多人不是很清楚，Unreal的MOD社群在国外一直是一个比较大的社群，虚幻竞技场在欧美的活跃程度是很高的，欧美引擎非常注重养MOD社群的，欧美的玩家也更具有海洋民族的开拓精神）。

但是，UE3体量太过庞大，结构中一些死结还是很多的。而且，虽然UE3好扩展，但是再好扩展也要各种修改C++代码，想办法在虚幻的结构之间打上各种各样的眼儿，把自己的代码注入其中——这都会在后面的升级和维护中造成一系列不可预估的后果。

首先，模块化。UE4这套插件体系，在UE3中就是不可想象的。UE4做第三方集成，比VS工程做集成还简单，模块结构分的琐碎也使得它必须去设计一系列模块间进行交互的接口，使得做插件的时候可以直接去访问这些交互接口，在插件里写出引擎的范儿，也丝毫不用担心自己会破坏引擎的结构。而UE3里，则需要各种找对应处理的地方，往里面加入自己所需的代码。引擎一旦升级，就各种需要重新集成，平均每次升级基本上一个月的功夫就没了。而UE4的升级，只要接口不变（一个引擎数十上百个接口，而且接口本身就高度抽象，再大的升级也不可能所有地方都变啊），基本上放那里不管就行。目前来看，最短一天，最长一周，就基本可以完成项目的新旧版本迁移。至少现在是敢于去做这件事情了，之前的UE3项目，做一次升级那个困难啊……不到实在忍受不了的时候，谁也不愿意去开个头。

此外，UE3的很多游戏系统设计是非常棒的，只是一是跟FPS相性最好，其他游戏类型就要差点，另一个就是不该出现在引擎的核心层里：比如Game Mode，比如Login产生Player Controller，比如Controller变化要通知服务器广播……诸如此类的很多很多。熟知这套系统的，自然也能游刃有余地在其基础上绕出自己的玩法，但是它毕竟增加了理解成本。而且，一旦不做FPS，多多少少是要花点工作量绕一些概念的。比如要做RTS，Controller对Pawn的控制流程就会显得鸡肋。虽然对于熟悉的人而言，绕这么几下都不是个事儿，但毕竟这是一个没必要的事情。但是，这一点，话要两说，Unity够自由，完全不在游戏系统中做限制，缺点就是前期插件来插件去，很容易搞出一个很让人不知如何评价的游戏系统——特别是在游戏系统的设计层面国内鲜有人会去关注的情况下。在项目普遍比较接近原型开发、强调速度、策划也愿意各种放弃的手游项目里，还可以接受。但是一旦项目做大一些，特别是等到开始玩"刀尖上的芭蕾"，同一个系统要经受各种预想不到、无法假设的情况的时候，这样的问题就会暴露出来。所以就算是用Unity做项目的朋友，我也会经常向他们推荐UE的这套上层架构，包括过来公司参与项目，第一件事就是推行这套上层架构的概念。UE4为了加速迭代，这套架构的很多方面在不断弱化，而把所谓的自由更多地交给了制作者本人，所以其实BP现在可以完全绕开Game Mode和Player Controller，在几乎无视他们的情况下完成整个游戏。但这对于系统复杂的大项目来说，很可能前期的这种设计就是后期开发团队崩溃的根源。

最后就是对异步、并行的一系列支持。Task graph还没跟，但是现在已经不单纯是分逻辑线程和渲染线程，而是有了明确的线程池和业务的概念，未来并行这块的进化有很多可以期待的地方。UObject很可能会在后面的几个版本中全面异步化，借之影响的是资源系统的全面异步加载从理论上成为可能（甚至看Trello，UE自己就在做这方面的工作）。

我们站在今天的角度上去批评UE当年的决策，无疑是很不公平，就如同我们今天去批判C++为什么不早点引入C++1x这些特性一样。我想，如果理解了UE是怎么一步一个坑走过来的，应该也就比较容易理解UE4后续的一系列决策了吧。

所以，UE4来了。不管这一步是早是晚，不管这一步是来得及时还是不及时，它终究是在2014年的GDC来了，并在2015年的GDC免费了。

而UE也确实没有让我们失望，从一开始的4.0就能够看出来虚幻在对UE3一系列需要改代码才能实现的功能在做各种的封装和抽象。虚幻3只有十几个代码模块，而虚幻4则抽出了数十个模块——理论上，每个模块，除了依赖模块外都可以互相独立存在，这就必须要求在模块之间抽象大量的接口。UE3之前很多直接调用的地方，现在都变成了接口调用，特别是编辑器方面，导致现在的编辑器扩展变得简单许多。游戏系统部分，也简化了和弱化了许多虚幻3固有的一些概念，导致你不知道Player Contoller，不知道Game Mode，照样可以做自己的小游戏。UE4一系列C++的实现也简直是教科书般地优美，我现在在做一些C++ Console工程时，也已经不再使用VS的Wizard，而是直接在UE里创建Console工程项目了。……

这简直就是一座宝库，如果您的目标不仅仅是开发一个简单的手游、不仅仅是去折腾游戏系统和数值，而是想做一些别人想都不敢想的东西，那么，虚幻无疑是适合你的。它的代码可以让你受益良多，亦可以让你对整个系统拥有无可争辩的控制权，随意地增加一些尚未出现在这个世界上的游戏特性。

……嗯，越写越像传销了……因为个人确实是喜欢虚幻，它在强大的功能和强大的扩展性之间建立了绝妙的平衡，虽然仍然还有一些不足，但是随着社区的扩大、第三方库的不断加入，相信虚幻的未来会越来越易用、越来越强大。但是，说到底，无论引擎还是第三方的各种技术，都只是工具。Demo和产品之间横亘着巨大的鸿沟，更遑论是制作这些Demo所需的底层技术和工具。对于项目而言，工作流、人员、资金、目标受众、稳定的团队、整合程度……所有这些才是核心和关键的。

 

说了这么多，其实没有什么干货。从公司离职后，应该能有更多的时间去做UE部分的研究，希望下一篇随笔能多点干货。