从unity引擎切换到虚幻引擎

首先声明，我和其他团队成员仍然是Unity的粉丝。我们团队从Unity 3.X版本开始使用该引擎（包括职业许可证），并持续将其应用于各种项目。即便到今天，如果要开启一个新的项目，我依旧会考虑选择Unity。

我们在基于Unity引擎的原型项目ExtroForge上取得了显著进展，设计并集成了大量游戏元素。我们拥有丰富多样的资源存储包，以及多年积累的在线文章、博客和教程。团队中有至少两位拥有15年软件工程经验的专业人士，在Unity环境下，我们的开发高效且熟练。

然而，当项目推进到一定阶段，我们遇到了一个关键瓶颈——多人网络。团队成员此前有使用Unity建立多人项目的经验，采用了第三方工具（如RakNet、SmartfoxServer）和内置功能。但ExtroForge项目有一些特定需求，包括权威服务器逻辑、服务器端物理和逻辑碰撞，以及高性能要求（特别是ExtroForge的FPS和RTS部分）。我们最初尝试使用内置网络进行多人原型开发，同时也关注了一些第三方选项。我们满怀期待地等待着Unity 5+的网络功能——UNet的替代品。

但第一次迭代的结果令人失望。文档极其有限，性能也不稳定。简单的复制动画模型（位置/旋转）功能无法正常工作，或者会出现严重的延迟。我们积极尝试，查阅论坛帖子，耐心等待官方教程，但始终未能如愿。一些用户制作的教程视频也未能解决问题，我们最终决定等待未来版本。后来，Unity发布了路线图，将独立仿真的服务器实现推迟到2016年3月（还包括其他元素的定义），这促使我们开始考虑其他选择。

当我们首次启动虚幻引擎的项目时，惊喜随之而来。在“播放”按钮下方的小侧菜单中，我们可以自动启动一个非专用服务器，还能根据需要启动多个“额外”玩家客户端，这简直是多人游戏开发的理想状态。

需要说明的是，我们的决策并非仅仅基于引擎的多人功能。我们花费了大量时间研究世界、地形、树叶和水等元素的表现方式。团队/工作室负责人负责项目的外观和感觉，他发现使用Unity开发的结果看起来过于卡通或“粘土状”，因此开始评估其他游戏引擎，以确定能否更快地达到期望的效果。

在评估过程中，我们考察了CryEngine。它的画面十分精美，但要让团队适应这样一个社区规模较小、学习成本较高的引擎并不现实。而虚幻引擎则能够快速实现我们所需的外观和感觉，并且我们对其用户社区、文档和工具集（包括蓝图）更为熟悉。

在通过一些示例项目和原型阶段的验证后，我们确信能够在虚幻引擎中实现期望的视觉效果，同时保证多人游戏的稳定性和可扩展性。考虑到Epic在多人FPS领域的卓越表现，我们最终做出了切换到虚幻引擎的艰难决定。毕竟，我们有大量基于Unity的代码和内容（包括基于程序网格的体素实现），并且熟悉Unity的开发方式和C#语言。蓝图和C++的引入让我们犹豫了一段时间，但最终还是迈出了这一步。

C#、C++与蓝图

ExtroForge团队具备一定的技术深度。高级工程师们早年在C和C++领域有丰富经验，后来转向管理工作，主要使用Java和C#。团队其他成员也在不同高级语言方面有复杂的经验，熟悉面向对象和基于组件的设计。C#与Unity配合良好，操作GameObject及其相关对象对我们来说已经驾轻就熟。

起初，虚幻引擎的蓝图概念让我心生畏惧。因为团队中没有人有过视觉脚本的经验，缺乏比较的基准。我在Unity中使用有线预制件时曾有过糟糕的经历，容易丢失重要设置。我更习惯在代码中设置重要值和参数。但基于多年的软件开发经验，我相信我们能够重拾C++技能并开始新的开发。

让我感到鼓舞的是，虚幻引擎提供的大部分启动示例项目都有蓝图和C++两个版本。然而，这种鼓舞并未持续太久。由于虚幻引擎的低门槛，吸引了大量“业余爱好者”，网络上有大量关于使用蓝图完成实际任务的教程、论坛帖子和视频，但关于C++的资源相对较少。

