一种基于Unity引擎的游戏资源检查方法和系统与流程

本发明涉及一种基于Unity引擎的游戏资源检查方法和系统，属于计算机游戏领域。

背景技术：

越多来越的游戏，尤其是手机游戏使用Unity引擎进行制作。由于手游戏开发周期相对较短，这对程序和美术要求非常高。要在有限的时间内，做好资源，整好到游戏，并且优化也要跟上。然而，如果前期美术资源没有做好，到后期，发现手机上效率低下，或者CPU、GPU消耗过多跑不动游戏，或者内存占用太多，游戏由于内存占用过大，出现频繁闪退。这时候就要去优化，优化其中不可忽略的一个重要因素便是资源管理。要去对各模块的资源进行检查，发现问题时，让美术进行调整，有些美术资源调整，会引起策划表格的调整；如删除某个特效资源时，数值表如特效表里的填的特效也要相应删除。这些工作，很繁琐，并且会消耗巨大的工作量，同时，还有可能牺牲游戏效果。另一方面，在游戏开发过程中，也有非常多的游戏bug，他们的产生，是由美术资源不按规范制作导致的。

技术实现要素：

针对现在的技术缺陷，本专利总结合当前游戏的工程和开发流程，提出了一种基于Unity引擎的游戏资源检查方法和系统，用于使用在游戏开发过程中，将不符合规范的美术和会影响性能的美术资源分析出来，同时，对可以批量修改的资源和数据表，进行自动修改，以达到方便查找资源bug，减少后期对资源的修改，提高开发的效率。

本发明的技术方案包括一种基于Unity引擎的游戏资源检查方法，其特征在于，该方法包括：A.对即将导入Unity引擎及已导入Unity的游戏资源使用对应的检查器进行分析、检查，进一步，执行对游戏资源的修改；B.若所述步骤A完成的游戏资源检查和修改不合格则在一定时间内对将导入Unity引擎及已导入Unity的游戏资源进行自动分析、检查，根据分析及检查结果自动提示、并使用日志记录，使用交互界面对日志进行展示，以及，提供修改界面对游戏资源的修改。

根据所述的基于Unity引擎的游戏资源检查方法所述步骤A还包括：S21，设置一个监测器对导入的游戏资源进行识别，当检测到有资源载入时，自动选择资源对应的检查器进行检查，其所检查的为游戏资源配置设置及规范要求；S22，对已存在的游戏资源进行进一步的分析，并使用对应的检查器进行检查，若检查到问题时，则生成问题对应的日志；S23，对已存在的游戏资源进行修改，根据游戏项目的不同对对应的设置进行修改。

根据上述所述的基于Unity引擎的游戏资源检查方法，其特征在于，所述步骤S22的检查包括但不限于：检查游戏资源的ARGB色彩模式所占比例、检查贴图尺寸、检查非二次幂贴图、检查模型的法线和切线是否导入、检查场景的资源是否交叉引用、检查资源集是否有冗余、检查动画压缩的选项设置以及统计贴图、动画、模型的数量和大小、ARGB贴图的数量。

根据上述所述的基于Unity引擎的游戏资源检查方法，其特征在于，所述步骤S22生成的日志还包括：当点击日志记录的问题时，自动跳转到有对应的问题资源，进一步，若日志记录的问题涉及修改数据表内容时，记录需要修改的数据表地址。

根据上述所述的基于Unity引擎的游戏资源检查方法，所述步骤S23的修改包括但不限于：检查以及修改角色层；检查与模型是否带入不必要的组件，根据游戏资源进行决定是否删除；检查以及修改生成中间贴图的选项；检查蒙皮网格渲染的设置；修改特殊资源的标志。

根据所述的基于Unity引擎的游戏资源检查方法，所述步骤B还包括：S61，基于所述步骤A的游戏资源的分析、检查和修改，创建自定义检查计划，在一定时间内对游戏资源进行检查，以及，还可以手动对游戏资源的检查；S62，使用统一日志接口对所述步骤S61的检查及修改进行级别划分，根据划分的日志级别进行对应的提示；S63，根据日志级别的提示对资源使用自定义设置的修改规则进行修改，并生成修改日志。

根据所述的基于Unity引擎的游戏资源检查方法，其所述步骤S62还包括：若不采用自动检查及修改则直接生成，则直接生成对应的日志。

根据权利要求上述任意方法的基于Unity引擎的游戏资源检查方法，该方法还包括：对游戏资源的检查均使用检查器进行检查，检查器为数据表配置文件，其中配置文件包括但不限于检查函数、额外参数、修改规则，进一步，检查器生成日志均需要调用统一日志接口。

