The world at your fingertips — 天涯明月刀幕后17（资源管理2）

一元

文/顾煜 专栏：https://zhuanlan.zhihu.com/gu-yu

前文回顾：The world at your fingertips — 天涯明月刀幕后16（资源管理1）

我们基本讨论完了资源的效率问题，然后我们要看看资源的组织管理方式。

有几种不同的方式管理大量资源文件。

最简单的方式是离散的文件管理，每一个资源都是一个独立的小文件，放在目录中。这样管理模式的坏处，就是对资源管理工具不太友好，上传地图和其他数据的时候，往往需要上传一大堆数据文件，操作复杂度和出错可能都比较大。更进一步说，这样会造成下载版本、上传版本、copy版本以及游戏加载效率偏低，因为大量的小文件是磁盘IO的性能杀手，当规模大了以后，一个简单的copy或者loading地图，都会很慢，且很难提速。 但简单的系统，也有好处。好处之一是对Merge友好，多人协作的时候，如果不小心同时改了几个文件，至少大家还有一起Merge的可能性，能逐个文件检查哪些文件有冲突。另一个好处这个模式比较轻量，不需要太多的编程支持，文件系统天生就支持这个，很适合精益的开发流程。

稍复杂一点的系统，会从优化大量的零散文件出发，将文件做简单的打包，提供虚拟文件系统，封装了散落各地的小文件，变成几个大的虚拟文件。这类文件系统实现比较复杂，往往需要在editor或者特定的工具中打开才能看其中的内容。而且考虑到多人协作，会更复杂，资源包要可以部分增量更新，要有版本管理系统的集成，便于大家日常工作在版本管理工具上。这样的系统，对同步、copy版本非常友好，两三个文件就是一个版本的全部，管理版本速度非常快。但除此之外，好处也寥寥，之前用过一个in house的引擎，大文件的管理不够健壮，一直会出错，经常工作一段时间，整个大文件经过了几次sync，莫名其妙就损坏了，开发者对大文件损坏最是喜闻乐见。他们一边假装抱怨，一边愉快地开始从版本库中重建完整的大文件，并且在等待之余刷起了网页小说。

Unreal是一个高度工程化的引擎，对大规模团队合作考虑很多。于是Unreal引擎做了一些折中，使用了资源的package方式，把大量类型相同或者是逻辑上相关的资源，放进了一个个package，以package为基本文件单位来管理。至于package内部的资源，可以通过引擎的编辑器来进行浏览管理。这个方式是一个妥协，通过合适的文件粒度管理，来尽量确保大家的工作内容不要冲突。这个方法既有上面各种流派的优点，也继承了它们所有的缺点。只是优点不那么突出，因为Package的规模变小，但缺点也不那么明显了。

不管怎么做，大项目管理资源的方式都非常复杂，现代引擎往往还分成开发期的资源管理以及运行期的资源管理，用不同手段管理，适应开发阶段需要的灵活性以及发布版本需要的高效率。

没有万能的技术方案，所以在基础的技术流程外，所有的项目，都会努力制定一套针对开发者的工作流程，对目前资源管理体系的缺点，找一些操作的流程方案，规定了多人协作时候，大家操作使用数据的规范、顺序，大家的改动通知方法。合并友好的文件系统还好，开发者只要强调合并时候的检查和流程即可。不容易合并的文件，就要通过合理安排每个人工作范围，修改文件的流程，来确保大家尽可能减少冲突。

最后一个话题是资源的格式问题。很多时候资源的格式决定了工作和思考方式。不同格式的表现力不一样，协作流程也不同。专用格式，比如图像领域的贴图等，我们可以直接用，对于国内策划最喜欢用的表格，我们尝试了一些有趣的做法。

我希望天刀的主要格式都是基于对象层次结构的XML文件，XML表现力足够强，可以表达对象的各种层次，结构、数组等复杂的编程概念也可以一一对应，和我们的底层逻辑一样。一致性会带来很多好处，底层逻辑一致，开发效率就足够高，将来的整体优化也会更容易一些，减少工作量，提升效率。但策划天生喜欢用表格，理由也很充分，表格可以用Excel来处理，可以做各种公式和二次开发，这个是XML没法做到的。

