最近几天，每当我打开手机里的聊天讯息时，总会看到一大票《最终幻想14》玩家的哀嚎。随着 5.0 新版本的开启，这帮倒霉蛋饱受排队和掉线之苦已长达一周，等待六、七个小时进不了游戏的大有人在，以至于 WeGame 适时亮出了“二区新服排队少”的宣传口号，回想起来还有几分滑稽。根据以往的经验，只要一款线上游戏还有些名号，那么初期上线的过程往往伴随着一场“人口灾难”，玩家们蜂拥而至，超过服务器负载的用户连接，就像是持续不断的合法 DDOS 攻击，瞬间击垮那些以规模著称的公司和作品。《魔兽世界》如此，《命运2》如此，《最终幻想14》也是如此。

2004 年，暴雪配备了 40 台服务器迎接《魔兽世界》开服，但他们完全低估了用户的数量级，游戏几近崩溃。后来发展到扩充带宽也于事无补，不得不中断零售商的盒装游戏供应，以免情况进一步恶化。再就是不久前《命运2》的资料片“暗影要塞”上线，同样因服务器宕机而进行了一次紧急维护，期间还闹出了“Steam 好友超过 300 就会闪退”的笑话。有人在社交媒体上调侃到：工作辞了，婚也离了，孩子放学没去接，就为了履行“守护者”的职责，现在你居然不让我打游戏？上述这些问题，对很多人来说可能早已习以为常，但当自己不止一次的遭遇时，还是会感到疑惑。那么多资源殷实的大公司，那么多富有才华的游戏制作者，为何总是一错再错？搞不定的引擎早期的线上游戏很少会有排队系统，因为玩家数量有限，开发商和中间件的制作者也不太关心用户分流 —— 一个 MMO 内容比较泛用的引擎，Big World 就有类似的缺陷。打造该产品的 Micro Forté 公司很有意思，他们在上世纪 80 年代给 EA 开发了几部作品后，就布局其它业务去了。直到 1994 年时重返游戏行业，从澳大利亚政府那弄了笔拨款，筹划着制作 MMOFPS 的内容、开发引擎和工具，后来又顺利被微软看中，作为推广 Xbox live 服务的一部分，运气可以说相当不错。但财大气粗的微软，当时其实投资了好几家涉足 FPS 联机游戏的团队，他们最后选择了 Bungie 做的《光环》，Micro Forté 只不过是个保底。于是在项目被终止后，这家公司因经营困难被迫裁员 70%。幸好开发引擎在资金链断裂前做完了，他们为了填补家用就直接打包拿出来卖，没想到销路不错。

用 Big World 创造小镇

这套 MMO 工具最终商业化，并得名 Big World 是在 2002 年，有很多我们熟悉的企业都购买了授权，比如网易用来开发《天下2》和《天下3》，Wargaming 拿来支持《坦克世界》的服务，台湾的宇峻奧汀也是使用者之一。还有一个比较流行的说法，有人认为《魔兽世界》的一部分功能也是通过“自研 + Big World”引擎来实现的。理由很简单，当时暴雪的母公司维旺迪想要收购 Micro Forté，最后遭到拒绝，退而求其次获得了引擎的使用权，而 Micro Forté 的公司介绍中又有这么一段耐人寻味的话：2001 年底，在技术完工的最后阶段，我们收到了全球领先的跨国互动娱乐公司的收购邀约。作为交易的一部分，这家跨国公司提出会将一个重要的 IP，奇幻 MMOG 项目交由我方打造，但由于董事会认为出价太低，所以交易未能完成。不难发现，在很长一段时间内，Big World 引擎都是线上游戏的一套设计范式。但正因为推出得太早，它在排队系统、以及用户分流方面是有所缺陷的。就拿角色建模来说，由于最初定位于 FPS 游戏，相当一部分带宽和处理器资源都用在了 3D 空间的位置同步上。比如《坦克世界》里一炮打过去，履带、车头、车尾都有不同判定，对于绝大多数类型的 MMO 游戏而言，这套机制有些过于浪费性能了。

坦克世界

在排队系统的设计上，通常情况下可以单拿一组服务器出来当“连接服务器”，作为用户的入口。它们把汇集起的信息送到“心跳服务器”，由此转发到处理内容的“逻辑服务器”。当然有些小公司没钱、没条件，那也可以考虑利用多进程设计，把排队系统独立到一个进程里，负担过高时再分配到另一台物理机器上运转。但因为 Micro Forté 最早根本没考虑这些，导致其它公司的程序员在给 Big World 添加代码时，只能把排队系统放到引擎框架内，结果就是没法提高优先级，很难和服务器的其它资源做隔离。再就是排队本身的逻辑，要求服务器短时间内接纳连接，并将这些连接进行分流和保持，以免玩家“重连”而增加服务器的负担。但 Big World 全部采取了不稳定的 UDP 通讯协议，导致连接很难保持（虽然游戏内使用 UDP 是一种合适的方式，参考《无尽的任务》）。如果观察最近几年推出的线上游戏，会发现很多厂商都抛弃了老旧的 Big World 引擎，也有人在此基础上进行了二次优化。但有些古老的排队系统早已定型，重构需要耗费很多资源，有些设计思路也没有革新，一时半会还来不及做转型。

