网络游戏帧锁，事件锁，客户端预测和服务端补偿，状态同步以及命令同步

2019独角兽企业重金招聘Python工程师标准>>>

一：FPS历史 传统FPS游戏，例如Quake或者half life， 采用状态同步的机制，每一个游戏帧 50ms，服务器将会广播每个客户端状态变化，当客户端收到状态变化之后，根据时间进行插值预测，插值包括内插值和外插值，内插值即在两帧之间插值 状态，而外插值则为预测未来。

这种每帧同步的机制，可以称为帧锁。Quake中核心协议就两条，1创造一个新的实体；2同步实体状态。 在服务端将会存储所有实体的当前状态，而客户端需要实现每个实体的两个基本状态同步接口，即将当前状态序列化，以及从服务器获取序列化后的状态。

二：RTS 对于有大量单位的RTS游戏，例如war3 魔兽争霸，也是采用帧锁的，但是不能采用状态同步，而是采用了命令同步的机制，即客户端首先发起命令，在该帧同步时，将命令发往服务器，服务器接受到所有客户端命令，确认之后，广播给所有客户端，因此通常命令发起到执行需要一定时间，这段时间可以是1frame或者2frame。 http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php/

1：客户端在相同的时间帧开始执行命令， 2：游戏中所有的随机采用相同的随机种子。

每个单位行为都是确定的，即在目标时间，到到目标位置，这也就要求了例如发射一个子弹，那么发射初就已经知道了目标，并且知道了子弹多久命中目标。 即使目标移动了，命中和时间也不会改变。

主要问题是：客户端不能立即响应用户输入，这时候需要客户端预测。

三：事件锁 在mmo 里面世界较大，单位比较多，通信基本是发送message，消息报文，这个报文只在事件发生的时候发送。 例如移动事件，释放技能事件，被击事件，状态同步和quake不同，quake传递的是每帧之间状态的 delta变化，而事件有点类似于 命令。 但是存在一个问题，mmo里面各个客户端没有一个统一frame锁概念，客户端执行相同命令，也不一定能够产生相同的输出，因此需要定期对状态进行强制同步。

例如客户端发送移动命令给服务器，客户端自己执行移动命令，同时服务器广播移动命令； 服务器检查移动命令正确，则不修改客户端，否则如果不正确，则通知客户端停止移动，或者修正移动的路点。 同步的话，客户端通过加速执行命令即可。 因为在服务器上保存有最权威状态，所有客户端状态不一致的时候，服务器强制同步。

转载于:https://my.oschina.net/u/186074/blog/425503