Ctrlk
edgegap.comDashboard
discordlinkedin
For the complete documentation index, see llms.txt. This page is also available as Markdown.

深入了解

深入了解 Edgegap 无代码匹配器的概念，并根据需要进行自定义。

如果你需要帮助， 请通过 Discord 联系我们。关于实时游戏支持，请查看我们的 工单系统.

✔️ 介绍

基于对战的游戏中的匹配系统通常旨在：

  • 找到其他玩家 基于诸如区域、延迟、技术水平或游戏参数等条件；

  • 搜索服务器 根据可用容量[或延迟、区域、技术水平、地图、模式]加入；

  • 启动新服务器 如果现有服务器已满或不满足玩家条件。

玩家体验至上，定义我们的核心目标：

  • 高对局填充率和社交功能整合（与好友组队游戏），

  • 快速匹配且控制匹配质量（低延迟、共享偏好），

  • 可靠且可预测的匹配流程并具有全球可用性。

或者，让玩家 从列表中选择一个持久的（始终在线）服务器 带有 服务器浏览器.

5 分钟内即可开始，并免费测试所有功能，无需信用卡。

准备好后，升级以获得更强大、私有（专用）的集群。与 Edgegap 原生集成 部署 无论玩家位于哪里，都能提供一流的延迟（ping）。

免费层在每次重启后可运行 3 小时。你的匹配器将在共享基础设施上运行，资源有限，适合测试。 正式发布后，匹配器需要 24/7 运行。

每个匹配器都有三个核心概念：

  • 深入了解 - 底层服务器基础设施，由 Edgegap 完全托管和运营。

  • 深入了解 - 一组规则和设置，用于定义匹配器如何运作。

  • 🌐 服务实例 - 在集群上 24/7 运行的实时匹配服务，使用配置将玩家匹配在一起并生成部署（服务器）分配。

定期更新你的匹配器版本 以 利用新功能和错误修复。

▶️ 开始匹配

快速上手 - 将我们的 SDK 入门示例添加到你的游戏中:

了解匹配流程，以便自定义、排查问题并优化你的游戏集成：

匹配顺序

  1. 验证玩家身份 - 防止盗版拷贝联机游玩，

  2. 创建大厅 - 与你的朋友组队并共享玩家/匹配偏好，

  3. 组队 - 将你的大厅注册为一个匹配组，

  4. 寻找对局 - 准备就绪并开始寻找对局（新的或已有的），

    1. 分配服务器并注入票据 - 服务器会在几秒后自动分配，

  5. 连接并验证 - 尝试安全连接到游戏服务器，

    1. 确认身份 - 服务器使用第三方令牌验证游戏客户端的身份，

    2. 接受玩家或踢出玩家 - 服务器决定是否允许玩家加入。

验证

所有请求必须发送一个 Authorization（授权） HTTP 头并包含您的密钥 认证令牌：

请将您的令牌保密并妥善保存！Edgegap 员工绝不会向您索要令牌。

这个令牌可以安全地包含在你的游戏客户端中，因为它不会授予对 Edgegap API 的访问权限。

单个玩家可以通过其票据 ID 进行识别，该 ID 可在客户端和服务器上获取。可选地，借助自定义代理添加自定义身份验证或限制，并借助 服务器到服务器 API。

组队

创建组（队伍）可确保玩家与他们的朋友加入同一队伍和服务器。

创建一个已标记为准备好的组，以便 深入了解 快速地作为一名 没有组成员的单人玩家.

组生命周期活动图

大厅和组

如果你的游戏设计需要设置由玩家控制的匹配偏好（例如角色选择、难度、地图等），请使用大厅服务。随着玩家加入和离开大厅，他们也会更新匹配组，以便稍后寻找对局时做好准备。

没时间搭建大厅服务？ 引导玩家通过 Discord 或私信分享组 ID。

游戏设计 - 功能 / 需求
赛前大厅
匹配组

邀请朋友和我一起玩

✅

✅

修改我的玩家/匹配偏好

✅

❌

查看其他大厅成员偏好

✅

❌

存储和管理自定义键值数据

✅

❌

通知组成员我已准备好开始游戏

❌

✅

显示匹配进度并寻找对局

❌

✅

获取玩家/组的队伍分配

❌

✅

获取游戏服务器连接详细信息

❌

✅

我们的跨平台匹配器支持所有商用和自定义大厅服务：

大厅服务（第三方）
Unreal Engine
Unity
PC
主机
VR/XR
移动端

Epic Online Services 大厅 （Epic Games）

Steamworks 大厅 （Valve Corporation）

