游戏资源数据处理方法、装置、存储介质及电子设备与流程

阅读：评论：0

1.本公开涉及数据处理技术领域，具体涉及一种游戏资源数据处理方法、游戏资源数据处理装置、存储介质及电子设备。

背景技术：

2.对于游戏应用程序，玩家通常需要下载一个游戏安装包，下载的应用程序可以是完整的游戏包，包括游戏引擎和游戏各个阶段的资源包；或者是游戏基础安装包，仅仅包含自游戏启动甚至创建角阶段的游戏内容，游戏启动以后需要补充下载游戏各个阶段所必须的全部资源，才能进入游戏进行游玩。
3.目前不管是桌面平台还是移动平台，游戏都在往大型化的方式发展，现有的方式需要玩家进入游戏之前完成下载或者安装全部的游戏资源，导致玩家加载游戏的时间很长，影响游戏资源数据的处理效率，使得资源下载期间玩家的游戏体验较差。
4.需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

5.本公开的目的在于提供一种游戏资源数据处理方法、游戏资源数据处理装置、存储介质及电子设备，旨在减少游戏资源数据下载的等待时间，提升用户的游戏体验。
6.本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。
7.根据本公开实施例的一方面，提供了一种游戏资源数据处理方法，包括：识别游戏应用程序所处的当前游戏进程，并根据游戏进程信息确定所述当前游戏进程对应的下一游戏进程；基于游戏进程与分包资源数据的映射关系确定所述下一游戏进程对应的目标分包资源数据；下载所述目标分包资源数据，并解压所述目标分包资源数据至所述游戏应用程序中。
8.根据本公开的一些实施例，基于前述方案，所述游戏进程信息包括预先划分的多个游戏进程，以及各所述游戏进程之间的跳转关系。
9.根据本公开的一些实施例，基于前述方案，所述方法还包括：预先创建游戏进程与分包资源数据之间的映射关系，所述预先创建游戏进程与分包资源数据之间的映射关系，包括：利用资源提取器配置各所述游戏进程分别对应的依赖资源文件；将同一游戏进程对应的依赖资源文件进行合并，以生成各所述游戏进程分别对应的分包资源数据得到所述映射关系。
10.根据本公开的一些实施例，基于前述方案，所述利用资源提取器配置各所述游戏进程分别对应的依赖资源文件，包括：基于游戏进程所需的资源信息创建各所述游戏进程分别对应的配置文件；利用资源提取器中的资源深度遍历器根据所述配置文件进行索引以得到所述依赖资源文件。
11.根据本公开的一些实施例，基于前述方案，所述利用资源提取器配置各所述游戏进程分别对应的依赖资源文件，包括：预执行所述游戏进程得到运行信息；利用资源提取器中的日志分析提取器对所述运行信息进行分析以得到所述依赖资源文件。
12.根据本公开的一些实施例，基于前述方案，在生成各所述游戏进程分别对应的分包资源数据之后，所述方法还包括：将所述分包资源数据拆分为核心资源数据和可选资源数据；在确定所述下一游戏进程对应的目标分包资源数据后，下载所述目标分包资源数据中的目标核心资源数据；在所述目标核心资源数据下载完成后，下载所述目标分包资源数据中的目标可选资源数据。
13.根据本公开的一些实施例，基于前述方案，所述方法还包括：响应于所述游戏应用程序的游戏开启操作，加载启动资源数据至所述游戏应用程序中；其中，所述启动资源数据是将游戏开启对应的依赖资源文件进行合并生成的。
14.根据本公开实施例的第二方面，提供了一种游戏资源数据处理装置，包括：识别模块，用于识别游戏应用程序所处的当前游戏进程，并根据游戏进程信息确定所述当前游戏进程对应的下一游戏进程；确定模块，用于基于游戏进程与分包资源数据的映射关系确定所述下一游戏进程对应的目标分包资源数据；下载模块，用于下载所述目标分包资源数据，并解压所述目标分包资源数据至所述游戏应用程序中。
15.根据本公开实施例的第三方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述实施例中的游戏资源数据处理方法。
16.根据本公开实施例的第四方面，提供了一种电子设备，其特征在于，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中的游戏资源数据处理方法。
17.本公开示例性实施例可以具有以下部分或全部有益效果：
18.在本公开的一些实施例所提供的技术方案中，预先配置了不同的游戏进程，以及各游戏进程对应的分包资源数据，使得在游戏应用程序运行当前游戏进程时，能够提前下载和解压下一游戏进程对应的分包资源数据。这样一来，一方面玩家进入游戏之前，不需要等待下载安装完全部的游戏资源数据，可以大大减少进入游戏时等待资源下载的时间，使其快速进入游戏，提升用户的游戏体验；另一方面，在运行当前游戏进程时，能预先下载和解压下一游戏进程对应的分包资源数据，就可以在不影响游戏各个阶段玩法的基础上，最大化地降低玩家的等待时间，极大地提升游戏体验和转化率。
19.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
20.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
21.图1示意性示出本公开示例性实施例中一种游戏资源数据处理方法的流程示意
图；
22.图2示意性示出本公开示例性实施例中一种游戏进程的示意图；
23.图3示意性示出本公开示例性实施例中另一种游戏进程的示意图；
24.图4示意性示出本公开示例性实施例中一种游戏资源数据处理的数据交互示意图；
25.图5示意性示出本公开示例性实施例中一种游戏资源数据处理装置的组成示意图；
26.图6示意性示出本公开示例性实施例中一种计算机可读存储介质的示意图；
27.图7示意性示出本公开示例性实施例中一种电子设备的计算机系统的结构示意图。
具体实施方式
28.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
29.此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。
30.附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
31.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
32.对于游戏应用程序，玩家通常需要下载一个游戏安装包，在windows(微软公司研发的跨平台操作系统)平台上可以通过游戏或者游戏代理商获取游戏安装应用程序，在ios(internet work 0perating system，网间网操作系统)或者android(安卓操作系统)操作系统平台上可以利用app store(应用商店)下载。在现有技术中，通常有以下三种方案：
33.方案一：游戏服务提供商提供全量的游戏资源。目前这种方式在pc(personal computer，个人计算机或者个人电脑)平台、ps(playstation，索尼开发的游戏端)平台和switch(日本任天堂公司出品的电子游戏机)平台应用较多，而且这些游戏的安装包都非常大，特别是pc平台全量安装包可以达到几十g。如果对于100m的网络带宽，下载50g的游戏安装包需要大概50*1024/(100/8)≈1小时，而且实际能够达到100m带宽的用户是不多的，所以下载全量游戏的时间基本需要花费几个小时。对于没有耐心或者时间不充裕的玩家来说，还没进入游戏就已经流失了。另外高并发高带宽的网络下载对于游戏服务器提供商的网络基础设施要求也进一步提升，游戏运营成本进一步提升。
34.方案二：游戏服务提供商提供游戏基础安装包，玩家安装游戏并启动游戏以后需要下载额外的剩余全量资源才能进入游戏。该方法相对于方案一实际是一种改进，玩家下载的游戏基础安装包实际包含了进入游戏前的一些基本功能，例如登录功能，广告宣传模块、游戏修复模块等。对于一些有捏脸功能的游戏来说，还可以在游戏基础安装包附带捏脸功能，尽量延迟玩家真正进入游戏的时间。因为可以在玩家捏脸过程中下载游戏剩余的内容，当下载完毕才进入游戏。该方案还是免不了需要下载完整的游戏才能进入游戏，而且游戏基础安装包可能只占全量游戏的十分之一到五分之一，大量的资源还是需要在进入游戏之前完成下载。
35.方案三：游戏服务提供商提供游戏基础安装包。玩家安装完成以后即可进行捏脸甚至进入游戏。当玩家进入某个场景或者与某个npc(non-player character，非玩家角)进行交互时，会访问游戏资源目录并尝试读取场景或者npc依赖的全部资源，当资源缺失会中断并通过网络方式访问下载远程的资源提供服务器。此时可能是同步或者异步等待资源的下载完成。当下载完成以后再次调用场景或者npc的加载接口，因为此时资源已经完备，所以可以顺利加载处理。但是这种方式面临多种问题，首先是网络下载可能成为瓶颈，下载速度远远落后cpu(中央处理器)或者gpu(图形处理器)的计算速度，cpu和gpu花费了大量的时间等待下载，明显的表现就是画面卡顿，玩家的用户体验不好。另一个问题是技术难度问题，因为游戏资源的加载是通过引擎进行了，甚至还关联到渲染引擎，暂停资源的加载并通过回调的方式重新唤醒的代价是非常大的，而且会完全割裂游戏画面的渲染。同时游戏资源类型多种多样，需要处理的情况也是异常多。
36.因此，不管是预先下载全量安装包，还是按需下载游戏资源，都不能很好地降低玩家的等待时间并提升游戏体验。针对现有技术的缺陷，本公开提供一种游戏资源数据处理方法，可以根据玩家的游戏进程智能地划分不同的分包资源数据作为包体，随着游戏进程的深入，在玩家将会体验该部分游戏内容时才去资源服务器上下载所需的资源，玩家实际使用资源可以直接从本地内存加载已经预先下载好的资源，免去了网络等待时间。
37.以下对本公开实施例的技术方案的实现细节进行详细阐述。
38.图1示意性示出本公开示例性实施例中一种游戏资源数据处理方法的流程示意图。如图1所示，该游戏资源数据处理方法包括步骤s101至步骤s103：
39.步骤s101，识别游戏应用程序所处的当前游戏进程，并根据游戏进程信息确定所述当前游戏进程对应的下一游戏进程；
40.步骤s102，基于游戏进程与分包资源数据的映射关系确定所述下一游戏进程对应的目标分包资源数据；
41.步骤s103，下载所述目标分包资源数据，并解压所述目标分包资源数据至所述游戏应用程序中。
42.在本公开的一些实施例所提供的技术方案中，预先配置了不同的游戏进程，以及各游戏进程对应的分包资源数据，使得在游戏应用程序运行当前游戏进程时，能够提前下载和解压下一游戏进程对应的分包资源数据。这样一来，一方面玩家进入游戏之前，不需要等待下载安装完全部的游戏资源数据，可以大大减少进入游戏时等待资源下载的时间，使其快速进入游戏，提升用户的游戏体验；另一方面，在运行当前游戏进程时，能预先下载和解压下一游戏进程对应的分包资源数据，就可以在不影响游戏各个阶段玩法的基础上，最
大化地降低玩家的等待时间，极大地提升游戏体验和转化率。
43.下面，将结合附图及实施例对本示例实施方式中的游戏资源数据处理方法的各个步骤进行更详细的说明。
44.在步骤s101中，识别游戏应用程序所处的当前游戏进程，并根据游戏进程信息确定所述当前游戏进程对应的下一游戏进程。
45.具体地，会预先配置好游戏进程信息，游戏进程信息包括划分的多个游戏进程，以及各所述游戏进程之间的跳转关系。进而可以在游戏处在当前游戏进程时，提前下载和解压好下一个游戏进程的分包资源数据。
46.游戏进程划分是得到分包资源数据的基础，也是决定用户体验的重要因素，并且游戏进程和分包资源数据一一对应，所以对游戏进程的划分也就是对分包资源数据的划分。将一个或者多个游戏阶段依赖的资源放到同一个包体，该包体下载完成表示相应的游戏阶段可以正常体验。正确的游戏进程划分能够让玩家在游玩过程中静默下载下一阶段的资源，并且进入游戏进程对应的资源已经完全准备就绪。另外还需要考虑玩家的网络环境和划分的资源包体数量大小。
47.在实际操作中，可以预先根据游戏玩法的时间线对游戏进程进行划分。例如玩家角等级可以决定系统开放的玩法以及可达的场景等，所以可以为每一个角等级分配相应的游戏进程，之后再将各游戏进程连接起来得到游戏进程之间的跳转关系。
48.还可以将一些特殊的玩法单独划分游戏进程。例如有些玩法玩家可以选择游玩或者不游玩，那么可以将该玩法单独划分为一个游戏进程，然后配置该游戏进程的跳转关系，进而可以为该玩法生成一个单独的分包资源数据。
49.需要说明的是，一个游戏进程可以视为一个节点，根据游戏玩法可以确定各个游戏进程之间的跳转关系，进而得到节点之间的有向边，进而构成有向图，不同的游戏玩法得到的有向图不同。
50.图2示意性示出本公开示例性实施例中一种游戏进程的示意图，参考图2所示，按照游戏玩法的时间线得到直线型的跳转关系。图3示意性示出本公开示例性实施例中另一种游戏进程的示意图，参考图3所示，也可以得到树状型的跳转关系。
51.在识别出游戏应用程序所处的当前游戏进程，根据游戏进程信息寻下一游戏进程。需要说明的是，在跳转关系唯一时，下一游戏进程是唯一确定；而在当前游戏进程具有多个下一游戏进程，且无法根据当前游戏进程唯一确定时，可以将多个下一游戏进程的分包资源数据均进行下载和解压。
52.在步骤s102中，基于游戏进程与分包资源数据的映射关系确定所述下一游戏进程对应的目标分包资源数据。
53.在本公开的一个实施例中，首先需要预先创建游戏进程与分包资源数据之间的映射关系。具体来说，所述预先创建游戏进程与分包资源数据之间的映射关系，包括：利用资源提取器配置各所述游戏进程分别对应的依赖资源文件；将同一游戏进程对应的依赖资源文件进行合并，以生成各所述游戏进程分别对应的分包资源数据得到所述映射关系。
54.具体地，在划分包体时，将游戏进程对应的依赖资源文件合并生成一个包体作为该游戏进程的分包资源数据。
55.因此，在本公开的一个实施例中，首先需要利用资源提取器配置各所述游戏进程
分别对应的依赖资源文件。
56.其中，资源提取器实际是一个树状资源依赖关系的深度搜索器，包括一个资源深度遍历器，一个日志分析提取器，分别用于不同情况下的资源提取，分别用于以下两种情况。
57.(一)在可以明确划分游戏进程所需的资源信息的情况下，确定各所述游戏进程分别对应的依赖资源文件的具体步骤如下：基于游戏进程所需的资源信息创建各所述游戏进程分别对应的配置文件；利用资源提取器中的资源深度遍历器根据所述配置文件进行索引以得到所述依赖资源文件。
58.具体而言，为了得到游戏进程所需的资源信息，可以预先将系统玩法进行分类。由于游戏进程和系统玩法相关联，当游戏进程进行到某一阶段时，通常会解锁或者开放对应的系统玩法。所以对系统玩法根据游戏进程分类，然后获取系统玩法依赖的游戏资源，便可得到游戏进程对应的资源信息。
59.需要说明的是，系统玩法设计阶段应该保持独立，能够明确区分游戏进程和相互依赖的资源。另外，还可以预先制定系统玩法目录表，表格记录着各种系统玩法所依赖的资源，例如依赖的场景、特殊的npc等。
60.在确定了游戏进程所需的资源信息后，可以根据资源信息创建一个配置文件，其上记录了该游戏进程对应的依赖资源文件的索引信息，使得资源深度遍历器能够根据配置文件索引得到该游戏进程对应的依赖资源文件。
61.在得到配置文件后，资源深度遍历器可以针对不同类型的索引智能地提取依赖的资源，即得到该游戏进程对应的依赖资源文件。
62.举例来说，如进行游戏场景提取：场景会有一个总的索引组成的配置文件，如果一个场景是多个地图构成的，那么还会索引另外的子场景索引。场景包括模型、贴图、地形、寻路图和音效等。场景依赖的资源通过深度遍历场景索引进行获取，或者通过相应的资源目录表格依赖进行获取。
63.如进行玩家或者npc模型提取：人物模型通常包含多种类型的资源，如果需要遍历人物模型的全部资源，需要对多种资源文件的索引进行遍历然后获取文件列表。
64.如进行ui资源提取：ui资源也是会有索引组成的配置文件，配置文件定义了组成该界面所需要的图片和子ui资源，所以深度遍历即可获取全部所需的资源。
65.(二)在未知或不能明确划分游戏进程所需的资源信息时，或者依赖关系复杂时候，可以使用游戏实跑的方式确定各所述游戏进程分别对应的依赖资源文件，具体步骤如下：预执行所述游戏进程得到运行信息；利用资源提取器中的日志分析提取器对所述运行信息进行分析以得到所述依赖资源文件。
66.具体而言，首先需要在游戏资源的访问程序接口处加入资源记录的开关；然后预执行该游戏进程，即进行游戏跑查；最后在完成游戏跑查后，将运行信息的资源记录放到日志分析提取器中。
67.之后日志分析提取器便可以根据游戏跑查得到的log文件进行分析，日志会记录访问的资源索引或者具体的资源文件，提取到该游戏进程对应的依赖资源文件，对于资源索引，也就是利用资源深度遍历器进行资源深度遍历，对于具体的文件，将文件进行相应的游戏进程阶段编号记录。
68.在本公开的一个实施例中，在得到各所述游戏进程分别对应的依赖资源文件后，将同一游戏进程对应的依赖资源文件进行合并。
69.具体地，可以为每一个游戏进程配置一个全局唯一的编号作为进程标识，然后在得到该游戏进程对应的依赖资源文件时，可以为该依赖资源文件添加上编号，用于后续资源分类和收集生成相应的包体。
70.由于依赖资源文件都是一些小文件，小文件是不利于网络下载的，所以需要将多个小文件合成为一个大文件，最终一个包体由多个大文件组成，这种方式可以尽量提升下载速度。所以在标记完成后，把编号相同的查询依赖资源文件进行合并以生成包体，即可得到各游戏进程分别对应的分包资源数据。
71.在本公开的一个实施例中，游戏进程依赖的依赖资源文件可以是游戏脚本、美术资源、用户界面资源、外观资源中的一种或多种。各个资源是独立的文件，并且可以通过配置文件获取其他依赖文件。
72.对于美术资源，通常可以细分为场景、角模型、贴图和动画等。对于场景，可以配置场景配置文件，场景配置文件里面会标记用到的网格数据文件、贴图等的文件名和对应的位置，场景资源可以直接标记归属于某一个游戏进程的包体，进而为其增加进程标识；对于角模型，通常一个角可以单独配置一个角配置文件，角模型的索引访问更多地是通过游戏玩法记录获取，所以一般是标记为某一系统玩法，再根据系统玩法属于哪个游戏进程，进而为其增加进程标识，当某个玩法被归类到某个包体了，实跑游戏玩法时可以记录看到的角，根据记录的角编号搜索依赖的资源。
73.对于用户界面资源，即ui资源，可以配置ui资源配置文件，以索引到引用到的资源，可能是图片、子ui配置文件或者plist文件。对于图片可以直接标记，对于引用的ui配置文件和plist文件，需要递归获取并标记。ui资源通常是根据系统玩法读取，与角模型类似，也是需要标记系统玩法，然后实跑游戏记录访问的ui配置资源，根据ui配置资源搜索依赖的资源然后标记。
74.对于外观资源，通常可以独立标记，因为外观可以穿搭在不同的角身上。而且外观可以在设计的开始阶段就标记每种外观需要的依赖文件。当需要单独收集外观数据，通过读取标记的文件，获取每种外观所需的全部资源。
75.需要说明的是，划分的全部包体组合在一起应该是需要包含全部游戏内容所需的资源，并且各个包体不存在相同的资源。如果某些资源被共用，那么应该需要划分在最高下载优先级的包体中，保证在最先使用的包体能够被加载。
76.在步骤s103中，下载所述目标分包资源数据，并解压所述目标分包资源数据至所述游戏应用程序中。
77.具体地，可以在当前游戏进程运行过程中，通过下载器下载下一游戏进程的分包资源数据，然后将其解压，进而使玩家在游戏过程中可以毫无等待地进入游戏，并且畅玩游戏各个阶段的玩法无需等待资源下载，极大地提升游戏体验和转化率。
78.需要说明的是，如果玩家的网络速度欠佳而导致下一游戏进程的分包资源数据没有下载完成，那么会拦截玩家的操作并且让玩家体验游戏的其他玩法。
79.在本公开的一个实施例中，在生成各所述游戏进程分别对应的分包资源数据之后，所述方法还包括：将所述分包资源数据拆分为核心资源数据和可选资源数据；在确定所
述下一游戏进程对应的目标分包资源数据后，下载所述目标分包资源数据中的目标核心资源数据；在所述目标核心资源数据下载完成后，下载所述目标分包资源数据中的目标可选资源数据。
80.具体地，在游戏进程中，有一些资源时非必须使用的附加资源，例如音效，锦衣或者某些有条件开启的玩法等。所以可以根据资源的必要性划分为核心资源数据和可选资源数据，核心资源是游戏进程推进的必要资源，如果缺失那么会导致游戏进程中断，玩家需要等待资源；而可选资源并非游戏进程推进的必要资源。
81.在实际使用过程中，游戏客户端启动时会检查各个资源包的资源总大小和待下载大小。如果资源包还没下载完，核心包会按照队列的方式自动逐一下载，可选包会在核心包完成下载以后提醒玩家下载，或者玩家通过下载界面手动控制可选包的下载。基于上述方法，可以进一步压缩必须下载的资源量，加快下载速度。
82.在本公开的一个实施例中，所述方法还包括：响应于所述游戏应用程序的游戏开启操作，加载启动资源数据至所述游戏应用程序中；其中，所述启动资源数据是将游戏开启对应的依赖资源文件进行合并生成的。
83.具体而言，在玩家首次进入游戏应用程序时，通过游戏服务提供商获取启动资源数据作为首包，使得能够加载基础的、必要的可用资源，以让玩家以最快的速度进入游戏。启动资源数据与分包资源数据的生成类似，都是在获取游戏开启对应的依赖资源文件后，将依赖资源文件合并生成包体作为启动资源数据。
84.启动资源数据的大小应该尽可能降低，例如仅包含必要的资源和数据。根据不同类型的游戏，启动资源数据的首包可以包含登录场景和界面、各个玩家角所需的资源、捏脸界面和相关美术资源以及新手场景和相应的任务npc资源。
85.在本公开的一个实施例中，还可以配置一个资源缺失记录器，当访问的资源缺失，会通过远程方式下载，并且记录日志上传到日志分析服务器；另外，记录的日志会离线作为日志分析提取器的输入，再次将资源正确划分到对应的包体。
86.这样一来，资源缺失记录器能够在本公开提供的边玩边下模式下防止资源被错误划分，而导致的游戏进程中断，通过反馈方式的自修复资源标记方法，可以让错误划分的资源重新标记正确。而且如果需要在测试阶段重新去跑查游戏是非常耗时的，所以这种方法也进一步降低了下载系统的开发维护成本。
87.图4示意性示出本公开示例性实施例中一种游戏资源数据处理的数据交互示意图，如图4所示，显示了分包资源数据的划分与下载的具体过程。
88.预先通过场景分类器对场景资源信息进行分类，以及通过系统/玩法分类器对系统、玩法等游戏规则类信息进行分类，或是采用游戏实跑，利用资源分析提取器生成多个包体，即分包资源数据。每一个游戏进程都有相对应的包体，例如用于登录/捏脸/新手的首个游戏进程对应的包体可记为首包，包括该游戏应用程序的引擎、脚本、登录资源、捏脸资源、角资源、新手场景、新手玩法等，而后续各进程具有对应的包体，以图4中直线型的游戏进程来说，进程1至进程n分别对应包体1至包体n。当游戏按照时间线依次执行，则会相应地从下载器提前下载和解压下一进程的包体，进而使用户无障碍地进行游戏，提升用户体验。同时还配置有资源缺失记录器来对分包资源数据进行缺失记录。
89.图5示意性示出本公开示例性实施例中一种游戏资源数据处理装置的组成示意
图，如图5所示，该游戏资源数据处理装置500可以包括识别模块501、确定模块502以及下载模块503。其中：
90.识别模块501，用于识别游戏应用程序所处的当前游戏进程，并根据游戏进程信息确定所述当前游戏进程对应的下一游戏进程；
91.确定模块502，用于基于游戏进程与分包资源数据的映射关系确定所述下一游戏进程对应的目标分包资源数据；
92.下载模块503，用于下载所述目标分包资源数据，并解压所述目标分包资源数据至所述游戏应用程序中。
93.根据本公开的示例性实施例，所述游戏进程信息包括预先划分的多个游戏进程，以及各所述游戏进程之间的跳转关系。
94.根据本公开的示例性实施例，所述游戏资源数据处理装置500可以包括映射单元，用于利用资源提取器配置各所述游戏进程分别对应的依赖资源文件；将同一游戏进程对应的依赖资源文件进行合并，以生成各所述游戏进程分别对应的分包资源数据得到所述映射关系。
95.根据本公开的示例性实施例，所述映射单元还用于基于游戏进程所需的资源信息创建各所述游戏进程分别对应的配置文件；利用资源提取器中的资源深度遍历器根据所述配置文件进行索引以得到所述依赖资源文件。
96.根据本公开的示例性实施例，所述映射单元还用于预执行所述游戏进程得到运行信息；利用资源提取器中的日志分析提取器对所述运行信息进行分析以得到所述依赖资源文件。
97.根据本公开的示例性实施例，所述游戏资源数据处理装置500可以包括分包单元，用于将所述分包资源数据拆分为核心资源数据和可选资源数据；在确定所述下一游戏进程对应的目标分包资源数据后，下载所述目标分包资源数据中的目标核心资源数据；在所述目标核心资源数据下载完成后，下载所述目标分包资源数据中的目标可选资源数据。
98.根据本公开的示例性实施例，所述游戏资源数据处理装置500可以包括启动单元，用于响应于所述游戏应用程序的游戏开启操作，加载启动资源数据至所述游戏应用程序中；其中，所述启动资源数据是将游戏开启对应的依赖资源文件进行合并生成的。
99.上述的游戏资源数据处理装置500中各模块的具体细节已经在对应的游戏资源数据处理方法中进行了详细的描述，因此此处不再赘述。
100.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
101.在本公开的示例性实施例中，还提供了一种能够实现上述方法的存储介质。图6示意性示出本公开示例性实施例中一种计算机可读存储介质的示意图，如图6所示，描述了根据本公开的实施方式的用于实现上述方法的程序产品600，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如手机上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
102.在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。图7示意性示出本公开示例性实施例中一种电子设备的计算机系统的结构示意图。
103.需要说明的是，图7示出的电子设备的计算机系统700仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
104.如图7所示，计算机系统700包括中央处理单元(central processing unit，cpu)701，其可以根据存储在只读存储器(read-only memory，rom)702中的程序或者从存储部分708加载到随机访问存储器(random access memory，ram)703中的程序而执行各种适当的动作和处理。在ram 703中，还存储有系统操作所需的各种程序和数据。cpu 701、rom 702以及ram 703通过总线704彼此相连。输入/输出(input/output，i/o)接口705也连接至总线704。
105.以下部件连接至i/o接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(cathode ray tube，crt)、液晶显示器(liquid crystal display，lcd)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如lan(local area network，局域网)卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至i/o接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。
106.特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(cpu)701执行时，执行本公开的系统中限定的各种功能。
107.需要说明的是，本公开实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(erasable programmable read only memory，eprom)、闪存、光纤、便携式紧凑磁盘只读存储器(compact disc read-only memory，cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
108.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
109.描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
110.作为另一方面，本公开还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。
111.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
112.通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。
113.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。
114.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

技术特征：

1.一种游戏资源数据处理方法，其特征在于，包括：识别游戏应用程序所处的当前游戏进程，并根据游戏进程信息确定所述当前游戏进程对应的下一游戏进程；基于游戏进程与分包资源数据的映射关系确定所述下一游戏进程对应的目标分包资源数据；下载所述目标分包资源数据，并解压所述目标分包资源数据至所述游戏应用程序中。2.根据权利要求1所述的游戏资源数据处理方法，其特征在于，所述游戏进程信息包括预先划分的多个游戏进程，以及各所述游戏进程之间的跳转关系。3.根据权利要求1所述的游戏资源数据处理方法，其特征在于，所述方法还包括：预先创建游戏进程与分包资源数据之间的映射关系，所述预先创建游戏进程与分包资源数据之间的映射关系，包括：利用资源提取器配置各所述游戏进程分别对应的依赖资源文件；将同一游戏进程对应的依赖资源文件进行合并，以生成各所述游戏进程分别对应的分包资源数据得到所述映射关系。4.根据权利要求3所述的游戏资源数据处理方法，其特征在于，所述利用资源提取器配置各所述游戏进程分别对应的依赖资源文件，包括：基于游戏进程所需的资源信息创建各所述游戏进程分别对应的配置文件；利用资源提取器中的资源深度遍历器根据所述配置文件进行索引以得到所述依赖资源文件。5.根据权利要求3所述的游戏资源数据处理方法，其特征在于，所述利用资源提取器配置各所述游戏进程分别对应的依赖资源文件，包括：预执行所述游戏进程得到运行信息；利用资源提取器中的日志分析提取器对所述运行信息进行分析以得到所述依赖资源文件。6.根据权利要求3所述的游戏资源数据处理方法，其特征在于，在生成各所述游戏进程分别对应的分包资源数据之后，所述方法还包括：将所述分包资源数据拆分为核心资源数据和可选资源数据；在确定所述下一游戏进程对应的目标分包资源数据后，下载所述目标分包资源数据中的目标核心资源数据；在所述目标核心资源数据下载完成后，下载所述目标分包资源数据中的目标可选资源数据。7.根据权利要求1所述的游戏资源数据处理方法，其特征在于，所述方法还包括：响应于所述游戏应用程序的游戏开启操作，加载启动资源数据至所述游戏应用程序中；其中，所述启动资源数据是将游戏开启对应的依赖资源文件进行合并生成的。8.一种游戏资源数据处理装置，其特征在于，包括：识别模块，用于识别游戏应用程序所处的当前游戏进程，并根据游戏进程信息确定所述当前游戏进程对应的下一游戏进程；确定模块，用于基于游戏进程与分包资源数据的映射关系确定所述下一游戏进程对应的目标分包资源数据；
下载模块，用于下载所述目标分包资源数据，并解压所述目标分包资源数据至所述游戏应用程序中。9.一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如权利要求1至7任一项所述的游戏资源数据处理方法。10.一种电子设备，其特征在于，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至7任一项所述的游戏资源数据处理方法。

技术总结

本公开涉及数据处理技术领域，具体涉及一种游戏资源数据处理方法、游戏资源数据处理装置、存储介质及电子设备。本公开提供的游戏资源数据处理方法包括：识别游戏应用程序所处的当前游戏进程，并根据游戏进程信息确定所述当前游戏进程对应的下一游戏进程；基于游戏进程与分包资源数据的映射关系确定所述下一游戏进程对应的目标分包资源数据；下载所述目标分包资源数据，并解压所述目标分包资源数据至所述游戏应用程序中。本公开提供的游戏资源数据处理方法能够减少游戏资源数据下载的等待时间，提升用户的游戏体验。提升用户的游戏体验。提升用户的游戏体验。