如何将匹配系统集成到您的 PvE 多人游戏中

-> 本文基于 匹配系统文档编写。如果您遇到问题或不一致，请确保参考 原始指南，因为这些指南更经常更新。

以下示例将帮助您测试核心 匹配系统 玩家流程，即：

• 在共享的 托管集群 上创建匹配系统实例，

• 在您的匹配系统 配置 中定义规则和设置，

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

将我们的匹配系统实现到您的游戏中有 五个步骤：

1. 第一步是 创建一个帐户 并使用我们的 PvE 游戏示例。就这样，您已经（技术上）完成了一半！您只需在游戏中集成匹配系统（见第 5 步）。

2. 现在，您绝不应盲目跟随在互联网上找到的 JSON 示例，因此强烈建议根据您的回合制游戏修改上述规则。第 2 步（“探索配置”）是我们的“阅读方法”，讲述每个 匹配系统规则功能（“探索配置”）。

3. 第 3 步（“查看实例详情”）涵盖您的个人特定 匹配系统 以确保其已部署并与您游戏的设计配合。

4. 第 4 步，顾名思义（“4. 测试票务 API”），完全是关于测试玩家的匹配请求是否已被匹配系统接收，称为票务。

5. 第 5 步（“在您的游戏中集成匹配系统”）强调如何在您引擎的项目中集成匹配系统。

如果您遇到故障排除挑战，我们的深入 学习中心 提供额外的故障排除提示。

1. 设置免费层

注册您的免费 Edgegap 帐户，并导航至 匹配系统仪表板页面。

然后，首先点击 创建匹配系统 ，然后输入：

• 您的匹配系统名称 – 仅供您自己参考，例如 quickstart-dev，

• 然后，将以下简单示例作为 JSON 配置上传到您的 PvE 游戏：

{
  "version": "2.1.0",
  "inspect": true,
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "cooperative-example": {
      "application": {
        "name": "my-game-server=>CHANG-THIS-HERE",
        "version": "2024.01.30-16.23.00-UTC=>CHANG-THIS-HERE"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 1,
              "team_size": 4
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 60,
              "max_latency": 60
            }
          },
          "selected_map": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_difficulty": {
            "type": "string_equality"
          },
          "player_level": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 10
            }
          }
        },
        "expansions": {
          "5": {
            "beacons": {
              "difference": 80,
              "max_latency": 80
            }
          },
          "10": {
            "player_level": {
              "max_difference": 20
            }
          },
          "20": {
            "match_size": {
              "team_count": 1,
              "team_size": 3
            },
            "beacons": {
              "difference": 100,
              "max_latency": 100
            }
          },
          "30": {
            "match_size": {
              "team_count": 1,
              "team_size": 2
            },
            "beacons": {
              "max_latency": 200
            }
          },
          "60": {
            "match_size": {
              "team_count": 1,
              "team_size": 1
            }
          }
        }
      }
    }
  }
}

(善意提醒，请确保更改应用程序 name 和 version 以匹配您的 应用程序和版本！)

如果没有出现验证错误，点击 创建并启动 并等待过程完成。这将导致一个新的免费集群启动，带有您的简单示例匹配系统。

您可以继续下一步。

2. 探索配置​

独特的多人 PvE 游戏规则

特别针对 PvE 游戏，您可以定义多个 匹配系统个人资料 用于特定模式的规则和设置：

• 让玩家提供他们的地图偏好并选择适合所有人的地图，

• 让玩家选择适合每个人技能水平的特定游戏难度，

• 限制玩家等级差异，以便将拥有相似游戏进度的玩家进行匹配，

• 以小组身份加入 以便填写预设大厅或填补不超过团队规模的团队，

• 允许更高的延迟以优先考虑更快的匹配和更好的细粒度玩家偏好，

• 在允许更多玩家时，使用不同的 🏷️ 应用版本 分配更多的 CPU 或内存。

