CN109977022A - 游戏资源的检查方法、装置、***及存储介质 - Google Patents

Abstract

本发明提供一种游戏资源的检查方法、装置、***及存储介质，该方法，包括：在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程；通过资源检查进程查询预先配置的资源错误分类表，得到待检查的pre‑commit类错误；按照待检查的pre‑commit类错误对应的检查逻辑，对游戏资源进行检查；若存在pre‑commit类错误，则生成错误提醒信息；若不存在，则向所述版本控制服务器提交所述游戏资源。本发明可以缩短资源检查的时间，有效提高检查效率。

Description

游戏资源的检查方法、装置、***及存储介质

技术领域

本发明涉及数据处理技术领域，尤其涉及一种游戏资源的检查方法、装置、***及存储介质。

背景技术

大型游戏开发项目往往开发人员众多，开发人员之间一般通过SVN、Git等类似版本控制工具进行协同工作。其中，游戏开发最主要的内容是资源的生产，例如：场景、模型、特效、贴图等美术资源的制作，策划数据表配置以及游戏逻辑程序代码的实现等等。对于一个游戏项目，资源文件有着类型繁多、数量庞大、占用存储空间多、提交修改频繁等鲜明特点。因此，在开发过程中需要对开发人员提交的游戏资源进行检查，以避免游戏资源错误影响游戏的正常运行。

目前，开发人员在提交游戏资源前，都会在本地机器上手动安装检查工具，然后通过运行检查工具来检查资源错误，若发现错误，则提交失败，向开发人员反馈错误信息。

但是，当提交的游戏资源较多时，采用这种方式会使得检查运行时间变长，开发人员需要等待较长的时间才能够得到检查结果，影响开发效率；并且，这种方式依赖开发人员自觉配置本地环境，无法进行统一监管，可靠性不足。

发明内容

本发明提供一种游戏资源的检查方法、装置、***及存储介质，可以缩短资源检查的时间，有效提高检查效率。

第一方面，本发明实施例提供一种游戏资源的检查方法，包括：

在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程；

通过所述资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误；

按照所述待检查的pre-commit类错误对应的检查逻辑，对所述游戏资源进行检查；

若存在pre-commit类错误，则生成错误提醒信息；

若不存在pre-commit类错误，则向所述版本控制服务器提交所述游戏资源。

在一种可能的设计中，若存在pre-commit类错误，则生成错误提醒信息，包括：

若存在pre-commit类错误，则在终端的显示界面上显示检查到的错误信息，并提示游戏资源提交失败。

在一种可能的设计中，向所述版本控制服务器提交所述游戏资源，包括：

在所述游戏资源对应的日志尾部添加根据预设算法生成的数字签名，得到签名后的日志；

将所述签名后的日志和所述游戏资源发送给所述版本控制服务器。

在一种可能的设计中，在向所述版本控制服务器提交所述游戏资源之后，还包括：

接收所述版本控制服务器的反馈信息，所述反馈信息用于通知所述终端游戏资源是否提交成功；

若接收到游戏资源提交成功的反馈信息，则在预设时长内等待远程检查端反馈的错误报告；

在终端的显示界面上按照预设格式显示所述错误报告；所述错误报告包括：post-commit类错误。

第二方面，本发明实施例提供一种游戏资源的检查方法，包括：

接收终端提交的游戏资源，以及所述游戏资源对应的签名后的日志；

对所述签名后的日志进行解析，得到对应的数字签名；

将所述数字签名与预先存储的参照签名进行比对，若比对结果一致，则将所述游戏资源发送给远程检查端，并向所述终端发送反馈信息，用以通知所述终端游戏资源提交成功；

若比对结果不一致，则向所述终端发送反馈信息，用以通知所述终端游戏资源提交失败。

第三方面，本发明实施例提供一种游戏资源的检查方法，包括：

接收版本控制服务器发送的游戏资源；

对所述游戏资源进行任务分解后，投递至任务管理器；

查询预先配置的资源错误分类表，得到待检查的post-commit类错误；

按照所述待检查的post-commit类错误对应的检查逻辑，对所述任务管理器中的任务进行检查；

若存在post-commit类错误，则生成错误报告，并将所述终端反馈所述错误报告；

若不存在post-commit类错误，则完成游戏资源的提交。

在一种可能的设计中，对所述游戏资源进行分解后，投递至任务管理器，包括：

通过预先训练的BP神经网络对所述游戏资源进行任务分解；

将分解得到的任务，按照队列形式投递至任务管理器。

第四方面，本发明实施例提供一种游戏资源的检查装置，包括：

触发模块，用在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程；

查询模块，用于通过所述资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误；

检查模块，用于按照所述待检查的pre-commit类错误对应的检查逻辑，对所述游戏资源进行检查；

提醒模块，用于在存在pre-commit类错误时，生成错误提醒信息；

发送模块，用于在不存在pre-commit类错误时，向所述版本控制服务器提交所述游戏资源。

在一种可能的设计中，所述提醒模块，具体用于：

若存在pre-commit类错误，则在终端的显示界面上显示检查到的错误信息，并提示游戏资源提交失败。

在一种可能的设计中，所述发送模块，具体用于：

在所述游戏资源对应的日志尾部添加根据预设算法生成的数字签名，得到签名后的日志；

将所述签名后的日志和所述游戏资源发送给所述版本控制服务器。

在一种可能的设计中，还包括：接收模块，用于：

接收所述版本控制服务器的反馈信息，所述反馈信息用于通知所述终端游戏资源是否提交成功；

若接收到游戏资源提交成功的反馈信息，则在预设时长内等待远程检查端反馈的错误报告；

在终端的显示界面上按照预设格式显示所述错误报告；所述错误报告包括：post-commit类错误。

第五方面，本发明实施例提供一种游戏资源的检查装置，包括：

接收模块，用于接收终端提交的游戏资源，以及所述游戏资源对应的签名后的日志；

解析模块，用于对所述签名后的日志进行解析，得到对应的数字签名；

比对模块，用于将所述数字签名与预先存储的参照签名进行比对，若比对结果一致，则将所述游戏资源发送给远程检查端，并向所述终端发送反馈信息，用以通知所述终端游戏资源提交成功；

