描述规则集（必填）自定义匹配算法声明玩家属性定义对战队伍设置玩家匹配规则允许要求随着时间的推移而放松

设计 FlexMatch 规则集

本主题介绍规则集的基本结构以及如何将它们用于最多 40 位玩家的对战游戏。在最基本的层面上，对战规则集有两个作用：安排对战游戏的团队结构和规模，以及告知对战构建器如何评估玩家以查找可能的最佳匹配。

但是您的对战规则集可以做得更多。例如，您可以：

优化游戏的对战算法。
设置最低玩家延迟要求以保护游戏质量。
随着时间的推移，逐渐放宽团队要求和对战规则，这样所有活跃的玩家都可以在需要时找到可以接受的对战。
使用玩家方聚合定义组对战请求的处理。
处理 40 名或更多玩家的大型对战。有关构建大型对战的更多信息，请参阅设计大型对战规则集。

在建立对战规则集时，请考虑以下可选和必需任务：

描述规则集（必填）
自定义匹配算法
声明玩家属性
定义对战队伍
设置玩家匹配规则
允许要求随着时间的推移而放松

您可以使用 Amazon GameLift 控制台或 CreateMatchmakingRuleSet 操作来构建自己的规则集。

描述规则集（必填）

提供规则集的详细信息。

名称（可选） – 供您自己使用的描述性标签。此值与您在使用 Amazon GameLift 创建规则集时指定的规则集名称无关。
ruleLanguageVersion – 这是用于创建 FlexMatch 规则的属性表达式语言的版本。值必须为 1.0。

自定义匹配算法

FlexMatch优化了大多数游戏的默认算法，以最少的等待时间让玩家进入可接受的对战。您可以自定义算法并调整游戏的对战。

以下是默认的 FlexMatch 对战算法：

FlexMatch 将所有未完成的对战票证和回填票证放入票池中。
FlexMatch 将池中的票证随机分组为一个或多个批次。随着票池的增大，FlexMatch 会形成额外的批次以保持最佳的批次大小。
FlexMatch 在每个批次中按年龄对票证进行排序。
FlexMatch 根据每批中最旧的票证建立匹配项。

要自定义匹配算法，请在您的规则集架构中添加一个 algorithm 组件。有关完整参考信息，请参阅FlexMatch 规则集架构。

使用以下可选自定义项来影响对战过程的不同阶段。

添加批处理前排序
根据 batchDistance 属性形成批次
优先考虑回填工单
偏爱带有扩展版的旧票证

添加批处理前排序

您可以在形成批次之前对票池进行排序。这种类型的自定义对于拥有大量票证池的游戏最为有效。预批次排序可以帮助加快对战过程并提高玩家在定义特征上的统一性。

使用算法属性 batchingPreference 定义批处理前的排序方法。默认设置为 random。

自定义批处理前排序的选项包括：

按玩家属性排序。提供玩家属性列表以对票证池进行预排序。

要按玩家属性排序，batchingPreference 请设置为 sorted，然后在 sortByAttributes 中定义您的玩家属性列表。要使用属性，请先在规则集的 playerAttributes 组件中声明该属性。

在以下示例中，FlexMatch 根据玩家的首选游戏地图，然后按玩家技能对票证池进行排序。生成的批次更有可能包含想要使用相同地图的技能相似的玩家。
```
"algorithm": {
    "batchingPreference": "sorted",
    "sortByAttributes": ["map", "player_skill"],
    "strategy": "exhaustiveSearch"
},
```
按延迟排序。以最低的可用延迟创建匹配项，或者以可接受的延迟快速创建匹配项。此自定义对于形成超过 40 名玩家的大型对战的规则集非常有用。

将算法属性 strategy 设置为 balanced。平衡策略限制了规则语句的可用类型。有关更多信息，请参阅设计大型对战规则集。

