了解Edgegap的工作原理

了解Edgegap的工作原理

如何为多人 Roguelike 游戏添加匹配功能

已发布

已发布

已发布

如何为多人 Roguelike 游戏添加匹配功能

关键洞察

关键洞察

关键洞察

Edgegap 的 匹配系统 是一个完全托管、无限自定义的匹配系统,能够优化全球玩家的分组——在开发你的休闲多人游戏期间使用是免费的。

这也是我们所知道的 唯一 拥有 基于延迟的匹配规则 的匹配系统,能够为你的游戏提供理想的在线多人体验,无论使用何种引擎(Unity、Unreal 等)或游戏服务(EOS、UGS、PlayFab、Heroic Labs Nakama、Braincloud 等)。

由于我们的匹配系统基于参数,因此无需编写代码。集成非常简单,如果需要,我们的 入门指南 将在每一步中指导你。

当你的游戏上线时,由于我们的匹配系统是完全托管的,你无需处理基础设施、错误、停机、可扩展性或数据库管理。我们会为你处理所有的事情。将你的 DevOps 工作负载减少到几乎为零。

如何将匹配集成到您的多人 Roguelike 游戏中

-> 本文基于匹配文档。如果您遇到问题或差异,请务必参考原始指南,因为其更新更为频繁。

以下示例将帮助您测试核心匹配玩家流程,即:

  • 在共享的托管集群上创建匹配器实例,

  • 在匹配器配置中定义规则和设置,

  • 最后,使用我们的 API 测试玩家流程并管理玩家票据。

将我们的匹配器实施到游戏中分为五个步骤:

  1. 第一步是创建账户并使用我们的 Roguelike 游戏示例。瞧,您(在技术上)已经完成了一半!您只需要将匹配器集成到游戏中即可(参见步骤 5)。

  2. 现在,绝不应该盲目照搬在网上找到的 JSON 示例,因此强烈建议根据您的回合制游戏调整上述规则。步骤 2(“探索配置”)是我们的“阅读指南”,深入介绍了每项匹配规则的功能(“探索配置”)。

  3. 步骤 3(“查看实例详情”)涵盖了您个人特定的匹配器,以确保其已部署并符合您的游戏设计。

  4. 步骤 4,顾名思义(“4. 测试票据 API”),主要是测试匹配器是否收到了来自玩家的匹配请求,这些请求被称为票据。

  5. 步骤 5(“在游戏中集成匹配”)重点介绍了如何在您的引擎项目中集成匹配器。

如果您遇到疑难解答方面的挑战,我们深入的学习中心提供了更多疑难解答提示。

1. 设置免费层级

注册您的免费 Edgegap 账户,然后导航到 Matchmaker 仪表板页面。

在该页面中,先点击 Create Matchmaker,然后输入:

  • 匹配器的名称——这纯粹是为了方便您自己参考,例如 quickstart-dev,

  • 然后,为您的 Roguelike 游戏上传以下简单的 JSON 配置示例:

{
  "version": "2.1.0",
  "inspect": true,
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "custom-lobby-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 1,
              "team_size": 4
            }
          },
          "lobby_id": {
            "type": "string_equality"
          }
        },
        "expansions": {}
      }
    }
  }
}

(温馨提示:请务必修改应用程序 name 和 version,以匹配您的 应用程序和版本!)

如果没有出现验证错误,请点击 Create and Start 并等待该过程完成。这将启动一个新的免费集群,其中包含您的简单示例匹配器。

您现在可以继续进行下一步。

2. 探索配置​

独特的多人 Roguelike 游戏规则

自定义大厅(私人大厅、沙盒关卡)对于本地多人游戏非常受欢迎,同时也适用于在竞技或合作游戏的新功能进入主游戏模式之前对其进行测试。这些游戏通常需要最少的限制,但旨在确保玩家可以以组队方式加入。

补位票据可以使用自定义大厅配置文件来可靠地支持邀请好友,只要补位票据有效即可。

  • 提示:在其他配置文件之外,将 custom-lobby-example 配置文件添加到您的配置中,以支持自定义大厅。

语义化版本控制

随着我们发布 Matchmaker 的更新,每个新版本都使用 语义化版本控制 通过解释 主版本号.次版本号.修订号 格式来清晰传达更改的影响:

  • 主版本号 包含破坏性更改,需要进行集成审查,

  • 次版本号 包含重大的向后兼容改进,

  • 修订号 包含错误修复和微小改进。

某些 部署可能会导致错误。我们尝试通过自动重试部署最多 max_deployment_retry_count 次(无需客户端确认)来解决此问题。

为了确保意外的客户端崩溃或废弃的票据不会逗留并占用您的匹配器资源,票据将在 ticket_expiration_period 后被取消,导致其状态更改为 CANCELLED,然后在 ticket_removal_period 后被永久删除。

我们匹配逻辑的核心在 匹配配置文件中进行配置。每个配置文件都是一个完全隔离的匹配队列,指向具有预定义所需 CPU 和内存 (RAM) 资源的 应用版本。

初始规则集中的匹配规则必须得到满足才能将玩家分组在一起,每个规则由三个属性定义:

  • 您自选的名称,例如 - match size,

  • 规则类型,也称为运算符,例如 - player_count,

  • 最后是运算符属性,例如 team_count 或 team_size。

玩家数量规则

这是一条特殊规则,定义了需要匹配多少玩家才能发起分配:

  • team_count 指队伍数量,1 支队伍可用于合作或混战模式,

  • team_size 指每队玩家数量。

我们的简单示例展示了一个 2 名玩家的合作游戏。

请注意,“玩家数量”规则是必需的,并且只能在初始配置规则中定义一次。

延迟规则

使用此规则为所有玩家提供尽可能低的延迟。客户端测量并提交针对所有可用信标的往返时间 (ping) 后,Gen2 将仅考虑根据 Ping 信标测量的 ping 值在特定 difference 范围内的匹配。这提供了一种拆分玩家群体的“温和”解决方案,能够与邻近区域进行匹配,尤其可以提高人口较少区域的匹配速度。使用 max_latency 可以防止与距离较远的玩家进行匹配。

