不下结论,毕竟人和人的体质不同,对于某些情况,你永远不知道是不是真有人突破了人类的生理极限
作为游戏引擎码农给诸位科普一下游戏同步机制
实际上目前很多的RTS类游戏使用一种叫帧同步(可能结合状态同步)的方式来给所有玩家同步游戏
可以用一个简单的示意图来描述
- 首先,玩家P1进行了一个操作,比如按下了鼠标左键
- 那么P1会将他按下了鼠标左键的信息告诉服务器
- 服务器收到P1的消息后,会将玩家P1按下了鼠标左键的消息同步给P1,P2,P3,P4,P5,这样,所有玩家电脑上都会出现玩家P1按下了鼠标左键的操作,实现游戏的同步.
但这种同步方式,远没有上面解释的那么简单,需要知道的是,不同的玩家所在的位置不同,延迟也不同,自然因为网络抖动的原因,即使玩家A和玩家B同时按下了同样的一个操作,因为网络延迟原因可能会导致不同的结果,举个例子,A和B同时发送数据到服务端,A花了10ms,B花了20ms,于是,服务端中A先于B
因此如果服务端收到一个数据包后,就立即下发给其它所有客户端的话,比如发给C,A的数据包发给C花了90ms,而B的数据包发给C只花了50ms,就有
A--->服务端--->C 因为网络延迟或抖动,花了10+90=100ms,C实际收到A操作帧就变成了100ms
B--->服务端--->C 因为网络延迟或抖动,花了20+50=70ms,C实际收到B操作帧就变成了70ms
那么,服务端收到的信息是A操作先于B,但到玩家C哪里,就变成了B的操作先于A了
这将导致一个非常致命的情况,就是游戏的结果都不一样了,这游戏还怎么玩?并且如果每个玩家一有操作就让服务端广播一次数据包,对网络带宽也是一个巨大的挑战.除此之外,因为网络环境问题,B的操作网络数据包可能会被网络丢掉,因此,一个用的很多的做法是,一个游戏客户端可能会用更低的延迟来发送同样的数据包,比如一个操作发送3个数据包到服务端,只要当中的一个数据包能够被服务端收到,就不会对游戏造成太大的影响,你不可能因为为了鲁棒冗余的设计,让网络带宽花销也成倍增长.
因此,游戏的同步机制实际是这样的,服务端实际上会对游戏操作也进行分帧,我们假设这个帧的粒度是100ms
首先,A和B发生了某个操作,并将这个操作发送给服务端.这个时候,服务器并不会立即把A和B的操作立即下发,而是会把A和B的操作记录下来,直到第100ms的时候,才将操作下发给A和B
也就是说,在这100ms内,A和B的操作在现实世界中,谁先谁后其实已经不重要了,真正决定先后的,可能和服务端算法有关,比如B在第50ms对A造成了9999点伤害,A在第60ms对B造成9999点伤害,但因为服务器在100ms的同步帧中先处理A的数据,导致尽管是现实世界中B先出手,但仍然判定为A先对B造成伤害,当然更多的是A和B同时对对方造成伤害,导致一个"同归于尽"的结果,这样的做法有很多好处,第一个是能很大程度上避免网络抖动问题,让游戏更加平滑,第二能够减少带宽的负担,也能够让各玩家收到的操作信息保持一致,最终让游戏世界的同步保持一致
大多情况下,游戏同步时间大约在60-100ms左右,比赛服的同步时间可能会更低达到30-60ms左右,那是不是说十几毫秒的延迟全是心理作用没有影响呢?
其实也不全是,观察下面这种特殊情况,A和B同时进行了一个操作,但A比B延迟少了5ms
这将导致一种情况,A在服务器看来,A操作发生在第200ms,而B因为延迟只能算到后面的操作帧也就是300ms,即使实际的网络延迟是5ms,但它实际造成了100ms的游戏延迟,但总的来说,发生最终情况更多时候是一个概率问题,在实际游戏情况中,因为游戏数据包冗余发送机制,最终情况可能发生,但不会太多.与其说是网络延迟的锅,不如说是网络抖动影响的可能性会更大
因此注意了:游戏中显示的延迟时间,仅仅是延迟测试的时间,并不是游戏实际帧同步的时间,只有部分参考意义,真正的延迟与否还得看实际同步帧间隔时间,如果日常情况下,你说20ms和30ms那差距的10ms延迟影响你操作了,更大的可能性是总得给自己找个gg的理由,而右上角的延迟刚好替你背了锅.
