Go游戏服务器开发的一些思考（十四）：IO游戏同步（二）

概要

在本系列的11章中，介绍了IO游戏同步。本文介绍下，在此框架下的移动同步

移动同步类型

总结市面上常见的同步方法，可以大致归类为如下几种：

这里主要介绍第4种同步类型： 移动算法在服务端为主，客户端做追随的同步方式

这种同步房间优点在于：

• 逻辑简单
• 自带预测功能，命中率高
• 不错的同步效果

这种同步方法总体来说，“经济适用型”。即通过简单编码即可获得尚可的移动同步效果。

这种同步的缺点，等介绍了其运作原理后，再做总结

同步过程分析

如图，表现了一个300ms的直线移动，从300ms开始，移动状态发生改变（如停止、改变方向、改变速度）。所有的移动过程，都是上述这个过程的叠加、重复

根据十一章中的同步框架，服务器100ms给客户端同步一次位置信息

这里分析下该同步过程：

• 客户端发送第一个移动包到收到的第一条移动信息。会有一个小等于100ms的延迟 （不同步点1）
• 蓝色条为完全同步服务器状态
• 绿色条则是根据当前的速度预测服务器状态（图中只画了2条绿色条。这里假设有N条绿色条来做分析）
• N-1条绿色条是完全同步服务器状态的
• 第N条绿色条会存在不同步情况。不同步的时间为 0-100ms内（不同步点2）
• 红色条2为开始矫正过程。（不同步点3）（根据计算的矫正速度快速逼近正确的目标点）

以上是从时序上分析，下面来看下实际画面效果：

• 移动启动时略有滞后，手感上体验可能是比较“重”
• 停止时略超前被纠正，手感上体验可能是有点刹不住（快速的被矫正，画面可能会有晃动一下）
• 转弯、加速时，由于后续有在继续移动中（被矫正的速度向量平滑过渡了），一般是体验不到不同步的

网络波动情况

这里服务器定时 100ms发送 的框架下，本身自带了一定的抗网络波动的能力。

从十一章中，分析可以得出，100ms的定时发送，一般足以应对 家庭网络、WIFI、4G。

总结

从上分析也可以看出，本移动同步缺点在移动启动和结束时，但是在网络不错的环境下，一般是看不出不同的情况的

如本人试过在上海连接北京机柜的服务器。在wifi状态下，是感知不到有不同步的情况