您现在可以继续进行下一步。

我们上面初始带有 "difference": 50, "max_latency": 200 的示例 beacons 规则:

  • Alice 和 Bob 将匹配,因为北京被丢弃(>200),其余部分都在 | A-B | < 50 范围内:

    • Alice {Montreal: 12.3, Newark: 45.6, Dallas: 59.9, Beijing: 264.4};以及

    • Bob {Montreal: 27.3, Newark: 32.4, Dallas: 23.1, Beijing: 252.2}。

  • Charlie 和 Dave 将不会匹配,因为达拉斯信标的 | C-D | > 50:

    • Alice {Montreal: 5.7 Newark: 44.2, Dallas: 59.5, Beijing: 263.2};以及

    • Bob {Montreal: 57.8, Newark: 32.0, Dallas: 24.2, Beijing: 272.3}。

请注意,“延迟规则”在初始配置规则中只能定义一次。

3. 查看实例详情​

初始化完成后,在我们的仪表板中查看新匹配器的详细信息:

Status 表示服务健康状况,可能是 ONLINE、OFFLINE 或 ERROR。

  • Identifier 可在您需要疑难解答帮助时帮助 Edgegap 员工快速找到您的匹配器。

  • Started at 可用于追踪最新的更新时间。

  • Size 对应我们的 定价层级之一。

  • API URL 将供游戏客户端和游戏服务器用于与 Gen2 进行通信。

  • Swagger URL 是我们提供的一个便捷的 openAPI 规范 GUI,用于探索 API 架构。

  • Auth Token 是游戏客户端和游戏服务器用于身份验证的唯一机密令牌。

要使用 API 测试新的匹配器,您将需要 Swagger URL、API URL 和 Auth Token。

您现在可以继续进行下一步。

4. 测试票据 API

首先,打开您的 Swagger URL 以在 Swagger GUI 中检查您的 openAPI 架构

点击“Matchmaker”标题下方的 /...swagger.json URL 以打开原始 JSON 架构:

将此页面作为文件保存到您的驱动器中 (CTRL/CMD+S)。

打开您的 Postman 应用程序 并登录您的免费账户。

从上一步导入您的 swagger.json 文件:

  • 保持选中 Postman Collection,

  • 选择 View Import Settings 并将设置 Parameter generation 更改为 Example。

确认导入,这将在左侧的集合列表中显示一个名为 Matchmaker 的新集合。

View more actions,打开标签页 Authorization 并选择:

  • Auth Type - API Key,

  • Key - “Authorization”

  • Value - 在此处插入您的 AuthToken 值,

  • Add to - Header。

按 (CTRL/CMD+S) 或保存图标以保存更改。Postman 标签页中的橙色圆点应该会消失。

在您的 Matchmaker 集合中,选择 tickets 并点击 Create a matchmaking ticket,打开一个新标签页。

选择标签页 Body 以预览您的玩家票据请求:

注意 player_ip 设置为 null——这将使用自动添加到请求中的 IP 地址(有关替代方案,请参见服务器到服务器集成),

  • profile 指您的匹配配置文件,

  • attributes 包括匹配器规则的值,在本例中为 latencies 规则,

    • 规则 player_count 是唯一不需要在玩家票据中包含任何属性的规则。

注意:请务必参考示例的 Swagger 导入配置。 

点击 Send 并查看对玩家票据请求的响应:

  • id 是您唯一的匹配票据 ID,请妥善保存以便稍后检查您的票据,

  • profile 确认所选的匹配配置文件,

  • group_id 是发放给每张票据的唯一组 ID,单人玩家表示为大小为 1 的组,

  • player_ip 是解析出的玩家公共 IP 地址,无论使用何种识别方法,

  • assignment 设置为 null,表示票据尚未匹配或分配到服务器,

  • created_at 提供有关玩家票据创建时间的信息,供游戏 UI 使用,

  • status 表示票据的当前状态,所有票据最初都处于 SEARCHING 状态(详见匹配流程)。

再次点击 Send 创建第二张票据,这样我们的两名玩家就能匹配并启动服务器。

在您的 Matchmaker 集合中,选择 {ticketId} 并点击 Read a matchmaking ticket。

输入上一步响应中的票据 ID,然后点击 Send。

查看玩家票据更新后的分配情况:

  • 状态首先更改为 MATCH_FOUND,同时保持 assignment 设置为 null,表示玩家已匹配,正在分配服务器,

再次点击 Send 以检查您的票据,并查看玩家票据更新后的分配情况:

  • 状态更改为 HOST_ASSIGNED,其中 assignment 包含分配的服务器的详细信息。

 在我们的仪表板中检查您的新部署:

  • 注意每个部署都标记有所有票据 ID 和配置文件,以增加可追溯性。

尝试从游戏客户端连接到分配的服务器。

验证能够毫无问题地连接到部署并完成测试后,停止您的部署,以释放账户中的容量用于下一次构建。

您现在可以继续进行下一步。

5. 在游戏中集成匹配器​

Edgegap 的匹配集成了:

  • 与游戏客户端,以管理玩家票据,

  • 与游戏服务器,以:

    • 处理通过其票据传递的玩家偏好,

    • (可选)支持补位以在启动后添加或替换玩家。

在游戏客户端中,我们建议在整个匹配流程中通过游戏内 UI 向玩家提供票据状态更新,以获得最佳玩家体验。参见:

在游戏客户端中,确保处理不可重试的错误:

  • HTTP 404 Not Found - 票据已被删除,

  • HTTP 500 Internal Server Error - 临时服务中断。

在游戏服务器中,处理玩家偏好和初始服务器上下文。无需 API 集成:

  1. 读取 注入的环境变量 (Gen2) 以检索初始玩家的匹配数据。

  2. 读取 注入的环境变量(应用版本) 以获取特定于版本的参数、设置(玩家容量)和机密信息。

  3. 读取 注入的环境变量(部署) 以获取部署信息,例如 IP 地址、位置等。