反馈模块，用于在比对结果不一致是，向所述终端发送反馈信息，用以通知所述终端游戏资源提交失败。

第六方面，本发明实施例提供一种游戏资源的检查装置，包括：

接收模块，用于接收版本控制服务器发送的游戏资源；

分解模块，用于对所述游戏资源进行任务分解后，投递至任务管理器；

查询模块，用于查询预先配置的资源错误分类表，得到待检查的post-commit类错误；

检查模块，用于按照所述待检查的post-commit类错误对应的检查逻辑，对所述任务管理器中的任务进行检查；

反馈模块，用于在存在post-commit类错误时，生成错误报告，并将所述终端反馈所述错误报告；若不存在post-commit类错误，则完成游戏资源的提交。

在一种可能的设计中，所述分解模块，具体用于：

通过预先训练的BP神经网络对所述游戏资源进行任务分解；

将分解得到的任务，按照队列形式投递至任务管理器。

第七方面，本发明实施例提供一种游戏资源的检查***，包括：存储器和处理器，存储器中存储有所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行第一方面中任一项所述的游戏资源的检查方法。

第八方面，本发明实施例提供一种游戏资源的检查***，包括：终端、版本控制服务器、远程控制端；其中：

所述终端用于执行如第一方面中任一项所述的游戏资源的检查方法；

所述版本服务控制器用于执行第二方面所述的游戏资源的检查方法；

所述远程控制端用于执行如第三方面所述的游戏资源的检查方法。

第九方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面中任一项所述的游戏资源的检查方法。

本发明提供一种游戏资源的检查方法、装置、***及存储介质，通过在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程；通过资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误；按照待检查的pre-commit类错误对应的检查逻辑，对游戏资源进行检查；若存在pre-commit类错误，则生成错误提醒信息；若不存在，则向所述版本控制服务器提交所述游戏资源。本发明可以缩短资源检查的时间，有效提高检查效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一应用场景的原理示意图；

图2为本发明实施例一提供的游戏资源的检查方法的流程图；

图3为本发明实施例提供的资源错误分类的划分规则示意图；

图4为本发明实施例提供的错误提醒信息的示意图；

图5为本发明实施例提供的提交日志信息的示意图；

图6为本发明实施例二提供的游戏资源的检查方法的流程图；

图7为本发明实施例三提供的游戏资源的检查方法的流程图；

图8为本发明实施例提供的任务管理器的任务分解流程图；

图9为本发明实施例提供的任务分解的示意图；

图10为本发明实施例提供的并发资源检查的结构示意图；

图11为本发明实施例四提供的游戏资源的检查方法的流程图；

图12为本发明实施例五提供的游戏资源的检查装置的结构示意图；

图13为本发明实施例六提供的游戏资源的检查装置的结构示意图；

图14为本发明实施例七提供的游戏资源的检查装置的结构示意图；

图15为本发明实施例八提供的游戏资源的检查***的结构示意图；

图16为本发明实施例九提供的游戏资源的检查***的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

以下，对本申请中的部分用语进行解释说明，以便于本领域技术人员理解：

1)游戏资源：具体指游戏开发中涉及的三类资源，包括各种美术资源文件，场景、模型、特效、贴图等，程序开发的脚本逻辑代码以及策划配置的策划表。

2)pre-commit检查：是指在开发人员将制作的游戏资源尝试进行提交时触发的检查逻辑，不管最后是否成功提交，检查逻辑都会在本地执行。

3)post-commit检查：是指开发人员将制作的游戏资源成功提交到版本控制服务器之后触发的检查逻辑，提交成功之后触发检查，因此并不会因资源错误而阻止提交。

4)HMAC：是密钥相关的哈希运算消息认证码，HMAC运算利用哈希算法，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。

5)BP(back propagation)神经网络：是一种按照误差逆向传播算法训练的多层前馈神经网络。

6)Gearman：一种分布式任务架构。

大型游戏开发项目往往开发人员众多，而且很多是远程协作，开发人员之间往往通过SVN、Git等类似版本控制工具进行协同工作。同时游戏开发最主要的内容是资源的生产，包括场景、模型、特效、贴图等美术资源的制作，策划数据表配置以及游戏逻辑程序代码的实现。对于一个游戏项目，资源文件有着类型繁多、数量庞大、占用存储空间多、提交修改频繁等鲜明特点，特别是对于大型网游，工程项目资源量往往达到100GB的量级，而且存在多个分支并行开发。

游戏项目在开发前都会根据游戏类型、游戏目标用户设备性能分布等制定详细的项目规范，包括美术资源规格标准以及程序代码规范，保证资源的规范性。具体来说一般项目在美术资源方面都有着严格的标准，比如游戏场景贴图的大小、贴图模型是否缺失、特效等级是否超标、lightmap是否缺失、角色骨骼数是否超标、特效粒子数是否超标等等。美术资源不按标准制作会导致游戏的各种性能问题，最后资源返工制作造成成本巨大浪费，更严重的是部分资源错误还会导致游戏崩溃，问题定位和修复需要占用测试人员大量时间，造成开发进度受阻，因此项目中对美术资源进行检查非常必要。同时游戏的脚本代码书写规范也十分重要，比如变量命名规则、注释规则、缩进规则等，对于大量开发人员共同维护的游戏项目，代码的可读性、规范性能有效降低bug率和开发人员代码阅读的成本，减少低级错误，提高开发质量。同样道理，策划配表的正确性也非常关键而且极易出错。游戏开发过程中，对上述游戏资源的检查和监控必不可少。

目前，开发人员在提交游戏资源前，都会在本地机器上手动安装检查工具，然后通过运行检查工具来检查资源错误，若发现错误，则提交失败，向开发人员反馈错误信息。

但是，当提交的游戏资源较多时，采用这种方式会使得检查运行时间变长，开发人员需要等待较长的时间才能够得到检查结果，影响开发效率；并且，这种方式依赖开发人员自觉配置本地环境，无法进行统一监管，可靠性不足。

