多人地图的服务端和客户端同步是一个老话题了。公司的新游戏最近在做多人同屏的地图模块，需要先调研一下这方面的技术。打算采用状态同步，因为是大地图人数较多，而且游戏类型本身对位置的精确度要求没那么高。所以以下分析都是针对状态同步而非帧同步的做法。
这里参考了云风的博客以及其他一些的资料，把目前主流的同步策略在这里做下总结。
流程如下：
进入地图时做一次客户端和服务端的对时，以服务端为准，计算时间差，以后每隔一段时间（1分钟）对时一次。
客户端每隔一段时间（1秒），将当前运动状态（位置、速度、加速度）和时间戳T1同步到服务端。
服务端接到客户端同步后，立即推送给地图中的所有人的客户端。以下对于接收方是自己和其他人，两种情况分别讨论：
- 对于其他人，根据T1时刻的运动状态和当前本地时间T2，计算T2 + 1秒时刻的预测位置，反推当前的速度。
- 对于自己，根据T1时刻的运动状态和当前本地时间T2，计算当前时刻（T2）的预测位置，只要实际位置和预测位置相差不大，不用修正；否则直接移动到预测位置。
对于这套策略的总结如下：
以客户端的操作手感为先，服务端只做校验，防止作弊。这样对于自己来说，操作体验和单机无异；对于地图上显示的其他玩家，位置还原的精准程度取决于上述步骤2中同步的频率，理论上，频率越高则越精准，不过也会带来更高的网络和服务器开销，同时也要考虑游戏类型的实际需求，各方面因素综合考虑。
为了减小网络延迟的影响，采用对时和预测补偿的做法。对时是在进入地图的时候做一次，以后每隔1分钟再做一次，以防本地时间跳变带来的影响。预测补偿很重要，对于其他人的运动，我们总是预测1秒后的位置，再反推当前速度，为的是平滑处理，避免出现跳变。
保持一定的同步频率，还有一个好处是保持网络流量稳定，避免玩家在频繁操作时大量发包。例如，在带摇杆的游戏里玩家有可能会旋转摇杆在原地转圈，其实这种情况下其他玩家不用关心到那么细，只用保持一定采样频率即可。另外，就算客户端需要加入物理引擎也很方便，服务端不用做强验证，只要防止穿越地图这样的明显作弊即可。
基本思路就是这些。当然这些都是理论设想，最终效果还需要在实践中检验，也有可能部分策略需要做补充和微调，部分参数如采样频率和预测时间都需要在项目中调校，为了最终实现效果和性能的平衡。