Nakama 组 （Heroic Labs）

Playfab 大厅 （Microsoft）

brainCloud 大厅 （bitHeads）

Gamekit 好友 （Apple）

自定义大厅 （你的公司）

大厅所有者（发送邀请的玩家）也必须创建匹配组。

将你组的 ID 存储在共享大厅数据中，这样其他大厅成员就可以轻松找到并加入与第三方大厅关联的匹配组。被邀请加入该组的玩家使用组 ID 来 创建他们的成员资格（加入），并 安全地存储他们的 匹配属性.

一旦组开始匹配，就不能再加入。 深入了解 并创建一个新的组。

延迟优化

如果 深入了解 包含 延迟 规则 所有组成员都会发送他们的 Ping 信标 测量值以 防止将来自遥远地区的玩家进行匹配 或者 ping（延迟）高得多/低得多的玩家。

放弃队列

组所有者可以删除该组，这会自动删除所有组成员资格。在匹配开始后删除组将取消所有成员资格，并在不久后将其删除。

组成员（除所有者外）可以在之前的任何时间删除他们的成员资格（离开组） 深入了解。之后删除成员资格将取消整个组的匹配。

一旦匹配被取消，成员将 自动退出匹配 并通过成员资格 status:CANCELLED 在其下一次状态轮询响应中收到通知。

一旦取消，如果组希望重新开始匹配，组所有者必须重新创建该组，将新的组 ID 分享给成员，并让他们重新创建各自的成员资格。

一旦找到对局，组就不能被删除 (409 冲突，并且会被 自动移除。你的服务器应留出一些时间（例如 60 秒）让玩家连接，然后再假定某个玩家已放弃。

如果你的服务器将某个玩家标记为已放弃，你可以：

  • 用 AI 角色替换离开的玩家，以立即开始比赛，

  • 或者创建一个 补位 来寻找新玩家替换离开的玩家，

  • 或者在你的游戏设计允许可变玩家人数时，不替换离开的玩家直接继续。

寻找对局

要开始寻找对局，所有成员和所有者都必须将自己标记为准备就绪。

为了让组所有者 立即开始匹配，请在创建时将成员资格标记为准备就绪。一旦所有者将自己标记为准备就绪，匹配就会开始，因为每个人都已准备好。

为了获得最佳体验， 使用游戏内 UI 向玩家提供状态更新.

所有玩家都必须定期轮询其成员资格 （建议 3-5 秒）以检测匹配何时开始，并通过游戏内 UI 传达匹配进度。

玩家应 持久保存其成员资格和组 ID，从而在游戏客户端崩溃时，他们可以重启游戏并继续，而不会丢失匹配进度。

一旦我们找到足够的玩家，使其能够按照你的 规则，玩家将在其成员资格响应中收到通知，内容为 status:TEAM_FOUND.

在此阶段删除成员资格将导致所有组成员资格被取消，并使分配到同一队伍的所有其他组返回到 status:SEARCHING .

队伍会继续使用其组中的重叠值与其他队伍进行匹配（或者在以下情况下使用平均值： number_difference ) status:MATCH_FOUND ，这意味着你的 部署正在启动.

匹配器旨在最大化匹配填充率，并且不会进入 MATCH_FOUND 直到满足以下任一条件：

  1. 足够多的队伍以配置的最大队伍人数完成匹配，

  2. 或者如果 深入了解 已定义并且扩展时间已到，并且足够多的队伍以配置的最小队伍人数完成匹配，

  3. 或者配置的票据过期时间已到，并且足够多的队伍以配置的最小队伍人数完成匹配。

如果在配置的票据过期前这两种情况都未成功，则组和票据将被取消。

在测试期间，或者当玩家位于不太热门的地区时，是否遇到较长的排队时间？请设置更短的票据过期时间（例如 30 秒），并在过期后在客户端重新创建组（或票据）。

每当一个组（或玩家）匹配到队伍时，票据过期时间会自动重置。

存储 team_id 和 match_id 在你的游戏后端中，以在游戏内显示队伍成员信息。

每位玩家都会获得一个 唯一的 Ticket ID，可用于 深入了解 与游戏服务器通信。

如果玩家已匹配并分配到游戏服务器，其票据会自动删除。玩家在以下之后放弃队列： status:HOST_ASSIGNED 可以被替换为 补位.

一旦玩家收到 status:HOST_ASSIGNED 他们将继续进行 深入了解.

连接到服务器

在找到匹配后几秒钟，匹配过程会继续到 如果玩家已被匹配并分配到游戏服务器，他们的票据会被自动删除。在 表示你的 部署现在已就绪并且你的游戏服务器正在初始化.

