游戏资源的处理方法、装置以及服务端设备

技术领域

本申请涉及游戏技术领域，尤其是涉及一种游戏资源的处理方法、装置以及服务端设备。

背景技术

在很多网络游戏的游戏场景中存在有一定数量的游戏资源，例如，植被、宝箱、垃圾等游戏资源。目前，传统的网络游戏中需要管理的游戏资源数量较少，大约是几十个游戏资源，所以服务器采用简单进程对其进行处理即可。

但是，如果网络游戏的游戏场景非常大(数百平方千米)，其中涉及到的游戏资源数量非常多，在几百万个到上千万个的级别，服务器启动时的CPU开销和运行时内存的开销均较大，传统的服务器处理方法无法满足对大量游戏资源的管理，使得服务器无法承载大量的游戏资源数据。

发明内容

本发明的目的在于提供一种游戏资源的处理方法、装置以及服务端设备，以缓解目前服务器无法承载大量游戏资源数据的技术问题。

第一方面，本申请实施例提供了一种游戏资源的处理方法，所述方法包括：

获取所述游戏资源在游戏场景中的位置；

基于所述位置对多个所述游戏资源进行聚类，得到多个资源点集合；

根据所述资源点集合创建资源管理对象，其中，每个所述资源管理对象对应一个所述资源点集合，所述资源管理对象用于管理对应的所述资源点集合中的游戏资源的资源数据。

在一个可能的实现中，所述根据所述资源点集合创建资源管理对象的步骤之后，所述方法还包括：

基于客户端控制的虚拟对象在所述游戏场景中所处的当前位置，对所述当前位置的第一预设范围内的游戏资源对应的目标资源管理对象进行加载，以使所述客户端获取所述目标资源管理对象管理的资源数据。

在一个可能的实现中，所述游戏场景的整体占地范围按照预设单位面积被均匀划分成多个占地区域；所述基于客户端控制的虚拟对象在所述游戏场景中所处的当前位置，对所述当前位置的第一预设范围内的游戏资源对应的目标资源管理对象进行加载，以使所述客户端获取所述目标资源管理对象管理的资源数据的步骤，包括：

基于所述虚拟对象在所述游戏场景中所处的当前占地区域，从多个所述占地区域中确定所述当前占地区域的第一预设范围内的目标占地区域；

对位于所述目标占地区域中的目标资源点集合对应的目标资源管理对象进行加载，以使所述客户端获取所述目标资源管理对象管理的目标资源数据并基于所述目标资源数据对所述目标资源点集合中的目标资源进行显示和/或控制。

在一个可能的实现中，所述基于所述虚拟对象在所述游戏场景中所处的当前占地区域，从多个所述占地区域中确定所述当前占地区域的第一预设范围内的目标占地区域的步骤，包括：

基于客户端控制的虚拟对象在所述游戏场景中所处的当前占地区域，从多个所述占地区域中确定所述当前占地区域相邻的至少一个占地区域；

将所述当前占地区域和所述当前占地区域相邻的至少一个占地区域确定为目标占地区域。

在一个可能的实现中，所述根据所述资源点集合创建资源管理对象的步骤之后，还包括：

基于多个所述资源管理对象将每个所述资源管理对象管理的资源数据写入Redis数据库中，其中，所述Redis数据库用于通过加载所述资源管理对象查询和/或调取所述资源管理对象管理的资源数据。

在一个可能的实现中，所述基于多个所述资源管理对象将每个所述资源管理对象管理的资源数据写入Redis数据库中的步骤之后，所述方法还包括：

对预设时长内无加载事件发生的资源管理对象从所述Redis数据库中进行卸载。

在一个可能的实现中，所述基于所述位置对多个所述游戏资源进行聚类，得到多个资源点集合的步骤，包括：

遍历多个所述游戏资源，针对每个所述游戏资源执行以下步骤：

根据当前游戏资源在所述游戏场景中的目标位置，查询所述目标位置的第二预设范围内是否存在已生成的资源点集合；

