具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)网络游戏(Online Game)也称在线游戏，一般指多名玩家通过电脑网络互动娱乐的电子游戏。

2)动作游戏(Action Game)是电子游戏中的一种，它强调玩家的反应能力和手眼的配合。往往存在多个技能连续配合释放，形成连击的形式的玩法。

3)角色扮演游戏(Role-Playing Game，RPG)，是一种游戏类型，在角色扮演游戏中，玩家扮演虚拟世界中的一个或者几个队员角色在特定场景下进行游戏。通常这类游戏都是由玩家扮演冒险者在游戏世界中漫游，而一路上的各种遭遇(如战斗、交谈、会见重要人物等)则是玩家人物成长及游戏进行的重要关键所在。

4)游戏技能(Spell)在角色扮演游戏中的一种玩法，一个技能对应于一系列的规则，使用时可以对自身&目标产生特定的魔法效果。

5)视野，玩家操控的角色在游戏内能够看到的游戏世界范围。

6)群战，MMORPG中大量玩家聚集在一起PK的游戏玩法。

7)网络游戏客户端(Game Client)是指与网络游戏服务器相对应，为客户提供本地服务的程序。一般安装在普通的用户机上，需要与服务端互相配合运行。

8)网络游戏服务器(Game Server)，是指与网络游戏客户端相对应，安装在IDC中，为网络游戏客户端提供数据转发与逻辑处理服务的软件程序。由于安装在玩家机器上的客户端容易被破解而被利用作弊，所以在网络游戏中，复杂与关键的逻辑，都需要在网络游戏服务器上进行计算。

9)视野广播，网络游戏中，玩家操控的角色在游戏内能够看到其他角色的游戏内行为。这就要求每一个角色的游戏内行为需要广播给视野内的其他角色。

10)广播包，在本申请实施例中也可以称为游戏数据包，可以是需要服务器向其他玩家广播的数据，例如玩家在游戏内移动就会产生一次移动广播包。

11)TCP头(TCP header)，传输控制协议(TCP，Transmission Control Protocol)定义的数据头部，一个TCP Header一般有20个字节。

12)IP头(IP header)，网络互连协议(IP，Internet Protocol)定义的数据头部，一个IP Header一般有20个字节。

13)帧头(Frame header)：链路层帧协议数据头部，一般为14个字节。

14)数据缓冲区(buffer)，用于暂时存放数据的空间。

为了更好地理解本申请实施例提供的游戏数据处理方法，对相关技术中的游戏数据方法及存在的缺点进行说明。

MMO的视野管理一般采用常规的九宫格视野管理，如图1A所示，游戏场景地图会划分为54m*54m的小格，每一个格子称为一个区域(Around)，每个Around维护一个角色列表。如图1A所示，玩家角色A可见视野范围为3*3的9个Around(图1A中阴影部分101)。当一个玩家角色A在游戏场景内移动或者释放技能时，会把角色行为实时的广播给视野内9个Around的所有玩家。

图1B为相关技术中服务器针对游戏数据的下行广播机制示意图，如图1B所示，每个区域对应有一个角色列表，区域1对应角色列表1、区域2对应角色列表2、…、区域9对应角色列表9，在广播源111生成了多个数据包，在图1B中示例性示出数据包1、数据包2、数据包3和数据包4，在相关技术中这些数据包会分别通过网关进程发送给区域1至9对应的角色列表1至9的各个角色对应的游戏客户端。

群战期间，玩家的移动/技能操作也是非常频繁的。可以看到视野广播的写扩散效应是很严重的，每个玩家的行为都要广播给视野内其他玩家。整体下行包量和视野内玩家数量的平方成正比。在图1B所示的广播机制下，假设群战玩法的人数上限是500。群战激烈的时候500个玩家都会聚集在一起，假设条件包括：

1、广播范围为500；

2、技能施放的玩家比例a％，请求频率为1次/s，广播包平均大小120Byte；

3、移动的玩家比例b％，请求频率最高3次/s，广播包平均大小60Byte；

4、玩家移动速度5m/s，Around边长54m，移动玩家10s左右会进行视野切换；

5、TCP有效载荷按80％计算。

表1为不同的战斗比例和不同的移动比例下的数据量分析表，通过表1可以看出，当50％的玩家在战斗，50％的玩家在移动。每秒总包量达到了50w个/s，总流量达到600M，单人流量有150KB/s。群战活动有以下两个问题，一个是包量问题，单场包量已经有50w/s，需要为群战活动预置足够多的接入进程，平时空闲率高。一个是流量问题，总流量过高需要足够高的带宽，当带宽不够时，容易造成游戏卡顿或掉线。

表1、不同的战斗比例和不同的移动比例下的数据量分析表

基于此，本申请实施例提供一种游戏数据处理方法、装置、设备和计算机可读存储介质，基于每个Around维护广播缓存来实现广播并包，能够在没有对游戏体验造成影响的情况下，大幅降低数据传输总量，从而群战的下行广播压力。

下面说明本申请实施例提供的游戏数据处理设备的示例性应用，本申请实施例提供的设备可以实施为服务器。下面，将说明设备实施为服务器时示例性应用。

参见图2，图2是本申请实施例提供的游戏系统100的网络架构示意图，如图2所示，该游戏系统包括游戏终端200(示例性示出了游戏终端200-1和游戏终端200-2)、网络300和服务器400，其中游戏终端200-1和游戏终端200-2分别通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。

游戏终端200-1和游戏终端200-2中可以安装有游戏应用程序(也即游戏客户端)，游戏终端200-1或游戏终端200-2还可以是通过网页登录游戏客户端，从而开始游戏对局。

