共计 4510 个字符，预计需要花费 12 分钟才能阅读完成。
作为一个程序员，你有没有设想过多人游戏是如何实现的？
在外行人看来游戏很神奇：两个或者更多的玩家在网络上分享独特的经验，就像他们实在的存在于雷同的虚构的世界一样。游戏看起来犹如一个微小的魔术，微妙而又刺激，但作为一个开发人员咱们晓得，实在的状况和咱们所看到的并不一样，那只是一种错觉。你感触到的共享事实，实际上是在那个时刻内，由你本人的独特视角和地位所感知的近似状况。
一、Peer-to-Peer 帧同步
最后的游戏是通过 peer-to-peer 来联网的，每个计算机通过网状拓扑的构造的彼此连贯并替换信息。你依然能够看到这种模型存在于 RTS 游戏中，而且基于某些起因它还很乏味，兴许是因为它是大多数人认为游戏网络工作形式的第一种形式。
解决游戏信息的根本思维就是把游戏的数据抽象并转换成一系列命令音讯，当解决每个转换的时候就间接演变为游戏的状态。比方: 挪动单位、攻打物体、建造修建。这所有都须要在线的每个玩家机器，从一个初始化命令开始之后，都运行完全相同的命令和转换数据。
当然了，这只是一个过于简略的解释，同时也隐去了很多细节，不过咱们通过这个根本的思路能够晓得 RTS 游戏的网络是如何工作的。
这些看起来是如此简略和优雅，但可怜的它们有几个因素限度者咱们。
第一个限度，要保障游戏状态齐全确定统一的是异样艰难，特地是放弃每台机器上每个转换输入都放弃雷同。比方，一个单位在两台机器上有稍微不同的门路，在一台机器上早一些达到并开始了战斗，后果反败为胜，而在另一台机器上，因为略微晚一些达到而失败。就像一只蝴蝶扇动了翅膀，而后在世界的另一边导致了飓风的呈现，随着工夫的推移，一个渺小的区别就会导致两边齐全的不同步。
第二个限度，为了保障游戏的所有玩家输入统一，这就须要等到所有玩家的以后回合数据都达到之后才能够模仿播放这一回合动作。这就意味着游戏中的每一个玩家都须要期待网络提早最高的那个玩家。RTS 游戏通常代表性地通过立刻提供音频反馈与（或是）播放吟唱（过渡）动画来覆盖这段提早，然而最终真正影响游戏的动作要在这段提早过来之后能力进行。
第三个限度，因为游戏中状态扭转的同步是通过发送命令信息来同步的。所以为了游戏中玩家状态都统一，须要所有的玩家都要从雷同的初始状态来开始游戏。这意味着每个玩家必须在开始游戏之前先退出房间而后一起开始游戏，只管实践上也能够反对让某些玩家晚些退出游戏，然而在一场进行中的游戏中取得一个齐全确定的起始点的难度相当大，所以这种状况并不常见。
只管有这些因素限度困扰者咱们，不过这个模型还是很适宜 RTS 游戏的，并且它依然存在于明天的游戏当中，例如“Command and Conquer”、“Age of Empires”与“Starcraft”等。起因就是在 RTS 游戏中，外面蕴含了上千多的单位，这些单位都有本人的状态须要同步，而且他们数据量都太大了，很难用来在玩家之间替换。别无选择，咱们只能通过这些游戏状态扭转的命令来同步。所以以上这些就是 peer-to-peer 帧同步的网路游戏模型的介绍了，对于其余类型的游戏，最先进的技术曾经开始呈现了。让咱们当初从 Doom, Quake 以及 Unreal 经典游戏中开始一起察看动作游戏的技术演变。
二、客户端 / 服务器（c/ s 架构）
在动作游戏的时代，以上帧同步的限度在Doom 游戏中变得更加显著，只管在局域网中体验还不错，但在对于互联网的用户来说它体验太蹩脚了：
只管能够应用一个猫（调制解调器）把两个 Doom 机器通过互联网连贯在一起，但他们一起游戏会异样迟缓。范畴从无奈游戏（例如:14.4Kbps PPP 连贯) 到略微能够玩 (例如：28.8Kbps 猫运行一个被 SLIP 驱动压缩的数据) 之间游戏联机都异样迟缓。因为这些连贯形式只是边际效用，本文将仅关注间接的网络连接。
这个问题是因为 Doom 网络局部原本就是只为局域网而设计的，并且应用了后面介绍的 peer-to-peer 帧同步模型。每一回合每个玩家的输出的信息（比方要害按键等）都与其他人进行同步告诉，并且任何玩家在播放这一帧动画之前，必须得等到所有其余玩家的要害按键信息都被接管到，才能够去模仿播放。
也就是说，在你能够转身（转换），挪动或者射击之前，你必须期待提早最大的猫（调制调解器）玩家的输出。只是想想上述那个人所写的“这些连贯形式只是边际效用”就会让人恨之入骨和丧气了。
为了扭转这种现状，只能在局域网以及大学网络和大型企业能力取得良好连贯而进行游戏，是须要扭转这种网络模型了。在 1996 年，这变成了事实并被实现了，John Carmack 过后 公布雷神之锤，他采纳客户端 / 服务器（C/S）架构代替了 P2P 模型。
现在游戏中的玩家能够不用再运行雷同的代码以及间接互相通信，每个玩家的机器是都是一个“客户端”，他们都通过一台叫做“服务器”的机器进行通信交互。游戏的最终状态确定不再依赖于每台客户端机器来独特确认，而是由服务器来确定最终后果。每个客户端如同一个哑终端，用来展现一个近似值的表演，真是的游戏状态是运行于服务器之上。
在一个纯正的 c / s 架构中，你不用在本地运行游戏代码，而是把一些例如按键、鼠标挪动，点击等输出信息发送到服务器。服务器会在游戏世界中更新你的玩家状态，而后再封包一个蕴含你角色信息以及邻近玩家数据的包回复给你的客户端。所有的客户端在每个音讯更新的间隙做一个插值预测，以改善在每个状态更新期间，物体能够平滑的挪动，如此，你就有一个能够联网的客户端 / 服务器架构的游戏了。
这曾经是向前迈出了极大的一步。游戏的体验依赖于客户端和服务器的连贯，而不是游戏中提早最大的那个玩家。如此能够反对玩家在游戏中自在的进入和退出，同时因为客户端 / 服务器升高了均匀每位玩家的带宽，从而能够减少更多的在线玩家。
然而这里依然有一些问题存在于 c/s 架构中:
我记得我交代了所有从 DOO 到 Quake 中对于网络的决策，然而重要的是我正在应用谬误的假如来做一个好的网络游戏。我原先设计的指标是网络提早 <200ms。人们通过一个好的网络供应商连贯互联网，从而能够取得一个好的游戏体验。但大失所望，世界上 99% 的用户应用猫 (调制调解器) 通过 slip 或者 ppp 进行连贯，而他们经常都会通过槽糕而又拥挤的 ISP。这会带来最低 300+ms 的 网络提早。一个音讯要通过，客户端 > 用户猫 >ISP 猫 > 服务器 >ISP 猫 > 用户猫 > 客户端。上帝，这太逊了。
OK, 我做了一个谬误的设定。我在家里应用 T1 宽带，所以我只是不理解在 PPP 网络下的生存。我当初就解决它。
这个问题当然是提早。
接下来 John 在他公布 QuakeWorld 的时候将扭转这个行业。
三、客户端预测（Client-Side Prediction）
在原来的 Quake 游戏中，你会感觉到电脑与服务器之间的提早。比方，你按键向前挪动，在你真正挪动之前，你须要等到数据包发送服务器而后再回复到你的客户端，你才能够真正的挪动。按键停火，在你的射击之前同样须要雷同的期待。
如果你玩过任何 FPS 游戏，比方:Modern Warfar, 你会发现并没有提早产生。那么 fps 游戏是如何做到在多人状况下，你的动作看起来并没有提早？
这个问题被分为两个局部来解决。第一个局部是客户端挪动预测，这事 John Carmack 为 QuakeWorld 游戏多开发的，起初被合并到了 Tim Sweeney 的空幻网络模块。第二个局部就是提早弥补，它是有 Valve 公司的 Yahn Bernier 在 Counterstrike 所开发。那么在这个章节，咱们把焦点放在第一局部——暗藏用户挪动的提早。
当写到对于他行将公布的 QuakeWorld 打算的时候，John Carmack 讲到:
我当初容许客户端能够预测用户的挪动，直到服务器的权威信息回复之前。这是一个重大的构造变更。客户端须要晓得对于对象的硬度、摩擦力、重力等一系列根底属性。我很伤心的看到，客户端仅作为一个终端存在将会来到，但作为一个实用主义者，我必须超过这种现实情怀。
那么当初咱们为了打消提早，客户端须要运行更多的代码。它当初不再是一个只把输出发送给服务器而后再把返回信息进行插入的哑终端。当初客户端的机器能够运行一部分游戏代码，它能够在本地预测你的角色挪动并且能够即时响应你的输出。
当初当你即刻按键向前，你的游戏会立即向前挪动，不会再去期待数据往返一次客户端和服务器之间才来回应你的操作。
这种形式的难点不在于预测，这种预测工作，就像失常的游戏代码一样 —— 依据玩家的输出，及时地更新游戏角色的状态。而难点在于，当客户端和服务器对于玩家角色所做的事件（动作）核检不统一的时候，客户端如何基于服务器信息进行更正。
当初你会想，hey，如果代码运行在客户端——为何不以客户端的信息为准？客户端能够本人的为角色模仿运行代码，并且只须要在每次发送数据包时告知服务器这些信息。如果每个客户端都对服务器发送雷同的信息，通知服务器“这是我当初的地位信息”，那么将会带来这样的问题。客户端会很容易被黑客攻击并管制，这样在 RPG 游戏中，一个舞弊便能够立刻规避对方技能击中，或者当你射击的时候霎时挪动到你的身后。
所以在 FPS 游戏中，尽快每个玩家的客户端能够预测他们本人的角色进行操作挪动，但最终每个玩家的角色状态相对以服务器为准。
这就是乏味的中央。如果客户端和服务器产生了不统一，客户端必须基于服务器的信息为准并更新，然而因为客户端和服务器之前有提早，服务器的修改必然是过来的动作。比方，如果信息从客户端到服务器耗时 100ms，而后返回又耗时 100ms，那么任何服务器的的修改都是客户端 200ms 之前的行为动作，这个工夫正好是客户端预测角色挪动的工夫。
如果客户端每个动作都会被服务器修改，那么你将会看客户端被拉回了原先的地位，如此客户端将做不了任何事后预测的运算。那么咱们如何解决这个问题，仍然能够放弃客户端提前预测？
解决方案就是在客户端创立一个 buffer，而后用来循环放弃角色的状态以及原本玩家的输出。当客户端收到了服务器的更正信息时候，它首先抛弃掉 buffer 外面比（服务器回复的）更正状态要老的状态信息，而后基于（更正的）正确的状态重放存储在 buffer 外面的输出信息，重发的这些输出信息的范畴是从正确状态到以后预测工夫之间。如此实际上，客户端只是看似无形中“倒带和重放”当地玩家角色静止的最初 n 帧，同时放弃世界其余中央没有变动。
这种办法能够让玩家感觉在管制游戏的时候没有提早，同时也改善了客户端和服务器之间代码运行的一致性——在等同输出的状况下保持一致的后果。当然了，修改的状况很少产生，Tim Sweeney 如此形容:
…对于客户端和服务器最好的是：所有状况下，服务器都是权威的。简直所有的工夫，客户端模仿的和服务器的数据都是统一，所以客户端的地位很少被修改。只有的多数常见的状况下，例如一个玩家被火箭击中，或者和一个敌人（怪物）碰撞上，那么客户端本地的状况有可能须要被修改。
也就是说，只有当玩家的角色被一些内部事件影响玩家的输出，并且这些不能被客户端预测时，玩家的地位（行为）须要被服务器修改。当然，如果玩家试图舞弊，必然会被服务器修改。
