【翻译搬运】起源引擎网络同步模型（Source Multiplayer Networking）【一】

写在前面

文章的原文很多地方都能找到

我贴一处起源引擎（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）

最后

以上就是和谐航空为你收集整理的【翻译搬运】起源引擎网络同步模型（Source Multiplayer Networking）【一】的全部内容，希望文章能够帮你解决【翻译搬运】起源引擎网络同步模型（Source Multiplayer Networking）【一】所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。