在游戏对局过程中，用户可以通过终端触发游戏中的虚拟对象在游戏虚拟场景中移动，或者释放技能等操作，而移动或者释放技能等操作均会触发数据包的广播。在图2中，假设游戏终端200-1向服务器400发送了游戏数据包pk g1和pkg2，游戏终端200-2向服务器400发送了游戏数据包pkg3，在本申请实施例中，服务器的广播接口在接收到游戏终端发送的游戏数据包时，如果确定该游戏数据包满足数据缓存条件，则将该游戏数据包缓存至数据缓存队列，假设pkg1、pkg2和pkg3均存在至数据缓存队列。服务器在达到数据发送时机时，将数据缓存队列的数据包进行合并处理，增加数据包头，得到合并后的数据包，并将合并后的数据包发送至目标接收对象，该目标接收对象可以是虚拟对象所在虚拟场景区域以及该虚拟场景区域的邻接区域中所有的虚拟对象对应的游戏客户端。在图2中，示例性示出，游戏终端200-1和游戏终端200-2均为目标接收对象。在本申请实施例中，合并后的数据包里可以有多个游戏数据包，但是这多个游戏数据包共用一个数据包头，从而能够提高数据传输的有效载荷，降低服务器的下行数据传输总量，提高游戏的流畅性。

在一些实施例中，服务器400可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不做限制。

参见图3A，图3A是本申请实施例提供的服务器400的结构示意图，图3A所示的服务器400包括：至少一个处理器410、存储器450、至少一个网络接口420和用户接口430。服务器400中的各个组件通过总线系统440耦合在一起。可理解，总线系统440用于实现这些组件之间的连接通信。总线系统440除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3A中将各种总线都标为总线系统440。

处理器410可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口430包括使得能够呈现媒体内容的一个或多个输出装置431，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口430还包括一个或多个输入装置432，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器450可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器450可选地包括在物理位置上远离处理器410的一个或多个存储设备。

存储器450包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Me mory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memor y)。本申请实施例描述的存储器450旨在包括任意适合类型的存储器。

在一些实施例中，存储器450能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统451，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块452，用于经由一个或多个(有线或无线)网络接口420到达其他计算设备，示例性的网络接口420包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

输入处理模块453，用于对一个或多个来自一个或多个输入装置432之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图3A示出了存储在存储器450中的游戏数据处理装置454，其可以是程序和插件等形式的软件，包括以下软件模块：第一获取模块4541、第二获取模块4542、数据缓存模块4543、数据合并模块4544和第一发送模块4545，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的游戏数据处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logi c Device)、复杂可编程逻辑器件(CPLD，ComplexProgrammable Logic Devi ce)、现场可编程门阵列(FPGA，Field-Programmable GateArray)或其他电子元件。

将结合本申请实施例提供的服务器的示例性应用和实施，说明本申请实施例提供的游戏数据处理方法。

参见图4，图4是本申请实施例提供的游戏数据处理方法的一种实现流程示意图，应用于服务器，以下将结合图4示出的步骤对本申请实施例提供的游戏数据处理方法进行说明。

步骤S101，在游戏对局过程中，获取基于游戏客户端的操作触发的游戏数据包。

在游戏对局过程中，游戏客户端可以基于玩家移动虚拟对象的操作，或者基于玩家控制虚拟对象释放技能的操作而触发生成向其他玩家广播的游戏数据包，该游戏数据包会发送至服务器，由服务器向其他玩家进行发送、广播。

步骤S102，获取该游戏客户端所对应的虚拟对象所在的虚拟场景区域。

在本申请实施例中，服务器可以将游戏的虚拟场景进行划分，例如可以按照一定尺寸划分为边长为M米的多个正方形区域，M为正整数，可以为4、10、50等等。并且可以为各个虚拟场景区域进行编号，以作为各个虚拟场景区域的标识，并且记录各个虚拟场景区域的顶点坐标。虚拟场景区域对应其他实施例中的Around。

该步骤在实现时，服务器可以获取游戏客户端所对应的虚拟对象的位置信息，然后基于虚拟对象的位置信息和各个虚拟场景区域的顶点坐标，确定虚拟对象所在的虚拟场景区域。

步骤S103，在确定该游戏数据包满足数据缓存条件时，将该游戏数据包增加至该虚拟场景区域对应的数据缓存队列中。

在一些实施例中，在步骤S103之前需要确定该游戏数据包是否满足数据缓存条件。由于在大型的MMORPG游戏中，有大量的玩家，并且玩家是在地图场景中实时进行移动和战斗，会大量释放技能，玩家视野和属性更新频繁，因此胡产生有大量的数据包需要发给游戏终端。手机玩家对流量比较敏感，而玩家终端也参差不齐，大量的数据包也会给游戏终端端带来性能和电量消耗，影响游戏流畅度，因此需要在某个区域的玩家数量众多的情况下，才需要进行数据包的处理，实现流量优化。所以，该数据缓存条件可以包括该虚拟对象所在的虚拟场景区域中的虚拟对象总数大于总数阈值，另外，对于一些数据包数需要实时发送给游戏终端的，对于这类数据包不能进行缓存，因此数据缓存条件还包括该游戏数据包不为需要实时发送的数据包。

在本申请实施例中，每个虚拟场景区域维护有一个数据缓存区，在该数据缓存区中数据按照队列的形式进行存储，也即每个虚拟场景区域对应有一个数据缓存队列，处于同一个虚拟场景区域中的虚拟对象所触发的数据包缓存在该虚拟场景区域对应的数据缓存队列中。在一些实施例中，服务器在将游戏数据包增加至数据缓存队列中时，还会为每个游戏数据包设置一个序列号，以使得游戏客户端基于该序列号进行数据同步。

在本申请实施例中，是以虚拟场景区域(Around)为粒度，每个虚拟场景区域维护一个数据缓存队列，而处于同一个虚拟场景区域的虚拟对象所生成的游戏数据包的目标接收对象是一致的，因此以虚拟场景区域为粒度维护数据缓存队列，服务器的内存开销会小很多，并且在对游戏数据包进行合并处理时的并包效率更高。