如果第二预设范围内存在已生成的资源点集合，则将所述当前游戏资源加入至距离所述当前游戏资源最近的已生成的资源点集合中。

在一个可能的实现中，所述将所述当前游戏资源加入至距离所述当前游戏资源最近的已生成的资源点集合中的步骤之后，所述方法还包括：

基于加入所述当前游戏资源后的资源点集合进行集合的中心位置更新。

在一个可能的实现中，所述根据当前游戏资源在所述游戏场景中的目标位置，查询所述目标位置的第二预设范围内是否存在已生成的资源点集合的步骤之后，所述方法还包括：

如果第二预设范围内不存在已生成的资源点集合，则新建一个新资源点集合，将所述当前游戏资源加入至所述新资源点集合中，并将所述目标位置作为所述新资源点集合的中心位置。

在一个可能的实现中，所述资源数据包括下述任意一项或多项：

所述游戏资源的标识、模型路径、游戏资源在所述游戏场景中的位置坐标以及在所述游戏场景中的旋转信息。

第二方面，提供了一种游戏资源的处理装置，所述装置包括：

获取模块，用于获取所述游戏资源在游戏场景中的位置；

聚类模块，用于基于所述位置对多个所述游戏资源进行聚类，得到多个资源点集合；

创建模块，用于根据所述资源点集合创建资源管理对象，其中，每个所述资源管理对象对应一个所述资源点集合，所述资源管理对象用于管理对应的所述资源点集合中的游戏资源的资源数据。

第三方面，本申请实施例又提供了一种服务端设备，包括存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述的第一方面所述方法。

第四方面，本申请实施例又提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行上述的第一方面所述方法。

本申请实施例带来了以下有益效果：

本申请实施例提供的一种游戏资源的处理方法、装置以及服务端设备，能够基于游戏资源在游戏场景中的位置对多个游戏资源进行聚类从而得到多个资源点集合，然后再根据该资源点集合创建资源管理对象，其中的每个资源管理对象对应一个资源点集合，而资源管理对象用于管理其对应的资源点集合中的游戏资源的资源数据，本方案中，通过对大量的资源数据进行聚类，每个聚类出的资源点集合中的资源数据只利用一个资源管理对象来对其进行有效管理，使资源管理对象的数量仅为资源点集合的个数，大幅度减少了资源管理对象的数量，而且，根据游戏资源在游戏场景中的位置来分配资源管理对象的管理方式，也更加便于资源管理对象的有效管理，使资源管理效率提高，实现了服务器能够承载这些大量的资源数据并对其进行有效管理。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

图1为本申请实施例提供的游戏资源的处理方法的流程示意图；

图2为本申请实施例提供的游戏资源的处理方法中，原始文件的一个示例；

图3为本申请实施例提供的游戏资源的处理方法中，资源文件的一个示例；

图4为本申请实施例提供的游戏资源的处理方法中，聚类结果的一个示例；

图5为本申请实施例提供的游戏资源的处理方法中，数据库中储存的数据的一个示例；

图6为本申请实施例提供的游戏资源的处理方法中，占地区域的一个示例；

图7为本申请实施例提供的一种游戏资源的处理装置的结构示意图；

图8示出了本申请实施例所提供的一种服务端设备的结构示意图。

具体实施方式

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

本申请实施例中所提到的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括其他没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。目前，传统的网络游戏资源管理数量较少，大概是几十个游戏资源，因此服务器不需要特殊的处理，单个进程就是整个游戏世界，对于单个场景需要管理的资源数量有限，采用单个进程简单处理即可。而大世界技术框架(如MobileServer大世界技术框架)下的游戏场景巨大，一般的大世界游戏场景约有三百平方千米，这种大世界游戏场景中存在着大量的游戏资源。

申请人在长期的游戏研究过程中发现，上述传统的网络游戏资源管理方法存在以下缺陷：(1)传统的单个进程处理方法无法满足对较大数量游戏资源的管理，使得服务器利用单个进程无法承载大量的游戏资源数据。(2)对于游戏中长时间无用户访问的游戏资源缺少有效管理，使得该部分游戏资源长时间占用服务器资源，加重了性能消耗。