针对上述技术问题，本发明提供一种方法，在不影响开发人员体验的前提下，采用pre-commit本地检查和post-commit远程检查结合的方式，从而实现了一方面不会对游戏资源仓库产生污染的目的，另一方面做到***安全可靠、高效的识别所有资源问题，使得游戏资源仓库的所有资源问题处于测试人员的监控之下。同时，采用基于BP神经网络建立模型对任务评估，细化任务划分粒度，充分利用分布式架构的优势，极大提高检查效率。图1为本发明一应用场景的原理示意图，如图1所示，体设计框架可以分为三大部分，包括：

第一部分是终端，即开发人员本地，也就是pre-commit部分。项目组管理人员通过ssh等方式向所有成员定向推送安装资源检查工具。在开发人员每次向游戏项目的svn服务器申请提交资源时，会自动触发资源检查进程。该进程会去查询配置好的资源错误分类表，得到需要检查的pre-commit类错误，然后根据写好的检查逻辑对申请提交的资源进行逐一的检查，一旦发现有pre-commit类型错误，则反馈错误信息给用户，并且提示提交失败。同理如果检查通过，则在玩家提交的日志尾部加上一段用给定的算法生成的数字签名，并且将提交请求发送至svn服务器。

第二部分是版本服务控制器，即游戏资源svn仓库，也就是svn服务器端。在收到用户提交资源的请求时，首先进行提交日志的解析，然后用同样的算法得到数字签名去和玩家日志中的签名进行比对，签名一致则提交成功并反馈给用户，如果签名不对则提示用户其本地未安装检查工具并且本次提交失败了。如果有资源提交成功，那么随后svn服务器会触发post-commit的检查请求，发送到远程资源检查端。

第三部分是远程控制端，即远程资源检查端，也就是post-commit部分。收到svn服务器的检查请求信息后，远端资源检查***会根据输入数据基于BP神经网络训练得到的模型进行任务的分解及投递，按任务队列的形式投递到任务管理器，Gearman分布式架构中的检查进程在任务管理器中提取检查任务，然后查看资源错误分类表，逐一检查post-commit类型的错误，将错误报告发送给开发人员并且存储进mysql数据库。还包括资源错误的报告web，可以查看当前所有问题以及历史报告，根据错误类型进行分类展示。

应用上述方法可以可以缩短资源检查的时间，有效提高检查效率。

下面以具体地实施例对本发明的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。

图2为本发明实施例一提供的游戏资源的检查方法的流程图，如图2所示，本实施例中的方法可以包括：

S101、在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程。

本实施例中，终端的本地资源检查工具移入的目的是需要让所有开发人员在执行svn-commit提交资源时，自动触发hook的一段检查代码。svn客户端提供了可配置界面，可以通过设置pre-commit脚本达到目的。现有技术需要用户手动配置比较麻烦而且重新安装svn、开发人员本地环境、***改变后设置会失效。该方案依赖用户自己去安装配置，没有强制性因此效果也不好。本实施例仿照svn客户端commit指令，重新封装svn-commit操作，封装后的commit会先执行一段自定义的pre-commit检查脚本，然后将必要参数传递给原生的svn-commit执行提交。为了达到重新封装的目的，在Linux下通过设置alias别名的方法，将svn commit操作指向一个提交的shell脚本。

具体地，在本地的L i n u x账户下v i m～/.b a s h r c，添加/project_path/localhooks/commit脚本代码。保存更改后执行source～/.bashrc使得更改生效，这样开发人员在本地文件夹执行svn commit时，实际调用执行的是～/project_path/localhooks/commit下的脚本。项目管理员可以通过配置parallel-ssh(PSSH)环境，拥有对各开发服务器密钥认证访问权限后，对指定IP列表内的所有机器进行批量配置，这样就实现了将检查逻辑hook到svn commit过程中的目标。然后在～/project_path/localhooks/commit脚本中实现一个shell脚本接收svn commit传入的参数，包括log、提交文件列表名称，先执行pre-commit检查逻辑，然后根据检查结果返回错误或者提交成功。

S102、通过资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误。

本实施例中，可以制定了一个涵盖所有资源错误的分类表，在执行资源检查时根据分类表来确定在pre-commit和post-commit阶段分别需要具体检查哪些内容。通过分类表这种形式，较好的将检查规则和***检查流程分离，开发人员可以方便的修改配置，根据实际需要进行调整。比如在开发过程中某个错误类型A原先是放在post-commit阶段进行检查，实际后来发现这个类型错误会导致严重问题阻碍开发，希望能够在源头上禁止提交，此时开发人员只需要修改一下分类表，将错误类型A划分到pre-commit即可达到目的。在pre-commit阶段执行的检查需要严格控制，如果检查运算太复杂，耗时太多会给开发人员带来很差的体验。因此，图3为本发明实施例提供的资源错误分类的划分规则示意图，如图3所示，将具有检查代价小、错误影响大成本高的错误划分在pre-commit类型中，比如导致游戏crash，无法打手机包，修复困难等情况。挑选出pre-commit类型错误后，其余错误均划分到post-commit类型中。按照上述原则划分错误类型后，每次本地执行pre-commit的时间控制在0.5-1秒之内，对开发人员没有造成影响。

在执行游戏资源检查时，终端通过资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误。

S103、按照待检查的pre-commit类错误对应的检查逻辑，对游戏资源进行检查。

本实施例中，终端执行pre-commit资源检查脚本，对美术资源、脚本代码、策划表等游戏资源进行检查，执行检查脚本后会将检查结果存于RES_FILE下。

具体地，针对美术资源进行规范与检查。一般游戏项目中涉及的美术资源类型繁多，包括模型、场景、特效等，而且很多资源文件是互相索引关联的，要对美术资源进行检查，首先需要了解主要有哪些类型的资源文件，本实施例简单介绍一下主要的类型：

1).gim模型文件，一个模型文件同时还要包括.mesh、.mtg文件，可用modeleditor.exe编辑器打开。保存了怪物，npc等模型文件信息，同时模型文件也还会索引用到.gis模型动作文件，只有存在动作的模型才需要该类文件。

2).scn场景文件，可用sceneeditor.exe编辑器打开。保存了场景信息。

3).sfx特效文件，特效相关联的文件还有贴图文件(.png、.tga)、序列帧文件(.spr)可用fxeditor.exe编辑器打开，里面保存了特效信息。