每个玩家读取他们的 ticket_id 和 assignment 并使用以下方式尝试连接 FQDN （部署 URL） 和 外部端口。此时你的游戏服务器可能仍在初始化，因此 玩家必须多次重试连接，直到超过你通常的服务器初始化时间：

要 从 PIE（编辑器）连接 在开发和测试期间，按下波浪号键 ~ 并输入 open {URL}:{port} 并等待你的编辑器加载地图。

要 从游戏客户端构建连接 （以及在生产线上）尝试

如果连接失败或出现黑屏，请查阅我们的 故障排除指南.

我们不要求玩家确认匹配，因为我们的目标是提供尽可能短的游戏开始时间、高匹配填充率，并尽量减少排队弃赛和匹配取消。

玩家应当 在游戏重启之间持久保存他们的分配 ID，以便在游戏客户端崩溃的情况下他们可以检索连接详情并尝试重新连接。

参见 匹配 以及我们带有自动重连功能等更多功能的 SDK。

补位匹配

可选地，某些游戏可能有特殊的匹配需求，例如：

  • 允许新玩家加入进行中的比赛（好友或“随机玩家”），

  • 在服务器启动后替换弃赛的玩家（离开者），以避免重启比赛，

  • 允许观众加入并观看锦标赛或好友比赛（电子竞技），

  • 将玩家集中到更大的服务器以提供更多社交互动（大型多人在线游戏）。

回填是一个 由服务器持有的票据，代表当前连接到服务器的玩家。 这可确保新加入的玩家在与当前玩家匹配时会遵守你的匹配规则。

深入了解 以替代 Seat/Match 会话。Matchmaker 仅支持默认会话。

回填场景可视化

回填忽略 player_count 规则，并且始终精确匹配一个组. backfill_group_size 使用轮询策略控制队伍容量，以受控方式均匀填充队伍。

完成成功回填的步骤如下：

  1. 服务器为每个缺少玩家的队伍创建一个回填，使用来自以下项的值：

    • 真实 分配 从以下位置检索的数据 注入变量 （部署）。

    • 当前连接玩家的 票据:

      • 来自 深入了解 （匹配器），先前回填的 assigned_ticket 响应，或为匹配特定玩家而操纵的模拟数据，

      • 替换 backfill_group_size 具有可能的组大小的值 最多到可用容量,

  2. 游戏客户端创建新的票据（成员资格）并包含 backfill_group_size 值：

    • "1" 如果玩家是单独进行匹配。

    • "2" 如果玩家是总共 2 人匹配组的一部分.

    • “new” 如果玩家启用了在加入进行中比赛之外也能开启新游戏。

  3. 游戏客户端继续 深入了解 并将玩家与匹配的回填配对。

  4. 如果回填的组没有完全填满队伍，服务器可以使用新回填玩家的票据重复此过程，以添加更多玩家并达到期望的队伍规模。

要创建仅回填的配置文件，请将 min_team_size 设置为 999,999 并禁用票据 + 票据匹配。

🥛 回填示例（回填展示）
🥛 回填分配示例（回填展示）

参见 镜像座位管理 和 FishNet 座位管理 用于 玩家连接监控.

一旦游戏服务器初始化完成， 你的服务器应:

  • 为每个新玩家启动放弃计时器。 我们建议使用加载场景/关卡向已连接玩家显示加载进度——可以是完整的 3D 场景、类似大厅的社交 UI，或带进度条的加载界面。

  • 持续跟踪新玩家连接或现有玩家随时间离开:

    1. 新玩家必须向服务器报告票据 ID，以便进行身份验证并将其连接映射到匹配器 深入了解 或 assigned_ticket （如果是补位）。

    2. 在服务器生命周期内，为未使用的玩家容量（离开者）创建新的补位。

    3. 为已过期的补位续期，这些补位会在 ticket_expiration_period.

  • 清理（删除）任何残留的补位 一旦 部署:

一旦就绪，部署会被分配一个 URL（ 服务器状态可能会丢失 注入的变量（Injected Variables） 游戏服务器通常需要额外信息，例如服务器 IP、内部端口值等。注入只读环境变量是传递参数的一种可靠且与云无关的方式。 获取变量值。

只要提供有效的服务器分配和至少一个票据，任何配置文件都可用于补位。参见 匹配 一个最小示例。

⚙️ 配置

匹配器 API 由你在创建新的（或快速重启的）匹配器时指定的 JSON 配置生成。你可以指定任意数量的配置文件，并为其设置不同的规则和扩展：

参见 匹配 查看我们的 SDK 和详细示例场景。

