一种游戏同步方法、游戏客户端及游戏服务器

摘要

本发明实施例提供一种游戏同步方法、游戏客户端及游戏服务器，该方法包括：游戏客户端每获取一个游戏操作指令，将所述游戏操作指令加入上传队列中；每隔第一预定时间将所述上传队列中的游戏操作指令加入上传数据包中，并向游戏服务器发送所述上传数据包；及，接收所述游戏服务器每隔第二预定时间发送的下发数据包；根据所述下发数据包，从所述上传队列中删除所述游戏服务器已接收的游戏操作指令；并根据所述下发数据包，控制游戏表现。本发明实施例可使得游戏服务器与游戏客户端在进行游戏同步时，具有较高的通讯可靠性。

权利要求

1.一种游戏同步方法，其特征在于，应用于游戏客户端，所述方法包括：

每获取一个游戏操作指令，将所述游戏操作指令加入上传队列中；

每隔第一预定时间将所述上传队列中的游戏操作指令加入上传数据包中，并向游戏服务器发送所述上传数据包；所述上传数据包还包括：当前的上传编号，游戏客户端最近一次接收的下发数据包的接收确认信息；其中，所述最近一次接收的下发数据包的接收确认信息，携带有最近一次接收的下发数据包所对应的下发编号；

及，接收所述游戏服务器每隔第二预定时间发送的下发数据包；所述下发数据包包括：当前的第二预定时间所述游戏服务器的下发队列中存在的帧数据块，当前的下发编号，游戏服务器最近一次接收的上传数据包的接收确认信息；其中，所述最近一次接收的上传数据包的接收确认信息，携带有所述游戏服务器最近一次接收的上传数据包所对应的上传编号；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令；

根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从所述上传队列中删除对应上传编号的游戏操作指令；并根据所述下发数据包，控制游戏表现。

2.根据权利要求1所述的游戏同步方法，其特征在于，所述根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从所述上传队列中删除对应上传编号的游戏操作指令包括：判断所述下发数据包中的接收确认信息对应的上传编号，是否大于上一次接收的下发数据包中的接收确认信息对应的上传编号；

在所述下发数据包中的接收确认信息对应的上传编号，大于上一次接收的下发数据包中的接收确认信息对应的上传编号时，从所述上传队列中删除与所述下发数据包中的接收确认信息对应的上传编号，所相应的游戏操作指令。

3.根据权利要求2所述的游戏同步方法，其特征在于，所述上传编号，与对应的上传数据包发送时，最新加入上传队列中的游戏操作指令的获取序数对应；其中，每获取一个游戏操作指令，游戏操作指令的获取序数加1；

所述从所述上传队列中删除与所述下发数据包中的接收确认信息对应的上传编号，所相应的游戏操作指令包括：确定所述下发数据包中的接收确认信息对应的上传编号，与上一次接收的下发数据包中的接收确认信息对应的上传编号的差值；

从上传队列中删除个数与所述差值相应，且在上传队列中保留最久的游戏操作指令。

4.根据权利要求1所述的游戏同步方法，其特征在于，所述下发数据包还包括：用于校验下发数据包是否被篡改的校验和；

所述根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从所述上传队列中删除对应上传编号的游戏操作指令之前，所述方法还包括：判断所述下发数据包中的校验和是否为预定值；

在所述下发数据包中的校验和为预定值时，执行根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从所述上传队列中删除对应上传编号的游戏操作指令的步骤。

5.根据权利要求1所述的游戏同步方法，其特征在于，所述上传数据包还包括：用于校验上传数据包是否被篡改的校验和，所述游戏客户端的标识，所述上传数据包中的游戏操作指令的个数；

所述游戏操作指令包括：对玩家操作的定义，该定义对应的参数，及玩家操作所在的帧号。

6.根据权利要求1所述的游戏同步方法，其特征在于，所述下发数据包中的帧数据块以帧数据块列表形式存在，所述帧数据块列表中记录有至少一个帧数据块；

所述根据所述下发数据包，控制游戏表现包括：

遍历所述下发数据包中的帧数据块列表，根据帧数据块列表中各帧数据块对应的游戏操作指令，控制游戏表现。

7.根据权利要求6所述的游戏同步方法，其特征在于，所述遍历所述下发数据包中的帧数据块列表，根据帧数据块列表中各帧数据块对应的游戏操作指令，控制游戏表现包括：获取帧数据块列表；

遍历帧数据块列表中的各帧数据块，将所遍历的各帧数据块存入帧队列中；

将帧数据块列表中的各帧数据块的帧号进行变换，得到各帧数据块对应的游戏客户端帧号，并在下一个游戏服务器帧到来前，将所得到的游戏客户端帧号锁定在下一个游戏服务器帧的前一帧；及将各帧数据块对应的游戏客户端帧号，和下一个游戏服务器帧的前一帧传入帧缓冲器中；

每隔一帧从帧缓冲器中取出当前跳帧加速的倍数；

根据所述倍数，从帧队列中调取帧数据块；

根据所调取的帧数据块的游戏操作指令控制游戏表现。

8.根据权利要求7所述的游戏同步方法，其特征在于，所述根据所述倍数，从帧队列中调取帧数据块包括：如果所述倍数为零，说明帧缓冲器正在缓冲中，没有需要处理的帧；如果所述倍数为1，则说明帧缓冲器缓冲结束，但不需要加速，从帧队列中调取出最新的帧数据块；如果所述倍数大于1，从帧队列调取出与所述倍数相应个数的帧数据块。

9.根据权利要求6所述的游戏同步方法，其特征在于，所述帧数据块列表还包括：所述帧数据块列表中记录的帧数据块的个数；

所述帧数据块包括：游戏服务器需同步给游戏客户端的游戏操作指令，及需同步的游戏操作指令的个数。

10.根据权利要求1所述的游戏同步方法，其特征在于，在获取游戏操作指令时，如果玩家操作为非交互性操作，所述方法还包括：根据玩家操作进行游戏的预表现。

11.根据权利要求1所述的游戏同步方法，其特征在于，玩家角色具有两种角色模式，包括：预表现角色和逻辑角色；其中，预表现角色为通过直接执行玩家操作而作出表现的角色，逻辑角色为执行游戏服务器同步给游戏客户端的操作而作出表现的角色；

所述方法还包括：

保持预表现角色和逻辑角色的一致性，且随着时间推移，在预表现角色的距离大于一定值时，将预表现角色减速直到零，并在预表现角色的位置超过极限值时，强制拉扯预表现角色的位置到与逻辑角色一致的位置。

12.根据权利要求1所述的游戏同步方法，其特征在于，所述方法还包括：

在一局游戏结束时，将上传队列进行清空，并在新一局游戏开始时，重新在上传队列中写入游戏操作命令；

及在每一局游戏结束时，将上传编号清零，并在新的一局游戏开始时，重新计算上传编号。

13.一种游戏同步方法，其特征在于，应用于游戏服务器，所述方法包括：

接收游戏客户端每隔第一预定时间发送的上传数据包；所述上传数据包包括：当前第一预定时间所述游戏客户端的上传队列中存在的游戏操作指令，当前的上传编号，游戏客户端最近一次接收的下发数据包的接收确认信息；其中，所述最近一次接收的下发数据包的接收确认信息，携带有最近一次接收的下发数据包所对应的下发编号；

根据所述最近一次接收的下发数据包的接收确认信息，从下发队列中删除对应下发编号的帧数据块；

及，每隔第二预定时间，将所述下发队列中的帧数据块加入下发数据包中，将所述下发数据包发送给游戏客户端；所述下发数据包还包括：当前的下发编号，游戏服务器最近一次接收的上传数据包的接收确认信息；其中，所述最近一次接收的上传数据包的接收确认信息，携带有所述游戏服务器最近一次接收的上传数据包所对应的上传编号；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令。

14.根据权利要求13所述的游戏同步方法，其特征在于，所述根据所述最近一次接收的下发数据包的接收确认信息，从下发队列中删除对应下发编号的帧数据块包括：判断所述上传数据包中的接收确认信息对应的下发编号，是否大于上一次接收的上传数据包中的接收确认信息对应的下发编号；

在所述上传数据包中的接收确认信息对应的下发编号，大于上一次接收的上传数据包中的接收确认信息对应的下发编号时，从下发队列中删除与所述上传数据包中的接收确认信息对应的下发编号，所相应的帧数据块。

15.根据权利要求14所述的游戏同步方法，其特征在于，所述方法还包括：记录每次发送的下发数据包的下发编号，在下发队列中所对应的帧数据块；