由于对美术资源有着严格的规范要求，一旦不符合资源规范会导致各种游戏bug。举例来说如下。

对于模型文件，一个模型文件同目录下应该包括gim,mesh,mtg，缺一不可，有时候美术会漏提交或者命名不正确找不到对应文件；模型的面数、批次、骨骼数也不能超过制定的最大标准；mtg文件中假如有中文，这样不仅是找不到贴图，还会导致游戏crash。

对于场景文件，.scn场景文件相当于一个索引文件，游戏引擎会根据场景文件去加载场景的各种配置和具体资源，本实施例主要需要检查场景是否有lightmap缺失，如有则会在游戏中显示异常。

对于特效文件，同样要检查关联的贴图文件、序列帧文件是否存在；另外特效层数属性不能超过项目设定的最大值，特效使用的贴图文件像素大小是否符合标准；特效的粒子数是否超标等。

以上检查规则只是常见的一些情况举例，实际项目中会根据制定的标准得到大约几十条美术资源的检查规则，那么如何去检查呢？通过编辑器去打开资源是最直接的检查资源正确性的方法。但是使用这种方法对于测试工程师来说肯定是不现实的，工作量巨大而且不能保证没有遗漏。本实施例对所有资源文件格式进行了分析，大部分检查只要读取文件路径、文件名、大小即可，部分检查需要读取文件内具体属性参数，而这些资源文件主要包括xml格式、二进制、特殊格式文件，本实施例采用文本读取然后解析的方式去检查。例如，对于xml格式文件，使用python中xml.etree模块即可完成解析，xml.etree.ElementTree模块是一种灵活的容器对象，用于在内存中存储结构化数据。Parse()方法可以读取导入xml文件，然后用getroot()获得根节点，然后可以遍历根节点下所有的元素。获得检查需要的元素后，通过正则表达式的形式进行格式检查。对于其他类型资源格式，按照同样思路，针对每个类型文件设计解析器即可，不再赘述。

针对程序脚本代码进行检查。脚本代码主要检查的问题包括补齐格式、注释格式、命名规范、静态语法错误等。本实施例对于脚本代码检查采用flake8标准。对于待检查的脚本文件，在pre-commit触发检查逻辑中启动flake8进程执行检查。Subprocess.Popen函数传入path参数，即可对此路径的文件执行检查。具体检查的类型可以通过flake8.conf文件进行配置，配置可根据项目实际情况进行修改，通过配置可以忽略一些不考虑的检查项。

针对策划表进行检查。由于在游戏项目中，会将大量的游戏设定和具体配置交给游戏策划通过填表来进行自由修改，一方面可以增强游戏策划的可配置自由度，另一方面减少后期程序开发的工作量，一些数值和设定的调整不需要程序参与。因此，一般游戏项目采用的方案都是策划按指定格式填写excel表格，通过程序提供的导表程序，将excel表导出成一个一个的数据python代码文件。具体导表工具由于项目不同而有差异，但总体思路都是一致，先是读excel表内容然后将excel内容转成python数据格式。

由以上可以看出，策划配表非常关键而且比较容易出错，实际项目中也发现，策划配表错误导致的游戏bug占比接近一半，因此对策划表的检查不可缺少。策划表常见的错误类型有：漏填、配置不符合规范(不符合预设约束)、设置不合理(超过数值范围等)、值非法、表互相引用等。策划表表结构千差万别，而且错误种类繁多，如果针对每项错误都写检查脚本来进行检查，代码冗余重复度很高而且工作量大，不好维护。因此本实施例采用尽可能将所有检查公共逻辑部分抽离出来，形成一条一条独立的rule规范，然后提供给用户去配置rule参数和rule组合规则，那么只需实现数十条rule规则就能覆盖数百条常用的策划表检查规则。本实施例具体实现方法如下：

首先将一些通用的rule抽离出来，这些rule是最简单最基本的规则，举例如下：

rule1:attr_not_none(attr_name)，返回策划表指定属性是否为空。

rule2:attr_value_list(attr_name,value_list)，返回策划表指定属性取值是否在value_list中。

rule3:attr_int_range(attr_name,value_min，value_max)，返回策划表指定属性是否为整数且范围在value_min和value_max之间。

得到以上的基本规则库以后，本实施例继续构造规则操作符，规则操作符就是构造rule的运算和关联关系，目的是能够将已有的rule进行随意的组合，构造复杂的检查规则，本实施例支持的常用rule操作符有：

and操作符：rule1 and rule2，同时满足2个规则返回true。

or操作符：rule1 or rule2，2个规则满足任一规则即返回true。

not操作符：not rule1，规则1不满足则返回true。

if操作：if rule1:rule2，如果满足规则1则检查规则2。

if else操作：if rule1:rule2else rule3，如果满足规则1则检查规则2，否则检查规则3。

有了规则和操作符以后，测试人员和策划可以配置各种复杂定制化的检查规则，这种实现方式极大的降低了开发复杂度和工作量，工具维护简单，并且能够非常方便的添加新规则。每一条表检查规则最后只要配置一条规则表达式即可，资源检查工具在执行策划表检查时，会读取当前所有规则，然后收到策划表文件有新提交后，会执行已配置的检查，将错误信息返回给提交人员。

S104、若存在pre-commit类错误，则生成错误提醒信息。

本实施例中，若存在pre-commit类错误，则在终端的显示界面上显示检查到的错误信息，并提示游戏资源提交失败。例如，针对程序脚本代码检查执行完成后，检查若发现代码不符合规范，检查不通过则将具体错误信息输出至控制台。图4为本发明实施例提供的错误提醒信息的示意图，如图4所示，每条错误信息包括具体代码文件路径，行数和错误类型，提示提交人员进行修改。

S105、若不存在pre-commit类错误，则向版本控制服务器提交游戏资源。

本实施例中，终端在游戏资源对应的日志尾部添加根据预设算法生成的数字签名，得到签名后的日志；将签名后的日志和游戏资源发送给版本控制服务器。