本发明的技术方案还包括根据权利要求1-8任意方法的一种基于Unity引擎的游戏资源检查系统，该系统包括：资源检查模块，用于对即将导入Unity引擎及已导入Unity的游戏资源使用对应的检查器进行分析、检查，进一步，执行对游戏资源的修改；资源自动检查模块，用于当若所述资源检查模块完成的游戏资源检查和修改不合格则在一定时间内对将导入Unity引擎及已导入Unity的游戏资源进行自动分析、检查，根据分析及检查结果自动提示、并使用日志记录，使用交互界面对日志进行展示，以及，提供修改界面对游戏资源的修改。

根据所述的基于Unity引擎的游戏资源检查系统，该系统还包括：整合发布模块，调用资源检查模块，实现的各个资源检查规则，对出现问题的资源进行日志记录，通过邮件等方式发送至日志展示平台；检查器扩展模块，用于使用编辑界面对检查器的检查规则进行自定义修改。

本发明的有益效果为：将不符合规范的美术和会影响性能的美术资源分析出来，同时，对可以批量修改的资源和数据表，进行自动修改，以达到方便查找资源bug，减少后期对资源的修改，提高开发的效率。

附图说明

图1所示为根据本发明实施方式的总体流程图；

图2所示为根据本发明实施方式的自检流程图；

图3所示为根据本发明实施方式的详细流程图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。本发明的基于Unity引擎的游戏资源检查方法和系统适用于游戏资源的检查和修改。

图1所示为根据本发明实施方式的总体流程图。包括对即将导入Unity引擎及已导入Unity的游戏资源使用对应的检查器进行分析、检查，进一步，执行对游戏资源的修改；若上述步骤完成的游戏资源检查和修改不合格则在一定时间内对将导入Unity引擎及已导入Unity的游戏资源进行自动分析、检查，根据分析及检查结果自动提示、并使用日志记录，使用交互界面对日志进行展示，以及，提供修改界面对游戏资源的修改。

图2所示为根据本发明实施方式的自检流程图。一般项目都有每日构建计划，我们可以将这个模块加入每日构建计划，固定时间执行。当然，平时，我们手动进行打包时，也是可以加入这入检查。针对检查结果，我们可以分级，如分为：

（1）立刻，一旦发现，马上要修。因为不修，游戏会出错；

（2）紧急；

（3）一般错误；

（4）警告，发现比较紧急以上的问题时，检查模块，自动发邮件给相关人员，提醒他们资源有问题，需要及时处理，后面提交资源需要注意。

图3所示为根据本发明实施方式的详细流程图。包括检查与修改部分，以及，自动检查与修改部分。

检查与修改部分包括以下（1）-（3）：

（1）导入资源检查。当资源导入时，即将进行检查。如FBX的模型文件，一般游戏中需要检查：Import Materials(是否导入默认材质，unity引擎默认开启，但我们游戏实际情况默认不需要)、Read/Write Enable(模型数据是否可以读写，unity引擎默认是开启的，但游戏实际情况不需要开启)、Optimize Mesh (是否优化模型的数据，unity引擎默认是开启的，但游戏实际情况也是需要开启)， Normals(法线导入选项，默认是calculate Tangent Space,这个选项会在游戏中计算生成法线，对性能有影响，项目使用Import对性能更好)等等。但资源导进后，由程序，自动将相应的选择，修改成符合项目需求的美术规范。这些美术不用这些细节，可以大大提升美术提交资源的效率。

（2）对现有的资源，进行分析、检查。常见的检查有：

检查ARGB87mb。大概只有原图的17.5%。

检查贴图的尺寸，原则是不允许有大于1024X1024的贴图。

检查非2次幕的贴图。2次幂的图在压缩上会更省，计算也会更快。

检查是否是正方形的贴图。 在IOS环境，正方形的贴图，会进行优化处理，有更好的性能。

检查模型的法线和切线是否导入。法线和切线导入选项，默认是calculate Tangent Space,这个选项会在游戏中计算生成法线，对性能有影响，项目使用Import对性能更好。不过，不能直接修改这个选择，Import的选项，需要美术提交在资源上做好。

检查场景的资源是否交叉引用。如场景A，使用场景B的资源，这种会给后面美术资源带来很大的麻烦。如场景B删除后，场景A也会跟着出错。

检查AssetBundle资源是否有冗余。如贴图A,分别打到了AssetBundle包B和包C，即打了2份，到时，加载包B,C时，内存存了2份贴图A.

动画Animations的Anim.Compression 选项，即动画的压缩选项，压缩后，动画在内存会占用更小。一般项目选择压缩，即：Keyframe Reduction.

统计贴图、动画、模型的数量、大小、ARGB8贴图的数量大小等，以供优化进行

