您不是订单管理的定向开发者_游戏引擎随笔 0x01：资产管理

评判一个引擎先进与否的一个重要指标就是资产管理（Asset Management，以下简称 AM），也称资源管理。根据引擎的运行环境不同，AM 可分为以下 2 种：

1. 离线资产管理（编辑时）Offline Asset Management 简称 OAM，主要包括资产的创建、导入、编辑、引用关系管理等。
2. 运行时资产管理 Run-Time Asset Management 简称 RAM，主要包括资产的加载、卸载、以及使用等操作。

这次我们先聊聊 OAM。

资产导入管理

从创建方式视角来看，资产可分为两大类：

1. 导入资产，DCC 产出的内容，需要导入到引擎中生成引擎可识别的数据格式方可使用，常见的有用于制作模型和动画的 3dsMaxMayaXSI、制作贴图的 PhotoshopSubstance、制作音频的 GoldWave 等等。另外还有一些特定的 DCC 内容，比如制作地形的 World Machine、制作服装的 Marvelous Designer 等等。
2. 原生资产，指的是由引擎自身的资产内容创建工具创建，例如：材质、特效、动画、UI、AI、预制、关卡、自定义资产等等。

对于导入资产，每个引擎有各自不同的管理方式，Unity 将 DCC 源文件也纳入到资产管理之中，这样做的好处是，只要有 DCC 源文件和对应的导入描述元数据，就无须对导入后的资产进行版本管理，而且开发者操作的是 DCC 源文件，比较直观。坏处也显而易见，当开发团队达到一定规模时，无论是否需要，在版本控制时都会更新 DCC 源文件，这样会造成内容巨大的 DCC 源文件导入会非常耗时，严重影响团队协同开发效率，另外一个副作用是游戏项目的版本控制库会越来越大，也不利于项目管理。而 UE 则与之相反，引擎管理的是导入后的资产，DCC 源文件可以单独进行版本控制，与引擎的资产管理分离，对于开发团队来说，则不必每个人更新后都重新导入一遍，提高了协同开发效率。但这种方式也有一定缺点，导入后的引擎资产中记录了 DCC 源文件的路径，如果 DCC 源文件路径变化，则无法自动重新导入，需要手工维护 DCC 源文件和导入后的引擎资产之间的关系。

这里单独说一下纹理资源，纹理资源的特殊性在于图形 API 相关的纹理格式，一般情况下，普通意义上的纹理格式比如 bmp、tga、png、jpg 等都不会作为直接用于最终渲染使用的数据，每个图形 API 都提供各自的硬件纹理格式，以提高渲染时的性能（显存大小、总线传输带宽、采样性能等），这就要求在最终资源打包时，要将原始纹理格式纹理资源转换成图形 API 对应的硬件纹理格式。要实现这一点，需要引擎自身的纹理资产带有原始纹理数据，这里还是以 Unity 和 UE 为例来说明。Unity 已经将 DCC 源文件纳入到资产管理，所以在打包时直接转换即可。UE 虽然没有管理 DCC 源文件，但是将原始纹理数据在导入引擎时放在对应的 uasset 资产文件中保存，这样在打包时也可读取相应的原始纹理数据进行转换。除纹理之外，还有几种硬件格式相关的资产，比如音频、视频等，处理方式和纹理相似。另外还有一种资产和图形 API 相关：Shader ，不同的图形 API 的 Shader 语法不同，这也是一个比较复杂的话题，如果要论述清楚的话需要单独开篇来讲，这里简单说下 Unity 和 UE 的处理方式，两者都是用同一种描述方式编写 Shader，最终打包时转换成对应图形 API 的格式，区别在于 Unity 使用自己发明的 Shader 描述语言，UE 则使用 HLSL 语法 。

