帧同步游戏的设计

从单机游戏到网络游戏

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

帧同步的引入

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

帧同步的原理

了解帧同步技术，不妨可以参考下DOOM/QUAKE I/II/III 网络模型的演化，约翰·卡马克为FPS的网络同步写下了原型，后面的版本又在这基础上做出了众多改良版本。

帧同步技术最重要的基础概念：
相同的输入+相同的时机=相同的显示
意思是每个客户端接受的输入是相同的，执行的逻辑帧也是一样的，那么结果也是同步一致的。为了跟每个机器执行的快慢无关，每个逻辑帧为固定帧数固定时长，游戏当中的实体都是按照这种设定运算，因此移动、碰撞等都能算出相同的结果。而渲染帧（一般为30到60帧），则是根据逻辑帧（10到20帧）去插值，得到一个“平滑”的展示。逻辑帧实际是是由一个个定时下发的“网络帧”来驱动，而渲染帧则由本地CPU的update驱动，渲染帧只是逻辑帧无限逼近（插值），如果逻辑帧突然中断，则游戏就会卡在那一帧状态，这就是lockstep的由来。

为了保证游戏同步执行的一致性，代码必须按照lockstep的方式组织运算，不依赖本地客户端的帧率，时间或者随机数。理想状态下，每个“网络帧”被及时接收，客户端渲染帧都能满帧运算，游戏就像播放电影一样。但在网络游戏中，各个客户端的硬件和网络情况都不一样，可能会导致客户端收到“过去时间”里的一堆网络帧，因此，必须要有处理这些堆积起来的网络数据的能力。最简单的做法是加速播放（快进），根据堆积的量计算出加速比率，以此快速地执行逻辑帧，尽快地追上最新的实时帧。同时，在加速的过程中，可以考虑丢弃用户的操作，因为玩家看到的是“过去”的状态，此时进行控制打击是没有意义的。另外一种处理方式是，直接运算直至追上最新的网络帧，这样会直接闪现到“最新”的状态，玩家可以马上操作。比较建议采用快进的手段，这种方式可以让玩家感受到相对自然的游戏画面。这一基础特性也用于支持后面的断线重连。

帧同步的响应性

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

TCP还是UDP，这是一个问题

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

Paste_Image.png

这是腾讯一款以忍者格斗为题材的ACT手游给出来的数据，可以看到在各种网络情形下，UDP的表现（延迟分布）基本上都优于TCP。

那么到UDP，非面向连接的传输协议，没有自动重传，没有拥塞控制，不能保证包序，甚至不能保证可到达，只保证了数据报完整的基础特性。优点是延迟小、数据传输效率高、资源开销小，如果用来作为网络游戏的传输方案，需要在应用层定制更多适用于网游的特性。在UDP基础上定制一个应用层的协议，难度比较大。基于UDP也有一个通用的解决方案UDT，保证了可靠性和包序，但是跟TCP类似的，UDT也是基于超时重传的方式保证可靠。下面我想把一些专用定制的方案拿出来讨论。

首先，帧同步需要每帧广播数据，广播的频率非常高，这要求每次广播的数据要足够小，最好每个网络帧在一个MTU以下，这样可以避免在IP层分片，降低延迟，互联网的MTU标准为576字节，有效载荷长度控制在(576-8-20)548字节以内。为了尽量避免重传，游戏里面可以用冗余的方式——每个帧数据包实际包含了过去2帧的数据，也就是每次发3帧的数据来对抗丢包。三个包里面只要有一个包没丢，就不影响游戏。另外，定制的方案还需要有一个请求“下载”丢失帧的特性，以防止连续3个包全丢的情况。对于“下载”特性，则可以考虑使用TCP。这是全冗余的做法，缺点是会导致流量增加2倍。还有一种动态冗余算法，根据客户端的丢包状况动态调整冗余倍数，上面介绍的那款ACT游戏就是用了这种方法，本质上还是用流量换速度。

接发包速率对一款PVP竞技型的商业游戏来说至关重要，目前还只是学习到皮毛，以后深入了解后再补充。除此之外，后续还需要服务器介入，解决断线重连和反作弊等问题，先写到这里。