好的多人/ mmo客戶端<>服務器遊戲在運動計算中使用延遲嗎？

Question

這裏有幾個問題。

想象一下，我有客戶端A將向服務器發送以下消息：「START MOVEMENT FORWARD」。

服務器不會立即收到此消息，因爲延遲會導致延遲。

問題1：ping（或更好：round trip time）是客戶端向服務器發送消息並接收響應所需的時間。如果您可以忽略服務器注意到已收到消息並開始發送響應（這應該很短）的時間，這是否意味着以下內容？

1. 花費的時間爲客戶發送成才服務器=往返時間/ 2
2. 花費的時間服務器送東西給客戶端=往返時間/ 2

因此，當客戶端A發送該消息時，服務器應該在客戶端發送消息之後往返/ 2毫秒接收該消息。這導致我到下一個問題。

問題2：客戶端應該首先發送包，然後在實際執行該命令客戶端（在這種情況下：向前移動）之前等待往返時間/ 2毫秒以補償延遲/延遲？

現在，服務器會發送以下消息給所有附近的玩家：「客戶A現在正在向前移動」。然後這些客戶會確保客戶a的角色開始移動，這導致我接下來的問題。

問題3：客戶端是否應該收到其他客戶端已經移動的消息，並考慮到該消息是由服務器在往返時間/ 2毫秒前發送的？所以用於運動計算時間戳的當前時間應該減少往返時間/ 2？

所有這些方法都會在我的腦海中確保客戶端之間的同步得到改善，因爲考慮了延遲。這是做事的正確方式嗎？大多數其他好的多人遊戲能做到這一點嗎？任何意見，建議，選擇或隨機但相關的留言，你想給？提前致謝。

Answer 1

我認爲在大多數mmo中，除非發生嚴重滯後，否則您的客戶端主要移動時不與服務器交互。服務器藉助客戶端發送給服務器的消息再現移動。因此，例如，如果服務器滯後，客戶端將停止接收來自服務器的反饋，並恢復到服務器確定您處於的位置。這就是爲什麼你在糟糕的滯後期間跳回幾幀。這樣服務器也可以控制你的速度，這樣你就不會加速。如果您的客戶端以超過服務器確定的速度的特定速率移動，則只需跳回額外的幀即可。

其他客戶端不會讓你動彈沒有一定量的時間內，來自服務器的響應。這是你遇到「凍結滯後」的時候。

當然也有OCCURENCES所在服務器簡單地採取客戶端發送位置和盲目信任它。這些是通常易受傳送黑客攻擊的遊戲。

當涉及到的其他球員確實存在的位置是一個延遲，由此可以看出，如果你把兩臺電腦，連接到遊戲如WOW和同時放移動兩個字符。你會發現，在你開始移動他之後，兩個電腦上的非本地角色會開始移動。

客戶通常有某種滯後補償。因此，如果另一位玩家正朝某個方向移動然後停下來，您的客戶仍然會模擬該玩家的移動，直到您從服務器收到他改變方向或停止移動的消息。這就是爲什麼其他球員可以在平穩時跳來跳去的原因。這也是爲什麼玩家看起來只是在您碰到低點時滑動/跑步/走開，然後在您的客戶從服務器接收位置時返回其真實位置的原因。

當然，這個從發動機到發動機的變化，但這是一個相當普遍的問題。

編輯：忘了補充，這是很常見的服務器也使用滯後補償。如果您以範圍內的某個mmo命中某個人，該人可能不在服務器視圖範圍內。因此，服務器會爲您的客戶端提供延遲，並嘗試匹配，如果您真的在彼此的範圍內。第一季度：

Answer 2

一些優秀的多人遊戲通過允許玩家決定併發送玩家位置到服務器，即使在往返時間較長的情況下也允許玩家順利移動。有欺詐檢查機制，但客戶端是免費的。所以如果往返時間變得怪異，你會看到有人在你移動的過程中從一個地方跳到另一個地方。即使是一些MMO遊戲，它也允許客戶在未經服務器同意的情況下處理單個玩家內容，從而進入下一個階段。只有統計數據，戰鬥報告和其他一些信息纔會被髮送到服務器以及很少的欺詐檢查數據。