具体地，pre-commit资源检查是在开发人员本地运行，虽然网络管理员给开发人员统一安装了hook插件，但是这并不是可靠的，不能保证开发人员本地环境改变，检查工具失效的情况。为了保证***安全有效，本实施例提出了数字签名的方式进行校验，保证用户提交的资源都经过了pre-commit检查逻辑。为了用最简便的方法达到目的，本实施例提出直接在提交日志的尾部加入一串生成的数字签名，这样既省事而且服务端还能方便获取然后校验。具体实现如下：开发人员每次经过pre-commit检查工具检查通过并提交成功后，***均会在提交的log尾部添加一个HMAC数字签名。图5为本发明实施例提供的提交日志信息的示意图，如图5所示，提交的日志信息中带有数字签名。大部分情况下，数字校验可以采取哈希算法，为了防止黑客用哈希值反推原始口令，在计算哈希的时候，在原始输入基础上通常增加一个salt算法来使得相同的输入也能得到不同的哈希，这样，大大增加了破解的难度。因此本实施例采用了HMAC算法：Keyed-Hashing for Message Authentication，它通过一个标准算法，在计算哈希的过程中，把key混入计算过程中。采用HMAC替代默认的salt算法，可以使程序算法更标准化，也更安全。本实施例HMAC的输入采用的是本次提交的文件名列表转换成的字符串，加上预先设定好的salt key，保证校验过程的安全可靠性。

可选地，在向版本控制服务器提交游戏资源之后，还包括：接收版本控制服务器的反馈信息，反馈信息用于通知终端游戏资源是否提交成功；若接收到游戏资源提交成功的反馈信息，则在预设时长内等待远程检查端反馈的错误报告；在终端的显示界面上按照预设格式显示错误报告；错误报告包括：post-commit类错误。

本实施例中，终端还可以接收版本控制服务器、远程检查端返回的反馈信息。版本控制服务器、远程检查端的工作原理将在后续实施例中进行详细介绍，此处不再赘述。

本实施例，通过在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程；通过资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误；按照待检查的pre-commit类错误对应的检查逻辑，对游戏资源进行检查；若存在pre-commit类错误，则生成错误提醒信息；若不存在，则向版本控制服务器提交游戏资源。本发明可以缩短资源检查的时间，有效提高检查效率。

图6为本发明实施例二提供的游戏资源的检查方法的流程图，如图6所示，本实施例中的方法可以包括：

S201、接收终端提交的游戏资源，以及游戏资源对应的签名后的日志。

S202、对签名后的日志进行解析，得到对应的数字签名。

S203、将数字签名与预先存储的参照签名进行比对，若比对结果一致，则将游戏资源发送给远程检查端，并向终端发送反馈信息，用以通知终端游戏资源提交成功。

S204、若比对结果不一致，则向终端发送反馈信息，用以通知终端游戏资源提交失败。

本实施例中，版本服务控制器，即svn服务器端进行数字签名校验时，也是通过解密方法进行计算，如果校验通过则svn服务端会允许本次提交，否则将判定为开发人员本地检查插件缺失，提交的内容未经过pre-commit阶段检查而被禁止提交，并向终端反馈提交失败的信息。

图7为本发明实施例三提供的游戏资源的检查方法的流程图，如图7所示，本实施例中的方法可以包括：

S301、接收版本控制服务器发送的游戏资源。

S302、对游戏资源进行任务分解后，投递至任务管理器。

本实施例中，通过预先训练的BP神经网络对游戏资源进行任务分解；将分解得到的任务，按照队列形式投递至任务管理器。

具体地，为了充分发挥分布式并行资源检查的优势，本实施例将资源检查的粒度进行细化。目前已有方案都是以单次提交为基本单位，单次提交的游戏资源作为一个检查数据包，该方案存在的问题是，如果单次提交涉及大量资源文件的修改，或者修改的内容比较多的时候，无法保证检查的时间。有可能单次提交造成检查***阻塞，并且该用户需要等待很长时间才能得到自由检查结果的反馈，无法做到实时性。

本实施例的解决思路是根据历史资源检查的数据，训练得到一个可靠的模型，该模型能够根据任务的各种属性数据，比如文件类型、数量、大小等预估检查逻辑需要的时间，判断需要进行任务拆解后，输入决策模型，决策模型根据定义的决策特征函数进行任务划分，不断迭代，直到所有的根节点满足最优的解决方案，一方面充分利用分布式资源，另一方面尽可能将资源检查耗时控制在可接受范围。图8为本发明实施例提供的任务管理器的任务分解流程图。

1)样本数据

样本数据来自于历史资源检查真实的数据。随着检查不断的进行，一方面样本数据保持不断更新，然后定期去更新预测模型，提高模型准确度；另外一方面，如果有新类型的资源文件，通过训练数据的更新，能够保证模型对新类型资源的可预测性。

样本数据维度的选择是根据实际数据库存储的数据以及对检查时间的实际影响来判断，本实施例提取了资源文件类型，对应类型文件数量，各文件大小以及耗时4个维度。其中文件的类型决定了需要检查的资源错误类型，文件的大小和数量对最终检查的耗时有着最直接的影响，包括从svn仓库进行文件更新下载以及资源解析等过程。

2)基于BP神经网络训练模型

完成了样本数据搜集后，下一过程就是对数据进行量化和建模，寻找耗时与文件类型，文件数量，文件大小三个属性之间的具体关系，得到这个模型以后，可以利用此模型作为评价函数和依据，进行当前任务耗时的评估然后再进行任务细化。

本实施例对以上数据进行梳理，各已知维度的指标变量如下：

T：表示检查耗时

N：表示已知的资源文件类型数(当前N＝12，包括的类型有py、xml、gis、gim、mesh、mtg、png、tga、sfx、binary、scn、spr)。

Xi，i取值范围是[1,N]：表示对应类型文件的数量。

Yi，i取值范围是[1,N]：表示第i类文件的大小总和，单位为KB。

为了便于建模，将Xi和Yi数据整合成一个长度为2N的数组的矩阵，S＝[X1Y1X2Y2……XN YN]。

