大型多玩家在线游戏，第 1 部分: 一种基于性能的基础结构规模评估方法

在电影业中，电影分成多种类型，比如动作和冒险片、艺术片、传奇片、恐怖片和喜剧片。游戏也分成许多类型，包括第一人称射击游戏、解谜游戏、休闲游戏、聚会游戏、角色扮演游戏、比赛游戏和模拟游戏。但是与电影不同，游戏行业还在分类法中增加了一个新的维，即区分玩游戏的方式以及游戏是否可以由多个玩家同时参与。

单一玩家游戏

大家最熟悉的电子游戏类型是单一玩家游戏。这种游戏是在玩家和计算机之间进行的。从企业的角度来看，创建这种类型的游戏与创建任何其他消费产品相似，在交付产品之后，企业不需要承担任何产品开发或运营费用。只需要对销售、市场营销和发行进行管理的基础结构。

多用户地下城、多用户维、多用户域

多用户地下城、维或域（Multiuser dungeon, dimension, or domain，MUD）游戏通常是基于文本的多用户角色扮演游戏。这种游戏允许多个玩家登录一个中心服务器，并参与一般基于文本的冒险活动。这些游戏的历史可以追溯到串行控制台、大型机和小型机时代。MUD 的出现不但早于 PC 游戏，甚至早于 PC 机本身的出现。据关于 MUD 的一篇 Wikipedia 文章所说，第一个 MUD 游戏出现于 1977 年（参见 参考资料）。从基础结构的角度来说，与其他在线游戏类型（比如多玩家在线游戏和 MMOG）相比，MUD 的需求非常简单。

多玩家在线游戏

多玩家在线游戏涵盖许多游戏，它们支持来自任何地方的数十位玩家。在这些比较休闲的游戏中，玩家最多为 32 人。多玩家在线游戏的范围很广，从基于文本的第一人称射击游戏（比如 Half Life 和 Unreal Tournament），到传统社交游戏的在线版本（比如扑克牌、国际象棋和西洋跳棋）。与大型多玩家在线游戏相比，这些游戏需要的基础结构不太复杂。

大型多玩家在线游戏

MMOG 包括一些著名的游戏，比如 EverQuest、World of Warcraft、EVE Online、Guild Wars 和 Lineage II。这些游戏在全球部署，支持数百万玩家。这种游戏需要最复杂的基础结构，这些结构被复制并部署在世界各地的数据中心中。开发社区常常将 MMOG 称为永恒的世界（persistent world）。从基础结构的角度来说，它们是相同的。

永恒的世界

永恒的世界是一种无论是否有玩家登录，都一直保持运行的模拟环境。永恒的世界与 MMOG 之间的主要差异是受众。永恒的世界主要面对比较小的受众群，具有非传统的客户集或业务模型。来自 Linden Lab 的 Second Life 是永恒世界的典范，这个游戏不被认为是 MMOG。对于在娱乐业之外使用的模拟和游戏技术，永恒的世界常常是合适的分类，比如天气预报、战场模拟、全球气候模型和海洋学模拟。

大型社会性游戏

玩 MMOG 的最大好处之一是，可以在各种协作和竞争场景中与大量的真人进行交互。这个特性将来自各个地方、具有不同社会背景的人们吸引到在线游戏中。因为真人在游戏中由一个化身来表示，所有玩家在社会身份、地理位置和经济地位方面都是平等的（至少在刚开始时是平等的），所以游戏在玩家之间提供了一种民主的效果。在现实世界中，人们往往由于地理距离或其他许多因素而无法进行交互，游戏中的民主效果克服了这些障碍。MMOG 出现了一个新的子类别，大型社会性游戏（massively social game），这种游戏利用游戏的功能建立全球性的社区。玩家实际上组成社交网络，他们可以使用游戏设施进行交流，比如通过移动的动画形象在桌面之间传递消息，或者在虚拟的 3D 世界中聊天。这些游戏玩家可以决定自己的化身的外观，决定他们的行为，控制对他们的世界的访问，这些在现实世界中是做不到的。

平台