所述从下发队列中删除与所述上传数据包中的接收确认信息对应的下发编号，所相应的帧数据块包括：根据所记录的下发编号，在下发队列中所对应的帧数据块，从下发队列中删除与所述上传数据包中的接收确认信息对应的下发编号，所相应的帧数据块。

16.根据权利要求13所述的游戏同步方法，其特征在于，所述上传数据包还包括：用于校验上传数据包是否被篡改的校验和；所述根据所述最近一次接收的下发数据包的接收确认信息，从下发队列中删除对应下发编号的帧数据块之前，所述方法还包括：判断所述上传数据包中的校验和是否为预定值；

在所述上传数据包中的校验和为预定值时，执行根据所述最近一次接收的下发数据包的接收确认信息，从下发队列中删除对应下发编号的帧数据块的步骤。

17.根据权利要求13所述的游戏同步方法，其特征在于，所述上传数据包还包括：所述游戏客户端的标识，所述上传数据包中的游戏操作指令的个数；

所述游戏操作指令包括：对玩家操作的定义，该定义对应的参数，及玩家操作所在的帧号。

18.根据权利要求13所述的游戏同步方法，其特征在于，所述下发数据包中的帧数据块以帧数据块列表形式存在，所述帧数据块列表中记录有至少一个帧数据块；

所述帧数据块列表还包括：所述帧数据块列表中记录的帧数据块的个数；

所述帧数据块包括：游戏服务器需同步给游戏客户端的游戏操作指令，及需同步的游戏操作指令的个数。

19.根据权利要求13所述的游戏同步方法，其特征在于，所述方法还包括：所述游戏服务器为一局游戏维持一个对应的下发队列，在一局游戏结束时，将该局游戏的下发队列清空，并在新一局游戏开始时，根据新一局游戏中进行游戏的游戏客户端所发送的操作命令数据，重新在下发队列中写入帧数据块；

所述游戏服务器维持有各局游戏对应的下发编号，在一局游戏结束时，将该局游戏的下发编号清零，并在新一局游戏开始时，重新计算下发编号。

20.一种游戏客户端，其特征在于，包括：

游戏操作指令获取并加入模块，用于每获取一个游戏操作指令，将所述游戏操作指令加入上传队列中；

上传数据包上传模块，用于每隔第一预定时间将所述上传队列中的游戏操作指令加入上传数据包中，并向游戏服务器发送所述上传数据包；所述上传数据包还包括：当前的上传编号，游戏客户端最近一次接收的下发数据包的接收确认信息；其中，所述最近一次接收的下发数据包的接收确认信息，携带有最近一次接收的下发数据包所对应的下发编号；

下发数据包接收模块，用于接收所述游戏服务器每隔第二预定时间发送的下发数据包；所述下发数据包包括：当前的第二预定时间所述游戏服务器的下发队列中存在的帧数据块，当前的下发编号，游戏服务器最近一次接收的上传数据包的接收确认信息；其中，所述最近一次接收的上传数据包的接收确认信息，携带有所述游戏服务器最近一次接收的上传数据包所对应的上传编号；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令；

指令删除模块，用于根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从所述上传队列中删除对应上传编号的游戏操作指令；

游戏表现控制模块，用于根据所述下发数据包，控制游戏表现。

21.一种游戏服务器，其特征在于，包括：

上传数据包接收模块，用于接收游戏客户端每隔第一预定时间发送的上传数据包；所述上传数据包包括：当前第一预定时间所述游戏客户端的上传队列中存在的游戏操作指令，当前的上传编号，游戏客户端最近一次接收的下发数据包的接收确认信息；其中，所述最近一次接收的下发数据包的接收确认信息，携带有最近一次接收的下发数据包所对应的下发编号；

帧数据块删除模块，用于根据所述最近一次接收的下发数据包的接收确认信息，从下发队列中删除对应下发编号的帧数据块；

下发数据包下发模块，用于每隔第二预定时间，将所述下发队列中的帧数据块加入下发数据包中，将所述下发数据包发送给游戏客户端；所述下发数据包还包括：当前的下发编号，游戏服务器最近一次接收的上传数据包的接收确认信息；其中，所述最近一次接收的上传数据包的接收确认信息，携带有所述游戏服务器最近一次接收的上传数据包所对应的上传编号；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令。

说明书

一种游戏同步方法、游戏客户端及游戏服务器

技术领域

[0001] 本发明涉及游戏数据处理技术领域，具体涉及一种游戏同步方法、游戏客户端及游戏服务器。

背景技术

[0002] 动作游戏(如目前风靡的动作类手游)等对游戏数据同步要求较高的网络游戏，需要设置实时性较高的游戏同步机制；游戏同步可以理解为是，一个玩家的操作所触发的游戏操作命令，需要同步到与该玩家处于同一游戏场景的其他玩家的游戏客户端上进行表现。

[0003] 游戏同步主要是通过游戏服务器、游戏客户端间的数据交互实现，即游戏服务器可将一游戏客户端发送的游戏操作命令，反馈给处于同一游戏场景的其他游戏客户端中；在实现游戏同步时，游戏服务器与游戏客户端间的通讯可靠性尤为重要，提供具有较高通讯可靠性的游戏同步方案，一直是本领域技术人员研究的关键点。

发明内容

[0004] 有鉴于此，本发明实施例提供一种游戏同步方法、游戏客户端及游戏服务器，以使得游戏服务器与游戏客户端在进行游戏同步时，具有较高的通讯可靠性，以便进一步提升游戏同步的实时性、准确性。

[0005] 为实现上述目的，本发明实施例提供如下技术方案：

[0006] 一种游戏同步方法，应用于游戏客户端，所述方法包括：

[0007] 每获取一个游戏操作指令，将所述游戏操作指令加入上传队列中；

[0008] 每隔第一预定时间将所述上传队列中的游戏操作指令加入上传数据包中，并向游戏服务器发送所述上传数据包；

[0009] 及，接收所述游戏服务器每隔第二预定时间发送的下发数据包；所述下发数据包包括：当前的第二预定时间所述游戏服务器的下发队列中存在的帧数据块；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令；

[0010] 根据所述下发数据包，从所述上传队列中删除所述游戏服务器已接收的游戏操作指令；并根据所述下发数据包，控制游戏表现。

[0011] 本发明实施例还提供一种游戏同步方法，应用于游戏服务器，所述方法包括：

[0012] 接收游戏客户端每隔第一预定时间发送的上传数据包；所述上传数据包包括：当前第一预定时间所述游戏客户端的上传队列中存在的游戏操作指令；

[0013] 根据所述上传数据包包，从下发队列中删除所述游戏客户端已接收的帧数据块；

[0014] 及，每隔第二预定时间，将所述下发队列中的帧数据块加入下发数据包中，将所述下发数据包发送给游戏客户端；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令。

[0015] 本发明实施例还提供一种游戏客户端，包括：

[0016] 游戏操作指令获取并加入模块，用于每获取一个游戏操作指令，将所述游戏操作指令加入上传队列中；

[0017] 上传数据包上传模块，用于每隔第一预定时间将所述上传队列中的游戏操作指令加入上传数据包中，并向游戏服务器发送所述上传数据包；

[0018] 下发数据包接收模块，用于接收所述游戏服务器每隔第二预定时间发送的下发数据包；所述下发数据包包括：当前的第二预定时间所述游戏服务器的下发队列中存在的帧数据块；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令；

[0019] 指令删除模块，用于根据所述下发数据包，从所述上传队列中删除所述游戏服务器已接收的游戏操作指令；

[0020] 游戏表现控制模块，用于根据所述下发数据包，控制游戏表现。

[0021] 本发明实施例还提供一种游戏服务器，包括：

[0022] 上传数据包接收模块，用于接收游戏客户端每隔第一预定时间发送的上传数据包；所述上传数据包包括：当前第一预定时间所述游戏客户端的上传队列中存在的游戏操作指令；

[0023] 帧数据块删除模块，用于根据所述上传数据包包，从下发队列中删除所述游戏客户端已接收的帧数据块；

[0024] 下发数据包下发模块，用于每隔第二预定时间，将所述下发队列中的帧数据块加入下发数据包中，将所述下发数据包发送给游戏客户端；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令。

[0025] 基于上述技术方案，本发明实施例中，游戏客户端可每隔第一预定时间将上传队列中写入的游戏操作指令加入上传数据包中，并上传给游戏服务器，且可基于所接收的游戏服务器发送的下发数据包，从上传队列中删除已被游戏服务器接收的游戏操作指令；同时，游戏服务器可每隔第二预定时间将下发队列中写入的帧数据块加入下发数据包中，并发送给游戏客户端；且一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令，从而游戏客户端在接收下发数据包后，可基于帧数据块进行游戏表现的控制，实现游戏同步。

