虚幻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，那首推UE四、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部分的研究，但愿下一篇随笔能多点干货。