顯然，UE在這方面有著決定性的優(yōu)勢。不過就當前的時間點，UE和Unity的差距也不算特別巨大，并不存在代差，這和Unity和coscos的差距并不相同。因此即使選擇Unity作為基礎來開發(fā)3A游戲也并非是不現(xiàn)實的（如果Unity在其他方面有優(yōu)勢的話，比如價格），只是并非優(yōu)解，需要投入較大的開發(fā)成本。

如果局限到移動領域，由于移動的機能限制以及用戶成分，對新技術的需求較低，UE在這方面就不再存在優(yōu)勢，但總得來說，也沒有太明顯的劣勢。事實上，兩款引擎都可以滿足目前的移動開發(fā)需求，雖然各有缺陷，但缺陷都可以比較簡單地通過二次開發(fā)補足。

注意，我并不是說引擎的內置功能是夠用的。就現(xiàn)在的移動開發(fā)需求而言，只使用引擎內置功能誰都不能很好的完成工作。甚至可以說，UE在功能的完整性上還略遜一籌（但是功能細節(jié)更多）。但考慮引擎功能的時候不能只考慮內置功能，還要考慮那些已經針對引擎開發(fā)好的免費/付費三方擴展，他們和引擎的內置功能在使用上并沒有區(qū)別。

總得來說，UE在移動開發(fā)的適用性上確實還是要差一些，但這個差距并沒有那么大，更完全沒有“不可行”這回事。但是在之前大部分情況下確實稱不上是優(yōu)解，于是就沒有被開發(fā)商所選擇。

簡而言之在現(xiàn)在這個時間點，即使假設Unity因為某些原因而被國內封殺，只要UE還在，那么國內游戲業(yè)也不會完蛋，甚至都不會迎來很長時間的停滯，而且這個停滯更多是在人員學習成本而非改造的工作量上。

（但是以前確實不行，但以前Unity也完全不能想PC主機那邊的事兒對吧？）

功能擴展效率

如果需要對引擎進行擴展……總得來說區(qū)別不大，但通常情況Unity會具備一定優(yōu)勢，但并不多。

Unity并不開放源碼，它是通過開放一些底層接口來支持自己的擴展性的，而且處理得很好。而UE對于擴展性的處理方法就是“開放源碼”。雖然看上去通過開放源碼擴展功能比起使用引擎提供的底層接口更加Dirty，但實際上也沒有那么糟糕。UE的源碼同樣也是分層的，如果你只關心你需要關心的部分，心智負擔并不會太高。如果一套源碼僅應用于少量項目并且不關心在其他項目的兼容性，通過修改源碼更新功能并不能算是一個難以處理的工程缺陷。而且只要UE官方不要頻繁重構，也能夠正常同步UE自身的后續(xù)更新（哈哈，這點是很難保證，但重寫渲染這種事也不會總有的，總之需要預備好合并版本的人力）

UE在這方面的缺陷其實主要體現(xiàn)在，每個用戶擴展后的功能不容易通過社區(qū)與其他用戶共享。同一個問題，某個Unity開發(fā)者解決了，它就能直接把工程打包放到網絡上（或者扔進商店）讓其他用戶直接使用，但UE的開發(fā)者就只能寫一些教程來教其他用戶怎么改。這會導致你通過網絡解決問題的效率變慢。但如果你的問題本來就無法借助網絡解決，那這個缺陷就等于不存在。而且這個缺陷也只是交流沒有Unity方便，而非不能。

此外，直接通過修改源碼來擴展功能，也就意味著這部分內容并沒有官方教程以及參考，畢竟官方不可能每個功能都教你怎么改，那也太多了。但一些常見的修改需求還是會有其他開發(fā)者的分享的。但是一旦涉及到不常用的修改，恐怕就很容易陷入可能性的汪洋之中，對開發(fā)者的水平就具備了比較高的要求。

（當然還有個問題是引擎的編譯速度……但畢竟改引擎是低頻操作，類似的情況還是忍忍吧，不要亂動Core這樣的地方編譯速度還是可以接受的，否則很容易陷入一次編譯一小時的情況）

Unity雖然在擴展上要簡便許多，但如果你的游戲有比較高的要求，依然會遇到必須修改引擎才能獲得最優(yōu)結果的情況。而由于平時無法看到源碼，只能使用黑盒測試，做性能調優(yōu)方面的工作也尤其不利。并且如果想接入一些三方中間件，直接接入源碼也比從C#中轉更加高效。

而Unity其實也是可以購買源碼的。通過使用額外的資金購買源碼后也就可以達到和UE同一水準。不過這里其實有一個很嚴重的“坑”：和UE的源碼不同，Unity的源碼實際上屬于“別人的”商業(yè)機密，一旦泄露會產生非常嚴重的問題。因此各公司對Unity源碼的保護都是非常嚴格的，這自然會導致一般員工源碼的閱讀權和修改權嚴重受限。當然，對Unity源碼的修改內容也更不可能“泄露”了——你甚至都不能討論，哪怕只是說說原理輔助解決使用上的引擎性能問題都不行，找公司外的人員幫忙處理問題當然更不行了，更不會有社區(qū)什么事兒。因此，如果準備對引擎做出比較徹底的改造，相比直接使用UE，購買Unity引擎源碼這個方案絕對稱不上是優(yōu)解。

雖說這也不是一個很嚴重的問題（概率�。�，但終究會讓人覺得心里有些沒底，從而對技術選型產生一定的影響。

技術開發(fā)效率

雖然UE邏輯代碼使用的是C++，但是已經經過了包裝，內置了自動垃圾回收和反射，并提供了支持垃圾回收的整套數(shù)據(jù)容器。如果使用最新的C++編程規(guī)范，盡可能使用引用寫法，并嚴格禁止各種所謂的“技巧”，代碼看上去和C#其實并沒有太大的區(qū)別。

而且C++也并不算一個很困難的語言，覺得C++難的程序員多半并沒有接觸過C++，畢竟

Unity和虛幻都是很好的平臺工具，使用的語言不太一樣，一個是.net，一個是c；應用場景不太一樣，unity主要是手持設備，ue比較全面；還有就是價格了。不能簡單說誰好誰不好，良性競爭對程序員來說比較好，省錢。