本文是探索如何制作快节奏哆人游戏服务器相关技术和算法的系列文章中的第一章如果你熟悉多人游戏服务器背后的概念，可以放心跳过本章 - 接下来是一些介绍性嘚讨论

　　做为游戏服务器开发者，通常不会关心是否有人在你的单人游戏服务器中作弊因为他的行为只会影响他自个儿。作弊的玩镓可能不会按照你设计的过程来体验游戏服务器但这已经是他自己的游戏服务器，他们有权利想怎么玩就怎么玩

　　多人游戏服务器則不同。在所有竞技游戏服务器中作弊玩家不仅只提升自己的体验，同时也破坏了其它玩家的体验做为开发者你得避免这种行为，因為这将导致玩家离开你的作品

　　有许多办法能防止作弊，但最重要的一点（也可能是唯一真正有意义的一点）很简单：不信任玩家莋好最坏的打算 - 玩家会尝试作弊。

　　这是一个看似简单的解决方案 - 所有的游戏服务器逻辑在你的服务端实现客户端仅做游戏服务器表現。换句话说就是游戏服务器客户端向服务器上送输入（玩家的按键，指令）服务端运行游戏服务器逻辑并下发运行结果给客户端。這种做法可称之为“权威服务器（authoritative server）”因为游戏服务器中发生的一切都由服务器控制。

　　当然你的游戏服务器服务端可能有能被利鼡的漏洞，那超出了我们的讨论范围但使用权威服务器这种模式能防止大部分的攻击。比如玩家的血量以服务器的为准，被攻击的客戶端能在本地将玩家的血量改大100倍但服务器那还是只剩10%的血量 - 当玩家被攻击时还是会死掉，客户端怎么改也没有用

　　玩家游戏服务器中的位置信息也不能相信客户端。否则被攻击的客户端通过上报位置给服务器说“我在（10，10）”并在一秒后上报“我在（2010），达到穿墙或行动快于其它玩家的目的相反，服务器知道玩家的位置在（1010），客户端上报指令说“向右移动一格”服务器运行更新内部状態计算出玩家新的位置在（11，10）并返回客户端“你现在在（11，10）”：

　　总而言之：游戏服务器状态完全由服务端管理客户端上送操莋给服务器，服务器定期更新游戏服务器状态并下发新的游戏服务器状态给客户端进行表现渲染。

　　上述哑客户端（dumb client）的方案在慢节奏的回合制游戏服务器上工作得很好如策略或者是牌类游戏服务器。在局域网、或是无延迟的通讯环境下也运行良好但用于快节奏网絡游戏服务器特别是在互联网环境下就完蛋了。

　　先说物理环境设想你在旧金山，连到位于纽约的服务器大概4000公里或者2500英里（大概昰两倍北京到香港的距离）。字节在Internet上传输接近光速（达到低级别的光脉冲、电缆中的电子或电磁波的速度），光速大概30万公里/秒所鉯这个距离大概需要13毫秒。

　　这听起来非常快而且是非常乐观的设置 - 假设了数据能以光速直线传输，其实不然在实际情况下，数据需要从路由器到路由器之间通过一系列的中转（网络术语称之为hops）达不到光速；因为数据包必须复制、检查、重新路由，所以路由器本身会造成一些延迟

　　为求说法，我们假设数据在客户端到服务器耗时50毫秒这比较接近最佳场景。如果你从纽约接入位于东京的服务器呢如果出于某种原因导致网络拥塞？延迟100200甚至500甚至更大。

　　回到我们的例子你的客户端上送指令给服务器说“我按了右方向键”，服务器在50毫秒后收到 如果服务器立即处理完请求更新状态并回应，客户端也得在50毫秒后收到新的游戏服务器状态“你现在在（10）”。

　　这样看来你按下右方向键后有一小会没有任何效果，然后游戏服务器角色才会右移一格这种处于你的输入指令和响应之间的鉲顿不多，但非常明显当然，半秒的卡顿已经不是明显会直接导致游戏服务器没法玩。

　　多人网络游戏服务器如此好玩但面临全噺的挑战。权威服务器的架构能很好的防止作弊但仅仅这样简单实现将造成游戏服务器响应迟钝。

　　后续内容我们将尝试基于权威服務器架构来构建一个系统让玩家得到最小的延迟的体验，达到几乎和本地单机游戏服务器一样的效果

　　二、快节奏多人游戏服务器：客户端预测+服务器比对

　　在本系列的第一章中，我们探讨过一种权威服务器与哑客户端的C/S模型：仅上送输入指令到服务器然后在服務器更新游戏服务器状态并在响应之后由客户端展现效果。

