通过

配置匹配队列

  • 项目

概述

匹配配置以队列为中心，队列表示票证等待互相匹配的位置。 每个队列都有一些关于匹配要求的常规配置。 此外，它还可以包含一组规则，对票证如何匹配提供进一步限制。

队列配置

在队列级别，配置描述有关如何在队列中匹配票证的基本要求，以及如何获取有关队列的统计信息。

队列名称

特定队列的名称。 长度介于 1 到 64（含端值）个字符之间，区分大小写。 可以是字母数字与下划线和连字符的组合，以字母或数字开头。 通常，队列名称表示一种游戏玩法，例如“4v4CaptureTheFlag”或“UnrankedRace”。 在创建匹配票证时，必须指定队列名称以标识应进入的队列。

匹配大小

匹配中允许的玩家数的范围。 最小匹配大小必须大于或等于 2，最大匹配大小必须小于或等于 100（如果使用团队时，此限制为 32）。

此外，即使一个票证就已满足最小匹配要求，但它必须与至少一个其他票证匹配才能返回找到匹配项的消息。 但如果一个票证已达到最大匹配大小，它将被拒绝。

玩家可用的统计信息

这确定哪些队列统计信息通过 GetQueueStatistics API 向玩家公开。 服务器始终可以访问所有统计信息。 有关详细信息，请参阅在作品中显示队列统计信息教程。

在此页面上，有两个可供您控制的选项：

  1. Show the number of players matching - 是否向玩家公开等待匹配的玩家数量。 游戏可以使用此选项隐藏模式的相对受欢迎程度，或出于商业原因隐藏玩家计数。
  2. Show the time to match statistics - 是否向玩家公开用于匹配统计信息（平均值和百分比）的时间。

团队

队列可以包含团队配置以让匹配服务向团队分配玩家。 还可以使用其他团队特定规则来控制如何进行团队分配。 此外，匹配服务还将确保在同一票证中匹配的玩家不会被分配到不同团队。

一个队列中可以定义两个或更多团队。

  • Team name - 用于此团队的名称。 团队名称长度介于 1 到 64（含端值）个字符之间，区分大小写。 可以是字母数字与下划线和连字符的组合，以字母或数字开头。 此外，团队名称在队列中必须唯一。
  • Team size - 团队中可以包含的最小和最大玩家数量。 匹配将尝试按照最大可能玩家数量组队。

除定义团队和团队规模外，还可以启用其他规则来帮助处理团队匹配。 请参阅下面的内容了解有关团队特定规则的信息。

规则配置

可以选择为队列定义规则。 配置时，规则可以帮助匹配算法确定应匹配的票证。 每个规则都适用于玩家元数据中的单个属性。 最多可以为一个队列定义 20 个规则。

有多种规则类型。 每种都包含一些常见可配置元素和一些特定规则类型特有的元素。 此外，很多规则还允许扩展，在扩展中，随着时间的推移，规则的限制性会降低。

常见规则元素

下面是所有规则都经常使用的元素。

  • Rule Name - 名称长度必须介于 1 到 255（含端值）个字符之间，可以是字母数字与下划线和连字符的组合，必须以字母或数字开头。 规则名称必须在队列中唯一。

  • Weight - 修改规则重要性的一种方法。 一般情况下，规则不仅提供限制，还提供一种方法来对符合条件的剩余票证进行排序。 权重是一个乘数，用来修改规则对排序目的的重要性。

  • Attribute Source - 规则通常对提供给它们的信息起作用。 此字段介绍此信息来源的两个选项：

    1. User - 属性是在创建或加入票证请求中与玩家一起提交的。
    2. Player Entity - 属性是从玩家的关联玩家实体中检索到的。 可以通过 SetObjects API 进行设置。

  • Attribute Path - 到达属性的路径。 在使用用户属性来源时，这就是属性的名称。 在使用玩家实体属性来源时，这是一个从实体检索特定项的 JSONPath，例如 $.playerSkill.Mean。

  • Behavior when attribute is not specified - 如果规则需要某一属性，但并未指定，可以用以下两种行为之一配置规则：

    1. 可以为属性提供默认值。
    2. 它可以用此作为信号来指示票证满足规则提供的任何限制。 当有些玩家表示有首选项，而另一位玩家愿意匹配任何人时，这可能非常有用。 没有首选项的玩家可以忽略提供属性，并与任意其他玩家匹配。

