原文鏈接

 https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/

 

Have you ever wondered how multiplayer games work?

From the outside it seems magical: two or more players sharing a consistent experience（一致的體驗） across the network like they actually exist together in the same virtual world.

But as programmers we know the truth of what is actually going on underneath is quite different from what you see.

It turns out it’s all an illusion . A massive sleight-of-hand （一個大戲法）.

What you perceive as a shared reality is only an approximation unique to your own point of view and place in time. （你所感受到的真實感，只是在你這個客戶端的“獨特的”近似表達）

Peer-to-Peer Lockstep

In the beginning games were networked peer-to-peer, with each each computer exchanging information with each other in a fully connected mesh topology(網絡拓撲). You can still see this model alive today in RTS games, and interestingly for some reason, perhaps because it was the first way - it’s still how most people think that game networking works.

 一開始，游戲網絡是p2p方式，每個游戲端都是相互鏈接的網絡拓撲結構。你仍然可以在當今的RTS游戲中看到這種模式。有趣的是，也許這是第一種網絡方式，現在很多人認為游戲網絡就是這樣工作的。

The basic idea is to abstract the game into a series of turns and a set of command messages when processed at the beginning of each turn direct the evolution of the game state. For example: move unit, attack unit, construct building. All that is needed to network this is to run exactly the same set of commands and turns on each player’s machine starting from a common initial state.

基本思路是：將游戲抽象成一系列的回合，并且在每回合開始的時候處理一組指令消息，這組指令消息會在每個客戶端推進游戲狀態。

比如移動單位、攻擊單位、建造建筑。要實現網絡聯機，只需從一個共同的初始狀態開始，在每個玩家的機器上運行完全相同的命令和回合。

Of course this is an overly simplistic explanation and glosses over many subtle points, but it gets across the basic idea of how networking for RTS games work. You can read more about this networking model here: 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond.

當然，這是一種過于簡單的解釋，并掩蓋了許多微妙之處，但它卻傳達了RTS游戲網絡運作的基本理念。

It seems so simple and elegant, but unfortunately there are several limitations.

它看起來簡單優雅，但不幸的是有一些限制。

First, it’s exceptionally difficult to ensure that a game is completely deterministic; that each turn plays out identically on each machine. For example, one unit could take slightly a different path on two machines, arriving sooner to a battle and saving the day on one machine, while arriving later on the other and erm. not saving the day. Like a butterfly flapping it’s wings and causing a hurricane on the other side of the world, one tiny difference results in complete desynchronization over time.

首先，我們很難確保游戲是完全確定的；每個回合在每臺機器上的表現都是一樣的。例如，同一個單位在兩臺機器上可能會選擇略微不同的路徑，一臺機器上可能會更早到達戰場并挽救局面，而在另一臺機器上則可能晚到并且無法挽救局面。就像一只蝴蝶扇動翅膀可能在世界另一端引起颶風一樣，一個微小的差異最終會導致隨著時間的推移完全失去同步。"

The next limitation is that in order to ensure that the game plays out identically on all machines it is necessary to wait until all player’s commands for that turn are received before simulating that turn. This means that each player in the game has latency equal to the most lagged player. RTS games typically hide this by providing audio feedback immediately and/or playing cosmetic animation, but ultimately any truly game affecting action may occur only after this delay has passed.

下一個限制是，為了確保游戲在所有機器上以完全相同的方式運行，需要等待所有玩家該回合的指令都被接收到后，才能模擬該回合的進程。這意味著游戲中每位玩家的延遲將等于延遲最大的那位玩家。即時戰略游戲（RTS）通常通過立即提供音效反饋和/或播放裝飾性的動畫來掩蓋這一問題，但最終，任何真正影響游戲的行動只能在這一延遲過去之后才能生效。

The final limitation occurs because of the way the game synchronizes by sending just the command messages which change the state. In order for this to work it is necessary for all players to start from the same initial state. Typically this means that each player must join up in a lobby before commencing play, although it is technically possible to support late join, this is not common due to the difficulty of capturing and transmitting a completely deterministic starting point in the middle of a live game.