在实际的开发中，导入到引擎中的一般并不是真正的 DCC 源文件，比如纹理，尽管可以直接将 PSD 放在引擎中或者直接导入，但一般情况下导入的是已经经过一次加工处理之后的 导出文件，在 PS 中将 PSD 导出成 TGAPNG 等格式，再将 TGAPNG 文件导入到引擎中。而模型动画的 DCC 源文件更是如此，必须要经过 DCC 导出成 FBX 文件之后才能再导入到引擎中（上古时代的引擎一般都提供 DCC 导出插件，随着 FBX 等通用格式的兴起和不断完善成熟，目前来说，除非极特殊情况，FBX 足以满足游戏的需求了），因此像 Unity 那样将 “DCC 源文件”纳入到资产管理并没有太大意义，毕竟这个所谓的源文件并不是真正的原始美术文件。而 UE4 的方式由于只管理导入后生成的资产文件，可将 DCC 源文件和游戏资产的版本控制管理分离，提高协作开发效率。

资产引用关系管理

OAM 另一项重要工作是维护资产之间的引用关系。我们都知道资产之间必然存在着引用关系，正是这种引用关系，为呈现出复杂多样的游戏表现提供了数据基础。最简单的引用管理就是完全人工维护，引擎不做任何自动的维护工作，但很明显这早已不符合现代游戏的开发需求，所以需要引擎提供自动化的资产引用关系管理系统。资产引用关系中一个主要解决的问题是当资产路径变更时（重命名或者移动到其它路径），如何保持原有的引用关系。由于资产在游戏开发过程中经常变化，因此现代游戏引擎基本上都具有自己特定的资产引用关系管理机制。这里还是以目前主流的两大引擎 Unity 和 UE 为例来说明。Unity 的资产关系管理方案是给每个资产定义一个 GUID，资产之间的引用通过 GUID 来完成。Unity 给每个资产都创建了一个 .meta 文件，这个文件中包含的最重要的数据就是 GUID。而 UE4 采用的是资产路径，引用一个资产就是使用这个资产的路径。这两个引擎都要求在修改资产路径时都要在编辑器中操作，不能在编辑器外部通过操作系统文件系统操作，否则会导致引用关系的丢失。但实际上如果只是移动路径，Unity 是可以在编辑器外操作，前提是将资产以及资产 .meta 文件同时移动，即可保持完整的引用关系，而这一点 UE4 是无法做到的。但 UE4 在编辑器层面维护资产的引用关系上做得更加完善，比如在删除资产时，如果有引用关系存在，会弹出窗口提示，并且提供引用替换功能，还提供了方便的引用关系查看器让开发者直观看到引用图。通过这些编辑器资产操作功能上的差异可以看出，UE 确实是经过无数大型项目历练的引擎，这些功能都是在开发过程中实际遇到问题的解决方案。

由于 Unity 使用 GUID 作为资产的引用关系，这就必然需要额外的资产描述源文件，也就是 .meta 文件，同时还需要一个包括全部资产的资产注册数据库，用来映射 GUID 到真正的资产。这种方式增加了资产管理的复杂性。UE4 以资产路径作为 GUID，优势在于引用直观，易于理解，不需要引入其他的辅助数据。但当资产路径变化时，需要额外的处理工作。UE4 的解决方法是在原路径下生成一个原名的重定向资产，这样所有引用者都无需改动，通过重定向即可正常获取引用的资产。但这样也带来一些麻烦，重定向有一定的性能开销暂且不说，最终还是需要人工在引擎中修正重定向，增加了管理成本，而且这种修正会导致所有引用者自身的修改，当引用者数量很多时，影响面比较广，所以需要在项目初期规划好资产路径，减少改动带来的管理成本。

除了 Unity 和 UE4，还有其他的引擎的资产管理方案，比如 xenko，使用的是 Unity 和 UE 相结合的管理方式，但也有其管理上的问题。还有比如 利用文件摘要简化游戏资源的引用管理，也是一种解决特定问题的资产管理思路。但正如软件工程中没有银弹的规律那样，没有哪个游戏引擎的资产管理系统是完美的，所以在设计引擎的初期，需要仔细权衡，分析利弊，做出最适合自己引擎的选择。