当我们启动“X翼战机VS钛战机”这个项目的时候，我们的目标是去创造第一个多人在线的星球大战游戏。为了实现这个目标，除了通过因特网进行联网对战以外，还有很多问题需要我们解决。我将回顾我们遇到的所有问题，以及我们是如何解决的，包括最后的结果如何。我希望我的经验能够给看这篇文章的读者带来帮助。 面临的问题“X翼战机VS钛战机”是星球大战系列的第三部作品。我们最初在开发星球X翼系列游戏引擎的时候，肯定是没有考虑因特网的。所以，这是我们第一个需要面对的难题。向一个最初没有考虑因特网的游戏引擎里添加因特网的功能是极其困难的。 我们的第二个难题是游戏设计的复杂性。我们一直认为我们游戏引擎的强大之处在于它能够模拟并创造出一种公平的对战环境。我们非常自豪的说，在我们设计的任务中，存在大量的不同的飞船，它们有各种不同的能力和行为，但是总体来说是公平的，没有那一艘飞船会影响游戏的平衡。我们开发“X翼战机VS钛战机”的目的之一就是实现一个能够既公平又富有可玩性的多人在线游戏。我们想要带给游戏玩家的多人游戏体验，比以前的”死亡匹配赛“更加激烈。为了达到这个目的，玩家所需要的数据量将会极大的增加。
我们清单上的第三个难题是我们没有专用的服务器来运行我们的游戏；我们将不得不使用P2P技术来弥补这一点。为我们预期的玩家数量，提供所需的处理能力和带宽的服务器是一笔难以想象的高额花销。由于我们游戏发行的证书的性质，不允许玩家自己架设服务器来运行游戏。但一个P2P的系统避免了这个问题，可它同时也抛出另一个技术上的难题，因为每名玩家都需要跟别的玩家进行沟通，而这些玩家不一定在同一个服务器上。因为因特网没有多播的能力，发送同样的一条消息到三个不同的目的地，相比发送到一个目的地需要3倍的带宽。 第四个难题当然就是因特网本身了。当我们启动这个项目的时候，我们假设了我们能够处理200毫秒到1秒的延迟。我们还知道我们的带宽是有限制，只有28K的调制解调器可以用。这两个限制是我们设计网络模型一开始最关注的问题，但是最后我们发现，这仅仅是我们需要解决的最简单的问题罢了。 解决办法面对着一堆的难题，我们设计了一个我们自认为可以涵盖所有问题，并找到满意的解决方案的网络模型。第一个我们需要解决的也是最重要的一个问题，同时它也是我们后来头疼的罪魁祸首。那就是我们认为，不该让网络模型限制我们游戏关卡设计的复杂性，但是我们也知道没有办法把每一个玩家的数据压缩，然后通过这么窄的带宽进行同步。所以我们想出了三个可能的解决方案。第一个选择，也是我们所知的被其他的游戏成功运用的方法，我们只传输最重要的数据，然后通过预测的方式填充其他不重要的数据。第二个选择是只传输所需绘制的游戏世界的数据。第三个选择是只传输玩家的操作，然后在每个客户端模拟出这些操作的结果。 第一个选择需要我们有能力快速决定哪些数据是重要的，哪些不是。在我们之前的游戏中，玩家被赋予了大量的能力来探寻游戏世界中的一切。我们甚至给玩家一个能够实时显示游戏世界中所有飞船动向的地图。除此之外，玩家还能够通过使用一个叫”追踪电脑“的东西来查询任何一艘飞船的当前状态。如果说我们要解决前面提到的问题的话，我们必须去修改或者删掉这个功能。 第二个选择听起来像是一个可行方案。从玩家飞船的座舱看出去，只能看到很少的一部分物体，而且如果玩家想看到更多的物体，那么玩家必须是离的很远，那样的话就不用太精确的画出这些物体了。问题是玩家是在一个开放的空间中，并驾驶一艘机动性非常好的飞船。他们能够非常快的做一个360度回旋，在那个时候他们就能够看到游戏世界中的几乎所有的物体。我们知道这种只传输所需绘制的游戏世界的数据的方法，在那些室内游戏中能够成功，但是我们的游戏是不会用墙之类的东西把游戏世界分隔开的。我们还考虑过使用一种雾来分隔玩家的视线，这样玩家就只能看到一定距离之内的物体了，但是面对现实吧，这不是一个好主意。
第三个选择立刻吸引了我们。带宽限制了我们只能发送玩家的操作，而不用考虑游戏关卡设计的复杂性。我们以前用过一种类似的技术来让玩家记录下战斗的过程，然后能够在“VCR”里重放战斗过程。所以我们知道我们的游戏引擎是有这种功能和概念的。我们决定对这个办法做一个快速测试，几天后我们就完成了我们的第一个多人任务的关卡。 |