最后一個限制源于游戲通過僅發送改變狀態的指令消息來實現同步的方式。為了讓這種方法奏效，所有玩家必須從相同的初始狀態開始。通常情況下，這意味著每位玩家在游戲開始之前必須先進入同一個大廳。盡管從技術上講支持玩家在游戲中途加入是可能的，但由于在實時游戲中捕獲并傳輸一個完全確定性的起始點非常困難，這種功能并不常見。

Despite these limitations this model naturally suits RTS games and it still lives on today in games like “Command and Conquer”, “Age of Empires” and “Starcraft”. The reason being that in RTS games the game state consists of many thousands of units and is simply too large to exchange between players. These games have no choice but to exchange the commands which drive the evolution of the game state.

But for other genres, the state of the art has moved on. So that’s it for the deterministic peer-to-peer lockstep networking model. Now lets look at the evolution of action games starting with Doom, Quake and Unreal.

盡管存在這些限制，這種模式仍然非常適合即時戰略（RTS）游戲，并且在《命令與征服》《帝國時代》和《星際爭霸》等游戲中依然得以延續。原因在于，在RTS游戲中，游戲狀態由成千上萬個單位組成，數據量過于龐大，無法在玩家之間直接交換。這些游戲別無選擇，只能交換驅動游戲狀態演變的指令。

但對于其他游戲類型，技術的前沿已經不斷發展。因此，關于確定性的點對點鎖步網絡模型的討論到此為止。接下來，讓我們看看動作游戲的演變，從《毀滅戰士》《雷神之錘》和《虛幻》開始。

 

Client/Server

In the era of action games, the limitations of peer-to-peer lockstep became apparent in Doom, which despite playing well over the LAN played terribly over the internet for typical users:

Although it is possible to connect two DOOM machines together across the Internet using a modem link, the resulting game will be slow, ranging from the unplayable (e.g. a 14.4Kbps PPP connection) to the marginally playable (e.g. a 28.8Kbps modem running a Compressed SLIP driver). Since these sorts of connections are of only marginal utility, this document will focus only on direct net connections.

在動作游戲的時代，peer-to-peer lockstep 模型的局限性在《毀滅戰士》中變得顯而易見。盡管它在局域網（LAN）環境下運行良好，但對于普通用戶而言，通過互聯網的游戲體驗卻非常糟糕：

盡管可以通過調制解調器連接兩臺運行《毀滅戰士》的機器以實現跨互聯網的對戰，但游戲的運行速度會非常慢，從完全無法游玩（例如使用14.4Kbps的PPP連接）到勉強可玩（例如使用運行壓縮SLIP驅動的28.8Kbps調制解調器）不等。由于此類連接的實用性非常有限，本文件將僅專注于直接網絡連接。

The problem of course was that Doom was designed for networking over LAN only, and used the peer-to-peer lockstep model described previously for RTS games. Each turn player inputs (key presses etc.) were exchanged with other peers, and before any player could simulate a frame all other player’s key presses needed to be received.

問題在于，《毀滅戰士》僅設計用于局域網（LAN）環境下的聯網，并采用了之前描述的適用于RTS游戲的點對點鎖步模型。每回合，玩家的輸入（例如按鍵等）會與其他玩家進行交換，而在任何玩家能夠模擬一個幀之前，都必須接收到所有其他玩家的按鍵輸入。

In other words, before you could turn, move or shoot you had to wait for the inputs from the most lagged modem player. Just imagine the wailing and gnashing of teeth that this would have resulted in for the sort of folks with internet connections that were “of only marginal utility”. :)

換句話說，在你能夠轉身、移動或射擊之前，必須等待來自延遲最大的調制解調器玩家的輸入。試想一下，這對那些使用“勉強實用”的互聯網連接的玩家來說，會帶來多少哀嚎和咬牙切齒的場面吧。:)

In order to move beyond the LAN and the well connected elite at university networks and large companies, it was necessary to change the model. And in 1996, that’s exactly what John Carmack and his team did when he released Quake using client/server instead of peer-to-peer.