🍀 简单示例（最小推荐配置）
🏁 高级示例（完整示例配置）
🥛 回填配置示例
⚔️ 竞技游戏示例
🤝 合作游戏示例
🎈 社交游戏示例

编辑正在运行的匹配器会 触发快速重载，删除所有票据并导致短暂停机。

应用配置对于配置文件 XYZ 无效。
标签为 '2024.01.30-16.23.00-UTC' 的 Docker 镜像未被缓存。

🌟 升级到按需付费等级 以解锁 具有缓存的即时部署.

  • 4GB 以上未缓存的镜像可能需要更长时间部署，导致 部署。请考虑优化您的服务器镜像大小（虚幻引擎 / Unity).

  • 您仍然可以继续，但我们建议测试您的部署时间。

配置文件（队列）

配置文件代表完全独立的匹配队列，共享相同的匹配器版本。你可以 为每个匹配器配置任意数量的配置文件。 将你的玩家群体拆分到多个配置文件中，可能会导致玩家排队时间更长。

每个匹配器配置文件都使用一个 应用版本 作为启动新部署（服务器）的模板。

某些游戏模式可能需要更多 vCPU / RAM，尤其是在支持更多玩家时。每个 匹配器可能包含多个配置文件，每个都关联到一个经过资源调整的应用版本。

规则

每个玩家和组都会加入匹配队列，并使用 初始 规则开始匹配。

配置文件中路径 .rules.initial 中的每一项都代表一条规则，其中：

  • key 是一个字符串值，用于按你喜欢的方式命名规则；例如 match_size ，以及

  • value 是一个对象，用于定义规则的类型和属性，并遵循我们的标准规则集。

所有规则必须同时满足，才能启动主机分配并启动或查找部署。

运算符（规则类型）

player_count 是一条特殊规则，用于定义需要匹配多少玩家才能开始分配。

规则 player_count 是必需的，并且只能定义一次 在你的初始配置规则中。

匹配器始终努力最大化匹配填充率，直到指定的 max_team_size :

  1. 如果达到最大队伍人数，则立即生成匹配，

  2. 否则，玩家会在队列中等待以填满匹配，直到 扩展 （或过期）即将到来，

  3. 在……之前不久 扩展 （或过期）时，如果可以进行部分匹配（≥ 最小且 < 最大队伍人数），则将使用处于相同扩展阶段的所有玩家生成该匹配（假设其他规则通过）。

对于合作、自由混战或非对称队伍人数的游戏模式，请将你的 "team_count": 1 .

队伍数量可配置为为竞技游戏组成多个平衡队伍：

  • 组属性按平均值/重叠计算 基于组的 玩家属性，

  • 队伍属性按平均值/重叠计算 基于队伍的 组属性。

假设队伍固定为 4 名玩家：

示例匹配场景

组会在不超额填充的情况下匹配到队伍中， 前提是队伍有足够的容量容纳整个组。

字符串相等 匹配字符串值完全相同的玩家。

规则示例： selected_game_mode

selected_game_mode 规则将按大小写敏感方式匹配玩家：

✅ Alice + Bob + Dave 可能匹配，

❌ Alice + Erin，或 Charlie + Frank 将永远不会匹配。

"自由混战"
"夺旗"
"夺旗"

Alice

Erin

Frank

Bob

Charlie

Dave

number_difference 匹配彼此之间绝对数值差在范围内的玩家。

规则示例： elo_rating

elo_rating 上面的规则，配合 "max_difference": 50 最初：

✅ Alice + Bob 可能匹配，或 Bob + Charlie 可能匹配，

❌ Alice + Bob + Charlie 将永远不会匹配。

延迟 是一条特殊规则，用于优化玩家匹配的 ping：

  • 通过移除延迟高（超过阈值）的区域来降低客户端-服务器延迟，

  • 通过将延迟相近（差值低于指定值）的玩家分组来提高匹配公平性。

规则示例： 信标

信标 已配置为以下内容的规则 "difference": 100, "max_latency": 200 将匹配：

✅ Alice 和 Bob 可能匹配：

  • 东京被丢弃（>200 毫秒），

  • 芝加哥的延迟绝对差在 100 毫秒以内。

信标城市
匹配
abs(A - B) [毫秒]
Alice [毫秒]
Bob [毫秒]

芝加哥

✅

75.0

12.3

87.3

洛杉矶

❌

113.2 ❌

145.6

32.4

东京

不适用

不适用

233.2 ❌

253.2 ❌

