帧同步游戏的设计

从单机游戏到网络游戏

单机游戏,这里指即时的动作类游戏,玩家输入操作,通过终端运算而进行的游戏。加入了多人网络以后,玩家的输入不仅仅只是在本地的终端上运算,还会通过网络同步,使多人可以在同一个虚拟环境中同时游戏。由此,网络多人快节奏的动作游戏带来了新的问题:一致性,响应性,带宽,延迟。网络游戏的实时PVP就是为了平衡这四点的要素。


帧同步的引入

帧同步应该是引入多人网络以后,能想到最直接 的同步方式,在理想状态下,是合适的解决方案。而现实是,帧同步需要发送大量的帧数据来驱动游戏逻辑,需要客户端能在一段时间保持网络稳定(低延迟,少量的网络抖动)。此外,还有状态同步技术,帧同步是把玩家的动作直接同步到其他玩家的终端上,通过确定性的运算达到同步效果,而状态同步是所有客户端的动作发送到服务器,由服务器计算并把最终状态广播下发。网上有大量的资料对这两种技术进行对比,下面只对帧同步的技术做讲述。


帧同步的原理

了解帧同步技术,不妨可以参考下DOOM/QUAKE I/II/III 网络模型的演化,约翰·卡马克为FPS的网络同步写下了原型,后面的版本又在这基础上做出了众多改良版本。
帧同步技术最重要的基础概念:
相同的输入+相同的时机=相同的显示
意思是每个客户端接受的输入是相同的,执行的逻辑帧也是一样的,那么结果也是同步一致的。为了跟每个机器执行的快慢无关,每个逻辑帧为固定帧数固定时长,游戏当中的实体都是按照这种设定运算,因此移动、碰撞等都能算出相同的结果。而渲染帧(一般为30到60帧),则是根据逻辑帧(10到20帧)去插值,得到一个“平滑”的展示。逻辑帧实际是是由一个个定时下发的“网络帧”来驱动,而渲染帧则由本地CPU的update驱动,渲染帧只是逻辑帧无限逼近(插值),如果逻辑帧突然中断,则游戏就会卡在那一帧状态,这就是lockstep的由来。
为了保证游戏同步执行的一致性,代码必须按照lockstep的方式组织运算,不依赖本地客户端的帧率,时间或者随机数。理想状态下,每个“网络帧”被及时接收,客户端渲染帧都能满帧运算,游戏就像播放电影一样。但在网络游戏中,各个客户端的硬件和网络情况都不一样,可能会导致客户端收到“过去时间”里的一堆网络帧,因此,必须要有处理这些堆积起来的网络数据的能力。最简单的做法是加速播放(快进),根据堆积的量计算出加速比率,以此快速地执行逻辑帧,尽快地追上最新的实时帧。同时,在加速的过程中,可以考虑丢弃用户的操作,因为玩家看到的是“过去”的状态,此时进行控制打击是没有意义的。另外一种处理方式是,直接运算直至追上最新的网络帧,这样会直接闪现到“最新”的状态,玩家可以马上操作。比较建议采用快进的手段,这种方式可以让玩家感受到相对自然的游戏画面。这一基础特性也用于支持后面的断线重连。


帧同步的响应性

对于实时PVP的游戏来说,手感流畅的角色控制体验很重要。玩家的输入往往在几十分之一秒内,就开始显示变化,而在帧同步中,玩家的输入发送到网络,下一个网络帧操作回来时尽快处理并显示 ,当网络不稳定时,常常会时快时慢,非常难以预测输入动作后,角色会在什么时候起反应。要解决这个问题,可以参考下传输语音业务的做法,在接收网络数据时,不立刻处理,而是给所有的操作增加一个固定的延迟,在延迟的时间内尽可能收集更多的网络包,然后按固定的时间去播放(运算)。这种做法相当于建立了一个网络缓冲区,平滑了因为网络抖动而时快时慢的数据包。这里添加的固定延迟可以按照玩家所在的网络延迟来设置,可以动态地取一个连续平稳(避免抖动)的值,可以使用累计或抽样的加权平均来获取延迟。玩家发出的操作只要在固定延迟内接收,游戏就可以流畅运行,网络的抖动已经被间隔相等的逻辑帧抹平了。


TCP还是UDP,这是一个问题

保证了逻辑运算的一致性以及逻辑帧的平滑加速,基本上可以动手把一个单机游戏改成多人联机游戏了,在局域网运行勉强还能接受,可惜,我们做的是互联网上的游戏。接下来了解一下移动网络的延迟情况。首先是TCP,保证了包序,丢包自动重传,看起来就是我们想要的拼图,并且已经有人帮我们实现了,而且还帮老板省了一大笔钱。诚然,可靠的传输协议非常诱人,并且也有不少成功的例子,且再权衡下缺点再做决定。TCP是基于重传来保证可靠性,如果IP包丢包,TCP协议需要等待至少2个往返时延才会重新发送这个数据包,丢包严重甚至会断线,一旦断线,则触发断线重连流程。看看下面一组数据。


这是腾讯一款以忍者格斗为题材的ACT手游给出来的数据,可以看到在各种网络情形下,UDP的表现(延迟分布)基本上都优于TCP。
那么到UDP,非面向连接的传输协议,没有自动重传,没有拥塞控制,不能保证包序,甚至不能保证可到达,只保证了数据报完整的基础特性。优点是延迟小、数据传输效率高、资源开销小,如果用来作为网络游戏的传输方案,需要在应用层定制更多适用于网游的特性。在UDP基础上定制一个应用层的协议,难度比较大。基于UDP也有一个通用的解决方案UDT,保证了可靠性和包序,但是跟TCP类似的,UDT也是基于超时重传的方式保证可靠。下面我想把一些专用定制的方案拿出来讨论。
首先,帧同步需要每帧广播数据,广播的频率非常高,这要求每次广播的数据要足够小,最好每个网络帧在一个MTU以下,这样可以避免在IP层分片,降低延迟,互联网的MTU标准为576字节,有效载荷长度控制在(576-8-20)548字节以内。为了尽量避免重传,游戏里面可以用冗余的方式——每个帧数据包实际包含了过去2帧的数据,也就是每次发3帧的数据来对抗丢包。三个包里面只要有一个包没丢,就不影响游戏。另外,定制的方案还需要有一个请求“下载”丢失帧的特性,以防止连续3个包全丢的情况。对于“下载”特性,则可以考虑使用TCP。这是全冗余的做法,缺点是会导致流量增加2倍。还有一种动态冗余算法,根据客户端的丢包状况动态调整冗余倍数,上面介绍的那款ACT游戏就是用了这种方法,本质上还是用流量换速度。
接发包速率对一款PVP竞技型的商业游戏来说至关重要,目前还只是学习到皮毛,以后深入了解后再补充。除此之外,后续还需要服务器介入,解决断线重连和反作弊等问题,先写到这里。



你可能感兴趣的:(客户端开发)