在1996年，約翰·卡馬克（John Carmack）和他的團隊正是這么做的。他們在發布《雷神之錘》（Quake）時，采用了客戶端/服務器（client/server）模型，取代了點對點（peer-to-peer）模型。

Now instead of each player running the same game code and communicating directly with each other, each player was now a “client” and they all communicated with just one computer called the “server”. There was no longer any need for the game to be deterministic across all machines, because the game really only existed on the server. Each client effectively acted as a dumb terminal showing an approximation of the game as it played out on the server.

現在，每位玩家不再運行相同的游戲代碼并直接相互通信，而是變成了“客戶端”，他們都只與一臺被稱為“服務器”的計算機通信。游戲不再需要在所有機器上保持確定性，因為游戲實際上只存在于服務器上。每個客戶端實際上相當于一個dumb terminal ，展示出服務器上游戲運行時的近似畫面。

In a pure client/server model you run no game code locally, instead sending your inputs such as key presses, mouse movement, clicks to the server. In response the server updates the state of your character in the world and replies with a packet containing the state of your character and other players near you. All the client has to do is interpolate between these updates to provide the illusion of smooth movement and BAM you have a networked game.

在c/s模型中，您本地不運行任何游戲代碼，而是將按鍵、鼠標移動、點擊等輸入發送到服務器。服務器根據這些輸入更新您在游戲世界中的角色狀態，并回復一個數據包，其中包含您角色的狀態以及您附近其他玩家的狀態。客戶端所需做的只是在這些更新之間進行插值，以提供平滑運動的假象，這樣，一個聯網游戲就誕生了。

This was a great step forward. The quality of the game experience now depended on the connection between the client and the server instead of the most lagged peer in the game. It also became possible for players to come and go in the middle of the game, and the number of players increased as client/server reduced the bandwidth required on average per-player.

這是一次巨大的進步。游戲體驗的質量現在取決于客戶端與服務器之間的連接，而不是游戲中延遲最大的玩家。此外，玩家可以在游戲進行中隨時加入或退出，且由于客戶端/服務器模型平均每位玩家所需的帶寬減少，玩家數量也得以增加。

But there were still problems with the pure client/server model:

While I can remember and justify all of my decisions about networking from DOOM through Quake, the bottom line is that I was working with the wrong basic assumptions for doing a good internet game. My original design was targeted at < 200ms connection latencies. People that have a digital connection to the internet through a good provider get a pretty good game experience. Unfortunately, 99% of the world gets on with a slip or ppp connection over a modem, often through a crappy overcrowded ISP. This gives 300+ ms latencies, minimum. Client. User's modem. ISP's modem. Server. ISP's modem. User's modem. Client. God, that sucks.

Ok, I made a bad call. I have a T1 to my house, so I just wasn't familliar with PPP life. I'm addressing it now.

 John Carmack：

雖然我記得并能解釋我在《毀滅戰士》（DOOM）到《雷神之錘》（Quake）之間關于聯網的所有設計決策，但歸根結底，我在設計優秀的互聯網游戲時基于了一些錯誤的基本假設。我的初始設計是針對延遲小于200毫秒的連接優化的。那些通過優質供應商以數字連接方式接入互聯網的用戶能獲得相當不錯的游戲體驗。然而，不幸的是，世界上99%的人是通過調制解調器使用SLIP或PPP連接接入互聯網的，通常還得通過一個劣質且過于擁擠的ISP。這種情況下的延遲至少是300毫秒以上。流程是：客戶端、用戶的調制解調器、ISP的調制解調器、服務器、ISP的調制解調器、用戶的調制解調器、客戶端。天哪，這太糟糕了。

好吧，我做了一個糟糕的決定。我家里有一條T1線路，所以我根本不了解PPP用戶的生活。現在，我正在解決這個問題。

The problem was of course latency.

What happened next would change the industry forever. 接下來的事情將永遠改變整個行業。

Client-Side Prediction

In the original Quake you felt the latency between your computer and the server. Press forward and you’d wait however long it took for packets to travel to the server and back to you before you’d actually start moving. Press fire and you wait for that same delay before shooting. If you’ve played any modern FPS like Call of Duty: Modern Warfare, you know this is no longer what happens. So how exactly do modern FPS games remove the latency on your own actions in multiplayer?