[0026] 可见，本发明实施例提供的游戏同步方法，可避免游戏客户端重复发送游戏服务器已接收的游戏操作指令，且可避免游戏服务器未接收的游戏操作指令被遗漏发送，游戏服务器也可避免重复发送游戏客户端已接收的帧数据块，且可避免游戏客户端未接收的帧数据块被遗漏发送，具有较高的通讯可靠性，且通讯流量便于控制，减小了游戏同步带来的通讯流量过大的情况；本发明实施例提供的游戏同步方法，可使得游戏服务器与游戏客户端在进行游戏同步时，具有较高的通讯可靠性，进一步提升了游戏同步的实时性、准确性。

附图说明

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

[0028] 图1为本发明实施例提供的游戏系统的结构示意图；

[0029] 图2为本发明实施例提供的游戏同步方法的信令流程图；

[0030] 图3为游戏客户端和游戏服务器的交互简化示意图；

[0031] 图4为游戏客户端所维持的上传队列的示意图；

[0032] 图5为游戏服务器所维持的下发队列的示意图；

[0033] 图6为上传数据包的内容示意图；

[0034] 图7为OperateCmd的内容示意图；

[0035] 图8为下发数据包的内容示意图；

[0036] 图9为FrameList的内容示意图；

[0037] 图10为Frame数据块的内容示意图；

[0038] 图11为SyncCmd的内容示意图；

[0039] 图12为本发明实施例提供的删除游戏操作指令及控制游戏表现的流程图；

[0040] 图13为游戏客户端向游戏服务器发送上传数据包的流程图；

[0041] 图14为本发明实施例提供的控制游戏表现的方法流程图；

[0042] 图15为非交互性操作的游戏预表现示意图；

[0043] 图16为交互性操作下采用游戏同步进行游戏表现的示意图；

[0044] 图17为本发明实施例提供的从下发队列中删除Frame数据块的方法流程图；

[0045] 图18为PVP游戏类型的游戏系统的示意图；

[0046] 图19为一游戏表现结果的示意图；

[0047] 图20为本发明实施例提供的游戏客户端的结构框图；

[0048] 图21为本发明实施例提供的游戏客户端的另一结构框图；

[0049] 图22为本发明实施例提供的游戏客户端的再一结构框图；

[0050] 图23为本发明实施例提供的游戏服务器的结构框图；

[0051] 图24为本发明实施例提供的游戏服务器的另一结构框图。

具体实施方式

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

[0053] 图1为本发明实施例提供的游戏系统的结构示意图，参照图1，该游戏系统可以包括：游戏服务器10和多个游戏客户端20；该多个游戏客户端20可处于同一游戏场景下进行游戏，如在同一游戏房间，同一游戏竞技场中进行游戏，游戏房间、游戏竞技场可以认为是游戏服务器设置的用于容纳玩家进行游戏的虚拟空间；

[0054] 在本发明实施例中，一个游戏客户端可对应至少一个操作该游戏客户端的玩家；游戏服务器10需要在该多个游戏客户端20之间进行游戏同步，且需保证游戏服务器与各游戏客户端在进行数据交互时，具有较高的通讯可靠性；

[0055] 游戏服务器10可以认为是网络侧设置的为游戏提供网络服务的服务设备，该游戏服务器可以是由单台服务器实现，也可以由多台服务器构成的服务器群组实现；

[0056] 游戏客户端20可以认为是用户侧设置的为游戏提供本地服务的程式；

[0057] 图1所示游戏系统可应用于动作游戏(如动作手游)等对游戏同步的实时性要求较高的网络游戏中，显然，也可以应用于回合制游戏等具有游戏同步需求的网络游戏中。

[0058] 结合图1所示游戏系统，在本发明实施例中，游戏客户端每获取一个游戏操作指令，可将所述游戏操作指令加入上传队列中，且游戏客户端可每隔第一预定时间将所述上传队列中的游戏操作指令加入上传数据包中，并向游戏服务器发送所述上传数据包；

[0059] 同时，游戏客户端可接收所述游戏服务器每隔第二预定时间发送的下发数据包；所述下发数据包包括：当前的第二预定时间所述游戏服务器的下发队列中存在的帧数据块；其中，一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令；

[0060] 游戏客户端在接收到游戏服务器发送的下发数据包后，可分析出游戏服务器已接收的游戏客户端发送的游戏操作指令，从上传队列中删除所述游戏服务器已接收的游戏操作指令，同时，根据所述下发数据包，控制游戏客户端的游戏表现。

[0061] 相应的，游戏服务器可接收游戏客户端每隔第一预定时间发送的上传数据包；所述上传数据包包括：当前第一预定时间所述游戏客户端的上传队列中存在的游戏操作指令；

[0062] 同时，游戏服务器可每隔第二预定时间，将所述下发队列中的帧数据块加入下发数据包中，将所述下发数据包发送给游戏客户端；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令；

[0063] 而在游戏服务器接收客户端发送的上传数据包后，游戏服务器可分析出游戏客户端已接收的游戏服务器发送的帧数据块，从下发队列中删除所述游戏客户端已接收的帧数据块。

[0064] 进一步，游戏客户端每隔第一预定时间发送的上传数据包中还可以包括以下内容：当前的上传编号，游戏客户端最近一次接收的下发数据包的接收确认信息；其中，所述最近一次接收的下发数据包的接收确认信息，携带有最近一次接收的下发数据包所对应的下发编号；

[0065] 游戏服务器每隔第二预定时间发送的下发数据包中还可以包括以下内容：当前的下发编号，游戏服务器最近一次接收的上传数据包的接收确认信息；其中，所述最近一次接收的上传数据包的接收确认信息，携带有所述游戏服务器最近一次接收的上传数据包所对应的上传编号；

[0066] 相应的，游戏客户端在从上传队列中删除所述游戏服务器已接收的游戏操作指令时，可根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从所述上传队列中删除对应上传编号的游戏操作指令；

[0067] 相应的，游戏服务器在从下发队列中删除所述游戏客户端已接收的帧数据块时，可根据所述最近一次接收的下发数据包的接收确认信息，从下发队列中删除对应下发编号的帧数据块。

[0068] 可选的，图2示出了本发明实施例提供的游戏同步方法的信令流程图，参照图2，该流程可以包括：

[0069] 步骤S10、游戏客户端每获取一个游戏操作指令，将所述游戏操作指令加入上传队列中；

[0070] 游戏客户端可基于使用所述游戏客户端的玩家的操作，生成并获取相应的游戏操作指令，如游戏客户端可将玩家的操作封装成OperateCmd(游戏操作指令)；玩家的操作一般是玩家对所控制的游戏角色的操作，也可能是玩家对其他玩家所控制的游戏角色的操作；如在对战类的游戏中，玩家可对处于同一游戏场景的其他玩家进行攻击操作，相应的，玩家对其他玩家的攻击操作将被封装成相应的游戏操作指令；

[0071] 游戏客户端中设置有上传队列，上传队列中写入有游戏客户端需要上传给游戏服务器的游戏操作指令；可选的，上传队列中写入的游戏操作指令，可按游戏操作指令的获取先后顺序写入上传队列中并排序，显然，根据游戏的实际情况，本发明实施例也可以设置游戏操作指令在上传队列中的其他写入排序方式；

[0072] 可选的，游戏客户端可在一局游戏结束时，将上传队列进行清空，并在新一局游戏开始时，重新在上传队列中写入游戏操作命令。

[0073] 步骤S11、如果所述上传队列不为空，所述游戏客户端每隔第一预定时间将所述上传队列中的游戏操作指令，当前的上传编号，及最近一次接收的游戏服务器发送的下发数据包的接收确认信息加入上传数据包中；

[0074] 所述当前的上传编号与所述游戏客户端向所述游戏服务器发送上传数据包的当前次数相应；所述当前的上传编号也可以是与最新加入上传队列中的游戏操作指令的获取序数对应，相应的，每获取一个游戏操作指令，游戏操作指令的获取序数加1，即每获取一个游戏操作指令，当前的上传编号也将加1；

[0075] 所述最近一次接收的游戏服务器发送的下发数据包的接收确认信息，携带有，所述游戏客户端最近一次接收的游戏服务器发送的下发数据包所对应的下发编号。

[0076] 步骤S12、所述游戏客户端每隔第一预定时间向所述游戏服务器发送一次上传数据包；

[0077] 可选的，游戏客户端可定义第一预定时间，并且游戏客户端在所维持的上传队列不为空时，可每隔第一预定时间向游戏服务器上传一次上传数据包；上传数据包包含有所述上传队列中写入的游戏操作指令，当前的上传编号及游戏客户端最近一次接收的下发数据包的接收确认信息；