❌ Alice 和 Charlie 永远不会匹配：

  • 没有任何信标对两位玩家都具有 < 200 毫秒的延迟，

  • Alice 住在北美 - 伊利诺伊州，

  • Charlie 住在亚洲 - 日本。

信标城市
匹配
abs(A - B) [毫秒]
Alice [毫秒]
Charlie [毫秒]

芝加哥

不适用

不适用

12.3

215.6 ❌

洛杉矶

不适用

不适用

145.6

238.3 ❌

东京

不适用

不适用

233.2 ❌

24.2

规则 延迟 是 可选，并且只能在你的初始配置中定义一次 规则。

一些玩家对所有信标的网络延迟很高，原因是 互联网服务提供商 问题或连接较慢（例如无线/移动）可能导致延迟并降低其他人的游戏体验。为缓解此问题：

  • 逐步扩大允许的最大延迟和差异（参见 高级示例配置),

    • 延迟高的玩家可能需要比平时更长时间才能找到匹配。

  • 或者，允许玩家通过手动区域选择来覆盖测量，只为玩家选择的区域发送伪造的延迟值（例如为快速匹配设置为25毫秒），

    • 这可能会对该玩家的队友和对手的游戏体验产生负面影响。

高信标延迟并不总是导致高服务器延迟。部署点比信标地点更多。信标会实时编排以优先考虑全球覆盖和可靠性。

参见 匹配 用于 使用我们的 SDK 进行自动化延迟测量.

信标会在实时中自动重新调整规模——添加/移除/替换现有信标。您的客户端和后端应考虑到这一点并 在每轮匹配之前重新加载信标列表.

交集 匹配具有一个或多个重叠字符串值的玩家，且区分大小写。

规则示例： selected_map

selected_map 上面的规则，配合 "overlap": 1 将匹配：

✅ Alice + Bob + Charlie 可能匹配，或 Alice + Bob + Dave 可能匹配，

❌ Alice + Bob + Charlie + Dave 将永远不会匹配。

规则扩展

可选地， 扩展 在队列中等待一段时间后修改规则属性，以放宽限制并扩大可匹配的玩家池， 从而加快匹配速度.

示例场景：扩展

最初，我们要求 1 支由恰好 4 名玩家组成的队伍（可能拆分为多个组） 包含：

  • 相对于同一个（任意一个）信标的最大 125 毫秒延迟，

  • 同一信标最低/最高值之间的延迟差不超过 125 毫秒，

  • 最低和最高排名玩家之间的技能评级差不超过 50 分，

  • 完全相同（区分大小写）的所选游戏模式，

  • 玩家之间至少有一个匹配的地图选择（区分大小写），

  • 至少有一个匹配的 补位组大小 玩家之间的值。

在上面的示例中，我们 通过修改属性来扩展搜索 之后：

30 秒：

  • 4 名玩家

  • 150 技能评级区间

  • 最大 250 毫秒延迟

60 秒：

  • 4 名玩家

  • 200 技能评级区间

  • 最大 250 毫秒延迟

3 分钟（180 秒）：

  • 1-4 名玩家

  • 200 技能评级区间

  • 任意延迟

任何规则属性的扩展都会 覆盖该属性的先前值 。

了解匹配中的常见陷阱，以及 使用我们的指南优化你的对局填充率.

📌 注入的变量

你的服务器可能需要知道有关其玩家的详细信息。玩家属性、已解析的对局值以及其他值会与常规部署一起注入到你的部署中 应用和版本.

预览未格式化内容 🏁 高级示例变量：

环境变量被 存储为字符串化的 JSON，请使用我们的 SDK 或自定义方法解析它们。

服务器可以将玩家连接映射到组和属性 在玩家将其票据 ID 发送到服务器之后。

🧵 玩家追踪

如果你的玩家遇到任何问题，追踪他们到服务器日志的路径会很有帮助。每个 Matchmaker 部署 都会标记分配的玩家票据 ID 这样你就可以轻松 部署 并找到 部署 以帮助你排查问题。

在客户端对战历史 UI 中显示票据 ID 和部署 ID 以便在排查问题时追踪玩家。

参见 部署 以了解部署故障排查。

👀 分析

无需代码或配置，即可深入了解你的 Matchmaker 负载和性能。

🌟 将 Matchmaker 升级到企业层级 以解锁匹配指标和洞察：

☁️ 托管集群

Matchmaker 由 Edgegap 便捷地全天候 24/7 托管和管理。

选择最适合你目标的托管方案：

  • 免费集群（共享） 用于测试所有功能并探索与您的设计的协同效应，

    • 会在 3 小时后自动关闭，需要重启才能继续测试。

  • 私有集群 （专用） 以确保为您的生产需求提供稳定的环境，

    • 选择您的区域并为实时游戏获得 24/7 支持，以便自信发布。