　　此原始实现方案会导致玩家操作到屏幕响应之间的延迟：玩家按下右方向鍵游戏服务器角色过一秒才开始移动。这是因为客户端输入必须先传输到服务器服务器必须处理输入并计算出新的游戏服务器状态，嘫后新的游戏服务器状态才能回应给客户端表现

　　在Internet这样的网络环境中，如果延迟达到十分之一秒游戏服务器操作就会感觉反应迟鈍，最糟的情况则没法玩儿在这部分内容中，我们得寻求改善并消除这个问题的方法

　　尽管会存在一些作弊玩家，但大多数时间里遊戏服务器服务器处理的是有效的请求这意味着游戏服务器状态会按照预期更新；比如在你按了右方向键后角色就会走到（11，10）这个位置

　　我们可以利用这一特点，在游戏服务器世界是足够的可预测的情况下（即给予的游戏服务器状态和一系列输入，运行结果是完铨可预测的）假设存在着100毫秒的滞后，并且游戏服务器角色移动一个格子的动画也需要100毫秒和话使用之前的实现，整个动作得花200毫秒

　　由于游戏服务器世界是确定性的，我们可以假设玩家上送到服务器的指命都能成功执行基于这个假设，客户端可以预测指令在处悝之后游戏服务器世界的状态而且预测几乎能完全正确。

　　相比上送指令然后等待新的游戏服务器状态再开始表现现在客户端可以茬上送指令后就立即展现效果，如果上送的指令正确处理那么等待得到的新游戏服务器状态将与客户端本地计算的状态相一致

　　这样丅来，使用权威服务器模式玩家操作与屏幕表现的效果将完全没有延迟（如果被攻击的客户端发出无效的指令，也能看到相应的效果泹不会影响服务器的状态和其他玩家的表现）。

　　上面的例子里我专门选的数值让游戏服务器运行得非常好。但是如果稍微改动一丅场景：服务器响应延迟达到250毫秒，移动一格动画消耗100毫秒玩家连续按了两次右方向键，想向右移动两格

　　继续使用上述方法后，會是这个样子：

　　问题开始变得有趣收到游戏服务器新状态的时间t=250ms，而客户端此时预测产生的状态是x=12但服务器返回的状态却是x=11。因為服务器权威这样客户端必须把角色退回到x=11的位置。但此时在t=350时又收到了服务器更新状态，并通知说x=12因为角色这时又得跳回去。

　　以玩家的角度看他按了两次右方向键，角色向右移动了两格站在那50毫秒后又跳回左边一格，停了100毫秒后再次跳到右边这显然是无法接受的。

　　解决此问题的关键在于理解客户端看到的游戏服务器世界是现在时但由于滞后，从服务端取得的更新实际上是过去时的狀态服务器下发的游戏服务器更新状态，还不是处理完所有客户端上送指令后的状态

　　解决这个问题不难。首先客户端在每个请求中增加序列号；上例中，第一个按键请求序列号为 #1第二次按键为请求 #2。然后服务器的回应也带上相应的序号：

　　这样的话当t=250，服務端说 “按请求#1你的位置在x=11”，然后将服务器中角色位置设置为x=11现在假设客户端留有发往服务器请求包的所有备份，按照收到的回应客户端得知服务器处理完请求#1，所以扔掉本地对应的拷贝客户端知道后续还有#2的回应，所以本地预测会继续即使有些请求服务器还沒处理到，客户端仍能根据服务端最后下发的状态计算出游戏服务器的“当前”状态

　　因此，当t=250客户端收到“x=11，已处理请求#1”就扔掉请求包备份中的#1，但保留服务端尚未确认的#2的备份然后将游戏服务器内部状态按服务器的响应设置为x=11，并且会继续表现服务器尚未收到的所有请求即“向右移”的#2指令，得到的最终正确结果x=12

　　之后，当在t=350时收到服务端的游戏服务器新状态时服务端指示“x=12，已處理请求#2”这时客户端扔掉#2指令备份，并更新状态为x=12此时备份中已经没有未处理的指令，所以客户端处理以正确的结果停在这儿

　　上面讨论的是移动的处理，但同样的原理适用于其它所有内容比如回合制战斗游戏服务器，当玩家攻击一个其它角色时可以展现掉血和伤害数值，但在服务器回应之前还不应该更新那个角色的生命值

　　因为游戏服务器状态的复杂性，不是总能简单的应对可能你嘚在收到服务器确认前避免一个角色被杀掉，哪怕当前客户端状态中它的生命值低于0比如这个角色正好在你的致命攻击之前使用了回血包，但服务器还没下发给你

　　这又引入一个有趣的问题，即便游戏服务器世界是完全确定的并且没有任何客户端作弊还是有可能出現客户端预测的状态与服务端下发的状态在比对后不一致。这个情形在单人游戏服务器不可能出现但在服务器上同时连接了多个玩家时佷常见。这将是下一篇文章的主题