对于大世界技术框架下的游戏场景，服务器管理大量游戏资源过程的性能消耗较大，目前无法在有效管理服务器中海量游戏资源的同时又兼顾服务器的性能。

基于此，本申请实施例提供了一种游戏资源的处理方法、装置以及服务端设备，通过该方法可以缓解目前服务器无法承载大量游戏资源数据的技术问题。

下面结合附图对本发明实施例进行进一步地介绍。

图1为本申请实施例提供的一种游戏资源的处理方法的流程示意图。其中，该方法可以应用于游戏的服务端设备(例如，服务器)。如图1所示，该方法包括：

步骤S110，获取游戏资源在游戏场景中的位置。

其中，游戏资源可以为游戏场景中可以与玩家进行交互的任意资源。例如，植被、宝箱、垃圾等玩家可搜集的资源。

在实际应用中，本申请实施例中的游戏场景可以为上述大世界技术框架下的游戏场景。该游戏场景中的游戏资源的位置可以通过场景坐标的形式表示。

步骤S120，基于位置对多个游戏资源进行聚类，得到多个资源点集合。

本申请实施例中，服务端设备可以按照就近规则对多个游戏资源进行聚类，即位置较为接近的游戏资源聚为同一类。本步骤中，服务端设备可以遍历游戏原始数据文件中的各个游戏资源，根据其位置就近规则对各个游戏资源进行聚类，生成不同聚类结果对应的资源点集合。

步骤S130，根据资源点集合创建资源管理对象。

其中，每个资源管理对象对应一个资源点集合，资源管理对象用于管理对应的资源点集合中的游戏资源的资源数据。

需要说明的是，资源管理对象(Entity)是应用程序域中的一个概念，指的是实体对象，在计算机网络中，实体对象表示任何可能发送或接受信息的硬件或软件进程。在一般情况下，实体对象是一个特定的软件模块。本申请实施例中的资源管理对象为用于管理资源数据的实体对象。

本申请实施例中，服务端设备聚类出的每个资源点集合，均对应一个资源管理对象来对其中资源的数据进行管理，这种聚类的数据处理方式可以大幅度减少服务端设备运行时需要创建的资源管理实体资源管理对象的数量，使服务器能够承载这些大量的资源数据，而且，根据游戏资源在游戏场景中的位置来分配资源管理对象的管理方式，也更加便于资源管理对象的高效管理，使服务器能够对大量资源数据进行有效管理。

在实际应用中，本申请实施例提供的游戏资源的处理方法也可以作为一种基于大世界技术框架(如MobileServer)下的服务器海量(千万级)游戏资源管理方法，不仅能够更加有效的管理服务器中海量的资源数据，还能够通过减少需要创建的资源管理对象数量，缓解大世界网络游戏背景下管理海量游戏资源的性能消耗，实现了在管理海量游戏资源(如游戏资源的创建、刷新、玩家之间竞争处理)的同时，还兼顾服务器的性能，为玩家提供更加流畅的游戏体验。

下面对上述步骤进行详细介绍。

在一些实施例中，游戏资源的资源数据可以包含游戏资源多种方面的信息，以使游戏资源的资源数据更加全面，便于对其进行更加全面有效的管理。基于此，资源数据包括下述任意一项或多项：

游戏资源的标识、模型路径、游戏资源在游戏场景中的位置坐标以及在游戏场景中的旋转信息。

在实际应用中，服务端设备可以先导出这些游戏资源的资源数据，再对这些游戏资源进行聚类处理。示例性的，如图2所示，服务端设备可以基于客户端场景的加载规则，利用原始数据导出工具从游戏的运行服务器中导出资源数据的原始数据文件。

