Unreal4 VS Unity

这是一个很难的问题，而且不容易回答，很容易引起争论，老实说我并不想在公开场合评论到底哪个更好或者更坏，这并不明智，其实每个人心底都有自己的答案。

我只想聊一些我的看法。

一、关于Unreal4和Unity

很不幸，我并没有看过Unity代码，我们没有购买，而我也并不是特别想看。或许有人说：装！嗯，其实写了很多年代码了，什么没见过？看过并不一定能写出那样的产品，没看过也不代表你不能写出超越它的代码。很多人对待引擎代码的态度其实和追女孩差不多，没追到的时候，天天时时刻刻想着，到手了，就呆在硬盘里，其实真正每个文件都读过的人，凤毛麟角，读懂的人可能更少。

在刚开始学习游戏引擎的时候，需要读一定数量的代码，但积累了一定的代码量和经验之后，需要的更多是观察、思考、总结。所以比较资深的程序员，会花更大量的时间思考，而不是学（chao）习（xi）别人的代码。

回到这两者的对比上，我没看过，所以就不知道怎么对比了，只能说各有各的好，咸鱼青菜各有所爱，而且游戏界的金科玉律就是，谁能出产品，谁能大卖，谁就是赢家。

至今Unreal3已经被证明了是一个伟大的引擎，有足够的title说明问题了。Unity有不少作品，但还缺乏一锤定音的作品，和AAA不沾边有关系吧。但用户足够多，增长率高也可以说明问题。Unreal4还欠缺证明自己的作品，等战争机器吧，Epic还需要向别人演示怎么使用这个引擎。

二、关于题主提出的几个对比

很直接说一句，那都不是什么问题，或者可以说，根本不是比较的重点。Unity那种写法，上世纪就已经有人在用，不见得是什么高明的写法，这种c/c++的奇技淫巧，只有初学者或者刚刚学会一点儿的人会感兴趣。我顺手可以拈来好多类似的，比如gcc的tree node结构，初读感觉那个精妙，后来发现也就那样儿。这种union我大概10年前在写高速raytrace引擎的时候已经用过，而且用在xmm上面，即现在DirectXMath的写法。至于你说不明白为什么Unreal这么写，看不懂if。为什么？很简单啊，因为这是“历史问题”。那个年代过来的代码都是这么写的，就一直这么写了。

很多人搞错了一点，以为数学库要效率高，这也是我刚开始写引擎和图形程序时候的错觉。后来发现，不是的，游戏引擎的数学库，不是全都要求效率高的，数学库最重要的是“稳定”。因为真正在跑的，AAA游戏，或者重度的MMORPG，最重要的，不是数学运算，而是“架构”。反而数学运算，需要稳。稳到什么程度？havok曾经推销他们的物理引擎，最引以为傲的的，并不是它有多快，而是它的所有物理运算在所有平台上的计算结果都完全一致（评论有朋友修正了这个说法，应该是同样的计算在同一平台上每次计算都一样）。这简直吊炸天啊有木有！！！如果你不明白这句话背后的意义，那么我想你没必要讨论数学库了。

回到问题本身，一个字，编译器优化，可以回答一切问题。

现代游戏引擎的瓶颈，有两处，一处是runtime的执行效率，一处是content creation的pipeline生产效率。后者太庞大太宽泛，没实战过的人，不理解，这里不展开细说，只讨论第一点，runtime。

runtime部分，现代引擎面对的问题，主要是越来越复杂的场景，越来越多的drawcall，越来越重的资源。这里面最麻烦的就是提交。所以新一代的API，都注重提高提交效率，即更薄的driver层。这就是DX12标榜的十万drawcall的意义。

这里我必须提一点，这两个引擎，Unreal4和Unity，都有一个架构上的严重欠缺，就是没有从原生上支持多线程。即使Unity5，也只是用了一种thread pool的分发的策略，把一部分集中的繁重的事务分发到其它线程计算，但它并不是真正的“原生多线程”，即任意的不相关的任务都可以随意分发到不同的线程上。考虑每个entity自己更新自己的逻辑，可以并行，有100核心就可以几乎真的并行更新100个entity，这才是真正的原生多线程。