玩家连接后,游戏服务器和游戏客户端启动加载场景以执行同步步骤(例如选择并加载地图/场景/关卡)。我们建议使用功能齐备的 3D 场景、类似大厅的社交 UI 或带有进度条的加载屏幕,以指示初始化正在进行中。

游戏客户端完全加载后,玩家将加载/前往主游戏场景。

(可选)游戏服务器可以创建和管理补位和玩家容量(添加或替换离开的玩家)。

如果发生以下情况,请确保使用 注入的 DELETE_URL 正确停止部署:

  • 没有玩家加入比赛,

  • 所有玩家都已离开比赛,

  • 比赛正常结束。

恭喜,您已完成 Edgegap Matchmaker 集成!如果您想了解更多信息,请在我们的学习中心阅读全部相关内容。

如何将匹配集成到您的多人 Roguelike 游戏中

-> 本文基于匹配文档。如果您遇到问题或差异,请务必参考原始指南,因为其更新更为频繁。

以下示例将帮助您测试核心匹配玩家流程,即:

  • 在共享的托管集群上创建匹配器实例,

  • 在匹配器配置中定义规则和设置,

  • 最后,使用我们的 API 测试玩家流程并管理玩家票据。

将我们的匹配器实施到游戏中分为五个步骤:

  1. 第一步是创建账户并使用我们的 Roguelike 游戏示例。瞧,您(在技术上)已经完成了一半!您只需要将匹配器集成到游戏中即可(参见步骤 5)。

  2. 现在,绝不应该盲目照搬在网上找到的 JSON 示例,因此强烈建议根据您的回合制游戏调整上述规则。步骤 2(“探索配置”)是我们的“阅读指南”,深入介绍了每项匹配规则的功能(“探索配置”)。

  3. 步骤 3(“查看实例详情”)涵盖了您个人特定的匹配器,以确保其已部署并符合您的游戏设计。

  4. 步骤 4,顾名思义(“4. 测试票据 API”),主要是测试匹配器是否收到了来自玩家的匹配请求,这些请求被称为票据。

  5. 步骤 5(“在游戏中集成匹配”)重点介绍了如何在您的引擎项目中集成匹配器。

如果您遇到疑难解答方面的挑战,我们深入的学习中心提供了更多疑难解答提示。

1. 设置免费层级

注册您的免费 Edgegap 账户,然后导航到 Matchmaker 仪表板页面。

在该页面中,先点击 Create Matchmaker,然后输入:

  • 匹配器的名称——这纯粹是为了方便您自己参考,例如 quickstart-dev,

  • 然后,为您的 Roguelike 游戏上传以下简单的 JSON 配置示例:

{
  "version": "2.1.0",
  "inspect": true,
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "custom-lobby-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 1,
              "team_size": 4
            }
          },
          "lobby_id": {
            "type": "string_equality"
          }
        },
        "expansions": {}
      }
    }
  }
}

(温馨提示:请务必修改应用程序 name 和 version,以匹配您的 应用程序和版本!)

如果没有出现验证错误,请点击 Create and Start 并等待该过程完成。这将启动一个新的免费集群,其中包含您的简单示例匹配器。

您现在可以继续进行下一步。

2. 探索配置​

独特的多人 Roguelike 游戏规则

自定义大厅(私人大厅、沙盒关卡)对于本地多人游戏非常受欢迎,同时也适用于在竞技或合作游戏的新功能进入主游戏模式之前对其进行测试。这些游戏通常需要最少的限制,但旨在确保玩家可以以组队方式加入。

补位票据可以使用自定义大厅配置文件来可靠地支持邀请好友,只要补位票据有效即可。

  • 提示:在其他配置文件之外,将 custom-lobby-example 配置文件添加到您的配置中,以支持自定义大厅。

语义化版本控制

随着我们发布 Matchmaker 的更新,每个新版本都使用 语义化版本控制 通过解释 主版本号.次版本号.修订号 格式来清晰传达更改的影响:

  • 主版本号 包含破坏性更改,需要进行集成审查,

  • 次版本号 包含重大的向后兼容改进,

  • 修订号 包含错误修复和微小改进。

某些 部署可能会导致错误。我们尝试通过自动重试部署最多 max_deployment_retry_count 次(无需客户端确认)来解决此问题。

为了确保意外的客户端崩溃或废弃的票据不会逗留并占用您的匹配器资源,票据将在 ticket_expiration_period 后被取消,导致其状态更改为 CANCELLED,然后在 ticket_removal_period 后被永久删除。

我们匹配逻辑的核心在 匹配配置文件中进行配置。每个配置文件都是一个完全隔离的匹配队列,指向具有预定义所需 CPU 和内存 (RAM) 资源的 应用版本。

初始规则集中的匹配规则必须得到满足才能将玩家分组在一起,每个规则由三个属性定义:

  • 您自选的名称,例如 - match size,

  • 规则类型,也称为运算符,例如 - player_count,

  • 最后是运算符属性,例如 team_count 或 team_size。

玩家数量规则

这是一条特殊规则,定义了需要匹配多少玩家才能发起分配:

  • team_count 指队伍数量,1 支队伍可用于合作或混战模式,

  • team_size 指每队玩家数量。

我们的简单示例展示了一个 2 名玩家的合作游戏。

请注意,“玩家数量”规则是必需的,并且只能在初始配置规则中定义一次。

延迟规则

使用此规则为所有玩家提供尽可能低的延迟。客户端测量并提交针对所有可用信标的往返时间 (ping) 后,Gen2 将仅考虑根据 Ping 信标测量的 ping 值在特定 difference 范围内的匹配。这提供了一种拆分玩家群体的“温和”解决方案,能够与邻近区域进行匹配,尤其可以提高人口较少区域的匹配速度。使用 max_latency 可以防止与距离较远的玩家进行匹配。

您现在可以继续进行下一步。