[0078] 当前的上传编号可以表示游戏客户端当前向游戏服务器第几次发送了上传数据包，即随着游戏客户端向游戏服务器发送上传数据包的次数的增加，上传编号也将随之增加，在当前向游戏服务器发送上传数据包时，当前的上传编号与游戏客户端向游戏服务器发送上传数据包的当前次数相应；或者，当前的上传编号也可以是与最新加入上传队列中的游戏操作指令的获取序数对应；

[0079] 而最近一次接收的下发数据包的接收确认信息可以是，游戏客户端对最近一次接收的游戏服务器发送的下发数据包的接收确认，其中可包含有游戏客户端最近一次接收的下发数据包的下发编号。

[0080] 步骤S13、游戏服务器接收所述游戏客户端发送的上传数据包，根据所述上传数据包中携带的最近一次接收的下发数据包的确认信息，从下发队列中删除对应下发编号对应的帧数据块(Frame数据块)；并每隔第二预定时间，根据游戏客户端发送的上传数据包生成帧数据块，将所述帧数据块写入所述下发队列；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令；

[0081] 如图3所示，游戏服务器每隔第二预定时间生成一个Frame数据块，游戏服务器可根据一个第二预定时间内所接收到的，同一游戏场景的游戏客户端通过上传数据包发送的游戏操作指令，生成一Frame数据块，并发送给游戏客户端；图3中简化了游戏客户端的上传内容和游戏服务器的下发内容，仅为便于理解本方案的Frame数据块生成原理；

[0082] 可选的，游戏服务器可为一局游戏维持一个对应的下发队列，在一局游戏结束时，游戏服务器可将该局游戏的下发队列清空，并在新一局游戏开始时，根据新一局游戏中进行游戏的游戏客户端所发送的操作命令数据，重新在下发队列中写入帧数据块。

[0083] 步骤S14、游戏服务器每隔第二预定时间将所述下发队列中的帧数据块，当前的下发编号，及最近一次接收的上传数据包的接收确认信息加入下发数据包中，将所述下发数据包发送给游戏客户端；

[0084] 所述当前的下发编号与所述游戏服务器向游戏客户端发送下发数据包的当前次数相应；所述最近一次接收的上传数据包的接收确认信息，携带有所述游戏服务器最近一次接收的游戏客户端发送的上传数据包所对应的上传编号；

[0085] 可选的，游戏服务器可定义第二预定时间，并且游戏服务器在所维持的下发队列不为空时，可每隔第二预定时间向游戏客户端发送一次下发数据包；下发数据包携带有所述下发队列中写入的帧数据块，当前的下发编号，及游戏服务器最近一次接收的上传数据包的接收确认信息；

[0086] 同时，在游戏服务器接收到游戏客户端发送的上传数据包后，游戏服务器可基于上传数据包中携带的最近一次接收的下发数据包的接收确认信息，确认游戏客户端已接收到游戏服务器最近一次发送的下发数据包，从而将最新一次发送的下发数据包所携带的帧数据块从下发队列中删除，避免下次重复发送已被游戏客户端接收的帧数据块；具体的，游戏服务器可将游戏客户端发送的最近一次接收的下发数据包的接收确认信息，所对应的下发编号的帧数据块，从下发队列中删除；

[0087] 可选的，游戏服务器可记录每次发送的下发数据包的下发编号，在下发队列中所对应的帧数据块，从而在接收到游戏客户端反馈的接收确认信息时，可基于接收确认信息中表示的下发编号，删除相应的帧数据块；

[0088] 可选的，当前的下发编号可以表示游戏服务器当前向游戏客户端第几次发送了下发数据包，即随着游戏服务器向游戏客户端发送下发数据包的次数的增加，下发编号也将随之增加；在当前向游戏客户端发送下发数据包时，当前的下发编号与游戏服务器向游戏客户端发送下发数据包的当前次数相应。

[0089] 步骤S15、所述游戏客户端接收所述下发数据包，根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从上传队列中删除对应上传编号的游戏操作指令；并根据所述下发数据包中携带的帧数据块对应的游戏操作指令，控制游戏表现。

[0090] 游戏客户端接收游戏服务器发送的下发数据包后，基于下发数据包中携带的游戏服务器最近一次接收的上传数据包的接收确认信息，游戏客户端可确定游戏服务器已接收到游戏客户端最近一次发送的上传数据包，可将该上传数据包中包含的游戏操作指令从上传队列中删除，避免下次重复向游戏服务器发送已发送的游戏操作指令；

[0091] 同时，游戏客户端可基于接收的下发数据包中的帧数据块，控制游戏角色的表现，如控制游戏角色的动作，发动技能等；由于帧数据块包含了处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令，因此游戏客户端可基于帧数据块中携带的游戏操作指令控制当前游戏场景中至少一个游戏角色的表现，实现游戏同步。

[0092] 本发明实施例中，游戏客户端可每隔第一预定时间将上传队列中写入的游戏操作指令，当前的上传编号，及最近一次接收的下发数据包的接收确认信息加入上传数据包中，并上传给游戏服务器，且可基于所接收的游戏服务器发送的下发数据包，从上传队列中删除已被游戏服务器接收的游戏操作指令；同时，游戏服务器可基于所接收的上传数据包，从下发队列中删除已被游戏客户端接收的帧数据块，并每隔第二预定时间将下发队列中写入的帧数据块，当前的下发编号，及最近一次接收的上传数据包的接收确认信息加入下发数据包中，并发送给游戏客户端；且一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令，从而游戏客户端在接收下发数据包后，可基于帧数据块进行游戏表现的控制，实现游戏同步。

[0093] 可见，本发明实施例提供的游戏同步方法，可避免游戏客户端重复发送游戏服务器已接收的游戏操作指令，且可避免游戏服务器未接收的游戏操作指令被遗漏发送，游戏服务器也可避免重复发送游戏客户端已接收的帧数据块，且可避免游戏客户端未接收的帧数据块被遗漏发送，具有较高的通讯可靠性，且通讯流量便于控制，减小了游戏同步带来的通讯流量过大的情况；本发明实施例提供的游戏同步方法，可使得游戏服务器与游戏客户端在进行游戏同步时，具有较高的通讯可靠性，进一步提升了游戏同步的实时性、准确性。

[0094] 为便于理解图2所示流程方案，图4示出了游戏客户端所维持的上传队列的示意图，在本发明实施例中，上传队列中写入的游戏操作指令(OperateCmd)可基于游戏客户端的玩家操作获取，如图4所示的OperateCmd1至OperateCmd10表示了基于玩家的不同操作，所获取的10个OperateCmd；

[0095] 图4中，Seq表示一次游戏客户端向游戏服务器发送上传数据包所对应的上传编号，如Seq1表示第一次发送的上传数据包的上传编号，Seq2表示第二次发送的上传数据包的上传编号，以此类推；

[0096] Ack’表示游戏服务器通过下发数据包所发送的最近一次接收的上传数据包的接收确认信息，如Ack’1表示游戏游戏服务器对Seq1对应的上传数据包的接收确认(即对游戏客户端第一次发送的上传数据包的接收确认)，Ack’2表示游戏服务器对Seq2对应的上传数据包的接收确认，以此类推；

[0097] 游戏客户端可定义第一预定时间，在上传队列不为空时(即上传队列中存在OperateCmd)，可每隔第一预定时间，将上传队列中的OperateCmd加入上传数据包中并发送给游戏服务器；

[0098] 需要说明的是，由于上传队列中的OperateCmd，会基于游戏服务器发送的最近一次接收的上传数据包的接收确认信息进行相应的删除，因此在游戏客户端的玩家未操作的情况下，上传队列中可能没有OperateCmd(即上传队列为空)；

[0099] 回到图4，在第1个第一预定时间到来时，游戏客户端进行第一次的上传数据包的发送，此时，上传队列中存在OperateCmd1，游戏客户端可将OperateCmd1，Seq1加入上传数据包，如果有最近一次接收的下发数据包，则上传数据包中还可以有最近一次接收的下发数据包的接收确认信息；游戏客户端将该上传数据包发送给游戏服务器；

[0100] 如果游戏客户端接收到游戏服务器发送的下发数据包中携带有Ack’1，则表示Seq1的上传数据包被游戏服务器接收，游戏客户端可将OperateCmd1从上传队列中删除；

[0101] 在第4至第7个第一预定时间到来时，由于第4个第一预定时间发送的上传数据包没有收到游戏服务器的接收确认信息，于是上传队列中需保留未确认接收的OperateCmd；即在Seq4的上传数据包上传后，上传队列中需保留OperateCmd4，在Seq5的上传数据包上传后，上传队列中需保留OperateCmd4-OperateCmd5，在Seq6的上传数据包上传后，上传队列中需保留OperateCmd4-OperateCmd6，以此类推；