私有集群层级

我们目前提供 3 个私有集群等级 以满足每个人的需求：

等级
爱好者等级
工作室等级
企业等级

最适合用于

爱好者， 独立开发者

商业发布

高流量上线

资源

1 vCPU + 2GB 内存

6 vCPU + 12GB 内存

18 vCPU + 48GB 内存

冗余

1 个虚拟节点

3 个虚拟节点

3 个虚拟节点

限流（请求/秒）

200

750

2,000

价格，每小时

$0.0312

$0.146

$0.548

价格，30 天 （持续使用）

$22.464

$105.12

$394.56

一键升级到私有集群。在发布后无需任何玩家停机即可更改私有集群层级，也可以通过 ⏩ 滚动更新。托管集群为公开发布的游戏提供由 Edgegap 维护的高可用服务托管，并配有 24/7 实时支持。

你的实例资源需求取决于以下因素：

  • 玩家数量 - 玩家越多，票据和 API 请求就越多，

  • 每位玩家的请求数量 - 更快的重试会增加服务负载并消耗资源，

  • 配置复杂度 - 交集规则和扩展尤其耗费资源，

  • 平均对局时长 - 更短的会话会让玩家更频繁地重新加入匹配，

  • 过期和移除周期 - 过期票据会随着时间堆积并消耗资源，

  • 客户端重试回退逻辑 - 使用带抖动的退避重试有助于分散流量突发峰值。

为成功做好准备，并在发布后持续优化，这样你就不会在上线当天阻塞你的玩家。 使用 开发者工具 或 实现指数抖动退避 以从高负载中恢复。

我们的集群使用配备 AMD/Intel CPU 的云主机，主频为 2.4 - 3.2 GHz。

⏩ 滚动更新

跟踪服务器和客户端版本之间的兼容性可能会变得复杂。请遵循我们的建议，以实现可靠的发布、更新，并防止停机或兼容性问题。

重启后，你的 Matchmaker URL 和认证令牌将始终保持不变。

为开发和生产创建独立的 Matchmaker 环境，以便安全地进行实验。

⚠️ 上线前

我们建议提前创建多个 Matchmaker 副本： 绿色, 蓝色 和 橙色。在你发布更新时，可以轮换正在使用的 Matchmaker（蓝绿策略).

为每个实例选择不同区域，以防止停机 在局部故障期间。

蓝绿 DevOps 环境示例

🔃 客户端 + 服务器更新

前提条件： 本节假定你已完成 深入了解.

为了 发布游戏客户端 + 服务器更新，你可以：

  1. 准备新的服务器应用版本 v1.2.0-rc 在 Edgegap 上：

    1. 将新的镜像标签推送到你的容器注册表 t1.2.0,

    2. 创建新的应用版本 v1.2.0-rc,

  2. 通过以下方式执行任何开发测试： 部署你的新应用版本 v1.2.0-rc:

    1. 将你的游戏引擎编辑器连接到提供的 URL + 外部端口，

  3. 更新未使用的 Matchmaker 蓝色 以链接到你的新镜像标签 t1.2.0,

    1. 为新应用版本启用缓存 v1.2.0-rc ，为此版本启用缓存将确保该镜像也会被缓存到版本 v-blue 因为它们引用相同的标签，

    2. 等待版本中的缓存指示器 v1.2.0-rc 达到 🟢 绿色，

  4. 更新你的新游戏客户端 c2 以使用新版本 v-blue 在创建票据时：

    1. 在游戏客户端中更新你的基础 URL 和授权令牌，

  5. 对你的新游戏客户端执行 QA 测试和最终验证 c2:

    1. 如果你发现并解决了任何问题，请从头重复该流程，

    2. 在 Matchmaker 停止后等待 3-7 天，让 Matchmaker 的 DNS 更改传播到全球各地的 ISP（快速重启不需要 DNS 更新或等待期），

  6. 发布你的新游戏客户端更新 c2 在游戏分发平台上，

  7. 为新游戏客户端预留时间 c2 分发到玩家设备（通常最多需要 3-7 天）：

    1. 监控过时的游戏客户端 c1 使用部署 部署,

  8. 清理你 Edgegap 账户中的未使用资源：

    1. 删除镜像标签 t1.0.0 以释放容器注册表容量，

    2. 删除镜像标签 t1.1.0 以释放容器注册表容量，

    3. 关闭你的 绿色 Matchmaker，以暂停计费直到下一次更新。