Answer 3

：這對我來說很合適。第二季度：我過去這樣做的方式是：如果你想讓事情感覺到反應迅速，在客戶端的模擬中立即開始執行動作，然後服務器在遊戲時間模擬遊戲時間，行動。即客戶端知道它開始的遊戲模擬時間是多少ms，所以服務器也可以在那個時候啓動它（注意：從服務器的當前時間點開始，這個時間總是倒退，所以你必須及時保存狀態去做這個）。

Q3：客戶端只有真正需要知道，他們是在一次X模擬，服務器說，事件集{A，B，C}發生在次{X，Y，Z}。然後，客戶端和服務器可以使用相同的信息進行模擬，並且通常保持同步（除非發生同時衝突）。在這種情況下，您可以讓服務器重新同步事物，這樣您通常會在相當緊密的錯誤和最平滑的體驗中結束。

如果你的目標是改善延遲的感覺你可能也只是嘗試信任的客戶端。

Answer 4

這是一個老問題，但我最近研究出類似的代碼，所以也許這會幫助某人。

是延遲在計算中總是有用的。但它比RTT稍微複雜一些。往返時間總是在變化......您的網絡代碼可以保持平均值，但與平均值的差異很大。

本地客戶端，遠程客戶端和服務器都使用算法預測當前位置。下面的數據是接近典型：

• 時間：噸
• 放置：位置（X，Y，Z）和方向（X，Y，Z，W）
• 機芯：線性運動矢量給予與長度爲速度（X，Y，Z），並 旋轉運動向量賦予軸線與長度爲轉速（X，Y，Z）

方向您需要一個從[T，P推斷算法，M]設置爲simtime。我不會在這裏提供這些。

當客戶端在[T，P，M]的船舶驅動器中記錄更改時，在T + deltaT之前不會到達服務器。但是，如果deltaT在典型網絡延遲的容忍範圍內，服務器可以說「是的，它發生在T，我接受」。否則，它可能需要糾正客戶說「沒有那麼容忍，它發生在我的時間T'」，在這種情況下，客戶將不得不重新從服務器的糾正的一個更新所有隨後驅動的[T，P，M]變化（這意味着你需要保持一個隊列或列表）。

下一個客戶端將在T + deltaT + differentdeltaT獲取它。它不可能改變它已經模擬的東西，所以如果它不延遲它的模擬，它將跳過遠程船，你會看到一個混亂的框架。這就是爲什麼遠程驅動的船隻應該使其模擬延遲一段時間，持續時間大於2 *typicalδT。這應該是一個恆定的延遲，或者逐漸改變的延遲，嚴重滯後的時候，你會看到混蛋幀仍然

可以流暢的額外平滑代碼的所有抽搐，但不這樣做，直到你的代碼，否則完美無瑕，因爲它會讓人不可能看到問題出在哪裏。

你必須有一個很好的同步時間參考。很多代碼都比較滑落（例如RakNet沒有（或沒有）非常好）。這裏有一個很好的提示：短時間內，你可以假定每個人的時鐘都以相同的速率運行，你只需要計算出偏移量是多少，所以保持一個最大和最小偏移量的窗口，並在學習時關閉它;從長遠來看，您需要補償時鐘快速或慢速運行的客戶，因此，如果您確實知道必須打開窗口，請打開該窗口。您必須使用單調遞增的本地時間源，並且不要使用處理器速度（現在是可變的）。

不，當本地「頭像」移動時不要延遲本地模擬。這看起來太沒有反應了。你可以稍微延遲一段時間（最多50毫秒）以幫助改善同步，但是一直延遲到RTT會使你的遊戲看起來令人沮喪地失去響應。爲本地延遲設置一個選項並播放它，因爲一個小的一致延遲是可以接受的，並且可以改善同步。但這不是必要的，可能會導致很多問題，所以我建議最後一次執行該代碼。 （如果你正在嘗試做一個FPS近戰遊戲，你需要做這個，所有其他的幫助你可以得到）。

