

您Unity游戏中最简单最佳的红娘

文章更新于 2026 年 8 月。
每款多玩家游戏都需要解决同一个问题:以良好的连接和值得一玩的对局,快速将合适的玩家送入同一个会话中。
这就是基于逻辑的對局配對。在大多数架构中,它也是触发游戏服务器部署的组件,这使其成为玩家与基础设施之间的承重部分。
这与大厅形成鲜明对比,大厅允许玩家连接到任何列出的服务器,而不施加任何逻辑。
本文介绍了 Unity 开发者可用的选择、每种选择实际能带给你什么以及其成本。
了解對局配對
在根本上,少数几个要素决定了玩家是否会被分组在一起,包括技术水平、连接质量以及游戏内偏好(如模式或地图)。其目标是打造一个既好玩又具有挑战性的会话。
值得关注的三个原因:
平衡的对局。屡次输给比自己强得多的人并不好玩,而痛击比自己弱得多的人也同样无趣。配对系统的职责就是让结果充满悬念。
玩家留存。获得合理对局的玩家会留下来。而遭遇惨败且延迟高达 200 毫秒的玩家则会流失。
进入游戏的时间。手动协调对手是种摩擦。自动分组能在玩家依然想玩的时候将他们带入游戏。
值得注意的是,这些目标相互冲突。更严格的技术匹配意味着更长的排队时间,而更严格的延迟限制则意味着更小的候选池。这份列表中的每个配对系统实际上都是关于如何进行权衡的一套主张,而优秀的系统会让你自己来设定这种权衡。
如果你想了解大型工作室是如何思考这一问题的,我们对《使命召唤》基于技术的對局配對的剖析涵盖了动视自身关于该主题的数据。
Open Match
Open Match 是来自 Google Cloud 的开源對局配對框架,运行在 Kubernetes 上。它处理大规模运行對局配對服务的基础设施,并将实际的配对决策留给你。
这种分离是其重点,也是其难点。Open Match 为你提供管道。你需要构建连接客户端和配对系统的 Game Frontend、决定谁与谁一起玩的 Match Function,以及将对局分配给游戏服务器的 Director。每款游戏验证玩家的方式不同,启动服务器的方式不同,衡量技术的方式也不同,因此这三个组件需要由你来编写和维护。
Open Match 最后一个带标签的发布版本 v1.8.1 于 2023 年 12 月出货。在大多数生产部署运行的分支上,已经将近三年没有版本化的发布了。
开发工作已转移到 Open Match 2,它将 Frontend、Backend 和 Query 服务合并为一个单一的水平可扩展二进制文件,完全弃用了 Evaluator,并与 gRPC 一起暴露 HTTP。它与语言无关,因此你的 match function 可以用任何支持 gRPC 的语言编写。它目前仍处于公开预览版阶段,从 OM1 迁移到 OM2 属于对集成层的重写,而不仅仅是版本升级。
这并没有让它成为一个糟糕的项目。它是一个设计真正优秀的框架,如果你的团队在 Kubernetes 方面有深厚的积累,并且想要完全控制对局逻辑,那么它是值得信赖的开源起点。
但免费的部分仅限于许可证。你拥有集群、Redis 层、可观测性栈、轮班待命值班以及迁移决策。这是一项长期的工程承诺,也是团队一致低估的部分。我们在免费产品的昂贵代价中更详细地介绍了相同的模式。
Edgegap
Edgegap 的配对系统是完全托管、完全可定制的,且无需代码进行配置。
你只需编写一个 JSON 配置来定义一个或多个配置文件,其中每个配置文件都是一个带有自身规则的独立队列,配对系统会据此生成其 API。规则是具有类型的命名条目:player_count 用于队伍大小,number_difference 用于类似 Elo 的数值,string_equality 用于游戏模式的精确匹配,intersection 用于重叠的地图选择,而 latencies 用于连接质量。
最后一种规则类型是其他地方所没有的部分。客户端针对 Ping Beacon 测量其延迟,配对系统直接根据这些测量值进行匹配,同时强制执行最大可接受延迟以及对局中最快和最慢玩家之间的最大差异。
这不是地区下拉菜单。而是实测的 ping 值,无地区限制。
这意味着里斯本的玩家和卡萨布兰卡的玩家可以基于他们都能很好地连入同一台服务器这一事实进行配对,而无需他们中的任何一方选择“欧洲西部”并碰运气。
规则也会随着时间的推移而扩大。你定义与排队秒数挂钩的扩大阶段,每个阶段都会放宽特定属性。竞争性配置文件可能开始于 50 Elo 差异和 125 毫秒最大延迟,在三十秒时扩大到 150 Elo 和 250 毫秒,然后在三分钟时降低队伍大小的下限。队列变短了,而无需在最初的十秒钟内放弃你的质量标准。
盒子里的其他东西:
群组和第三方大厅。内置了组队支持,并且该配对系统可与 Epic Online Services Lobby、Steamworks Lobby、Nakama Groups、PlayFab Lobby、brainCloud、GameKit 或你自己的大厅服务协同工作。
补人 (Backfill)。由服务器拥有的票据,用于替换离开的玩家或允许玩家加入正在进行的对局,同时仍然遵守你的對局配對规则。
注入的变量。票据 ID、队伍分配、解析的规则值以及玩家属性作为环境变量到达游戏服务器,因此服务器确切知道它刚刚接收了谁。
分析和玩家追踪。部署会标记有分配给它们的票据 ID,这使“该玩家说他们的对局很糟糕”变成了一个可搜索的问题。
滚动更新。蓝/绿配对系统实例,因此客户端和服务器版本过渡不需要停机时间。
Edgegap 的配对系统现在通过专用的 Unity SDK 更易于集成
Unity SDK 通过 Unity Package Manager 安装,并附带一个可运行的對局配對示例、针对信标的自动 ping 测量以及针对注入的服务器变量的 JSON 解析。
实际上,这把集成变成了“导入包、将其指向你的配对系统 URL、调整示例”。如果你需要,原始 API 依然存在,同时还有一个服务器对服务器层,用于附加敏感属性,如作弊标记或来自你自己后端的权威技术评级。
Edgegap 的配对系统成本
免费套餐涵盖所有功能,无需信用卡,运行三小时后关闭,这对于开发来说已经足够。生产环境运行在私有集群上,起步价大约为每 30 天 22 美元。完整套餐在价格页面上。
在你估算成本时,有一点值得注意:填充率直接驱动着你的托管账单。一个将 6 名玩家的对局送入 8 人服务器的配对系统在每一次对局中都会浪费容量,这就是为什么会话填充率是一个成本指标,而不仅仅是一个质量指标。
Unity 的配对系统 (Unity Gaming Services)
Unity Matchmaker 是基于规则的、现成的,直接存在于 Unity Dashboard 的 Multiplayer 部分,与 Relay、Lobby 和 Distributed Authority 并列。如果你已经在使用 Unity Gaming Services,这种便利性就是主要的吸引力:队列、票据流和玩家选择在与你其他服务相同的地方进行配置,且编辑器中内置了 SDK 支持。
Multiplay 游戏服务器托管此后已移至 Unity 之外,因此 Matchmaker 现在通过调用你正在使用的任何托管提供商的 Cloud Code 模块来分配服务器。
该教程逐步讲解了将 UGS Matchmaker 与 Edgegap 托管进行配对,这样你的對局配對规则保留在 Unity 中,同时服务器部署到最靠近每场对局的位置。
Heroic Labs 的 Nakama
Nakama 是一个开源游戏后端,涵盖身份验证、存储、社交功能、排行榜和实时多玩家游戏,對局配對作为其中一个组件。该服务器采用 Apache 2.0 许可,使用 Go 编写,并由 PostgreSQL 支持。
它的配对系统开箱即用地考虑了玩家技术和自定义属性,这使其成为比裸框架更完整的选择。它与用于 LiveOps 的 Satori 和用于元游戏系统的 Hiro 搭配使用。
Heroic Cloud 的规模基于配置的 Nakama CPU 和数据库 CPU,没有 DAU、MAU 或 CCU 限制,因此成本跟踪的是分配的资源,而不是玩家计数器。Heroic Cloud 上的 Satori 起价约为每月 600 美元,专用支持包的价格从每月 2,000 美元到 6,000 美元不等。自行托管在许可证条款上是免费的,但在运营方面绝对不是免费的,因为你拥有 Postgres 集群和每一次升级。
Nakama 和 Edgegap 已直接集成。Nakama 处理账户、對局配對和玩家数据,然后触发在对局中玩家的最佳位置在 Edgegap 上进行部署。从 Nakama 部署文档涵盖了 Heroic Cloud 和自行托管实例的插件设置。
Photon
Photon 是一个网络引擎和云平台,也是这里历史最悠久的选择之一。它的配对系统位于 REALTIME 层,该层也为 Fusion 和 Quantum 提供支持,并附带大厅功能、庞大的示例库和广泛的平台覆盖。
公共云定价从单应用 100 CCU 免费开始。付费阶段在 500 CCU 时大约为每月 125 美元,1,000 CCU 时为 250 美元,2,000 CCU 时为 500 美元,每个阶段都附带流量额度。Premium Cloud 基于使用量,大约为每 CCU 0.50 美元,每月最低消费接近 1,000 美元。
请仔细估算 CCU。账单基于各地区月度峰值的总和,超额流量单独计算,且低于 500 CCU 的方案是硬限制的,这意味着达到上限的玩家会被断开连接,而不会计费。
如果你在服务器模式下运行 Fusion,请注意你的 Photon 方案涵盖的是网络而不是机器。Photon 明确声明它不为专用的 Fusion 服务器应用程序提供托管服务,也不提供每个会话启动它们的编排。那是另一个提供商和另一笔单独的开支,并且它特定于 Fusion 的专用服务器拓扑,而不是 Quantum,后者的确定性模拟作为插件运行在 Photon 自身的云中。
Steamworks
Steamworks 对局配對仅限点对点(P2P),这是首先需要了解的一点。
在此限制下,它是可靠且免费的。它直接接入 Steam 的用户池,处理大厅创建和玩家组织,并为你解决 NAT 穿透问题。对于在 Steam 上发布且不需要权威服务器的游戏,它在开发省力程度上很难被超越。
如果你的游戏确实需要专用服务器,Steamworks 可以为你实现分组,但无法进行服务器分配。它也仅限 Steam,这在游戏机或移动设备进入计划的那一刻就将其排除在你的主要系统之外。一种常见的模式是使用 Steamworks Lobby 作为社交层,并将产生的分组交给一个独立的配对系统。
PlayFab
PlayFab 于 2018 年被微软收购,是一个包含對局配對和大厅管理的完整后端即服务(BaaS)。它的配对系统运行在 SmartMatch 上,该技术是 Xbox 网络配对背后的技术,支持基于票据流的技术、位置和自定义属性规则。
定价从免费开始,然后转向付费层,其上叠加有 Azure 使用成本,因此估算你的真实账单不仅仅是看一个数字。v1 和 v2 服务的划分仍然是文档中混淆的根源,并且一些开发者写下了围绕大厅和配对对等性的一些粗糙边缘。
如果你正在使用 PlayFab 對局配對并且在其下需要专用服务器,PlayFab Bridge 文档涵盖了设置:一个 Cloud Script 函数在 playfab.matchmaking.match_found 上触发并请求来自 Edgegap 的部署,从而让你的 API 令牌远离游戏客户端。
结论
这里不缺少选择,从融入到你引擎中的服务到你自己组装的开源框架。每一种选择对于某些团队来说都是合理的。
重要的是最终产生的结果。
具体来说,是两件事。更好的对局,意味着玩家基于连接质量和技术进行分组,而不是基于刚好在队列中的任何人。以及更低的托管成本,因为正如我们在会话填充率如何影响你的多玩家托管成本中所剖析的那样,一个能正确填充会话的配对系统是你在服务器账单上拥有的最大单一杠杆。
选择适合你技术栈的切入点。根据这两个结果来评判它。
—
价格和详情截至 2026.08.26。公布的方案定价经常变动,因此在制定预算前请向各厂商的价格页面进行核实。
书写者
加布里埃尔·帕伦特(总监)与雅库布·莫蒂尔(产品)