步骤S104，在确定达到数据发送时机时，将该数据缓存队列中的游戏数据包进行合并处理，得到合并后的数据包。

在一些实施例中，在该步骤之前需要判断是否达到数据发送时机，其中该数据发送时机可以是达到预设的数据发送间隔时长，还可以是数据缓存队列的数据包占用的空间大小达到一定的空间阈值，在一些实施例中，还可以是数据包数达到预设的数量阈值。

该步骤在实现时，可以是将数据缓存队列中的各个游戏数据包按照进入队列的顺序进行拼接，然后再为拼接后的数据包依次增加TCP头、IP头及帧头，从而得到合并后的数据包。也就是说，在本申请实施例中，不用为每个游戏数据包分配TCP头、IP头以及帧头，而是多个游戏数据包共用一个TCP头、一个IP头及一个帧头，如此能够在很大程度上降低服务器的下行数据传输总量，提高数据传输的有效载荷。

步骤S105，确定该合并后的数据包的目标接收对象，并将该合并后的数据包发送至该目标接收对象。

该目标接收对象为该虚拟场景区域内的虚拟角色视野范围内的虚拟对象对应的游戏客户端。该步骤在实现时，可以首先获取该虚拟场景区域的邻接区域，其中，虚拟场景区域的邻接区域可以是与该虚拟场景区域相邻的区域，虚拟场景区域和虚拟场景的邻接区域构成了该虚拟场景区域中的虚拟角色在游戏内能够看到的游戏世界范围，也即虚拟场景区域和虚拟场景的邻接区域为处于该虚拟场景区域中的虚拟角色的视野范围，由于在游戏中数据包进行的是视野广播，也即一个虚拟场景区域中的虚拟角色所触发产生的数据包是需要广播给视野内的其他角色，因此，在本申请实施例中，是将并位于该虚拟场景区域以及该虚拟场景区域的多个邻接区域的多个虚拟对象对应的游戏客户端确定为目标接收对象，然后将合并后的数据包发送至各个游戏客户端，从而实现数据包的视野广播。

在本申请实施例提供的游戏数据处理方法中，在游戏对局过程中，服务器在获取基于游戏客户端的操作触发的游戏数据包之后，获取该游戏客户端所对应的虚拟对象所在的虚拟场景区域，并在确定该游戏数据包满足数据缓存条件时，将该游戏数据包增加至该虚拟场景区域对应的数据缓存队列中，而不是实时发送，在确定达到数据发送时机时，将该数据缓存队列中的游戏数据包进行合并处理，得到合并后的数据包，确定该合并后的数据包的目标接收对象，之后将该合并后的数据包发送至该目标接收对象；在本申请实施例中，目标接收对象为该虚拟角色视野范围内的其他虚拟对象对应的游戏客户端，由于处于同一虚拟场景区域中的虚拟角色的视野范围是相同的，因此处于同一虚拟场景区域中虚拟角色所产生的数据包的目标接收对象是相同的，因此在本申请实施例中，是以虚拟场景区域为粒度，将处于同一虚拟场景区域的虚拟角色所产生的数据包进行合并处理，而这多个数据包是共用一个数据包头，在虚拟场景区域玩家角色众多进而产生数量巨大的数据包的情况下，相比与为每个数据包增加一个数据头能够极大的提高数据传输的有效载荷，从而能够降低降低游戏对局中的数据传输量，进而提高游戏的流畅性。

在一些实施例中，在步骤S102之后，如图5所示，还可以执行以下步骤，以确定是否满足数据缓存条件，以及在不满足数据缓存条件的情况下的处理过程，以下结合图5对各个步骤进行说明。

步骤S106，获取该游戏数据包的属性信息，并确定位于该虚拟场景区域中的虚拟对象的对象总数。

在本申请实施例中，游戏数据包的属性信息至少包括表征游戏数据包是否需要实时发送的标志位信息，当该标志位信息为1时，说明该游戏数据包需要实时发送，也即为实时发送数据包；当该标志位信息为0时，说明该游戏数据包不需要实时发送，也即为非实时发送数据包。

在本申请实施例中，每个虚拟场景区域可以对应有一个虚拟对象列表，当有新的虚拟对象进入时，将新进入的虚拟对象增加至该虚拟对象列表中；当有虚拟对象退出时，将退出的虚拟对象从该虚拟对象列表中删除。确定虚拟场景区域中虚拟对象的对象总数也即确定虚拟对象列表中的对象总数。

步骤S107，基于该对象总数和该属性信息确定该游戏数据包是否满足数据缓存条件。

其中，在该对象总数大于预设的总数阈值且该属性信息为非实时发送数据包时，确定该游戏数据包满足数据缓存条件，此时进入步骤S103；在该对象总数小于或者等于该总数阈值，或者该属性信息为实时发送数据包时，确定该游戏数据包不满足数据缓存条件，此时进入步骤S108。

在一些实施例中，游戏数据包的属性信息还可以包括数据包类型，数据包类型可以包括角色死亡数据包、攻击其他角色数据包、位移数据包、释放技能数据包等，对于某一些类型的游戏数据包是需要广播给视野范围内的所有虚拟角色的，而对于其他一些类型的游戏数据包是不需要广播给视野范围内的所有虚拟角色的。例如，对于死亡包，是需要广播是视野范围内的所有虚拟角色的，而攻击其他角色数据包可以只广播给攻击者和被攻击者，为了降低流量可以不广播给视野内的所有虚拟角色。在实现时，可以预先将数据包类型进行归类，哪些数据类型属于需要广播给视野范围内所有虚拟角色的，哪些数据包是不需要广播给视野范围内所有虚拟角色的，这些都是预先设置好的。