在下一次更新时，提高版本号并交换 绿色 和 蓝色 指南中的关键字。

⚡ 服务器热修复

前提条件： 本节假定你已完成 深入了解.

为了 在不需要游戏客户端更新的情况下发布服务器补丁，你可以：

  1. 准备新的服务器应用版本 v1.2.0-rc 在 Edgegap 上：

    1. 将新的镜像标签推送到你的容器注册表 t1.2.0,

    2. 创建新的应用版本 v1.2.0-rc,

  2. 通过以下方式执行测试和验证： 部署你的新应用版本 v1.2.0-rc:

    1. 将你的游戏引擎编辑器连接到提供的 URL + 外部端口，

    2. 如果你发现并解决了任何问题，请从头重复该流程，

    3. 为新应用版本启用缓存 v1.2.0-rc ，为此版本启用缓存将确保该镜像也会被缓存到版本 v-green 稍后，因为它们将引用相同的标签，

    4. 等待版本中的缓存指示器 v1.2.0-rc 达到 🟢 绿色，

  3. 更新版本 v-green 以链接到你的新镜像标签 t1.2.0,

    1. 新的对局将自动使用更新后的标签开始分配 t1.2.0,

    2. 监控过时的游戏客户端 c1 使用部署 部署,

  4. 清理你 Edgegap 账户中的未使用资源：

    1. 删除镜像标签 t1.1.0 以释放容器注册表容量。

📗 API

客户端和服务器可以直接调用 API，或使用游戏引擎 SDK，另请参阅 匹配.

Unity/Android - 考虑 使用原始字符串插值 以防止对硬编码 JSON 的代码剥离。

Swagger Web UI：部署您的服务将生成一个 OpenAPI 规范和一个便捷的网页 UI。在浏览器中打开该 URL 以查看和测试所有 API 端点，并审查示例负载。

106KB
mm-conf-simple-example.json
打开

将 API 规范导入到 Scalar API Web 客户端 注入的变量（Injected Variables） Swagger 编辑器 以查看详细信息。

速率限制

为了保护你的集群不超过其突发容量并崩溃，我们根据内部负载测试限制每秒请求数，使用 匹配 配置。

API 端点
免费层级
业余爱好者层级
工作室层级
企业层级

总限制

100

200

750

2,000

创建部署

5

10

30

30

列出信标

10

20

75

200

创建组 + 创建票据 + 创建组票据

10

20

75

200

读取成员资格 + 读取组 + 读取票据

10

120

450

1,300

创建补位

5

10

37

100

速率限制以 对指定 API 端点集合的合并每秒请求数.

如果你的游戏客户端在收到响应后不重试请求 429 请求过多 你的部署可能会缺少玩家 在短时突发和流量高峰期间。

负载测试

在类似生产环境中进行负载测试会产生部署托管成本。请参见各层级对应的资源和价格 我们的定价页面.

使用 私有集群 用于压力测试。 免费实例严格仅限于开发测试。

在设计负载测试时， 请考虑真实的玩家行为模式:

真实场景
不现实的流量模式

✅ 玩家逐步加入游戏，在数小时内逐渐提升请求/秒。

❌ 所有玩家协调一致，在完全相同的一秒内访问 API。

✅ 玩家在重试之间等待的时间逐步增加（例如 1s-5s-10s-10s）。

❌ 所有玩家在收到后立即重试 429 请求过多 响应。

✅ 大多数玩家会在较短时间内（10-60 秒）收到分配并停止轮询。

❌ 所有玩家在收到分配后仍会继续轮询一段固定时间。

✅ 大多数玩家在重新开始新会话之前会先完成当前游戏（需要一些时间）。

❌ 所有玩家在收到服务器分配后立即重新开始新的会话。

✅ 峰值流量每天持续约 6 小时，之后部分时区的流量会下降。

❌ 峰值流量全天 24 小时持续，所有玩家日夜不停地玩。

负载下的行为

如果 Matchmaker 正在承受高负载：

  • 如果 CPU 被限频，匹配速度可能会变慢，

  • 如果 Matchmaker 内存耗尽，它会在不丢失票据信息的情况下重启，希望客户端实现指数退避，并将突发流量分散到更长时间内。

跨域资源共享（CORS）

对于托管在第三方分发平台上的 WebGL 游戏（例如 itch.io），从游戏客户端向 Matchmaker 发送任何请求可能会导致 跨域资源共享 策略违规。大多数现代网页浏览器会发送一个 预检请求 以验证后端服务（Matchmaker）是否理解并接受来自你的游戏客户端的通信。