在导出资源数据后，服务端设备可以根据不同的游戏场景分别存储这些资源数据。例如，如图3所示，其中的每一行数据代表一个游戏资源；其中第一列表示该游戏资源的标识(如logic_id)，第二列表示该游戏资源的模型路径，之后的列表示该资源在游戏场景中的位置坐标以及旋转信息等数据。

通过游戏资源的标识、游戏资源的模型路径、游戏资源在游戏场景中的位置坐标以及旋转信息等数据，使游戏资源的资源数据更加全面，便于对其进行更加全面有效的管理。

在一些实施例中，上述步骤S120中的聚类过程可以通过在一定距离范围内查询资源点集合的方式来实现，以得到更加合适的聚类结果大小范围。作为一个示例，上述步骤S120可以包括如下步骤：

遍历多个游戏资源，针对每个游戏资源执行以下步骤：

步骤a)，根据当前游戏资源在游戏场景中的目标位置，查询目标位置的第二预设范围内是否存在已生成的资源点集合；

步骤b)，如果第二预设范围内存在已生成的资源点集合，则将当前游戏资源加入至距离当前游戏资源最近的已生成的资源点集合中。

对于上述步骤a)，示例性的，服务端设备可以遍历导出的所有资源数据。假设当前遍历到第i个资源数据，其对应的游戏资源为Di，根据Di在游戏场景中的位置坐标，利用固定半径长度查询以Di坐标为中心的附近一定半径范围内(即第二预设范围内)是否存在已生成的资源点集合。

对于上述步骤b)，示例性的，如果存在已生成的资源点集合，则以最小中心距离为原则从中选择出最合适的资源点集合，即其集合中心距离Di最近的资源点集合，如为集合N，则将Di加入到集合N的列表中。如图4所示，其中圆形中的多个黑色圆点表示属于同一个聚类结果(即资源点集合)。

本申请实施例中，可以针对每个资源数据，重复执行上述步骤a)和步骤b)，直到所有资源数据遍历完成。

需要说明的是，每个资源点集合管理该集合中的该部分资源数据，其中，资源点集合的半径(即聚类半径)不能太小也不能太大。如果半径太小则资源点集合的个数会过多使资源管理对象数量较多影响服务器性能，如果半径太大则使游戏体验较差，本申请实施例可以采用30米的预设半径。

通过上述步骤a)和步骤b)的这种聚类方式，可以使聚类出的资源点集合的范围不会过小也不会过大，以得到更加合适的资源点集合大小范围，从而在游戏体验和服务器性能之间实现更好的权衡。

基于上述步骤a)和步骤b)，还可以更新加入游戏资源后的资源点集合中心位置，以使资源点集合的中心位置达到实时准确，便于执行下一个游戏资源的聚类过程。作为一个示例，在步骤b)之后，该方法还可以包括以下步骤：

步骤c)，基于加入当前游戏资源后的资源点集合进行集合的中心位置更新。

对于上述步骤c)，集合中心位置的更新过程可以采用取平均值的方式实现，例如，计算加入当前游戏资源后的资源点集合中所有游戏资源位置坐标的平均值，即为该资源点集合的中心位置。通过对加入游戏资源后的资源点集合中心位置进行重新确定，使资源点集合的中心位置达到实时准确，便于执行下一个游戏资源的聚类过程。

基于上述步骤a)、步骤b)，在没有找到已生成的资源点集合的情况下，可以针对该当前游戏资源新建一个新的资源点集合。作为一个示例，在步骤a)之后，该方法还可以包括以下步骤：

步骤d)，如果第二预设范围内不存在已生成的资源点集合，则新建一个新资源点集合，将当前游戏资源加入至新资源点集合中，并将目标位置作为新资源点集合的中心位置。

对于上述步骤c)，示例性的，可以新建一个以Di(即当前游戏资源)为中心的新的集合Ni(即新资源点集合)，从而使当前游戏资源具有其更为合适的资源点集合。

在一些实施例中，可以将资源管理对象管理的资源数据单独储存于一个数据库中，以使游戏的正式运行服务器可以随时从该数据库中快速高效的查询、调取出这些资源数据。作为一个示例，在步骤S130之后，该方法还可以包括以下步骤：

