放弃Unity后，我为什么选择了Unigine？

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++啊
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！