1.  网络游戏的同步

同步是网络游戏关键技术也是难点问题之一，如何同步也牵扯到各个方面的问题。比如游戏的规模、类型等。对于规模比较大的游戏，在同步方面可以下很多的工夫，把消息分得十分的细腻，对于不同的消息采用不同的同步机制。而对于规模比较小的游戏，则可以采用大体上一样的同步机制。在公网平均120-200ms的延迟下，是不存在“完全同步”的。如何通过消除/隐藏延迟，将用户带入快速的交互式实时游戏中，没有固定的模式可循，是需要根据自己的不同情况来决定采取哪些不同的同步策略。介绍同步策略之前，先简单阐述一下网路游戏的同步。

1.1. 同步涉及以下几个方面

1.1.1. 同步的对象

所谓同步的对象，就是要同步的消息，发送给谁。可以是client-client，client-server，也可以是client-server-client。其中server负责的是验证数据并转发。

(1) 单个用户，比如创建一个用户的消息，某些确认消息，转发给私聊或者好友的聊天信息。

(2) 发给同一区域中的所有用户，常见的是同屏。

(3) 发给整个游戏世界中的所有用户的消息，比如游戏中的各种通告消息。

1.1.2. 同步的数据

(1) 命令同步，即时发送。Client或者server都可以发起。比如一个用户开始行走，将发送一条描述行走的命令给server，server校验合法后，将这条命令转发给其他client中的用户。

(2) 状态同步，按照一定频率，可以区分细节度发送，这只能由server发起。

对象属性细分（对象指游戏中的玩家，怪物等）:

(1) 不需同步的属性，服务端和客户端都可根据本地的配置文件载入，比如PVE中怪物的名字，怪物的移动速度；PVP中角色技能等级数据等。

(2) 需要在创建时同步一次的，以后不会改变。比如玩家的性别。

(3) 需要频繁的同步的属性，比如玩家的生命。

1.1.3. 同步的周期

(1) 命令：即时转发

(2) 状态：按照一定的频率和细节度发送，具体的数值需要有足够的灵活性来调节。

1.2. 同步面临的问题

在目前公网环境下，既然不存在“完全的”同步，那么要想在有限的网络响应情况下，实现快速实时类游戏，提供完美交互，需要解决好以下几个问题。

1.2.1. 网络延迟问题

网络传输过程中的延迟是一定会发生的，如何减少延迟，以及延迟发生后如何减少客户端的视觉感受是每个具体项目组需要重点研究的课题，一般会采用客户端的预测以及服务器端的矫正，但不能生硬、粗暴的矫正，需要考虑客户端的视觉体验。

1.2.2. 网络带宽问题

优化带宽消耗

(1) 对象的第一次状态同步与平时的状态同步需要区别对待，第一次状态同步需要创建相应的客户端对象，需要完整的客户端信息，以后同步只需传递少量、经常会改变的信息。

(2) 每个协议内容的优化，尽量减少传输的内容。

(3) 某些复杂数据内容可以通过传递基本数据，服务器端和客户端使用相同的算法计算得到相同的内容。

1.2.3. 反外挂问题

(1) 关键游戏逻辑只在服务器端完成，但也要尽量保证客户端的流畅度。

(2) 协议需要加密，密钥会频繁的改变。

(3) 服务端收到不合理的数据，需要立即矫正。

2.  常见的同步策略

采取什么样的同步策略跟游戏的类型关系密切，常见的几种同步策略中涉及到的同步对象可以是C-C(Client-Client)，也可以是C-S-C(Client-Server-Client)。C-C就是通常说的P2P，即：client产生行为后，发送到对方client去同步该行为。C-S-C就是client将数据发送给server，然后经过server的处理(通常为校验)，再下发给各个client。至于通信的协议，目前P2P采用UDP协议的占多数，尽管安全性不如TCP，但也可省去一些额外的开销。比如TCP的重传机制带来的开销等，这点可以通过程序本身的控制来模拟实现。下面简单介绍时间轴同步与帧同步：

2.1. 时间轴同步

A产生命令，在发给B的同时，为了增加本地的流畅度，自己预测命令的执行。B收到消息后，将使用同样的算法执行命令，如图1所示。这是最简单的同步方式，缺点是B收到命令再执行时，已经有了延迟。即两者不是在“同一”时刻执行同一个命令的。

图1

为了克服上述缺点，可以在游戏开始阶段，对A与B进行对时(由于延迟的存在，对时会存在一定的误差，只要误差在容忍的范围内，还是比较好的)。A在T0产生命令的同时发送给B(消息内有A的时间戳)，但不会立即执行命令。跟B约定在T1时刻执行命令。B收到命令后，也不会立即执行。等到T1时，与A“同时”指令该命令，如图2所示。可以根据网络延迟情况，动态调整DeltaT = T1-T0的数值范围。其中：DeltaT >= 单向延迟。

图2

2.2. 帧同步

所谓帧同步简单说就是逻辑帧保持一致，如图3所示，A与B均从第0逻辑帧开始。在B端，如果更新逻辑到第m帧时，需要A的数据，那么此时进行锁帧，不再继续执行逻辑。直到接收到从A发送过来的第m帧数据，处理完后才继续执行第m+1帧。同理，在A端更新到第n帧时，如果需要B的第n帧数据，也会进行锁帧，收到B的第n帧数据，才继续执行。

图3：逻辑帧序列

优点是保证了逻辑帧的“完全同步”，而缺点也很明显：如果有一个client的网络条件比较差，跟其他client的通信延迟较大时，会导致需要交互的client都要锁帧等待该client，视觉上会有卡帧的感觉。对于网络环境较好，对视觉同步要求较高的游戏，一般会采用帧同步。

2.3. Server同步

上述描述的两种为P2P的情况，还有一种常见的同步就是有Server的参与。server可以是中转消息，也可以作为仲裁者。即：client产生命令，并发送给server。server校验通过后，再将命令下发给相关的client(可以是单个client，也可以是同区域的所有client，见1.1.1)，在本地执行命令。

这也是很多mmog中采用的同步方式，这种策略的缺点是发起命令的client可能会存在一定的等待时间，不能及时表现。也有些游戏，在client产生命令发送给server的同时，为了增加本地流畅度，自己进行简单校验后，立即执行命令进行表现。如果server没有校验通过，则使client之前执行的命令无效，即只有表现，没有血量、经验等数值的改变。

Server参与的优点是可以对client的命令进行处理或者校验，然后再下发给client执行，这样所有的client的行为基本一致，也不可能出现作弊。比如伤害计算，升级的判断等关键数据应该通过这种同步策略。

3、小结

同步策略是网络游戏中非常重要的内容，每个游戏对同步的要求又存在很大的区别。比如实时性要求不是很高(可以容忍1000ms量级的延迟)的游戏，比如mmog，可以采取一般的同步策略即可；而实时性要求较高的游戏，像竞速、格斗及体育类等，除了在技术上改进的同时，还需策划给予足够的重视，规避一些对同步影像较大的设计，巧妙地隐藏“延迟”。