游戏平台就是最终用户用来访问游戏的设备，在技术上也称为客户端（client side）。主要的游戏平台包括游戏机、PC、手持设备和移动设备。另一种常常被忽视的平台是街机（arcade）。在美国，街机在 20 世纪 70 年代晚期和 80 年代早期达到一个高峰，之后就衰退了。但是在日本和亚洲的其他许多地方，街机仍然很流行。近来，手持设备和移动设备正在成为重要的游戏平台。这些平台在亚洲和欧洲非常流行，最终引起了大公司的注意，因此最近出现了许多针对这些设备的游戏。但是，本文主要关注两种最流行的游戏平台：游戏机和 PC。

游戏机

目前许多人都非常熟悉这种电视机附件，尤其是在过去 25 年度过童年的人。在 20 世纪 80 年代早期，有 Atari 和 Intellivision。80 年代的后几年出现了 Nintendo 和 Sega。现在，有 Sony® PLAYSTATION®、Microsoft® Xbox 和 Nintendo。

游戏机游戏系统在美国、日本和欧洲的部分地区占据很大的游戏市场份额。随着市场的发展，当前和下一代的所有游戏机都能够通过宽带连接在一起。因此，游戏机市场仍然具有经济潜力。

自从 Nintendo Entertainment System 在 20 年前进入游戏市场以来，许多人就不断地预言 PC 游戏将走向消亡。但是，这些人忽视了编写软件的经济动力。只要 PC 还是日常用品，就存在为它们编写游戏的经济动力。

“Gaming” 您可能听说过 Nevada Gaming Commission（内华达州委员会），或许会质疑它与韩国游戏 Lineage II 的关系。简单地说，它们没关系。“Gaming” 只是业采用的委婉说法之一，它指的其实就是。

PC

每年都有文章预言 PC 游戏即将走向消亡。按照本人的看法，PC 游戏不会很快消失，理由非常多。例如，PC 游戏对开发人员的要求最低。PC 还是全亚洲最流行的游戏平台。另外，PC 上的连网游戏曾经非常流行。PC 的开放性质让各个公司都能够研发创新的新硬件和软件。因为 PC 具有玩游戏之外的其他功用，所以 PC 的装机量总是非常大的，这就产生了很大的市场。为 PC 开发的技术似乎总能够在 PC 游戏中找到用武之地，比如鼠标、彩色图像、3D 加速、多声道音频、连网支持、基于 Web 的技术、音频输入、实时文本和语音聊天以及多线程。喜欢冒险的 PC 游戏开发人员采用所有这些技术来改进游戏体验。没有迹象表明这种动力会很快消失，所以在可以预见的时期内 PC 还会是所有游戏类型的流行平台。

从基础结构的角度来说，过去可以构建一个通用的在线游戏服务器基础结构，支持任何能够连网的客户机平台。由于最近出现的游戏机平台，情况似乎有所变化。这个新的趋势给游戏开发人员造成了新的复杂性，这超出了本文的范围。

回页首

对全球性在线游戏进行划分

为了控制在线运营的复杂性，游戏行业使用一些合同条款和一种标准方法将全球划分为便于管理的区域。

全球

为了解决日益增长的全球需求，多玩家在线游戏公司往往在他们认为有足够大市场的地理位置建立站点，从而保证能够收回投资。每个全球性玩家社区都由几个按照战略布局的数据中心提供服务。每个数据中心可能为一个地区或国家服务。

站点

多玩家在线游戏常常有许多游戏站点，甚至有许可机制，个人或公司（比如宽带运营商）在签定许可协议之后就可以运营游戏的实例。每个站点支持一个地理区域中的玩家社区。当然，各个游戏的玩家社区的规模和地理划分有很大差异。

管理游戏世界规模的模式

对于多玩家在线游戏和 MMOG，使用两种不同的 “模式” 来提供多玩家体验。这两种模式都对整个玩家社区进行划分。一般情况下，玩家社区划分进一个游戏世界的多个拷贝，即战场、赛道等的实例。在人类历史上，还没有别的娱乐形式能够让数千甚至数百万人同时参与一项活动。当前，在 1000 万人参与时，游戏体验就不太好了。