BP神经网络具有任意复杂的模式分类能力和优良的多维函数映射能力，层次结构上，BP网络分为输入层、隐藏层和输出层三个层次；BP算法就是以网络误差平方为目标函数、采用梯度下降法来计算目标函数的最小值。BP神经网络能够通过给定的数据样本，通过自身的训练，学习某种规则，在给定输入值时得到最接近期望输出值的结果。本实施例训练样本中，数据输入值为各类型游戏资源的数量、文件大小数组S＝[X1Y1X2Y2……XN YN]，输出值则为执行资源检查的耗时T。为了达到比较准确的效果，同时避免训练时长过久，本实施例隐层数选择为2层，隐层节点数选择为6。

首先导入numpy线性代数工具库，本实施例使用“sigmod”函数作为非线性映射函数，Sigmod函数可以将任何值都映射到一个位于0到1范围内的值。通过它，可以将实数转化为概率值。代码中当传入参数tag为1时，得到sigmoid函数的导数形式。S为训练数据，每行为一条训练数据实例，每一列对应一个输入节点。这样本实施例的输入节点数是24个，例子中有4个训练实例(仅举例说明实现方法，实际用例数量比较大)。T为输出节点，每行表示对应输入实例的输出值。接下来是训练过程，首先对权重矩阵进行初始化，然后通过for循环迭代式地多次执行训练代码，使得网络能更好地拟合训练集。最终得到结果的误差小于设定值后，判定训练的得到模型为准确的，后续任务评估就可以依据此模型进行。

3)任务分解

训练的得到BP神经网络模型后，本实施例以此作为任务复杂度的评估函数，采用优先按文件类型，其次按文件数量的模式进行任务的分解，也就是同一个类型的资源文件倾向于划分到一个检查任务中，如果某个类型文件数量过多检查超时，则再进行分解。按上述思路本实施例设计出决策树形结构来进行任务的分解。图9为本发明实施例提供的任务分解的示意图，如图9所示，为了更清晰的说明分解过程，对任务类型维度进行了简化，假设只有4种类型的资源文件。某次提交的资源输入数据为S＝【X1 Y1 X2 Y2 X3 Y3 X4 Y4】，输入BP模型进行预估，输出值大于设定阈值，则判定需要进行任务拆分。然后首先对输入进行类型统计，如果资源类型种类大于2，则进行任务类型划分，将资源类别分到两个子任务中S1＝【X1 Y1 0 0 X3 Y3 0 0】和S2＝【0 0 X2 Y2 0 0 X4 Y4】，S＝S1+S2并且S1和S2中没有同类型的资源文件。若输入S中只有一种资源类型，则无法按资源类型进行任务分解，然后考虑从数量层面进行分解，假设此时任务S＝【X1 Y1 0 0 0 0 0 0】，X1若大于1，则将S分为子任务S3＝【x1 y1 0 0 0 0 0 0】和S4＝【x2 y2 0 0 0 0 0 0】，其中S＝S3+S4。若X1＝1则不进行拆分，直接投递任务。最后，对子任务S1-S4进行同样流程递归，直至所有任务经过BP模型预估值小于设定阈值或者任务无法拆分则停止。上述流程递归结束后，单次提交成功被分解成多个简单的独立的子任务，投递到远端post-commit检查任务队列中。

S303、查询预先配置的资源错误分类表，得到待检查的post-commit类错误。

S304、按照待检查的post-commit类错误对应的检查逻辑，对任务管理器中的任务进行检查。

本实施例中，图10为本发明实施例提供的并发资源检查的结构示意图，如图10所示，采用Gearman的方案来实现并发资源检查需求的处理，Gearman架构通常包括三大部分，一个client接受请求分解任务送至任务管理器，一个任务服务器管理job，一个或多个worker具体执行job。

(1)远端资源检查***client用来接受请求分解任务、投递任务job到任务服务器，在本实施例job内容包括：待测试的美术资源文件列表，提交版本号，提交人信息，资源块信息等。

(2)任务服务器Job中部署Gearman服务，将接受到的任务放置在任务队列中，会自动寻找合适的空闲的worker进行任务投放。

(3)worker：本***中有数十个worker同时工作，他们承担着具体资源检查任务执行的工作，对接收到的目标文件列表逐一进行资源检查。

本实施例部署了一台机器安装Gearman作为中心节点进行任务接收和分配调度；多台机器作为worker，每台机器根据CPU核心数来配置worker数量，它们用来执行具体的资源检查任务。Gearman Client负责任务投递，主要流程如下：

步骤1：首先导入gearman模块，实例化client，连接中心节点的Gearman服务。

步骤2：从远端资源检查***client获得任务数据，拆分得到具体任务data。

步骤3：然后调用方法投递任务，图中的submit_job方法即投递任务的接口。

任务投递后，Gearman服务器上可以查看队列中的任务。至此，Client端的任务投递完成。

Worker接收任务，执行检查任务部分，主要流程如下：首先，实现了一个GearmanWorker类将worker的各种操作进行了一个封装，它提供***队列任务和执行任务的方法。Worker工作时，先连接Gearman中心节点，获得工作队列，并制定工作队列取回数据执行的函数，并开始工作。图中，注册的工作队列就是之前Client发起任务的工作队列，Worker会不停的从队列中取任务，并执行resource_check方法。resource_check方法中，解析队列中取得的job，并执行检查，检查完成后，将结果返回到后台数据库，并且发送消息通知，当worker执行完分配给自己的当前任务时，Gearman会自动分配任务，让其继续工作。

S305、若存在post-commit类错误，则生成错误报告，并将终端反馈错误报告。

本实施例中，若存在post-commit类错误，则生成错误报告，远程控制端向终端反馈错误报告。在每次提交检查完成生产报告后，会通过泡泡消息进行提醒。错误报告还可以分为两类，一类是每次提交后，资源检查模块进行检查收到反馈结果后生成了本次提交的一个错误报告，另外一类是当前版本仓库所有错误报告的汇总，也就是所有待修复问题的汇总报告。错误报告可以按照错误类别进行分类，点击查看每一类错误，可以查看检查出资源错误的资源文件列表，便于开发人员修复。

S306、若不存在post-commit类错误，则完成游戏资源的提交。

图11为本发明实施例四提供的游戏资源的检查方法的流程图，如图11所示，本实施例中的方法可以包括：

