在 Partner Center（合作伙伴中心）配置匹配
此主题描述如何配置 Partner Center（合作伙伴中心）以选择兼容的玩家。
SmartMatch 匹配运行时操作配置
在 SmartMatch 配置期间定义团队规则
SmartMatch 匹配运行时操作配置
所有 SmartMatch 匹配的配置都通过合作伙伴中心进行。
匹配会话模板配置
匹配会有两种类型的相关会话。
- 匹配票证会话，它是输入匹配服务的内容。
- 匹配目标会话，它是输出。
在配置会话模板时，您应该为每个会话类型创建一个模板。
对于票证会话，您可以使用专用模板。 或者，您可以将模板重新用于大厅会话或其他不用于游戏的会话。
重要
票证会话不能启用服务质量 (QoS) 检查，并且不得标有“游戏”功能。
对于目标会话，您必须创建用于配对游戏的模板。 它应具备可在开始游戏之前在玩家间启用 QoS 检查的设置，并且必须标有“游戏”功能。
为合作伙伴中心配置 UI 时，您可以将每个会话映射到一个或多个漏斗，每个漏斗中包含确定如何将会话匹配在一起的规则。 有关更多信息，请参阅下面的“用于匹配的基本漏斗配置”。
用于匹配的基本漏斗配置
本部分中定义了用于配置基本漏斗字段的字段。 完成此配置后，您必须配置漏斗规则，如本主题后面的“漏斗规则配置”中所述。 以下屏幕截图显示了漏斗编辑器。 将在下面各部分中介绍。
名称
提交会话进行匹配时使用的漏斗名称。 此名称必须与在创建匹配票证的过程中作为参数传递给 XblMatchmakingCreateMatchTicketAsync 方法的值一致。
最小/最大组大小
从漏斗中的会话创建的玩家组的最小和最大大小。 匹配服务尝试创建尽可能大的匹配组，达到最大组大小。 但是，如果可以将足够数量的玩家汇集到一起以满足最小组大小，即创建了匹配组。
Should 规则扩展周期
对于 SHOULD 规则，匹配服务将尝试扩大搜索位置，如果未成功找到匹配，会逐渐放宽提供的匹配规则。 此过程在多个周期中执行，如使用“Should 规则扩展周期“字段所指定。
到最后一个扩展周期时，SHOULD 规则会被删除，以便它们不会再阻止票证进行匹配。 但是，它们仍然可用于确定最佳匹配项（如果有多个票证可用）。 删除它们之前，仅扩展数字和 QoS 类型。
有关详细信息，请参阅本主题后面的“漏斗规则配置”部分。
增大“Should 规则扩展周期”设置的值会为 SHOULD 规则扩展提供更多周期。 但还会延长匹配持续时间。 默认值为 3，通常这对于大多数配置已足够。
重要事项
扩展周期的固定时间间隔为 5 秒。 到最后一个扩展周期时，其余匹配尝试都将不再考虑所有的“SHOULD”规则。
排名 hopper
一般情况下，SmartMatch 禁止匹配已被阻止的玩家。 如果选中“排名漏斗”，会绕过该逻辑，以防止玩家使用该系统避开技能更高的玩家。
漏斗规则配置
本部分定义了用于配置漏斗规则的字段。
常见规则字段
在本部分中定义的字段适用于所有漏斗规则。
规则名称： 出于配置目的，为规则显示了友好名称。
规则类型： 规则的类型。 选项包括 MUST 和 SHOULD。
要成功进行匹配，必须满足 MUST 规则。
为了成功匹配，可放宽或删除 SHOULD 规则。
有关此过程的更多详细信息，请参阅本主题前面的“应控制扩展周期”部分。
数据类型： 匹配规则属性的数据类型。 可能的值如下。
- 数字： 指定简单的 32 位数值。
- 字符串： 指定最多 128 个字符的 Unicode 字符串。
- 集合： 指定一组字符串。 使用此值确定可下载内容 (DLC)、会员阵容或玩家的角色偏好。
- 服务质量： 指定用于在匹配中包含延迟 QoS 数据的自定义数据类型。 每个匹配漏斗只能使用一个此类规则。
注意
如果此限制对你的游戏有问题，请与开发人员客户经理（DAM）联系。
- 总计值： 指定总计提交的匹配值的自定义数据类型。 您可以使用此值确保生成的总和在特定范围内，或者是确切值。
- 团队： 为匹配请求中包含的玩家团队指定自定义数据类型。 您可以使用此值避免在多个团队之间拆分单个匹配票证内的玩家。
数据类型特定规则字段
本部分定义了用于定义适用于某些数据类型但不适用于其他数据类型的规则的字段。 UI 应该能够阐明哪些数据类型适用于特定规则。
允许使用通配符： 指示是否可以在匹配票证中忽略属性的值。 如果忽略，票证将与任何其他票证兼容，而不考虑此属性的值。
属性源： 数据类型值的源。 可能的来源如下。
- 提供的游戏： 在匹配票证中提交数据值。
- 用户统计实例：自动从
UserStatistics服务检索数据值。
属性名称： 属性值源的名称。 它是匹配票证中的属性名称，或用户统计信息的名称。
默认值： 未指定或没有可用于匹配请求的值时数据类型的默认值。 如果选中“允许使用通配符”字段且未指定任何值，则默认值不适用。
权重： 规则的重要性。 权重可用于指示匹配和规则扩展期间哪些规则优先使用。 权重值必须为正值，默认值为 1。
平展方法： 仅支持“数字”数据类型。 指示如何合并多个值以满足匹配的值。 它适用于单个匹配票证中以及跨多个票证的不同玩家的多个值。 可能的值如下。
- 最小值/最大值： 使用来自不同匹配票证的多个值的最小值或最大值。
- 平均值： 使用来自不同匹配票证的多个值的平均值。
最大差值： 仅支持“数字”数据类型。 为满足规则两个比较值之间可接受的最大数值差。 对于 SHOULD 规则，此值为规则扩展的起点。
设置操作： 仅支持“集合”数据类型。 匹配设置值组时要执行的操作。 可能的选项如下。
交集： 基于两个集合之间的交集量对它们进行匹配。 此设置会产生类似或相同的集合值。
差异： 基于两个集合之间的差异程度对它们进行匹配。
角色偏好： 根据基于角色的游戏模式中玩家的角色偏好对集合进行匹配。
目标交集： 设置操作配置的一部分。 匹配之前，两个集合的最小交集或最大差异。
网络拓扑： 仅支持“服务质量”数据类型。 用于 QoS 的网络拓扑。 可能的值为“对等”、“端点对主机”以及“客户端/服务器”。
最大延迟/最大缩放： 仅支持“服务质量”数据类型。 指定的网络拓扑内成功匹配的最大延迟。
使用客户端服务器服务质量的 should 规则时，此值会被视为缩放值（相对于必要的延迟）。
注意
此外，默认信誉规则也适用于漏斗。 这些规则无法删除，且不能用于确保在匹配期间正确处理信誉。
允许等待角色： 仅支持“集合角色偏好”数据类型。 指定是否此匹配服务持有匹配票证以填充所有可用角色。
扩展增量
表示针对每个扩展生成提交规则的放宽程度的数值。 除了最大差值，还应用了扩展增量。 有关详细信息，请参阅本主题后面的示例 1（规则扩展）。
您还可以使用扩展增量以不同速度扩展多个数值。 这在扩展周期配置设置中是不可能的，因为它适用于所有规则。 相反，方法是使用小数点扩展值，例如，0.4。
仅在达到新整数时才会发生扩展，从而允许有不同的扩展速度，即使对于相同数量的扩展周期亦是如此。
QoS 扩展（对等、端点对主机）
对于对等游戏的 QoS 类型扩展，无法配置扩展增量。 相反，您应使用以下扩展策略之一。
MaxLatency 小于 256
在 MaxLatency × 扩展周期执行扩展。
例如，如果初始值为 200，则在第一个周期中使用 200，在第二个周期中使用 400。
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 次数的服务器从列表中删除，以此排除这些服务器。
示例 1（规则扩展）
使用玩家级别进行匹配，将基于玩家级别的接近程度对玩家进行松散匹配。 级别差值最小的玩家将视为首选玩家。
- 玩家级别规则
- 规则类型：SHOULD
- 数据类型：数字
- 最大差值：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
- 数据类型：集合
- 设置操作：交集
- 目标交集：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
- 数据类型：集合
- 设置操作：差异
- 目标交集：0
在 SmartMatch 配置期间定义团队规则
配置团队规则
要设置团队规则，请首先在合作伙伴中心创建一个团队规则。 填写您的游戏预期从此漏斗中匹配的票证创建的团队大小。
例如，如果您的游戏预期是 4 对 4，您应创建两项，预期每个项的最大大小为 4，并采用不同名称。
还有一个最小的团队规模。 如果可以在团队中较少的玩家进行游戏，请使用此功能。 否则，最小值和最大值应相同。
使用团队规则
配置团队规则后，如果无法使漏斗内票证的组刚好适合团队而不会导致拆分，那么会阻止这些票证。 此规则会将生成的团队分配写入位于 members/constants/custom/matchmakingresult/initialTeam 下的目标会话中。
注意
这只是建议的分配。 游戏可能会发现，通过重新排列玩家，可能会创建更出色的游戏，并仍然能阻止票证拆分为不同的团队。
如果为正在进行的游戏创建票证，团队规则将需要其他信息。 例如，假设一个 4对4 游戏中有 8 个玩家，而两个玩家放弃或断开连接。 游戏将会填充这些空位，但游戏正在进行时，它无法重新安排团队。
填充正在进行的游戏的尝试用 PreserveSession 字段设置为 always 的票证表示。
在这种情况下，因为团队都已分配给玩家，所以游戏必须指定当前的团队分配，这样匹配服务就会知道每个团队有多少位置空缺。
要提供每个玩家所在团队的名称，请每个玩家将其团队名称写入位于 members/me/properties/system/groups 的游戏会话中。
此字段为 JArray。
上面提及的属性写入游戏会话中之后，玩家会为此会话创建票证，以尝试寻找更多玩家。 填写票证后，匹配服务将再次写入加入 members/constants/custom/matchmakingresult/initialTeam 的任意玩家的建议团队。
首选均衡团队
此外，首先对最大的团队进行匹配。 这意味着，在假设的 4 对 4 漏斗中，会首先将 4 个玩家的票证匹配在一起，直到不再剩余 4 个玩家的票证。 然后 3 个玩家的票证继续，根据需要抽取单一实例，以此类推。
通过这种方式，类似大小的票证通常会互相比赛（如果它们存在且未被其他规则阻止）。
注意
这会让团队规则的优先级远高于其他规则。 例如，假设您有一个有限的群体，其中包含：一个大小为 4 的高技能 (A) 票证、一个大小为 4 低技能 (B) 票证，以及四个大小为 1 的高技能 (C-F) 票证。 团队规则会使匹配服务倾向于将 A 和 B 匹配，而不是 A、C、D、E 和 F。
SHOULD 变体
MUST 规则阻止在所有代次中拆分票证，并提供“首选均衡团队”排序。 直到最后一代，SHOULD 规则都相等，从最后一代起，可能会拆分票证，尽管“首选均衡团队”排序仍处于活动状态。