Author: Super
Date: 5/17/2003
Topic: Online game synchronization
同步在网络游戏中是非常重要的，它保证了每个玩家在屏幕上看到的东西大体是一样的。其
实呢，解决同步问题的最简单的方法就是把每个玩家的动作都向其他玩家广播一遍，这里其
实就存在两个问题：1，向哪些玩家广播，广播哪些消息。2，如果网络延迟怎么办。事实上
呢，第一个问题是个非常简单的问题，不过之所以我提出这个问题来，是提醒大家在设计自
己的消息结构的时候，需要把这个因素考虑进去。而对于第二个问题，则是一个挺麻烦的问
题，大家可以来看这么个例子：
比如有一个玩家A向服务器发了条指令，说我现在在P1点，要去P2点。指令发出的时间
是T0，服务器收到指令的时间是T1，然后向周围的玩家广播这条消息，消息的内容是“玩
家A从P1到P2”有一个在A附近的玩家B，收到服务器的这则广播的消息的时间是T2，
然后开始在客户端上画图，A从P1到P2点。这个时候就存在一个不同步的问题，玩家A
和玩家B的屏幕上显示的画面相差了T2-T1的时间。这个时候怎么办呢？
有个解决方案，我给它取名叫 预测拉扯，虽然有些怪异了点，不过基本上大家也能从字面
上来理解它的意思。要解决这个问题，首先要定义一个值叫：预测误差。然后需要在服务器
端每个玩家连接的类里面加一项属性，叫TimeModified，然后在玩家登陆的时候，对客户端
的时间和服务器的时间进行比较，得出来的差值保存在TimeModified里面。还是上面的那
个例子，服务器广播消息的时候，就根据要广播对象的TimeModified，计算出一个客户端的
CurrentTime，然后在消息头里面包含这个CurrentTime，然后再进行广播。并且同时在玩家
A的客户端本地建立一个队列，保存该条消息，只到获得服务器验证就从未被验证的消息队
列里面将该消息删除，如果验证失败，则会被拉扯回P1点。然后当玩家B收到了服务器发
过来的消息“玩家A从P1到P2”这个时候就检查消息里面服务器发出的时间和本地时间
做比较，如果大于定义的预测误差，就算出在T2这个时间，玩家A的屏幕上走到的地点
P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再继续走下去，这样就能保证同步。更
进一步，为了保证客户端运行起来更加smooth，我并不推荐直接把玩家拉扯过去，而是算
出P3偏后的一点P4，然后用(P4-P1)/T(P4-P3)来算出一个很快的速度S，然后让玩家A用速
度S快速移动到P4，这样的处理方法是比较合理的，这种解决方案的原形在国际上被称为
（Full plesiochronous），当然，该原形被我篡改了很多来适应网络游戏的同步，所以而变成
所谓的：预测拉扯。
另外一个解决方案，我给它取名叫 验证同步，听名字也知道，大体的意思就是每条指令在
经过服务器验证通过了以后再执行动作。具体的思路如下：首先也需要在每个玩家连接类型
里面定义一个TimeModified，然后在客户端响应玩家鼠标行走的同时，客户端并不会先行走
动，而是发一条走路的指令给服务器，然后等待服务器的验证。服务器接受到这条消息以后，
进行逻辑层的验证，然后计算出需要广播的范围，包括玩家A在内，根据各个客户端不同
的TimeModified生成不同的消息头，开始广播，这个时候这个玩家的走路信息就是完全同
步的了。这个方法的优点是能保证各个客户端之间绝对的同步，缺点是当网络延迟比较大的
时候，玩家的客户端的行为会变得比较不流畅，给玩家带来很不爽的感觉。该种解决方案的
原形在国际上被称为（Hierarchical master-slave synchronization），80年代以后被广泛应用于
网络的各个领域。
最后一种解决方案是一种理想化的解决方案，在国际上被称为Mutual synchronization，是一
种对未来网络的前景的良好预测出来的解决方案。这里之所以要提这个方案，并不是说我们
已经完全的实现了这种方案，而只是在网络游戏领域的某些方面应用到这种方案的某些思
想。我对该种方案取名为：半服务器同步。大体的设计思路如下：
首先客户端需要在登陆世界的时候建立很多张广播列表，这些列表在客户端后台和服务器要
进行不及时同步，之所以要建立多张列表，是因为要广播的类型是不止一种的，比如说有
local message,有remote message,还有global message 等等，这些列表都需要在客户端登陆的
时候根据服务器发过来的消息建立好。在建立列表的同时，还需要获得每个列表中广播对象
的TimeModified，并且要维护一张完整的用户状态列表在后台，也是不及时的和服务器进行
同步，根据本地的用户状态表，可以做到一部分决策由客户端自己来决定，当客户端发送这
部分决策的时候，则直接将最终决策发送到各个广播列表里面的客户端，并对其时间进行校
对，保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。那么再采用预测
拉扯中提到过的计算提前量，提高速度行走过去的方法，将会使同步变得非常的smooth。
该方案的优点是不通过服务器，客户端自己之间进行同步，大大的降低了由于网络延迟而带
来的误差，并且由于大部分决策都可以由客户端来做，也大大的降低了服务器的资源。由此
带来的弊端就是由于消息和决策权都放在客户端本地，所以给外挂提供了很大的可乘之机。
综合以上三种关于网络同步派系的优缺点，综合出一套关于网络游戏传输同步的较完整的解
决方案，我称它为综合同步法（colligate synchronization）。大体设计思路如下：
首先将服务器需要同步的所有消息从划分一个优先等级，然后按照3/4的比例划分出重要消
息和非重要消息，对于非重要消息，把决策权放在客户端，在客户端逻辑上建立相关的决策
机构和各种消息缓存区，以及相关的消息缓存区管理机构，如下图所示：
消息缓存
决策机构
消息管理机构
消息来源
客户端被动行为
回发给服务器端
Client A
Client B
Client C
Client D
上图简单说明了对于非重要消息，客户端的大体处理流程，其中有一个客户端被动行为值得
大家注意，其中包括对服务器发过来的某些验证代码做返回，来确保消息缓存中的消息和服
务器端是一致的，从而有效的防止外挂来篡改本地消息缓存。其中的消息来源是包括本地的
客户端响应玩家的消息以及远程服务器传递过来的消息。
对于重要消息，比如说战斗或者是某些牵扯到玩家一些比较敏感数据的操作，则采用另外一
套方案，该方案首先需要在服务器和客户端之间建立一套Ping System，然后服务器保存和
用户的及时的ping值，当ping比较小的时候，响应玩家消息的同时先不进行动作，而是先
把该消息反馈给服务器，并且阻塞，服务器收到该消息，进行逻辑验证之后向所有该详细广
播的有效对象进行广播（包括消息发起者），然后客户端收到该消息的验证，才开始执行动
作。而当ping比较大的时候，客户端响应玩家消息的同时立刻进行动作，并且同时把该消
息反馈给服务器，值得注意的是这个时候还需要在本地建立一个无验证消息的队列，把该消
息入队，执行动作的同时等待服务器的验证，还需要保存当前状态。服务器收到客户端的请
求后，进行逻辑验证，并把消息反馈到各个客户端，带上各个客户端校对过的本地时间。如
果验证通过不过，则通知消息发起者，该消息验证失败，然后客户端自动把已经在进行中的
动作取消，恢复原来状态。如果验证通过，则广播到的各个客户端根据从服务器获得校对时
间进行对其进行拉扯，保证在该行为完成之前完成同步。
执行
等待
消息来源
Ping值大小
大
小
回发给服务器验证
等待
验证通过
执行该Action
中断执行
验证通过
验证没通过
至此，一个比较成熟的网络游戏的同步机制已经初步建立起来了，接下来的逻辑代码就根据
各自不同的游戏风格以及侧重点来写了。
同步是网络游戏最重要的问题，如何同步也牵扯到各个方面的问题，比如说游戏的规模，游
戏的类型以及各种各样的方面，对于规模比较大的游戏，在同步方面可以下很多的工夫，把
消息分得十分的细腻，对于不同的消息采用不同的同步机制，而对于规模比较小的游戏，则
可以采用大体上一样的同步机制，究竟怎么样同步，没有个定式，是需要根据自己的不同情
况来做出不同的同步决策的。
