對不起，這是一篇有立場的文字，以我的心性，絕對的客觀是做不到的。
我嘗試放下現有方案和項目歷史，就去假想一個適合自己情況的理想化的手游引擎（后文均簡稱為引擎），他應該是什么樣的。然后再來看看如今流行的方案 unreal，u3d，他們和理想中的引擎的異同。
引擎的使用者是誰。
引擎從來沒有一個標准的概念，但是翻越歷史的長河，可以很明顯的看得到引擎這個概念的行業共識是在不斷發生變化的，而引擎的使用者也有着一個清晰的變化軌跡。
如果你看過獅子王，那劇情差不多就是這樣子的
1. 蠻荒
游戲與引擎沒有明顯邊界，程序員要直接面對dx gl 這類api，甚至更早的年代程序員自己堆像素。這是一個沒有分工的時期。
2. 先知
終於有人意識到，底層框架擁有很大程度的共性，可以通過分工協作抽象出引擎這一概念，於是涌現出很多的游戲引擎，比如torque、irrlicht、ogre，這個時代的游戲引擎其最大特征都是以供程序員使用作為主導，其提供的核心內容是一組供程序員調用的類庫，以及一些零散的輔助工具。
此時主要使用引擎的人，是程序猿
3. 文藝復興
在后來的發展過程中，美術工具的價值被發掘出來，美術向編輯器的豐富程度和一個引擎的易用程度有着非常直觀的聯系，而引擎的含義，更大程度是表示這些美術向的編輯器，而非程序使用的類庫。
換句話說，引擎的使用者從程序主導，開始過渡到美術主導。這也是游戲畫面開始突飛猛進的時代。
4. 策划的崛起
作為游戲設計者的策划自然不甘寂寞，可視化編程興起了。
比如virtools和unreal就是這股浪潮中的佼佼者，這股浪潮並沒有持續太久。歷史的巨輪自會給出答案，virtools更是連骨頭都沒有留下。
5. 走向共和
程序猿又殺回來了。
於是引擎的定義在很多人心里，成了今天的樣子：
當前，引擎的定義就一個一個全功能IDE
美術可以在這里做視覺的工作，
策划和程序可以在這里做一些組合、測試游戲性
並且一些其它的工具也都可以整合進來，形成一整個工作的平台。
歷史的車輪滾滾向前，引擎的含義也一直在變化。虛幻，看上去很美。但在引擎的發展歷史中，他的理念已經落后了。
勝者U3D
引擎都有哪些功能
游戲引擎的發展過程中概念一直在變化，但是他的服務目標是不變的，輔助游戲開發。
基於此，游戲引擎基本的功能是必須要具備的。
如今的引擎已經是所有工作的整合平台，那么他的功能都應該整合在IDE中。
項目資源管理
作為一個IDE，首要功能就是整合所有的游戲資源，這包括代碼、策划數據表、美術資料等。
調試與發布
作為開發的最基本的環境，最主要的功能就是在IDE中試運行游戲，檢查功能是否符合預期，以及發布出獨立運行的游戲程序包
游戲基本功能
輸入是鍵盤鼠標觸摸屏手柄
輸出是圖像和聲音
這些基本功能具有高度的一致性，各個引擎提供的也基本差不多，不必多言。
游戲高級功能
UI、圖集、烘焙、導航、物理、AI等等
游戲開發中需要的功能可以說沒有盡頭，也沒有一個引擎可以說直接提供最好的附加功能，這只能稱為游戲引擎的特色。
游戲高級功能擴展
因為需求是無限的，游戲引擎的功能擴展性是一個很重要的指標。一個好的游戲引擎應該在不需要開發者觸碰引擎源碼的情況下，就可以進行附加功能的擴展。
游戲編輯器功能
首先上邊的很多游戲功能是需要編輯環境的，這就是IDE的工作。
IDE的擴展
同上，因為游戲功能沒有盡頭，游戲IDE中相關編輯器的功能也就沒有盡頭。
這同樣是游戲引擎很重要的指標，他也應該不要求開發者接觸引擎源碼。
從上述角度分析來看Unreal
優點：
1. 游戲高級功能集成的多，尤其是渲染效果，默認msaa，高質量的場景烘焙，優秀的反射系統。
2. 游戲編輯器功能豐富
缺點：
1.集成的東西太多學習成本高
2.集成的東西太多導致實際上限制比較多，Unreal更適合主視角這種沉浸式畫面，強行綁定了角色控制的概念，甚至局域網聯機同步這種設計，似乎都是為古老的FPS游戲為模板而設計的
3.資源管理尤其是代碼管理很不方便，開發效率較低。
4.擴展機制比較復雜，Unreal插件開發門檻高
再看U3D
1. 優點：
擴展性優秀，方便整合各種功能
2. 缺點：
沒有明顯的缺點
勝者：U3D
引擎使用的開發語言
對於引擎用的開發語言的要求，簡言之就是可低可高。
低就直接c/c++，可以取得很高的性能，精確的內存使用。
高就使用一門真正的高級語言或者腳本，安全、編譯迅速，易排錯，適合業務開發。
Unreal
低c++（但是有一套自己的反射實現，所以也是比較特別的c++）
高藍圖（太高了，直接去可視化編程了，不適合作為業務開發層）
Unity3D
低c語言（但是沒給出業務接口，c語言為泛指，任何能編出native dll 導出cstyle接口的語言都可以，因為沒有業務接口，直接用c語言寫業務邏輯很不方便，比如不方便操作場景中的物體）
高c#（理想的業務型語言）
Unreal 和Unity3D 在這里缺點都很明顯。
Unreal是高性能擴展，寫業務麻煩。
Unity3D是寫業務容易，想要高性能的擴展不好弄。
綜合來看，寫業務肯定更加重要，勝者U3D
渲染效果
因為很多人分析引擎，都喜歡拋出畫質論，這也是Unreal唯一勝出的點，因為Unreal默認的一套，不需要花很大力氣就能得到很好的畫質
一、久經考驗的烘焙系統
Unreal是做端游起家，GPU足夠，他們在渲染技術的積累非常雄厚，其中Unreal畫質的一大領先優勢就來自與他們這套久經考驗的烘焙系統，他表現非常優秀，即使在不使用貼圖的素模場景，也能弄出不錯的效果。
這個烘焙系統，U3D暫時還不能望其項背。
二、同樣久經考驗的可視化材質生成器
UE4的默認光照模型打眼一望和U3D 的standard材質相差無幾，實際上細節上還是更好一些，雖然u3d可以通過自定義shader做到完全一樣，但默認值，是不可忽略的因素。而U3D的standard不可擴展，而UE4的光照模型更底層，所有的材質編輯都基於這套光照模型，美術只是拖拽一下材質，就能得到一套優秀的材質。
U3D雖然也可以做到，默認值完敗
三、優秀的默認設定
UE4的默認配置 延遲渲染 抗鋸齒 HDR 場景反射 高精度 shadowmap, GI, 一應俱全。
Unity3D就像個屌絲。
四、其它黑科技
長期根植AAA游戲的Unreal 還有些其它的技術。
比如為超大地圖准備的虛擬貼圖，幾乎無限分辨率的超大貼圖，專門為超大場景編輯設計。
站在設計獅的角度談畫質Unreal毫無異議，地表最強
然而還是回來潑一下冷水，在目之所及的未來，運算量與發熱量之間的正相關都無法打破，移動平台AAA優勢的發揮始終會被限制。
引擎的CPU與內存
一個游戲引擎必然是資源消費大戶，但是有多大
空白項目簡單對比（就顯示一個box一個球，黑色背景unreal，藍色u3d,cocos就一個圖標）
Unreal cpu 10%,內存306MB
Unity3D cpu 5%，內存 135MB
Cocos2dx cpu 2%,內存 104MB
第三人稱項目 簡單實驗（場景都很簡單）
Unreal Cpu10%左右 內存335MB
Unity3D Cpu10%左右 內存 155MB
開源與否
開源從來不是問題，錢才是
源碼相關的主要有兩個點
1.擴展性，Unreal開源但零分，U3D不開源，但我給90分
開源的Unreal因為糟糕的擴展能力，導致擴展人力成本非常高。
而不開源的U3D因為優秀的擴展能力，導致擴展成本很低。
3. 排查底層BUG的難度
開源的Unreal自然擁有快速排查bug的機會。
Unity3D，付錢買源碼后可得同等機會。
黑粉時間
還是先拉張表格來對比一下
引擎 |
Unreal |
Unity3D |
假如自研 |
使用理念 |
服務美術設計師和游戲設計師，程序員躲在后台去做組件擴展。 |
全角色開發平台 |
全角色開發平台 |
基本游戲功能 |
齊備 |
齊備 |
齊備 |
高級游戲功能 |
整合的多 |
整合的少 |
整合的少 |
擴展性 |
很糟糕 |
很優秀 |
很優秀 |
業務開發 |
C++和藍圖，難用 |
C#，方便 c語言寫插件，不方便 |
C#或者c語言均可做業務開發 |
畫質效果 |
優秀，烘焙尤其優秀 |
默認慘烈，調整后可以優秀 |
無所謂 |
CPU與內存 |
高cpu，高內存 |
一般，mono使用不當容易引起高內存 |
使用Xamarin保證最新的Mono |
開源 |
開源，但是擴展性0分 |
不開源但是擴展性強，源碼可以買 |
全開源 |
其它費用 |
項目分成 |
正版授權 企業服務 源碼費用 |
無 |
簡單來算，Unreal不是一個適合手游平台的引擎。
U3D比較理想，主要的缺點有三個。
1. 要錢
2. Mono版本很低，且走il2cpp路線，不好好用c#
3. c語言不能直接開發業務邏輯，想往c/c++ 切換提升性能不方便。
假如自研的技術路線
1. 首先U3D在Editor的界面上使用IMGUI這種模式的UI，大大降低了編輯器UI的擴展編寫代碼數量，這里有開源的dear imgui 可以做到類似的效果。
2. 得益於dotnet的高效的編譯器，和動態加載技術。可以監測相應文件的變化，自動組織項目編譯。編譯成功后重新加載，可以實現editor擴展變更不停機重加載
3. 得益於dotnet所有異常均可捕獲的特性，在dotnet 層面的錯誤不會導致editor崩潰，大大提高了擴展開發效率
4. U3D 早期集成了Mono2.6，后來開始走上了IL2CPP技術，這個Mono版本太老
，可以使用微軟收購的Xamarin（Mono正版團隊）來替代Unity的方案，並且這個方案還可以直接c#真機斷點，方便很多。
5. Unity一部分核心代碼由C#寫成，造成內存的浪費很嚴重，（主要是因為Unity的早期Mono版本遲鈍的GC系統），自研引擎應以c語言構成核心代碼，c#是業務邏輯的一個選項，也可以完全不使用c#。
6. 跨平台渲染基礎庫可以用bgfx解決
中美關系緊張，准備個Unity3D的備胎，也是正常操作。
這里面涉及的 Imgui bgfx xamarin 甚至dotnet，都是開源項目，就算windows被禁止了，這套方案不受大的影響。