不过，之所以 Big World 引擎能被线上游戏广泛应用，证明它还是有两把刷子。秘诀是它并不以地图的形式来分担负载，而是哪里聚集的玩家多，就给哪里分配服务器资源，比较灵活，因此理论上可以最大限度的容纳角色数量。2011 年时，《坦克世界》就创造了并发在线人数 25 万的成绩 。相比之下，有人猜测《最终幻想14》的单区容量撑死 10 万人，肯定是架构方面有所不同。比如 1.0 版本用的是 Square Enix 自研“Crystal tools”引擎，当时的设计非常愚蠢，几乎所有的页面交互都要过一道服务器，无法在本地进行，玩家们关个物品栏都要几秒钟，很容易导致服务器过载。归根究底，这些网络工程的技术，和制作游戏内容领域有别，也难怪那些知名的单机游戏开发团队频繁踩坑。反倒是现在比较流行的手游，服务器单区容量都是以几百万注册用户、几十万在线玩家为基准的。料不到的问题当然，无论使用什么样的技术，还是不计成本的优化，用户连接数在物理意义上都是有限制的。较为常见的一套排队系统是，客户端登录时等同于向医院柜台挂号，叫到你的号时，连接服务器把号给收回来，同时送出一张通行券。但这其中又有很多变化，比如竞技匹配的排队机制，就要求将水平相近的玩家一批批放行。看似无缝的逻辑，也很容易在外力的影响下崩溃。《废土之王》的制作人拉米（Rami Ismail）举了个有趣的例子，他认为，如果是代码本身减慢了玩家数据的处理速度，可以比喻成“一个车站有足够多的火车和轨道，但每个乘客都必须下车填一张表”。若是硬件限制，那相当于“轨道的数量不够，一大批进站的火车堵住了”。要是算到网络问题的头上，就如同“发车班次太少，人们都被困在了车站”：也许从 A 站到 D 站的火车只比你想象中慢了 2%，但久而久之 D 站就会挤满等待的人，直到最终发生故障。其实站在消费者的角度来看，线上游戏的冗长排队和频繁掉线，无疑是运营商“风控”的结果。他们本可以掏钱买服务器解决问题，但又担心玩家流失后，针对基础设施的投资打了水漂，因此才过于保守。但置身其中的一部分开发者又会认为，问题的根源通常不是缺少机器，而是软件引发的崩溃和故障。

前顽皮狗工作室的德鲁（Drew Thaler）对此深有体会，他之前负责维护《神秘海域》和《最后生还者》的多人服务器。由于索尼提供了一项尚未大规模使用的技术，《最后生还者》在重制到 PS4 上时，服务器的代码出现了问题，这导致玩家的匹配时间过长，有时还会直接掉线。开发团队当时提出了一个临时方案，几个月后才发现，那个问题只是由一小段关于“SSL 实现”的 Java 代码引发的。换而言之，可能是配置加密传输时，手动处理端口、约定协议给搞错了。虽然这算是一个比较低级的失误，很容易就能解决，但相当难以定位，德鲁表示：就像是手机上的谷歌地图给你指了条错路……最后原因可以追溯到你家有根电线出了故障……网络服务不仅仅是一台服务器，它们是复杂的系统。这台服务器处理匹配和排队，那台要去接收日志，这个得拿来做 NAT 隧道，还有设备用于处理排行榜和身份验证，又比如应对虚拟货币，需要对交易进行特别保护……

故障可能由任何细小的东西引起，《网络创世纪》的设计师拉菲（Raph Koster）同样分享了一则糗事。有次在给《网络创世纪》的活动制作圣诞树时，由于缺少美术，他突发奇想的做了个看起来很酷的功能：我在一棵普通的松树上附加脚本，做出了彩色宝石的效果。每棵树都带有周期性的回调脚本，这些脚本可以（使宝石）出现和消失，所以它们会闪烁。然后我们给每个登陆的玩家送了棵圣诞树，成千上万棵树使得每秒会产生 20 个回调，每台服务器上的消息队列都超载了，最终导致整个服务器崩溃。

《网络创世纪》中的圣诞树

实际上，《全境封锁2》中也有过相似的问题，玩家们的炮塔和无人机有时不起作用，最后查明原来是技能的状态效果太过复杂，一旦有很多人同时使用，消息就会堆积起来阻塞服务器。这意味着，不少代码上的缺陷，只有在用户数量激增的情况下才会体现，德鲁补充到：这就是问题所在，游戏在测试或是千人模拟时远转良好，但如果 1 个小时内，突然有 10 万人登陆会怎样……3A 游戏免费后，用户会呈指数增加，付费情况下你可能不会完全预料到这一点。我们推出过《神秘海域》的免费周末活动，它带来了 10~20 倍于正常负载（的用户数），击垮了我们的服务器。如何保证线上游戏稳定的运行，以及如何减少排队和掉线的情况，全方位牵扯到引擎、游戏设计和网络工程等相关知识，由此来看它是一项非常精细的技术。但有时这些理不清的关系，会导致某些麻烦无法单靠开发者、运营商，乃至投资人任何一方解决，于是他们本应付诸的成本，顺理成章的转嫁到了玩家身上。十年前还有人相信，遵循摩尔定律的发展，线上游戏的一些网络制约最终会弱化。但随着集成电路走向瓶颈，以及用户需求的不断提升，时至如今，它仍然是一个悬而未决的问题。

责任编辑：孙妍(EN083)