我们上面初始带有 "difference": 50, "max_latency": 200 的示例 beacons 规则:

  • Alice 和 Bob 将匹配,因为北京被丢弃(>200),其余部分都在 | A-B | < 50 范围内:

    • Alice {Montreal: 12.3, Newark: 45.6, Dallas: 59.9, Beijing: 264.4};以及

    • Bob {Montreal: 27.3, Newark: 32.4, Dallas: 23.1, Beijing: 252.2}。

  • Charlie 和 Dave 将不会匹配,因为达拉斯信标的 | C-D | > 50:

    • Alice {Montreal: 5.7 Newark: 44.2, Dallas: 59.5, Beijing: 263.2};以及

    • Bob {Montreal: 57.8, Newark: 32.0, Dallas: 24.2, Beijing: 272.3}。

请注意,“延迟规则”在初始配置规则中只能定义一次。

3. 查看实例详情​

初始化完成后,在我们的仪表板中查看新匹配器的详细信息:

Status 表示服务健康状况,可能是 ONLINE、OFFLINE 或 ERROR。

  • Identifier 可在您需要疑难解答帮助时帮助 Edgegap 员工快速找到您的匹配器。

  • Started at 可用于追踪最新的更新时间。

  • Size 对应我们的 定价层级之一。

  • API URL 将供游戏客户端和游戏服务器用于与 Gen2 进行通信。

  • Swagger URL 是我们提供的一个便捷的 openAPI 规范 GUI,用于探索 API 架构。

  • Auth Token 是游戏客户端和游戏服务器用于身份验证的唯一机密令牌。

要使用 API 测试新的匹配器,您将需要 Swagger URL、API URL 和 Auth Token。

您现在可以继续进行下一步。

4. 测试票据 API

首先,打开您的 Swagger URL 以在 Swagger GUI 中检查您的 openAPI 架构

点击“Matchmaker”标题下方的 /...swagger.json URL 以打开原始 JSON 架构:

将此页面作为文件保存到您的驱动器中 (CTRL/CMD+S)。

打开您的 Postman 应用程序 并登录您的免费账户。

从上一步导入您的 swagger.json 文件:

  • 保持选中 Postman Collection,

  • 选择 View Import Settings 并将设置 Parameter generation 更改为 Example。

确认导入,这将在左侧的集合列表中显示一个名为 Matchmaker 的新集合。

View more actions,打开标签页 Authorization 并选择:

  • Auth Type - API Key,

  • Key - “Authorization”

  • Value - 在此处插入您的 AuthToken 值,

  • Add to - Header。

按 (CTRL/CMD+S) 或保存图标以保存更改。Postman 标签页中的橙色圆点应该会消失。

在您的 Matchmaker 集合中,选择 tickets 并点击 Create a matchmaking ticket,打开一个新标签页。

选择标签页 Body 以预览您的玩家票据请求:

注意 player_ip 设置为 null——这将使用自动添加到请求中的 IP 地址(有关替代方案,请参见服务器到服务器集成),

  • profile 指您的匹配配置文件,

  • attributes 包括匹配器规则的值,在本例中为 latencies 规则,

    • 规则 player_count 是唯一不需要在玩家票据中包含任何属性的规则。

注意:请务必参考示例的 Swagger 导入配置。 

点击 Send 并查看对玩家票据请求的响应:

  • id 是您唯一的匹配票据 ID,请妥善保存以便稍后检查您的票据,

  • profile 确认所选的匹配配置文件,

  • group_id 是发放给每张票据的唯一组 ID,单人玩家表示为大小为 1 的组,

  • player_ip 是解析出的玩家公共 IP 地址,无论使用何种识别方法,

  • assignment 设置为 null,表示票据尚未匹配或分配到服务器,

  • created_at 提供有关玩家票据创建时间的信息,供游戏 UI 使用,

  • status 表示票据的当前状态,所有票据最初都处于 SEARCHING 状态(详见匹配流程)。

再次点击 Send 创建第二张票据,这样我们的两名玩家就能匹配并启动服务器。

在您的 Matchmaker 集合中,选择 {ticketId} 并点击 Read a matchmaking ticket。

输入上一步响应中的票据 ID,然后点击 Send。

查看玩家票据更新后的分配情况:

  • 状态首先更改为 MATCH_FOUND,同时保持 assignment 设置为 null,表示玩家已匹配,正在分配服务器,

再次点击 Send 以检查您的票据,并查看玩家票据更新后的分配情况:

  • 状态更改为 HOST_ASSIGNED,其中 assignment 包含分配的服务器的详细信息。

 在我们的仪表板中检查您的新部署:

  • 注意每个部署都标记有所有票据 ID 和配置文件,以增加可追溯性。

尝试从游戏客户端连接到分配的服务器。

验证能够毫无问题地连接到部署并完成测试后,停止您的部署,以释放账户中的容量用于下一次构建。

您现在可以继续进行下一步。

5. 在游戏中集成匹配器​

Edgegap 的匹配集成了:

  • 与游戏客户端,以管理玩家票据,

  • 与游戏服务器,以:

    • 处理通过其票据传递的玩家偏好,

    • (可选)支持补位以在启动后添加或替换玩家。

在游戏客户端中,我们建议在整个匹配流程中通过游戏内 UI 向玩家提供票据状态更新,以获得最佳玩家体验。参见:

在游戏客户端中,确保处理不可重试的错误:

  • HTTP 404 Not Found - 票据已被删除,

  • HTTP 500 Internal Server Error - 临时服务中断。

在游戏服务器中,处理玩家偏好和初始服务器上下文。无需 API 集成:

  1. 读取 注入的环境变量 (Gen2) 以检索初始玩家的匹配数据。

  2. 读取 注入的环境变量(应用版本) 以获取特定于版本的参数、设置(玩家容量)和机密信息。

  3. 读取 注入的环境变量(部署) 以获取部署信息,例如 IP 地址、位置等。

玩家连接后,游戏服务器和游戏客户端启动加载场景以执行同步步骤(例如选择并加载地图/场景/关卡)。我们建议使用功能齐备的 3D 场景、类似大厅的社交 UI 或带有进度条的加载屏幕,以指示初始化正在进行中。

游戏客户端完全加载后,玩家将加载/前往主游戏场景。