标准规则类型

下面列出了每种规则类型，还有它的目的、一些常见用法以及规则可能需要的任何特定配置。

规则类型 说明 常见用法 规则特定字段
字符串相等 确保字符串属性在一个匹配中的所有票证上都相同。 要求内部版本号或其他特定项目匹配。 无
差异 确保一个匹配中的任意两个票证之间的数字属性的绝对差异小于配置的最大差异。 按技能、经验或其他数值比较对玩家分组 Merge function - 选择如何将多个玩家值合并到一个表示票证的值中。 选项有最小、最大和平均。 默认为平均。
取交集 确保对于作为字符串列表的给定属性，匹配中的所有票证至少共享所配置个数的值。 DLC 或地图选择 Min intersection size - 一个匹配的最小共享项目数。
匹配总数 确保一个匹配中的所有玩家的某一数字属性的总和在配置的范围内。 角色选择，模拟主机/服务器匹配，随着时间的推移调整玩家计数限制 Min/Max total - 属性总和必须在这些范围内，包含边界。
区域选择 确保匹配中所有用户的公共数据中心的延迟小于配置的最大值。 多人游戏服务器集成需要这一规则。 Max Latency - 只有位于这一最大延迟范围内的数据中心有资格匹配。

团队规则类型

只有当队列配置中存在团队时才能设置团队规则。 它们可以提供其他方式来要求团队间保持平衡。 有以下团队规则可用：

规则类型 说明 常见用法 规则特定字段
团队差异 确保匹配中包含的团队的某一特定属性（如技能）处于配置的差异内。 这与标准差异规则非常相似，只是用来比较的值是各团队的平均值。 团队间的技能平衡 无
团队规模平衡 确保最大和最小团队之间的玩家计数差异不超过阈值。 例如，可以使用此规则创建允许 3v3 和 4v4 匹配但不允许 3v4 的队列。 团队间的玩家计数平衡 允许团队规模差异，即团队的不均衡程度，用分配给每个团队的玩家数量的差异衡量。
团队票证大小相似性 确保所有团队或者都有大群，或者都没有大群。 大群的定义是至少为最大团队规模的一半。 阻止群（预创建的团队）与一组或单个玩家匹配。 无

扩展和成为可选

随着时间的推移，规则可能会成为可选或者限制性降低，从而允许等待了一段时间的票证扩大搜索范围来查找潜在的匹配。 有两种方法可控制此行为：

  1. Seconds until optional - 简单指示规则处于活动状态的时间长度。 规则不再限制已经等待此时间的票证之间的匹配。

  2. Expansion process - 规则随着时间的推移逐渐调整其配置的阈值。 例如，差异规则可能要求匹配在某一特定最大差异范围内。 当票证等待时，此规则可能会扩展最大差异，以允许扩展到逐渐加大的票证范围，从而允许它在没有合适对手时也能匹配。

扩展可以是线性扩展或自定义扩展。 在线性扩展中，值随着时间的推移增长，在每个时间间隔后使用一个固定的更改。 在线性扩展中自定义的项目有：

  • Seconds between expansions - 规则更改其限制的每个规则实例之间的时间长度。
  • Delta - 值的变化。
  • Limit - 结束值。 规则永远不会扩展超出此值。

在自定义扩展中，每次规则更改其限制时都可以使用任意值。 使用以下字段：

  • Seconds between expansions - 规则更改其限制的每个规则实例之间的时间长度
  • 一个或多个自定义字段，在扩展期间修改规则。 每个字段用分号分隔以表示在每个扩展间隔中使用的不同的值。 可以使用“null”代替某个值，以指示规则在此间隔期间无效。

确切的修改字段取决于规则。 下面的图表介绍哪些规则具有哪些扩展种类以及扩展修改哪些字段。

规则类型 允许线性扩展？ 允许自定义扩展？ 扩展期间修改的属性
字符串相等 否 是 规则是否处于活动状态
差异 是 是 允许的最大差异
取交集 是 是 所需的最小交集
匹配总数 否 是 所需的最小和最大总计
区域选择 是 是 允许的最大延迟
团队差异 是 是 允许的团队值差异
团队规模平衡 是 是 允许的每团队玩家人数差异
团队票证大小相似性 否 否 不适用

有关配置用例和示例的更多详细信息，请参阅匹配方案和配置示例。