[0102] 而在第7个第一预定时间对应的Seq7的上传数据包发送后，游戏客户端接收到Seq6的上传数据包的接收确认信息Ack’6，游戏客户端可从上传队列中删除Seq6对应的OperateCmd，即删除OperateCmd4-OperateCmd6；

[0103] 此后，在第8个第一预定时间到来时，上传队列中包含OperateCmd7-OperateCmd8，因此可在Seq8的上传数据包中携带OperateCmd7-OperateCmd8；由于此后接收到Seq8的上传数据包的接收确认信息Ack’8，因此游戏客户端可从上传队列中删除OperateCmd7-OperateCmd8；

[0104] 游戏客户端维持上传队列，及向游戏服务器发送上传数据包的原理如上文描述；值得注意的是，游戏客户端在未接收到游戏服务器的接收确认信息时，并不是一直等待游戏服务器的接收确认信息，而是每隔第一预定时间，将上传队列中的OperateCmd加入上传数据包，继续向游戏服务器发送上传数据包。

[0105] 游戏服务器维持下发队列，及游戏服务器向游戏客户端发送下发数据包的方式，与图4所示部分类似，区别在于，发送端变为游戏服务器，接收端变为游戏客户端；

[0106] 具体的，游戏服务器可每隔第二预定时间，根据一个第二预定时间内收到的同一游戏场景的游戏客户端发送的游戏操作指令，生成Frame数据块(帧数据块)，并加入到下发队列；同时，每隔第二预定时间将下发队列中的Frame数据块加入到下发数据包中发送给游戏客户端；

[0107] 如图5所示，Seq’表示一次游戏服务器向游戏客户端发送下发数据包所对应的下发编号，Ack表示游戏客户端通过上传数据包所发送的最近一次接收的下发数据包的接收确认信息；

[0108] 在第1个第二预定时间到来时，游戏服务器进行第一次的下发数据包的发送，此时，下发队列中存在Frame1，游戏服务器可将Frame1，Seq’1加入下发数据包，如果有最近一次接收的上传数据包，则下发数据包中还可以有最近一次接收的上传数据包的接收确认信息；游戏服务器将该下发数据包发送给游戏客户端；

[0109] 如果游戏服务器接收到游戏客户端发送的上传数据包中携带有Ack1，则表示Seq’1的下发数据包被游戏客户端接收，游戏服务器可将Frame1从下发队列中删除；

[0110] 在第4至第7个第二预定时间到来时，由于第4个第二预定时间发送的下发数据包就没有收到游戏客户端的接收确认信息，于是下发队列中需保留未确认接收的Frame；

[0111] 而在第7个第二预定时间对应的Seq’7的下发数据包发送后，游戏服务器接收到Seq’6的下发数据包的接收确认信息Ack6，游戏服务器可从下发队列中删除Seq’6对应的Frame，即删除Frame4-Frame6；

[0112] 此后，在第8个第二预定时间到来时，下发队列中包含Frame7-Frame8，因此可在Seq’8的下发数据包中携带Frame7-Frame8；由于此后接收到Seq’8的下发数据包的接收确认信息Ack8，因此游戏服务器可从下发队列中删除Frame7-Frame8；

[0113] 可见，游戏客户端和游戏服务器针对各自队列的维持过程，和数据的发送方式是类似的，只是发送端和接收端对调。

[0114] 由上可看出，本发明实施例可以通过帧同步技术实现游戏同步；而在实现游戏同步时，为了提高客户端到游戏服务器的通讯速度，本发明可采用UDP(User Datagram Protocol，用户数据报协议)作为底层通讯协议，UDP相对TCP(Transmission Control Protocol，传输控制协议)能够明显提高弱网络环境下的通讯速度，但是UDP本身并不保证通讯的可靠性，因此本发明实施例采用图4和图5所示的队列维持方式和数据发送方式，实现一个基于UDP的可靠传输协议栈，简称为基于UDP的FSP(Frame Sync Protocl，帧同步协议)协议栈，以此来提升游戏客户端和游戏服务器间的通讯可靠性。

[0115] 下面对游戏客户端发送给游戏服务器的上传数据包的内容，及游戏服务器发送给游戏客户端的下发数据包的内容进行介绍，

[0116] 图6示出了上传数据包的内容示意图，如图6所示，上传数据包可以包括：Seq，Ack，SessionId，CmdCnt，及至少一个OperateCmd，CheckSum；

[0117] 其中，Seq是游戏客户端每次发送的上传数据包的上传编号；Ack是游戏客户端对最近一次接收到的下发数据包的接收确认信息；CheckSum是上传数据包的校验和，用来校验上传数据包是否被篡改；SessionId是游戏客户端的标识；CmdCnt是上传数据包的游戏操作指令(OperateCmd)的个数，表示的是游戏客户端在一个第一预定时间内基于玩家的操作所获取的OperateCmd的个数；

[0118] 一个OperateCmd中封装的数据可以如图7所示，包括Vkey，Arg，clientFrameId；其中，Vkey是对玩家操作的定义，可以根据游戏的具体设计情况来定义玩家当前操作的Vkey；Arg是对应Vkey的参数；clientFrameId是玩家操作所在的帧号；Vkey，Arg，clientFrameId构成了一个游戏操作指令(OperateCmd)。

[0119] 图8示出了下发数据包的内容示意图，如图8所示，下发数据包可以包括：Seq’，Ack’，FrameList，CheckSum’；

[0120] 其中，Seq’是游戏服务器每次发送的下发数据包的下发编号；Ack’是游戏服务器对最近一次接收的上传数据包的接收确认信息；CheckSum’是下发数据包的校验和，用来校验下发数据包是否被篡改；FrameList是游戏服务器下发的Frame数据块列表，FrameList可以记录有游戏服务器在一个第二预定时间内所生成的Frame数据块，FrameList中的Frame数据块的数量可以是至少一个；

[0121] 图9示出了FrameList的内容示意图，参照图9，FrameList可以包括：FrameCnt，SyncFrame；其中，FrameCnt是FrameList中记录的Frame数据块的个数，一个SyncFrame对应一个Frame数据块；

[0122] Frame数据块(图9所示SyncFrame)记录的内容可以如图10所示，包括CmdCnt’，SyncCmd；其中，SyncCmd是Frame数据块中记录的游戏服务器需同步给游戏客户端的游戏操作指令，CmdCnt’表示一个Frame数据块中记录的游戏服务器需同步给游戏客户端的游戏操作指令的个数；

[0123] SyncCmd记录的内容与图7所示的OperateCmd内容类似，具体如图11所示，SyncCmd记录的内容可以包括：Vkey，Arg，PlayerId；其中，Vkey是对玩家操作的定义，Arg是Vkey对应的参数，PlayerId是玩家的Id，PlayerId一般与SessionId相应。

[0124] 可选的，基于上述所示的上传数据包和下发数据包内容，游戏客户端在接收下发数据包，从上传队列中删除游戏操作指令，且根据下发数据包中携带的帧数据块对应的游戏操作指令控制游戏表现的过程可通过图12所示实现；图12为本发明实施例提供的删除游戏操作指令及控制游戏表现的流程图，该方法可以应用于游戏客户端，参照图12，该方法可以包括：

[0125] 步骤S100、接收下发数据包；

[0126] 步骤S110、判断所述下发数据包中的CheckSum’是否为预定值，若否，执行步骤S120，若是，执行步骤S130；

[0127] 可选的，预定值可以为零，也可以是约定的其他值，预定值表示的是约定的CheckSum’的原始值；CheckSum’为预定值说明下发数据包未被篡改，CheckSum’不为预定值，说明下发数据包被篡改，所接收的下发数据包不能被处理。

[0128] 步骤S120、结束流程；

[0129] 步骤S130、判断所述下发数据包中的接收确认信息对应的上传编号，是否大于上一次接收的下发数据包中的接收确认信息对应的上传编号，若是，执行步骤S140，若否，执行步骤S150；

[0130] 可设当前接收的下发数据包中的接收确认信息对应的上传编号为RecvAck’，上一次接收的下发数据包中的接收确认信息对应的上传编号为LastRecvAck’，则RecvAck’＞LastRecvAck’，执行步骤S140，否则，执行步骤S150；

[0131] 步骤S140、从上传队列中删除与所述下发数据包中的接收确认信息对应的上传编号，所相应的游戏操作指令，并执行步骤S150；

[0132] 可选的，玩家的一次操作一般对应一个游戏操作指令，在一般情况下，上传队列中的1个OperateCmd可对应1个Seq值；在从上传队列中删除游戏操作指令时，本发明实施例从上传队列中删除的游戏操作指令的个数，可与RecvAck’减去LastRecvAck’的值相应；

