Unity一直在搞事相信大家都知道，特別是unity.cn，之前都還在我的容忍范圍之內，直到上半年他們事實性的宣布不會支持Unity 6之后，我就決定換引擎了。

至于換哪個引擎著實挑選了一段不短的時間（實際上我“物色”引擎從23年Runtime Fee事件之后就開始了）。首先被排除的是Unreal，這玩意兒我玩不起。之后我在幾個支持C#的引擎里面挑選，最后鎖定在三個引擎上面：Stride，Flax Engine和Unigine。

Stride是第一個被排除的，它的編輯器壓根就沒法正常運行，窗口拖動了一下直接崩了，第一印象非常壞。實話實說我不知道現在的Stride修好了這個問題沒有，至少我今年是沒有再嘗試過的。

在Flax和Unigine之間我糾結了很久。我真的很喜歡Flax的代碼設計（能看到源代碼絕對是個加分項）。可惜最終有幾個決定性因素讓我選擇了Unigine：

• Flax用cm（厘米）而不是m（米）作為基本單位，只是這樣倒還好，但間接導致了物理引擎的數值變得特別的怪，實際使用中很容易填錯。Unigine沒有這個問題。
• Flax的編輯器至今仍然有一些小毛病，比如界面過于簡陋，比如Alt+LMB（鼠標左鍵）環繞聚焦對象的功能是半殘的（滾輪動一下就會失焦），而我又是個會經常Alt+LMB的人。Unigine沒有這個問題。
• Flax的引擎工具鏈不全。比如地形和植被編輯比較原始，沒有水，沒有云。Unigine全都有，特別是Unigine的云，比我在Unity市場里買到的還要漂亮。
• Flax的音頻系統很原始，它的Roadmap上倒是準備更新一個新的音頻系統，但根本不知道什么時候會有，我也不打算繼續等了。Unigine的有點像老版本Unity音頻系統的功能強化版，比Flax的要好不少，實在不夠用它還自帶了FMOD的整合。
• Flax沒有Imposter，對于我想做的游戲（有大量的高速運動小物體）是個麻煩事。雖然說沒有這東西影響其實沒那么大，但Unigine是有的，而且不久前還更新了一次，現在效果完全不輸Unity那邊的Amplify Impostors。
• Flax的調試仍然需要通過編輯器來進行，這點和Unity很像。但Unigine創建的項目直接就是一個標準的C# MSBuild項目，你完全不需要啟動編輯器，直接Visual Studio里面F5就能調試運行了，省事了不止一星半點（想要加載哪個場景就在Debug的啟動參數里直接指定）。同時也是因為它是標準的MSBuild項目，那些能用在普通C#項目上的東西，比如nuget，各種第三方工具什么的都可以直接用，對于我這種C#粉是絕對的加分項。
• Flax的編輯器Asset管理是Unreal式的，我不喜歡。而且Flax對于Runtime DLC沒有任何支持。在Roadmap上有，但我也懶得等。Unigine的編輯器Asset管理和Unity如出一轍，雖然對Runtime DLC沒有直接支持，但它的運行時打包和資源管理模式非常的簡單明了，DLC什么的直接把資源文件打包成usc包扔進data目錄里去就行了（甚至直接扔zip進去都可以，你甚至可以先扔到別的文件夾然后手動選擇是否將其mount到它的虛擬文件目錄里）。我一直覺得Unity的Addressable是把簡單問題復雜化了，Unigine用了幾個函數就給了我一直想要的東西！

當然Flax也有很多優勢，比如它的C++/C#混合編程做的非常棒（可能是我見過的引擎里面做的最棒的，沒有之一），Unigine建立了C#項目后，也能繞個圈子用C++，但就比較麻煩。不過我對這方面基本沒什么需求，PInvoke級別的支持就足夠我用了（能寫C#誰寫C++啊??）。

相比于Unity和Flax，Unigine的劣勢還是有的，主要這幾個方面，得一個一個來解決：

