每一个程序员都须要知道一些游戏网络知识

做为一个程序员，你有没有想象过多人游戏是如何实现的？

在外行人看来游戏很神奇：两个或者更多的玩家在网络上分享共同的经历，就像他们真实的存在于相同的虚拟的世界同样。游戏看起来犹如一个巨大的魔术，奇妙而又刺激，但做为一个开发人员咱们知道，真实的状况和咱们所看到的并不同，那只是一种错觉。你感觉到的共享现实，其实是在那个时刻内，由你本身的独特视角和位置所感知的近似状况。

1、Peer-to-Peer 帧同步

最初的游戏是经过peer-to-peer来联网的，每一个计算机经过网状拓扑的结构的彼此链接并交换信息。你仍然能够看到这种模型存在于RTS游戏中，并且基于某些缘由它还颇有趣，也许是由于它是大多数人认为游戏网络工做方式的第一种方式。

处理游戏信息的基本思想就是把游戏的数据抽象并转换成一系列命令消息，当处理每一个转换的时候就直接演变为游戏的状态。好比:移动单位、攻击物体、建造建筑。这一切都须要在线的每一个玩家机器，从一个初始化命令开始以后，都运行彻底相同的命令和转换数据。

固然了，这只是一个过于简单的解释，同时也隐去了不少细节，不过咱们经过这个基本的思路能够知道RTS游戏的网络是如何工做的。若是你想知道更多网络模型，请点击:1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond.

这些看起来是如此简单和优雅，但不幸的它们有几个因素限制者咱们。

第一个限制，要保证游戏状态彻底肯定一致的是异常困难，特别是保持每台机器上每一个转换输出都保持相同。好比，一个单位在两台机器上有略微不一样的路径，在一台机器上早一些到达并开始了战斗，结果反败为胜，而在另外一台机器上，因为稍微晚一些到达而失败。就像一只蝴蝶扇动了翅膀，而后在世界的另外一边致使了飓风的出现，随着时间的推移，一个微小的区别就会致使两边彻底的不一样步。

第二个限制，为了保证游戏的全部玩家输出一致，这就须要等到全部玩家的当前回合数据都到达以后才能够模拟播放这一回合动做。这就意味着游戏中的每个玩家都须要等待网络延迟最高的那个玩家。RTS游戏一般表明性地经过当即提供音频反馈与（或是）播放吟唱（过渡）动画来掩盖这段延迟，可是最终真正影响游戏的动做要在这段延迟过去以后才能进行。

第三个限制，由于游戏中状态改变的同步是经过发送命令信息来同步的。因此为了游戏中玩家状态都一致，须要全部的玩家都要从相同的初始状态来开始游戏。这意味着每一个玩家必须在开始游戏以前先加入房间而后一块儿开始游戏，尽管理论上也能够支持让某些玩家晚些加入游戏，可是在一场进行中的游戏中得到一个彻底肯定的起始点的难度至关大，因此这种状况并不常见。

尽管有这些因素限制困扰者咱们，不过这个模型仍是很适合RTS游戏的，而且它仍然存在于今天的游戏当中，例如“Command and Conquer”、“Age of Empires”与“Starcraft”等。缘由就是在RTS游戏中，里面包含了上千多的单位，这些单位都有本身的状态须要同步，并且他们数据量都太大了，很难用来在玩家之间交换。别无选择，咱们只能经过这些游戏状态改变的命令来同步。

因此以上这些就是 peer-to-peer 帧同步的网路游戏模型的介绍了，对于其余类型的游戏，最早进的技术已经开始出现了。让咱们如今从Doom, Quake 以及 Unreal经典游戏中开始一块儿观察动做游戏的技术演化。

2、客户端/服务器（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中关于网络的决策，可是重要的是我正在使用错误的假设来作一个好的网络游戏。我原先设计的目标是网络延迟<200ｍs。人们经过一个好的网络供应商链接互联网，从而能够得到一个好的游戏体验。但事与愿违，世界上99%的用户使用猫(调制调解器)经过 slip或者ppp 进行链接，而他们经常都会经过槽糕而又拥挤的ISP。这会带来最低300+ms 的 网络延迟。一个消息要通过，客户端>用户猫>ISP猫>服务器>ISP猫>用户猫>客户端。上帝，这太逊了。

OK,我作了一个错误的设定。我在家里使用T1 宽带，因此我只是不了解在PPP网络下的生活。我如今就解决它。

这个问题固然是延迟。

接下来John在他发布QuakeWorld的时候将改变这个行业。

3、客户端预测（Client-Side Prediction）

在原来的Quake游戏中，你会感受到电脑与服务器之间的延迟。好比，你按键向前移动，在你真正移动以前，你须要等到数据包发送服务器而后再回复到你的客户端，你才能够真正的移动。按键开火，在你的射击以前一样须要相同的等待。