对于 MMOG，要根据技术和市场两个因素决定游戏世界的规模。也就是说，游戏设计者要根据娱乐性和经济因素决定一个游戏世界容纳的玩家数量。游戏开发人员很难让这个数量最大化，从而降低基础结构的复杂性。

对于多玩家在线游戏，一个游戏实例中的并发玩家数量主要取决于引擎中使用的技术。为运动、第一人称射击和比赛游戏设计的大多数多玩家在线游戏引擎足以处理 16、32 或 64 个并发玩家。

全新的（单实例）世界

一些著名的公司（比如 EVE Online 的开发商 CCP）创建了单实例 MMOG 游戏，并证明了他们的尝试是有积极效果的。这些公司率先尝试用单实例 MMOG 来解决可玩性和技术问题。在这些问题之中，必须解决单实例 MMOG 的内容创建问题。允许玩家创建内容可能是一个解决方案。玩家创建的内容不是在线游戏中的新概念，但是玩家扩展游戏世界的能力会消除实现单一世界在线游戏的最大障碍。但是，允许玩家在游戏中添加内容会导致许多问题，包括游戏管理问题。尽管如此，游戏行业内外的实践都反复地证明，积极参与游戏的社区可以大大加强游戏的吸引力，并延长游戏的生存期。

单实例世界的其他可玩性问题是可以解决的。（寻宝的）资源缺乏问题可以通过创造性的游戏方法来解决，比如寻宝系统可以根据寻找资源的玩家数量来管理寻宝资源。交易区域过分拥挤的问题是单实例世界固有的另一个概念性问题。这可以通过创造性的交易方式来避免。“虚拟” 卖家和由非玩家角色（NPC）进行寄售是两个例子。

困扰单世界游戏的技术问题也是可以解决的。一些技术使软件系统能够动态地扩展和收缩，比如优化的网格应用程序（参见 参考资料）。这些技术使支持单游戏实例所需的技术基础结构可以扩展，而不会破坏现有的游戏。最后一个技术障碍是延迟，也就是玩家的物理位置对游戏效果的影响。幸运的是，依赖全球实时系统的其他行业对这个问题已经有解决方案了。在地理上分布的金融交易系统就是这样的系统，能够实时地对全球的用户交互做出响应。

单实例在线游戏对于开发人员的好处是，大大降低了开发、部署和运营的成本。对于玩家的好处是大大增加了可玩性。

回页首

评估游戏的规模

因为 MMOG 是在全球范围部署数十或数百个拷贝的应用程序，支持数百万用户，所以评估所需的技术规模是一项艰巨的任务。与任何复杂的系统一样，首先需要将系统分割成比较小的容易处理的问题。但是，即使在比较容易理解的层次上，MMOG 涉及的各种问题也让人觉得不知道从哪里下手。

有一条公理：“最好从用户界面开始”。在游戏中，用户界面由许多东西组成，比如复杂的 3D 图形、2D 菜单、六声道的动态触发的音乐、可调音量的声音效果、3D 定位和移动以及 2D 导航。尽管界面如此丰富，但是在客户机上只有两个技术指标对游戏的服务器基础结构有影响：网络吞吐量和延迟需求。因此，在了解构建 MMOG 所需的物理基础结构的规模时，首先要了解这些问题。

吞吐量就是系统在任何给定的时间间隔内可以处理的事务数量，比如每秒一百万个事务。延迟或性能是系统完成任何给定的事务所花费的时间（例如，40 毫秒）。

一定要注意，吞吐量和性能是两个不同的概念。每秒执行一百万个事务并不意味着每个事务都可以在一百万分之一秒内执行完。每分钟执行一百万个事务可能意味着可以同时处理一百万个耗时一分钟的事务。事务仍然需要一分钟才能完成。每秒事务数（TPS）不是衡量应用程序的 “实时性” 的合适指标，对于在线游戏也是如此。

因此，衡量任何游戏玩起来是否流畅的主要指标是响应时间。您可能会问，“合理的响应时间是多少？” 对于国际象棋这样的游戏，时间可以比较长，因为玩家考虑的时间很长。通过游戏机访问的多玩家在线游戏具有严格且快速的性能规则，这是因为显示设备具有固定的刷新速率。具体地说，整个游戏必须在下一次刷新显示之前更新。对于电视机，每秒有 24 次扫描。对于 PC（多玩家在线游戏当前的主要平台），要求更高。目前，大多数 PC 游戏玩家将显示器设置为每秒 60 帧以上。