至於防止欺詐與模擬平滑：首先，客戶不應該從最後一個已知的位置推斷，當官員的位置發生變化時。它應該註冊一個調整矢量，然後慢慢地從舊路徑移動到新路徑以獲得平滑（但就像我上面所說的那樣，最後執行此代碼或者將屏蔽其他錯誤）。其次，服務器應該容忍大範圍的延遲......即使在同一個以太網上的機器上，數據包延遲通常會運行5ms到100ms左右......這是一個很大的範圍。當然，你需要把它關掉，並說「如果你說你在時間T移動，但我在T + some_large_number得到了數據包，那麼我認爲你正試圖調整過去並對我說謊。」 some_large_number不應該比平均RTT大得多，以保持誠實。

模擬不會嚴格同步。他們應該在互聯網上停留不超過400毫秒，但肯定會在滯後時間以外流失到30秒或更長時間，而且你需要容忍那些因爲它們並不稀有的東西。鑑於互聯網受銅纜中光速的限制，您可以始終期望單向延遲通常至少爲您的遠端客戶100ms，通常爲500ms或更長。

因此我強烈建議你不要試圖通過互聯網混戰的FPS遊戲（一些大公司嘗試，但總是有麻煩）。如果您使用投射物（通過在一次模擬中快速運行它們並在另一次模擬中運行速度較慢），您可以執行一些技巧，以便即使計時關閉，它也會顯示。另外，FPS遊戲使用命中檢測基於攻擊者模擬的規則......當攻擊者知道他已經死於目標並且未命中時，感覺更加錯誤，然後當防禦者知道他已經擋住並被擊中時無論如何。你必須選擇一個或另一個，並且從心理上來看，這是如何完成的。近戰需要一定程度的同步，這是坦率的不可能的，大多數遊戲公司不會觸及MMORPG FPS近戰，而是使用自動瞄準（嘗試玩Mortal Online，你會明白我的意思）。

祝你好運。

Answer 5

有幾種網絡模型可以解決這些問題;

在網絡遊戲中，你需要同步兩件事，一件是時間，另一件是空間。

1. 的網絡遊戲模式叫步調一致;

你應該看看Empire2遊戲工作室的年齡寫的文章，它描述了鎖步模型的細節。

在由幀此模型，客戶端和服務器運行的遊戲邏輯框架，例如，RTS使用100毫秒，幀，服務器和客戶端將同步幀ID，這意味着同步時間。

客戶在第50幀，發送命令MoveForward，但不立即運行，客戶端會告訴服務器以51幀運行移動命令; 然後當框架51到來時，服務器和客戶端將同時運行命令。 因此客戶端和服務器邏輯將是相同的。

在這樣的模型中，在第50幀，客戶端和服務器將運行在框架49也許發出的命令，所以有在客戶端輸入反饋送花兒給人100毫秒或更多的延遲。

客戶端和服務器之間的延遲不僅包含網絡RTT，而且還包含邏輯幀延遲，即100ms;

在這個模型

，同步空間，你需要讓你的客戶端代碼和服務器代碼確定性，所以他們只能sync命令和frameId，有沒有需要同步實體狀態。

在這個模型中，輸入反饋很大，所以你需要播放動畫或聲音來幫助玩家忽略滯後。

其他車型使用狀態同步

在這個模型中，我們還需要時間同步，所以客戶端將在服務器猜測當前時間。

當玩家輸入時，客戶端立即移動，然後發送移動命令或客戶端目標位置到服務器與當前服務器時間戳，這是由客戶端估計。

當服務器接收到客戶端命令時，它知道客戶端在服務器端發出命令時，它會嘗試運行外部命令。

所有其他客戶端將收到命令，在其服務器時間內，所有其他客戶端將嘗試推斷該命令。

這些技術包括客戶端預測，服務器滯後補償，服務器實體內插。

在這個模型中，客戶端輸入反饋很短，但對於一些衝動命令，比如使用技巧，我們仍然需要使用鎖步方法，用動畫，聲音和粒子效果來化妝輸入反饋時間。

在網絡遊戲中，至少有兩種命令，第一種就像運動，命令會運行一段時間，就像一個穩定的流，它具有連續性的屬性。另一方面喜歡用冷時間技能，指揮效應會衝動，我們應該以不同的方式對待他們。