在实际开发中，我遇到了不少问题。即使在C++方面取得了一些小成功（如实现自定义结构体/类来体现体素世界），但在某些领域（如RPC调用）使用这些自定义结构体/类时却遇到了困难。我可以通过添加适当的宏或命名来解决编译错误，但RPC调用仍然会产生空结果。此外，在运行时动态获取资源（如网格、材质或蓝图）的技术在独立非编辑器构建中也会出现问题。我查阅了大量文章，尝试了各种技术，但仍然无法在C++运行时动态获取这些资源。

后来，一位资深团队成员开始连接一些蓝图功能，将骨骼第一人称角色BP与我正在开发的C++类结合起来。创建小盒子、拖动小电线，这些操作让我着迷。大多数与输入/控制以及GUI元素/UI相关的内容，使用蓝图似乎是更好的选择。我开始自己尝试使用蓝图处理材质逻辑，惊讶地发现可以在几秒钟内轻松完成在Unity中需要编写着色器代码才能实现的功能。虽然我的核心代码仍然使用C++，但我们逐渐学会了从C++暴露变量，以便在蓝图中根据需要进行输入和访问。

枚举也是一个让人头疼的问题。我们的游戏中有很多底层元素使用枚举来表示各种类型，如建筑类型、体素类型和资源类型等。将这些枚举转换为适合蓝图使用的格式并不容易，需要使用一些古怪的技术。在蓝图中，枚举有时需要转换为字节，有时又不需要，这导致编译时会出现大量错误。我们尝试关闭编辑器并重新打开来解决这些问题，但目前还没有找到一个完美的工作流程。

随着开发的推进，我们越来越熟练地将C++和蓝图结合使用，甚至创建了自定义蓝图节点。我们逐渐爱上了蓝图及其开发过程，认为它们非常适合游戏开发中的某些元素。对于玩家角色的行动逻辑，我们认为没有必要将其迁移到C++中。

资产管理

虚幻引擎的资产管理相对成熟。将文件拖入编辑器或复制到资源文件夹通常可以正常工作，将资源转移到不同目录也只需简单的拖拽操作。包的导入/导出功能（除了一些依赖关系方面的小问题）表现出色，甚至可以通过编辑脚本来编写自定义逻辑来管理资源。

然而，我们在使用虚幻引擎进行资产管理时也遇到了一些痛苦的经历。部分问题是由于我们自身的无知和缺乏经验，但仍有一些问题原因不明。将内容从一个项目迁移到具有不同目录结构的另一个项目时，会浪费大量时间。使用虚幻引擎提供的工具迁移基于C++类的蓝图更是一场灾难，C++类无法直接迁移，需要手动复制并更改类名，而迁移后的蓝图会永久引用原始类，无法修改。在编辑器中移动内容也会导致文件副本残留、子文件夹为空以及各种引用破裂（有些无法修复）的问题。相比之下，Unity的关键资源数据库可能会损坏，但Unity会自动检测并修复问题，而虚幻引擎需要手动处理这些问题。

在资源存储方面，Unity经过多年发展，已经建立了一个大型且繁荣的商店，提供各种免费、低价和高价的资源，质量参差不齐。作为几个Unity商店资源的作者，我对内容创建和销售过程（特别是支付环节）感到满意，在Unity中查找和导入新内容也相对轻松。而虚幻引擎的市场规模较小，内容的“平均”价格更高。我们尚未有在虚幻引擎商店出售或购买资源的经验，必要时会使用资源或启动器创建内部内容。

程序操纵网格

Unity提供了开箱即用的网格数据操纵能力，包括从头创建或操作现有网格。顶点、顶点颜色和UV等数据都可以方便地访问，并且文档详细。多年来，我在各种项目中多次使用这些功能，如地形变形、网格破坏/压裂等。在ExtroForge的体元建设引擎中，这些功能也发挥了重要作用，表现出色且速度快。