对于游戏，必须对用户输入进行取样，从而计算它对环境的影响；取样之后必须将更新发送到服务器，从而根据游戏中的其他所有变化调整这些更新。最后，服务器将结果发送回客户机；客户机接收结果之后，就可以用图形显示更新 —— 所有这些步骤要在 60 分之一秒内完成。幸运的是，在现代的普通处理器上，这些操作只需几微秒就能计算出用户操作的影响。

回页首

两个世界（类型）的情况

既然我们已经了解了当前两种主要在线游戏类型（通常称为多玩家在线游戏和大型多玩家在线游戏）之间的差异，就一定要了解它们对玩家体验和游戏类型的影响，以及它们对所需的基础结构的重要影响。对于喜欢计算机科学的人来说，多玩家在线游戏和 MMOG 代表的体系结构模式会导致完全不同的操作模型。到编写本文时，交互式娱乐业还没有为多玩家在线游戏和 MMOG 体系结构创建标准的名称，所以我们将它们分别称为 “匀质的（homogeneous）” 和 “分层的（tiered）”。现在，我将解释这些游戏所需的基础结构是什么样的。

多玩家在线游戏基础结构层

对于匀质型的体系结构，服务器执行的功能并不分层。在许多情况下，简单在线游戏的几个实例运行在一个服务器上，它们甚至不必相互通信。在略微复杂一点儿的情况中，服务器平等地相互通信来支持多玩家在线游戏。在这种体系结构中，每个服务器的作用相同。当游戏增长时，只需增加更多的服务器。如果实现的方式合适的话，游戏将会自动地开始使用新的服务器。

MMOG 基础结构层

与匀质型的体系结构相反，在分层型或分片型体系结构中，玩家连接到一个服务器层。这个层与另一个执行特定功能的服务器层进行通信，那个服务器层又与另一个执行另一功能的服务器层进行通信。网络负责将这些连接在一起。另外，当需要扩大游戏容量时，在每一层中都可以增加服务器。

分层型或分片型 MMOG 使用游戏世界的数十甚至数百个拷贝来支持数量庞大的玩家。“片（shard）” 这个词通常用来描述围绕一种传统应用程序模式设计的各个服务器。这种模式是多层的 Model-View-Controller（MVC）。MMOG 中的每个片划分成三个主要的层。数据库层在最下面。数据库层上面的一层常常称为游戏引擎（或游戏服务器）。在这一层上面的一层常常称为前端。这个前端层常常进一步划分为几个子层，比如登录、边界和负载平衡。最后，所有 MMOG 都需要游戏防火墙和到互联网的连接。

性能因素

有许多因素会显著影响 MMOG 的性能，比如：

• 每个玩家每秒传输的平均数据量：这对于了解网络和前端基础结构很重要。
• 玩家的目标总数量：必须精确地估计将玩这个游戏的玩家数量。
• 并发玩家的目标总数量：在所有注册的玩家中，要计算出同时在线的玩家数量。
• 每个地理区域玩家的目标总数量：地理区域的划分应该与世界不同地区中玩这个游戏的玩家数量相匹配（例如，上海、北京、首尔、东京、悉尼、洛杉矶、西雅图、奥斯汀、纽约、伦敦、巴黎、慕尼黑等等）。
• 每个地理区域并发玩家的目标数量：根据游戏的情况划分地理区域之后，要判断每个地理区域中同时在线的玩家数量。
• 每个实例并发玩家的目标数量：要计算每个游戏实例可以支持的玩家数量，但是这常常难以判断。
• “世界数据” 的大小：这个指标是可控制的，但是变化范围很大，它是指数据库中将存储的信息量。
• 与玩家相关的数据的大小范围：这是指一个玩家在玩游戏期间将生成的持久数据量。

对这些因素进行评估

