
對局配對深入分析:區域對局配對与服务器区域选择

选择区域是一个真实信号,而非规范:当玩家要求选择其服务器区域时,他们是在报告一个他们无法看到或控制的延迟问题。他们所请求的功能是其中一种可能的解决方案,而且在较小的玩家基数下,这会用糟糕的比赛来换取未填满的比赛。
基于延迟的分组解决了区域限制所绕过的根本原因:区域是行政边界。而延迟是经过测量的。通过测量的 Ping 值对玩家进行分组,可以在不按地理位置划分队列的情况下,将距离遥远的玩家排除在同一个大厅之外。
随着时间的推移放宽规则是大多数匹配机制未充分利用的杠杆:动视(Activision)发表的研究表明,随着排队时间的增加,放宽技能限制的速度要快于放宽连接限制。同样的渐进方法也适用于任何池化规则。
当权衡过程可见时,排队时间是可以商榷的:几个社区的玩家自愿等待更长时间以获得更好的连接。让他们感到沮丧的不是等待本身,而是不知道等待能给他们带来什么好处。
透明度和自主权可以缩短反馈回路:可见的 Ping 值和选择等待更近服务器的选项,可以将模糊的指责转变为玩家可以采取的行动,代价是可能会暴露您不想公开的数据。
几乎每个多人游戏社区最终都会出现这种诉求,且具体措辞几乎一模一样。一名《战地6》玩家要求 EA “让我们选择自己的服务器区域,不要强加高延迟的服务器给我们”,并解释说他们住在中西部,到东海岸官方服务器的延迟是 50-60 毫秒,却常常被分配到他们怀疑是西海岸的服务器,延迟大约在 100 毫秒。一名《火箭联盟》玩家询问是否可以禁用扩大区域的對局配對,因为他们遇到延迟超过 200 毫秒的对手。一名《绝地求生》(PUBG)玩家则在寻找曾位于大厅底部的服务器选择按钮,该按钮在一次更新中消失了。
这些社区的反馈都没有错,所涉及的游戏也没有任何异常。这正是该诉求值得深入探讨而非简单回应的原因。动视的第二份對局配對白皮书(2024年)仍然是目前最详细的公开报告,阐述了大型工作室如何在队列中权衡连接质量与其他所有因素。以下其余内容则源于在各种在线玩家规模的实际游戏中运行 Edgegap 的對局配對系统的经验,在这些场景中,这些权衡不再只是理论。
以下是玩家在要求选择区域时所反馈的问题、可用于解决该问题的机制,以及每种机制所付出的代价。遗憾的是,没有一种机制是“免费”的,它们都伴随着权衡。
玩家反馈的问题
最常见的投诉形式是:
游戏体验不稳定。有些对局很流畅,有些则完全无法进行。
玩家无法预测自己即将进入哪种对局,而且游戏中没有任何信息解释这种差异。
这实际上描述的是一个在无可见度、无输入情况下的连接质量问题。
这就引出了应对方式。如果玩家反馈的是“我的延迟不稳定”,那么区域选择器只是几种可以解决该问题的机制之一,而且它恰好带有最大的副作用。字面意思上,这种需求产生的功能只解决了表象,而作为根源的對局配對系统最初如何对玩家进行分组却未被触及。
划分队列的代价
区域选择并不能凭空创造玩家,它只是对已经在队列中的玩家进行分流。
一款拥有庞大玩家基数的游戏可以轻松吸收这一影响,这也是为什么该功能在拥有数十万同时在线用户的游戏中是标配。但对于只有几千名玩家的游戏来说则不然。一旦按区域划分,再按技术水平、组队人数和游戏模式列表划分,在非高峰时段,每个玩家池可能会缩减到只有几十人。對局配對系统剩下的唯一选择就是等待,而玩家剩下的唯一选择就是放弃等待。一名《Apex 英雄》玩家展示了这一极端的后果,反馈排队时间长达 50 分钟,而且在他们切换的每个区域都遇到了同样的等待时间。
玩家有时自己也能摸清其中的机制。在某款较小游戏的反馈帖中,对区域选择诉求获得最多赞同的回复指出,工作室不会推出该功能,因为这“会导致對局配對时间过长”,并暴露玩家群体的规模。
区域只是这种划分的一个维度。游戏模式列表是大多数开发者已经了解但仍低估的维度,因为模式数量是在一个没人关注玩家池深度的会议室里决定的。以下是三种应对措施,按难度从高到低排列:
增加每个区域的玩家数量。这是一个用户获取问题,而非工程问题,也是唯一能让其他选项变得不必要的选择。
整合游戏模式。向玩家清晰传达,选择特定的游戏模式固然重要,但相比于确保玩家能加入一场对局,它并非强制性的规则。
增加队列后备机制。为在某一模式中等待过长的玩家提供相邻模式的对局,而不是让他们继续等待。
没人喜欢削减模式,这种阻力是合理的:多样性是人们持续玩游戏的部分原因。后备机制保留了多样性,但需要小心处理,因为被直接扔进一个自己没有选择的模式的玩家会将其视为 Bug,除非这一机制是明确告知的。无论如何,区域选择始终依赖于玩家数量。当每个区域都能维持自己的队列时,它行之有效;而当某个区域无法维持时,它会迅速恶化。
限制因素是距离,而非区域
区域是行政划分,而网络距离是物理存在的,它决定了一场对局能否被公平地提供。这种影响很容易被独立证实:像 Globalping 这样的分布式测量工具可以向您展示从全球探测点到您选择的任何主机的真实延迟,这是计算平衡点所需的原始数据。
Edgegap 在對局配對时测量每个玩家到信标网络的延迟,然后计算一个平衡点:即与拟定对局中每个玩家的网络距离大致相等的近似位置。它回答了一个问题,即是否存在一个能对这一特定群体一视同仁的服务器位置。
下面的热力图描绘了在一组实际部署中这些平衡点的分布情况。美国中部和英国上空的聚集区并不令人意外,因为实际的服务器容量就在附近。高亮显示的聚集区才是最有趣的。在这些对局中,最公平的服务器位置实际上是大西洋北部。

