概览

　　在上次实现的帧同步模型当中，游戏帧率和通信频率(也就是帧同步长度)长度是固定间隔的。但实际上，每个玩家的延迟和性能都不同的。在update中会跟踪两个变量。第一个是玩家通信的时长。第二个则是游戏的性能时长。

　　移动平均数

　　为了处理延迟上的波动，我们想快速增加帧同步回合的时长，同时也想在低延迟的时候减少。如果游戏更新的节奏能够根据延迟的测量结果自动调节，而不是固定值的话，会使得游戏玩起来更加顺畅。我们可以累加所有的过去信息得到”移动平均数”，然后根据它作为调节的权重。
　　每当一个新值大于平均数，我们会设置平均数为新值。这会得到快速增加延迟的行为。当值小于当前平均值，我们会通过权重处理该值，我们有以下公式：
　　newAverage=currentAverage∗(1–w)+newValue∗(w)
　　其中0<w<1
　　在我的实现中，我设置w=0.1。而且还会跟踪每个玩家的平均数，而且总是使用所有玩家当中的最大值。这里是增加新值的方法：

　　为了保证计算结果的确定性，计算只使用整数。因此公式调整如下：
　　newAverage=(currentAverage∗(10–w)+newValue∗(w))/10　
　　其中0<w<1
　　而在我的例子中，w=1。

　　运行时间平均数

　　每次游戏帧更新的时间是由运行时间平均数决定的。如果游戏帧要变得更长，那么我们需要降低每次帧同步回合更新游戏帧的次数。另一方面，如果游戏帧执行得更快了，每次帧同步回合可以更新游戏帧的次数也多了。对于每次帧同步回合，最长的游戏帧会被添加到平均数中。每次帧同步回合的第一个游戏帧都包含了处理动作的时间。这里使用Stopwatch来计算流逝的时间。

　　注意到我们也用到了Time.deltaTime。使用这个可能会在游戏以固定帧率执行的情况下与上一帧时间重叠。但是，我们需要用到它，这使得Unity为我们所做的渲染以及其他事情都是可测量的。这个重叠是可接受的，因为只是需要更大的缓冲区而已。

　　网络平均数

　　拿什么作为网络平均数在这里不太明确。我最终使用了Stopwatch计算从玩家发送数据包到玩家确认动作的时间。这个帧同步模型发送的动作会在未来两个回合中执行。为了结束帧同步回合，我们需要所有玩家都确认了这个动作。在这之后，我们可能会有两个动作等待对方确认。为了解决这个问题，用到了两个Stopwatch。一个用于当前动作，另一个用于上一个动作。这被封装在ConfirmActions类当中。当帧同步回合往下走，上一个动作的Stopwatch会成为这一个动作的Stopwatch，而旧的”当前动作Stopwatch”会被复用作为新的”上一个动作Stopwatch”。

　　每当有确认进来，我们会确认我们接收了所有的确认，如果接收到了，那么就暂停Stopwatch。

　　发送平均数

　　为了让一个客户端向其他客户端发送平均数，Action接口修改为一个有两个字段的抽象类。

　　每当处理动作，这些数字会加到运行平均数。然后帧同步回合以及游戏帧回合开始更新