(可选)游戏服务器可以创建和管理补位和玩家容量(添加或替换离开的玩家)。

如果发生以下情况,请确保使用 注入的 DELETE_URL 正确停止部署:

  • 没有玩家加入比赛,

  • 所有玩家都已离开比赛,

  • 比赛正常结束。

恭喜,您已完成 Edgegap Matchmaker 集成!如果您想了解更多信息,请在我们的学习中心阅读全部相关内容。

如何将匹配集成到您的多人 Roguelike 游戏中

-> 本文基于匹配文档。如果您遇到问题或差异,请务必参考原始指南,因为其更新更为频繁。

以下示例将帮助您测试核心匹配玩家流程,即:

  • 在共享的托管集群上创建匹配器实例,

  • 在匹配器配置中定义规则和设置,

  • 最后,使用我们的 API 测试玩家流程并管理玩家票据。

将我们的匹配器实施到游戏中分为五个步骤:

  1. 第一步是创建账户并使用我们的 Roguelike 游戏示例。瞧,您(在技术上)已经完成了一半!您只需要将匹配器集成到游戏中即可(参见步骤 5)。

  2. 现在,绝不应该盲目照搬在网上找到的 JSON 示例,因此强烈建议根据您的回合制游戏调整上述规则。步骤 2(“探索配置”)是我们的“阅读指南”,深入介绍了每项匹配规则的功能(“探索配置”)。

  3. 步骤 3(“查看实例详情”)涵盖了您个人特定的匹配器,以确保其已部署并符合您的游戏设计。

  4. 步骤 4,顾名思义(“4. 测试票据 API”),主要是测试匹配器是否收到了来自玩家的匹配请求,这些请求被称为票据。

  5. 步骤 5(“在游戏中集成匹配”)重点介绍了如何在您的引擎项目中集成匹配器。

如果您遇到疑难解答方面的挑战,我们深入的学习中心提供了更多疑难解答提示。

1. 设置免费层级

注册您的免费 Edgegap 账户,然后导航到 Matchmaker 仪表板页面。

在该页面中,先点击 Create Matchmaker,然后输入:

  • 匹配器的名称——这纯粹是为了方便您自己参考,例如 quickstart-dev,

  • 然后,为您的 Roguelike 游戏上传以下简单的 JSON 配置示例:

{
  "version": "2.1.0",
  "inspect": true,
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "custom-lobby-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 1,
              "team_size": 4
            }
          },
          "lobby_id": {
            "type": "string_equality"
          }
        },
        "expansions": {}
      }
    }
  }
}

(温馨提示:请务必修改应用程序 name 和 version,以匹配您的 应用程序和版本!)

如果没有出现验证错误,请点击 Create and Start 并等待该过程完成。这将启动一个新的免费集群,其中包含您的简单示例匹配器。

您现在可以继续进行下一步。

2. 探索配置​

独特的多人 Roguelike 游戏规则

自定义大厅(私人大厅、沙盒关卡)对于本地多人游戏非常受欢迎,同时也适用于在竞技或合作游戏的新功能进入主游戏模式之前对其进行测试。这些游戏通常需要最少的限制,但旨在确保玩家可以以组队方式加入。

补位票据可以使用自定义大厅配置文件来可靠地支持邀请好友,只要补位票据有效即可。

  • 提示:在其他配置文件之外,将 custom-lobby-example 配置文件添加到您的配置中,以支持自定义大厅。

语义化版本控制

随着我们发布 Matchmaker 的更新,每个新版本都使用 语义化版本控制 通过解释 主版本号.次版本号.修订号 格式来清晰传达更改的影响:

  • 主版本号 包含破坏性更改,需要进行集成审查,

  • 次版本号 包含重大的向后兼容改进,

  • 修订号 包含错误修复和微小改进。

某些 部署可能会导致错误。我们尝试通过自动重试部署最多 max_deployment_retry_count 次(无需客户端确认)来解决此问题。

为了确保意外的客户端崩溃或废弃的票据不会逗留并占用您的匹配器资源,票据将在 ticket_expiration_period 后被取消,导致其状态更改为 CANCELLED,然后在 ticket_removal_period 后被永久删除。

我们匹配逻辑的核心在 匹配配置文件中进行配置。每个配置文件都是一个完全隔离的匹配队列,指向具有预定义所需 CPU 和内存 (RAM) 资源的 应用版本。

初始规则集中的匹配规则必须得到满足才能将玩家分组在一起,每个规则由三个属性定义:

  • 您自选的名称,例如 - match size,

  • 规则类型,也称为运算符,例如 - player_count,

  • 最后是运算符属性,例如 team_count 或 team_size。

玩家数量规则

这是一条特殊规则,定义了需要匹配多少玩家才能发起分配:

  • team_count 指队伍数量,1 支队伍可用于合作或混战模式,

  • team_size 指每队玩家数量。

我们的简单示例展示了一个 2 名玩家的合作游戏。

请注意,“玩家数量”规则是必需的,并且只能在初始配置规则中定义一次。

延迟规则

使用此规则为所有玩家提供尽可能低的延迟。客户端测量并提交针对所有可用信标的往返时间 (ping) 后,Gen2 将仅考虑根据 Ping 信标测量的 ping 值在特定 difference 范围内的匹配。这提供了一种拆分玩家群体的“温和”解决方案,能够与邻近区域进行匹配,尤其可以提高人口较少区域的匹配速度。使用 max_latency 可以防止与距离较远的玩家进行匹配。

您现在可以继续进行下一步。

我们上面初始带有 "difference": 50, "max_latency": 200 的示例 beacons 规则:

  • Alice 和 Bob 将匹配,因为北京被丢弃(>200),其余部分都在 | A-B | < 50 范围内:

    • Alice {Montreal: 12.3, Newark: 45.6, Dallas: 59.9, Beijing: 264.4};以及

    • Bob {Montreal: 27.3, Newark: 32.4, Dallas: 23.1, Beijing: 252.2}。

  • Charlie 和 Dave 将不会匹配,因为达拉斯信标的 | C-D | > 50:

    • Alice {Montreal: 5.7 Newark: 44.2, Dallas: 59.5, Beijing: 263.2};以及

    • Bob {Montreal: 57.8, Newark: 32.0, Dallas: 24.2, Beijing: 272.3}。

