快速多人游戏(1)

原文地址：Fast-Paced Multiplayer (Part I): Introduction

简介

这是一系列的关于快速多人游戏的技术和算法的文章的第一篇，如果你对于多人游戏背后的技术非常熟悉，那么你可以直接跳到下一篇 - 因为接下来的内容只是介绍性质的。

每一种游戏的开发技术都有各自的难点，多人游戏则给游戏开发添加了一系列要处理的问题，有趣的是，其中最核心的问题是让人看上去自然和物理模拟。

关于作弊的问题

所有的一切的起源都是作弊。

作为一个游戏开发者，你一般不会去担心有人在你的单人游戏中去作弊 - 因为他的行为不会给其他人带来影响，一个作弊的玩家可能并不会按你设计的套路去进行游戏，但是游戏是他的，他们有权利去选择怎么去玩。

多人游戏则不同。在任何的有竞争关系的游戏中，一个作弊玩家不仅仅给自己带来了更好的体验，他也毁了其他的玩家的游戏。作为开发者，你可能希望避免出现这样的情况，因为这会让玩家流失。

为了防止作弊，有很多事可以去做，但是最重要最（可能也是唯一有意义的）的事非常简单：不要相信玩家。就做最坏的打算：所有玩家都想要作弊。

权威服务器和静默客户端

有一个非常简单的解决方案 - 你将游戏中所有的逻辑都放在你控制的服务器来做，而客户端只是游戏的旁观者，换句话说，你游戏的客户端把输入（按键，命令）发送到服务器，服务器来运行这个游戏，然后你把结果返回给客户端。这就是常说的权威服务器，因为游戏世界中发生的一切都在服务器中进行。

当然，你的服务器还是可能被发现漏洞，但是这就不属于我们要谈论的范围了。使用权威服务器可以防止很多的漏洞，比如，服务器不信任玩家的在客户端的血量，客户端想要作弊，把本地的血量调到10000%，但服务器知道血量只有10% - 当玩家被攻击的时候它还是会死掉，不管客户端的血量是多少。

服务器同样不信任玩家的位置。你可能会这样做，在这一秒你告诉服务器“我在（10，10）”，然而下一秒你告诉服务器“我在（20，10）”，这样就可以穿过一堵墙或者超快速的移动。但是，权威服务器知道玩家在（10，10），当客户端告知服务器他要往右动一格的时候，客户端的位置会由服务器来处理，将位置更新为（11，10），然后告知玩家“你在（11，10）”。如下图所示:

一个简单的CS交互

小结：游戏的状态由服务器独自管理。客户端将动作发送给服务器，服务器来周期性地更新游戏状态，然后将新的游戏状态发送给客户端，客户端对结果进行渲染呈现。

处理网络

上面的处理方式对于回合制的游戏非常适合，比如策略游戏或者棋牌类的游戏。它在LAN中也能工作的很好，在这种情况下，通信是瞬发的。但是对于一些对实时性要求很高的游戏，而且在internet环境中，这种解决方案就会出问题了。

下面来谈一些物理的问题。假如你在旧金山，连接了一个在纽约的服务器，两地相距4000km或者2500英里（大概是里斯本到莫斯科的距离）。任何东西都不能比光快吧，即使是Internet上的数据（数据传播的底层可能是光的脉冲，线缆中的电子，或者是电磁波），光传播的速度大概是300000km/s，所以传播4000km需要13ms。

这听起来可能很快，但这实际是最乐观的情况 - 假设数据传播的速度是光速，沿着直线传播，这些通常是不可能的。在真实情况下，数据是由无数个路由经过一系列的跳（在计算机网络里的属于叫做hops）进行传播的，而且大部分的传播速度都达不到光速；路由在传播的时候也会产生一些延迟，因为包必须被打包，检查和分发。

所以保险起见，我们假设数据从客户端到服务器需要50ms，这接近最好的场景了 - 当你在纽约而服务器在东京呢？假设网络因为什么原因发生阻塞了呢？100ms，200ms，500ms的延迟也是有可能的。

回到我们的例子，你的客户端将输入“我按下了向右的按键”发给服务器，服务器在50ms之后获取了数据，现在假设服务器能够立即响应并且将结果返回，那么客户端在50ms之后获得新的游戏状态“你现在在（1，0）”。

从你的视角来看，情况是这样的：你按下了向右的按键，但是什么事都没发生，直到一百年后你的角色向右移动了一格。这样的延迟是显而易见的，当然延迟半秒不仅仅是显而易见，它让整个游戏没法玩了。

总结

通过网络连接的多人游戏是超级有趣的，但是引入了一系列的难题和挑战。权威服务器架构能够防止很多的作弊，但是直接用这种方法会让游戏的响应变得迟缓。

在下面的文章，我们会介绍我们怎么围绕权威服务器来建立一个系统，能够最小的减少玩家的延迟体验，就像在玩单机游戏一样顺畅。