在原版《雷神之錘》（Quake）中，你能明顯感受到你電腦與服務器之間的延遲。按下“前進”鍵后，你需要等待數據包往返服務器所需的時間，然后角色才會真正開始移動。按下“開火”鍵后，你同樣需要經歷同樣的延遲，才能真正射擊。

如果你玩過任何現代FPS游戲，比如《使命召喚：現代戰爭》，你會知道這種延遲已經不再存在。那么，現代FPS游戲是如何在多人模式中消除自己動作的延遲的呢？

When writing about his plans for the soon to be released QuakeWorld, John Carmack said:

I am now allowing the client to guess at the results of the users movement until the authoritative response from the server comes through. This is a biiiig architectural change. The client now needs to know about solidity of objects, friction, gravity, etc. I am sad to see the elegant client-as-terminal setup go away, but I am practical above idealistic.

到他對即將發布的 QuakeWorld 的計劃時，約翰·卡馬克（John Carmack）寫道：

我現在允許客戶端在等待服務器的權威響應到來之前，猜測用戶動作的結果。這是一個非常大的架構變更。客戶端現在需要了解物體的固體特性、摩擦力、重力等。我很遺憾看到優雅的“客戶端作為終端”的設置被舍棄，但相比于理想主義，我更傾向于務實主義。

So now in order to remove the latency, the client runs more code than it previously did. It is no longer a dumb terminal sending inputs to the server and interpolating between state sent back. Instead it is able to predict the movement of your character locally and immediately in response to your input, running a subset of the game code for your player character on the client machine.

因此，為了消除延遲，客戶端現在需要運行比以前更多的代碼。它不再是一個僅向服務器發送輸入并在接收到的狀態之間插值的dumb terminal。相反，它能夠在本地預測你的角色移動，并即時響應你的輸入，在客戶端機器上為玩家角色運行游戲代碼的一個子集。

Now as soon as you press forward, there is no wait for a round trip between client and server - your character start moving forward right away.

現在，當你按下“前進”鍵時，不再需要等待客戶端和服務器之間的往返延遲——你的角色會立即開始向前移動。

The difficulty of this approach is not in the prediction, for the prediction works just as normal game code does - evolving the state of the game character forward in time according to the player’s input. The difficulty is in applying the correction back from the server to resolve cases when the client and server disagree about where the player character should be and what it is doing.

這種方法的難點不在于預測，因為預測的工作方式與普通的游戲代碼類似——根據玩家的輸入，推進游戲角色的狀態隨時間向前演變。真正的難點在于如何應用服務器返回的修正數據，以解決客戶端和服務器在玩家角色的位置以及其行為上的分歧。

Now at this point you might wonder. Hey, if you are running code on the client - why not just make the client authoritative over their player character? The client could run the simulation code for their own character and simply tell the server where they are each time they send a packet. The problem with this is that if each player were able to simply tell the server “here is my current position” it would be trivially easy to hack the client such that a cheater could instantly dodge the RPG about to hit them, or teleport instantly behind you to shoot you in the back.

到了這里，你可能會想：“嘿，如果客戶端已經在運行代碼，為什么不讓客戶端對自己的角色具有權威性呢？” 客戶端可以運行自己的角色模擬代碼，并在每次發送數據包時簡單地告訴服務器它當前的位置。

問題在于，如果每個玩家都能夠簡單地告訴服務器“這是我的當前位置”，那么修改客戶端進行作弊將變得非常容易。比如，作弊者可以瞬間躲開即將命中的火箭彈，或者瞬間傳送到你身后射擊你。

So in FPS games it is absolutely necessary that the server is the authoritative over the state of each player character, in-spite of the fact that each player is locally predicting the motion of their own character to hide latency. As Tim Sweeney writes in The Unreal Networking Architecture: “The Server Is The Man”.