因此在基于该对象总数和该属性信息确定游戏数据包是否满足数据缓存条件，在实现时可以该对象总数大于预设的总数阈值且该属性信息为非实时发送数据包且数据包类型为需要广播给视野范围内的虚拟角色时确定该游戏数据包满足数据缓存条件。

步骤S108，在该游戏数据包确定不满足数据缓存条件时，确定该游戏数据包的目标接收对象。

与步骤S105类似，在该步骤中，将位于该虚拟场景区域以及该虚拟场景区域的邻接区域的虚拟对象的游戏客户端确定为目标接收对象。

步骤S109，将该游戏数据包发送至该目标接收对象。

该步骤在实现时，需要为游戏数据包增加TCP头、IP头和帧头，得到增加数据包头的游戏数据包，然后将增加数据包头的游戏数据包发送至目标接收对象。

在本申请实施例提供的游戏数据处理方法中，服务器在接收到需要广播的游戏数据包之后，首先需要通过虚拟场景区域中虚拟对象的对象总数以及游戏数据包的属性信息确定游戏数据包是否满足数据缓存条件时，将游戏数据包缓存至数据缓存列表，并在达到数据发送时机时，将多个游戏数据包进行合并处理，并将合并后的数据包发送至目标接收对象；而基于对象总数及游戏数据包的属性信息确定不满足数据缓存条件时，则将游戏数据包进行实时发送，从而保证数据传输的及时性。

在一些实施例中，判断是否达到数据发送时机，可以通过至少以下两种实现方式实现：

第一，在确定与上一次发送数据的时刻之间的时间间隔达到预设的间隔阈值时，确定达到数据发送时机。

在实现时，可以是在服务器每发送一次数据之后，启动计时器进行计时，在确定计时器的计时时长达到间隔阈值时，确定达到数据发送时机。在一些实施例中，在服务器完成该次数据发送之后，则将计时器清零。

第二，获取该数据缓存队列中的游戏数据包所占用的空间大小，在确定该空间大小达到预设的空间阈值时，确定达到数据发送时机。

在实现时，可以是每将数据缓存队列中增加一个游戏数据包后，统计当前数据缓存队列中游戏数据包所占用的总空间大小，并确定该空间大小是否大于或者等于预设的空间阈值，该空间阈值可以是该虚拟场景区域对应的缓存空间大小，还可以小于该缓存空间大小，例如可以是该缓存空间大小乘以0.8得到的数值。在确定该空间大小大于或者等于该空间阈值时，确定达到数据发送时机。

在一些实施例中，还可以确定数据缓存队列中游戏数据包的包个数，在确定包个数达到个数阈值时，确定达到数据发送时机。

在一些实施例中，在游戏对局过程中，由于虚拟对象的移动比较频繁，可能会移出当前所在的虚拟场景区域，从而进入另一个虚拟场景区域，在该虚拟对象移出当前所在的虚拟场景区域之后，该虚拟场景区域对应的数据缓存队列的数据包有可能不会发送至该虚拟对象对应的游戏客户端，因此，在本申请实施例中，在监测到存在移动出该虚拟场景区域的目标虚拟对象时，确定达到数据发送时机。

对应地，确定该合并后的数据包的目标接收对象，在实现时，是将目标虚拟对象对应的游戏客户端确定为该合并后的数据包的目标接收对象，也就说，当有目标虚拟对象移动出虚拟场景区域时，为了避免该目标虚拟对象对应的游戏客户端遗漏掉该目标虚拟对象在虚拟场景区域时的游戏数据包，会在监测到目标虚拟对象移动到新的虚拟场景区域时，将该目标虚拟对象的原虚拟场景区域对应的数据缓存队列中的游戏数据包进行合并，并且单发送至该目标虚拟对象对应的游戏客户端。

在一些实施例中，上述步骤S105中的“确定该合并后的数据包的目标接收对象”，可以通过下述的步骤S1051和步骤S1052实现，以下对各步骤进行说明。

步骤S1051，确定该虚拟场景区域的邻接区域。

在本申请实施例中，虚拟场景区域的邻接区域可以是虚拟场景区域的上、下、左、右、右上、右下、左上、左下这八个邻接区域，当然，当虚拟场景区域位于游戏虚拟场景地图的边缘或顶角时，邻接区域会少于八个，例如左上顶点的虚拟场景区域的邻接区域仅包括下、右及右下这三个邻接区域。

步骤S1052，将位于该虚拟场景区域和该虚拟场景区域的邻接区域中的虚拟对象对应的游戏客户端确定为该合并后的数据包的目标接收对象。

在一些实施例中，某一虚拟场景区域和该虚拟场景区域的邻接区域又可以称为该虚拟场景区域的视野范围，因此在实现时，是将该虚拟场景区域的视野范围中的多个虚拟场景区域中所包括虚拟对象对应的游戏客户端确定为合并后的数据包的目标接收对象。

基于前述的实施例，本申请实施例再提供一种游戏数据处理方法，应用于图2所示的网络架构，图6为本申请实施例提供的游戏数据处理方法的再一种实现流程示意图，以下结合图6对各步骤进行说明。

步骤S201，游戏终端响应于接收到的游戏对局启动指令，启动游戏对局。

在启动游戏对局之前，可以首先启动游戏客户端，启动游戏客户端可以是可以是通过点击或者触控游戏终端中游戏应用图标，或者是登录游戏客户端的网址触发的。在启动游戏客户端之后，玩家可以选择要加入的游戏对局以及要使用的虚拟对象、虚拟对象皮肤、技能等，在此之后，玩家可以通过游戏终端触发游戏对局启动指令，并启动游戏对局。

步骤S202，在游戏对局过程中，游戏终端响应于接收到的游戏操作指令，向服务器发送游戏数据包。

