动作手游实时PVP帧同步方案（客户端）

1、概述

1.1、基于UDP的帧同步方案

　　在技术选型方面，之所以选择帧同步方案，在Kevin的一篇介绍PVP帧同步后台实现的文章中已经做了详细叙述，这里简单摘要如下：

　　高一致性。如果每一帧的输入都同步了，在同样的上下文中，计算得出的结果应该也是同步的。

　　低流量消耗。除了帧同步，其它方案（比如状态同步）想做到高一致性，需要同步非常大量的数据。无论是对于移动网络，还是固络都是不合适的。

　　服务器逻辑简化。采用帧同步方案，服务器只需要做简单的帧同步，不需要关心太多的业务细节。有利于客户端功能的扩展和服务器的稳定和性能。

　　反作弊。客户端只需要在适当机时上报校验数据给服务器，服务器对2个客户端上报的数据进行对比，就可以快速识别是否有人作弊。然后通过无收益的方式间接防止作弊。

　　那么，为什么选择UDP而不是TCP呢？主要有2点原因：

　　弱网络环境。

　　实时性要求。

　　我们通过一个测试APP，在WIFI和4G环境下，采用TCP和UDP两种方式连接同一个服务器，分别获得对应的RTT进行对比。

　　我们可以发现，在弱网络环境下，UDP的RTT几乎不受影响。而TCP的RTT波动比较大，特别是受丢包率影响比较明显。

1.2、基于UDP的FSP协议栈

　　由于UDP具有不可靠性，所以在UDP的基础上实现一个自定义的协议栈：FSP，即FrameSyncProtocol。

　　FSP的基本原理就是防照TCP的ACK/SEQ重传机制，实现了传输的可靠性，同时还采用冗余换速度的方式，又保证了传输的**速率。在帧同步方案中一举两得。

2、技术原理

2.1、帧同步技术原理

　　如下图所示，客户端A的操作A1与客户端B的操作B1封装成OperateCmd数据发送给PVP服务器。PVP服务器每66MS产生一个逻辑帧，在该帧所在时间段内收到A1和B1后，生成一个Frame数据块，在该帧时间结束时，将Frame发送给客户端A和B。Frame数据块内有该帧的帧号。客户端A和B收到Frame数据后，便知道该帧内，客户端A和B都做了什么操作。然后根据收到的操作A1和B1进行游戏表现，最终呈现给玩家A和B的结果是一致的。从而实现客户端A与B的数据同步。

图1 帧同步技术原理

2.2、FSP协议栈原理

　　如下图所示，发送者维持一个发送队列，对每一次发送进行编号。每一次发送时，会将待发送的数据写入队列。然后将队列里的数据+编号发送给接收者。

　　接收者收到数据后，会将该编号回送给发送者以确认。发送者收到确认编号后，会将该编号对应的数据包从队列中删除，否则该数据仍保存在发送队列中。

　　下次发送时，会有新的数据进入队列。然后将队列中的数据+最新的编号发送给接收者。以此循环反复。

图2 FSP协议栈原理

上图解析：

　　第1次发送，在发送队列里只有Data1，于是将Data1和编号1（Seq=1）发送给接收者。收到确认编号1（Ack=1）后，将Data1从队列中删除。

　　第4到7次发送，由于从第4次发送开始就没有收到确认编号，于是队列中包含了Data4到Data7。第7次发送后，收到确认编号6，于是将Data4至Data6从队列中删除。

　　第8次发送，队列中包含Data7和Data8。发送后收到确认编号8，从而将Data7和Data8从队列中删除。

　　以上的关键点是，发送者未收到确认编号，并不一直等待，而是会继续下一次发送。结合图1：

　　如果发送者是服务器，则会每隔66MS会将一个Frame数据写入发送队列，然后将该队列里的所有Frame数据一起发送给客户端。

　　如果发送者是客户端，则会在玩家有操作时，将玩家的每一个OperateCmd数据写入发送队列，然后将该队列里的所有OperateCmd数据一起发送给服务器。如果发送队列不为空，则每隔99MS重复发送。如果发送队列为空，则不再发送。直到玩家下一次操作。

　　由于服务器和客户端即是发送者，又是接收者。则服务器和客户端的每一次发送，除了会带上该次发送的编号，还会带上对对方发送编号的确认。