显然那里没有基础设施,因此这些对局中的每一场都必须托管在偏向某一方的某个地方。
这并非海洋所特有。在一个横跨大国两端的游玩大厅中,在较小尺度上也会产生相同的结果。只要群体过于分散,就会有人在与技术无关的情况下处于劣势,公平性也会明显下降。Edgegap 的 1v1 测试发现,在构建和托管对局时考虑延迟对等,可以带来 28% 的公平性提升。
有两种机制可以在不使用区域下拉菜单的情况下解决这一问题:
根据测量的延迟而非声明的区域对玩家进行分组,并根据需要放宽该限制,这正是 Edgegap 的對局配對系统处理该问题的方式。
或者在低于最大填充率的情况下进行部署,例如以 4v4 开始一场 6v6 的游戏,而不是从另一个大洲拉入第七名玩家。第一种方法的代价是队列复杂性以及边缘情况下较长的等待时间。第二种方法的代价是每局游戏的人数,这在纸面上看起来像是降级,但实际游戏体验往往比另一种选择更好。这两者需要的频繁程度取决于您的玩家附近有多少服务器容量,这也是增加服务器位置而非增加区域的实际意义所在。
随时间放宽的规则
大多数對局配對限制都是一次性设定并统一应用的。将它们视为固定阈值会导致“严格”还是“宽松”的争论,这场争论没有赢家,因为这两种设置在一天中的不同时段都是错误的。
动视的白皮书描述了一种更细致的方法。系统会追踪延迟差(即玩家最佳连接与他们与其他数据中心连接之间的差异),并在排队时间增长时引入退避机制。玩家等待的时间越长,限制就越放宽。技术限制比连接限制放宽得更快,这反映了该白皮书的立场,即连接质量重于技术水平(Edgegap 对这些发现的剖析,以及应用延迟规则的机制)。
可推广的部分并不是阈值本身,而是具有放宽曲线的规则比具有单一数值的规则能更好地服务于变化的玩家群体,这适用于任何分组逻辑,无论是延迟还是其他因素。
其付出的代价是调优。曲线必须适配真实的玩家群体,并随着群体的变化而重新调整,而且在冷门时段排队的玩家按设计会进入更宽松的对局。主动做出这一决定总比事后才发现要好。
当权衡可见时,排队时间是可以妥协的
排队时间是游戏工作室极力维护的指标,数据也支持这一点。Edgegap 的延迟研究表明,34% 的玩家流失归因于在队列中等待的时间。
论坛的讨论帖让这个问题变得更加复杂且具有建设性。那位《战地》发帖者表示愿意接受更长的對局配對时间以换取更好的连接。在另一款规模小得多的游戏讨论帖中,一名玩家给出了具体数字:最近的排队时间“经常在 2 分钟以内”,并且如果对局体验良好,他们明确愿意接受 5 分钟或更长时间的等待。
两人都不是在抱怨等待。他们抱怨的是等待之后却进入了一场无法正常游玩的对局。当玩家明白等待能换来什么时,等待时间似乎是可以容忍的;而当等待似乎毫无收获时,它就变得无法忍受。
这指向了一个低成本的行动,即在排队时让这种交换变得清晰可读。一个显示正在寻找低延迟对局,或者提供继续寻找更近服务器选项的队列,是让玩家主动选择参与这种权衡,而不是默默承受。其代价是坦诚面对自己的数据,并承担部分玩家拒绝并离开的风险。并不会因为论坛用户说他们愿意等待,那 34% 的流失数据就会凭空消失。
透明度与自主权
这些讨论帖中的两个诉求与服务器毫无关系。玩家希望看到自己的延迟,并希望在接受糟糕的延迟时有发言权。
在某款较小游戏的公开功能诉求板上,2026年6月提交的第一个条目要求在计分板上显示玩家和服务器的延迟,以及所连服务器的位置。论坛评论者也提出了同样的要求,其中一人指出他们不理解隐藏这个数字的决定。
这种挫败感背后的机制很简单。在没有延迟读数的情况下,玩家无法将距离遥远的服务器分配与他们自己的连接问题或网络代码问题区分开来。每一次糟糕的对局都变得无法归因,而无法归因的糟糕对局往往会被归咎于开发者。显示数字并不能改善任何人的连接。但它改变了玩家对待糟糕连接的态度——他们会去诊断原因,而不是指责。
有两个已经上线的例子值得研究。《反恐精英 2》提供了一个“最大可接受對局配對延迟”设置,将延迟上限以及随之而来的排队时间交由玩家掌握。《街头霸王 6》在对局前的信息展示上更进一步,在对局开始前显示对手是使用 Wi-Fi 还是有线网络,这告诉了玩家一些原始延迟无法体现的连接稳定性信息。《以太之战 2》是另一个对被告知其网络状况真相反应良好的社区(其网络体验剖析)。

书写者
Jakub Motyl,Edgegap 产品负责人