这种引擎，目前公开的只有Frostbite 3是这么做的。（当然我不会告诉你，我们……）。

至于Component架构，这方面我有另一种看法。游戏引擎是一个很重度的工程项目，而非科研项目，干净与否并不能成为评判标准，实用性才是金科玉律。我认为unreal这么做（把业务相关的东西放到底层），是基于一种发展的眼光看。很简单，我也会这么做，如果我开发了一套非常超前的架构，但我又对它没有足够的底，不知道接下来应该怎么写，我认为总体方向是对的，但我不清楚业务和他如何结合，那么我就采取折中的方式来处理，即把一部分业务嵌到架构中，先把业务应用起来，验证架构的正确性，然后通过重构和迭代，逐步把业务细节划分出去。

显然UObject是继承Unreal3而来的，Unreal4非常大胆，blueprint是一种非常超前的想法，而且非常有前途，也非常好，但这个改变太庞大了，太重了，要一下子割裂和Unreal3的关系是不切实际的，稳妥的方式是逐步修改过来，并且验证之后再完全迁移过去。所以迁入一部分实际业务的想法很现实。而且要考虑，引擎开发本身应该依附具体项目。我认为Unreal4应该依附在战争机器游戏本身的开发身上，才可以保证它不会走弯路。所以在底层重度嵌入一部分FPS相关代码，无可厚非也没有任何问题。

老实说，我有代码洁癖，但我也会这么做，因为引擎不是独立产品，是依附游戏的附带产物，一切应该以游戏业务为优先。这也是为什么我一直对Unity有一些负面看法的原因，它的开发商本身并没有任何游戏，一切反馈是来自于用户，二手数据。所以Unity看起来似乎很“干净”，但就是太干净，干净得出奇，变得不接地气，这才是为什么它缺乏AAA。

三、渲染质量之谈

题主似乎不断在强调不要被Unreal4的渲染质量吓唬住了，我觉得这句话是很有问题的，直接地说，这句话是不专业的，一点都不professional的。显然题主是有倾向性的，因为Unity本身就是一直被Unreal4的渲染所吓唬住了，所以每个版本的升级都在重点强调自己的渲染特性得到了提升。

老实说，这并不明智。因为Unity的提交效率。。。

上面提到了一点，现代引擎的瓶颈一个很重要的点就在于渲染批次的提交上面。这里请看我一直所赞誉的Frostbite 3,的数据——BF4一些场景的DP数量达到了5000~10000。吊炸天啊！这需要非常高的提交效率，非常优异的渲染组织。这就是引擎真正的架构技术核心所在。另一个碉堡了的是CryEngine，提交效率很高。

所谓“渲染质量”是什么鬼东西？搞了差不多二十年图形，我很少听到专业人士提到这个词。我听过渲染效率，听过画面质量，听过各种shading model。同一张显卡，同样的shading model如果还用同样的模型，同样的算法，有什么质量不质量的？难道Unreal4算的 1 + 1 = 2 比 Unity 算的 1 + 1 = 2 质量要高？那个 2 要更好看？

不是的，这是业余的看法。专业的看法是，你要对画面有取舍，有调控。引擎是一个大的系统，系统设计最重要的一环是控制和分配。图形学没什么算法是不公开的，Unreal4用到的所有算法都是公开的，所有的siggraph paper你都能access到，没什么秘方，没什么magic code。关键是，你的取舍，你花多少资源在哪个部分，省了哪个地方的东西。

这部分的功力，是源自于游戏开发本身，源自于积累，源自于TA。这也是Unity欠缺的地方，因为Epic自己开发游戏。所以Epic在资源的调配上，有取舍，有经验，在开发战争机器的时候，在开发游戏的时候，有各种纠结，填了不少坑。写好代码只是开始，教会TA和美术使用引擎、正确使用你写的技术、配合并创造出美丽的画面，才是真正有绝对价值和意义的工作，这占了99%。

