虚幻，看上去很美
对不起，这是一篇有立场的文字，以我的心性，绝对的客观是做不到的。
我尝试放下现有方案和项目历史，就去假想一个适合自己情况的理想化的手游引擎（后文均简称为引擎），他应该是什么样的。然后再来看看如今流行的方案 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被禁止了，这套方案不受大的影响。