若是你玩过任何FPS游戏，好比:Modern Warfar,你会发现并无延迟发生。那么fps游戏是如何作到在多人状况下，你的动做看起来并无延迟？

这个问题被分为两个部分来解决。第一个部分是客户端移动预测，这事John Carmack 为 QuakeWorld游戏多开发的，后来被合并到了Tim Sweeney的虚幻网络模块。第二个部分就是延迟补偿，它是有Valve公司的Yahn Bernier在Counterstrike所开发。那么在这个章节，咱们把焦点放在第一部分——隐藏用户移动的延迟。

当写到关于他即将发布的QuakeWorld计划的时候，John Carmack 讲到:

我如今容许客户端能够预测用户的移动，直到服务器的权威信息回复以前。这是一个重大的结构变动。客户端须要知道关于对象的硬度、摩擦力、重力等一系列基础属性。我很伤心的看到，客户端仅做为一个终端存在将会离开，但做为一个实用主义者，我必须超越这种理想情怀。

那么如今咱们为了消除延迟，客户端须要运行更多的代码。它如今再也不是一个只把输入发送给服务器而后再把返回信息进行插入的哑终端。如今客户端的机器能够运行一部分游戏代码，它能够在本地预测你的角色移动而且能够即时响应你的输入。

如今当你即刻按键向前，你的游戏会马上向前移动，不会再去等待数据往返一次客户端和服务器之间才来回应你的操做。

这种方式的难点不在于预测，这种预测工做，就像正常的游戏代码同样 —— 根据玩家的输入，及时地更新游戏角色的状态。而难点在于，当客户端和服务器对于玩家角色所作的事情（动做）核检不一致的时候，客户端如何基于服务器信息进行更正。

如今你会想，hey，若是代码运行在客户端——为什么不以客户端的信息为准？客户端能够本身的为角色模拟运行代码，而且只须要在每次发送数据包时告知服务器这些信息。若是每一个客户端都对服务器发送相同的信息，告诉服务器“这是我如今的位置信息”，那么将会带来这样的问题。客户端会很容易被黑客攻击并控制，这样在RPG游戏中，一个做弊即可以当即躲避对方技能击中，或者当你射击的时候瞬间移动到你的身后。

因此在FPS游戏中，尽快每一个玩家的客户端能够预测他们本身的角色进行操做移动，但最终每一个玩家的角色状态绝对以服务器为准。就像Tim Sweeney 在所写的文章The Unreal Networking Architecture中描述的同样：“服务器才是主人”。

这就是有趣的地方。若是客户端和服务器产生了不一致，客户端必须基于服务器的信息为准并更新，可是因为客户端和服务器以前有延迟，服务器的修正必然是过去的动做。好比，若是信息从客户端到服务器耗时100ms，而后返回又耗时100ms，那么任何服务器的的修正都是客户端200ms以前的行为动做，这个时间正好是客户端预测角色移动的时间。

若是客户端每一个动做都会被服务器修正，那么你将会看客户端被拉回了原先的位置，如此客户端将作不了任何预先预测的运算。那么咱们如何解决这个问题，依然能够保持客户端提早预测？

解决方案就是在客户端建立一个buffer，而后用来循环保持角色的状态以及原本玩家的输入。当客户端收到了服务器的更正信息时候，它首先丢弃掉buffer里面比（服务器回复的）更正状态要老的状态信息，而后基于（更正的）正确的状态重放存储在buffer里面的输入信息，重发的这些输入信息的范围是从正确状态到当前预测时间之间。如此实际上，客户端只是看似无形中“倒带和重放”当地玩家角色运动的最后n帧，同时保持世界其余地方没有变化。

这种方法可让玩家感受在控制游戏的时候没有延迟，同时也改善了客户端和服务器之间代码运行的一致性——在同等输入的状况下保持一致的结果。固然了，修正的状况不多发生，Tim Sweeney 如此描述:

…对于客户端和服务器最好的是：全部状况下，服务器都是权威的。几乎全部的时间，客户端模拟的和服务器的数据都是一致，因此客户端的位置不多被修正。只有的少数罕见的状况下，例如一个玩家被火箭击中，或者和一个敌人（怪物）碰撞上，那么客户端本地的状况有可能须要被修正。

也就是说，只有当玩家的角色被一些外部事件影响玩家的输入，而且这些不能被客户端预测时，玩家的位置（行为）须要被服务器修正。固然，若是玩家试图做弊，必然会被服务器修正。

这是一篇翻译文章，主要针对游戏的网络设计，目前主流的网络游戏实现方案都有讲解，若是对英文更感兴趣，请查看文章尾部连接，你如果以为有翻译不妥的地方，欢迎留言指正。原文地址: 点此看原文

-------------------------------------------------------------------------------------------------------

更新游戏开发专题请关注个人公众号

大码候，关注我的成长和游戏研发，致力于推动国内游戏技术社区的进步。