寫在前面
文章的原文很多地方都能找到
我貼一處起源引擎（Source Engine）開發公司Valve Software的網址，其他的我，提供一處steam的。
① V社 VALVE（Dota2、半條命的開發） Source Multiplayer Networking
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
② Steam CSGO（Counter-Strike: Global Offensive）Source Multiplayer Networking
http://steamcommunity.com/sharedfiles/filedetails/?id=527313998
也有人做過優秀翻譯 【騰訊GAD譯館】 Source引擎多人模式網絡同步模型，我只是因爲自己注意力渙散覺得文章乾澀不寫下來就看不動，也請閱讀的大家不要用我的渣翻水平做橫向對比，取得必要知識信息就好。
【2017-09-05補充】 找資料途中發現一篇更加準確的翻譯https://tieba.baidu.com/p/1819264994 搬運原文地址已不可尋，貼吧排版不是很方便閱讀。（所以我的坑還是會填完的~）
【2018-03-12補充】 對格式進行了整理，逐句的方式太影響閱讀體驗了，內容和原來還是相同的。
正文
索引
概述 （本篇）
基礎部分 Basic networking（本篇）
支持Tickrate修改的服務器 Servers that Support Tickrate（第二篇）
實例平滑插值 Entity interpolation（第二篇）
客戶端輸入預測 Input prediction（第二篇）
服務器滯後補償 Lag compensation（第三篇）
網絡狀態視圖 Net graph（第三篇）
優化 Optimizations（第三篇）
參閱 See also（第三篇）
概述
Paragraph 1
Multiplayer games based on the Source Engine use a Client-Server networking architecture.Usually a server is a dedicated host that runs the game and is authoritative about world simulation, game rules, and player input processing. A client is a player’s computer connected to a game server. The client and server communicate with each other by sending small data packets at a high frequency (usually 20 to 30 packets per second). A client receives the current world state from the server and generates video and audio output based on these updates. The client also samples data from input devices (keyboard, mouse, microphone, etc.) and sends these input samples back to the server for further processing. Clients only communicate with the game server and not between each other (like in a peer-to-peer application). In contrast with a single player game, a multiplayer game has to deal with a variety of new problems caused by packet-based communication.
Source Engine 的多人遊戲基於一套 client-server 的網絡架構。通常，服務器是一個運行遊戲的專用主機，用於裁定世界模擬，遊戲規則，玩家輸入處理。客戶端是一個連接到遊戲服務器的計算機。客戶端和服務器之間，通過相互以高頻率發送小數據包來交互（通常頻率爲 20~30個包/秒）。客戶端從服務器接收到世界的當前狀態，並且根據這些狀態更新，生成輸出視頻、音頻內容。客戶端還負責從輸入設備（鍵盤、鼠標、麥克風等等）採樣，並且將這些輸入樣本發送到服務器做進一步的處理。各個客戶端只與遊戲服務器發生會話，而不在客戶端之間（類似於p2p應用）發生會話。與單人遊戲相比，多人遊戲需要面對消息通訊帶來的多種問題。
Paragraph 2
Network bandwidth is limited, so the server can’t send a new update packet to all clients for every single world change. Instead, the server takes snapshots of the current world state at a constant rate and broadcasts these snapshots to the clients. Network packets take a certain amount of time to travel between the client and the server (i.e. half the ping time). This means that the client time is always a little bit behind the server time. Furthermore, client input packets are also delayed on their way back, so the server is processing temporally delayed user commands. In addition, each client has a different network delay which varies over time due to other background traffic and the client’s framerate. These time differences between server and client causes logical problems, becoming worse with increasing network latencies. In fast-paced action games, even a delay of a few milliseconds can cause a laggy gameplay feeling and make it hard to hit other players or interact with moving objects. Besides bandwidth limitations and network latencies, information can get lost due to network packet loss.
因爲網絡帶寬有所限制，所以服務器不能把每一個細小的世界變化都打包通知給所有的客戶端。所以產生了替代方法：固定頻率下服務器根據遊戲世界的狀態生成 snapshot，並且將snapshot廣播給所有的客戶端。 網通通信包在客戶端和服務器之間的傳導需要花費一定的時間（即：ping time的一半）
【額外說明】GAD譯館將ping time直接解釋爲RTT，所以我額外貼一段RTT的圖示，本文後面也會解釋RTT與Ping
To this end, we define the round-trip time (RTT), which is the time it takes for a small packet to travel from client to server and then back to the client
RTT：一個很小包從客戶端發送到接收端再返回客戶端的時間。ping命令使用的也是這麼一個非常小的包來試探網絡的情況。
這也就是說客戶端的時間總是比服務器稍晚一些。 此外，客戶端的輸入信息包在傳輸時也會發成延遲，所以服務器也在處理着延時過的用戶指令。還有，每一個客戶端都有不同情況的網絡延遲，這取決於他們的後臺事物情況以及客戶端的幀率，也並不是恆定的。
這些存在於服務器和客戶端的時間差異，將會引起邏輯上的問題，並且隨着網絡延遲的增高問題變得更加嚴重。在快節奏的動作遊戲中，甚至幾毫秒的延遲，就會有延遲感，並且造成難以擊中其他玩家、難以和移動物體互動的情況。除了帶寬限制和網絡延遲，網絡數據包的丟失還會造成信息的丟失。
【額外說明】關於Tick的說明，可見Basic networking的解釋
Paragraph 3
To cope with the issues introduced by network communication, the Source engine server employs techniques such as data compression and lag compensation which are invisible to the client. The client then performs prediction and interpolation to further improve the experience.
爲了處理這些網絡通信帶來的問題，Source引擎服務器採用了譬如數據壓縮（data compression）、延遲補償（lag compensation）等技術，而這些技術對於客戶端是不可見的（透明的）。而客戶端可以採用執行預測值和平滑插值來提升遊戲體驗。
Basic networking 基礎部分
Paragraph 1
The server simulates the game in discrete time steps called ticks. By default, the timestep is 15ms, so 66.666… ticks per second are simulated, but mods can specify their own tickrate.Note: The -tickrate command line parameter is not available on CSS, DoD S, TF2, L4D and L4D2 because changing tickrate causes server timing issues. The tickrate is set to 66 in CSS, DoD S and TF2, and 30 in L4D and L4D2. During each tick, the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary. A higher tickrate increases the simulation precision, but also requires more CPU power and available bandwidth on both server and client.The server admin may override the default tickrate with the -tickrate command line parameter, though tickrate changes done this way are not recommended because the mod may not work as designed if its tickrate is changed.
服務器以一個離散的時間步長模擬遊戲世界，我們稱之爲 Tick。默認情況下，時間步長爲15ms，也就是每秒發生66.666…次 Tick，但是，通過修改，用戶可以指定自己的 tickrate （Tick頻率）。
Note: -tickrake 命令行命令在CSS（Counter-Strike： Source 反恐精英：起源），DoD S（Day Of Defeat Source 勝利之日起源），TF2（Team Fortress 2 軍團要塞2），L4D（Left 4 Dead 求生之路） 和 L4D2（Left 4 Dead 2 求生之路2）並不可使用，因爲tickrate的變化將會引起服務器記時的問題，所以在CSS,，DoD S，TF2中Tick頻率爲66，在L4D，L4D2中Tick頻率爲30。
在每一個Tick中，服務器都要處理用戶傳遞來的命令、做一步物理模擬、檢測遊戲規則、更新所有對象的狀態。一個Tick模擬完成後，服務器決定某個客戶端是否需要一個更新，如果需要則發送一個snapshot到該客戶端。 較高的Tick頻率有利於模擬更加準確，但是要求CPU有更高的處理能力，也要求客戶端和服務器的帶寬可以承載。服務器的管理者可能使用 -tickrate 這個命令行命令來修改默認的tickrate，但是這樣的方法並不推薦，因爲tickrate的修改可能會使得程序運行發生改變。
Paragraph 2
Clients usually have only a limited amount of available bandwidth. In the worst case, players with a modem connection can’t receive more than 5 to 7 KB/sec. If the server tried to send them updates with a higher data rate, packet loss would be unavoidable. Therefore, the client has to tell the server its incoming bandwidth capacity by setting the console variable rate (in bytes/second). This is the most important network variable for clients and it has to be set correctly for an optimal gameplay experience. The client can request a certain snapshot rate by changing cl_updaterate (default 20), but the server will never send more updates than simulated ticks or exceed the requested client rate limit. Server admins can limit data rate values requested by clients with sv_minrate and sv_maxrate (both in bytes/second). Also the snapshot rate can be restricted with sv_minupdaterate and sv_maxupdaterate (both in snapshots/second).
客戶端可容許的帶寬通常有限。最糟糕的情況下，玩家的調制解調器最大帶寬只有5~7KB/秒。如果服務器要以更高的數據發送頻率給這樣的客戶端發送更新，不可避免的將會發生丟包。因此，客戶端必須控制檯設置variable rate（單位 字節/秒），用來告訴服務器自己的帶寬容量。 【額外說明】關於設置方式，翻的比較隨意，方式不是很重要，比較形式。帶寬承載這個參數，是客戶端網絡參數中最重要的一個，準確設置才能獲得最佳的遊戲體驗。客戶端可以通過修改參數cl_updaterate（默認爲20）來改變請求snapshot的頻率，服務器發送snapshot的頻率永遠不會超過服務器自身的tickerate，也不會超過客戶端設置的請求頻率。服務器管理可以通過設置 sv_minrate 和 sv_maxrate (單位均爲 bytes/秒)來限制客戶端請求數據的帶寬限量。同樣snapshot的發送頻率也受限於sv_minupdaterate 和 sv_maxupdaterate（單位均爲 snapshot/秒）這兩個值。
Paragraph 3
The client creates user commands from sampling input devices with the same tick rate that the server is running with. A user command is basically a snapshot of the current keyboard and mouse state. But instead of sending a new packet to the server for each user command, the client sends command packets at a certain rate of packets per second (usually 30).This means two or more user commands are transmitted within the same packet. Clients can increase the command rate with cl_cmdrate. This will increase responsiveness but requires more outgoing bandwidth, too.
客戶端使用服務器的相同的Tickrate 從輸入設備中對用戶命令取樣。一個用戶命令，基本上是一個當前鍵鼠狀態的快照【額外說明】此處原文爲snapshot，爲與服務器snapshot做出區別，譯爲“快照”，也是snapshot的中文譯名。不同於每一個用戶命令都向服務器發送一次，客戶端會每秒以一個固定的頻率（通常爲30/秒）發送一個命令包。所以意味着一個命令包裏面包含着兩條或者更多的命令。客戶端可以通過cl_cmdrate參數修改命令頻率，這可以提高響應體驗，但是需要更大的上傳帶寬。
Paragraph 4
Game data is compressed using delta compression to reduce network load. That means the server doesn’t send a full world snapshot each time, but rather only changes (a delta snapshot) that happened since the last acknowledged update. With each packet sent between the client and server, acknowledge numbers are attached to keep track of their data flow.Usually full (non-delta) snapshots are only sent when a game starts or a client suffers from heavy packet loss for a couple of seconds.Clients can request a full snapshot manually with the cl_fullupdate command.
遊戲數據使用了增量壓縮（delta compression）來減輕網絡負載。 這意味着，服務器不用每次都發送整個世界的 snapshot， 只需要發送相對於上一次已經確認的update發送後，發生變化的部分即可（一個差值snapshot）。對於每一個客戶端與服務器之間發送的包體，會附加一個確認碼用來追蹤他們的數據流。 通常，完整的snapshot（沒有差量）只會在遊戲開始，以及客戶端遭受數秒嚴重丟包時候，纔會發送。客戶端使用cl_fullupdate命令，可以手動請求一個完整的snapshot。
Paragraph 5
Responsiveness, or the time between user input and its visible feedback in the game world, are determined by lots of factors, including the server/client CPU load, simulation tickrate, data rate and snapshot update settings, but mostly by the network packet traveling time.The time between the client sending a user command, the server responding to it, and the client receiving the server’s response is called the latency or ping (or round trip time). Low latency is a significant advantage when playing a multiplayer online game. Techniques like prediction and lag compensation try to minimize that advantage and allow a fair game for players with slower connections. Tweaking networking setting can help to gain a better experience if the necessary bandwidth and CPU power is available.We recommend keeping the default settings, since improper changes may cause more negative side effects than actual benefits.
響應度，或者說是遊戲中的擁護輸入和可見反饋之間的間隔時間，取決於多種因素，包括雙端的CPU負載，模擬設置中的 Tick頻率，數據帶寬，snapshot更新頻率，但是最爲主要的還是包在網絡中傳輸的時間。從客戶端發送一個用戶命令，到服務器相應，再到客戶端收到服務器的相應。這段時間被稱作延遲，或者ping（或者RTT）。玩線上遊戲時，低延遲是一個很顯著的優勢。像是客戶端輸入預測、服務器滯後補償技術，可以爲網絡連接差的玩家縮小這種優勢、提供一個公平的遊戲。在CPU處理能力和帶寬承載限制下，調整網絡設置，可以幫助玩家獲得更好的體驗。我們推薦保持默認設置，不合理的改變將會帶來比收益更多的負面影響。
寫在後面
第二篇：【翻譯搬運】Source引擎多人模式網絡同步模型（Source Multiplayer Networking）【二】 。
第三篇：【翻譯搬運】Source引擎多人模式網絡同步模型（Source Multiplayer Networking）【三】
歡迎糾錯
轉載請註明，出自喵喵丸的博客 （http://blog.csdn.net/u011643833/article/details/77750350）