[0133] 可选的，本发明实施例可从上传队列中删除个数与RecvAck’减去LastRecvAck’的值相应，且在上传队列中保留最久的游戏操作指令。

[0134] 步骤S150、判断所述下发数据包中的下发编号，是否大于上一次接收的下发数据包中的下发编号，若是，执行步骤S160，若否，执行步骤S120；

[0135] 可设当前接收的下发数据包的下发编号为RecvSeq’，上一次接收的下发数据包中的下发编号为LastRecvSeq’，则RecvSeq’＞LastRecvSeq’，执行步骤S160，否则，执行步骤S120；

[0136] 当前接收的下发数据包的下发编号，大于上一次接收的下发数据包中的下发编号，说明当前接收的下发数据包中携带有新的Frame数据块，可通过新的Frame数据块中的游戏操作指令实现游戏同步；

[0137] 步骤S160、判断所述下发数据包中的Frame数据块的个数是否大于零，若是，执行步骤S170，若否，执行步骤S120；

[0138] 步骤S170、遍历所述下发数据包中的FrameList，根据FrameList中各Frame数据块对应的游戏操作指令，控制游戏表现。

[0139] 可选的，图13示出了游戏客户端向游戏服务器发送上传数据包的流程图，该方法可应用于游戏客户端，参照图13，该方法可以包括：

[0140] 步骤S200、将基于玩家操作获取的游戏操作指令加入上传队列中，并将上传编号加1；

[0141] 步骤S210，判断是否达到第一预定时间，若是，执行步骤S220，若否，回到步骤S210；

[0142] 步骤S220、将上传队列中记录的游戏操作指令加入上传数据包并发送给游戏服务器。

[0143] 可选的，游戏客户端可维持一个主线程和发送线程，主线程可将基于玩家操作获取的游戏操作指令加入上传队列中，并将上传编号加1，同时每加入一个游戏操作指令至上传队列中，可激活一次发送线程；发送线程可检测距上一次的上传数据包发送时间是否达到第一预定时间，并在达到第一预定时间时，访问上传队列，从上传队列中读取游戏操作指令，并结合Seq，Ack等信息加入上传数据包，向游戏服务器发送上传数据包。

[0144] 可选的，本发明实施例中，游戏客户端还可维持一个FrameQueue(帧队列)，FrameBuffer(帧缓冲器)；在游戏客户端接收到下发数据包，且遍历所述下发数据包中的FrameList，根据FrameList中各Frame数据块对应的游戏操作指令，控制游戏表现时，游戏客户端可通过图14所示方法实现；图14为本发明实施例提供的控制游戏表现的方法流程图，该方法可应用于游戏客户端，参照图14，该方法可以包括：

[0145] 步骤S300、获取FrameList；

[0146] 步骤S310、遍历FrameList中的各Frame数据块，将所遍历的各Frame数据块存入FrameQueue；

[0147] 步骤S320、将FrameList中的各Frame数据块的帧号进行变换，得到各Frame数据块对应的游戏客户端帧号(FrameIndex)，并在下一个游戏服务器帧到来前，将所得到的游戏客户端帧号锁定在下一个游戏服务器帧的前一帧；及将各Frame数据块对应的游戏客户端帧号，和下一个游戏服务器帧的前一帧传入FrameBuffer；

[0148] 由于游戏服务器和游戏客户端形成帧的间隔是不同的，因此本发明实施例可计算游戏服务器和游戏客户端形成帧的时间比例，将FrameList中的各Frame数据块的帧号，分别乘以该时间比例，得到各Frame数据块对应的游戏客户端帧号；

[0149] 同时，在等下一个游戏服务器帧到来之前，需要将游戏客户端的帧锁定在下一个游戏服务器帧的前一帧(LockFrameIndex)；然后将FrameIndex和LockFrameIndex传入FrameBuffer。

[0150] 步骤S330、每隔一帧从FrameBuffer中取出当前跳帧加速的倍数(SpeedUpTimes)；

[0151] 可选的，本发明实施例可根据所述倍数从FrameQueue调取Frame数据块，并基于所调取的Frame数据块的游戏操作指令控制游戏表现；具体可见步骤S340和步骤S350。

[0152] 步骤S340，如果SpeedUpTimes为零，说明FrameBuffer正在缓冲中，没有需要处理的帧；如果SpeedUpTimes为1，则说明FrameBuffer缓冲结束，但不需要加速，从FrameQueue调取出最新的Frame数据块；如果SpeedUpTimes大于1，从FrameQueue调取出与所述SpeedUpTimes相应个数的Frame数据块；

[0153] 步骤S350、根据所调取的Frame数据块的游戏操作指令控制游戏表现。

[0154] 可选的，游戏客户端除了通过游戏服务器发送的下发数据包中的游戏操作指令进行游戏表现，还可以基于玩家操作进行预表现；

[0155] 可以理解的是，由于需要严格在游戏客户端之间实现游戏的同步，如在游戏客户端A和游戏客户端B之间实现游戏同步，如果游戏客户端A进行了操作A1，客户端A并不直接执行A1对应的游戏逻辑，来进行游戏表现，而是将操作A1发送给游戏服务器；由游戏服务器将操作A1同步给客户端A和B后，再在客户端A和B同时执行操作A1，实现游戏表现；

[0156] 而预表现则是为了优化以上流程对客户端A的玩家造成的延时，使得客户端A将操作A1发送给游戏服务器的同时，可一并执行操作A1；基于此，本发明实施例可在网络延时较大，玩家的操控有明显的滞后感(特别是在无线网络下)时，保证同步的准确性和操作的流畅性。

[0157] 本发明实施例可在上文以帧同步实现的游戏同步方案的基础上，结合预表现方式进行游戏表现：

[0158] 在本发明实施例中，玩家等角色的行为可以被分成两大类；一、非交互性操作，即操作对玩家的对手不会产生任何影响，玩家自己的行为也不受对手的影响(如玩家的跑动，站立，跳等)；二、交互性操作，即攻击，受击类的行为等；

[0159] 玩家角色可以有两种角色模式，分为：预表现角色和逻辑角色；在非交互性操作下，游戏客户端的预表现角色可以不等待游戏服务器的回应，而进行提前预表现；配合游戏服务器的间隔控制，如果在网络相对稳定的情况下，最终移动停下的位置，预表现角色和逻辑角色的位置不会有太大的差异(时间点上逻辑角色会稍晚一些)，因此在非交互性操作下，本发明实施例可通过预表现进行游戏的表现，图15示出了非交互性操作的游戏预表现示意图可参照；

[0160] 其中，预表现角色是指，通过直接执行游戏客户端的玩家操作而作出表现的角色；逻辑角色是指通过执行游戏服务器同步给游戏客户端的操作而作出表现的角色；正常情况下，预表现角色和逻辑角色最终的表现不会有差异；但是也不排除一些异常情况，万一造成了差异，则可以通过下述1和2的要素点进行控制，最终让差异消除；其中下述2中a和b控制方式是指两种对位置差异的控制；

[0161] 本发明实施例在预表现角色和逻辑角色的位置存在差异时，控制差异可通过如下几点要素实现：

[0162] 1、保持预表现角色和逻辑角色的一致性；

[0163] 即角色的速度改变，外形的变化均可通过预表现实现；

[0164] 2、随着时间推移预表现角色和逻辑角色的差异范围控制；

[0165] a.预表现角色的距离大于一定值时，将预表现角色减速直到零；

[0166] b.预表现角色的位置超过极限值，则强制拉扯预表现角色的位置到与逻辑角色一致的位置。

[0167] 而在交互性操作下，玩家的预表现角色立即被隐藏，显示玩家的逻辑角色，且预表现角色强制同步位置和逻辑角色一致；此种情况下，关于位置突变和操作延时的解释是，由于格斗等动作游戏的爽快性，位置由移动(站立)切到攻击(受击)后有略微的偏移操作，对于玩家的体验是不明显，可以被接受的(除非在网络延时过大时，偏移操作比较明显)；而技能释放后(如人物受击)后，按键的响应受动画表现的影响，自然会有一些延时情况，玩家对此己有延时的预期，所以操控上并没有太大的感知损失，也是可以接受的；基于此，在交互性操作下，可采用游戏同步进行游戏表现，图16示出了交互性操作下采用游戏同步进行游戏表现的示意图；

[0168] 因此，非交互性操作的预表现比较适用于对实时性要求很高的游戏类型中，且不会影响打击的精准性，两全其美；由于非交互操作对响应要求也很高，预表现后与网络状态没有关系，操作者的体验也非常的流畅。

