基本同步模型基于上篇  

结论：网络抖动的情况下 可以预测玩家操作，达到平滑过渡的目的

同步频率40，帧间隔25MS。

一个BUG引发的思考

BUG：在地图一直用遥感控制玩家不停地走动，玩家控制的角色会偶然出点停下来一瞬间然后继续走，

初步查是因为这一帧的方向控制数据服务器发来的是默认值，而不是我玩家实际操作的值，严格查了客户端代码，发现这样一个可能性，因为要遥感的逻辑代码只会去写遥感的度数变量，逻辑帧发送的时候 会去取出来，然后设置为默认值，正常情况下是不会不连贯的，但是如果unity的帧数小于逻辑帧数（40） 那就会存在遥感代码写一次，逻辑代码读2次，因为读第一次会置为默认值，第二次读 就是读的默认值，这样就导致客户端发的就不是连贯的，然后把设置默认值的代码，去掉，测试还有这个问题，而且还有一个现象，unity的帧数大于逻辑帧数时，如果是上面的原因 那么肯定在逻辑代码读取一次的时候至少会存在遥感代码 写一次 数值的情况，但是这样的unity帧数下 依然有这个原因。

暂时排除客户端的原因后，在思考服务端的原因，想到了因为服务端是异步接受数据，25MS内没收到就会默认客户端什么都没做，遥感角度也是默认值，如果存在在规定时间内服务端没收到数据，就会出现这种情况，但是测试的时候是本地服务器，不太相信会出现25MS 都没有收到，请教了一下大佬，说：局域网也会出现网络抖动，实际收到的时间会在25MS 左右抖动，

基于这个原因，那么解决方案 也就好处理了，在这个游戏规则下，规定时间内，没收到来自客户端的数据时， 原来默认是空帧数据，现预测为为上一个操作的遥感角度，

修改Player.cpp部分代码如下

这种预测是基于服务端的，对于这个游戏来说预测也就只有玩家的遥感操作了，虽然看起来更连贯，但是对于服务器发给客户端的网络波动问题 ，也就是客户端预测

一个额外的问题，虽然之前已经设计了，但是觉得蛮重要的，记录一下，网络波动导致在规定时间内没有收到，但是不意味着已经丢包，下一帧可能服务端会收到2条甚至更多 客户端的数据，为了保证完全一致，因此在没有丢包的情况下， 要舍去多出来的数据，保证数据和发给客户端的一致，丢包了的话，那不用考虑取舍问题了。

取舍规则：可以按照游戏游戏特色 来取决，这个游戏下，玩家的技能操作得比较弱，在40的同步频率下，所以多个包，优先保留 有释放技能数据的包，都有释放技能的话，那就根据游戏具体规则对技能本身取舍，

----技能权重的数据 > 有技能的数据 > 非技能的数据

客户端预测：

客户端如果因为网络延迟 波动等问题，在帧时间内没有收到的话，也可以预测，等数据到来时 和预测作对比，预测失败直接回滚，玩家看到的现象就是卡了一下 然后被拉回了正确的情况，常规状态同步的话很好做，但是对于帧同步的话，如果预测了帧数据 那么 会涉及到整个游戏系统的回滚，游戏复杂度不高的话，可以吧每个逻辑操作对应一个逆操作，甚至暴力还可以到 强行备份游戏系统的数据，然后模拟，类似于备忘录模式，比如轻度IO游戏， 庞大的游戏 并不适合这种粗暴的方式，

每个指令的逆操作：预测的目的是为了减少玩家网络突然不好的情况下，逆操作可能会很复杂，甚至是回滚时间很长，然而达不到减少卡顿的目的，即使这样，如果网络卡顿 波动持续一定到一定到时间时，相比长时间卡顿，和一瞬间的卡顿体验还是好很多，

客户端可以做插值处理，即 网络同步模型 和 表现模型分为2大类， 表现模型可以插值预测处理

待续。。。