在游戏对局过程中，玩家通过游戏终端可以触发虚拟对象移动，或者击杀敌方虚拟对象、拾取游戏道具等操作，而这些操作均会生成游戏数据包，并将这些游戏数据包发送至服务器，以使得服务器将这些游戏数据包进行广播。

步骤S203，服务器获取游戏终端所对应的虚拟对象所在的虚拟场景区域。

服务器在获取到游戏数据包后，为了确定游戏数据包是否符合数据缓存条件或者确定游戏数据包的目标接收对象都需要先确定虚拟对象所在的虚拟场景区域。在实现时，可以基于虚拟对象所在的位置信息，确定该虚拟对象所在的虚拟场景区域。

步骤S204，服务器判断该游戏数据包是否满足数据缓存条件。

在实现时，可以首先确定该游戏数据包是否为需要实时发送的数据包，如果该游戏数据包不是需要实时发送的数据包，则进一步确定虚拟场景区域中虚拟对象的对象总数是否大于总数阈值，当对象总数大于总数阈值时，确定该游戏数据包满足数据缓存条件；而在第一步确定游戏数据包为需要实时发送的数据包时，则确定该游戏数据包不满足数据缓存条件，或者在第一步确定该游戏数据包不是需要实时发送的数据包，在第二步确定虚拟对象总数小于或者等于总数阈值时，说明虚拟场景区域内虚拟对象较少，数据包的发送量也就相对较少，那么就暂时不对数据进行缓存，同样确定该游戏数据包不满足数据缓存条件。

在本申请实施例中，确定该游戏数据包不满足数据缓存条件时，进入步骤S205；确定该游戏数据包满足数据缓存条件时，进入步骤S207。

步骤S205，服务器基于虚拟场景区域确定该游戏数据包的目标接收对象。

该目标接收对象至少包括该游戏终端，还可以包括虚拟场景区域和虚拟场景区域的邻接区域中虚拟对象对应的游戏终端。

步骤S206，服务器将游戏数据包发送至目标接收对象。

在一些实施例中，目标接收对象接收到游戏数据包后，基于该游戏数据包进行渲染显示。

步骤S207，服务器获取该虚拟场景区域对应的数据缓存队列的当前数据包序列号。

在本申请实施例中，为了保证数据包发送的同步性，可以为每个数据缓存队列分配数据包序列号，服务器每接收到一个要存储到某一数据缓存队列的游戏数据包时，首先获取数据缓存队列的当前数据包序列号，该当前数据包序列号也即该数据缓存队列中队尾数据包的序列号。

步骤S208，服务器基于该当前数据包序列号确定该游戏数据包的序列号。

在实现时，将当前数据包序列号加1，也即得到了该游戏数据包的序列号。例如，数据缓存队列的当前数据包序列号为35，在接收到一个要存入该数据缓存队列的游戏数据包的序列号为36。

步骤S209，服务器将该游戏数据包的序列号更新为该数据缓存队列的当前数据包序列号。

在将游戏数据包缓存至数据缓存队列中之后，等于数据缓存队列中的数据包多了一个，并且刚刚缓存的游戏数据包为位于队尾的数据包，因此可以将该游戏数据包的序列号更新为数据缓存队列的当前数据包序列号。承接上述举例，新加入数据缓存队列的游戏数据包的序列号为36，那么数据缓存队列的当前数据包序列号也更新为36。

步骤S210，服务器将该游戏数据包和该游戏数据包的序列号增加至该数据缓存队列中。

在实现时，可以将游戏数据包的序列号作为游戏数据包的其中一个新增的属性信息，和游戏数据包一并增加至数据缓存队列中。

步骤S211，服务器在确定达到数据发送时机时，将该数据缓存队列中的游戏数据包进行合并处理，得到合并后的数据包。

在一些实施例中，在达到预设的时间间隔时长或者在确定数据缓存队列中的数据包的占用空间大小达到一定阈值时，确定达到数据发送时机。另外，对于虚拟对象移出该虚拟场景区域时，也作为一种达到数据发送时机的情况。

将游戏数据包进行合并处理是指将当前数据缓存队列中的所有数据包按照加入队列的顺序进行拼接，并依次增加TCP头、IP头和帧头，从而得到合并后的数据包。

步骤S212，服务器确定该合并后的数据包的目标接收对象，并将该合并后的数据包发送至该目标接收对象。

对于由于虚拟对象移出该虚拟场景区域而确定达到数据发送时机的这一情况，是将移出该虚拟场景区域的目标虚拟对象对应的游戏终端(游戏客户端)确定为目标接收对象。对于达到预设的时间间隔时长或者确定数据缓存队列中数据包的占用空间大小达到一定阈值时，而确定达到数据发送时机的情况，是将处于该虚拟场景区域和该虚拟场景区域的邻接区域的虚拟对象对应的游戏终端确定为目标接收对象。在确定出目标接收对象之后，服务器将合并后的数据包通过网络发送至目标接收对象。

步骤S213，游戏终端接收服务器发送的合并后的数据包，解析该合并后的数据包，得到多个游戏数据包。

该步骤在实现时，游戏终端在接收到合并后的数据包之后，解析合并后的数据包，依次去除帧头、IP头和TCP头，从而得到多个游戏数据包。

步骤S214，游戏终端从该多个游戏数据包中确定目标数据包，并基于该目标数据包进行渲染显示。

该步骤在实现，游戏终端首先获取游戏客户端对应的虚拟对象当前所处的虚拟场景区域的当前数据包序列号，之后再获取解析出的各个游戏数据包对应的序列号，并将序列号大于或者等于该当前数据包序列号的游戏数据包确定为目标数据包。