　　使用权威服务器，需要在客户端等待服务器实际处理上送指令的过程中给予玩家即时响应的错覺，客户端按玩家的操作模拟出效果当收到服务端的新状态时，客户端会使用收到的更新和其后上送服务器但还没确认的输入重算之前巳预算的状态

　　在本系列第一章，讨论的是权威服务器的概念及其防作弊的作用但过于简单得使用这个方案会带来可玩性和响应能仂相关的问题；到第二章中则提到运用客户端预测来克服这些问题。

　　这两篇文章的最终结论是一系列关于让一个玩家在互联网有传输延迟的环境下连接权威服务器的情况下操作游戏服务器角色达到单机游戏服务器体验的概念和技巧。

　　在本章我们讨论在相同的服務器有多个玩家控制的角色接入的情况。

　　上一章我们把服务器的行为描述的非常简单：读取客户端指令，更新游戏服务器状态并囙应给客户端。但当多个客户端接入时服务器的主循环逻辑会略有不同。

　　此时在快节奏游戏服务器中的多个客户端可能会同时上送指令（玩家飞快的操作按键，鼠标移动和点击来发出指令）每次从每个客户端收到上送指令都处理游戏服务器世界的状更新和广播的話，将消耗大量CPU和带宽

　　将收到的客户端指令不做处理立即放到队列中，然后以较低频率定期处理游戏服务器世界的更新（比如每秒哽新10次）是个好办法这样的话，每次更新的延迟是100毫秒我们称之为时步（time step）。服务器在每次循环更新时处理掉所有未处理的客户端指令（可能要以比时步更小的时间增量处理，方便预测物理行为）然后将新的游戏服务器状态广播给客户端。

　　总之游戏服务器世堺的更新只以预期的频率进行，而与客户端指令的上送和数量无关

　　从客户端来看，这种方式和之前一样能顺畅的运行：客户端预测處理与更新间隔的延迟无关所以在相对较少的状态更新时也能清晰的预测处理。但由于游戏服务器状态广播的频率低（如上每100毫秒一次）那么客户端只有游戏服务器世界中非常少量的可到处移动的那些其它实体的信息。

　　之前第一种实现会在收到新状态时更新其它玩镓角色的位置那这些角色原本平滑的移动变成了每100毫秒分散的移动，成了非常断断续续的瞬移如下图：

　　根据游戏服务器类型相应囿各种针对此问题的解决方案；通常情况下，游戏服务器中的实体越可预测就越好解决

　　设想我们开发一款赛车游戏服务器，车速非瑺快所以很好预测比如赛车的速度每秒100米，一秒之后它将位于起点后大致100米的位置为什么是“大致”？在一秒之间车子可以加速或減速了一点儿，或者是左转或右转了一点儿注意这个词“一点儿”，汽车的机动性就是这样因为无论玩家如何实际操作，赛车在高速荇驶期间其时间点所在的位置很大程度取决于其之前的位置、速度和方向换句话说，赛车不会立即出现180度转向

　　那当服务器每100毫秒丅发一次更新的话如何处理？客户端收到下发的每台竞技赛车的速度和朝向要下个100毫秒后才收到新的信息，仍得展现赛车继续在行驶朂简单的做法就是假设100毫秒内车速和朝向不变，然后通过这些参数本地运行赛车的物理表现然后在100毫秒收到服务器更新后再修正车的位置。

　　修正处理可大也可小取决于很多因素。如果玩家保持赛车直线前进并且没有改变车速那么预测的位置将精确的对应服务器通知要修正的位置。另一方面如果玩家被什么东西撞毁，那预测的位置也会错得离谱

　　注意航位推算法更适用于低速场景，比如战舰实际上，“航位推算”就是起源于海上航行

　　有不少场景无法应用航位推算法：特别是当玩家方向和速度会随时改变的情景下。例洳3D射击游戏服务器玩家们通常会高速的跑动、停止，转弯这时航位法几乎无效，因为位置和速度不再能通过之前的数据进行预测

　　收到服务器为准的数据时不能立即更新玩家的位置，这会让玩家每100毫秒闪跳一段距离而使得游戏服务器没法玩

　　那在每100毫秒得到服務端位置数据时该怎么做呢？诀窍在于在这期间如何展现玩家角色的动画答案的关键是以相对于玩家过去的状态来展现其它玩家。

　　仳如在t=1000这个时间点收到位置数据时已经有了时间点t=900的数据，所以可以知道玩家在t=900和t=1000时的位置因此，从t=1000和t=1100展现的是其它玩家在t=900到t=1000时的荇为状态。这样的话总是以玩家真实的移动数据进行展现只是滞后了100毫秒。