3、技术实现

3.1、整体框架

图3 PVP通讯模块整体框架

　　这是一个典型的手游PVP通讯模块的整体框架。这里主要分享一下FSP模块和帧同步模块的技术实现。

3.2、FSP模块

　　FSP模块主要用来实现FSP协议栈。其协议格式定义如下。

　　FSP上行协议定义：

Seq

Ack

SomeData

OperateCmd List

CheckSum

　　FSP下行协议定义：

Seq

Ack

Frame List

CheckSum

　　如下图所示，是FSP模块的接收逻辑流程。

图4 FSP模块接收逻辑流程

　　其中关键点是：

　　对Recv New Ack判断，对曾经发送过的Operate进行确认删除。

　　对Recv New Seq判断，过滤掉因为网络问题造成乱序的包。

　　上图中，接收到的Frame最终都存储在RecvQueue中。我们将接收逻辑放在子线程中。所以只需要在主线程中需要Recv的时刻从RecvQueue中读取FremeList即可。

　　如下图所示，是FSP模块的发送逻辑流程。发送逻辑同样放在子线程中。发送逻辑有2种触发方式：

　　业务层主动调用发送

　　每隔指定时间触发一次（在WIFI和4G下使用不同的时间，可以减少服务器收到的纯确认包比例，有利于提高通讯性能）

图5 FSP模块主动发送逻辑流程

图6 FSP模块定时发送逻辑流程

3.3、帧同步模块

　　下图是帧同步模块的实现框架。

图7 帧同步模块实现框架

　　按照上图箭头编号描述如下：

　　（1）负责接收来自FSP模块的FrameList。

　　（2）将FrameList里的每1帧都存入FrameQueue。

　　（3）同时将FrameList的每1帧的帧号进行变换后，得到客户端帧号。同时，在等下1个服务器帧到来之前，需要将客户端的帧锁定在下1个服务器帧的前一帧（LockFrameIndex）。然后　将FrameIndex和LockFrameIndex传入FrameBuffer。

　　（4）客户端每1帧从FrameBuffer中取出当前可能需要跳帧加速的倍数（SpeedUpTimes）。

　　（5）如果SpeedUpTimes为0，则表示正在缓冲中，没有需要处理的帧。如果SpeedUpTimes是1，则表示缓冲结束，但是不需要加速，只需要处理最新的1帧。如果SpeedUpTimes大于1，则从FrameQueue里取出这SpeedUpTimes个帧，将里面的SyncCmd取出来。

　　（6）将SyncCmd传入OperationExecutor。

　　（7）OperationExecutor与具体游戏的业务逻辑相关联，负责将SyncCmd传入给业务逻辑和预表现模块进行具体的处理。

　　其流程图如下：

图8 帧同步逻辑流程1

图9 帧同步逻辑流程2

4、最新优化

4.1、断线重连优化

　　在传统网络模块开发思想中，当发送超时达到阀值，或者底层判定断开连接时，需要重新建立连接。之前这部分工作是交给一个偏上层的模块来执行，该模块需要等Apollo通讯模块连接成功之后，才进行PVP通讯模块的连接。这样使逻辑变得复杂。

　　由于UDP本身的不可靠性，可以认为网络断线也是其不可靠性的一部分。

　　而FSP协议栈就是为了解决UDP的不可靠性而设计的，所以也附带解决了断线重连问题。

　　去除了原来的断线重连逻辑之后，用FSP模块本身的特性来处理断线重连，实测能够提高网络恢复的响应速度。由于PVP服务器设定的超时阀值是15秒，有些时候，其实网络已经恢复，但是由于Apollo通讯模块对网络的恢复响应过于迟钝，造成不必要的判输。

4.2、接入GSDK

　　从目前接入GSDK后的数据来看，能够减少一定的网络延时，但是并不明显。

4.3、AckOnly优化

　　AckOnly优化是指减少服务器收到的纯确认包数据。这样做的目的是：

　　减少包量，有助于在WIFI下节省路由器性能。GSDK有个统计表明，有大概20%多的网络延时是因为路由器性能造成。

　　节省流量，一定程度上也可以节省网络设备性能，同时在4G下为用户省钱。

