不下結論,畢竟人和人的體質不同,對於某些情況,你永遠不知道是不是真有人突破了人類的生理極限
作為遊戲引擎碼農給諸位科普一下遊戲同步機制
實際上目前很多的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的理由,而右上角的延遲剛好替你背了鍋.