当我开始使用虚幻引擎（大约4.7版本）时，惊讶地发现其“正式”版本中缺少这些功能。地形变形不被支持（至少使用内置的景观类时如此），要获取地形高度数据，只能在编辑器中通过跟踪/射线检测地形高度。虽然论坛上有一些聪明的开发者创建并发布了自己的代码库来实现基本的程序网格建设和操纵，但这些代码并不完善。

到了4.8版本，虚幻引擎发布了“实验性”的ProceduralMeshComponent，缩小了与Unity的差距。我们能够在虚幻引擎中实现体元程序网格技术，但也遇到了一些问题，如移动程序网格组件可能会导致物理对撞机出现问题。4.9.X版本进一步增强了这些功能，并且看起来会继续改进。尽管虚幻引擎在某些方面（如操纵现有网格模型）仍与Unity存在差距，但已经在朝着正确的方向发展。

照明

虚幻引擎为我们的项目引入了大量出色的开放世界照明工具。虽然Unity通过启发引擎推出了实时全局照明功能，但在开放世界中，其结构添加和删除的灵活性仍然有限。

虚幻引擎的距离字段阴影和环境闭塞功能可以以近似的方式遮挡远处的物体，从远处看效果非常完美。使用光传播体积，我们可以创建发射材料暴露到附近几何形状的项目，效果非常棒。虽然这些功能目前被列为“实验性”，需要在引擎设置属性文件中启用，但到目前为止表现良好。相比之下，在Unity中，远处的物体看起来比较平淡，难以实现远处山脉在山谷中投下阴影的效果，除非设置非常大的阴影距离。

开放世界工具

在Unity中，我们使用自定义逻辑动态生成地形高度、添加纹理和树叶等元素，效果相当不错。但在虚幻引擎中，使用内置景观元素时无法在运行时修改地形高度，这让我们有些失望。

不过，虚幻引擎提供了一些补偿性的功能。我们可以使用新的程序性开放世界工具，为某些地形纹理随机分配草和植物，使世界看起来更加郁郁葱葱、充满活力。新的程序树叶放置工具可以基于规则轻松创建整个生态系统，虽然我们在完全实现动态世界生成方面还有很多工作要做，但我们期待迎接这些技术挑战。

各种特性和功能

在4.6版本之前，Unity的UI系统比较混乱，低效的内置系统被一些优秀但相对昂贵的第三方资源所取代。Unity 4.6之后的新UI系统表现良好，提供了开发人员可能需要的几乎所有功能。

虚幻引擎的UMG系统与之类似，提供了强大的UI特性，并且可以通过蓝图和代码进行操作。在我看来，蓝图是连接UI逻辑和流程的完美机制。我们在这个领域没有遇到重大问题，只是对小部件组件（允许将UI小部件附加到3D资源）标记为“实验性”有些担忧，但目前使用情况良好。

虚幻引擎的AI行为树和知觉特性在Unity中没有直接对应的功能，除非使用第三方资源。我曾尝试过一些第三方资源，但通常最终还是会自己在C#中实现有限状态机（FSM）或分层任务网络（HTN）/目标导向行动规划（GOAP）。虽然我们在虚幻引擎中对AI功能的实验还处于初步阶段，但它提供了一种快速添加基本原型人物和生物AI的方法，无需手动创建大量基础设施。

最后一点

在使用Unity的过程中，我曾遇到过一些关键错误，影响了一些手机游戏的启动和运行。我们在很大程度上受制于Unity的发布/更新周期。虽然虚幻引擎也存在一些bug，但它提供了源代码。如果遇到关键错误或需要添加引擎不支持的功能，我们可以自行跟踪问题并进行修复。

ExtroForge团队已经对引擎代码进行了分叉，并添加了逻辑，使得我们可以为程序创建的网格添加多个UV集。这解决了体元逻辑中的一个关键障碍，使我们能够通过材质应用体元的健康、伤害和权力信息，而无需浪费CPU周期。能够以这种方式调整引擎令人兴奋，我们也期待着将4.9.1版本的更新干净地合并到我们的引擎代码中。

尽管已经切换到虚幻引擎一个多月，但我们仍然对Unity怀有深厚的感情，并且会持续关注其在多人网络和其他关键引擎功能方面的进展。未来，我们将有更多机会对Unity和虚幻引擎的其他元素进行比较。