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

作者:顾煜 专栏: 2018-05-22

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。

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

最新评论
暂无评论
参与评论

商务合作 查看更多

编辑推荐 查看更多