请注意,“延迟规则”在初始配置规则中只能定义一次。

3. 查看实例详情​

初始化完成后,在我们的仪表板中查看新匹配器的详细信息:

Status 表示服务健康状况,可能是 ONLINE、OFFLINE 或 ERROR。

  • Identifier 可在您需要疑难解答帮助时帮助 Edgegap 员工快速找到您的匹配器。

  • Started at 可用于追踪最新的更新时间。

  • Size 对应我们的 定价层级之一。

  • API URL 将供游戏客户端和游戏服务器用于与 Gen2 进行通信。

  • Swagger URL 是我们提供的一个便捷的 openAPI 规范 GUI,用于探索 API 架构。

  • Auth Token 是游戏客户端和游戏服务器用于身份验证的唯一机密令牌。

要使用 API 测试新的匹配器,您将需要 Swagger URL、API URL 和 Auth Token。

您现在可以继续进行下一步。

4. 测试票据 API

首先,打开您的 Swagger URL 以在 Swagger GUI 中检查您的 openAPI 架构

点击“Matchmaker”标题下方的 /...swagger.json URL 以打开原始 JSON 架构:

将此页面作为文件保存到您的驱动器中 (CTRL/CMD+S)。

打开您的 Postman 应用程序 并登录您的免费账户。

从上一步导入您的 swagger.json 文件:

  • 保持选中 Postman Collection,

  • 选择 View Import Settings 并将设置 Parameter generation 更改为 Example。

确认导入,这将在左侧的集合列表中显示一个名为 Matchmaker 的新集合。

View more actions,打开标签页 Authorization 并选择:

  • Auth Type - API Key,

  • Key - “Authorization”

  • Value - 在此处插入您的 AuthToken 值,

  • Add to - Header。

按 (CTRL/CMD+S) 或保存图标以保存更改。Postman 标签页中的橙色圆点应该会消失。

在您的 Matchmaker 集合中,选择 tickets 并点击 Create a matchmaking ticket,打开一个新标签页。

选择标签页 Body 以预览您的玩家票据请求:

注意 player_ip 设置为 null——这将使用自动添加到请求中的 IP 地址(有关替代方案,请参见服务器到服务器集成),

  • profile 指您的匹配配置文件,

  • attributes 包括匹配器规则的值,在本例中为 latencies 规则,

    • 规则 player_count 是唯一不需要在玩家票据中包含任何属性的规则。

注意:请务必参考示例的 Swagger 导入配置。 

点击 Send 并查看对玩家票据请求的响应:

  • id 是您唯一的匹配票据 ID,请妥善保存以便稍后检查您的票据,

  • profile 确认所选的匹配配置文件,

  • group_id 是发放给每张票据的唯一组 ID,单人玩家表示为大小为 1 的组,

  • player_ip 是解析出的玩家公共 IP 地址,无论使用何种识别方法,

  • assignment 设置为 null,表示票据尚未匹配或分配到服务器,

  • created_at 提供有关玩家票据创建时间的信息,供游戏 UI 使用,

  • status 表示票据的当前状态,所有票据最初都处于 SEARCHING 状态(详见匹配流程)。

再次点击 Send 创建第二张票据,这样我们的两名玩家就能匹配并启动服务器。

在您的 Matchmaker 集合中,选择 {ticketId} 并点击 Read a matchmaking ticket。

输入上一步响应中的票据 ID,然后点击 Send。

查看玩家票据更新后的分配情况:

  • 状态首先更改为 MATCH_FOUND,同时保持 assignment 设置为 null,表示玩家已匹配,正在分配服务器,

再次点击 Send 以检查您的票据,并查看玩家票据更新后的分配情况:

  • 状态更改为 HOST_ASSIGNED,其中 assignment 包含分配的服务器的详细信息。

 在我们的仪表板中检查您的新部署:

  • 注意每个部署都标记有所有票据 ID 和配置文件,以增加可追溯性。

尝试从游戏客户端连接到分配的服务器。

验证能够毫无问题地连接到部署并完成测试后,停止您的部署,以释放账户中的容量用于下一次构建。

您现在可以继续进行下一步。

5. 在游戏中集成匹配器​

Edgegap 的匹配集成了:

  • 与游戏客户端,以管理玩家票据,

  • 与游戏服务器,以:

    • 处理通过其票据传递的玩家偏好,

    • (可选)支持补位以在启动后添加或替换玩家。

在游戏客户端中,我们建议在整个匹配流程中通过游戏内 UI 向玩家提供票据状态更新,以获得最佳玩家体验。参见:

在游戏客户端中,确保处理不可重试的错误:

  • HTTP 404 Not Found - 票据已被删除,

  • HTTP 500 Internal Server Error - 临时服务中断。

在游戏服务器中,处理玩家偏好和初始服务器上下文。无需 API 集成:

  1. 读取 注入的环境变量 (Gen2) 以检索初始玩家的匹配数据。

  2. 读取 注入的环境变量(应用版本) 以获取特定于版本的参数、设置(玩家容量)和机密信息。

  3. 读取 注入的环境变量(部署) 以获取部署信息,例如 IP 地址、位置等。

玩家连接后,游戏服务器和游戏客户端启动加载场景以执行同步步骤(例如选择并加载地图/场景/关卡)。我们建议使用功能齐备的 3D 场景、类似大厅的社交 UI 或带有进度条的加载屏幕,以指示初始化正在进行中。

游戏客户端完全加载后,玩家将加载/前往主游戏场景。

(可选)游戏服务器可以创建和管理补位和玩家容量(添加或替换离开的玩家)。

如果发生以下情况,请确保使用 注入的 DELETE_URL 正确停止部署:

  • 没有玩家加入比赛,

  • 所有玩家都已离开比赛,

  • 比赛正常结束。