[0169] 站在游戏服务器的角度，游戏服务器接收游戏客户端的上传数据包，从下发队列中删除Frame数据块的原理与图12所示流程类似；相应的，图17示出了本发明实施例提供的从下发队列中删除Frame数据块的方法流程图，参照图17，该方法可以包括：

[0170] 步骤S400、接收上传数据包；

[0171] 步骤S410、判断所述上传数据包中的CheckSum是否为预定值；

[0172] 可选的，预定值可以为零，也可以是约定的其他值，预定值表示的是约定的CheckSum的原始值；CheckSum为预定值说明上传数据包未被篡改，CheckSum不为预定值，说明上传数据包被篡改，所接收的上传数据包不能被处理。

[0173] 步骤S420、在所述上传数据包中的CheckSum为预定值时，判断所述上传数据包中的接收确认信息对应的下发编号，是否大于上一次接收的上传数据包中的接收确认信息对应的下发编号；

[0174] 可设当前接收的上传数据包中的接收确认信息对应的下发编号为RecvAck，上一次接收的上传数据包中的接收接收确认信息对应的下发编号为LastRecvAck，则需判断RecvAck是否＞LastRecvAck；

[0175] 步骤S430、在所述上传数据包中的接收确认信息对应的下发编号，大于上一次接收的上传数据包中的接收确认信息对应的下发编号时，从下发队列中删除与所述上传数据包中的接收确认信息对应的下发编号，相应的Frame数据块。

[0176] 相应的，游戏服务器在发送下发数据包时，可将一个第二预定时间内同一游戏场景中的游戏客户端发送的游戏操作指令，整合成Frame数据块并写入下发队列，从而在一个第二预定时间内，基于Seq’，Ack’，下发队列中的Frame数据块形成下发数据包，并发送给游戏客户端。

[0177] 可选的，在一局游戏结束时，游戏客户端的上传编号和游戏服务器针对该局游戏的下发编号可清零后，在新的一局游戏开始时重新计算；即游戏客户端可在每一局游戏结束时，将上传编号清零，并在新的一局游戏开始时，根据上传数据包的上传次数或者游戏操作指令的获取序数，重新计算上传编号；游戏服务器可维持有各局游戏对应的下发编号，在一局游戏结束时，将该局游戏的下发编号清零，并在新一局游戏开始时，根据下发数据包的下发次数重新计算新一局游戏对应的下发编号。

[0178] 下面以PVP(玩家对战)游戏为例，对本发明实施例提供的游戏同步方法进行介绍；图18示出了PVP游戏类型的游戏系统的可选示意图，参照图18，游戏服务器可以包括：大区服务器，匹配服务器，业务服务器，PVP服务器；

[0179] 在进行PVP游戏时，玩家A与B通过各自的游戏客户端，基于3G、4G、WIFI(无线保真)等无线接入点登录大区服务器；当玩家A和B需要进入PVP模式时，玩家A和B的匹配请求将通过大区服务器中转到匹配服务器，玩家A与B匹配成功之后，再通过业务服务器获取到玩家A和B的玩家数据，并且分配一个PVP服务器IP(网络之间互连的协议的地址)，然后大区服务器将玩家A和B的玩家数据和PVP服务器IP，同时下发给玩家A和B；最后，玩家A与B通过PVP服务器进行PVP数据的实时同步；

[0180] 在进行游戏同步时，如图19所示，如果玩家A发动了一个技能，则技能相应的游戏操作指令将被玩家A的游戏客户端写入到上传队列中，并在一个第一预定时间到来时，将该操作指令数据，当前上传编号，上一次接收的下发数据的接收确认信息加入到上传数据包中，传送给PVP服务器；

[0181] PVP服务器维持有下发队列，当接收到玩家A的游戏客户端上传的上传数据包后，可基于该上传数据包中的接收确认信息从下发队列中删除相应的Frame数据块；同时，基于该上传数据包中的游戏操作指令生成Frame数据块，并写入到下发队列中；

[0182] PVP服务器在一个第二预定时间到来时，将下发队列中的Frame数据块，当前下发编号，及对最近接收到的上传数据包的接收确认信息加入到下发数据包中，传送给玩家A和B的游戏客户端；

[0183] 玩家A的游戏客户端接收到下发数据包后，基于下发数据包中的接收确认信息删除下发队列中相应的游戏操作指令，同时，基于下发数据包中的Frame数据块进行游戏同步表现；玩家B的游戏客户端接收到下发数据包后，也进行相应的游戏表现，从而在玩家A发动一个技能后，在玩家A和B的游戏客户端同步的实现如图19所示的游戏表现。

[0184] 可选的，在本发明实施例中，游戏客户端所设置的第一预定时间可以，大于游戏服务器所设置的第二预定时间；如第一预定时间可以是99ms(毫秒)，第二预定时间可以是66ms(毫秒)，显然此处的具体数值仅是可选的。

[0185] 在实现游戏同步的过程中，本发明实施例可避免游戏客户端重复发送游戏服务器已接收的游戏操作指令，且可避免游戏服务器未接收的游戏操作指令被遗漏发送，游戏服务器也可避免重复发送游戏客户端已接收的帧数据块，且可避免游戏客户端未接收的帧数据块被遗漏发送，具有较高的通讯可靠性；

[0186] 同时，本发明实施例通过基于UDP通信协议的FSP协议栈，有效的实现了网络不稳定时，游戏客户端和游戏服务器的通讯可靠性；

[0187] 另外，通过预表现技术可以在网络不稳定时，使得玩家依然能够获取流畅的操作体验和视觉表现；并且在游戏服务器侧，本发明实施例通过简单高性能的服务器逻辑，实现游戏服务器的数据处理，可以大大提高游戏服务器能够承担的PVP单局数，降低游戏服务器的运行成本。

[0188] 下面对本发明实施例提供的游戏客户端进行介绍，下文描述的游戏客户端可与上文描述内容相互对应参照。

[0189] 图20示出了本发明实施例提供的游戏客户端的结构框图，参照图20，该游戏客户端可以包括：

[0190] 游戏操作指令获取并加入模块100，用于每获取一个游戏操作指令，将所述游戏操作指令加入上传队列中；

[0191] 上传数据包上传模块110，用于每隔第一预定时间将所述上传队列中的游戏操作指令加入上传数据包中，并向游戏服务器发送所述上传数据包；

[0192] 下发数据包接收模块120，用于接收所述游戏服务器每隔第二预定时间发送的下发数据包；所述下发数据包包括：当前的第二预定时间所述游戏服务器的下发队列中存在的帧数据块；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令；

[0193] 指令删除模块130，用于根据所述下发数据包，从所述上传队列中删除所述游戏服务器已接收的游戏操作指令；

[0194] 游戏表现控制模块140，用于根据所述下发数据包，控制游戏表现。

[0195] 可选的，所述上传数据包还包括：当前的上传编号，游戏客户端最近一次接收的下发数据包的接收确认信息；其中，所述最近一次接收的下发数据包的接收确认信息，携带有最近一次接收的下发数据包所对应的下发编号；

[0196] 所述下发数据包还包括：当前的下发编号，游戏服务器最近一次接收的上传数据包的接收确认信息；其中，所述最近一次接收的上传数据包的接收确认信息，携带有所述游戏服务器最近一次接收的上传数据包所对应的上传编号；

[0197] 相应的，指令删除模块130具体可用于：根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从所述上传队列中删除对应上传编号的游戏操作指令。

[0198] 可选的，指令删除模块130在根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从所述上传队列中删除对应上传编号的游戏操作指令时，具体可用于：

[0199] 判断所述下发数据包中的接收确认信息对应的上传编号，是否大于上一次接收的下发数据包中的接收确认信息对应的上传编号；

[0200] 在所述下发数据包中的接收确认信息对应的上传编号，大于上一次接收的下发数据包中的接收确认信息对应的上传编号时，从所述上传队列中删除与所述下发数据包中的接收确认信息对应的上传编号，所相应的游戏操作指令。

[0201] 可选的，上传编号，与对应的上传数据包发送时，最新加入上传队列中的游戏操作指令的获取序数对应；其中，每获取一个游戏操作指令，游戏操作指令的获取序数加1；

[0202] 指令删除模块130在从所述上传队列中删除与所述下发数据包中的接收确认信息对应的上传编号，所相应的游戏操作指令时，具体可用于：

[0203] 确定所述下发数据包中的接收确认信息对应的上传编号，与上一次接收的下发数据包中的接收确认信息对应的上传编号的差值；

[0204] 从上传队列中删除个数与所述差值相应，且在上传队列中保留最久的游戏操作指令。

