![]()
在游戏发展的数十年间，游戏画面也在逐渐发展。从最早的像素风格到如今几近真实的渲染画面，游戏美术已经成为游戏中表达情感、渲染氛围、吸引用户的重要手段。
本文以unity项目为例，介绍了一些针对美术资源的精准测试手段以及在项目内的实际落地经验。
在游戏发展的数十年间，游戏画面也在逐渐发展。从最早的像素风格到如今几近真实的渲染画面，游戏美术已经成为游戏中表达情感、渲染氛围、吸引用户的重要手段。美术资源一般先由美术提交到美术目录，再由程序处理、制作以后提交到项目的工程目录，最终打包到游戏中得以展现（有些组可能没有进行美术目录和程序目录的区分）。游戏中常见到美术资源有原画、UI、贴图、模型、动作、动画、特效、场景等，美术资源之间相互引用互相整合，才能够制造出一个完整的游戏世界。随着技术的发展游戏中的画面越来越精致，各类美术资源的数量也在急速上升，为了控制包体的大小，游戏中的美术资源会加以复用。以倩女手游为例，一棵树的模型可能既出现在公共场景中，又可能出现在玩家的家园中；一张贴图既可能出现在玩家身上，也可能出现在npc身上；一段代码既可以控制灵兽变色，也可以控制玩家时装的变色。美术资源的复用有效控制了包体、成本等但在资源修改时也增加了测试的复杂度以及影响和范围。美术资源的复用增加了美术资源之间的耦合性，使得美术资源之间的依赖关系更加的复杂；同时也可能出现牵一发而动全身的情况。基于此种情况，我们需要对美术资源的依赖关系进行整理，方便定位修改的影响范围。通过依赖关系的建立，可以精确定位到每个资源修改时所影响到的资源范围，在方便测试、缩减测试工作量的同时也可以避免测试遗漏。资源的引用关系具体可分为直接依赖和间接依赖。如图中的A.prefab和x.mat之间的依赖关系是直接的依赖关系，A.prefab和o.npg和k.png的依赖关系是通过x.mat建立起来的，属于间接依赖关系。Unity中有获取资源依赖的接口Assets -- Select
Dependencies，具体操作为在编辑器里面选中某一个资源后右键，在弹出的菜单栏中选中Select
Dependencies即可获得该资源的依赖情况。
图 3 在Unity中获取资源的依赖关系结果，即该资源包含的所有子资源图4 代码中调用接口获取资源的依赖关系，返回是一个字符串的组合通过select dependencies接口可以获得资源的所有依赖关系（即资源依赖哪些其他资源），但没有直接的接口可以获得资源的被依赖关系（即资源被哪些其他的资源所依赖）。需要获取资源的依赖关系需要同时获取资源的依赖和被依赖关系，因此我们需要获取资源的被依赖关系才可以快速获得资源之间完整的依赖关系。
对于任意一个资源，需要获得其依赖和被依赖的关系，需要遍历项目的全部资源才能获取完整。若需要获取多个资源的被依赖关系也需要重复这样的操作，耗时且重复繁琐。针对这种情况，我们需要记录资源之间的依赖关系。通过遍历一遍工程中的所有资源，建立起资源之间的依赖和被依赖关系，关系具体存储在数据库中。在通过接口获取资源的依赖关系的时候，也反向记录下资源的被依赖关系。如下图，在记录资源A的依赖关系（x.mat， o.png k.png）的同时，也记录这些资源被A依赖的关系。用一张表记录项目中的所有资源及对应的guid，同时记录资源大小，资源更新版本，资源是否被删除，资源是否是顶级资源等信息。有一点需要说明的是，在记录资源依赖关系的时候我们去掉了直接依赖和间接依赖的区别，只记录资源是否依赖和是否被依赖，并不关心资源之间的调用顺序。主要是考虑到若记录资源之间的调用顺序，在获取资源所有依赖和被依赖关系时会频繁的进行递归操作，对于查找依赖关系不太方便。同时资源之间的调用顺序无法通过接口直接获得，需要对资源进行文本分析或者依赖关系的二次分析。去掉资源的间接依赖关系更方便建立数据库，也方便查找。但去掉资源依赖顺序的做法也有一定的弊端，具体可以看依赖资源关系维护部分中对修改资源的依赖关系维护。美术资源之间的依赖关系，以及资源本身经常会发生变化；依赖关系建立起来以后需要维护否则很可能出现资源依赖关系的错乱。资源的依赖关系可以跟着项目工程的提交来更新。
对于更新频率来说，间隔时间越短涉及到影响的资源越少，更新起来的干扰也就越小，但是如果每有一次svn提交就进行一次更新，这样子基本要占用一台机器（差不多时时都要开启Unity）对于机器来说比较浪费。因此目前采用的方法是每天更新三次，这个频率是和打包频率一样的，大家可以根据每次提交中的依赖关系来进行当前包体的资源测试。资源更新的时间也会和打包的时间错开，既不影响打包还可以增加打包机的使用率。同时每次更新时维护的资源更新列表也和当前版本号的包体是一致的，这样方便保证大家在测试的时候资源关系和包体上表现的一致性。为了增加每次资源依赖关系更新的速度，对每次更新时需要进行更新的资源进行了二次筛选。先从svn中拉取指定两次版本号之间的资源更新列表，对于一些多次提交的资源进行合并处理，如先提交再删除的这种资源虽然出现项目的目录中，但是并没有被打进包里面去，因此直接删除；对于先修改再删除的资源对于目录最终的影响是删除，因此直接按照资源被删除去记录等。资源文件一般还有一个以meta为后缀的同名文件，该文件一般会记录资源的guid（资源全局唯一的标识符）和一些导入信息。Meta文件中guid通常不会改变，它的改动一般不会影响资源的依赖关系，更新时会略过meta文件的分析来减少需要进行分析的资源量。但为了预防meta文件中guid被误修改导致依赖关系断开，我们会统一对guid的改动做一个监控。对于新增资源A，分析并记录资源A的依赖关系；同时对于所有A依赖的资源，新增并记录这些资源和A之间的被依赖关系。对于删除的资源D，更新资源D的状态为0（被删除）；同时对于D所依赖的资源，断开这些资源和D之间的被依赖关系。这里不去更新D被依赖的那些资源，这些资源正常情况下应该会修改主动断开和D之间的依赖关系，若没有主动断开很可能是一个误删除（如一个mat被删了，但是另外一个prefab还在引用它，那这样子在游戏中就很容易出现洋红色）。对于被修改的资源M，相当于先删除再被新增，同时操作上述两个步骤，更新修改资源的依赖关系。这里还要做一步额外的操作，所有M被依赖的资源也会加入修改资源的列表中，进行处理。（这里就是去掉资源依赖顺序以后的一个弊端，若资源M的引用关系发生了变化，从依赖X.mat变成了Y.mat，则所有M的被依赖资源们均需要更新这一关系，因为这些资源在查询的时候不会通过M获取这一变化，会直接从数据库中获取其所依赖的资源，若不更新则会出现依赖X和不是依赖Y这一误差。）整体来讲，资源的更新离不开新增、删除和修改这三个操作，难点在于一些比较特殊的操作需要考虑全面。具体比如说，一个资源N在第一个版本删除了，后面发现是误删以后需要恢复资源，对于美术来说只要把资源N再提交回来就可以了，但是对于资源依赖关系来说在删除的时候把资源的依赖关系全部断掉了，现在一定要把这些依赖关系和被依赖关系全部找回，否则就会出现关系网的断裂；或者说资源的guid发生了变化，对于资源来说guid修改以后资源的引用关系就会断裂，这种情况也需要特殊考虑进去。依赖关系建立好以后，获取资源的依赖关系就很简单了，在数据库中进行一下操作，就可以获取资源的依赖和被依赖的关系。对sql语句进行一下包装，就可以轻松对在脚本或者页面中调用。
图7 脚本中根据资源名获取guid，根据guid获取资源依赖和被依赖关系对于一些比较底层的资源，资源的被依赖关系可能非常复杂，并会存在一些中间资源。它们也不会以某个单独实例的样子出现，对于大家在测试时也无法单独观察这些中间资源而是要通过这些中间资源被依赖的顶级资源进行测试。对于这种资源可以做一次隐藏，通过判断是否是顶级资源再来进行显示。是否是顶级资源的判断也非常简单，根据资源是否有被依赖来判断，若资源没有被任何其他资源所依赖，则认定为是顶级资源，一般会直接加载游戏场景或者界面中。图8 在svn平台显示时只会过滤掉部分中间资源mat除此之外，还可以通过依赖关系的数据库获取一些其他的信息。如资源的当前状态，资源的更新时间，一些没有被引用的冗余资源等。依赖关系的建立最初的想法是帮助定位每一次资源改动所影响到的资源，避免有一些资源的改动会影响到其他资源。依赖关系的第一个应用就是和svn的提交相结合，每个提交的资源都可以定位到一些可能影响游戏表现的顶级资源（图8）。单一的资源名和策划表中id可能会过于抽象，对部分资源存储了资源的缩略图，也会在平台上点击资源的时候进行展示。项目工程的资源现在是程序自动提交，一次自动提交包含了几次甚至十几次美术提交；一次提交可能会对应到几位不同同学的测试内容，需要手动拆分。现在和svn平台合作进行了资源提交的自动拆分，可以根据提交单时的refs和对应的美术资源目录进行映射，映射后自动进行拆分和分割。图9 自动拆分比较理想的情况，大部分全部自动拆分出去，只剩一个提交需要人工拆分提交单随着项目资源的增多，控制项目包体，删除冗余资源是一项长期且必要的工作。资源之间相互依赖，删除一个还在被依赖的资源，很有可能会对游戏的表现有所影响。删除资源的检查可以自动进行提醒，方便大家在进行资源测试的时候有重点的进行测试。具体做法是在每次更新完资源的依赖关系以后，遍历一遍当前资源改动列表里面被删除的资源，并对资源被依赖列表中的资源进行检查。若资源中依然还在依赖这个被删除的资源就进行报警。有些比较关键的资源修改时影响的资源范围广泛，此时会进行二次提醒，增加大家对这些资源的重视。一般是一些shader文件，会出现在很多材质中，在进行改动的时候影响范围也会比较大。对于数据库中的顶级资源进行筛查，若没有被策划表或者程序代码中引用，则很有可能是冗余资源可以删除。部分代码数据也是通过资源引用的方法挂在美术资源上面的，如变色脚本等。通过代码和资源的依赖关系，在代码进行改动时列举其被依赖的资源进行测试。图11 染色相关的c#代码的改动也会影响到游戏中资源的表现美术资源的精准分析的初衷是希望定位一个资源的影响范围，避免过度测试和遗漏测试，在实际使用中发现对资源数据库的分析还可以实现其他的功能。代码的可移植性整体比较高，Unity的项目基本可以平移过来，非Unity的项目可以复用整个框架，修改核心的分析接口即可。在结果展示上svn提交平台的同学也帮忙开发了一套通用的接口可以直接调用。希望上面的文章可以对你有所帮助，也欢迎大家来一起讨论！
![]()
![]()
基于DNN实现的使用策划局内战斗策略的最强阵容预测分享
你是最好的QA
接口测试快速上手指南
![]()
都看到这里了，点个赞再走吧~