从理想条件开始，并且 扩展限制 以确保快速匹配：

• 随着时间的推移放宽延迟限制以找到更多玩家，

• 逐步减少团队规模以要求更少的玩家并尽快开始游戏，

  • 可选择性地，您可以让服务器用人工智能队友填补空缺位置，

• 逐步增加允许的玩家等级差异以便找到更多玩家，

• 如果没有找到队友，单独启动游戏并使用 补位 稍后添加玩家。

语义版本控制

当我们发布匹配系统的更新时，每个新版本使用 语义版本控制 通过解释格式 major.minor.patch 来清楚地传达更改的影响：

• major 版本包括重大更改并需要集成审核，

• minor 版本包括重大向后兼容的改进，

• patch 版本包括错误修复和小改进。

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

为了确保意外的客户端崩溃或废弃的票务不再滞留并占用您的匹配系统资源，票务将在 ticket_expiration_period 后被取消，状态将更改为 CANCELLED ，然后在 ticket_removal_period 后永久删除。

我们的匹配逻辑核心配置在 匹配系统个人资料中。每个个人资料都是一个完全隔离的匹配队列，指向 应用版本 ，并预定义所需的 CPU 和内存（RAM）资源数量。

匹配规则 在初始规则集中的所有规则必须满足，且各规则由三个属性定义：

• 您选择的名称，例如 - 匹配规模，

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

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

玩家数量规则

这是一个特殊规则，定义有多少玩家需要匹配以启动分配：

• team_count 指的是团队的数量，1个团队可以用于合作或自由竞技模式，

• team_size 指的是 每个团队的玩家数量。

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

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

延迟规则

使用此规则为所有玩家提供最低的延迟。客户端在测量并提交与所有可用信标的往返时间（延迟）后，Gen2 将仅考虑在与 延迟信标 测量的延迟值中，特定 difference 的匹配。这提供了一种“软”解决方案，通过与邻近区域匹配来拆分您的玩家基础，特别针对人口稀少的区域，可以提高匹配速度。使用 max_latency来防止与远离的玩家匹配。

您可以继续下一步。

我们上面的 信标 规则与 "difference": 50, "max_latency": 200 初始情况下：

• Alice 和 Bob 将匹配，因为北京被丢弃（>200），其余在 | A-B | < 50 之内：

  • Alice {Montreal: 12.3, Newark: 45.6, Dallas: 59.9, 北京: 264.4}; 和

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

• Charlie 和 Dave 将不匹配，因为 | C-D | > 50 对于达拉斯信标：

  • Alice {Montreal: 5.7 Newark: 44.2, Dallas: 59.5, 北京: 263.2}; 和

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

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

3. 查看实例详情​

在仪表板中查看新匹配系统的详细信息，直到其初始化：

状态 表示服务健康状况，可能为在线、离线或错误。

• 标识符 帮助 Edgegap 员工在您需要故障排除时快速找到您的匹配系统。

• 启动于 可以帮助跟踪最新的更新时间。

• 大小 对应于我们的 定价层之一。

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

• Swagger URL 是我们提供的方便的 openAPI 规范 GUI，用于探索 API 架构。

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

要使用 API 测试您的新匹配系统， 您将需要 Swagger URL、API URL 和授权令牌。

您可以继续下一步。

4. 测试票务 API

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

单击“匹配系统”标题下的 /...swagger.json URL 以打开原始 JSON 架构：

将此页面保存为文件到您的驱动器（CTRL/CMD+S）。

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

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

• 继续保留 Postman 集合 选中，

• 选择 查看导入设置 并将设置 参数生成 更改为 示例。

确认导入，这将导致新的集合出现在左侧的集合列表中，标题为“匹配系统”。

查看更多操作，打开 授权 选项卡并选择：

• 授权类型 - API 密钥，

• 密钥 - “授权”

• 值 - 在此处插入您的 AuthToken 值，

• 添加到 - 标头。