FlexMatch 通过以下方式之一根据玩家报告的延迟数据对票证进行排序：
- 延迟最低的位置。票证池按玩家报告最低延迟值的位置进行预先排序。然后，FlexMatch 在相同的位置以低延迟对票证进行批处理，从而创造更好的游戏体验。它还减少了每批票证的数量，因此对战可能需要更长的时间。要使用此自定义设置，请将 batchingPreference 设置为 fastestRegion，如以下示例所示。
```
"algorithm": {
    "batchingPreference": "fastestRegion",
    "strategy": "balanced"
},
```
- 可接受的延迟很快就会匹配。票证池按玩家报告可接受延迟值的位置进行预先排序。这会形成更少的批次，包含更多的票证。每批票证越多，就能更快地找到可接受的匹配项。要使用此自定义设置，请将属性 batchingPreference 设置为 largestPopulation，如以下示例所示。
```
"algorithm": {
    "batchingPreference": "largestPopulation",
    "strategy": "balanced"
},
```
注意
平衡策略的默认值为 largestPopulation。

优先考虑回填工单

如果您的游戏实现了自动回填或手动回填，则可以根据请求类型自定义 FlexMatch 处理对战票证的方式。请求类型可以是新的匹配请求或回填请求。默认情况下，FlexMatch 对两种类型的请求都一视同仁。

回填优先级会影响 FlexMatch 在对工单进行批处理后的处理方式。回填优先级要求规则集使用详尽的搜索策略。

FlexMatch 不会将多张回填票证匹配在一起。

要更改回填票证的优先级，请设置属性 backfillPriority。

先匹配回填票证。在创建新的匹配项之前，此选项会尝试匹配回填票证。这意味着新玩家加入现有游戏的几率更高。

如果您的游戏使用自动回填功能，则最好使用此选项。自动回填通常用于游戏会话短、玩家周转率高的游戏。自动回填可以帮助这些游戏形成最低限度的可行匹配并开始对战，而FlexMatch则会搜索更多玩家来填补空缺位置。

将 backfillPriority 设置为 high。
```
"algorithm": {
    "backfillPriority": "high",
    "strategy": "exhaustiveSearch"
},
```
最后匹配回填票证。此选项会忽略回填票证，直到它评估所有其他票证。这意味着，当FlexMatch无法将新玩家匹配到新游戏时，它会将他们重新填充到现有游戏中。

当您想使用回填作为最后机会让玩家进入游戏时，例如当没有足够的玩家来组建新的对战时，这个选项很有用。

将 backfillPriority 设置为 low。
```
"algorithm": {
    "backfillPriority": "low",
    "strategy": "exhaustiveSearch"
},
```

偏爱带有扩展版的旧票证

当对战难以完成时，扩展规则会放宽匹配标准。当部分完成的对战的票证达到一定年龄时，Amazon GameLift会适用扩展规则。票证的创建时间戳决定了 Amazon GameLift 何时应用规则；默认情况下，FlexMatch 会跟踪最近匹配的票证的时间戳。

要更改 FlexMatch 应用扩展规则的时间，请按以下方式设置 expansionAgeSelection 属性：

根据最新票证进行扩展。此选项根据添加到潜在匹配项中的最新票证来应用扩展规则。每当 FlexMatch 匹配新票证时，时钟都会重置。使用此选项，结果匹配的质量往往更高，但匹配时间更长；如果匹配请求需要太长时间才能匹配，则匹配请求可能会在完成之前超时。将 expansionAgeSelection 设置为 newest。newest 为默认值。
根据最旧的票证进行扩展。此选项根据潜在匹配中最旧的票证应用扩展规则。使用此选项，FlexMatch 可以更快地应用扩展，从而缩短最早匹配的玩家的等待时间，但会降低所有玩家的对战质量。将 expansionAgeSelection 设置为 oldest。


"algorithm": {
    "expansionAgeSelection": "oldest",
    "strategy": "exhaustiveSearch"
},

声明玩家属性

在本节中，列出要包含在对战请求中的个人玩家属性。您可能在规则集中声明玩家属性有两个原因：

当规则集包含依赖玩家属性的规则时。
当您想通过匹配请求将玩家属性传递给游戏会话时。例如，您可能希望在每个玩家连接之前将玩家角色选择传递给游戏会话。

在声明玩家属性时，请包含以下信息：

名称（必需）–此值在规则集中必须唯一。
类型（必需）– 这是属性值的数据类型。有效数据类型为数字、字符串或字符串映射。
默认（可选）– 输入一个默认值，以便在对战请求未提供属性值时使用。如果未声明默认值且请求中不包含值，则 FlexMatch 无法满足请求。