因此，在FPS游戲中，服務器對每個玩家角色的狀態必須具有絕對的權威性，即使每個玩家都在本地預測自己角色的運動以隱藏延遲。正如蒂姆·斯威尼（Tim Sweeney）在《虛幻網絡架構》中所寫的那樣：“服務器才是老大”（“The Server Is The Man”）。

Here is where it gets interesting. If the client and the server disagree, the client must accept the update for the position from the server, but due to latency between the client and server this correction is necessarily in the past. For example, if it takes 100ms from client to server and 100ms back, then any server correction for the player character position will appear to be 200ms in the past, relative to the time up to which the client has predicted their own movement.

這就是事情變得有趣的地方。如果客戶端和服務器的狀態不同步，客戶端必須接受服務器發送的角色位置更新。然而，由于客戶端和服務器之間存在延遲，這種修正必然是針對過去的狀態。例如，如果從客戶端到服務器需要100毫秒，再從服務器返回需要100毫秒，那么任何服務器對玩家角色位置的修正，相對于客戶端已經預測的時間線來看，都顯得滯后了200毫秒。

If the client were to simply apply this server correction update verbatim, it would yank the client back in time, completely undoing any client-side prediction. How then to solve this while still allowing the client to predict ahead?

如果客戶端只是簡單地照搬服務器的修正更新，直接應用到當前狀態，這將把客戶端的角色狀態強制拉回到過去，完全推翻任何客戶端預測。那么，如何在允許客戶端繼續預測的同時解決這個問題呢？

The solution is to keep a circular buffer of past character state and input for the local player on the client, then when the client receives a correction from the server,

it first discards any buffered state older than the corrected state from the server,

and replays the state starting from the corrected state back to the present “predicted” time on the client using player inputs stored in the circular buffer.

In effect the client invisibly “rewinds and replays” the last n frames of local player character movement while holding the rest of the world fixed.

解決方法是客戶端為本地玩家角色的狀態和輸入維護一個循環緩沖區（circular buffer）。當客戶端從服務器接收到修正數據時，它會采取以下步驟：

• 1.丟棄舊狀態：客戶端首先丟棄循環緩沖區中比服務器修正狀態更舊的所有記錄。

• 2.回放重演：從服務器提供的修正狀態開始，客戶端使用循環緩沖區中存儲的玩家輸入，重新計算角色的狀態，逐幀回放直到恢復到當前的“預測”時間。

通過這種方式，客戶端實際上是無形中“回放并重演”了最近 n 幀的玩家角色運動，而同時保持游戲世界的其余部分固定不變。

這一過程解決了修正延遲的問題，同時保留了客戶端預測的平滑體驗，從而讓玩家幾乎察覺不到延遲所帶來的影響。

This way the player appears to control their own character without any latency, and provided that the client and server character simulation code is reasonable, giving roughly exactly the same result for the same inputs on the client and server, it is rarely corrected. It is as Tim Sweeney describes:

... the best of both worlds: In all cases, the server remains completely authoritative. Nearly all the time, the client movement simulation exactly mirrors the client movement carried out by the server, so the client's position is seldom corrected. Only in the rare case, such as a player getting hit by a rocket, or bumping into an enemy, will the client's location need to be corrected.

通過這種方式，玩家看起來能夠即時控制自己的角色而沒有任何延遲。而只要客戶端和服務器的角色模擬代碼設計合理，對于相同的輸入能在客戶端和服務器上產生幾乎完全一致的結果，就很少需要進行修正。正如蒂姆·斯威尼（Tim Sweeney）所描述的那樣：

這是一種兩全其美的設計：在所有情況下，服務器始終保持完全的權威性。幾乎所有時候，客戶端的運動模擬與服務器執行的客戶端運動完全一致，因此客戶端的位置很少需要修正。只有在少數情況下，例如玩家被火箭擊中或撞到敵人時，客戶端的位置才需要進行修正。

“客戶端預測+服務器權威模式”是一個精心設計的平衡：客戶端提供即時反饋以實現流暢的用戶體驗，而服務器確保了游戲的公平性和同步性。

In other words, only when the player’s character is affected by something external to the local player’s input, which cannot possibly be predicted on the client, will the player’s position need to be corrected. That and of course, if the player is attempting to cheat :)