按(CTRL/CMD+S)或保存图标来 保存更改。您 Postman 标签中的橙色点应消失。

在您的匹配系统集合中，选择 票务 并 创建匹配票务 ，打开一个新选项卡。

选择 正文 选项卡来预览您的 玩家票务请求：

注意 player_ip 设置为 null - 这将导致使用自动添加到您的请求中的 IP 地址（请参见 服务器与服务器集成 以获取替代方案），

• profile 指的是您的 匹配系统个人资料，

• attributes 包括您的匹配系统规则的值，在这种情况下是 latencies 规则，

  • 规则 player_count 是唯一不需要任何属性的玩家票务。

注意：请确保参考示例的 Swagger 导入配置。

单击 发送 并查看您玩家票务请求的响应：

• id 是您的唯一匹配票务 ID，请保留此值以便后续查询您的票务，

• profile 确认选择的 匹配系统个人资料，

• group_id 是分配给每个票务的唯一组 ID，一名单独的玩家表示为一个组，

  • 请参见 以小组身份加入 与您的朋友或大厅进行匹配，

• player_ip 是玩家的公用 IP 地址，无论采用何种身份识别方法，

• assignment 设置为 null 以指示该票务尚未匹配或分配到服务器，

• created_at 提供有关玩家票务创建时间的信息，供游戏用户界面使用，

• status 表示票务的当前状态，所有票务开始时处于 SEARCHING 状态（请参阅 匹配流程 获取详细信息）。

通过再次点击 发送 创建第二张票务，以便我们的两名玩家可以进行匹配并启动服务器。

在您的匹配系统集合中，选择 {ticketId} 并 读取匹配票务。

在前一步的响应中输入票务 ID 并单击 发送。

查看您的玩家票务的更新分配：

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

再次点击 发送 来检查您的票务，并查看您的玩家票务的更新分配：

• 状态更改为 HOST_ASSIGNED ，并且 assignment 包含所分配服务器的详细信息。

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

• 请注意，每个部署都标记着所有票务 ID 和个人资料，以增加可追溯性。

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

一旦您确认能够无问题地连接到您的部署并完成测试， 停止您的部署 以便释放您的帐户中的容量以供下一个构建使用。

您可以继续下一步。

5. 在您的游戏中集成匹配系统​

Edgegap 的匹配系统集成：

• 与 游戏客户端集成，以管理 玩家票务，

• 与 游戏服务器集成，以：

  • 处理通过票务传递的玩家偏好，

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

在 游戏客户端中，我们建议在整个 匹配流程 中为玩家提供票务状态更新，使用游戏内部用户界面以获得最佳玩家体验。参见：

• Edgegap - Unity Gen2 匹配开发包，

  • 导入简单示例 并根据您的需求进行自定义，

• Betide Studio - 虚幻引擎 Edgegap 集成工具包，

  • 下载示例项目 并根据您的需求进行自定义。

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

• HTTP 404 未找到 - 票务已被删除，

• HTTP 500 内部服务器错误 - 临时服务中断。

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

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

2. 读取 注入环境变量（应用版本） 以获取特定版本的参数、设置（玩家容纳量）和机密。

3. 读取 注入环境变量（部署） 以获取部署信息，例如 IP 地址、位置等。

一旦玩家连接， 游戏服务器和游戏客户端 启动加载场景以执行同步步骤（例如选择和加载地图/场景/关卡）。我们建议一个完整的 3D 场景、一个大厅式的社交用户界面或一个带进度条的加载屏幕，以指示初始化进展。

一旦 游戏客户端 完全加载，玩家将加载/旅行到主要游戏场景。

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

确保您的 部署将被正确停止 ，使用 注入的 DELETE_URL，如果：

• 没有玩家加入比赛，

• 所有玩家已经离开比赛，

• 比赛正确结束。

恭喜，您已完成 Edgegap 匹配系统集成！如果您想了解更多，请在我们的 学习中心中阅读更多。