定义对战队伍

描述对战游戏的团队的结构和规模。每个对战游戏必须至少有一个团队，您可以根据需要定义任意数量的团队。您的团队的玩家数量可以相同，也可以不同。例如，您可以定义有一个玩家的怪物团队和有 10 个玩家的猎人团队。

根据规则集如何定义团队规模将对战请求处理为小型对战或大型对战。最多 40 位玩家的潜在对战游戏属于小型对战，而超过 40 位玩家的对战游戏则属于大型对战。要确定规则集的潜在对战游戏规模，请为在规则集中定义的所有团队添加 maxPlayer 设置。

名称（必需）– 为每个团队分配一个唯一名称。您可以在规则和扩展中使用这个名字，在游戏会话中使用 FlexMatch 引用对战数据。
maxPlayers（必需）– 指定可以分配给团队的玩家的最大数量。
MinPlayers（必填）– 指定要分配给队伍的最小玩家人数。
数量（可选）– 使用此定义指定要组建的团队数量。当 FlexMatch 创建对战时，它会为这些团队提供所提供的名字和一个附加的数字。例如 Red-Team1、Red-Team2 和 Red-Team3。

FlexMatch 试图将队伍填满最大玩家人数，但确实会创建玩家人数较少的团队。如果您希望对战游戏的所有团队都具有相同规模，可以创建相应的规则。有关 EqualTeamSizes 规则的示例，请参阅 FlexMatch 规则集示例主题。

设置玩家匹配规则

创建一组定义如何评估玩家在对战游戏中的接受情况的规则语句。规则可以设置应用于单个玩家、团队或整个对战的要求。当处理对战请求时，它将从可用玩家池中最早的玩家开始，围绕该玩家构建对战。有关创建 FlexMatch 规则的详细帮助，请参阅FlexMatch 规则类型。

名称（必需）– 这是用于在规则集中唯一标识规则的有意义的名称。规则名称也可在跟踪与此规则相关的活动的事件日志和指标中引用。
描述（可选）– 使用此元素可附加自由格式文本描述。
类型（必需）– 类型元素标识处理规则时要使用的操作。每个规则类型都需要一组额外属性。有关有效的规则类型和属性的列表，请参阅 FlexMatch 规则语言。
规则类型属性（可能是必需的）根据定义的规则类型，您可能需要设置某些规则属性。在 FlexMatch 规则语言中了解有关属性以及如何使用 FlexMatch 属性表达式语言的更多信息。

允许要求随着时间的推移而放松

当 FlexMatch 找不到匹配项时，扩展允许您随着时间的推移放宽规则标准。此功能可确保 FlexMatch 在无法实现完美匹配时提供最佳可用性。通过利用扩展放宽规则，您将逐渐扩大可以匹配的玩家池。

当未完成匹配中最新票证的年龄与扩展版等待时间相匹配时，扩展版就会开始。当 FlexMatch 向对战添加新票证时，扩展等待时间时钟可能会被重置。您可以在规则集的algorithm部分自定义扩展的开始方式。

以下是扩展版的示例，它会逐渐提高对战所需的最低技能等级。该规则集使用名为 SkillDelta 的距离规则语句来要求对战中的所有玩家彼此相距在 5 个技能等级以内。如果在十五秒钟内没有进行新的对战，则此扩展版将寻找技能等级差异为 10，然后在十秒钟后寻找 20 的差异。


"expansions": [{
        "target": "rules[SkillDelta].maxDistance",
        "steps": [{
            "waitTimeSeconds": 15,
            "value": 10
        }, {
            "waitTimeSeconds": 25,
            "value": 20
        }]
    }]

如果此规则集由启用了自动回填的对战构建器使用，不要过快放宽玩家计数要求。新游戏会话需要几秒钟时间启动并开始自动回填。更好的方法是仅在您的游戏要开始自动回填后设置扩展等待时间。扩展时间因您的团实例集成而异，因此请进行测试以找到最适合您游戏的扩展策略。

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

构建规则集

设计大型对战规则集