一般来说，在估计 MMOG 的规模时，首先要估计游戏的全球目标用户社区会有多大。接下来，需要判断每个地理区域的目标用户社区。决定了每个地理区域的站点数量之后，就得到了每个站点支持的用户数量。然后，将这些信息与游戏世界的每个实例可以支持的用户数量相结合，就可以得出使用传统体系结构方法评估 MMOG 基础结构规模所需的大多数基本信息。

回页首

MMOG 中的各个层

为了支持 MMOG 中的大量用户，游戏的服务器端是由数十或数百台服务器组成的复杂配置，各个服务器执行不同的功能。这个基础结构常常划分为层。每层执行与其相关的一组功能。通常情况下，MMOG 采用的体系结构模式笼统地称为 “n 层体系结构”。按照最基本的形式，这个体系结构可以分为三层：前端层、中间层和数据库层。

评估前端层规模

在线游戏是网络攻击的主要目标之一。它们对那些喜欢搞破坏的个人和团体似乎很有吸引力。因此在线游戏一定要防御网络攻击。防御的最前沿是高性能的网络硬件和良好的安全设施以及防火墙层，从而防御拒绝服务攻击、包碎片攻击和其他典型的强力互联网攻击。

评估中间层规模

中间层的规模取决于游戏引擎本身的体系结构。这一层是放置游戏引擎的地方。这一层的规模几乎完全取决于游戏引擎的实现。一般来说，大多数 MMOG 引擎在每个服务器上可以处理 200 到 600 个玩家；在使用现代处理器的情况下，许多公司都宣称每个游戏引擎服务器可以支持 600 个用户。一些设计新颖的游戏引擎甚至可以支持这个数量的 10 倍。

评估数据库层规模

数据库层必须尽可能没有延迟地处理环境中的事务。玩家的每次移动以及每个物体和怪物的变化，都必须记录在游戏的数据库中。但是，即使是最大的游戏世界，它的数据库也不能与大公司的数据仓库相提并论。游戏的模式也相当简单。这些因素使多玩家在线游戏引擎可以利用并行数据库技术，比如对称多处理器，以及其他大内存系统。只需稍加处理，多玩家在线游戏的大多数工作集就可以放在一个大系统的主内存中。

关于游戏数据库的注意事项

当一个用户退出 MMOG 时，游戏的永恒世界仍然继续运行。必须保存这个玩家所做的操作的所有信息、玩家退出时的位置以及玩家拥有的物品（关于 MMOG 设计的持久化机制的更多信息，请参见 参考资料 部分）。

在 MMOG 中，数据库活动的性质非常特殊。事务负载主要是大量简单的更新和读取。例如，玩家的每次移动、物品属性和人物属性常常需要记录在数据库中。因此，每当玩家移动他的游戏人物时，都要在数据库中更新位置数据。在 MMOG 中，会有成百上千的玩家不断地进行这些更新。

一般情况下，MMOG 使用与银行、金融公司、交易所和医疗记录系统相同的数据库技术。但是，与传统的业务系统不同，MMOG 中的数据模式非常简单，而且在数据库表上执行的事务都是简单的更新和读取。不幸的是，MMOG 的规模已经接近了传统数据库的体系结构极限。游戏业正在对非传统数据库引擎进行许多研究，希望实现更好的性能和更低的延迟。经验表明，内存数据库可以提供出色的性能和很低的延迟。有一些出色的数据库引擎技术能够为延迟关键型应用程序提供 ACID（原子性、一致性、隔离性和持久性）事务（关于 ACID 的更多信息参见 参考资料）。这些技术常常将数据分布在几个服务器上，因此会跨这些系统分发查询，这使数据集完全驻留在内存中，而且几个系统可以并行执行查询。

回页首

规模评估的简单方法

了解了与 MMOG 规模评估相关的大多数因素，并大致了解了对各个层进行规模评估的方法之后，主要关注点就可以转到 MMOG 规模评估的两个最重要的因素上：网络吞吐量和延迟需求。

