本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
FlexMatch 规则集属性定义
本节定义了规则集架构中的每个属性。有关创建规则集的其他帮助，请参阅构建 FlexMatch 规则集。
name-
规则集的描述性标签。此值与分配给 Amazon GameL ift MatchMakingRuleSet 资源的名称无关。此值包含在描述已完成匹配的对战数据中，但任何 Amazon GameLift 流程均未使用该值。
允许的值：字符串：字符串
必填？ 否
ruleLanguageVersion-
正在使用的 FlexMatch 属性表达式语言的版本。
允许的值： 或
必填？ 是
playerAttributes-
包含在对战请求中并用于对战过程的玩家数据的集合。您还可以在此处声明属性，以便将玩家数据包含在传递给游戏服务器的对战数据中，即使对战过程中未使用这些数据也是如此。
必填？ 否
name-
玩家属性的唯一名称，供对战构建器使用。此名称必须与对战请求中引用的玩家属性名称相匹配。
允许的值：字符串：字符串
必填？ 是
type-
玩家属性值的数据类型。
允许的值：“字符串”、“数字”、“字符串列表”、“string_number_map”
必填？ 是
default-
当对战请求未提供给玩家的默认值时要使用的默认值。
允许的值：玩家属性允许的任何值。
必填？ 否
algorithm-
用于自定义对战过程的可选配置设置。
必填？ 否
strategy-
构建匹配时使用的方法。如果未设置此属性，则默认行为为“exhaustiveSearch”。
允许的值：
-
“EximativeSearch” – 标准匹配方法。FlexMatch 根据一组自定义匹配规则评估池中的其他票证，围绕一批中最旧的票证形成匹配。此策略适用于40名或更少玩家的对战。使用此策略时，
batchingPreference应设置为“随机”或“已排序”。 -
“平衡” – 经过优化的方法，可快速形成大型匹配项。此策略仅适用于 41 到 200 名玩家的对战。它通过对票证池进行预排序，建立潜在的对战并将玩家分配给团队，然后使用指定的玩家属性平衡对战中的每支团队来形成对战。例如，此策略可以用来平衡一场对战中所有团队的平均技能水平。使用此策略时，
balancedAttribute必须将其设置，batchingPreference应设置为“最大人群”或“最快区域”。此策略无法识别大多数自定义规则类型。
必填？ 是
-
batchingPreference-
在对票证进行分组以进行对战之前使用的预排序方法。预先对票证池进行排序会根据特定特征将票证批量组合在一起，这往往会提高最后一场对战中玩家的统一性。
允许的值：
-
“随机”– 仅在
strategy=“EximativeSearch”时有效。不进行预排序；池中的票证是随机批量排序的。这是详尽搜索策略的默认行为。 -
“已排序”– 仅在
strategy=“EximativeSearch”时有效。票证池是根据中列出的玩家属性进行预先排序的。sortbyAttributes -
“最大人群”– 仅在
strategy=“平衡”时有效。票证池是按玩家报告延迟水平可接受的区域进行预先排序的。这是默认的平衡策略的默认行为。 -
“最快区域”– 仅在
strategy=“平衡”时有效。票证池按玩家报告最低延迟水平的地区进行预先排序。由此产生的对战需要更长的时间才能完成，但是所有玩家的延迟往往很低。
必填？ 是
-
balancedAttribute-
使用平衡策略进行大型对战时要使用的玩家属性的名称。
允许的值：
playerAttributes用type=“数字”声明的任何属性。必填？ 是的，如果
strategy=“平衡”。 sortByAttributes-
在批处理之前对票证池进行预排序时要使用的玩家属性列表。此属性仅在使用详尽搜索策略进行预排序时使用。属性列表的顺序决定了排序顺序。FlexMatch 对字母和数值使用标准排序惯例。
允许的值：中声明的任何属性
playerAttributes。必填？ 是的，如果
batchingPreference=“已排序”。 backfillPriority-
用于匹配回填票证的优先级排序方法。此属性确定 FlexMatch 何时批量处理回填票证。它仅在使用详尽搜索策略进行预排序时使用。如果未设置此属性，则默认行为为“正常”。
允许的值：
-
“正常” – 在形成匹配项时，不考虑票证的请求类型（回填或新匹配项）。
-
“高” – 工单批次按请求类型（然后按年龄）排序，FlexMatch 会先尝试匹配回填票证。
-
“低” – 工单批次按请求类型（然后按年龄）排序，FlexMatch 会先尝试匹配非回填票证。
必填？ 否
-
expansionAgeSelection-
计算匹配规则扩展等待时间的方法。如果对战在一定时间后仍未完成，则扩展版用于放宽对战要求。等待时间是根据已部分填满的对战中已有票证的使用年限计算的。如果未设置此属性，则默认行为为“最新”。
允许的值：
-
“最新” – 扩展等待时间是根据部分完成的对战中带有最新创建时间戳的票证计算得出的。扩展触发的速度往往更慢，因为一张较新的票证可以重新启动等待时间。
-
“最旧” – 扩展等待时间是根据对战中创建时间戳最早的票据计算得出的。扩展往往会更快地触发。
必填？ 否
-
teams-
一场对战中团队的配置。为每支队伍提供团队名称和规模范围。规则集必须定义至少一支团队。
name-
HSM 的唯一名称。可以在规则和扩展中提及团队名称。成功对战后，玩家将在对战数据中按队名进行分配。
允许的值：字符串：字符串
必填？ 是
maxPlayers-
maxPlayers（必需） 指定可以分配给团队的玩家的最大数量。
允许的值：数值：数字
必填？ 是
minPlayers-
在对战可行之前，必须分配到团队的最低玩家人数。
允许的值：数值：数字
必填？ 是
quantity-
在一场对战中要创建的此类团队的数量。数量大于 1 的队伍会附加一个数字（“Red_1”、“Red_2” 等）。如果未设置该属性，默认值为 7。
允许的值：数值：数字
必填？ 否
rules-
创建一组定义如何评估玩家在对战游戏中的接受情况的规则语句。
必填？ 否
name-
HSM 的唯一名称。规则集中的所有规则都必须具有唯一的名称。规则名称也可在跟踪与此规则相关的活动的事件日志和指标中引用。
允许的值：字符串：字符串
必填？ 是
description-
规则的文字描述。此信息可用于确定规则的用途。它不用于对战过程。
允许的值：字符串：字符串
必填？ 否
type-
规则声明的类型。每种规则类型都有其他必须设置的属性。有关每种规则类型的结构和用法的更多详细信息，请参阅FlexMatch 规则类型。
允许的值：
-
“absoluteSort”– 使用显式排序方法进行排序，该方法根据指定的玩家属性是否与批次中最旧的票证进行比较，对批次中的票证进行排序。
-
“集合”-评估集合中的值，例如作为集合的玩家属性或多个玩家的一组值。
-
“比较”-比较两个值。
-
“距离”-测量数字值之间的距离。
-
“batchDistance”-测量属性值之间的差异并将其用于对匹配请求进行分组。
-
“distanceSort”– 使用显式排序方法进行排序，该方法根据具有数值的指定玩家属性与批次中最旧的票证的比较情况对批次中的票证进行排序。
-
“延迟” – 评估为对战请求报告的区域延迟数据。
必填？ 是
-
expansions-
当对战无法完成时，随着时间的推移放宽对战要求的规则。将扩展设置为一系列逐步应用的步骤，以便更容易找到匹配项。默认情况下，FlexMatch 根据添加到对战中的最新票证的年龄来计算等待时间。您可以使用算法属性更改扩展等待时间的计算方式
expansionAgeSelection。扩展等待时间是绝对值，因此每个步骤的等待时间应比上一步长。例如，要安排一系列逐步扩展，可以使用 30 秒、40 秒和 50 秒的等待时间。等待时间不能超过匹配请求允许的最长时间，该时间在对战配置中设置。
必填？ 否
target-
要放松的规则集元素。您可以放宽团队规模属性或任何规则语句属性。语法是 "<component name>[<rule/team name>]。 <property name>”。例如，要更改团队的最小规模：
teams[Red, Yellow].minPlayers。在名为“minSkill”的比较规则语句中更改最低技能要求:rules[minSkill].referenceValue.必填？ 是
steps-
waitTimeSeconds-
在为目标规则集元素应用新值之前等待的时间长度，以秒为单位。
必填？ 是
value-
目标规则集元素的新值。