S401、在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程。

S402、通过资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误。

S403、按照待检查的pre-commit类错误对应的检查逻辑，对游戏资源进行检查。

S404、若存在pre-commit类错误，则生成错误提醒信息

S405、若不存在pre-commit类错误，则向版本控制服务器提交游戏资源。

本实施例中，步骤S401～步骤S405的具体实现过程和技术原理请参见图2所示的方法中步骤S101～步骤S105中的相关描述，此处不再赘述。

S406、接收终端提交的游戏资源，以及游戏资源对应的签名后的日志。

S407、对签名后的日志进行解析，得到对应的数字签名。

S408、将数字签名与预先存储的参照签名进行比对，若比对结果一致，则将游戏资源发送给远程检查端，并向终端发送反馈信息，用以通知终端游戏资源提交成功。

S409、若比对结果不一致，则向终端发送反馈信息，用以通知终端游戏资源提交失败。

本实施例中，步骤S406～步骤S409的具体实现过程和技术原理请参见图6所示的方法中步骤S201～步骤S204中的相关描述，此处不再赘述。

S410、接收版本控制服务器发送的游戏资源。

S411、对游戏资源进行任务分解后，投递至任务管理器。

S412、查询预先配置的资源错误分类表，得到待检查的post-commit类错误。

S413、按照待检查的post-commit类错误对应的检查逻辑，对任务管理器中的任务进行检查。

S414、若存在post-commit类错误，则生成错误报告，并将终端反馈错误报告。

S415、若不存在post-commit类错误，则完成游戏资源的提交。

本实施例中，步骤S410～步骤S415的具体实现过程和技术原理请参见图7所示的方法中步骤S301～步骤S306中的相关描述，此处不再赘述。

本发明具有如下的优点：

1.本地插件工具由***管理员推送自动安装，无需手动安装，优化开发人员体验，避免了繁琐安装流程。

2.资源检查类别覆盖全面，能够覆盖策划表、程序代码以及各类美术资源。

3.对资源错误类型进行分类，采用pre-commit和post-commit两种方式结合的策略，控制pre-commit检查时间，避免开发人员提交时等待过久，且从根源避免仓库被污染。

4.采用数字签名的方式进行服务端验证，确保提交的资源都经过检查，保证***的安全可靠性。

5.利用BP神经网络进行模型训练，准确预估资源检查耗时，据此进行任务粒度细分，避免大量资源提交后post-commit检查结果反馈等待时间过长。

6.远程资源检查服务器采用分布式架构，用任务队列的形式多worker同步检查，极大提高资源检查***效率，避免检查***任务堆积。

7.检查结果和测试报告通过前端进行展示并且给相关人员进行消息提醒。

图12为本发明实施例五提供的游戏资源的检查装置的结构示意图，如图12所示，本实施例的装置可以包括：

触发模块31，用在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程；

查询模块32，用于通过资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误；

检查模块33，用于按照待检查的pre-commit类错误对应的检查逻辑，对游戏资源进行检查；

提醒模块34，用于在存在pre-commit类错误时，生成错误提醒信息；

发送模块35，用于在不存在pre-commit类错误时，向版本控制服务器提交游戏资源。

在一种可能的设计中，提醒模块34，具体用于：

若存在pre-commit类错误，则在终端的显示界面上显示检查到的错误信息，并提示游戏资源提交失败。

在一种可能的设计中，发送模块35，具体用于：

在游戏资源对应的日志尾部添加根据预设算法生成的数字签名，得到签名后的日志；

将签名后的日志和游戏资源发送给版本控制服务器。

在一种可能的设计中，还包括：接收模块36，用于：

接收版本控制服务器的反馈信息，反馈信息用于通知终端游戏资源是否提交成功；

若接收到游戏资源提交成功的反馈信息，则在预设时长内等待远程检查端反馈的错误报告；

在终端的显示界面上按照预设格式显示错误报告；错误报告包括：post-commit类错误。

本实施例的装置，可以执行图2所示方法中的技术方案，其具体实现过程和技术原理参见图2所示方法中的相关描述，此处不再赘述。

图13为本发明实施例六提供的游戏资源的检查装置的结构示意图，如图13所示，本实施例的装置可以包括：

接收模块41，用于接收终端提交的游戏资源，以及游戏资源对应的签名后的日志；

解析模块42，用于对签名后的日志进行解析，得到对应的数字签名；

比对模块43，用于将数字签名与预先存储的参照签名进行比对，若比对结果一致，则将游戏资源发送给远程检查端，并向终端发送反馈信息，用以通知终端游戏资源提交成功；

反馈模块44，用于在比对结果不一致是，向终端发送反馈信息，用以通知终端游戏资源提交失败。

本实施例的装置，可以执行图6所示方法中的技术方案，其具体实现过程和技术原理参见图6所示方法中的相关描述，此处不再赘述。

图14为本发明实施例七提供的游戏资源的检查装置的结构示意图，如图14所示，本实施例的装置可以包括：

接收模块51，用于接收版本控制服务器发送的游戏资源；

分解模块52，用于对游戏资源进行任务分解后，投递至任务管理器；

查询模块53，用于查询预先配置的资源错误分类表，得到待检查的post-commit类错误；

检查模块54，用于按照待检查的post-commit类错误对应的检查逻辑，对任务管理器中的任务进行检查；

反馈模块55，用于在存在post-commit类错误时，生成错误报告，并将终端反馈错误报告；若不存在post-commit类错误，则完成游戏资源的提交。

在一种可能的设计中，分解模块52，具体用于：

通过预先训练的BP神经网络对游戏资源进行任务分解；

将分解得到的任务，按照队列形式投递至任务管理器。

本实施例的装置，可以执行图7所示方法中的技术方案，其具体实现过程和技术原理参见图7所示方法中的相关描述，此处不再赘述。

图15为本发明实施例八提供的游戏资源的检查***的结构示意图，如图15所示，本实施例的***60可以包括：处理器61和存储器62。

存储器62，用于存储计算机程序(如实现上述游戏资源的检查方法的应用程序、功能模块等)、计算机指令等；

上述的计算机程序、计算机指令等可以分区存储在一个或多个存储器62中。并且上述的计算机程序、计算机指令、数据等可以被处理器61调用。