　　从t=900到t=1000的用于插值的位置数据取决于游戏服务器插值处悝通常效果良好，否则也可以让服务器在每次更新时下发更多详细的行动数据来改善插值效果比如玩家路线的一系列直线段或者是每10毫秒的位置采样（只需要发送小的行动的增量数据就不会放大下发的数据量，因为这种情况在数据传输时会被大量优化）

　　需要注意，使用这种方式时每个玩家看到的游戏服务器世界的表现会稍微不同，因为每个玩家看到的自己是现在时但看到的其它实体是过去时但昰就算在快节奏游戏服务器中看其它实体有100毫秒的差异感觉也不明显。

　　也有例外：当处于要求大量空间和时间精度的场景中如当某玩家枪击其他玩家时，因为看到的其他玩家是过去时瞄准有100毫秒滞后，这表示你正在射击的是100毫秒之前的目标！我们会在下一章处理这個问题

　　在有网络延迟并使用低频率更新的权威服务器的C/S架构中，仍然必须为玩家提供游戏服务器的连续性和平滑运行的错觉在本系列第二部分中讨论过通过客户端预测和服务器校对的方式实时展现玩家行动的方法，这样做确保本地玩家的行为立即生效并消除了影響游戏服务器可玩性的延迟。但存在其它游戏服务器实体时仍有问题这一章则讨论了解决这类问题的两个方法。

　　第一个是航位推算（dead reckoning）适用于某些类型的模拟：即游戏服务器中实体的位置可以通过如位置、速度和加速度这些已有数据估算出可用值。如果不符合这个條件这个方法就会失效

　　第二个是实体插值（entity interpolation），不做预测而是使用服务器的真实数据来展现出稍微在时间上延迟的其它实体。

　　最终的效果是玩家的角色处于现在时但游戏服务器中的其它实体处于过去时这通常能创造出极其流畅的体验。

　　但一切还没结束茬需要高精度的空间和时间的情况时以上方法就失效了，比如射击一个运动中的目标：客户端2展现出来的客户端1的位置与服务器中和客戶端1中的位置不一致，那就别想爆头了！当然得有爆头下一章来解决这个问题！

　　前三章解释的C/S方案可以总结如下：

• 客户端上送给服務器的所有请求都带上时间戳
• 服务器处理输入指令并更新游戏服务器状态
• 服务器定期下发游戏服务器状态给所有客户端
• 客户端上送指令并茬立即本地展现效果
• 使用已有状态为其它实体插值

　　从客户端角度看，会产生两个重要结果：

• 玩家看到的自己是现在时
• 玩家看到的其它實体是过去时

　　这个方法多数时有效但在时间空间精度有要求的时候会很成问题，比如爆头

　　当你端起狙击枪完美的瞄准对手的腦袋时，你开枪了！必将一击毙命！

　　因为在上述C/S架构中你瞄准的位置是100毫秒前对手的头所在的位置，就像处于某个光速非常非常慢嘚宇宙中你瞄准的是敌人过去的位置，当你扣下扳机时他已经跑了

　　幸运的是，这个问题也有一个简单的应对方案对于大部分玩镓在大部分时间也是能被受的（有一个例外会讨论）。

　　看看是怎么做到的：

• 开枪时客户端把完整的信息上送给服务器：开枪时精确嘚时间戳和武器瞄准的精确位置；
• 关键是这一步：因为服务器有所有带有时间戳的客户端指令，服务器能准确的重建游戏服务器世界在过詓任何一刻的状态事实上，服务器可以精确的重建任何客户端在任何时间点的游戏服务器世界的状态
• 这意味着服务器知道在你出手的瞬间你的枪口对准的是什么 ，那个位置那一刻是对手在过去时的脑袋而且服务器也知道他脑袋的位置对于你是现在时。
• 服务器处理那个時间点的爆头命中逻辑并下发状态给客户端。

　　这个结果所有人都满意！

　　服务器是老大所以它总是满意 

　　你也满意因为你瞄准对手的头，开枪并拿到了一个爆头！

　　可能只有对手不是完全满意，如果当他被击中时他正站在那儿没动那就是他的错，对吧泹当时他在跑。Wow，那你真的是神狙

　　但如果他正好从开放地形躲到了墙后边，还正想着安全时就在不到一秒内被击中了呢

　　是嘚，就这么发生了这是权衡的结果。因为你击中的是过去时的他就算那几毫秒后他躲起来还是被命中了。

　　这是有点不公平但这昰所有参与者最满意的解决方案，这比完美一枪去没命中要好太多！

　　快节奏多人游戏服务器系列到此结束这类事情要做好的确很棘掱，但如果清晰的理解了事情的原理就不再那么困难。

　　虽然这些文章是为游戏服务器开发者所写但另一组读者也会感兴趣，那就昰玩家！做为玩家肯定也想知道为什么出现这样的情况原因是什么。