当检查出问题后，我们除了输出日志，还可以加入一些小细节：如点中日志，会自动跳转到具有问题资源。又如当资源修改，涉改改数据表时，再相应的表名及路径，也打印出来，方便使用人员。

（3）对现在的资源，进行修改。这一步对工作的效率提高很有意义，但每个项目具体的需求不一样。需要根据具体的设计来定。常见的修改有：

检查与修改角色层。在unity里的layer层。通常角色资源，会单独指定为player层。不过，默认时是default 层。

检查与模型是否带入不必要的组件。如Unity导入模型时，默认mesh会附带Animator组件，而很多项目通常会程序单独管理模型的动画播放，也有少量的剧情由美术管理时，才需要用到Animator组件，这时Animator组件的Controller值不为 NULL。所以程序可以判定Animator组件的Controller为NULL时，将这个组件删除。

检查与修改贴图的:Generate mip Maps 选择。开启这个选项，会增大此图约33%包的体积以及内存。项目通常会选择不开启这个选项。

Skinned Mesh Render 的Receive Shadows选项。默认所有的模型均不开启，只有地表(地面)的模型才开启。故可以根据这特点批量修改。

特殊资源的标志的修改，如需要在内存中动态合并贴图时，贴图需要开启：Read/Write Enable.

并且，可以根据项目后面发现的问题，扩展以及添加检查规则。第二模块：自动检查流程整合。这个模块，主要整合资源检查的功能进来，以便资源检查可以按计划执行，方便查看结果。

一般项目都有每日构建计划，我们可以将这个模块加入每日构建计划，固定时间执行。当然，平时，我们手动进行打包时，也是可以加入这入检查。针对检查结果，我们可以分级。

自动检查与修改部分，包括以下（1）-（4）：

（1）日志管理

统一日志的输入接口，以便后面可以灵活控制。相关接口伪代码参考如下：

Log(int Level, string info, Color color, bool isNeedSendMail ) 其中：

Int Level值为日志的输出等级。值参考为：

1立刻。一旦发现，马上要修。因为不修，游戏会出错。

2 紧急。

3 一般错误。

4 警告。

String info:为日志的输出信息，记录哪些文件，出了什么错；或哪些文件进行了哪些修改。

Color color:输出日志的颜色值。

Bool isNeedSendMail:是否需要发邮件通知。

（2）导入资源检查

继承自unity的：UnityEditor.AssetPostprocessor,这个类，提供了一个重要的成员变量：string assetPath，这个变量记录刚导入的资源的路径。可以取得刚导进资源的路径。

然后重写AssetPostprocessor的部分接口，进行我们需要修改的项的值。

如导入模型检查，重写：AssetPostprocessor.OnPostprocessModel(GameObject)，然后，通过AssetImporter 改写导入的模型的数据：

AssetImporter tmpAsset = ModelImporter.GetAtPath(path);

tmpAsset .optimizeGameObjects = true;

其次AssetPostprocessorp这个类还提供了API操作audio clip、贴图、动画等的导入事件回调，以及添加删除资源的处理回调：AssetPostprocessor，同理，我们只需要重写这些接口，修改资源，以符合我们的规范，中间如需要记录日志统一调用记录日志接口。

（3）对现有的资源，进行分析、检查、修改

此模块，一般涉及目录管理。即部分规则专利针对具体目录而写。为了方便管理规则，添加规则，修改规则，本专利使用配置表管理规则。配置表格式参考：

参数说明：

Checkid:检查的id，不重复。

CheckFunction:检查、统计、修改资源用到的函数。需要具体实现。这里配表管理，方便针对不同的目录，使用重复的函数。

DirPath:检查或修改的目录。

IsSendEmail: 是否需要发邮件。

ExtraPara:函数需要额外的参数，如检查动画压缩CheckAnimationCompression时，过滤掉 idel的动画，不要检查与处理。

IsAutoModify:当检查出问题，是否直接修改。

然后，逐一实现每条检查功能，提供一个接口调用所有的检查规则，同时，将提供手动点单独的菜单，执行相就原命令，中间如需要记录日志统一调用记录日志接口。

（4）整合到发布流程

一般项目会布署自动发布平台，以提交发布的效率。在发布开始时，提前调用资源检查模块，即（3）里实现的各个资源检查规则，有问题，会写到日志，以及发现有需要发邮件时，调用相应的发邮件接口。

以上所述，只是本发明的较佳实施例而已，本发明并不局限于上述实施方式，只要其以相同的手段达到本发明的技术效果，都应属于本发明的保护范围。在本发明的保护范围内其技术方案和/或实施方式可以有各种不同的修改和变化。