处理器61，用于执行存储器62存储的计算机程序，以实现上述实施例涉及的方法中的各个步骤。

具体可以参见前面方法实施例中的相关描述。

处理器61和存储器62可以是独立结构，也可以是集成在一起的集成结构。当处理器61和存储器62是独立结构时，存储器62、处理器61可以通过总线63耦合连接。

图16为本发明实施例九提供的游戏资源的检查***的结构示意图，如图16所示，本实施例的***70包括：终端30、版本控制服务器40、远程控制端50；其中：

终端30用于执行实施例一中任一项的游戏资源的检查方法；

版本服务控制器40用于执行实施例二中的游戏资源的检查方法；

远程控制端50用于执行实施例三中的游戏资源的检查方法。

此外，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当用户设备的至少一个处理器执行该计算机执行指令时，用户设备执行上述各种可能的方法。

其中，计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于用户设备中。当然，处理器和存储介质也可以作为分立组件存在于通信设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请还提供一种程序产品，程序产品包括计算机程序，计算机程序存储在可读存储介质中，服务器的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得服务器实施上述本发明实施例任一的方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (13)

1.一种游戏资源的检查方法，其特征在于，包括：

在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程；

通过所述资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误；

按照所述待检查的pre-commit类错误对应的检查逻辑，对所述游戏资源进行检查；

若存在pre-commit类错误，则生成错误提醒信息；

若不存在pre-commit类错误，则向所述版本控制服务器提交所述游戏资源。

2.根据权利要求1所述的方法，其特征在于，若存在pre-commit类错误，则生成错误提醒信息，包括：

若存在pre-commit类错误，则在终端的显示界面上显示检查到的错误信息，并提示游戏资源提交失败。

3.根据权利要求1所述的方法，其特征在于，向所述版本控制服务器提交所述游戏资源，包括：

在所述游戏资源对应的日志尾部添加根据预设算法生成的数字签名，得到签名后的日志；

将所述签名后的日志和所述游戏资源发送给所述版本控制服务器。

4.根据权利要求1-3中任一项所述的方法，其特征在于，在向所述版本控制服务器提交所述游戏资源之后，还包括：

接收所述版本控制服务器的反馈信息，所述反馈信息用于通知所述终端游戏资源是否提交成功；

若接收到游戏资源提交成功的反馈信息，则在预设时长内等待远程检查端反馈的错误报告；

在终端的显示界面上按照预设格式显示所述错误报告；所述错误报告包括：post-commit类错误。

5.一种游戏资源的检查方法，其特征在于，包括：

接收终端提交的游戏资源，以及所述游戏资源对应的签名后的日志；

对所述签名后的日志进行解析，得到对应的数字签名；

将所述数字签名与预先存储的参照签名进行比对，若比对结果一致，则将所述游戏资源发送给远程检查端，并向所述终端发送反馈信息，用以通知所述终端游戏资源提交成功；

若比对结果不一致，则向所述终端发送反馈信息，用以通知所述终端游戏资源提交失败。

6.一种游戏资源的检查方法，其特征在于，包括：

接收版本控制服务器发送的游戏资源；

对所述游戏资源进行任务分解后，投递至任务管理器；

查询预先配置的资源错误分类表，得到待检查的post-commit类错误；

按照所述待检查的post-commit类错误对应的检查逻辑，对所述任务管理器中的任务进行检查；

若存在post-commit类错误，则生成错误报告，并将所述终端反馈所述错误报告；

若不存在post-commit类错误，则完成游戏资源的提交。

7.根据权利要求6所述的方法，其特征在于，对所述游戏资源进行分解后，投递至任务管理器，包括：

通过预先训练的BP神经网络对所述游戏资源进行任务分解；

将分解得到的任务，按照队列形式投递至任务管理器。

8.一种游戏资源的检查装置，其特征在于，包括：

触发模块，用在向版本控制服务器提交游戏资源之前，触发启动终端的资源检查进程；

查询模块，用于通过所述资源检查进程查询预先配置的资源错误分类表，得到待检查的pre-commit类错误；

检查模块，用于按照所述待检查的pre-commit类错误对应的检查逻辑，对所述游戏资源进行检查；

提醒模块，用于在存在pre-commit类错误时，生成错误提醒信息；

发送模块，用于在不存在pre-commit类错误时，向所述版本控制服务器提交所述游戏资源。

9.一种游戏资源的检查装置，其特征在于，包括：

接收模块，用于接收终端提交的游戏资源，以及所述游戏资源对应的签名后的日志；

解析模块，用于对所述签名后的日志进行解析，得到对应的数字签名；

比对模块，用于将所述数字签名与预先存储的参照签名进行比对，若比对结果一致，则将所述游戏资源发送给远程检查端，并向所述终端发送反馈信息，用以通知所述终端游戏资源提交成功；

反馈模块，用于在比对结果不一致是，向所述终端发送反馈信息，用以通知所述终端游戏资源提交失败。

10.一种游戏资源的检查装置，其特征在于，包括：

接收模块，用于接收版本控制服务器发送的游戏资源；

分解模块，用于对所述游戏资源进行任务分解后，投递至任务管理器；

查询模块，用于查询预先配置的资源错误分类表，得到待检查的post-commit类错误；

检查模块，用于按照所述待检查的post-commit类错误对应的检查逻辑，对所述任务管理器中的任务进行检查；

反馈模块，用于在存在post-commit类错误时，生成错误报告，并将所述终端反馈所述错误报告；若不存在post-commit类错误，则完成游戏资源的提交。

11.一种游戏资源的检查***，其特征在于，包括：存储器和处理器，存储器中存储有所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-7中任一项所述的游戏资源的检查方法。

12.一种游戏资源的检查***，其特征在于，包括：终端、版本控制服务器、远程控制端；其中：

所述终端用于执行如权利要求1-4中任一项所述的游戏资源的检查方法；

所述版本服务控制器用于执行如权利要求5所述的游戏资源的检查方法；

所述远程控制端用于执行如权利要求6或7所述的游戏资源的检查方法。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1-7中任一项所述的游戏资源的检查方法。