浅谈《守望先锋》中的 ECS 构架(6)
时间:2019-01-08 07:03 来源:百度新闻 作者:巧天工 点击:次
只有在预测操作时,比如玩家一直在向前跑,但是服务器那里感知到另一个玩家对他释放了一个冰冻,将他顶在原地。这样,服务器回传给玩家的位置数据:他在某时刻停留在某地就和当初他自己预测的那个时刻的位置不同。产生这种预测失败后,客户端就需要自己调节。有ECS的帮助,状态回滚到发生分歧的版本,考虑到服务器回传的结果和新了解到的世界变化,重新将之后一段时间的操作重新作用到那一刻的状态上,做起来就相对简单了。 对于服务器来说,它默认客户端会持续不断的以固定周期向它推送新的操作。正如前面所说,服务器的时刻是有意比客户端延后的,这样,它并非立刻处理客户端来的输入,而是把输入先放在一个缓冲区里,然后按和客户端固定的周期(60fps)从缓冲区里取。由于有这个小的缓冲区的存在,轻微的网络波动(每个网络包送达的路程时间不完全一致)是完全没有影响的。但如果网络不稳定,就会出现到时间了客户端的操作还没有送到。这个时候,服务器也会尝试预测一下客户端发生了什么。等真的操作包到达后,比对一下和自己的预测值有什么不同,基于过去那个产生分歧的预测产生的状态和实际上传的操作计算出下一个状态。 同时,这个时候服务器会意识到网络状态不好,它主动通知客户端说,网络不太对劲,这个时候的大家遵循的协议就比较有趣了。那就是客户端得到这个消息就开始做时间压缩,用更高的频率来跑游戏,从60fps提高到65fps,玩家会在感受到轻微的加速,结果就是客户端用更高的频率产生新的输入:从16 ms一次变成了15.2 ms一次。也就是说,短时间内,客户端的时刻更加领先服务器了,且越领先越多。这样,服务器的预读队列就能更多的接收到未来将发生的操作,遇到到点却不知道客户端输入的可能性就变少了。但是总流量并没有增加,因为假设一局游戏由一万个tick组成,无论客户端怎么压缩时间,提前时刻,总的数据还是一万个tick产生的操作,并没有变化。 (责任编辑:波少) |