谈谈UE和Unity这两个技术选型的优缺点
内置功能的数量和先进性显然，UE在这方面有着决定性的优势。不过就当前的时间点，UE和Unity的差距也不算特别巨大，并不存在代差，这和Unity和coscos的差距并不相同。因此即使选择Unity作为基础来开发3A游戏也并非是不现实的（如果Unity在其他方面有优势的话，比如价格），只是并非优解，需要投入较大的开发成本。
如果局限到移动领域，由于移动的机能限制以及用户成分，对新技术的需求较低，UE在这方面就不再存在优势，但总得来说，也没有太明显的劣势。事实上，两款引擎都可以满足目前的移动开发需求，虽然各有缺陷，但缺陷都可以比较简单地通过二次开发补足。
注意，我并不是说引擎的内置功能是够用的。就现在的移动开发需求而言，只使用引擎内置功能谁都不能很好的完成工作。甚至可以说，UE在功能的完整性上还略逊一筹（但是功能细节更多）。但考虑引擎功能的时候不能只考虑内置功能，还要考虑那些已经针对引擎开发好的免费/付费三方扩展，他们和引擎的内置功能在使用上并没有区别。
总得来说，UE在移动开发的适用性上确实还是要差一些，但这个差距并没有那么大，更完全没有“不可行”这回事。但是在之前大部分情况下确实称不上是优解，于是就没有被开发商所选择。
简而言之在现在这个时间点，即使假设Unity因为某些原因而被国内封杀，只要UE还在，那么国内游戏业也不会完蛋，甚至都不会迎来很长时间的停滞，而且这个停滞更多是在人员学习成本而非改造的工作量上。
（但是以前确实不行，但以前Unity也完全不能想PC主机那边的事儿对吧？）
功能扩展效率
如果需要对引擎进行扩展……总得来说区别不大，但通常情况Unity会具备一定优势，但并不多。
Unity并不开放源码，它是通过开放一些底层接口来支持自己的扩展性的，而且处理得很好。而UE对于扩展性的处理方法就是“开放源码”。虽然看上去通过开放源码扩展功能比起使用引擎提供的底层接口更加Dirty，但实际上也没有那么糟糕。UE的源码同样也是分层的，如果你只关心你需要关心的部分，心智负担并不会太高。如果一套源码仅应用于少量项目并且不关心在其他项目的兼容性，通过修改源码更新功能并不能算是一个难以处理的工程缺陷。而且只要UE官方不要频繁重构，也能够正常同步UE自身的后续更新（哈哈，这点是很难保证，但重写渲染这种事也不会总有的，总之需要预备好合并版本的人力）
UE在这方面的缺陷其实主要体现在，每个用户扩展后的功能不容易通过社区与其他用户共享。同一个问题，某个Unity开发者解决了，它就能直接把工程打包放到网络上（或者扔进商店）让其他用户直接使用，但UE的开发者就只能写一些教程来教其他用户怎么改。这会导致你通过网络解决问题的效率变慢。但如果你的问题本来就无法借助网络解决，那这个缺陷就等于不存在。而且这个缺陷也只是交流没有Unity方便，而非不能。
此外，直接通过修改源码来扩展功能，也就意味着这部分内容并没有官方教程以及参考，毕竟官方不可能每个功能都教你怎么改，那也太多了。但一些常见的修改需求还是会有其他开发者的分享的。但是一旦涉及到不常用的修改，恐怕就很容易陷入可能性的汪洋之中，对开发者的水平就具备了比较高的要求。
（当然还有个问题是引擎的编译速度……但毕竟改引擎是低频操作，类似的情况还是忍忍吧，不要乱动Core这样的地方编译速度还是可以接受的，否则很容易陷入一次编译一小时的情况）
Unity虽然在扩展上要简便许多，但如果你的游戏有比较高的要求，依然会遇到必须修改引擎才能获得最优结果的情况。而由于平时无法看到源码，只能使用黑盒测试，做性能调优方面的工作也尤其不利。并且如果想接入一些三方中间件，直接接入源码也比从C#中转更加高效。
而Unity其实也是可以购买源码的。通过使用额外的资金购买源码后也就可以达到和UE同一水准。不过这里其实有一个很严重的“坑”：和UE的源码不同，Unity的源码实际上属于“别人的”商业机密，一旦泄露会产生非常严重的问题。因此各公司对Unity源码的保护都是非常严格的，这自然会导致一般员工源码的阅读权和修改权严重受限。当然，对Unity源码的修改内容也更不可能“泄露”了——你甚至都不能讨论，哪怕只是说说原理辅助解决使用上的引擎性能问题都不行，找公司外的人员帮忙处理问题当然更不行了，更不会有社区什么事儿。因此，如果准备对引擎做出比较彻底的改造，相比直接使用UE，购买Unity引擎源码这个方案绝对称不上是优解。
虽说这也不是一个很严重的问题（概率小），但终究会让人觉得心里有些没底，从而对技术选型产生一定的影响。
技术开发效率
虽然UE逻辑代码使用的是C++，但是已经经过了包装，内置了自动垃圾回收和反射，并提供了支持垃圾回收的整套数据容器。如果使用最新的C++编程规范，尽可能使用引用写法，并严格禁止各种所谓的“技巧”，代码看上去和C#其实并没有太大的区别。
而且C++也并不算一个很困难的语言，觉得C++难的程序员多半并没有接触过C++，毕竟一个语言的复杂程度始终无法和大型类库相提并论（而且特性多也不代表你都要会用，C#的全部特性也未必所有人都知道）。而C++所面临的巨大的工程灾难也并非它的复杂所至，而是人的问题。如果你招募一群熟练的C#程序员，用C#的规范和习惯来写C++，那大部分的常见问题其实都不会成为问题。
诸如getter方法确实需要声明为const，但我并不声明它，并从来不将自定义类的实例修饰为const，对普通的业务代码有任何影响吗？（虽然可以的话还是尽量声明了，c++多出来的特性也不算特别多，有用的特性干嘛不用呢）
不管怎么说，C++作为一门语言，开发效率怎么说也总比lua强多了。而且分好module编译速度也都OK。所以UE的C++相比Unity的C#是基本没有劣势的。
但是对于蓝图……不管是逻辑蓝图还是材质蓝图，对于技术来讲都是难用到几乎无法使用的东西。录入速度慢，更糟糕的是阅读效率极低。关于这点我实在不想争论，并没有讨论的价值。（光是蓝图不能像代码一样贴到网络上就够致命了，我抄别人的蓝图配置还得把图放大一个一个摆？）
但蓝图这东西本来就不是和C++平行的概念。C++是给技术使用的，蓝图是给非技术使用的。蓝图真正应该对标的应该是Unity的编辑器界面——如果这样对比的话，蓝图显然比Unity的编辑器要好用很多。正常的模式应该是由技术用C++实现蓝图节点，然后再由非技术用蓝图将功能拼接起来。假如并没有非技术拼接的这个步骤，那直接最大比例使用C++代码完成就好了。
蓝图本身可以作为逻辑的载体，但同时，它同时也负担着数据的载体。对于技术而言，依然必须使用蓝图的数据载体这个功能。
现代游戏团队里，由非技术设计逻辑早就是常态，即使是Unity也存在技能编辑器，关卡编辑器，AI编辑器这一类功能需求，而它们在UE对应的实现就是蓝图。除了数据外，确实也有一部分需要填写的内容是逻辑。从这点看，Unity孱弱的编辑器功能相比蓝图反而是一种劣势。
但问题是，UE官方对待蓝图显然并不是这样的逻辑。在他们的设计里，使用蓝图是优先于C++代码的，他提供的官方方案全部都是蓝图，最终导致很多内容非技术不看也看不懂，而技术看起来也很费劲——但说归这么说，我们只要自己做自己的，自己写的逻辑用C++，放给非技术用的内容暴露给蓝图，这样就行了，所以UE的蓝图其实并非缺点。
UE的材质系统其实也是可以使用代码的，需要利用插件系统编写usf文件自定义材质蓝图节点。虽然不能像hlsl那样完成所有工作单起码写函数的时候不再需要连连看，稍微麻烦点，但能用。
美术/设计的效率
上面也说了，蓝图作为C++的代替绝对是一种非常垃圾的形式，但是仅仅把它当做一种编辑器工具的话，那就是非常好用的了。虽然蓝图开发效率很低，但对于那些没有经历过编程学习的人来讲这就是唯一的方法（全民编程普及真的挺有必要的）。能够在流程里尽可能剥离掉技术的干扰，这就是效率的提升。更重要的是，可以有效回避他们由于难以实现而放弃需求的倾向性，有利于产品质量的提升。
而即使不考虑蓝图，UE的编辑器相比Unity也是具备一定优势的。这个……就是一些细节UE上的区别。
当然，Unity的编辑器扩展也是挺好用的，基本功能安装了odin也会更加便利一些。缺少的行为树一类功能也三方库，材质编辑器现在也有了。但终究，没有UE这种官方一体化，一致性要来的优秀。
不过，和我们编程一样，美术/设计师的主要工作也并非无脑密集操作，而是思考。而且有大量的工作是在引擎外完成的，所以引擎在这方面优劣在实际工作效率上的贡献并不起决定性作用。
但UE确实在这方面是占优的，所以一般外传的也是：UE是一个对美术非常友好的引擎。其实这种风评还是满重要的，因为它能让美术自己安装UE调试美术效果的概率提升。
这点我本来打算放到下面去讲——UE绝大部分界面支持中文其实是它非常大的优势。中国存在大量学不会英文的策划和美术，他们使用英文界面的方法就是死记单词和位置。虽然这看起来是个学习成本，但天天看着鸟文多多少少还是会对效率产生影响。更重要的是，这容易导致他们拒绝使用引擎，或者不愿意接触他们还没有“背过”的功能，从而导致许多工作必须由技术代而执行，导致了极大的效率降低。
Unity在中国的市场份额如此巨大的情况下依然不提供一个基本的用户界面汉化，讲真，我完全无法理解，难道它只打算让程序员使用Unity编辑器吗？（不过UE也没有提供代码参考的中文版本就是了）
人员培养成本
一般认为，对于技术而言，UE的学习成本比Unity高。
但你要真去问那些萌新初学者，恐怕答案并不总是如此。首先，UE是中文的，然后，UE进来以后会直接弹一个教程页出来介绍它所包含的功能，会采用新手引导的方式来进行教学，点击链接会弹到一个全中文的教程网页去。相比之下，Unity干了啥？
UE的功能也确实比Unity多一些，但只考虑实现特定功能需要花费的时间成本的话，UE并不比Unity困难。而且UE内置的功能也比Unity要多很多，Unity连个Post都需要从外部获取，这个寻找功能的成本可一点都不低。
如果面对的是非技术人员就更不用说了。首先就是语言是母语的优势，同时他们可以利用蓝图实现相当多功能，而不需要涉及编程，这对提高积极性有很大帮助。当然更重要的是，UE默认画质好啊。UE商店里的美术资源也比Unity数量多多了，画质好多了。能够比较快地搭建出可用的工程，对摸索学习引擎是有帮助的。
Unity当初被认为是一个容易学习的引擎，只是因为它功能少。但到了现在，需求上升了，要求学会的内容增加了，Unity和UE的画面和复杂度接近的时候……这个优势其实已经不存在了。
但是Unity毕竟有着先发优势，从业人员数量远大于UE。因此UE在这方面依然是大劣势。
然而这只是一个心态问题。其实游戏程序员的知识从来都不是绑定在某个引擎上的，而是绑定在特定技术上的，而技术通常是共通的。Unity的许多功能，你都可以在UE中找到对应的版本。唯一会绑定引擎的只是一些针对于引擎的技巧，但它们数量并不多，影响也不大。
其实不少厂商招募UE人员的时候还就是允许招募一点UE都不会的Unity技术的，因为事实上就是无所谓，也不需要磨合太久，实际用起来是比什么都不懂的UE新人强的。如果只是要避开UE的坑以及减少寻找解决方案的时间的话，有一个经验者也足够了。
UE困难的地方反而是修改源码这部分的工作，对成员的要求似乎是提高了——但那只是你对项目的要求提高了，而不是UE还是Unity的问题吧。
风险
是个引擎，就有坑。
想不掉坑，就得有人踩。
如果是主机PC平台，UE就占据着巨大的优势，因为做的人多。反之，在移动平台，Unity在这方面的优势就是绝对的。
然而风险归风险，这东西也并非那么可怕。诸如像安卓的适配问题，UE确实在这方面会经验不足，但如果你认真写一份测试用例，将游戏中有可能出兼容问题的部分都涉及一遍，然后用TestBird之类的兼容测试平台整体测试一遍，心理也是有底的。源码在你手上，没有什么是不能改的，实在改不了的也可以针对机型屏蔽。
不管怎么说，和平精英，龙族幻想这些游戏也上线了，至少说明这并不是一个不能解决的问题。
风险是实实在在的，但也就只是风险罢了。它其实很容易被其他因素影响，否则只考虑风险的话，你显然应该永远使用Unity 4.x。
引擎购买费用
UE相对于Unity的最大的竞争劣势，其实是价格。
上面说了那么多，其实，那些都是“可以解决的问题”，而价格则是“不能解决的问题”。
UE采用的是5%的收入分成，这对于大部分的国内厂商其实是不能接受的。因为这个5%是从总流水上抽成的，除去广告，渠道运营分成，落实到开发商手中的比例其实没多少，而这个总流水5%相对于开发商的投入就会成为一笔不小的开支，甚至在极端的情况下会完全吃掉所有的盈利。
但实际操作的时候，Epic也不是傻子。他很清楚自己的引擎相比Unity也没有什么决定性的优势，比起死磕这个5%的分成然后一分钱都拿不到，不如大家坐下来商议一个双方都能接受的价格。
5%只是UE的默认授权方式，而这个授权方式是可以商量的。只要价格合适，像Unity那样一次性购买也不是不能考虑。否则，现在那些使用UE的公司也不可能选择UE。
当然，国内也确实存在白用不给钱的说法。毕竟现在使用UE的编辑器连破解工具都不用，源码也放GIT上让你随便拉。
UE确实可以靠法务来找你要钱，但你看，你用Unity的时候，法务真的就来找你了吗？你的游戏如果不赚钱，人家都不知道你这个游戏。而且不赚钱的，干嘛来找你要分成费，闲的吗？
当然我这只是随便说说，毕竟国内用UE的项目很少，样本其实严重不足。这种做法也实在太不道德了。但是UE的授权方式确实是可以商量的，不要被这个5%吓到，还是老老实实按规矩来。
至少对于大厂而言，授权费用的差异，并不会对选择UE或Unity产生决定性影响。
人择
上面说的这些，可能有人会觉得我是在向着UE——这样想也正常，因为现在主流的看法就是，UE只能做桌面PC，不能做移动。如果和这个说法有一点违背的意思，那就是在偏向UE。
但你我其实心里也清楚，这只是防卫意识在作祟，作为Unity阵营的人，肯定不希望“UE可以做移动”，因为这会影响到Unity的生存，从而对自己的生存造成威胁。
我的看法其实是：在移动开发上，我也不清楚UE是比Unity强，还是比Unity差，而让我选的话，单是风险和不确定的授权费这两点就足够枪毙掉UE了。但是，选型这种东西，往往并不是把他们的优缺点列出来，然后一个个对比总结得出答案的过程。选型重要的不是哪个好，而是哪个“能用”，哪个“不能用”。
如果两个都“能用”的话……选择哪个，更多时候是由个别的，少数的人决定的，这个过程并不讲究完全的“合理性”。
所以FLASH死了，所以C#国内没人用，所以GO在仅有在国内大行其道，所以PHP是世界上最好的语言，然后被半斤八两的Python取而代之……
Unity用事实证明了自己“能行”，而UE呢？
我并不清楚，因为我只是个UE4初学者，更不可能有什么UE4线上项目经验（几个人有呢），所以我也不清楚UE4行不行，但至少，现在的我无法证明它“不行”。
这就很危险。
然而已经有人做出了选择。
因为他们做出了选择，在UE就产生了积累，放弃UE转向Unity的话就会产生沉没成本，在没有什么特别的理由（比如“UE确实不能用”）的情况下，他们多半是不会重新作出选择的。
并且，当今的形势下，有能力的人基本都在向头部公司靠拢。现在大部分中小公司已经不仅仅是资本无法和大公司抗衡，连“人”都已经完全不行了，没有“人”会进一步导致人员流失产生恶性循环。在这种情况下，他们想生存下去几乎是不可能的。
寡头的情况下，这些人选择的影响就会进一步放大。
总之，你根本无法阻止。
你只能也同样做出选择。至少，也要做出两手准备。
我只能说到这里了。
页:
[1]