对大型基础结构进行规模评估本身就是一门科学。有意思的是，对新的高速公路系统进行规模评估所用的技术也可以应用于 MMOG。简单地说，这种技术要寻找关键的容量因素和关键的性能因素。换句话说，要寻找关键的瓶颈。找到关键瓶颈的好处是，只要针对这个瓶颈增加资源，就能得到立杆见影的效果。在理想情况下，针对关键瓶颈增加资源，就能够成正比地提高整个系统的性能。如果找到了一些瓶颈，但是克服瓶颈的措施只使性能提高了百分之五或百分之十，那么就说明应该将精力花在别的地方了。如果克服瓶颈带来的改进很小，就很难证明值得这么做。如果找到了关键的瓶颈，性能可以得到很大改进，那么增加资源就是很值得的。

因此，关键的瓶颈就是对容量（“多少”）和速度（“多快”）限制最大的瓶颈。关键瓶颈通常用这两个指标来衡量。找到指标之后，就可以用它来评估整个 MMOG 基础结构的规模。

对于 MMOG 来说，关键瓶颈很明确 —— 游戏服务器与客户机之间的链路。可以放心地假设 CPU、内存和硬盘的速度比网络快得多。知道了瓶颈之后，就要评估这个瓶颈的影响。换句话说，识别出瓶颈之后，就可以判断对基础结构规模评估最重要的性能指标 —— 速度和容量。

速度因素涉及每个客户机需要的每秒比特速率。不幸的是，由于存在许多复杂的因素，常常会发现很难查明客户机和服务器之间需要的带宽，除非能够进行实际的度量。这意味着，需要构建完整的客户机和服务器，然后才能判断所需的带宽。

MMOG 的容量因素甚至更复杂。这个问题涉及到有多少用户同时玩这个游戏，而这个数字很难准确地估计。这个条件可以由游戏设计或业务模型来决定。无论通过哪种方式，必须确定一个数字，而且这个数字必须基本准确。

设计人员可能犯两种错误：

• 如果过高地估计每个实例的玩家数量，就很可能将投资浪费在不必要的设备上。
• 如果低估了玩家数量，设备就可能不足以支持游戏的运营，玩家会觉得游戏不流畅，因此放弃这个游戏。

没有什么方法能够精确地估计游戏会有多少玩家。只需进行比较准确的估计，以免浪费投资。经验表明，高估要比低估好一些。

在决定了要支持的并发玩家数量之后，就可以将注意力转移到计算 MMOG 的关键因素。只需将并发玩家数量与每个玩家所需的带宽相乘，得出基础结构的前端必须提供的总带宽。在判断并发连接数量以及每个前端服务器每秒可以处理的字节数时，网络经验是很重要的。

下一层的规模评估很复杂，因为它在很大程度上取决于实现游戏引擎的方式。对于游戏引擎层，可以可靠地假设瓶颈在内存/CPU 带宽上，而不是通信。如果是这种情况，那么就可以计算具有特定 CPU 和内存配置的一台双向服务器可以支持多少个并发用户。有一条经验规则：对于大多数游戏，每台前端服务器可以让至少四个游戏引擎服务器达到饱和。在游戏开发的早期阶段，可以使用这条经验规则决定大致的游戏引擎服务器数量。

与前两层的情况相反，数据库层的规模评估相当容易。答案是两台数据库服务器，因为过去几十年人们一直在设计和改进关系数据库技术。现代的关系数据库具有惊人的容量，在多 CPU 系统上执行效果非常好。在估计出并发玩家数量之后，就可以估计每秒事务量。得到结果之后，只需访问一个关系数据库性能基准站点，查找能够满足需要的系统。找到了能够满足事务需求的 CPU 和内存配置之后，只需购买两台这样的服务器，并将它们配置为 active-active 集群。在理想情况下，一台数据库服务器就能够处理游戏的全部负载，但是使用两台可以在成本和风险之间取得合理的平衡。与别的组件相比，数据库和数据库服务器不容易崩溃。选择 active-active 集群的原因是，现代的数据库集群技术很成熟，光纤连接的存储系统也相当便宜，所以实际上没有理由不采用这种方案。