其中，游戏终端获取游戏客户端对应的虚拟对象当前所处的虚拟场景区域的当前数据包序列号，在实现时，可以是接收服务器发送的当前数据包序列号，还可以是基于之前接收到的游戏数据包的序列号而更新得到的。当游戏终端对应的虚拟对象是从其他的虚拟场景区域(称为第一虚拟场景区域)新加入到另一个虚拟场景区域(称为第二虚拟场景区域)，那么服务器在监测到该虚拟对象所处的虚拟场景区域发生变化时，会向游戏终端发送第二虚拟场景区域的当前数据包序列号。如果该虚拟对象所处的虚拟场景区域没有发生变化，那么游戏终端每接收一次游戏数据包，则会将接收到的多个游戏数据包中的最大序列号更新为当前数据包序列号。当游戏终端再次接收到游戏数据包之后会将序列号大于或者等于当前数据包序列好的游戏数据包确定为目标数据包。

需要说明的是，下述的步骤S215至步骤S227未在图6中示出。

步骤S215，当服务器检测到该虚拟对象所处的虚拟场景区域发生变化时，确定该虚拟对象更新前的虚拟场景区域和更新后的虚拟场景区域。

在本申请实施例中，可以将更新前的虚拟场景区域称为第一虚拟场景区域，将更新后的虚拟场景区域称为第二虚拟场景区域。在一些实施例中，当虚拟对象所处的虚拟场景区域发生变化时，会对应将虚拟对象的标识从第一虚拟场景区域的对象列表中删除，并增加至第二虚拟场景区域的对象列表中。

步骤S216，服务器将该更新前的虚拟场景区域对应的数据缓存队列中的多个游戏数据包进行合并处理，得到合并后的数据包。

在本申请实施例中，在监测到虚拟对象所处的虚拟场景区域发生变化时，确定达到数据发送时机，此时对更新前虚拟场景区域对应的数据缓存队列中的多个游戏数据包进行合并处理，从而得到合并后的数据包。

步骤S217，服务器将该合并后的数据包发送至该游戏终端。

也就是说，此时仅仅将合并后的数据包发送至发生虚拟场景区域变换的虚拟对象对应的游戏终端。

步骤S218，服务器获取该更新后的虚拟场景区域对应的当前数据包序列号。

当虚拟对象移动至更新后的虚拟场景区域之后，该更新后的虚拟场景区域内各个虚拟对象触发生成的游戏数据包都应发送至该虚拟对象，而在虚拟对象移动至更新后的虚拟场景区域之前产生的游戏数据包对该虚拟对象来说是无效且没有意义的，因此为了让游戏终端能够区分哪些是需要的游戏数据包，哪些是不需要的游戏数据包，在该步骤中，服务器会获取更新后的虚拟场景区域对应的当前数据包序列号，以使得游戏终端基于该当前数据包序列号确定为判断标准。

步骤S219，服务器将该更新后的虚拟场景区域对应的当前数据包序列号发送至该虚拟对象对应的游戏终端。

步骤S220，游戏终端接收服务器发送的虚拟场景区域的当前数据包序列号。

在本申请实施例中，游戏终端接收到服务器发送的虚拟场景区域的当前数据包序列号之后，会将自身存储的当前数据包序列号进行更新。

举例来说，虚拟对象从第一虚拟场景区域移动至第二虚拟场景区域，游戏终端自身存储的是第一虚拟场景区域对应的当前数据包序列号，例如为378，当虚拟对象移动至第二虚拟场景区域之后，服务器将第二虚拟场景区域对应的当前数据包序列号发送至游戏终端，例如为543，那么游戏终端会将当前数据包序列号更新为543。

步骤S221，服务器在确定达到数据发送时机时，将更新后的虚拟场景区域对应的数据缓存队列中的数据包进行合并处理，得到合并后的数据包。

步骤S222，服务器将合并后的数据包发送至包括游戏终端在内的目标接收对象。

步骤S223，游戏终端接收服务器发送的合并后的数据包，解析该合并后的数据包，得到多个游戏数据包。

步骤S224，游戏终端获取各个游戏数据包对应的序列号。

步骤S225，游戏终端将序列号大于或者等于该当前数据包序列号的游戏数据包确定为目标数据包，并基于该目标数据包进行渲染显示。

由于游戏终端是新加入更新后的虚拟场景区域的，因此在当前数据包序列号之前的游戏数据包对于游戏终端来说是无用的游戏数据包，因此在本申请实施例中，并不对该部分游戏数据包进行渲染显示，而是仅对虚拟对象进入更新后的虚拟场景区域之后的游戏数据包进行渲染显示，从而能够提高渲染效率，提高游戏的流畅性。

步骤S226，游戏终端获取各个目标数据包对应的序列号中的最大序列号。

步骤S227，游戏终端将该最大序列号更新为该虚拟场景区域的当前数据包序列号。

由于游戏终端对应的虚拟对象已经移动至更新后的虚拟场景区域，那么之后如果在服务器再次发送数据之前，服务器不再会向游戏终端发送最新的当前数据包序列号，因此需要游戏终端自身根据接收到的各个游戏数据包对应的序列号中的最大序列号更新为当前数据包序列号。