　　该优化分2部分实现：

　　（1）空帧免确认

　　（2）WIFI延迟确认

　　在优化前的AckOnly比例为：57%

　　空帧免确认优化后降到：38%

　　WIFI延迟确认优化后降到：25%

5、一些尝试

　　将FSP模块抽象得与业务无关，使之可快速完成一个使用帧同步方案通讯的Demo成为可能。

　　实验了本地局域网PVP对局，只要在同一网段下，可以成功对局。（如果有需求，可以实现该功能）

　　实验了本地蓝牙PVP对局，发现蓝牙是带连接态的，并且其通讯是用类似TCP的数据流进行的。同时它与WIFI信号有干扰，如果开启WIFI，其延时非常高。在非WIFI下，其单条数据的延时很低，但是如果以66MS的频率发送数据，则延时又非常高。

　　建立了一套用于FSP在线诊断和断线诊断的工具。

转自：http://gad.qq.com/article/detail/7171195

动作手游实时PVP帧同步方案（客户端）相关推荐

动作手游实时PVP技术揭密（服务器篇）
前言我们的游戏是一款以忍者格斗为题材的ACT游戏,其主打的玩法是PVE推图及PVP 竞技.在剧情模式中,高度还原剧情再次使不少玩家泪目.而竞技场的乐趣,伴随着赛季和各种赛事相继而来,也深受玩家喜爱, ...
神位纷争服务器维护,《神位纷争》沉寂了一年的硬核动作手游从PVP到PVE的转型...
由微笑科技推出的第三人称动作手游<神位纷争>在沉寂了一年之后,终于是在此前正式登陆了安卓平台. 经过一系列的调整和更新,此次的正式版本以「神位纷争 2.0」的全新面貌重新展现在玩家面前. ...
从一款已上线的MMO手游分析游戏地图的同步方案
地图几乎是每一部RPG.MOBA.动作冒险等游戏作品中必不可少的东西,而地图的设计也是影响玩家体验的重要元素之一,游戏中的地图该怎么设计呢?本文将以一款已经上线的MMO手游为例,介绍地图在设计中需要注 ...
手游后台PVP系统网络同步方案总结
http://www.gameres.com/476063.html 概述 PVP系统俨然成为现在新手游的上线标配,手游Pvp系统体验是否优秀,很大程度上决定了游戏的品质.从最近半年上线的新手游来看, ...
实时帧数手机_使命召唤手游高帧率帧数多少帧-高帧率帧数介绍_使命召唤手游...
使命召唤手游高帧率帧数多少帧?很多玩家不知道使命召唤手游中高帧率是多少帧,下面小编就给大家带来使命召唤高帧率帧数介绍,感兴趣的小伙伴快来看看吧. <使命召唤手游>高帧率帧数介绍一.高帧率 ...
帧同步与状态同步：王者荣耀的帧同步方案
以下为<王者荣耀>技术总监复盘回炉历程演讲全文如今已经大获市场成功的<王者荣耀>一直是业内各方关注的对象,而我们也知道这款产品在成为国民级游戏之前,也遇到过一段鲜有人知的调优 ...
《鬼泣-巅峰之战》制作人：预约800万的动作手游是怎么做出来的？
凭借<鬼泣>IP的影响力,由CAPCOM授权.云畅游戏开发的<鬼泣-巅峰之战>手游,在公布之后受到许多玩家的关注,目前游戏全渠道预约人数超过了800万.葡萄君此前也写过这款手游 ...
手游实时语音，你所不知道的那些事
随着手机性能的提高,手游开始向复杂化发展.不再是以消消乐这种简单的小游戏为主,RPG.实时对战类游戏开始变火.这种游戏,由于有玩家间的交互,有团队作战.配合,保证玩家能够进行实时语音通话,成为极大的需 ...
《火柴人联盟》制作人鬼人谈如做好动作手游
<火柴人联盟>制作人鬼人谈如做好动作手游发布者: justsolo | 发布时间: 2015-1-21 00:20| 评论数: 19 游戏类型:手游游戏/平板游戏设计类型:[系统/框 ...

动作手游实时PVP帧同步方案（客户端）

动作手游实时PVP帧同步方案（客户端）相关推荐

最新文章

热门文章