每个游戏开发人员都希望将整个游戏数据库放在内存中。在这种情况下，性能会非常出色，完成事务的时间可以接近一次函数调用的时间。但是，这也意味着系统必须有非常大的物理内存。有什么现实的解决方案吗？有一种称为 “distributed shared nothing（分布式非共享）” 的数据库类型，它有可能提供将整个数据库放在内存中的能力。到编写本文时，在系统中安装 4GB 内存是比较经济的方案。shared nothing 数据库系统可以在一个系统阵列上分派数据和查询。例如，如果将 12 个 4GB 系统集合在一起，它们就能够为整个 40GB 的数据库提供足够的 RAM，同时还能运行操作系统和其他任务。

注意：游戏事务与业务事务有很大差异。在游戏运行期间，会对数据库进行大量非常小的读取和更新。游戏引擎不需要对星型模式做大量联结。游戏与决策支持系统（DSS）和在线事务处理（OLTP）系统完全不一样。游戏的负载更接近于 Lightweight Directory Access Protocol（LDAP）或电话簿查询：对简单的表执行大量的小事务。

关于延迟的考虑因素

到目前为止，本文一直回避了影响多玩家在线游戏和 MMOG 的可玩性的最重要的因素：延迟。描述延迟的相关因素及其评估方法的最佳方式是用交通进行类比。可以将在线游戏中的延迟与您开车从家里到商店并返回的时间进行对比。开车来回的时间受到以下因素的影响：开车去商店的速度，在商店里购物的效率，将物品装上车的效率，返回时的速度。汽车的马力不足，商店的组织混乱（比如收银台设计不合理），商店里排长队，交通拥挤，这些都会对往返时间产生显著的影响。

如果希望降低延迟，就需要增强所有这些方面的能力。还用交通来类比：可以将小货车换成马力强劲、容量更大而且速度更快的大货车。还可以选择更宽、车道更多的公路，以此避免交通拥挤。还可以提前打电话给商店订货。商店可以将货物准备好，放在大箱子里，等您的大货车一到就可以装货了。货车可以开进商店的自动装货通道，装货系统自动地将箱子放进货车车厢。大货车甚至可以走高速公路上专用的大容量汽车车道。

这种类比听起来可能有点儿可笑，但是它说明了要点。这个场景中的所有元素都代表网络技术中的某个组件；如果要降低延迟，可以修改所有这些组件，从特别设计的数据包（比如利用 jumbo 数据包这样的 IPv6 扩展）到 Quality of Service 协议（使用 IP 中的 QoS 选项）。如果在客户机和服务器之间传输的数据的设计不合理（就像是速度缓慢的笨重的汽车），游戏服务器的效率低下（就像是老式的家庭商店），那么数据包的往返时间就好不了。反之，如果对客户机和服务器之间传输的数据进行适当的设计，让服务器像新型跑车那样高效率，那么往返时间就可以降低。

这里的要点是，延迟会受到游戏引擎和客户机通信系统方面的设计决策的影响。一些出色的技术可以帮助优化数据包、减少数据包的数量并减少传输时间。缓存、预获取数据、队列优化、乱序传输和接收、连接池、提示和并行连接都是相当好的技术，可以在任何多玩家在线游戏中利用它们降低延迟。

当然，我们还是没有提到对 MMOG 中的延迟影响最大的因素 —— 互联网的速度。无论您是否相信，我们能够对这个问题采取一些措施。首先，一定要选择多个适当的站点驻留设施，它们一定要具有宽带提供商提供的低延迟连接，可以为特定的市场提供充足的服务。降低互联网延迟的最佳方式是将站点驻留在宽带服务提供商的基础结构中。提供商希望通过多玩家在线游戏给他们的网络增加价值，因此这种方式越来越可行了。对于在线第一人称射击游戏、比赛游戏、运动游戏和休闲游戏，这是更可行的方式；因为在这些游戏中永恒世界数据不是游戏的中心，而且玩家往往按照地理位置分组。

后勤基础结构的规模评估

对于整个 MMOG 的规模评估来说，完成游戏引擎基础结构的规模评估只是完成了一半儿的工作。计费和帐号管理系统同样复杂，而且对于 MMOG 的成功也同样重要，尤其是因为在玩家登录期间要使用这些系统。对于计费系统的规模评估，要考虑用户的数量和付费方法。