步骤e)，基于多个资源管理对象将每个资源管理对象管理的资源数据写入Redis数据库中。

其中，Redis数据库是一种高性能的kv型内存数据库。Redis数据库用于通过加载资源管理对象查询和/或调取资源管理对象管理的资源数据。本步骤中，如图5所示，可以将导出的所有资源数据按照步骤S120中生成的资源点集合的设置方式，写入一个Redis服务器中，Redis服务器中有多个资源管理对象，Redis服务器可以通过加载资源管理对象来实现查询、调取以及更新资源数据等功能的使用。

通过Redis数据库可以对大量的资源数据进行更加高效的存储，利用Redis的高性能可以支持较大的查询范围。

基于上述步骤e)，为了进一步缓解服务器启动时CPU开销和运行时内存开销均较大的技术问题，对于较长时间无玩家查看的资源点集合，可以将其对应的资源管理对象从Redis数据库中卸载，以降低服务器的内存消耗。作为一个示例，在步骤e)之后，该方法还可以包括以下步骤：

步骤f)，对预设时长内无加载事件发生的资源管理对象从Redis数据库中进行卸载。

对于上述步骤f)，还可以根据一定的规则，从Redis服务器中卸载掉游戏过程中长时间无用户访问的资源点集合对应的资源管理对象。

通过上述步骤f)中的卸载过程，能够进一步减少实际需要创建的资源管理对象的数量，更加减少了服务器启动时的CPU开销和运行时内存的开销。

在一些实施例中，还可以就近仅加载玩家附近的资源管理对象，以在保证玩家完整体验的同时，减少服务器性能的消耗。作为一个示例，在步骤S130之后，该方法还可以包括以下步骤：

步骤g)，基于客户端控制的虚拟对象在游戏场景中所处的当前位置，对当前位置的第一预设范围内的游戏资源对应的目标资源管理对象进行加载，以使客户端获取目标资源管理对象管理的资源数据。

对于上述步骤g)，示例性的，可以在大世界技术框架的游戏场景中，将这个较大的游戏场景根据物理位置拆分成多个区域，将其分散在多个进程以承载其业务逻辑运行。服务器在启动之后，玩家控制的虚拟对象在游戏场景中的移动涉及到服务器进程的切换，达到区域切换的无缝衔接，对于控操作客户端的玩家来说可以无感知，使游戏体验游戏提高。

需要说明的是，本步骤中的虚拟对象与上述游戏资源指的是游戏场景中的不同对象。游戏资源是游戏本身设置有的内容，如宝箱、垃圾等等玩家可搜集的资源，其不受客户端的直接控制。而虚拟对象是玩家通过客户端可以直接控制的对象，而且并不是游戏本身设置有的内容，例如，玩家控制的游戏中的虚拟角色。

在实际应用中，本申请实施例中的资源管理对象可以结合感兴趣区域(Area OfInterest，简称AOI)的管理，支持游戏场景中的物体个体对一定半径范围内的游戏资源进行处理，在客户端实现只显示AOI附近的资源管理对象，进一步的减少客户端资源管理对象数量。

通过基于位置聚类出的资源点集合来创建资源管理对象，还结合了仅加载玩家一定范围内的资源管理对象，能够进一步减少实际需要创建的资源管理对象数量，更加减少了服务器启动时CPU开销和运行时内存开销。

基于上述步骤g)，可以利用划分的区域确定玩家附近范围的资源管理对象。作为一个示例，游戏场景的整体占地范围按照预设单位面积被均匀划分成多个占地区域；上述步骤g)可以包括如下步骤：

步骤h)，基于虚拟对象在游戏场景中所处的当前占地区域，从多个占地区域中确定当前占地区域的第一预设范围内的目标占地区域；

步骤i)，对位于目标占地区域中的目标资源点集合对应的目标资源管理对象进行加载，以使客户端获取目标资源管理对象管理的目标资源数据并基于目标资源数据对目标资源点集合中的目标资源进行显示和/或控制。