• GUI。Unity有UI Toolkit，雖然我不喜歡它的設計但好歹用了這么久也用熟了。Flax的有點類似老的Unity UI的進化版，也是可以直接上手的東西。然而Unigine的Runtime GUI就有點復古了。不過我現在整合了Myra進去用，這個問題也就讓我繞過去了。之后會有文章講解如何將Myra整合到Unigine。
• 編輯器擴展，就是Unity放在Script文件夾里的那些操作。Flax對這方面的支持和Unity很接近（部分功能上都有點接近Unity的第三方插件Odin了），看一下文檔就能直接上手。而Unigine則比較……嗯，“傳統”，你需要以插件的形式來制作擴展，而Unigine的編輯器是基于Qt的，也就是說你得寫一個C++ Qt插件。好在Unigine也只是拿Qt搭了個殼子，并沒有用到太深入的東西，QtWidget也不復雜，花了兩天時間學了下就會玩了，上手之后確實不難。之后會有文章講解如何在Unigine里面用QtWidget制作編輯器擴展，繞過Unigine那套GUI。
• ECS。這個Flax和Unigine都沒有，不過我準備用Friflo.Engine.ECS了。說實話Unity那套DOTS感覺就是他們的開發者對于一直卡在老Mono上無法前進到.net core的現狀絕望了之后搞出來的東西。當然現在他們神功大成之后準備把整個引擎都ECS化，這一點我還是很喜歡的。
• 網絡。Unigine沒有對網絡提供任何支持，所有東西都得手搓。我有過手搓MMORPG網絡層的經驗所以這倒不是個大事，就是有點麻煩。然而我現在懶得再搞一次（畢竟不打算做MMORPG），準備直接用LiteEntitySystem。
• 輸入系統。我很喜歡Unity新的Input System，這東西Flax那邊有一個較為原始的版本，Unigine則完全沒有，還是和老Unity類似的那一套。只能自己搞了。好在這個不難。
• 動畫。Unigine一直以來缺乏一個像Unity/Flax那樣好用的動畫系統。好在開發者也知道這個問題，最近幾個版本都在完善他們的新動畫系統，現在用起來有點像Unity的第三方插件Animancer。只不過沒有UI多少還是麻煩一些。
• 粒子系統有點原始，比Unity的老粒子系統（Shuriken）功能還要少一點，跟VFX Graph更是沒得比。而Flax的粒子系統已經能摸到VFX Graph的屁股了。
• 沒有硬件光追。這點倒還好，現在光追對顯卡的要求還是有點高，我暫時也沒打算搞一個會把玩家電腦弄爆炸的游戲，而以Unigine一貫的對渲染質量的追求來看，加入硬件光追支持是遲早的事。
• Unigine最大的劣勢：社區太冷清了。畢竟是個冷門引擎??，網上的資料也很少，導致有些問題哪怕去問AI也得不到靠譜的回答。好在它的文檔很全面，甚至有離線的.chm版本可以下載（就是條目組織的有點亂）。Flax雖然熱度也是遠不如Unity，但它的Discord頻道很熱鬧，頻道里的老哥老姐們也很熱情。
• Unigine第二大的劣勢：只支持Windows和Linux。選擇了Unigine基本就等于放棄了移動平臺。而主機平臺，我看引擎的C++ Header里面有PS5/XBSX的define了，估計也是準備支持的，就看什么時候做好了。好在我現在對這方面目前沒有太高的需求。

最后是幾個Unigine獨有的優勢，也是讓我下定決心用它的地方：

• 渲染效果和運行效率。我認為Unigine的渲染效果是好于Unity HDRP的，而且運行效率也高于HDRP。雖然比URP還是要差一點，但Unigine提供的東西比URP多太多了，特別是光、影、霧、水和云，我要再吹一遍：Unigine的云是我見過的最漂亮最真實的云。我用第一視角在它的云里面飛進飛出，換各種云，來回飛，真的玩了一天。考慮到這引擎的出身，這一點倒是不奇怪。
• 全面的double精度坐標支持。有多全面呢，連物理引擎都是有針對性的優化過的，上手即用無需額外代碼。Unigine沒有用PhysX，而是用的自己的方案，所以能做到這一點。你在Unigine里面真的是可以直接編輯整個恒星系的，非常離譜，它這雙精度坐標支持搞不好是業界最好的。
• RTGI，這個Flax也有，甚至我感覺效果比Unigine還好一些，但運行效率是Unigine這邊更高。Unity那里的RTGI要么你開硬件光追，要么就得用快被淘汰的Enlighten方案（實際上也確實被標記過Obsolete一次，后來在用戶的強烈要求下又加了回去）。要么就得去Asset Store里打獵，終歸是沒有引擎原生支持的好。
• DLSS 4 + FSR 3.1.3。同樣省去了去Unity Asset Store打獵的功夫和金錢。Flax的FSR還停留在1.0版本，也不知道啥時候能更新，DLSS倒是更新到了3.1，不過比起Unigine還是落后了。
• 整合了自動LOD生成和自動Imposter生成，進一步省去Asset Store打獵的功夫。
• 騷到不行的MicroProfiler，直接給你開了個本地HTTP服務器，Profile的時候用瀏覽器連接上去就能看各種measure數據了。不過實話實說，Flax那邊整合了Tracy，API方面也更簡潔，其實要更好用一些。
• 非常直觀的Asset管理模式。這個前面提到過了。
• .NET 8。以及和原生C#體驗基本一致的C#編輯/調試體驗，這個前面也提到過。
• 官方提供了一個Unity導入插件，雖然并沒有100%兼容Unity的東西（也不可能全兼容），但整個場景布局都可以導過去，節省了很多時間。
• 最后，普通版本免費，Pro版本固定金額的收費模式，沒有什么Runtime Fee之類的爛活！也不需要利潤分成。

當然我也并沒有放棄Flax。哪天要做個移動平臺項目的時候我會毫不猶豫的打開Flax??。