浅谈UE4引擎,ue4引擎

学习Unity引擎更好还是学习UE4引擎更好?

浅谈UE4引擎,ue4引擎


显然,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虽然在扩展上要简便许多,但如果你的游戏有比较高的要求,依然会遇到必须修改引擎才能获得最优结果的情况 。

推荐阅读