未通过预检检查（出于安全原因默认如此）可能会导致 多种可能的 CORS 相关错误之一，最常见的是 缺少 CORS 头 'Access-Control-Allow-Origin' .

要解决此错误，请添加 allowed_cors_origin 参数到你的配置中，以便：

  • 将你的客户端托管域名精确列入白名单：

🍀 简单示例（特定域名示例）

  • 或者将通配符域名（包括所有子域）列入白名单：

🍀 简单示例（通配符域名示例）

如果域名配置正确，Matchmaker 的预检请求不需要凭据。

服务器到服务器

为匹配流程添加增强或自定义控制——使用我们的 托管集群 或任何云 FaaS 计算平台，以实现以下任一目标：

  • 附加敏感玩家属性——例如作弊标记、技能评级或类似信息，

  • 在游戏内提供队伍和对局上下文——在加载时列出我的队友和对手，

  • 限制特定边缘情况——例如，允许每名玩家在任意时刻仅有 1 个组，

  • 添加缓存或 API 速率限制——减少请求数量并降低 Matchmaker 负载，

  • 自定义大厅-组集成——在匹配前创建非对称/基于角色的大堂。

包含参数 player_ip 使用成员的公网 IP 地址 以确保尽可能最低的玩家延迟，并利用 部署.

游戏客户端可以使用 ipify.org 这个免费服务来查找其公网 IP。VPN 可能会掩盖公网 IP 地址。

服务器到服务器匹配活动图

🚨 故障排查

你的成功是我们的首要任务。 如果你想发送自定义请求、提出缺失的关键功能，或表达任何想法， 请在我们的社区 Discord 中联系我们.

应用配置对于配置文件 XYZ 无效。
标签为 '2024.01.30-16.23.00-UTC' 的 Docker 镜像未被缓存。

🌟 升级到按需付费等级 以解锁 具有缓存的即时部署.

  • 4GB 以上未缓存的镜像可能需要更长时间部署，导致 部署。请考虑优化您的服务器镜像大小（虚幻引擎 / Unity).

  • 您仍然可以继续，但我们建议测试您的部署时间。

为什么我在尝试创建新的 Matchmaker 时会出错？

  • 请阅读错误信息，你可能拼错了标识符、规则或运算符。- 使用 JSONLint 来验证你的 JSON 格式，你可能遗漏了逗号或括号。- 通过 我们的社区 Discord 寻求帮助，我们很乐意提供协助。🙏

为什么我的 Matchmaker 在 3 小时后自动关闭了？

  • 免费层级中的 Matchmaker 仅用于初始测试，并会在 3 小时后自动关闭。若要继续测试，你可以 重启你的 Matchmaker.

  • 考虑升级到付费层级以获得无限运行时间。

为什么我无法在我的账户上启动第二个部署？

  • 在免费层级中，你一次只能运行 1 个并发部署。

  • 请考虑升级到付费层级以获得无限部署。

为什么我会在随机时间收到分配/部署，而不考虑 player_count?

  • 你或其他团队成员可能在之前的测试会话中创建了尚未分配的票据。请 重启你的 Matchmaker.

我的票据卡在 SEARCHING .

  • 请确认你已根据配置创建了足够的匹配票据。

我的票据卡在在以下状态之间反复切换 MATCH_FOUND 和 TEAM_FOUND 。

  • 免费层级账户一次仅限 1 个部署。

  • 请考虑升级，或先停止当前部署再启动新的部署。

我的票据会直接进入 已取消.

  • 你的票据已到达其过期时间。请创建新票据，或在配置中增加过期时间用于测试。

我收到 HTTP 404 未找到 在查询我的票据时。

  • 你的票据已被 DELETE 请求删除，或者已到达其移除周期（在票据过期后开始，由你的配置定义）。请重新创建新票据，或在配置中增加过期/移除周期用于测试。

我的 Matchmaker 显示错误，我该怎么办？

🔖 更新日志

语义化版本控制

我们的开发者工具和托管服务使用官方 语义化版本控制，表明哪些更新是✅安全的（次要、补丁），哪些可能包含⚠️破坏性更改（主要）。

一旦某个版本发布，它将永远不会被修改/更改.

你的配置文件将根据所使用的 Matchmaker 版本进行验证，请确保你的规则与该 Matchmaker 版本的能力相匹配。

Matchmaker 的最新版本是 3.2.2。本页上的所有示例均为最新。

请留意 更新和公告。另请参阅 ⏩ 滚动更新.

要升级你的 Matchmaker 版本——停止、编辑、重启。 快速重启不会应用版本更改。

上一页匹配下一页服务器浏览器

最后更新于

这有帮助吗？