[0205] 可选的，所述下发数据包还可以包括：用于校验下发数据包是否被篡改的校验和；图21示出了本发明实施例提供的游戏客户端的另一结构框图，结合图20和图21所示，该游戏客户端还可以包括：

[0206] 校验和判断及指令删除触发模块150，用于判断所述下发数据包中的校验和是否为预定值；在所述下发数据包中的校验和为预定值时，触发指令删除模块130根据所述下发数据包中携带的最近一次接收的上传数据包的接收确认信息，从所述上传队列中删除对应上传编号的游戏操作指令。

[0207] 可选的，所述上传数据包还可以包括：用于校验上传数据包是否被篡改的校验和，所述游戏客户端的标识，所述上传数据包中的游戏操作指令的个数；所述游戏操作指令可以包括：对玩家操作的定义，该定义对应的参数，及玩家操作所在的帧号。

[0208] 可选的，所述下发数据包中的帧数据块以帧数据块列表形式存在，所述帧数据块列表中记录有至少一个帧数据块；游戏表现控制模块140具体可用于，遍历所述下发数据包中的帧数据块列表，根据帧数据块列表中各帧数据块对应的游戏操作指令，控制游戏表现；

[0209] 具体的，游戏表现控制模块140在遍历所述下发数据包中的帧数据块列表，根据帧数据块列表中各帧数据块对应的游戏操作指令，控制游戏表现时，具体可用于：

[0210] 获取帧数据块列表；

[0211] 遍历帧数据块列表中的各帧数据块，将所遍历的各帧数据块存入帧队列中；

[0212] 将帧数据块列表中的各帧数据块的帧号进行变换，得到各帧数据块对应的游戏客户端帧号，并在下一个游戏服务器帧到来前，将所得到的游戏客户端帧号锁定在下一个游戏服务器帧的前一帧；及将各帧数据块对应的游戏客户端帧号，和下一个游戏服务器帧的前一帧传入帧缓冲器中；

[0213] 每隔一帧从帧缓冲器中取出当前跳帧加速的倍数；

[0214] 根据所述倍数，从帧队列中调取帧数据块；

[0215] 根据所调取的帧数据块的游戏操作指令控制游戏表现。

[0216] 可选的，根据所述倍数，从帧队列中调取帧数据块的方式可以是：如果所述倍数为零，说明帧缓冲器正在缓冲中，没有需要处理的帧；如果所述倍数为1，则说明帧缓冲器缓冲结束，但不需要加速，从帧队列中调取出最新的帧数据块；如果所述倍数大于1，从帧队列调取出与所述倍数相应个数的帧数据块。

[0217] 可选的，所述帧数据块列表还可以包括：所述帧数据块列表中记录的帧数据块的个数；所述帧数据可以包括：游戏服务器需同步给游戏客户端的游戏操作指令，及需同步的游戏操作指令的个数。

[0218] 可选的，图22示出了本发明实施例提供的游戏客户端的再一结构框图，参照图20和图22所示，该游戏客户端还可以包括：

[0219] 预表现模块160，用于在获取游戏操作指令时，如果玩家操作为非交互性操作，则根据玩家操作进行游戏的预表现。

[0220] 在本发明实施例中，玩家角色可以具有两种角色模式，分为：预表现角色和逻辑角色；其中，预表现角色为通过直接执行玩家操作而作出表现的角色，逻辑角色为执行游戏服务器同步给游戏客户端的操作而作出表现的角色；

[0221] 在预表现模块160根据玩家操作进行游戏的预表现时，游戏客户端需保持预表现角色和逻辑角色的一致性，且随着时间推移，在预表现角色的距离大于一定值时，需将预表现角色减速直到零，并在预表现角色的位置超过极限值时，需强制拉扯预表现角色的位置到与逻辑角色一致的位置；

[0222] 可选的，游戏客户端在一局游戏结束时，可将上传队列进行清空，并在新一局游戏开始时，重新在上传队列中写入游戏操作命令；同时，游戏客户端在每一局游戏结束时，可将上传编号清零，并在新的一局游戏开始时，重新计算上传编号。

[0223] 下面对本发明实施例提供的游戏服务器进行介绍，下文描述的游戏服务器可与上文内容相互对应参照。

[0224] 图23为本发明实施例提供的游戏服务器的结构框图，在本发明实施例中，游戏服务器可以如PVP服务器，参照图23，该游戏服务器可以包括：

[0225] 上传数据包接收模块200，用于接收游戏客户端每隔第一预定时间发送的上传数据包；所述上传数据包包括：当前第一预定时间所述游戏客户端的上传队列中存在的游戏操作指令；

[0226] 帧数据块删除模块210，用于根据所述上传数据包包，从下发队列中删除所述游戏客户端已接收的帧数据块；

[0227] 下发数据包下发模块220，用于每隔第二预定时间，将所述下发队列中的帧数据块加入下发数据包中，将所述下发数据包发送给游戏客户端；一帧数据块包含有处于同一游戏场景的游戏客户端在同一第二预定时间内通过上传数据包发送的游戏操作指令。

[0228] 可选的，所述上传数据包还包括：当前的上传编号，游戏客户端最近一次接收的下发数据包的接收确认信息；其中，所述最近一次接收的下发数据包的接收确认信息，携带有最近一次接收的下发数据包所对应的下发编号；

[0229] 所述下发数据包还包括：当前的下发编号，游戏服务器最近一次接收的上传数据包的接收确认信息；其中，所述最近一次接收的上传数据包的接收确认信息，携带有所述游戏服务器最近一次接收的上传数据包所对应的上传编号；

[0230] 可选的，帧数据块删除模块210具体可用于：根据所述最近一次接收的下发数据包的接收确认信息，从下发队列中删除对应下发编号的帧数据块。

[0231] 可选的，帧数据块删除模块210在根据所述最近一次接收的下发数据包的接收确认信息，从下发队列中删除对应下发编号的帧数据块时，具体可用于：

[0232] 判断所述上传数据包中的接收确认信息对应的下发编号，是否大于上一次接收的上传数据包中的接收确认信息对应的下发编号；在所述上传数据包中的接收确认信息对应的下发编号，大于上一次接收的上传数据包中的接收确认信息对应的下发编号时，从下发队列中删除与所述上传数据包中的接收确认信息对应的下发编号，所相应的帧数据块。

[0233] 可选的，游戏服务器可记录每次发送的下发数据包的下发编号，在下发队列中所对应的帧数据块；

[0234] 相应的，帧数据块删除模块210在从下发队列中删除与所述上传数据包中的接收确认信息对应的下发编号，所相应的帧数据块时，具体可用于：根据所记录的下发编号，在下发队列中所对应的帧数据块，从下发队列中删除与所述上传数据包中的接收确认信息对应的下发编号，所相应的帧数据块。

[0235] 可选的，所述上传数据包还可以包括：用于校验上传数据包是否被篡改的校验和；图24示出了本发明实施例提供的游戏服务器的另一结构框图，结合图23和图24所示，该游戏服务器还可以包括：

[0236] 校验和判断及帧数据块删除触发模块230，用于判断所述上传数据包中的校验和是否为预定值；在所述上传数据包中的校验和为预定值时，触发帧数据块删除模块210根据所述最近一次接收的下发数据包的接收确认信息，从下发队列中删除对应下发编号的帧数据块。

[0237] 可选的，所述上传数据包还可以包括：所述游戏客户端的标识，所述上传数据包中的游戏操作指令的个数；所述游戏操作指令可以包括：对玩家操作的定义，该定义对应的参数，及玩家操作所在的帧号。

[0238] 可选的，下发数据包中的帧数据块可以帧数据块列表形式存在，所述帧数据块列表中记录有至少一个帧数据块；所述帧数据块列表还可以包括：所述帧数据块列表中记录的帧数据块的个数；所述帧数据块可以包括：游戏服务器需同步给游戏客户端的游戏操作指令，及需同步的游戏操作指令的个数。

[0239] 可选的，游戏服务器可为一局游戏维持一个对应的下发队列，在一局游戏结束时，将该局游戏的下发队列清空，并在新一局游戏开始时，根据新一局游戏中进行游戏的游戏客户端所发送的操作命令数据，重新在下发队列中写入帧数据块；

[0240] 同时，游戏服务器可维持有各局游戏对应的下发编号，在一局游戏结束时，游戏服务器可将该局游戏的下发编号清零，并在新一局游戏开始时，重新计算下发编号。

[0241] 本发明实施例可使得游戏服务器与游戏客户端在进行游戏同步时，具有较高的通讯可靠性，进一步提升游戏同步的实时性、准确性。

[0242] 本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

[0243] 专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

[0244] 结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

[0245] 对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。