在本申请实施例提供的游戏数据处理方法中，在玩家通过终端启动游戏客户端，在游戏对局过程中的玩家移动虚拟对象、击杀敌方对象、释放技能等操作都会触发生成需要广播给其他虚拟对象的游戏数据包，该游戏数据包会由游戏终端发送至服务器，由服务器进行广播。在本申请实施例中，服务器在接收到游戏数据包之后，首先判断游戏数据包是否需要实时发送，如果需要时实时发送，则直接增加数据包头将该游戏数据包进行发送；如果不需要实时发送，则将游戏数据包缓存至该虚拟对象所在虚拟场景区域对应的数据缓存队列中，在达到数据发送时机时，将数据缓存队列中的多个游戏数据包进行并包，然后将并包后的数据包一次性进行发送，如此能有效提高数据传输的有效载荷；另外，在服务器将游戏数据包增加至数据缓存队列时，会为每个游戏数据包分配序列号，并且每个数据缓存队列对应有一个当前数据包序列号，当确定虚拟对象所处的虚拟场景区域发生变更时，服务器会将更新前的虚拟场景区域的数据缓存队列的数据包进行合并，并且仅发送给该虚拟对象对应的游戏客户端；服务器还会将更新后的虚拟场景区域对应的数据缓存队列的当前数据包序列号发送至游戏终端，以使得游戏终端在接收到更新后的虚拟场景区域对应的游戏数据包时，能够基于当前数据包序列号确定出哪些是需要渲染显示，哪些是需要丢弃的游戏数据包，能够提高游戏渲染效率，提高游戏流畅性。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

本申请实施例提供的游戏数据处理方法适用但不限于图7所示的MMORP G群战场景，通过图7可以看出，在群战场景中游戏的虚拟角色数量巨大，因此虚拟角色的移动以及技能释放能过程会产生数量更加巨大的数据包，通过本申请实施例提供的游戏数据处理方法，能够进行同Around(对应其他实施例中的虚拟场景区域)内数据包的并包，实现广播优化，对于玩家来说，可以以较低的带宽，更好的体验实时交互性以及千人同屏等更高级的游戏体验。

考虑到同一个Around中的玩家收到的广播包(对应其他实施例中的游戏数据包)是相同的，因此就可以基于每个Around维护一个广播缓存队列。服务器的广播接口首先将广播包放入Around缓存队列中，等到一定的时机再把广播缓存对了中的广播包针对Around内玩家一并发送。广播缓存队列是暂存广播包的空间，一个Around内虚拟角色触发的广播包会按时间顺序放入到该Around对应的广播缓存队列中。

例如玩家A处于Around1中，那么玩家A对应的虚拟角色在游戏的虚拟场景地图中移动产生移动广播包pkg1，此时会将pkg1存放在Around1广播缓存中，然后玩家释放技能产生广播包pkg2和广播包pkg3，也放入到广播缓存中。这时如图8所示，广播缓存801中就存在pkg1，pkg2，pkg3这三个广播包。

如果不用包合并的做法是，Around内产生的广播包会直接广播给Around内玩家列表actor_list。并包的做法是，Around内的广播包会按顺序放入到广播缓存中，等待一定的时机再将广播缓存中的包一起发送。广播时机有两种：一是当广播缓存用满时，一是定时发送。例如玩家在游戏内先后产生pkg1，pkg2，pkg3这三个广播包，都放入广播缓存(pkg_buffer)中。等待并包发送间隔时间后，如图8所示，将广播缓存pkg_buffer中的三个广播包一并广播给Around玩家列表actor_list，actor_list至少包括图8所示的玩家A和玩家B。

图9为本申请实时汇率提供的基于Around并包的下行广播发送数据包示意图，如图9所示，玩家通过在游戏对局中的操作触发广播包1、广播2和广播3，这些广播包由服务器的广播接口接收，并存储到Around的广播缓存901中，每个Around还维护有一个玩家列表902，在达到数据发送时机时，将广播缓存中的广播包进行并包，并通过网关903发送至其他玩家。

这种方式可以有效利广播包量大而每个包长度较小的特点，把大量广播包合并在一起发送，大幅减少包量，提升下行包的有效载荷。基于Around广播缓存机制增加了一定的内存开销。针对这个问题，其实大部分玩法下玩家聚集程度不高，其实不需要并包。只有在广播目标Around的人数超过一定阀值时才开启，可以避免过高的内存开销。

基于Around并包的方式在通过包合并减少了广播包量的同时，也通过提升有效载荷率来减少了下行广播流量。举例来说，假设广播包数据长度为75Byte，下行发送给给客户端时，如图10所示，网络协议栈会加上TCP header 1001、IP header 1002和Frame header1003，其中TCP header 1001为20Byte、IP header 1002为20Byte和Frame header 1003为14Byte，那么客户端网卡收到的数据大小为75+20+20+14＝129Byte。有效载荷率是75/129＝58％。并包可以把多个小的广播包合并在一起，如果20个广播包合并在一起，那么广播数据长度为20*75＝1500Byte，有效载荷率为1500/1554＝96.5％，有效载荷率提升很明显。

在实际的游戏对局中，玩家的虚拟对象会不断在不同的Around之间移动，也就是说虚拟对象会不断在不同的buffer间切换，图11是本申请实施例提供的Around切换示意图，如图11所示，当该虚拟对象从Around a移动到Around b之后，该虚拟对象对应的包缓存队列也相应地由pkg_bufer_a切换为pkg_buff er_b。而Around_a缓存在pkg_buffer_a里的广播包由于要等待超时才能发送。此时会带来两个问题：第一、Around_a缓存在pkg_buffer_a里的广播包应该发送给玩家但是没有发送；第二、Around_b缓存在pkg_buffer_b中的包是在玩家进入之前发送到Around_b的，不应该发送给玩家，但是却在等待发送。

对于第一个问题，只需要在玩家移动到Around b时将pkg_buffer_a当前缓存内容单独发送给客户端即可。

对于第二个问题，在本申请实施例中可以通过以下步骤解决包同步的问题：

第一步、对于每一个Around引入一个广播包序列号seq。

第二步、当每有一个广播包对该Around进行广播，则序列号加1。

第三步、玩家进入新的Around的时候，客户端对序列号进行同步(因为每个Around的当前序列号都不一样)。

第四步、客户端如果收到了序列号小于当前序列号的广播包则可以直接丢弃。

