
会话填充率如何影响你的多人游戏托管成本

当游戏开发者谈论匹配时,讨论通常会集中在面向玩家的指标上:基于技能的匹配(SBMM)、匹配评级(MMR)、排队时间和对局质量。这些都很重要。它们直接决定玩家是留下还是离开。
但还有另一个鲜少受到关注的匹配指标,它既不会出现在玩家评论里,也不会出现在社区投诉中。它会出现在你的托管账单里。
这个指标就是 会话填充率。
填充率不是一个匹配指标,而是一个计费指标。大多数开发者不会这样看待它,而这种认知差距会直接带来成本。
本文将拆解会话填充率是什么、它如何与托管成本关联,以及它在不同游戏类型中的表现。如果你想深入了解如何在技术层面优化它,详细配套指南在这里。
什么是会话填充率?
会话填充率是指你的游戏服务器玩家容量中,实际被活跃玩家占用的百分比,按一段会话的完整生命周期取平均。一个配置为 10 名玩家、平均运行 8 名玩家的服务器,填充率为 80%。一个平均运行 5 名玩家的服务器,填充率为 50%。
之所以这个差距重要,是因为无论其中有多少玩家,你都要为服务器付费。
填充率由玩家如何进入会话所决定。在匹配制游戏中,匹配器决定会话开始时大厅有多满;这是影响填充率的主要杠杆。对于支持补位的游戏,新玩家可以在对局进行中加入,替换离开者或填补空位,从而在整个会话生命周期内提高平均占用率。对于持久在线服务器,服务器浏览器允许玩家自行选择可用槽位,使填充在各个在线实例之间更自然地分布。
填充率与托管成本之间的关系
如果没有匹配指标,要在规模上衡量会话填充率与托管成本之间的关系很困难。凭借我们在匹配数据方面的经验,可以说在建模场景中,这种关系近似成比例,而真实环境中的部署也证实了类似的模式。
作为一个方向性的经验法则:对于基于会话的游戏,填充率每提高 1 个百分点,月度托管成本大约可降低 1%。
其背后的数学很简单。在任意时刻,你的基础设施需要运行的活跃会话数量为:
active sessions = CCU / (players_per_session × fill_rate)
填充率越低,为服务同样数量的玩家所需的会话就越多。会话越多,计费的 vCPU 分钟就越多。
为了让这一点更具体,下表基于一个建模预设:一款中端市场的会话制射击游戏,峰值 CCU 为 10,000,每场 8 名玩家,每个会话 1.0 vCPU,55% 混合部署(裸金属加云端溢出)。这些数字仅用于说明,不代表你的具体游戏一定如此,因为每款游戏的指标都不同,但它们清楚地展示了这种关系的形态。
填充率 | 月度成本 | 相对于 95% 的年度超支 |
|---|---|---|
50% | $17,247 | +$95,436 |
60% | $14,443 | +$61,788 |
65% | $13,366 | +$39,492 |
70% | $12,447 | +$37,836 |
80% | $10,948 | +$19,848 |
85% | $10,327 | +$12,396 |
90% | $9,773 | +$5,748 |
95% | $9,294 | - |
有几点很突出。首先,曲线在底部更陡峭。在此模型中,一家工作室将填充率从 60% 提高到 70%,每年可节省约 24,000 美元。而从 85% 提高到 95%,每年可节省约 12,400 美元。填充率最低的工作室,每提高 1 个百分点获益也最大。其次,即便每月差额 478 美元看起来还能接受,90% 填充率下每年 5,748 美元的超支也更难忽视。
在填充率之上,匹配人数还会带来叠加效应。在同一模型中,在 95% 填充率下将每场 8 人提高到 10 人,可进一步将月度成本降低 1,796 美元,约每年 21,500 美元。填充率决定你在成本结构内运作的效率;匹配人数决定成本结构本身。
你的数据会因 CCU、服务器规模、部署模式和云服务商组合而不同。填充率计算器可让你直接为自己的游戏建模,或者联系我们获取更有针对性的估算。
为什么填充率会下降
低填充率通常不是 bug。它往往是匹配机制与服务器生命周期相互作用,以及玩家群体随时间整合的自然结果。
最常见的原因有:
在达到最小玩家数后立刻填充服务器,而不是等待大厅更满
激进的超时设置,优先速度而非会话密度
游戏模式过多,把匹配池分散到太多队列中
实例生命周期中的预热和回收阶段会产生开销,但不会提供任何游戏内容
这些都不是意图上的失败。它们是为了玩家体验而调优的匹配规则,在没有将填充率作为明确约束时所产生的可预见结果。
地理因素会让问题更严重。规模较小的地区玩家池在结构上就很难填满。你可以在全球平均填充率看起来健康的情况下,某个地区却在每位玩家成本上严重失血(见“区域盲点”)。
影响最严重的地方
填充率风险在不同游戏类型之间并不相同。最重要的两个结构性属性是大厅规模和对局时长。二者共同决定了任何游戏能够多高效地填充会话,无论匹配器调得多好。
大逃杀游戏面临最严峻的挑战。一个 24 人大厅需要在会话开始前聚集大量玩家,而且早期掉线意味着服务器很少能在整场比赛中保持满员。在没有专门优化的情况下,估计填充率结构上大约落在 50%–65% 之间。这还是在叠加任何匹配效率问题之前的起点。
MOBA 和射击游戏处于更可控的区间,估计为 65%–80%,但它们对区域碎片化非常敏感。它们的对局规模更小,在健康市场中更容易填满,但某个表现不佳的地区就可能把原本健康的整体数据显著拉低,下一节会讲到这一点。
对于无法在所有支持硬件上实现跨平台游玩的游戏,例如许多 VR 游戏,来自不同头显的玩家无法一起匹配,那么玩家池实际上会按平台被分割成多个独立队列。这并不总在开发者控制范围内,但仍值得纳入填充率预期。一个玩家分布在多个不兼容平台上的游戏,与同等总规模的单平台游戏相比,会面临更大的填充率挑战。
区域盲点
一家运营多个地区的工作室,并不是只有一个填充率,而是有多少地区,就有多少填充率。
如果只跟踪全球总量,很容易忽略那个为了服务你一小部分受众却要支付两到三倍每位玩家成本的地区。
一个匿名的基于会话的 PvP 游戏,运行着五个全球地区,恰好展示了这一点。主要市场的填充率处于合理水平。但观察到某个较小的地区部署填充率大约只有 35%,这意味着每 1 美元服务器成本中,只有约 0.35 美元对应的部分真正提供了游戏内容。该地区的每位玩家云成本大约是主要市场的三倍,纯粹是因为匹配效率低,而不是基础设施成本更高。
那家工作室的全球平均值看起来很可能是健康的,而这个平均值把那个离群地区完全掩盖了。
如何衡量并改进它
第一步是知道你的数字。填充率计算器会在你做任何埋点之前,根据游戏参数给出一个起点。如果你使用 Edgegap 的匹配器,也可以直接通过分析仪表板获得填充率指标。
一旦有了基线,可用于提升的杠杆就很明确了。深入优化指南会详细介绍这些内容,但下面是你可以探索的方向:
分别设置 min_team_size 和 max_team_size。 默认情况下,匹配器会尽可能追求最大填充率并尽量等待。将 min_team_size 设得低于 max_team_size,可定义底线——低于该点时,匹配器会接受一个不完整大厅,而不是让票据在完全没有匹配的情况下过期。随后补位会在会话开始后把人数恢复到满员。
调整扩展规则。 随着排队时间逐步放宽技能和延迟约束,可以在不影响早期对局质量的前提下,提高大厅更满的概率。
为适用的游戏模式实现补位。 对于玩家可在进行中加入的游戏,补位会在整个会话生命周期内替换离开者并填补空位,而不只是对局开始时。
为低 CCU 边缘场景使用按配置文件划分的设置。 非高峰时段、次级地区、小众游戏模式以及低人口地图,都会产生标准配置超时或填充不足的情况。针对这些场景采用一个具有更宽松扩展容忍度的独立配置文件,可以在不影响高峰时段对局质量的前提下显著提升填充率。
按地区而非仅按全球监控填充率。 汇总数会掩盖地区离群值。按地区跟踪填充率,是识别哪儿的每位玩家成本最高的唯一方法。
机器人替补作为隐藏的成本放大器
用机器人替代缺失玩家,是许多需要最低玩家数才能运行的游戏模式的常见解决方案。由于它会在三个层面上叠加,托管成本通常会被低估。
缺失的人类玩家会直接降低填充率,意味着会话的运行占用率低于预期。
运行在服务器端的 AI 逻辑会在基础会话成本之上增加 CPU 负载。
而且机器人的游戏状态会网络同步给所有已连接客户端,增加会随玩家数量和 tick 速率增长的出站流量成本。
看似是玩家体验上的解决方案,在每一层都会带来可衡量的基础设施成本。对于结构上确实需要机器人的游戏模式,最好将这部分成本明确纳入核算,而不是把它当作无法解释的超支吞掉。
—
本文中的成本数字基于固定的说明性预设建模得出,不应被视为保证结果。按类型划分的填充率范围属于结构性估计,基于对游戏机制的分析以及匿名客户的部署模式。区域填充率的观察结果来自某个客户部署的匿名数据。
书写者
Jakub Motyl,Edgegap 的产品经理