需要说明的是，本申请实施例中的目标占地区域还可以包括虚拟对象在游戏场景中所处的当前占地区域。

在实际应用中，大世界技术框架支持将巨大的游戏世界(Space)划分为不同的占地区域，以此来平衡负载。对于每个占地区域的划分，可按照特定尺寸(如50米*50米)将整体游戏场景进行占地区域的划分。为了节省性能消耗，可以选择只加载玩家当前坐标所在的占地区域及其周围的若干个占地区域范围内的资源管理对象，同时也能够使资源管理对象的加载范围更加合理且便于快速确认。

对于每个占地区域，还可以使用Redis数据库提供的范围查询接口,查询本占地区域范围内的资源点集合列表，每一个资源点集合对应一个服务器的资源管理对象，责管理资源点集合内部的所有游戏资源的资源数据，以及这些游戏资源与玩家之间的交互和通信。

此外，对于上述步骤e)中待卸载资源管理对象的确定方式，也可以利用上述占地区域实现，即对于长时间无玩家察看的占地区域，可以卸载该占地区域中的资源管理对象，以减少服务器性能的开销。当该占地区域再次有玩家进入之后，可以再次对其中的资源管理对象进行加载。

基于上述步骤h)和步骤i)，对于上述占地区域的占地形状，可以不对其进行具体的限制，以使占地区域的划分更加灵活。基于此，占地区域在游戏场景中的占地范围为下述任意一项的多边形结构：三角形、正方形、长方形、菱形、六边形。通过从多种形状中选择一种占地形状，可以使占地区域的划分更加灵活。

基于此，需要加载游戏资源的占地区域可以包括与当前占地区域相邻的若干个占地区域，避免玩家应该看到的游戏资源没有显示出来，以使玩家对游戏的体验全面完整。作为一个示例，上述步骤h)可以包括如下步骤：

步骤j)，基于客户端控制的虚拟对象在游戏场景中所处的当前占地区域，从多个占地区域中确定当前占地区域相邻的至少一个占地区域；

步骤k)，将当前占地区域和当前占地区域相邻的至少一个占地区域确定为目标占地区域。

通过加载与当前玩家所在占地区域相邻的若干个占地区域，能够避免玩家应该看到的游戏资源没有显示出来，以使玩家对游戏的体验全面完整。

基于上述步骤j)和步骤k)，占地区域可以是正方形结构，以使占地区域的划分更加合理且便于管理。基于此，占地区域在游戏场景中的占地范围为正方形结构；当前占地区域相邻的至少一个占地区域的数量为八个。

为了节省性能消耗，如图6所示，可以只加载玩家当前坐标所在的占地区域及其周围的八个占地区域范围内的资源管理对象，即玩家当前坐标所在的占地区域的上、下、左、右的四个边以及四个角的占地区域，形成九宫格的结构。

例如，每个占地区域均是50米*50米的正方形结构，这样玩家最少也可以看到附近50米范围内的资源点，使最短范围也可以达到50米，以在节省性能消耗的基础上，充分满足玩家的视野范围。

通过正方形结构的占地区域能够使区域划分结果更加合理，而且形成的九宫格结构也使加载范围能够快速确认，便于资源加载管理过程。

图7提供了一种游戏资源的处理装置的结构示意图。该装置可以应用于服务端设备。如图7所示，游戏资源的处理装置700包括：

获取模块701，用于获取游戏资源在游戏场景中的位置；

聚类模块702，用于基于位置对多个游戏资源进行聚类，得到多个资源点集合；

创建模块703，用于根据资源点集合创建资源管理对象，其中，每个资源管理对象对应一个资源点集合，资源管理对象用于管理对应的资源点集合中的游戏资源的资源数据。

在一些实施例中，该装置还包括：

加载模块，用于在根据资源点集合创建资源管理对象之后，基于客户端控制的虚拟对象在游戏场景中所处的当前位置，对当前位置的第一预设范围内的游戏资源对应的目标资源管理对象进行加载，以使客户端获取目标资源管理对象管理的资源数据。