图形学是工程的图形学，是trick和cheat的集合。正如你堆钱买奢侈品是不能除掉身上浓浓的杀马特山寨风的，必须读书、读书、读书、思考、思考、思考、沉淀、沉淀、沉淀。光靠堆一些feature，不是正确的姿势。这就是为什么Unity 5堆了那么多feature，看起来还是远不如Elemental Demo。

四、双生

对比Unreal、Unity，同样的例子，请看CGFX领域的MetalImage和Pixar。MentalRay非常屌，有很多先进设计，一直坚持用raytrace，早就开发出电影质量的全局光渲染，但它一直被死对头Pixar的RenderMan所压制。Pixar的RenderMan，采用“落后的”渲染算法REYES，直到13.0版本之前一直不支持raytrace，且价格昂贵，更新缓慢，但广受电影制作喜爱，上世纪好莱坞特效渲染标配渲染器。为什么？很简单，Pixar自己是做电影的，RenderMan本身一直为Pixar的电影服务，获得各种第一手电影制作需求。而反观MentalImage一直只是一家软件公司，没有电影业务，只卖软件，只卖技术，所以无论改进得多好，一直不懂电影制作者的心。

我对Unreal和Unity的看法，也基本基于此案例。当然，现在disney有更强的渲染器，可以完全干死RenderMan，不过这货是不卖的，正如Frostbite，也是不卖的。世界上最好的引擎技术，不会出现在商业引擎里面，只会在In house engine中。

五、寄望

我聊了许多，然而这并没有什么卵用，工作中该用哪款的，还是要用哪款，这不是技术人员能够决定的。不过我一直以来的信念，都是我们始终是要做自己的引擎的，并不是为国争光什么的狗屁高大上理由。很简单，技术人员存在的意义，就在于用技术碾压对手。你的技术，到底是用在给别人打补丁上，还是给自己充实力量上？

所以我对所有这些第三方引擎的态度，都是批判地学习。好的，我兹词，不好的，我谨记并绕开。其它不参合任何个人感情，也不需要卖任何情怀，只需要记住，所有的这些——Unreal、Unity、CryEngine、Frostbite、SnowDrop、Fox等等等等，都是他人的嫁衣裳，我们真正需要的，是自己的遮羞布。

题主的批判态度，已经带有点私人感情了，这并不理智，希望你可以成长，客观看待这些东西。

————————————————————

补充一点，题主说Unreal4不如ogre，我觉得这真有点太过了。ogre实在是渣渣渣渣渣。不多说，自己领悟吧。

————————————————————

再最后补充一点，评判这些引擎的时候，如果你不是对自己的实力有足够的把握，如果你不是很清楚到底自己是否真的彻底了解这些设计背后的原本意义，那么千万千万千万别开上帝视角。

要很清楚这些引擎是世界最顶尖的脑袋架构出来的，一些显而易见的问题，比如用if是否很2b，难道你以为可以架构出blueprint、能够做到c++hot load这种吊炸天的人，他们想不到？

不可能的事情！去看看Unreal4的Multicast delegate怎么设计，怎么构建，C++用的多好，多纯熟，对语言的压榨多极致，能够有这种把握深度的人，会不知道用书本上写的条条框框“千万别用if啊”什么的？不可能的事情！

Tim Sweeney这些人的脑袋太好用了，太厉害了。比如Component的结构，坑超级多，你想到的，别人不会没想到。我遇到这种情况，不会第一时间想别人是否2b了，而会先考虑、是否自己没想到更深刻的问题？或许还有其他坑？就连Voxel Cone Tracing这种屌炸天的算法都能想到，不可能想不到你看出来的小问题。

所以，每当要开启上帝视角，请换一下角度，如果是你，你怎么设计，你怎么处理，真的就没有问题？如果你真的设计的比他们好，请别犹豫，站出来，战胜他们。