恭喜,您已完成 Edgegap Matchmaker 集成!如果您想了解更多信息,请在我们的学习中心阅读全部相关内容。

如何将匹配集成到您的多人 Roguelike 游戏中

-> 本文基于匹配文档。如果您遇到问题或差异,请务必参考原始指南,因为其更新更为频繁。

以下示例将帮助您测试核心匹配玩家流程,即:

  • 在共享的托管集群上创建匹配器实例,

  • 在匹配器配置中定义规则和设置,

  • 最后,使用我们的 API 测试玩家流程并管理玩家票据。

将我们的匹配器实施到游戏中分为五个步骤:

  1. 第一步是创建账户并使用我们的 Roguelike 游戏示例。瞧,您(在技术上)已经完成了一半!您只需要将匹配器集成到游戏中即可(参见步骤 5)。

  2. 现在,绝不应该盲目照搬在网上找到的 JSON 示例,因此强烈建议根据您的回合制游戏调整上述规则。步骤 2(“探索配置”)是我们的“阅读指南”,深入介绍了每项匹配规则的功能(“探索配置”)。

  3. 步骤 3(“查看实例详情”)涵盖了您个人特定的匹配器,以确保其已部署并符合您的游戏设计。

  4. 步骤 4,顾名思义(“4. 测试票据 API”),主要是测试匹配器是否收到了来自玩家的匹配请求,这些请求被称为票据。

  5. 步骤 5(“在游戏中集成匹配”)重点介绍了如何在您的引擎项目中集成匹配器。

如果您遇到疑难解答方面的挑战,我们深入的学习中心提供了更多疑难解答提示。

1. 设置免费层级

注册您的免费 Edgegap 账户,然后导航到 Matchmaker 仪表板页面。

在该页面中,先点击 Create Matchmaker,然后输入:

  • 匹配器的名称——这纯粹是为了方便您自己参考,例如 quickstart-dev,

  • 然后,为您的 Roguelike 游戏上传以下简单的 JSON 配置示例:

{
  "version": "2.1.0",
  "inspect": true,
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "custom-lobby-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 1,
              "team_size": 4
            }
          },
          "lobby_id": {
            "type": "string_equality"
          }
        },
        "expansions": {}
      }
    }
  }
}

(温馨提示:请务必修改应用程序 name 和 version,以匹配您的 应用程序和版本!)

如果没有出现验证错误,请点击 Create and Start 并等待该过程完成。这将启动一个新的免费集群,其中包含您的简单示例匹配器。

您现在可以继续进行下一步。

2. 探索配置​

独特的多人 Roguelike 游戏规则

自定义大厅(私人大厅、沙盒关卡)对于本地多人游戏非常受欢迎,同时也适用于在竞技或合作游戏的新功能进入主游戏模式之前对其进行测试。这些游戏通常需要最少的限制,但旨在确保玩家可以以组队方式加入。

补位票据可以使用自定义大厅配置文件来可靠地支持邀请好友,只要补位票据有效即可。

  • 提示:在其他配置文件之外,将 custom-lobby-example 配置文件添加到您的配置中,以支持自定义大厅。

语义化版本控制

随着我们发布 Matchmaker 的更新,每个新版本都使用 语义化版本控制 通过解释 主版本号.次版本号.修订号 格式来清晰传达更改的影响:

  • 主版本号 包含破坏性更改,需要进行集成审查,

  • 次版本号 包含重大的向后兼容改进,

  • 修订号 包含错误修复和微小改进。

某些 部署可能会导致错误。我们尝试通过自动重试部署最多 max_deployment_retry_count 次(无需客户端确认)来解决此问题。

为了确保意外的客户端崩溃或废弃的票据不会逗留并占用您的匹配器资源,票据将在 ticket_expiration_period 后被取消,导致其状态更改为 CANCELLED,然后在 ticket_removal_period 后被永久删除。

我们匹配逻辑的核心在 匹配配置文件中进行配置。每个配置文件都是一个完全隔离的匹配队列,指向具有预定义所需 CPU 和内存 (RAM) 资源的 应用版本。

初始规则集中的匹配规则必须得到满足才能将玩家分组在一起,每个规则由三个属性定义:

  • 您自选的名称,例如 - match size,

  • 规则类型,也称为运算符,例如 - player_count,

  • 最后是运算符属性,例如 team_count 或 team_size。

玩家数量规则

这是一条特殊规则,定义了需要匹配多少玩家才能发起分配:

  • team_count 指队伍数量,1 支队伍可用于合作或混战模式,

  • team_size 指每队玩家数量。

我们的简单示例展示了一个 2 名玩家的合作游戏。

请注意,“玩家数量”规则是必需的,并且只能在初始配置规则中定义一次。

延迟规则

使用此规则为所有玩家提供尽可能低的延迟。客户端测量并提交针对所有可用信标的往返时间 (ping) 后,Gen2 将仅考虑根据 Ping 信标测量的 ping 值在特定 difference 范围内的匹配。这提供了一种拆分玩家群体的“温和”解决方案,能够与邻近区域进行匹配,尤其可以提高人口较少区域的匹配速度。使用 max_latency 可以防止与距离较远的玩家进行匹配。

您现在可以继续进行下一步。

我们上面初始带有 "difference": 50, "max_latency": 200 的示例 beacons 规则:

  • Alice 和 Bob 将匹配,因为北京被丢弃(>200),其余部分都在 | A-B | < 50 范围内:

    • Alice {Montreal: 12.3, Newark: 45.6, Dallas: 59.9, Beijing: 264.4};以及

    • Bob {Montreal: 27.3, Newark: 32.4, Dallas: 23.1, Beijing: 252.2}。

  • Charlie 和 Dave 将不会匹配,因为达拉斯信标的 | C-D | > 50:

    • Alice {Montreal: 5.7 Newark: 44.2, Dallas: 59.5, Beijing: 263.2};以及

    • Bob {Montreal: 57.8, Newark: 32.0, Dallas: 24.2, Beijing: 272.3}。

请注意,“延迟规则”在初始配置规则中只能定义一次。

