SmartMatch 匹配运行时操作的配置
所有 SmartMatch 匹配配置都通过 Partner Center 完成。匹配会话模板配置
匹配有两种相关的会话类型。- 匹配票据会话，是匹配服务的输入
- 匹配目标会话，是输出
票据会话不得启用服务质量 (QoS) 检查，也不得标记为”gameplay”能力。
匹配基本 hopper 配置
本节定义用于配置基本 hopper 字段的字段。 完成此配置后，您必须配置 hopper 规则，如本主题稍后的”hopper 规则配置”部分所述。以下屏幕截图显示了 hopper 编辑器。它将在以下部分中进行描述。名称
将会话提交到匹配时使用的 hopper 名称。 此名称必须与创建匹配票据时传递给 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 类型扩展，无法配置扩展增量。 相反，您应该使用以下扩展策略之一。- 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
- 数据类型：Number
- 最大差异：1
- 扩展增量：2
- 扁平化方法：平均
- 如果在此差异范围内找到匹配，玩家将被匹配。
- 如果未找到初始匹配，则玩家等级值在每次迭代中扩展 2（默认情况下有三次迭代）。
示例 2（集合规则）
游戏发布了三种可供玩家使用的 DLC。 此匹配规则应用于”仅限 DLC”游戏玩法匹配，玩家应至少拥有一个 DLC 才能与其他玩家匹配。- 玩家 DLC 规则
- 规则类型：MUST
- 数据类型：Collection
- 集合操作：交集
- 目标交集：1
在下表中，集合值指示 DLC 的所有权。如果 DLC 对玩家可用，则值设置为 1。如果没有，则设置为 0。|
如果本示例中的目标交集设置为 2，则玩家 1 和 3 将不会被匹配，因为它们之间的交集仅为 1。
示例 3（避免以前的玩家）
游戏倾向于避免与最近玩过的玩家一起玩游戏。- 规则类型：MUST
- 数据类型：Collection
- 集合操作：差集
- 目标交集：0
在 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 中，四人票据将首先相互匹配，直到没有四人票据为止。 然后三人票据继续，根据需要拉入单人票据，依此类推。 通过这种方式，如果它们存在且未被其他规则阻止，则大小相似的票据通常会相互对战。这使团队规则相对于其他规则具有相当强的优先级。