图12是本申请实施例提供的通过序列号避免串包问题的实现过程示意图，如图12所示，在玩家加入一个新的Around时，此时该Around的数据包缓存队列中缓存有pkg_i-n至pkg_i，序列号为i，那么服务器会将该序列号i同步给客户端，客户端存储该序列号，服务器会继续缓存数据，如图12所示，在数据包缓存队列中又新增到pkg_i+m，在达到数据发送时机时，服务器将数据缓存队列中的pkg_i-n至pkg_i+m发送给玩家客户端，玩家在接收到pkg_i-n至pkg_i+m后，根据序列号，丢弃掉pkg_i-n至pkg_i-1，仅保存pkg_i至pkg_i+m。

通过本申请实施例提供的游戏数据处理方法，能够降低群战期间广播包量，减轻网关层压力，减少所需要的服务器资源，并且能够减少服务器和玩家带宽消耗，避免出现玩家掉线等问题，同时也降低游戏运营成本。

下面继续说明本申请实施例提供的游戏数据处理装置454的实施为软件模块的示例性结构，在一些实施例中，如图3A所示，存储在存储器440的游戏数据处理装置454中的软件模块可以包括：

第一获取模块4541，用于在游戏对局过程中，获取基于游戏客户端的操作触发的游戏数据包；

第二获取模块4542，用于获取该游戏客户端所对应的虚拟对象所在的虚拟场景区域；

数据缓存模块4543，用于在确定该游戏数据包满足数据缓存条件时，将该游戏数据包增加至该虚拟场景区域对应的数据缓存队列中；

数据合并模块4544，用于在确定达到数据发送时机时，将该数据缓存队列中的游戏数据包进行合并处理，得到合并后的数据包；

第一发送模块4545，用于确定该合并后的数据包的目标接收对象，并将该合并后的数据包发送至该目标接收对象。

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

第三获取模块，用于获取该游戏数据包的属性信息，并确定位于该虚拟场景区域中的虚拟对象的对象总数；

第二确定模块，用于基于该对象总数和该属性信息确定该游戏数据包是否满足数据缓存条件；

其中，在该对象总数大于预设的总数阈值且该属性信息为非实时发送数据包时，确定该游戏数据包满足数据缓存条件，在该对象总数小于或者等于该总数阈值，或者该属性信息为实时发送数据包时，确定该游戏数据包不满足数据缓存条件。

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

第三确定模块，用于在该游戏数据包确定不满足数据缓存条件时，确定该游戏数据包的目标接收对象；

第三发送模块，用于将该游戏数据包发送至该目标接收对象。

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

第四确定模块，用于在确定与上一次发送数据的时刻之间的时间间隔达到预设的间隔阈值时，确定达到数据发送时机；或者；

第五确定模块，用于获取该数据缓存队列中的游戏数据包所占用的空间大小，在确定该空间大小达到预设的空间阈值时，确定达到数据发送时机。

在一些实施例中，该第一发送模块，还用于：

确定该虚拟场景区域的邻接区域；

将位于该虚拟场景区域和该虚拟场景区域的邻接区域中的虚拟对象对应的游戏客户端确定为该合并后的数据包的目标接收对象。

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

第六确定模块，用于在监测到存在移动出该虚拟场景区域的目标虚拟对象时，确定达到数据发送时机；

对应地，该第一发送模块，还用于：

将该目标虚拟对象对应的游戏客户端确定为该合并后的数据包的目标接收对象。

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

第四获取模块，用于获取该虚拟场景区域对应的数据缓存队列的当前数据包序列号；

第七确定模块，用于基于该当前数据包序列号确定该游戏数据包的序列号；

第一更新模块，用于将该游戏数据包的序列号更新为该数据缓存队列的当前数据包序列号；

对应地，该数据缓存模块，还用于：

将该游戏数据包和该游戏数据包的序列号增加至该数据缓存队列中。

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

第八确定模块，用于当检测到该虚拟对象所处的虚拟场景区域发生变化时，确定该虚拟对象更新后的虚拟场景区域；

第五获取模块，用于获取该更新后的虚拟场景区域对应的当前数据包序列号；

第四发送模块，用于将该更新后的虚拟场景区域对应的当前数据包序列号发送至该虚拟对象对应的游戏客户端。

需要说明的是，本申请实施例针对游戏数据处理装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

参见图3B，图3B是本申请实施例提供的游戏终端200的结构示意图，图3B所示的游戏终端200包括：至少一个处理器210、至少一个网络接口220、用户接口230、总线系统240和存储器250。其中，用户接口230包括输出装置231和输入装置232，存储器250包括操作系统251、网络通信模块252、呈现模块253、输入处理模块254和游戏处理装置255，该游戏处理装置可以采用软件方式实现，图3B示出了存储在存储器250中的游戏数据处理装置255，如图3B所示，该装置包括：

游戏启动模块2551，用于响应于接收到的游戏对局启动指令，启动游戏对局；

第二发送模块2552，用于在游戏对局过程中，响应于接收到的游戏操作指令，向服务器发送游戏数据包；

第一接收模块2553，用于接收服务器发送的合并后的数据包，解析该合并后的数据包，得到多个游戏数据包；

第一确定模块2554，用于从该多个游戏数据包中确定目标数据包，并基于该目标数据包进行渲染显示。

在一些实施例中，该第一确定模块，还用于：

获取游戏客户端对应的虚拟对象当前所处的虚拟场景区域的当前数据包序列号；

获取各个游戏数据包对应的序列号；

将序列号大于或者等于该当前数据包序列号的游戏数据包确定为目标数据包。

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

第六获取模块，用于获取各个目标数据包对应的序列号中的最大序列号；

第二更新模块，用于将该最大序列号更新为该虚拟场景区域的当前数据包序列号。

需要说明的是，本申请实施例针对游戏数据处理装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的游戏数据处理方法。

本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的游戏数据处理方法，例如，如图4、图5和图6示出的游戏数据处理方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EP ROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。