策划黄教授给出了一个有趣的方案，希望XML和Excel可以互相转换。那些配置文件的XML，含有很多Meta信息，指示我们的Converter该如何转换这个表格到excel格式。我又写了个Excel插件，把excel表格再转换成我们需要的XML文件。在一套统一的规则的指导下，策划就可以比较容易的进行来回的转换。但Excel文件和XML文件的描述能力并不等价，XML的层次结构是Excel文件无法表达的。于是我们做了一些取舍，策划用的表格只转换并行逻辑关系，也就是表格那部分，所有逻辑层次关系都藏在Excel的某个字段，我称之为模板的地方，在今后需要转换回来的时候直接恢复，不做任何修改。

有了这个体系，策划只需要根据规范设计表格，我们的整个工作流中，只接受XML的上传。但策划工作中，他们可以随时把XML转换成Excel文件工作，在Excel里面调整完所有的表格后，导出XML上传即可。相当于Excel文件只是一个中间格式，在我们的工作规范中，我们保证这个格式可以和XML互相无损转换。引擎只使用最终的XML文件，确保多人协作的Merge友好性。

即使是这样的表格，在后期还是碰到了不少问题，虽然XML是可以Merge的，但并不方便，当大量策划需要工作在一样的表格上的时候，每次上传都需要Merge，想来也是令人沮丧。于是策划希望我们能分割表格，这个并不难做，一个表格可以有多个文件，每个策划工作在一个文件上，引擎启动的时候一起读进来就好了。这个方案有点像补丁，但很实用，轻松解决我们的难题。

程序员有着不一样的追求，希望一切有序和谐。另一个团队做过一套复杂的工具，把表格的编辑细化到行。针对每一行单独可以编辑上传，这样冲突的概率大大减少。相当于把原先的基于文件的冲突复杂度，降低到基于行的冲突复杂度了。在斗战神那个项目中中应用良好，于是我也希望能用到我们的游戏中。

但这个系统遭到了我们策划的强烈抵制，因为这个系统还是改动了他们的工作流程，无法使用Excel工作了，Excel的公式和宏扩展都不能做，要去这个工具里面做，这让策划非常恼火。虽然降低了冲突概率，但易用性和开发效率也降低了很多，最终我们还是没有能推行这套系统。再好的设计理念，也敌不过易用性的缺失，怎么顺畅的切入现有的工具体系，尽量保证大家能无缝切换，是工具开发需要自己考虑的。

探讨完各种资源的话题，最后用天刀的资源文件组织做一个简单的收尾，也是综合了各方面的考虑，分别考虑开发期和运行期。

以地图数据举例，开发期我们非常简单的使用了零散的XML文件，用来表示地图中的各种object。XML的好处是描述性足够好，可以表达出对象之间的引用关系、层级关系，也可以表达各种复杂类型的数据。同时，XML文件是Merge友好，确保了我们在早期工具不完善的时候，减少数据出错的机会，即使出错，必要时候也可以人力阅读修改XML文件来定位问题和修复问题。这个数据格式一直伴随了我们的早期开发，有时候编辑工具来不及写，大家也就用文本工具直接修改XML了，效率低了点，但至少还能快速看见工作效果。

随着进一步的开发，XML的解析效率成为一个问题，加载完XML，重新解析以及生成游戏中需要使用的内容，都是一个开销很大的工作。但是XML对于开发期的确有很多便利性，于是我们对运行期的资源文件格式做了一些调整，开发了XML的二进制化，把XML二进制化以后，顺手也把解析的操作Streaming化，这样加载资源文件的速度大大增加。但所有二进制的文件，并不作为上传数据，平时版本库中存放的还是XML，确保可Merge性，方便大家协作工作。

后续为了进一步加速运行期效率，也提升策划美术上传地图资源的易用性，我们又把有相关性的一些XML单独打包，生成类似package文件的中型规模的文件。这个应用场合主要是关卡数据，关卡文件通常都一起出现，在一个目录里，方便打包。打完包以后，管理这些文件变得更容易。打包了以后必然降低可阅读性，对这些文件进行调试找错也更麻烦。好在打包格式也是很简单的压缩格式，如果有bug，直接在原地把文件解压缩了，就又回到了一堆XML文件，可以容易的查找Bug。

天刀的整体框架是随着引擎的不断成熟，以及项目的进展，才逐渐成型的，早期的纯文本、不打包文件，慢慢过渡到后期的二进制、小规模打包，都是反映了开发流程中的不断取舍。所有的看见的切片，都是过程，引擎开发永远没有结果，我们也在随着产品变化，不停思考如何更好的管理资源。