在一些实施例中，游戏场景的整体占地范围按照预设单位面积被均匀划分成多个占地区域；加载模块具体用于：

基于虚拟对象在游戏场景中所处的当前占地区域，从多个占地区域中确定当前占地区域的第一预设范围内的目标占地区域；

对位于目标占地区域中的目标资源点集合对应的目标资源管理对象进行加载，以使客户端获取目标资源管理对象管理的目标资源数据并基于目标资源数据对目标资源点集合中的目标资源进行显示和/或控制。

在一些实施例中，加载模块还用于：

基于客户端控制的虚拟对象在游戏场景中所处的当前占地区域，从多个占地区域中确定当前占地区域相邻的至少一个占地区域；

将当前占地区域和当前占地区域相邻的至少一个占地区域确定为目标占地区域。

在一些实施例中，该装置还包括：

写入模块，用于在根据资源点集合创建资源管理对象之后，基于多个资源管理对象将每个资源管理对象管理的资源数据写入Redis数据库中，其中，Redis数据库用于通过加载资源管理对象查询和/或调取资源管理对象管理的资源数据。

在一些实施例中，该装置还包括：

卸载模块，用于在基于多个资源管理对象将每个资源管理对象管理的资源数据写入Redis数据库中之后，对预设时长内无加载事件发生的资源管理对象从Redis数据库中进行卸载。

在一些实施例中，聚类模块702具体用于：

遍历多个游戏资源，针对每个游戏资源执行以下步骤：

根据当前游戏资源在游戏场景中的目标位置，查询目标位置的第二预设范围内是否存在已生成的资源点集合；

如果第二预设范围内存在已生成的资源点集合，则将当前游戏资源加入至距离当前游戏资源最近的已生成的资源点集合中。

在一些实施例中，聚类模块702还用于：

在将当前游戏资源加入至距离当前游戏资源最近的已生成的资源点集合中之后，基于加入当前游戏资源后的资源点集合进行集合的中心位置更新。

在一些实施例中，聚类模块702还用于：

在根据当前游戏资源在游戏场景中的目标位置，查询目标位置的第二预设范围内是否存在已生成的资源点集合之后，如果第二预设范围内不存在已生成的资源点集合，则新建一个新资源点集合，将当前游戏资源加入至新资源点集合中，并将目标位置作为新资源点集合的中心位置。

在一些实施例中，资源数据包括下述任意一项或多项：

游戏资源的标识、模型路径、游戏资源在游戏场景中的位置坐标以及在游戏场景中的旋转信息。

本申请实施例提供的游戏资源的处理装置，与上述实施例提供的游戏资源的处理方法具有相同的技术特征，所以也能解决相同的技术问题，达到相同的技术效果。

本申请实施例提供的一种服务端设备，如图8所示，服务端设备800包括存储器801、处理器802，所述存储器中存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述实施例提供的方法的步骤。

参见图8，服务端设备还包括：总线803和通信接口804，处理器802、通信接口804和存储器801通过总线803连接；处理器802用于执行存储器801中存储的可执行模块，例如计算机程序。

其中，存储器801可能包含高速随机存取存储器(Random Access Memory，简称RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口804(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。

总线803可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器801用于存储程序，所述处理器802在接收到执行指令后，执行所述程序，前述本申请任一实施例揭示的过程定义的装置所执行的方法可以应用于处理器802中，或者由处理器802实现。

处理器802可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器802中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器802可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processing，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现成可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器801，处理器802读取存储器801中的信息，结合其硬件完成上述方法的步骤。

对应于上述游戏资源的处理方法，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行上述游戏资源的处理方法的步骤。

本申请实施例所提供的游戏资源的处理装置可以为设备上的特定硬件或者安装于设备上的软件或固件等。本申请实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，前述描述的系统、装置和单元的具体工作过程，均可以参考上述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

再例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述游戏资源的处理方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的范围。都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。