在不同的地理区域之间，付费方法差异很大。令人吃惊的是，MMOG 是首批真正全球性的在线服务之一，也就是一个服务供所有地区的人们使用。这给游戏业带来了一些独特的难题。例如，在北美，信用卡/借记卡系统是最普遍的付费方法，只有少量的预付费卡。在欧盟，预付费卡的使用量比在北美多一些。在亚太地区，尤其是中国，信用卡系统还没有普及，预付费卡系统是主要的付费方法。在所有这些地区中，无论采用哪种付费方法，付费处理和计费通常是一项外包的业务。通常，在每个地区，有几个公司专门从事游戏在本地区的收费。华盛顿州 Bellevue 的 InfoSpace 和北京的 YeePay（易宝）就是这样的公司。

付费系统本身是一种很成熟的后勤基础结构组件。许多业务咨询公司为电信公司或服务部门提供过咨询，他们可以帮助游戏公司以最小的代价建立付费系统。考虑构建 MMOG 的任何公司都应该认真考虑雇佣一家在付费系统方面有经验的咨询公司。无论从短期效果还是长期效果来看，这样做都是有利的。从业务的角度来看，MMOG 开发商和发行商对互联网服务的收入进行分成。按照这种模式，许多公司成功地构建了能够集成进游戏中的付费系统。

如您所知，规模评估并非一项简单的任务。好在它也不是完全没有规律的；而且通过做出几个合理的预测，就可以避免许多风险，避免浪费资金。有经验的运营商会让游戏更受欢迎，不应该低估他们的作用；在选择运营商时应该把期望值定得高些。有能力的运营商可以理解您的环境，能够更好地评估每个基础结构层的规模。

回页首

结束语

规模评估是 MMOG 项目中最具风险而且对成本影响很大的部分，您已经学习了如何处理这个问题。接下来，还有另一个重要的问题需要注意。您已经投入大量时间和资金开发出最新、最出色的游戏，那么将它们放在哪里呢？游戏的驻留并非一项简单的任务，应该认真考虑。驻留的经济影响很难评估。错误的决定会给游戏公司带来很大的损失。本系列的第 2 部分将从基础结构的规模评估转移到在实际驻留和运营 MMOG 时必须考虑的经济因素。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 在这篇 Wikipedia 文章中了解 MUD 的历史。
  
  
• 在这篇 Wikipedia 文章中 了解关于 ACID 的更多信息。
  
  
• “OptimalGrid -- 网格上的自主计算”（James Kaufman、Tobin Lehman、Glenn Deen 和 John Thomas，developerWorks，2003 年 6 月）讨论了 OptimalGrid，介绍了一种来自 IBM Almaden Research Center 的网格研究人员的研究原型。
  
  
• 对于任何游戏的客户端和服务器端的核心引擎组件，内存管理和性能都是很重要的。请参阅 “Memory profiling for C/C++ with IBM Rational Test RealTime and IBM Rational PurifyPlus RealTime”（Jeff Campbell，developerWorks，2004 年 4 月）。
  
  
• 创建 MMOG 时所面对的问题与数字特效（SFX）和动画行业面对的问题相似。请阅读 “Build a digital animation system, Part 1: Understanding the existing infrastructure”（Veronika Megler 和 George Dolbier，developerWorks，2005 年 7 月）。
  
  
• 通过 International Game Developers Association（IGDA） Online Games SIG 提供的 2004 Persistent Worlds Whitepaper（PDF 格式），了解关于 MMOG 设计的持久化机制的更多信息。
  
  

获得产品和技术

• 下载 IBM 试用产品：使用这些可从 developerWorks 直接下载的 IBM 试用软件构建您的下一个开发项目。

关于作者

		George Dolbier 是 IBM Games 团队的技术主管。George 在游戏行业有 10 年经验，他最初实现输入系统，然后从事游戏的语音和文本聊天，为在线游戏和服务提供商实现和管理在线运营。在进入游戏行业之前，George 已经具有深厚的软件工程背景，曾经为 Oracle、Informix 和 Sequent 等公司工作。目前，他正在利用自己的经验帮助 IBM 和游戏行业相互理解。

http://www.ibm.com/developerworks/cn/web/wa-mmogame1/index.html?S_TACT=105AGX52&S_CMP=techcsdn