1. 首頁 > 云知道 > >

淺談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雖然在擴展上要簡便許多，但如果你的游戲有比較高的要求，依然會遇到必須修改引擎才能獲得最優結果的情況 。

推薦閱讀