3. 查看实例详情​

初始化完成后,在我们的仪表板中查看新匹配器的详细信息:

Status 表示服务健康状况,可能是 ONLINE、OFFLINE 或 ERROR。

  • Identifier 可在您需要疑难解答帮助时帮助 Edgegap 员工快速找到您的匹配器。

  • Started at 可用于追踪最新的更新时间。

  • Size 对应我们的 定价层级之一。

  • API URL 将供游戏客户端和游戏服务器用于与 Gen2 进行通信。

  • Swagger URL 是我们提供的一个便捷的 openAPI 规范 GUI,用于探索 API 架构。

  • Auth Token 是游戏客户端和游戏服务器用于身份验证的唯一机密令牌。

要使用 API 测试新的匹配器,您将需要 Swagger URL、API URL 和 Auth Token。

您现在可以继续进行下一步。

4. 测试票据 API

首先,打开您的 Swagger URL 以在 Swagger GUI 中检查您的 openAPI 架构

点击“Matchmaker”标题下方的 /...swagger.json URL 以打开原始 JSON 架构:

将此页面作为文件保存到您的驱动器中 (CTRL/CMD+S)。

打开您的 Postman 应用程序 并登录您的免费账户。

从上一步导入您的 swagger.json 文件:

  • 保持选中 Postman Collection,

  • 选择 View Import Settings 并将设置 Parameter generation 更改为 Example。

确认导入,这将在左侧的集合列表中显示一个名为 Matchmaker 的新集合。

View more actions,打开标签页 Authorization 并选择:

  • Auth Type - API Key,

  • Key - “Authorization”

  • Value - 在此处插入您的 AuthToken 值,

  • Add to - Header。

按 (CTRL/CMD+S) 或保存图标以保存更改。Postman 标签页中的橙色圆点应该会消失。

在您的 Matchmaker 集合中,选择 tickets 并点击 Create a matchmaking ticket,打开一个新标签页。

选择标签页 Body 以预览您的玩家票据请求:

注意 player_ip 设置为 null——这将使用自动添加到请求中的 IP 地址(有关替代方案,请参见服务器到服务器集成),

  • profile 指您的匹配配置文件,

  • attributes 包括匹配器规则的值,在本例中为 latencies 规则,

    • 规则 player_count 是唯一不需要在玩家票据中包含任何属性的规则。

注意:请务必参考示例的 Swagger 导入配置。 

点击 Send 并查看对玩家票据请求的响应:

  • id 是您唯一的匹配票据 ID,请妥善保存以便稍后检查您的票据,

  • profile 确认所选的匹配配置文件,

  • group_id 是发放给每张票据的唯一组 ID,单人玩家表示为大小为 1 的组,

  • player_ip 是解析出的玩家公共 IP 地址,无论使用何种识别方法,

  • assignment 设置为 null,表示票据尚未匹配或分配到服务器,

  • created_at 提供有关玩家票据创建时间的信息,供游戏 UI 使用,

  • status 表示票据的当前状态,所有票据最初都处于 SEARCHING 状态(详见匹配流程)。

再次点击 Send 创建第二张票据,这样我们的两名玩家就能匹配并启动服务器。

在您的 Matchmaker 集合中,选择 {ticketId} 并点击 Read a matchmaking ticket。

输入上一步响应中的票据 ID,然后点击 Send。

查看玩家票据更新后的分配情况:

  • 状态首先更改为 MATCH_FOUND,同时保持 assignment 设置为 null,表示玩家已匹配,正在分配服务器,

再次点击 Send 以检查您的票据,并查看玩家票据更新后的分配情况:

  • 状态更改为 HOST_ASSIGNED,其中 assignment 包含分配的服务器的详细信息。

 在我们的仪表板中检查您的新部署:

  • 注意每个部署都标记有所有票据 ID 和配置文件,以增加可追溯性。

尝试从游戏客户端连接到分配的服务器。

验证能够毫无问题地连接到部署并完成测试后,停止您的部署,以释放账户中的容量用于下一次构建。

您现在可以继续进行下一步。

5. 在游戏中集成匹配器​

Edgegap 的匹配集成了:

  • 与游戏客户端,以管理玩家票据,

  • 与游戏服务器,以:

    • 处理通过其票据传递的玩家偏好,

    • (可选)支持补位以在启动后添加或替换玩家。

在游戏客户端中,我们建议在整个匹配流程中通过游戏内 UI 向玩家提供票据状态更新,以获得最佳玩家体验。参见:

在游戏客户端中,确保处理不可重试的错误:

  • HTTP 404 Not Found - 票据已被删除,

  • HTTP 500 Internal Server Error - 临时服务中断。

在游戏服务器中,处理玩家偏好和初始服务器上下文。无需 API 集成:

  1. 读取 注入的环境变量 (Gen2) 以检索初始玩家的匹配数据。

  2. 读取 注入的环境变量(应用版本) 以获取特定于版本的参数、设置(玩家容量)和机密信息。

  3. 读取 注入的环境变量(部署) 以获取部署信息,例如 IP 地址、位置等。

玩家连接后,游戏服务器和游戏客户端启动加载场景以执行同步步骤(例如选择并加载地图/场景/关卡)。我们建议使用功能齐备的 3D 场景、类似大厅的社交 UI 或带有进度条的加载屏幕,以指示初始化正在进行中。

游戏客户端完全加载后,玩家将加载/前往主游戏场景。

(可选)游戏服务器可以创建和管理补位和玩家容量(添加或替换离开的玩家)。

如果发生以下情况,请确保使用 注入的 DELETE_URL 正确停止部署:

  • 没有玩家加入比赛,

  • 所有玩家都已离开比赛,

  • 比赛正常结束。

恭喜,您已完成 Edgegap Matchmaker 集成!如果您想了解更多信息,请在我们的学习中心阅读全部相关内容。

书写者

Edgegap团队

Get your Game Online Easily & in Minutes

立即开始集成!

轻松在线游戏
且在几分钟内

Get your Game Online Easily & in Minutes