> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # 在 Partner Center 中配置匹配 > 为 XBOX 游戏在 Partner Center 中配置 SmartMatch 匹配，包括会话模板、hopper 规则以及用于兼容玩家匹配的团队规则。 本主题介绍如何配置 Partner Center 以选择兼容的玩家。 [SmartMatch 匹配运行时操作的配置](#SmartMatch-config) [在 SmartMatch 配置期间定义团队规则](#SmartMatch-defining) ## SmartMatch 匹配运行时操作的配置 所有 SmartMatch 匹配配置都通过 [Partner Center](https://partner.microsoft.com/dashboard) 完成。 ### 匹配会话模板配置 匹配有两种相关的会话类型。 * *匹配票据会话*，是匹配服务的输入 * *匹配目标会话*，是输出 配置会话模板时，应为每种会话类型创建一个模板。 对于票据会话，您可以使用专用模板。 或者，您可以重用大厅会话或其他不用于游戏玩法的会话的模板。 票据会话不得启用服务质量 (QoS) 检查，也不得标记为"gameplay"能力。 对于目标会话，您必须使用为匹配游戏玩法而设计的模板。 它应具有在游戏开始之前启用对等端之间 QoS 检查的设置，并且必须标记为"gameplay"能力。 通过 Partner Center 的配置 UI，您可以将每个会话映射到一个或多个 hopper，每个 hopper 都包含决定该 hopper 中会话如何匹配的规则。 有关详细信息，请参见下面的"匹配基本 hopper 配置"。 ### 匹配基本 hopper 配置 本节定义用于配置基本 hopper 字段的字段。 完成此配置后，您必须配置 hopper 规则，如本主题稍后的"hopper 规则配置"部分所述。以下屏幕截图显示了 hopper 编辑器。它将在以下部分中进行描述。 Screenshot that shows the hopper editor #### 名称 将会话提交到匹配时使用的 hopper 名称。 此名称必须与创建匹配票据时传递给 [XblMatchmakingCreateMatchTicketAsync](/reference/live/xsapi-c/matchmaking_c/functions/xblmatchmakingcreatematchticketasync) 方法的参数值匹配。 #### 最小/最大群组大小 从 hopper 中的会话创建的玩家群组的最小和最大大小。 匹配服务尝试创建尽可能大的匹配群组，最大不超过最大群组大小。 但是，如果它可以聚集足够多的玩家以满足最小群组大小，它就会创建匹配群组。 #### SHOULD 规则扩展周期 对于 SHOULD 规则，如果未找到成功的匹配，匹配服务会尝试随时间扩大搜索空间并放宽提供的匹配规则。 此过程在多个周期内执行，如使用 SHOULD 规则扩展周期字段所指定。 在最后一个扩展周期后，SHOULD 规则将被丢弃，以便它们不再阻止票据进行匹配。 但是，如果有多个票据可用，它们仍用于确定最佳匹配。 仅在丢弃之前扩展数字和 QoS 类型。 有关详细信息，请参见本主题稍后的"hopper 规则配置"部分。 增加 SHOULD 规则扩展周期设置的值可为 SHOULD 规则扩展提供更多周期。但是，这种增加还会增加匹配持续时间。 默认值为 3，通常足以满足大多数配置。 扩展周期以五秒的固定时间间隔发生。在最后一个扩展周期之后，所有 SHOULD 规则将不再被考虑用于匹配尝试的剩余部分。 #### 排名 hopper 通常，SmartMatch 防止被屏蔽的玩家被匹配。 如果选择了排名 hopper，则会绕过此逻辑，以防止玩家使用此系统来避免与技能更高的玩家匹配。 ### hopper 规则配置 本节定义用于为 hopper 配置规则的字段。 #### 通用规则字段 本节定义的字段是所有 hopper 规则的通用字段。 * **规则名称：** 出于配置目的显示的规则的友好名称。 * **规则类型：** 规则类型。选项为 MUST 和 SHOULD。 * MUST 规则必须满足才能成功匹配。 * SHOULD 规则可以放宽或删除以找到成功的匹配。 有关此过程的更多详细信息，请参见本主题前面的"Should 规则扩展周期"部分。 * **数据类型：** 匹配规则属性的数据类型。 可能的值如下。 * **Number：** 指定一个简单的 32 位数值。 * **String：** 指定一个最多 128 个字符的 Unicode 字符串。 * **Collection：** 指定一个字符串数组。使用此值可标识可下载内容 (DLC)、队伍成员身份或玩家的角色偏好。 * **Quality of Service：** 指定一种自定义数据类型，用于在匹配中包含延迟 QoS 数据。每个匹配 hopper 只应使用一条此类规则。 > \[!NOTE] > 如果此限制对您的游戏有问题，请联系您的开发者客户经理 (DAM)。 * **Total Value：** 指定一种自定义数据类型，用于汇总提交的匹配值。您可以使用此值来确保结果总和在特定范围内或是一个确切值。 * **Team：** 指定一种自定义数据类型，用于匹配请求中包含的玩家队伍。您可以使用此值来避免在单个匹配票据中将玩家分成多个队伍。 #### 数据类型特定的规则字段 本节定义适用于某些数据类型但不适用于其他数据类型的规则字段。UI 应能够阐明哪些数据类型适用于特定规则。 * **允许通配符：** 一个值，指示是否可以在匹配票据中省略该属性。 如果省略，则票据将与任何其他票据兼容，无论此属性的值如何。 * **属性来源：** 数据类型值的来源。可能的来源如下。 * **游戏提供：** 数据值在匹配票据中提交。 * **用户统计实例：** 数据值自动从 `UserStatistics` 服务中检索。 * **属性名称：** 属性值来源的名称。 它可以是匹配票据中的属性名称，也可以是用户统计的名称。 * **默认值：** 如果匹配请求未指定或不可用值，则数据类型的默认值。 如果选择了"允许通配符"字段且未指定值，则不应用默认值。 * **权重：** 规则的重要性。 权重可用于指示哪些规则在匹配和规则扩展期间被优先考虑。 权重值必须为正数，默认为 1。 * **扁平化方法：** 仅限 Number 数据类型。 一个值，指示如何组合多个值以满足匹配。 它适用于单个匹配票据中不同玩家的多个值，以及跨多个票据的多个值。可能的值如下。 * **最小/最大：** 使用来自不同匹配票据的多个值中的最小或最大值。 * **平均：** 使用来自不同匹配票据的多个值的平均值。 * **最大差异：** 仅限 Number 数据类型。 两个比较值之间可接受的最大数值差异，以满足规则。对于 SHOULD 规则，此值是规则扩展的起点。 * **集合操作：** 仅限 Collection 数据类型。 匹配集合值组时要执行的操作。可能的选项如下。 * **交集：** 根据两个集合之间的交集数量匹配它们。此设置会产生相似或相同的集合值。 * **差集：** 根据两个集合之间的差集数量匹配它们。 * **角色偏好：** 根据基于角色的游戏模式中玩家角色的偏好匹配集合。 * **目标交集：** 集合操作配置的一部分。 两个集合在匹配之前的最小交集或最大差集。 * **网络拓扑：** 仅限 Quality of Service 数据类型。 用于 QoS 的网络拓扑。 可能的值为 Peer to Peer、Peer to Host 和 Client/Server。 * **最大延迟/扩展最大值：** 仅限 Quality of Service 数据类型。 在指定网络拓扑内成功匹配的最大延迟。 使用 Client/Server Quality of Service SHOULD 规则时，此值被视为扩展值（而不是所需的延迟）。 > \[!NOTE] > 此外，默认信誉规则也适用于 hopper。这些规则无法删除，用于确保在匹配期间正确处理信誉。 * **允许等待角色：** 仅限 Collection Role Preferences 数据类型。 指定匹配服务是否保留匹配票据以填充所有可用角色。 #### 扩展增量 指示每次扩展代数时放宽提交规则的程度的值。 扩展增量在最大差异值之外应用。 有关详细信息，请参见本主题稍后的示例 1（规则扩展）。 您还可以使用扩展增量以不同的速度扩展多个数字值。 这通过扩展周期配置设置无法实现，因为它适用于所有规则。 相反，该方法是使用十进制扩展值；例如 0.4。 仅当达到新整数时才发生扩展，即使对于相同数量的扩展周期，也能实现不同的扩展速度。 #### QoS 扩展（对等到对等、对等到主机） 对于对等游戏的 QoS 类型扩展，无法配置扩展增量。 相反，您应该使用以下扩展策略之一。 1. MaxLatency 小于 256 扩展在 MaxLatency × 扩展周期时执行。 例如，如果初始值为 200，则第一个周期使用 200，第二个周期使用 400。 2. MaxLatency 大于或等于 256 扩展从 50 线性扩展到 MaxLatency - 256。 例如，如果初始值为 556，则该值在周期数上从 50 线性扩展到 300。 也就是说，如果选择六个周期，值将为 50、100、150、200、250 和 300。 如果选择五个周期，值将为 50、112.5、175、237.5 和 300。 #### QoS 扩展（客户端/服务器） 使用专用服务器时，扩展基于相对偏好。 在早期扩展周期中，仅考虑最偏好的服务器。 随着时间的推移，其他偏好较低的服务器也会被使用。 为确保适当的扩展，我们需要一个类似于 MaxLatency 的值，称为*扩展最大值*。它仍应设置为最大可接受的 ping 时间。但是，此值提供了玩家提供的不同服务器 ping 时间的相对比例，而不是提供 ping 时间的绝对要求。 您可以通过从请求列表中删除具有不可接受 ping 时间的服务器来排除它们。 [返回本主题顶部。](#top) #### 示例 1（规则扩展） 玩家等级用于匹配，玩家根据其等级的接近程度进行宽松匹配。 等级差异最小的玩家会被优先选择。 * 玩家等级规则 * 规则类型：SHOULD * 数据类型：Number * 最大差异：1 * 扩展增量：2 * 扁平化方法：平均 默认情况下，玩家等级之间所需的差异为 1 或更小。 * 如果在此差异范围内找到匹配，玩家将被匹配。 * 如果未找到初始匹配，则玩家等级值在每次迭代中扩展 2（默认情况下有三次迭代）。 对于 20 级玩家，此场景会产生下表所示的匹配行为。 \| 步骤 | 潜在匹配候选者的等级值 | 成功匹配的有效等级距离 | \|-----| \| 初始提交值 | 19-21 | 1 | \| 扩展周期 1 | 17-23 | 3 | \| 扩展周期 2 | 15-25 | 5 | \| 扩展周期 3 | 13-27 | 7 | 随着扩展周期的继续，成功匹配的有效等级距离在不改变最大差异值的情况下增加。 仅放宽玩家等级值。 #### 示例 2（集合规则） 游戏发布了三种可供玩家使用的 DLC。 此匹配规则应用于"仅限 DLC"游戏玩法匹配，玩家应至少拥有一个 DLC 才能与其他玩家匹配。 * 玩家 DLC 规则 * 规则类型：MUST * 数据类型：Collection * 集合操作：交集 * 目标交集：1 玩家评估其 DLC，并在其匹配票据中提交下表所示的值。 在下表中，集合值指示 DLC 的所有权。如果 DLC 对玩家可用，则值设置为 1。如果没有，则设置为 0。| | 玩家 | 集合值 | 与之匹配的玩家 | 备注 | | ---- | ---------------- | ------- | --------- | | 玩家 1 | { "1", "1", "1"} | 3 | 拥有所有 DLC | | 玩家 2 | { "0", "0", "0"} | 无 | 未拥有任何 DLC | | 玩家 3 | { "1", "0", "0"} | 1 | 拥有第一个 DLC | 如果本示例中的目标交集设置为 2，则玩家 1 和 3 将不会被匹配，因为它们之间的交集仅为 1。 #### 示例 3（避免以前的玩家） 游戏倾向于避免与最近玩过的玩家一起玩游戏。 * 规则类型：MUST * 数据类型：Collection * 集合操作：差集 * 目标交集：0 [返回本主题顶部。](#top) ## 在 SmartMatch 配置期间定义团队规则 ### 配置团队规则 要设置团队规则，请首先在 Partner Center 中创建一个团队规则。 填写您的游戏期望从此 hopper 中匹配的票据创建的团队大小。 例如，如果您的游戏预期为四对四，您应该创建两个条目，每个条目预期最大大小为四，且名称不同。 还有一个最小团队大小。如果游戏可以在一个团队中以更少的玩家进行，则使用此项。 否则，最小值和最大值应为相同的值。 ### 使用团队规则 配置团队规则后，如果无法在不导致分裂的情况下将其群组容纳到团队中，则 hopper 内的票据将被阻止匹配。 该规则将生成的团队分配写入 *members/constants/custom/matchmakingresult/initialTeam* 下的目标会话。 这仅是建议的分配。游戏可能会发现通过重新排列玩家，可以创建更好的游戏，同时仍防止票据分裂到不同的团队。 如果为正在进行的游戏创建票据，则团队规则将需要其他信息。 例如，假设八名玩家正在四对四游戏中，其中两名玩家掉线或断开连接。 游戏希望填补这些空位，但在游戏进行时无法重新洗牌团队。 填补正在进行的游戏的尝试由 `PreserveSession` 字段设置为 `always` 的票据表示。 在这种情况下，由于已经为玩家分配了团队，游戏必须指定当前的团队分配，以便 Match 知道每个团队上有多少空位。 要提供每个玩家所在团队的名称，每个玩家将其团队名称写入游戏会话中的 *members/me/properties/system/groups* 下。 此字段是一个 `JArray`。 在将上述属性写入游戏会话后，一名玩家为该会话创建一个票据，尝试找到更多玩家。 当票据被满足时，Match 将再次将加入的任何玩家的建议团队写入 *members/constants/custom/matchmakingresult/initialTeam*。 #### 优先选择均衡的团队 此外，比赛优先与最大的团队匹配。 这意味着在假设的四对四 hopper 中，四人票据将首先相互匹配，直到没有四人票据为止。 然后三人票据继续，根据需要拉入单人票据，依此类推。 通过这种方式，如果它们存在且未被其他规则阻止，则大小相似的票据通常会相互对战。 这使团队规则相对于其他规则具有相当强的优先级。 例如，假设您有有限的人群，包括一张高技能的 4 人票据 (A)、一张低技能的 4 人票据 (B) 和四张高技能的 1 人票据 (C-F)。 团队规则将使 Match 更偏好 A 和 B 匹配，而不是 A、C、D、E 和 F。 #### SHOULD 变体 MUST 规则在所有代次中防止票据分裂，并提供优先选择均衡团队的排序。 SHOULD 规则在最后一代之前与 MUST 相同——在此之后可以分裂票据，尽管优先选择均衡团队的排序仍然有效。 [返回本主题顶部。](#top) ## 另请参见 [多人游戏会话模板](/services/xbox-services/multiplayer/mpsd/concepts/live-session-templates) [Multiplayer Session Directory 概述](/services/xbox-services/multiplayer/mpsd/live-mpsd-overview) ## Related topics - [配置](/zh-CN/services/xbox-services/multiplayer/matchmaking/config/index.md) - [匹配门户配置](/zh-CN/services/xbox-services/multiplayer/matchmaking/config/live-matchmaking-config-nav.md) - [匹配概述](/zh-CN/services/xbox-services/multiplayer/matchmaking/live-matchmaking-overview.md) - [Matchmaking SDK 快速入门](/zh-CN/services/playfab/multiplayer/matchmaking/quickstart-client-sdk.md) - [在 Partner Center 中配置特权](/zh-CN/services/xbox-services/fundamentals/identity/privileges/config/live-privileges-config.md)