本申请涉及游戏处理技术领域，尤其涉及一种游戏资源管理、加载方法、设备及存储介质。
背景技术：
目前的游戏资源管理方案大致分为两类：
一类是将资源打包成大的资源包，每个资源包之间存在引用的先后关系。这样，在游戏加载过程中，可按引用关系加载资源包，对于客户端中缺少的资源包则需要去资源服务器进行下载。但是，由于下载量和网速的限制，几乎只能在游戏开始前下载好所有资源包，否则可能出现由于资源包下载时间过长，而导致游戏加载失败的问题。
另一类是将资源逐个打成小的资源包。这样，在游戏加载过程中，可按需从资源服务器中下载资源包。但是，由于资源包数量过多且单独维护，因此，会造成内存和磁盘资源双双占用过多。尤其对于大型游戏来说，在下载、磁盘io及版本控制等方面都会出现数量级带来的问题。
技术实现要素：
本申请的多个方面提供一种游戏资源管理、加载方法、设备及存储介质，用以实现边玩边下的游戏资源加载方式，且可有效保证游戏流畅度。
本申请实施例提供一种游戏资源管理方法，包括：
响应于资源管理请求，确定目标游戏所使用的至少一个资源；
构建所述至少一个资源之间的依赖关系，以生成资源依赖文件；
将所述至少一个资源的属性信息配置到资源管理文件中；
将所述资源管理文件、所述资源依赖文件和所述至少一个资源上传至资源服务器中，以供游戏客户端基于所述资源管理文件和所述资源依赖文件从所述资源服务器中下载所需的资源。
本申请实施例还提供一种游戏加载方法，适用于游戏客户端，包括：
在目标游戏的运行过程中，响应于资源加载请求，确定待加载的目标资源；
根据所述目标游戏下的资源依赖文件，查找所述目标资源的依赖资源；
若根据所述目标游戏下的资源管理文件确定需要下载所述目标资源及其依赖资源，则从资源服务器中下载所述目标资源及其依赖资源；其中，所述资源管理文件中包含所述目标游戏所使用的至少一个资源的属性信息；
加载所述目标资源。
本申请实施例还提供一种游戏系统，包括游戏资源管理设备、资源服务器和游戏客户端，所述资源服务器分别与所述游戏资源管理设备和所述游戏客户端通信连接；
所述游戏资源管理设备，设置为响应于资源管理请求，确定目标游戏所使用的至少一个资源；构建所述至少一个资源之间的依赖关系，以生成资源依赖文件；将所述至少一个资源的属性信息配置到资源管理文件中；将所述资源管理文件、所述资源依赖文件和所述至少一个资源上传至资源服务器中；
所述游戏客户端，设置为在所述目标游戏的运行过程中，响应于资源加载请求，确定待加载的目标资源；根据所述资源依赖文件，查找所述目标资源的依赖资源；若根据所述资源管理文件确定需要下载所述目标资源及其依赖资源，则从所述资源服务器中下载所述目标资源及其依赖资源；加载所述目标资源。
本申请实施例还提供一种游戏资源管理设备，包括存储器和处理器；
所述存储器用于存储一条或多条计算机指令；
所述处理器与所述存储器耦合，用于执行所述一条或多条计算机指令，以用于：
响应于资源管理请求，确定目标游戏所使用的至少一个资源；
构建所述至少一个资源之间的依赖关系，以生成资源依赖文件；
将所述至少一个资源的属性信息配置到资源管理文件中；
将所述资源管理文件、所述资源依赖文件和所述至少一个资源上传至资源服务器中，以供游戏客户端基于所述资源管理文件和所述资源依赖文件从所述资源服务器中下载所需的资源。
本申请实施例还提供一种游戏客户端，包括存储器和处理器；
所述存储器用于存储一条或多条计算机指令；
所述处理器与所述存储器耦合，用于执行所述一条或多条计算机指令，以用于：
在目标游戏的运行过程中，响应于资源加载请求，确定待加载的目标资源；
根据所述目标游戏下的资源依赖文件，查找所述目标资源的依赖资源；
若根据所述目标游戏下的资源管理文件确定需要下载所述目标资源及其依赖资源，则从资源服务器中下载所述目标资源及其依赖资源；其中，所述资源管理文件中包含所述目标游戏所使用的至少一个资源的属性信息；
加载所述目标资源。
本申请实施例还提供一种存储计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行前述的游戏资源管理方法或前述的游戏加载方法。
在本申请实施例中，可通过资源依赖文件，管理目标游戏所使用的至少一个资源之间的依赖关系，这样，可在游戏加载时，快速准确地确定出待加载的目标资源及其依赖资源；还可通过资源管理文件，维护至少一个资源的属性信息。这样，至少可实现以下几个方面的技术改进：
1、可实现集中统一地管理至少一个资源的属性状态，从而更加灵活地控制资源版本。
2、可在游戏运行过程中，将管理单位缩小至资源层面，从而可更加合理地、更加准确地确定出加载目标资源时所需下载的资源范围，而不再需要按资源包进行下载，这使得加载目标资源时所下载的资源不仅足够全面而且数量级低，从而可支持边玩边下的游戏加载方式，实现无需客户端补丁的热更新；且可充分利用下载资源/磁盘io性能。从而保证目标游戏的运行流畅度。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请一示例性实施例提供的一种游戏系统的结构示意图；
图2为本申请一实施例提供的一种游戏资源管理方法的流程示意图；
图3为本申请一示例性实施例提供的一种游戏加载方法的流程图；
图4为本申请另一示例性实施例提供的一种游戏资源管理设备的结构示意图；
图5为本申请另一示例性实施例提供的一种游戏客户端的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
针对现有技术中存在的由于资源包过大而导致的下载时长过长问题，或者由于资源包数量过多而导致下载过程中出现的数量级问题，本申请实施例的一些实施例中：可通过资源依赖文件，管理目标游戏所使用的至少一个资源之间的依赖关系，这样，可在游戏加载时，快速准确地确定出待加载的目标资源及其依赖资源；还可通过资源管理文件，维护至少一个资源的属性信息。这样，可实现集中统一地管理至少一个资源的属性状态，从而更加灵活地控制资源版本。据此，本申请实施例中，可在目标游戏运行过程中，将管理单位缩小至资源层面，从而可更加合理地、更加准确地确定出加载目标资源时所需下载的资源范围，而不再需要按资源包进行下载，这使得加载目标资源时所下载的资源不仅足够全面而且数量级低，从而可支持边玩边下的游戏加载方式，实现无需客户端补丁的热更新；且可充分利用下载资源/磁盘io性能。从而保证目标游戏的运行流畅度。
以下结合附图，详细说明本申请各实施例提供的技术方案。
图1为本申请一示例性实施例提供的一种游戏系统的结构示意图。如图1所示，该游戏系统包括：游戏资源管理设备10、资源服务器20和游戏客户端30，资源服务器20分别与游戏资源管理设备10和游戏客户端30通信连接。
本实施例中，游戏资源管理设备10可将目标游戏所使用的至少一个资源上传至资源服务器20，资源服务器20可用于存储目标游戏所使用的至少一个资源，而游戏客户端30则可从资源服务器20中下载目标游戏运行所需的资源。应当理解的是，图1所示的游戏系统可同时支持多款游戏的资源管理及加载方案，而不局限于目标游戏，不同游戏的资源管理及加载方案可相互独立、互不干扰。
以下将以目标游戏为例，分别从游戏资源管理和游戏加载两个阶段，对本实施例中的游戏系统进行说明。在游戏资源管理阶段，主要涉及游戏资源管理设备10和资源服务器20之间的交互逻辑。在游戏加载阶段，主要涉及游戏客户端30和资源服务器20之间的交互逻辑。另外，
游戏资源管理阶段
在该阶段，游戏提供方可在游戏资源管理设备10中管理目标游戏所使用的至少一个资源。游戏提供方可发起对目标游戏的资源管理请求，发起的实际可以是游戏初次发布时，或者也可以是游戏版本更新时。对于后一种情况，本实施例中，游戏资源管理设备10可将更新后的资源以及用于资源管理的相关文件更新到资源服务器20中，这保证了资源服务器20中的资源和用于资源管理的相关文件均为最新，从而，在游戏加载阶段，游戏客户端30可从资源服务器20中获取到最新资源，这样，可实现目标游戏的热更新，有效降低了游戏更新的复杂度。
对游戏资源管理设备10来说，可响应于资源管理请求，确定目标游戏所使用的至少一个资源；构建至少一个资源之间的依赖关系，以生成资源依赖文件；将至少一个资源的属性信息配置到资源管理文件中；将资源管理文件、资源依赖文件和至少一个资源上传至资源服务器20中。
本实施例中，通过资源依赖文件，可将管理单位缩小至资源，而不再局限于传统的资源包。其中，资源依赖文件可作为资源之间依赖关系的索引，从而可支持查找任意资源的依赖资源。
本实施例中，可分别为至少一个资源维护属性信息，属性信息包括但不限于资源的长度、名称标识、状态标识、在整包中的位置等。其中，状态标识用于标记资源的加载状态，状态标识包括但不限于已下载、未下载、正在下载、待更新、已删除等。
本实施例中，还可为目标游戏维护一个资源管理文件，上述的至少一个资源的属性信息可配置在资源管理文件中，当然，资源管理文件中还可包含其它管理信息，例如，资源版本信息、整包的包头信息等。基于资源管理文件，可将至少一个资源的属性信息整合到一起，从而实现对至少一个资源集中统一的管理，而改变传统的“小资源包”方式中资源各自为政的局面。而且，将至少一个资源的属性信息整合到一个资源管理文件中，可大大减少了文件数量，便于资源管理。
基于此，游戏资源管理设备10可将资源管理文件、资源依赖文件和至少一个资源上传至资源服务器20中，以供游戏客户端30基于资源管理文件和资源依赖文件从资源服务器20中下载所需的资源。其中，资源管理文件和资源依赖文件作为至少一个资源的管理和加载依据。
游戏加载阶段
在该阶段，主要阐述在游戏运行过程中，边玩边下的游戏加载方式。当然，本实施例中，游戏客户端30也可在目标游戏运行之前即将所有资源下载完毕，这种情况下，游戏运行过程中将不再需要从资源服务器20中下载资源，而可直接从游戏客户端30的本地中提取资源进行加载，从而支持游戏的运行。
边玩边下的游戏加载方式是指，在游戏运行过程中，若需要加载的资源未预先存储到游戏客户端30中，游戏客户端30可从资源服务器20中下载该资源，并在下载完成中，加载该资源，以支持游戏的运行。
本实施例中，对游戏客户端30来说，可在目标游戏的运行过程中，响应于资源加载请求，确定待加载的目标资源；根据目标游戏下的资源依赖文件，查找目标资源的依赖资源；若根据目标游戏下的资源管理文件确定需要下载目标资源及其依赖资源，则从资源服务器20中下载目标资源及其依赖资源；加载目标资源。
游戏客户端30可从资源服务器20中获取目标游戏下的资源依赖文件和资源管理文件，作为资源加载的依据。其中，正如前文提及的，资源管理文件中可包含至少一个资源的状态标识，基于此，游戏客户端30可根据目标资源及其依赖资源的状态标识，确定目标资源及其依赖资源是否需要下载或更新。这使得游戏客户端30可合理地确定出需要下载的资源范围，该资源范围中至少包含目标资源及其依赖资源，当然，该资源范围中还可包含其它与目标资源及其依赖资源存在关联的资源，以充分利用网络带宽。
在下载完成中，游戏客户端30可加载目标资源，以支持目标游戏的运行。当然，由于目标资源的依赖资源也已经下载到游戏客户端30中，因此，游戏客户端30也可按需加载目标资源的依赖资源，以支持目标游戏的运行。
从而，本实施例中，不再以资源包作为下载单位，而是以基于目标游戏下的资源依赖文件和资源管理文件确定出的资源范围为下载单位，这可保证对目标资源进行加载时所需下载的资源足够全面(至少包含目标资源及其依赖资源)而且数量级低(不再需要按资源包下载)。与传统的“大资源包”方案相比，本实施例确定出的资源范围远小于“大资源包”，从而避免了单次下载时长过大的问题，保证资源下载时长不影响游戏加载速度。与传统的“小资源包”方案相比，不再涉及到多资源包并发下载的情况，从而避免资源包的数量级带来的问题；而且，游戏加载过程中只需加载一个资源管理文件即可获取到至少一个资源的属性信息，大大减少了文件下载数量，更便于资源管理。因此，本实施例中，可支持边玩边下的游戏加载方式，且可保证目标游戏的运行流畅度。
在上述或下述实施例中，不同游戏引擎的文件读写方式不完全相同，例如，类ue4游戏引擎支持修改文件读写接口，而类unity游戏引擎则不支持修改文件读写接口。对于支持修改文件读写接口的情况，本实施例中，可将游戏引擎的文件读写接口修改为从资源包中读取资源，而不再采用直接从磁盘或者从引擎的包读取方式。为此，本实施例中，可分别为支持从资源包中读取资源的情况和不支持从资源包中读取资源的情况提供了不同的解决方案。
以下先对游戏客户端30支持从资源包中读取资源的情况进行说明。
在游戏资源管理阶段
在该情况下，若游戏资源管理设备10接收到的资源管理请求为针对目标游戏的初次管理请求，则游戏资源管理设备10可将至少一个资源打包为至少一个整包；将至少一个资源的属性信息分别配置到其所在整包的包头信息中；基于至少一个整包的包头信息，构建资源管理文件。
在整包制备过程中，游戏资源管理设备10可对至少一个资源进行烘焙，从而可按散资源的方式使用至少一个资源。在打包过程中，可尽量将至少一个资源打包为一个整包，而若至少一个资源的累积长度超过指定的分包长度，则可分出更多的整包，也即将至少一个资源打包为至少一个整包。实际应用中，分包长度可低于系统要求的整包长度，例如，可以是系统要求的整包长度的一半。这是由于，目标游戏下的资源可能会发生后文中提及的新增等情况，而这里可为这些情况提前预留长度，以避免膨胀后的整包超出系统要求。
一种示例性的打包方案可以是：按照指定的分包长度，从至少一个资源中选择至少一个未打包资源进行打包，以获得至少一个整包。实际应用中，可从至少一个资源中选择未打包资源，若选到第n(n为正整数)个未打包资源时的累积选中资源长度大于或等于分包长度，则将选到的n个未打包资源打包至当前整包中，并开启下一个整包；继续选择至少一个资源中的其它未打包资源，直至将至少一个资源全部打包至相应的整包中，以获得至少一个整包。
例如，若资源的总量是1000个，首先，可开启第一个整包，并从1000个资源中按个选取资源，当选到第100个时，累积选中资源长度超过了分包长度，则可将这100个资源打包到第一个整包中；开启第二个整包，并继续从剩余的900个资源中继续选择，若这次选到第80个资源时，累积选中资源长度超过了分包长度，则可将这次选到的80个资源打包到第二个整包中；在继续开启第三个整包，直至将1000个资源都打包到某个整包中，比如可能需要开启8个整包，则通过打包操作，可获得8个整包。
在打包过程中，可对至少一个资源进行压缩。另外，还可记录至少一个资源的名称标识、在整包中的位置、长度以及资源之间的初代依赖关系等，这些记录信息可配置到至少一个资源的属性信息中。还可为至少一个资源分别缺省一个状态标识，用来记录资源状态，例如，若某一资源已经携带在游戏安装包中，则可将该资源的状态标识设置为已下载，因为游戏安装后，该资源已经随安装包释放到游戏客户端30的本地，而不再需要下载。又例如，对于未携带在游戏安装包中的资源，则可将状态标识设置为未下载。值得说明的是，至少一个资源的状态标识是可按照实际情况进行更新的，因此，在此时的打包过程中，只需按真实状态设置状态标识即可。
本实施例中，还可为至少一个整包分别维护一个包头信息，整包的包头信息中可包括整包的长度、名称标识等。另外，还可将至少一个资源的属性信息分别配置到其所在整包的包头信息中。在此基础上，可基于至少一个整包的包头信息，构建目标游戏下的资源管理文件。据此，资源管理文件中可包含整包的长度、名称标识、资源在整包中的位置及长度、名称标识、状态标识、资源版本信息等等。总之，资源管理文件中可包含用于管理至少一个资源所需的各种信息，以作为管理依据，从而对至少一个资源进行集中统一的管理，这样，本实施例中，游戏服务器只需存储一个资源管理文件和整包文件，即可实现对资源的管理，所需存储的数量少，管理的便捷性更高。
这样，经过上述处理后，可获得目标游戏下的一个资源管理文件、一个资源依赖文件和至少一个整包。游戏资源管理设备10可将目标游戏下的资源管理文件、资源依赖文件和至少一个整包上传至资源服务器20。值得说明的是，本实施例中，提出了以至少一个资源的属性信息、整包的包头信息再到资源管理文件的层级式信息配置方式，但本实施例并不限于此，本实施例中，也可扁平化地在资源管理文件中记录上述各种信息，而不局限于属性信息、包头信息这些具体的信息配置模式。
在该情况下，若游戏资源管理设备10接收到的资源管理请求为针对目标游戏的非初次管理请求，则游戏资源管理设备10以及资源服务器20上已经存在上一次管理过程已经产生的资源管理文件、资源依赖文件和至少一个整包。这里我们将上一次管理过程已经产生的资源管理文件称为已有资源管理文件，将上一次管理过程已经产生的整包称为已有整包。
其中，非初次管理请求通常是在至少一个资源中的部分或全部资源发生变化的情况下发起，因此，这种情况下，游戏资源管理设备10可在目标游戏下确定已变化资源，并基于已变化资源，更新目标游戏下的已有整包和已有资源管理文件。
本实施例中，可根据已变化资源的变化信息，为目标游戏维护一个资源差异文件。资源差异文件用于记录目标游戏下资源的变化情况，从而保证游戏加载阶段可加载到最新的资源。
本实施例中，游戏资源管理设备10可将至少一个资源与目标游戏下的已有整包进行对比，以确定目标游戏下的内容已变化的第一类差异资源；将至少一个资源之间的依赖关系与目标资源下的已有资源依赖文件对比，以确定目标游戏下依赖关系已变化的第二类差异资源；将第一类差异资源的内容变化信息和第二类差异资源的依赖关系变化信息，配置到资源差异文件中。值得说明的是，这种情况下，至少一个资源为接到本次资源管理请求时目标游戏所使用的资源，也即是最新资源，与接到上一次资源管理请求时目标游戏所使用的资源可能存在不同。
据此，可完成对资源差异文件的维护。
如前文所述，游戏资源管理设备10还可基于已变化资源，对目标游戏下的已有整包和已有资源管理文件进行更新。在更新过程中：
若已变化资源为已删除资源，则游戏资源管理设备10可将已有整包中的对应资源删除，并在已有资源管理文件中更新已变化资源的属性信息；
若已变化资源为新增资源，则游戏资源管理设备10可将已变化资源打包至已有整包的已删除资源段，并在已有资源管理文件中更新已变化资源的对应的属性信息，或者，为已变化资源创建新属性信息以及已有整包中添加用于承载已变化资源的新资源段；
若已变化资源为修改资源，则游戏资源管理设备10可在已变化资源长度变大的情况下，在已有整包中删除原资源段并添加用于承载已变化资源的新资源段，以及为已变化资源创建新属性信息；在已变化资源长度变小或不变的情况下，更新已有整包中的对应资源段以及已有资源管理文件中的对应属性信息。
其中，上述对已有资源管理文件中的属性信息进行更新的过程中，可根据真实状态，将已变化资源对应的状态标识更新为已删除、已下载或未下载。
基于此，游戏资源管理设备10可将目标游戏下的资源差异文件、更新后的已有整包及已有资源管理文件再次上传至资源服务器20，以在资源服务器20上进行相应地更新。当然，本实施例中，游戏资源管理设备10还可基于已发生依赖关系变化的资源，对目标游戏下的已有资源依赖文件进行更新，并上传至资源服务器20。当然，也可不对资源依赖文件进行更新，而在后续的游戏加载过程中，由游戏客户端30结合资源差异文件及资源依赖文件来确定出最新的依赖关系，本实施例对此不作限定。
另外，正如前文提及的，资源管理文件中还可包含资源版本信息，据此，游戏资源管理设备10在响应针对目标游戏的非初次管理请求时，可在存在已变化资源的情况下，修改资源版本信息，并将修改后的资源版本信息更新至已有资源管理文件中，以便后续游戏加载阶段，游戏客户端30可根据资源版本信息判断目标游戏下的资源是否已经发生变化，从而可更加灵活地控制资源版本；而且更新后的资源也会被上传至游戏服务器中，游戏客户端可及时从游戏服务器中获取到最新版本的资源，而无需再通过安装补丁的方式进行资源更新，从而可实现资源热更新。
在游戏加载阶段
在该情况下，可在目标游戏的初始化过程中，确保游戏客户端30中的资源管理文件、资源依赖文件及资源差异文件为最新。以下分两种情形，说明目标游戏的初始化过程。
在一种情形下，游戏客户端30中第一次运行目标游戏，这种情形下，游戏客户端30的本地可能并不存在目标游戏下的已有整包。对此，游戏客户端30可从资源服务器20中下载目标游戏下的资源管理文件，并根据资源管理文件，在本地磁盘中分别创建用于承载至少一个整包的空文件。实际应用中，游戏客户端30可在本地磁盘中创建用于承载资源管理文件的空文件，这样，从资源管理器中下载的资源管理文件可存储在本地磁盘上，游戏客户端30可在本地磁盘中维护目标游戏下的资源管理文件。
本实施例中，资源下载到本地磁盘的过程可以是：资源服务器20将资源发送到游戏客户端30的本地网络缓存；游戏客户端30可将资源从本地网络缓存转存至内存；再基于在本地磁盘为整包创建的空文件，将资源从内存写入到本地磁盘中。当然，这仅是示例性的，本实施例并不限于此。
在资源下载过程中，游戏客户端30可将目标游戏下的至少一个整包分别划分为与网络参数适配的资源块，至少一个整包为对至少一个资源进行打包而获得的；根据资源管理文件，确定目标资源及其依赖资源所在的目标资源块；从资源服务器20中下载目标资源块。承接上述的资源下载到本地磁盘的过程，游戏客户端30可按资源块将整包下载到内存，在从内存写入到本地磁盘中相应的空文件中。应当理解的是，在进行磁盘io时，仍可以资源包为单位，因此，可保证磁盘io足够低。
其中，资源块的长度可与网络带宽适配，从而充分利用游戏客户端30的网络带宽。实际应用中，游戏客户端30可根据其网络带宽，确定资源块的长度；还可从目标游戏下的资源管理文件中，获取到整包的长度，从而可根据资源块的长度和整包的长度，将整包划分为合适数量的资源块。而且，游戏客户端30还可从资源管理文件中获取到目标资源的长度、在整包中的位置等信息，因此，游戏客户端30可计算出目标资源所在的资源块。这样，在目标资源的加载过程中，游戏客户端30确定出的资源范围将包括目标资源及其依赖资源，以及目标资源及其依赖资源各自所在资源块中个的其它资源。
在另一种情形下，若游戏客户端30中存在目标游戏下的已有整包和已有资源管理文件，则游戏客户端30可在确定目标游戏的资源版本信息已发生更新的情况下，从资源服务器20中下载资源差异文件，资源差异文件中包含目标游戏下已变化资源的变化信息；从资源服务器20中下载最新资源管理文件，并将已有资源管理文件中的状态标识更新至最新资源管理文件；基于资源差异文件，将存在内容变化的已变化资源在最新资源管理文件中的状态标识配置为待更新；使用更新后的最新资源管理文件覆盖已有资源管理文件。从而，游戏客户端30可及时发现资源版本的变化，并进行资源更新，从而更加灵活地控制资源版本。
其中，游戏客户端30可从资源服务器20中的最新资源管理文件中获取资源版本信息，并与本地的已有资源管理文件中的资源版本信息进行比对，如果不一致，则可确定目标游戏的资源版本信息已发生更新。
这种情形对应于前文提及的游戏资源管理设备10中发生了对目标游戏的非首次资源管理操作，游戏资源管理设备10向资源服务器20提供了资源差异文件，因此，这里，游戏客户端30可从资源服务器20中下载资源差异文件，以获知目标游戏下的资源变化情况。
游戏资源管理设备10还可从资源服务器20下载最新的资源管理文件，参考上文，在游戏资源管理阶段，游戏资源管理设备10维护的资源管理文件包含的资源的状态标识通常设定为已下载、未下载或已删除。但从游戏客户端30的角度来说，一方面，其可能已在游戏运行过程中下载了一部分在最新的资源管理文件中的状态标识为未下载的资源，当然，最新的资源管理文件中还可能存在游戏客户端30已经处理过的其它资源的状态标识不准确的问题。因此，本实施例中，可按照游戏客户端30本地的已有资源管理文件中的状态标识更新从资源服务器20上下载的最新的资源管理文件。另一方面，对于前述游戏客户端30已经处理过的资源，可能在资源服务器20中存在新的版本，为此，本实施例中，游戏客户端30可基于从资源服务器20上下载到的资源差异文件，在前一方面已经更新后的资源管理文件中将资源差异文件中记录的存在内容变化的资源的状态标识修改为待更新。这样，游戏客户端30可对本地的已有资源管理文件、从资源服务器20下载的最新资源管理文件以及资源差异文件进行整合，以整合出最准确的资源管理文件。
基于此，在游戏加载阶段，游戏客户端通过下载资源管理文件和整包文件即可实现资源加载，所需加载的文件数量少、复杂度低。而且，游戏客户端可在整合后的资源管理文件包含的目标资源及其依赖资源的状态标识为未下载或待更新时，确定目标资源及其依赖资源需要下载，进而对目标资源及其依赖资源进行下载，确定出的资源范围更加合理。另外，游戏客户端还可根据资源差异文件中包含的依赖关系变化信息以及资源依赖文件，确定目标资源的依赖资源，以保证准确确定目标资源的依赖资源。
以下再对游戏客户端30不支持从资源包中读取资源的情况进行说明。
在游戏资源管理阶段
在该情况下，游戏资源管理设备10不再对目标游戏所使用的至少一个资源进行打包，而是直接按照散资源的形式进行资源管理。但与游戏客户端30支持从资源包中读取资源的情况相同的是，游戏资源管理设备10依然会为目标游戏维护资源管理文件、资源依赖文件和资源差异文件，但在资源管理文件中与整包相关的管理信息可被摒弃。例如，资源管理文件中可仅保留资源的名称标识和状态标识，当然本实施例并不限于此。其中，关于资源管理文件、资源依赖文件和资源差异文件的维护过程可参考游戏客户端30支持从资源包中读取资源的情况下的技术细节，在此不再赘述。
基于此，游戏资源管理设备10可将目标游戏下的资源管理文件、资源依赖文件、资源差异文件上传至资源服务器20，并可按照散资源的方式将目标游戏所使用的至少一个资源上传至资源服务器20。
在游戏加载阶段
游戏客户端30可在游戏运行过程中，基于资源管理文件、资源依赖文件、资源差异文件，确定目标资源及其依赖资源、目标资源及其依赖资源是否需要进行下载，以及资源服务器20上是否存在目标资源及其依赖资源的新版本。实际应用中，游戏客户端30可以散资源的方式，从资源服务器20中下载目标资源及其依赖资源至目标游戏在游戏客户端30中的游戏目录中。
据此，在游戏客户端30不支持从资源包中读取资源的情况下，可通过资源管理文件对目标游戏所使用的至少一个资源进行集中统一的管理，并通过资源依赖文件、资源差异文件辅助确定资源是否需要下载以及资源是否存在新版本等，这样，不再涉及到资源包的管理和下载，而是可以散资源为单位进行资源管理和下载，因此，可节省大量的磁盘io，避免资源包的数量级产生的问题。
同样，在该情况下，游戏客户端30可在资源管理文件包含的目标资源及其依赖资源的状态标识为未下载或待更新时，确定目标资源及其依赖资源需要下载。还可根据资源差异文件中包含的依赖关系变化信息以及资源依赖文件，确定目标资源的依赖资源。
图2为本申请一实施例提供的一种游戏资源管理方法的流程示意图。该方法适用于游戏系统中的游戏资源管理设备，本实施例提供的游戏资源管理方法可以由一游戏资源管理装置来执行，该游戏资源管理装置可以实现为软件或实现为软件和硬件的组合，该游戏资源管理装置可集成设置在计算设备中。如图2所示，该方法包括：
步骤200、响应于资源管理请求，确定目标游戏所使用的至少一个资源；
步骤201、构建至少一个资源之间的依赖关系，以生成资源依赖文件；
步骤202、将至少一个资源的属性信息配置到资源管理文件中；
步骤203、将资源管理文件、资源依赖文件和至少一个资源上传至资源服务器中，以供游戏客户端基于资源管理文件和资源依赖文件从资源服务器中下载所需的资源。
在上述或下述实施例中，不同游戏引擎的文件读写方式不完全相同，例如，类ue4游戏引擎支持修改文件读写接口，而类unity游戏引擎则不支持修改文件读写接口。对于支持修改文件读写接口的情况，本实施例中，可将游戏引擎的文件读写接口修改为从资源包中读取资源，而不再采用直接从磁盘或者从引擎的包读取方式。为此，本实施例中，可分别为支持从资源包中读取资源的情况和不支持从资源包中读取资源的情况提供了不同的解决方案。
本实施例中，若游戏客户端支持从资源包中读取资源，则步骤202，可包括：
若资源管理请求为针对目标游戏的初次管理请求，则将至少一个资源打包为至少一个整包；
将至少一个资源的属性信息分别配置到其所在整包的包头信息中；
基于至少一个整包的包头信息，构建资源管理文件。
这种情况下，若资源管理请求为针对目标游戏的非初次管理请求，则步骤202可包括：在目标游戏下存在已变化资源的情况下，基于已变化资源，更新目标游戏下的已有整包和已有资源管理文件。
这种情况下，该方法还可包括：
根据已变化资源的变化信息，维护一个资源差异文件；
将资源差异文件上传至资源服务器中。
可选地，步骤根据已变化资源的变化信息，维护一个资源差异文件，包括：
将至少一个资源与目标游戏下的已有整包进行对比，以确定目标游戏下的内容已变化的第一类差异资源；
将至少一个资源之间的依赖关系与目标资源下的已有资源依赖文件对比，以确定目标游戏下依赖关系已变化的第二类差异资源；
将第一类差异资源的内容变化信息和第二类差异资源的依赖关系变化信息，配置到资源差异文件中。
可选地，该方法，还可包括：
修改目标游戏的资源版本信息，并将修改后的资源版本信息更新至已有资源管理文件中。
这种情况下，步骤基于已变化资源，更新目标游戏下的已有整包和已有资源管理文件，可包括：
若已变化资源为已删除资源，则将已有整包中的对应资源删除，并在已有资源管理文件中更新已变化资源的属性信息；
若已变化资源为新增资源，则将已变化资源打包至已有整包的已删除资源段，并在已有资源管理文件中更新已变化资源的对应的属性信息，或者，为已变化资源创建新属性信息以及已有整包中添加用于承载已变化资源的新资源段；
若已变化资源为修改资源，则在已变化资源长度变大的情况下，在已有整包中删除原资源段并添加用于承载已变化资源的新资源段，以及为已变化资源创建新属性信息；在第一类差异资源长度变小或不变的情况下，更新已有整包中的对应资源段以及已有资源管理文件中的对应属性信息。
可选地，步骤将至少一个资源上传至资源服务器中，可包括：
将至少一个整包上传至资源服务器中。
其中，上述的属性信息包括：在整包中的位置、长度、名称标识和状态标识中的一种或多种。
其中，状态标识包括已下载、未下载、下载中、待更新和已删除中的一种或多种。
若游戏客户端不支持从资源包中读取资源，则步骤将至少一个资源上传至资源服务器中，可包括：
按照散资源的方式，将至少一个资源上传至资源服务器中。
在该情况下，该方法还可包括：
若资源管理请求为针对目标游戏的非初次管理请求，则在目标游戏下存在已变化资源的情况下，根据已变化资源的变化信息，维护一个资源差异文件；
将资源差异文件上传至资源服务器中。
可选地，步骤将至少一个资源打包为至少一个整包，可包括：
按照指定的分包长度，从至少一个资源中选择至少一个未打包资源进行打包，以获得至少一个整包。
可选地，步骤按照指定的分包长度，从至少一个资源中选择至少一个未打包资源进行打包，以获得至少一个整包，可包括：
从至少一个资源中选择未打包资源，若选到第n个未打包资源时的累积选中资源长度大于或等于分包长度，则将选到的n个未打包资源打包至当前整包中，并开启下一个整包；
继续选择至少一个资源中的其它未打包资源，直至将至少一个资源全部打包至相应的整包中，以获得至少一个整包。
值得说明的是，上述方法实施例中的技术细节可参考前述游戏系统中的相关描述，为节省篇幅，在此不再赘述，但这不应造成对本申请保护范围的损失。
图3为本申请一示例性实施例提供的一种游戏加载方法的流程图，该方法适用于游戏系统中的游戏客户端，本实施例提供的游戏加载方法可以由一游戏加载装置来执行，该游戏加载装置可以实现为软件或实现为软件和硬件的组合，该游戏加载装置可集成设置在计算设备中。如图3所示，该方法包括：包括：
步骤300、在目标游戏的运行过程中，响应于资源加载请求，确定待加载的目标资源；
步骤301、根据目标游戏下的资源依赖文件，查找目标资源的依赖资源；
步骤302、若根据目标游戏下的资源管理文件确定需要下载目标资源及其依赖资源，则从资源服务器中下载目标资源及其依赖资源；其中，资源管理文件中包含目标游戏所使用的至少一个资源的属性信息；
步骤303、加载目标资源。
在上述或下述实施例中，不同游戏引擎的文件读写方式不完全相同，例如，类ue4游戏引擎支持修改文件读写接口，而类unity游戏引擎则不支持修改文件读写接口。对于支持修改文件读写接口的情况，本实施例中，可将游戏引擎的文件读写接口修改为从资源包中读取资源，而不再采用直接从磁盘或者从引擎的包读取方式。为此，本实施例中，可分别为支持从资源包中读取资源的情况和不支持从资源包中读取资源的情况提供了不同的解决方案。
一种情况下，若游戏客户端支持从资源包中读取资源，则步骤302可包括：
将目标游戏下的至少一个整包分别划分为与网络参数适配的资源块，至少一个整包为对至少一个资源进行打包而获得的；
根据资源管理文件，确定目标资源及其依赖资源所在的目标资源块；
从资源服务器中下载目标资源块。
其中，资源块的长度与网络带宽适配。
在这种情况下，该方法还可包括：
在目标游戏的初始化过程中，若目标游戏在游戏客户端中不存在已有整包，则根据资源管理文件，在本地磁盘中分别创建用于承载至少一个整包的空文件。
在这种情况下，该方法还可包括：
在目标游戏的初始化过程中，若目标游戏在游戏客户端中存在已有整包和已有资源管理文件，则在确定目标游戏的资源版本信息已发生更新的情况下，从资源服务器中下载资源差异文件，资源差异文件中包含目标游戏下已变化资源的变化信息；
从资源服务器中下载最新资源管理文件，并将已有资源管理文件中的状态标识更新至最新资源管理文件；
基于资源差异文件，将存在内容变化的已变化资源在最新资源管理文件中的状态标识配置为待更新；
使用更新后的最新资源管理文件覆盖已有资源管理文件。
在另一种情况下，若游戏客户端不支持从资源包中读取资源，则步骤302可包括：
从资源服务器中下载目标资源及其依赖资源至目标游戏在游戏客户端中的游戏目录中。
在一种可选实施例中，该方法还可包括：
在目标游戏运行过程中，若游戏客户端中的资源管理文件包含的目标资源及其依赖资源的状态标识为未下载或待更新，则确定目标资源及其依赖资源需要下载。
在一种可选实施例中，步骤301可包括：
根据资源差异文件中包含的依赖关系变化信息以及资源依赖文件，确定目标资源的依赖资源。
值得说明的是，上述方法实施例中的技术细节可参考前述游戏系统中的相关描述，为节省篇幅，在此不再赘述，但这不应造成对本申请保护范围的损失。
需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤301至步骤303的执行主体可以为设备a；又比如，步骤301和302的执行主体可以为设备a，步骤303的执行主体可以为设备b；等等。
另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如301、302等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。
图4为本申请另一示例性实施例提供的一种游戏资源管理设备的结构示意图。参考图4，该设备可包括：存储器40、处理器41以及通信组件42
存储器40用于存储一条或多条计算机指令；
处理器41与存储器40和通信组件42耦合，用于执行一条或多条计算机指令，以用于：
响应于资源管理请求，确定目标游戏所使用的至少一个资源；
构建至少一个资源之间的依赖关系，以生成资源依赖文件；
将至少一个资源的属性信息配置到资源管理文件中；
通过通信组件42将资源管理文件、资源依赖文件和至少一个资源上传至资源服务器中，以供游戏客户端基于资源管理文件和资源依赖文件从资源服务器中下载所需的资源。
在一可选实施例中，若游戏客户端支持从资源包中读取资源，则处理器41将至少一个资源的属性信息配置到资源管理文件中时，用于：
若资源管理请求为针对目标游戏的初次管理请求，则将至少一个资源打包为至少一个整包；
将至少一个资源的属性信息分别配置到其所在整包的包头信息中；
基于至少一个整包的包头信息，构建资源管理文件。
在一可选实施例中，处理器41在将至少一个资源的属性信息配置到资源管理文件中，还用于：
若资源管理请求为针对目标游戏的非初次管理请求，则在目标游戏下存在已变化资源的情况下，基于已变化资源，更新目标游戏下的已有整包和已有资源管理文件。
在一可选实施例中，处理器41还用于：
根据已变化资源的变化信息，维护一个资源差异文件；
将资源差异文件上传至资源服务器中。
在一可选实施例中，处理器41在根据已变化资源的变化信息，维护一个资源差异文件时，用于：
将至少一个资源与目标游戏下的已有整包进行对比，以确定目标游戏下的内容已变化的第一类差异资源；
将至少一个资源之间的依赖关系与目标资源下的已有资源依赖文件对比，以确定目标游戏下依赖关系已变化的第二类差异资源；
将第一类差异资源的内容变化信息和第二类差异资源的依赖关系变化信息，配置到资源差异文件中。
在一可选实施例中，处理器41还用于：
修改目标游戏的资源版本信息，并将修改后的资源版本信息更新至已有资源管理文件中。
在一可选实施例中，处理器41在基于已变化资源，更新目标游戏下的已有整包和已有资源管理文件时，用于：
若已变化资源为已删除资源，则将已有整包中的对应资源段删除，并在已有资源管理文件中更新已变化资源的属性信息；
若已变化资源为新增资源，则将已变化资源打包至已有整包的已删除资源段，并在已有资源管理文件中更新已变化资源的对应的属性信息，或者，为已变化资源创建新属性信息以及已有整包中添加用于承载已变化资源的新资源段；
若已变化资源为修改资源，则在已变化资源长度变大的情况下，在已有整包中删除原资源段并添加用于承载已变化资源的新资源段，以及为已变化资源创建新属性信息；在已变化资源长度变小或不变的情况下，更新已有整包中的对应资源段以及已有资源管理文件中的对应属性信息。
在一可选实施例中，处理器41在将至少一个资源上传至资源服务器中时，用于：
将至少一个整包上传至资源服务器中。
在一可选实施例中，属性信息包括：在整包中的位置、长度、名称标识和状态标识中的一种或多种。
在一可选实施例中，状态标识包括已下载、未下载、下载中、待更新和已删除中的一种或多种。
在一可选实施例中，若游戏客户端不支持从资源包中读取资源，则处理器41在将至少一个资源上传至资源服务器中时，用于：
按照散资源的方式，将至少一个资源上传至资源服务器中。
在一可选实施例中，处理器41还用于：
若资源管理请求为针对目标游戏的非初次管理请求，则在目标游戏下存在已变化资源的情况下，根据已变化资源的变化信息，维护一个资源差异文件；
将资源差异文件上传至资源服务器中。
可选地，处理器41在将至少一个资源打包为至少一个整包时，用于：
按照指定的分包长度，从至少一个资源中选择至少一个未打包资源进行打包，以获得至少一个整包。
可选地，处理器41在按照指定的分包长度，从至少一个资源中选择至少一个未打包资源进行打包，以获得至少一个整包时，用于：
从至少一个资源中选择未打包资源，若选到第n个未打包资源时的累积选中资源长度大于或等于分包长度，则将选到的n个未打包资源打包至当前整包中，并开启下一个整包；
继续选择至少一个资源中的其它未打包资源，直至将至少一个资源全部打包至相应的整包中，以获得至少一个整包。
进一步，如图4所示，该游戏资源管理设备还包括：电源组件43等其它组件。图4中仅示意性给出部分组件，并不意味着游戏资源管理设备只包括图4所示组件。
值得说明的是，上述关于游戏资源管理设备各实施例中的技术细节，可参考前述的系统实施例中的相关描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。
相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由游戏资源管理设备执行的各步骤。
图5为本申请另一示例性实施例提供的一种游戏客户端的结构示意图。如图5所示，该游戏客户端包括：存储器50、处理器51以及通信组件52。
处理器51，与存储器50和通信组件52耦合，用于执行存储器中的计算机程序，以用于：
在目标游戏的运行过程中，响应于资源加载请求，确定待加载的目标资源；
根据目标游戏下的资源依赖文件，查找目标资源的依赖资源；
若根据目标游戏下的资源管理文件确定需要下载目标资源及其依赖资源，则通过通信组件52从资源服务器中下载目标资源及其依赖资源；其中，资源管理文件中包含目标游戏所使用的至少一个资源的属性信息；
加载目标资源。
在一可选实施例中，若游戏客户端支持从资源包中读取资源，则处理器51在从资源服务器中下载目标资源及其依赖资源时，用于：
将目标游戏下的至少一个整包分别划分为与网络参数适配的资源块，至少一个整包为对至少一个资源进行打包而获得的；
根据资源管理文件，确定目标资源及其依赖资源所在的目标资源块；
从资源服务器中下载目标资源块。
在一可选实施例中，资源块的长度与网络带宽适配。
在一可选实施例中，处理器51还用于：
在目标游戏的初始化过程中，若目标游戏在游戏客户端中不存在已有整包，则根据资源管理文件，在本地磁盘中分别创建用于承载至少一个整包的空文件。
在一可选实施例中，处理器51还用于：
在目标游戏的初始化过程中，若目标游戏在游戏客户端中存在已有整包和已有资源管理文件，则在确定目标游戏的资源版本信息已发生更新的情况下，从资源服务器中下载资源差异文件，资源差异文件中包含目标游戏下已变化资源的变化信息；
从资源服务器中下载最新资源管理文件，并将已有资源管理文件中的状态标识更新至最新资源管理文件；
基于资源差异文件，将存在内容变化的已变化资源在最新资源管理文件中的状态标识配置为待更新；
使用更新后的最新资源管理文件覆盖已有资源管理文件。
在一可选实施例中，若游戏客户端不支持从资源包中读取资源，则处理器51在从资源服务器中下载目标资源及其依赖资源时，用于：
从资源服务器中下载目标资源及其依赖资源至目标游戏在游戏客户端中的游戏目录中。
在一可选实施例中，处理器51还用于：
在目标游戏运行过程中，若游戏客户端中的资源管理文件包含的目标资源及其依赖资源的状态标识为未下载或待更新，则确定目标资源及其依赖资源需要下载。
在一可选实施例中，处理器51在根据目标游戏下的资源依赖文件，查找目标资源的依赖资源时，用于：
根据资源差异文件中包含的依赖关系变化信息以及资源依赖文件，确定目标资源的依赖资源。
进一步，如图5所示，该游戏客户端设备还包括：显示器53、电源组件54、音频组件55等其它组件。图5中仅示意性给出部分组件，并不意味着游戏客户端只包括图5所示组件。
值得说明的是，上述关于游戏客户端各实施例中的技术细节，可参考前述的系统实施例中的相关描述，为节省篇幅，在此不再赘述，但这不应造成本申请保护范围的损失。
相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由游戏客户端执行的各步骤。
上述图4和5中的存储器，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。
上述图4和5中的通信组件，被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如wifi，2g、3g、4g/lte、5g等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。
上述图5中的显示器，包括屏幕，其屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。
上述图4和5中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。
上述图5中的音频组件，可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(mic)，当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
1.一种游戏资源管理方法，其特征在于，包括：
响应于资源管理请求，确定目标游戏所使用的至少一个资源；
构建所述至少一个资源之间的依赖关系，以生成资源依赖文件；
将所述至少一个资源的属性信息配置到资源管理文件中；
将所述资源管理文件、所述资源依赖文件和所述至少一个资源上传至资源服务器中，以供游戏客户端基于所述资源管理文件和所述资源依赖文件从所述资源服务器中下载所需的资源。
2.根据权利要求1所述的方法，其特征在于，若所述游戏客户端支持从资源包中读取资源，则所述将所述至少一个资源的属性信息配置到资源管理文件中，包括：
若所述资源管理请求为针对所述目标游戏的初次管理请求，则将所述至少一个资源打包为至少一个整包；
将所述至少一个资源的属性信息分别配置到其所在整包的包头信息中；
基于所述至少一个整包的包头信息，构建所述资源管理文件。
3.根据权利要求2所述的方法，其特征在于，所述将所述至少一个资源的属性信息配置到资源管理文件中，还包括：
若所述资源管理请求为针对所述目标游戏的非初次管理请求，则在所述目标游戏下存在已变化资源的情况下，基于所述已变化资源，更新所述目标游戏下的已有整包和已有资源管理文件。
4.根据权利要求3所述的方法，其特征在于，还包括：
根据所述已变化资源的变化信息，维护一个资源差异文件；
将所述资源差异文件上传至所述资源服务器中，以供所述游戏客户端根据所述资源差异文件进行资源更新。
5.根据权利要求4所述的方法，其特征在于，所述根据所述已变化资源的变化信息，维护一个资源差异文件，包括：
将至少一个资源与所述目标游戏下的已有整包进行对比，以确定所述目标游戏下的内容已变化的第一类差异资源；
将所述至少一个资源之间的依赖关系与所述目标资源下的已有资源依赖文件对比，以确定所述目标游戏下依赖关系已变化的第二类差异资源；
将所述第一类差异资源的内容变化信息和所述第二类差异资源的依赖关系变化信息，配置到所述资源差异文件中。
6.根据权利要求3所述的方法，其特征在于，还包括：
修改所述目标游戏的资源版本信息，并将修改后的资源版本信息更新至所述已有资源管理文件中，以供所述游戏客户端在所述目标游戏的资源版本信息发生更新的情况下，对所述目标游戏进行资源更新。
7.根据权利要求3所述的方法，其特征在于，所述基于所述已变化资源，更新所述目标游戏下的已有整包和已有资源管理文件，包括：
若所述已变化资源为已删除资源，则将所述已有整包中的对应资源段删除，并在所述已有资源管理文件中更新所述已变化资源的属性信息；
若所述已变化资源为新增资源，则将所述已变化资源打包至所述已有整包的已删除资源段，并在所述已有资源管理文件中更新所述已变化资源的对应的属性信息，或者，为所述已变化资源创建新属性信息以及所述已有整包中添加用于承载所述已变化资源的新资源段；
若所述已变化资源为修改资源，则在所述已变化资源长度变大的情况下，在所述已有整包中删除原资源段并添加用于承载所述已变化资源的新资源段，以及为所述已变化资源创建新属性信息；在所述已变化资源长度变小或不变的情况下，更新所述已有整包中的对应资源段以及所述已有资源管理文件中的对应属性信息。
8.根据权利要求2所述的方法，其特征在于，所述将所述至少一个资源打包为至少一个整包，包括：
按照指定的分包长度，从所述至少一个资源中选择至少一个未打包资源进行打包，以获得至少一个整包。
9.根据权利要求8所述的方法，其特征在于，所述按照指定的分包长度，从所述至少一个资源中选择至少一个未打包资源进行打包，以获得至少一个整包，包括：
从所述至少一个资源中选择未打包资源，若选到第n个未打包资源时的累积选中资源长度大于或等于所述分包长度，则将选到的所述n个未打包资源打包至当前整包中，并开启下一个整包；
继续选择所述至少一个资源中的其它未打包资源，直至将所述至少一个资源全部打包至相应的整包中，以获得至少一个整包。
10.根据权利要求2或3任一项所述的方法，其特征在于，所述将所述至少一个资源上传至资源服务器中，包括：
将所述至少一个整包上传至所述资源服务器中，以供所述游戏客户端将所述目标游戏下的至少一个整包分别划分为与网络参数适配的资源块，并以资源块为单位进行资源下载。
11.根据权利要求2-9任一项所述的方法，其特征在于，所述属性信息包括：在整包中的位置、长度、名称标识和状态标识中的一种或多种。
12.根据权利要求11所述的方法，其特征在于，所述状态标识包括已下载、未下载、下载中、待更新和已删除中的一种或多种。
13.根据权利要求1所述的方法，其特征在于，若所述游戏客户端不支持从资源包中读取资源，则所述将所述至少一个资源上传至资源服务器中，包括：
按照散资源的方式，将所述至少一个资源上传至所述资源服务器中，以供所述游戏客户端将游戏加载所需的资源下载至为所述目标游戏配置的游戏目录中。
14.根据权利要求13所述的方法，其特征在于，还包括：
若所述资源管理请求为针对所述目标游戏的非初次管理请求，则在所述目标游戏下存在已变化资源的情况下，根据所述已变化资源的变化信息，维护一个资源差异文件；
将所述资源差异文件上传至所述资源服务器中，以供所述游戏客户端根据所述资源差异文件进行资源更新。
15.一种游戏加载方法，适用于游戏客户端，其特征在于，包括：
在目标游戏的运行过程中，响应于资源加载请求，确定待加载的目标资源；
根据所述目标游戏下的资源依赖文件，查找所述目标资源的依赖资源；
若根据所述目标游戏下的资源管理文件确定需要下载所述目标资源及其依赖资源，则从资源服务器中下载所述目标资源及其依赖资源；其中，所述资源管理文件中包含所述目标游戏所使用的至少一个资源的属性信息；
加载所述目标资源。
16.根据权利要求15所述的方法，其特征在于，若所述游戏客户端支持从资源包中读取资源，所述方法还包括：
在所述目标游戏的初始化过程中，若所述目标游戏在所述游戏客户端中存在已有整包和已有资源管理文件，则在确定所述目标游戏的资源版本信息已发生更新的情况下，从所述资源服务器中下载资源差异文件，所述资源差异文件中包含所述目标游戏下已变化资源的变化信息；
从所述资源服务器中下载最新资源管理文件，并将所述已有资源管理文件中的状态标识更新至所述最新资源管理文件；
基于所述资源差异文件，将存在内容变化的已变化资源在所述最新资源管理文件中的状态标识配置为待更新；
使用更新后的所述最新资源管理文件覆盖所述已有资源管理文件。
17.根据权利要求16所述的方法，其特征在于，还包括：
在所述目标游戏运行过程中，若所述游戏客户端中的资源管理文件包含的目标资源及其依赖资源的状态标识为未下载或待更新，则确定所述目标资源及其依赖资源需要下载。
18.一种游戏资源管理设备，其特征在于，包括存储器、处理器以及通信组件；
所述存储器用于存储一条或多条计算机指令；
所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：
响应于资源管理请求，确定目标游戏所使用的至少一个资源；
构建所述至少一个资源之间的依赖关系，以生成资源依赖文件；
将所述至少一个资源的属性信息配置到资源管理文件中；
通过所述通信组件将所述资源管理文件、所述资源依赖文件和所述至少一个资源上传至资源服务器中，以供游戏客户端基于所述资源管理文件和所述资源依赖文件从所述资源服务器中下载所需的资源。
19.一种游戏客户端，其特征在于，包括存储器、处理器以及通信组件；
所述存储器用于存储一条或多条计算机指令；
所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：
在目标游戏的运行过程中，响应于资源加载请求，确定待加载的目标资源；
根据所述目标游戏下的资源依赖文件，查找所述目标资源的依赖资源；
若根据所述目标游戏下的资源管理文件确定需要下载所述目标资源及其依赖资源，则通过所述通信组件从资源服务器中下载所述目标资源及其依赖资源；其中，所述资源管理文件中包含所述目标游戏所使用的至少一个资源的属性信息；
加载所述目标资源。
20.一种存储计算机指令的计算机可读存储介质，其特征在于，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行权利要求1-14任一项所述的游戏资源管理方法或权利要求15-17任一项所述的游戏加载方法。
技术总结