本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 构建 Amazon GameLift Servers FlexMatch 对战构建器
构建 FlexMatch 对战构建器
本节介绍了对战构建器的关键要素，以及如何为您的游戏创建和自定义对战构建器。这包括设置对战配置和对战规则集。
创建对战构建器是 FlexMatch 路线图的第一步:
+ [路线图：在 Amazon GameLift Servers 托管解决方案中添加对战](match-tasks.md)
+ [路线图：使用 FlexMatch 创建独立的对战解决方案](match-tasks-safm.md)
FlexMatch 对战构建器可用于构建对战游戏。它可以管理接收的对战请求池、处理和选择玩家以找到最佳玩家组，以及组建参加对战游戏的团队。对于使用 Amazon GameLift Servers 进行托管的游戏，它还会放置和启动对战会话。
FlexMatch 可将对战服务与自定义规则引擎搭配使用。这样，您就可以设计如何根据适用于您的游戏的玩家属性和游戏模式匹配对战玩家，然后依靠 FlexMatch 来管理构成玩家组的基本要素，并将它们放置到游戏中。请参阅[FlexMatch 规则集示例](match-examples.md)中有关自定义对战的更多详细信息。
匹配完成后，FlexMatch 会提供对战数据，以便放置游戏会话。对于用于托管Amazon GameLift Servers的游戏，FlexMatch会将包含匹配玩家的游戏会话放置请求发送到游戏会话队列。此队列可在您的 Amazon GameLift Servers 队组中搜索可用的托管资源，并为对战游戏启动新的游戏会话。对于使用其他托管解决方案的游戏，FlexMatch 会提供匹配数据，供您提供给自己的游戏会话放置组件。
有关 FlexMatch 对战构建器如何处理它收到的对战请求的详细说明，请参阅 [FlexMatch 对战过程](gamelift-match-howitworks.md)。
**Topics**
+ [
# 设计 FlexMatch 对战构建器
](match-configuration.md)
+ [
# 构建 FlexMatch 规则集
](match-rulesets.md)
+ [
# 创建对战配置
](match-create-configuration.md)
+ [
# 设置 FlexMatch 事件通知
](match-notification.md)
# 设计 FlexMatch 对战构建器
设计 对战构建器
本主题提供有关如何设计适合您游戏的对战构建器的指导.
**Topics**
+ [
## 配置一个对战构建器。
](#match-configuration-elements)
+ [
# 为对战构建器选择一个区域
](match-configuration-regions.md)
+ [
# 添加可选元素
](match-configuration-options.md)
## 配置一个对战构建器。
对战构建器至少需要具备三个元素：
+ **规则集**可确定对战团队的规模和范围并定义用于评估玩家是否参加对战的规则集。每个对战构建器均配置为使用一个规则集。请参阅[构建 FlexMatch 规则集](match-rulesets.md)和[FlexMatch 规则集示例](match-examples.md)。
+ **通知目标**接收所有对战事件通知。您需要设置 Amazon Simple Notification Service (SNS) 主题，然后将主题ID添加到对战构建器中。有关设置通知的更多信息，请参阅[设置 FlexMatch 事件通知](match-notification.md)。
+ **请求超时**可确定对战请求留在请求池中以及被评估为潜在对战游戏的时长。一旦请求超时，则无法进行对战，并将从池中删除。
+ 将 FlexMatch 与 Amazon GameLift Servers 托管式托管资源配合使用时，**游戏会话队列**会找到最佳可用资源来托管对战的游戏会话，然后开始新的游戏会话。每个队列都配置了一系列位置和资源类型（包括竞价型实例或按需型实例），用于确定游戏会话的放置位置。有关队列的更多信息，请参阅[使用多位置队列](https://docs.amazonaws.cn/gamelift/latest/developerguide/queues-intro.html)。
# 为对战构建器选择一个区域
确定您希望进行对战活动的位置，并在该位置创建对战配置和规则集。Amazon GameLift Servers 会为您的游戏对战请求维护票证池，并在其中对这些请求进行排序和评估是否有可行的匹配。匹配完成后，Amazon GameLift Servers 会发送对战详细信息，以便放置游戏会话。您可以在托管解决方案支持的任何位置运行匹配的游戏会话。
请参阅[FlexMatch 支持的 Amazon Web Services 区域](match-regions.md)，了解可以创建 FlexMatch 资源的位置。
在 Amazon Web Services 区域 为你的媒人选择比赛时，要考虑位置会如何影响表现，以及它如何优化玩家的比赛体验。我们建议您遵循以下最佳实操：
+ 将对战构建器放置在离您的玩家和发送 FlexMatch 对战请求的客户端服务很近的位置。这种方法可以减少对对战请求工作流程的延迟影响，并提高其效率。
+ 如果您的游戏吸引了全球观众，可以考虑在多个位置创建对战构建器，并将匹配请求发送给离玩家最近的对战构建器。除了提高效率外，这还会导致在地理位置上彼此靠近的玩家形成票证池，从而提高了对战构建器根据延迟要求匹配玩家的能力。
+ 将 FlexMatch 与 Amazon GameLift Servers 托管式托管资源配合使用时，请将您的对战构建器及其使用的游戏会话队列放在同一位置。这有助于最大程度地减少对战构建器和队列之间的通信延迟。
# 添加可选元素
除了这些最低要求，您还可以为对战构建器配置以下附加选项。如果您与Amazon GameLift Servers托管解决方案FlexMatch一起使用，则内置了许多功能。如果您使用 FlexMatch 作为独立的对战服务，则可能需要在系统中内置这些功能。
**玩家接受**
您可以将对战构建器配置为要求选定参加对战的所有玩家都必须接受参与游戏。如果要求玩家接受，所有玩家都必须选择接受或拒绝建议的对战游戏。对战游戏必须收到建议对战游戏的所有玩家的接受信息，才能完成。如果任何玩家拒绝或未接受对战游戏，将会丢弃建议的对战游戏。对于所有玩家都接受对战游戏的票证，系统会将其状态返回到池中以继续处理。至少有一名玩家拒绝对战或未能回复的票证将进入失败状态，不再处理。玩家接受需要设置时间限制，您可以定义此限制；所有玩家都必须在限制时间内接受建议的对战游戏才能继续对战。
**回填模式**
FlexMatch 回填非常实用，可以在游戏会话的整个生命周期内，让游戏会话始终有良好匹配的新玩家。在处理回填请求时，FlexMatch 使用与匹配原始玩家相同的对战构建器和相同的过程来查找新玩家。您可以使用新对战的票证自定义回填票证的优先顺序，将回填票证放在排队的前面或末端。这意味着，当新玩家进入对战池时，他们被放置在现有游戏中的可能性大于或小于在新组建的游戏中。
无论您的游戏在托管式 Amazon GameLift Servers 托管上使用 FlexMatch 还是与其他托管解决方案搭配使用 FlexMatch，都可以进行手动回填。手动回填让您能够灵活地决定何时触发回填请求。例如，您可能不希望在游戏的某些阶段或仅存在某些条件时添加新玩家。
自动回填仅适用于使用托管式 Amazon GameLift Servers 托管的游戏。启用此功能后，如果游戏会话以开放的玩家席位开始，Amazon GameLift Servers 会开始自动为其生成回填请求。此功能允许您设置对战，以便以最少的玩家人数开始新游戏，然后在新玩家进入对战池时快速填满。在游戏会话生命周期内，您可以随时关闭自动回填功能。
**游戏属性**
对于使用 FlexMatch 和 Amazon GameLift Servers 托管式托管的游戏，您可以提供其他信息，以便在请求新的游戏会话时传递给游戏服务器。这可能是传递游戏模式配置的有用方法，这些配置是为正在创建的匹配类型启动游戏会话所必需的。由对战构建器创建的对战的所有游戏会话都将获得相同的游戏属性集。您可以通过创建不同的对战配置来更改游戏属性信息。
**预留玩家位置**
您可以指定为每个对战游戏预留的特定玩家位置，然后在日后占用这些位置。这可以通过配置对战配置的“额外玩家数量”属性完成。
**自定义事件数据**
使用此属性可在对战构建器的所有对战相关事件中包含一组自定义信息。此功能可用于跟踪您游戏独有的特定活动，包括跟踪对战构建器的性能。
# 构建 FlexMatch 规则集
构建规则集
每个 FlexMatch 对战构建器必须拥有一个规则集。规则集可确定对战游戏的两个关键元素：游戏团队的结构和规模，以及如何为玩家分组才能呈现可能的最佳对战游戏。
例如，规则集能够描述类似这样的对战游戏：创建包含两个团队的对战游戏，每个团队有 5 个玩家，一个团队是防守者，另一个团队是进攻者。一个团队可以有新手玩家和经验丰富的玩家，但两个团队的平均技能必须在 10 点内。如果在 30 秒后未能进行匹配，则逐渐放宽技能要求。
本部分的主题介绍如何设计和构建对战规则集。在创建规则集时，您可以使用 Amazon GameLift Servers 控制台或 Amazon CLI。
**Topics**
+ [
# 设计 FlexMatch 规则集
](match-design-ruleset.md)
+ [
# 设计 FlexMatch 大型对战规则集
](match-design-rulesets-large.md)
+ [
# 教程：创建对战规则集
](match-create-ruleset.md)
+ [
# FlexMatch 规则集示例
](match-examples.md)
# 设计 FlexMatch 规则集
设计 规则集
本主题介绍规则集的基本结构以及如何将它们用于最多 40 位玩家的对战游戏。在最基本的层面上，对战规则集有两个作用：安排对战游戏的团队结构和规模，以及告知对战构建器如何评估玩家以查找可能的最佳匹配。
但是您的对战规则集可以做得更多。例如，您可以：
+ 优化游戏的对战算法。
+ 设置最低玩家延迟要求以保护游戏质量。
+ 随着时间的推移，逐渐放宽团队要求和对战规则，这样所有活跃的玩家都可以在需要时找到可以接受的对战。
+ 使用玩家方聚合定义组对战请求的处理。
+ 处理 40 名或更多玩家的大型对战。有关构建大型对战的更多信息，请参阅[设计 FlexMatch 大型对战规则集](match-design-rulesets-large.md)。
在建立对战规则集时，请考虑以下可选和必需任务：
+ [描述规则集（必填）](match-rulesets-components-set.md)
+ [自定义匹配算法](match-rulesets-components-algorithm.md)
+ [声明玩家属性](match-rulesets-components-attributes.md)
+ [定义对战队伍](match-rulesets-components-teams.md)
+ [设置玩家匹配规则](match-rulesets-components-rules.md)
+ [允许要求随着时间的推移而放松](match-rulesets-components-expansion.md)
您可以使用 Amazon GameLift Servers 控制台或 `[CreateMatchmakingRuleSet](https://docs.amazonaws.cn/gameliftservers/latest/apireference/API_CreateMatchmakingRuleSet.html)` 操作来构建自己的规则集。
# 描述规则集（必填）
提供规则集的详细信息。
+ *名称*（可选） – 供您自己使用的描述性标签。此值与您在使用 Amazon GameLift Servers 创建规则集时指定的规则集名称无关。
+ *ruleLanguageVersion*-用于创建FlexMatch规则的属性表达式语言的版本。值必须为 `1.0`。
# 自定义匹配算法
FlexMatch 优化了大多数游戏的默认算法，以最少的等待时间让玩家进入可接受的对战。您可以自定义算法并调整游戏的对战。
以下是默认的 FlexMatch 对战算法：
1. FlexMatch 将所有未完成的对战票证和回填票证放入票池中。
1. FlexMatch 将池中的票证随机分组为一个或多个批次。随着票池的增大，FlexMatch 会形成额外的批次以保持最佳的批次大小。
1. FlexMatch 在每个批次中按年龄对票证进行排序。
1. FlexMatch 根据每批中最旧的票证建立匹配项。
要自定义匹配算法，请在您的规则集架构中添加一个 `algorithm` 组件。有关完整参考信息，请参阅[FlexMatch 规则集架构](match-ruleset-schema.md)。
使用以下可选自定义项来影响对战过程的不同阶段。
+ [添加批处理前排序](#match-rulesets-components-algorithm-presort)
+ [根据 batchDistance 属性形成批次](https://docs.amazonaws.cn//gameliftservers/latest/flexmatchguide/match-rules-reference-ruletype.html#match-rules-reference-ruletype-batchdistance)
+ [优先考虑回填工单](#match-rulesets-components-algorithm-backfill)
+ [偏爱带有扩展版的旧票证](#match-rulesets-components-algorithm-expansion)
## 添加批处理前排序
您可以在形成批次之前对票池进行排序。这种类型的自定义对于拥有大量票证池的游戏最为有效。预批次排序可以帮助加快对战过程并提高玩家在定义特征上的统一性。
使用算法属性 `batchingPreference` 定义批处理前的排序方法。默认设置为 `random`。
自定义批处理前排序的选项包括：
+ **按玩家属性排序。**提供玩家属性列表以对票证池进行预排序。
要按玩家属性排序，`batchingPreference` 请设置为 `sorted`，然后在 `sortByAttributes` 中定义您的玩家属性列表。要使用属性，请先在规则集的 `playerAttributes` 组件中声明该属性。
在以下示例中，FlexMatch 根据玩家的首选游戏地图，然后按玩家技能对票证池进行排序。生成的批次更有可能包含想要使用相同地图的技能相似的玩家。
```
"algorithm": {
"batchingPreference": "sorted",
"sortByAttributes": ["map", "player_skill"],
"strategy": "exhaustiveSearch"
},
```
+ **按延迟排序。**以最低的可用延迟创建匹配项，或者以可接受的延迟快速创建匹配项。此自定义对于形成超过 40 名玩家的大型对战的规则集非常有用。
将算法属性 `strategy` 设置为 `balanced`。平衡策略限制了规则语句的可用类型。有关更多信息，请参阅 [设计 FlexMatch 大型对战规则集](match-design-rulesets-large.md)。
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 Servers 会应用扩展规则。票证的创建时间戳决定了 Amazon GameLift Servers 何时应用规则；默认情况下，FlexMatch 会跟踪最近匹配的票证的时间戳。
要更改 FlexMatch 应用扩展规则的时间，请按以下方式设置 `expansionAgeSelection` 属性：
+ **根据最新票证进行扩展。**此选项根据添加到潜在匹配项中的最新票证来应用扩展规则。每当 FlexMatch 匹配新票证时，时钟都会重置。使用此选项，结果匹配的质量往往更高，但匹配时间更长；如果匹配请求需要太长时间才能匹配，则匹配请求可能会在完成之前超时。将 `expansionAgeSelection` 设置为 `newest`。`newest` 为默认值。
+ **根据最旧的票证进行扩展。**此选项根据潜在匹配中最旧的票证应用扩展规则。使用此选项，FlexMatch 可以更快地应用扩展，从而缩短最早匹配的玩家的等待时间，但会降低所有玩家的对战质量。将 `expansionAgeSelection` 设置为 `oldest`。
```
"algorithm": {
"expansionAgeSelection": "oldest",
"strategy": "exhaustiveSearch"
},
```
# 声明玩家属性
在本节中，列出要包含在对战请求中的个人玩家属性。您可能在规则集中声明玩家属性有两个原因：
+ 当规则集包含依赖玩家属性的规则时。
+ 当您想通过匹配请求将玩家属性传递给游戏会话时。例如，您可能希望在每个玩家连接之前将玩家角色选择传递给游戏会话。
在声明玩家属性时，请包含以下信息：
+ *名称*（必需）–此值在规则集中必须唯一。
+ *类型*（必需）– 这是属性值的数据类型。有效数据类型为数字、字符串、字符串列表或字符串映射。
+ *默认*（可选）– 输入一个默认值，以便在对战请求未提供属性值时使用。如果未声明默认值且请求中不包含值，则 FlexMatch 无法满足请求。
# 定义对战队伍
描述对战游戏的团队的结构和规模。每个对战游戏必须至少有一个团队，您可以根据需要定义任意数量的团队。您的团队的玩家数量可以相同，也可以不同。例如，您可以定义有一个玩家的怪物团队和有 10 个玩家的猎人团队。
FlexMatch 根据规则集如何定义团队规模将对战请求处理为小型对战或大型对战。最多 40 位玩家的潜在对战游戏属于小型对战，而超过 40 位玩家的对战游戏则属于大型对战。要确定规则集的潜在对战游戏规模，请为在规则集中定义的所有团队添加 *maxPlayer* 设置。
+ *名称*（必需）– 为每个团队分配一个唯一名称。您需在规则与扩展配置中使用此名称，同时 FlexMatch 会通过该名称引用游戏会话中的对战数据。
+ *maxPlayers*（必需）– 指定可以分配给团队的玩家的最大数量。
+ *MinPlayers*（必填）– 指定要分配给队伍的最小玩家人数。
+ *数量*（可选）– 使用此定义指定要组建的团队数量。当 FlexMatch 创建对战时，它会为这些团队提供所提供的名字和一个附加的数字。例如 `Red-Team1`、`Red-Team2` 和 `Red-Team3`。
FlexMatch 会尝试将团队填满最大玩家人数，但确实会创建玩家人数较少的团队。如果您希望对战游戏的所有团队都具有相同规模，可以创建相应的规则。有关 `EqualTeamSizes` 规则的示例，请参阅 [FlexMatch 规则集示例](match-examples.md) 主题。
# 设置玩家匹配规则
创建一组定义如何评估玩家在对战游戏中的接受情况的规则语句。规则可以设置应用于单个玩家、团队或整个对战的要求。当 Amazon GameLift Servers 处理对战请求时，它将从可用玩家池中最早的玩家开始，围绕该玩家构建对战。有关创建 FlexMatch 规则的详细帮助，请参阅[FlexMatch 规则类型](match-rules-reference-ruletype.md)。
+ *名称*（必需）– 这是用于在规则集中唯一标识规则的有意义的名称。规则名称也可在跟踪与此规则相关的活动的事件日志和指标中引用。
+ *描述*（可选）– 使用此元素可附加自由格式文本描述。
+ *类型*（必需）– 类型元素标识处理规则时要使用的操作。每个规则类型都需要一组额外属性。有关有效的规则类型和属性的列表，请参阅 [FlexMatch 规则语言](match-rules-reference.md)。
+ 规则类型属性（可能是必需的） 根据定义的规则类型，您可能需要设置某些规则属性。在 [FlexMatch 规则语言](match-rules-reference.md) 中了解有关属性以及如何使用 FlexMatch 属性表达式语言的更多信息。
# 允许要求随着时间的推移而放松
当 FlexMatch 找不到匹配项时，扩展允许您随着时间的推移放宽规则标准。此功能可确保 FlexMatch 在无法实现完美匹配时提供最佳可用性。通过利用扩展放宽规则，您将逐渐扩大可以匹配的玩家池。
当未完成匹配中最新票证的年龄与扩展版等待时间相匹配时，扩展版就会开始。当 FlexMatch 向对战添加新票证时，扩展等待时间时钟可能会重置。您可以在规则集的`algorithm`部分自定义扩展的开始方式。
以下是扩展版的示例，它会逐渐提高对战所需的最低技能等级。规则集使用距离规则声明，命名*SkillDelta*为要求比赛中的所有玩家彼此相距在 5 个技能等级以内。如果在十五秒钟内没有进行新的对战，则此扩展版将寻找技能等级差异为 10，然后在十秒钟后寻找 20 的差异。
```
"expansions": [{
"target": "rules[SkillDelta].maxDistance",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 25,
"value": 20
}]
}]
```
如果此规则集由启用了自动回填的对战构建器使用，不要过快放宽玩家计数要求。新游戏会话需要几秒钟时间启动并开始自动回填。更好的方法是仅在您的游戏要开始自动回填后设置扩展等待时间。扩展时间因您的团实例集成而异，因此请进行测试以找到最适合您游戏的扩展策略。
# 设计 FlexMatch 大型对战规则集
设计 大型对战规则集
如果您的规则集创建的对战允许 41 到 200 名玩家，则您必须对您的规则集配置做出一些调整。这些调整优化了对战算法，使其可以建立可行的大型对战，同时还可以缩短玩家的等待时间。因此，大型匹配规则集用针对常见对战优先级进行了优化的标准解决方案取代了耗时的自定义规则。
以下是如何确定是否需要针对大型对战优化规则集：
1. 对于规则集中定义的每支队伍，获取 *maxPlayer* 的值，
1. 将所有 *MaxPlayer* 值相加。如果这些设置的总计超过 40，表示您有大型对战规则集。
要针对大型对战优化规则集，请按如下所述进行调整。参考架构，了解 [大型对战的规则集架构](match-ruleset-schema-large.md) 中的大型对战规则集和 [示例：创建大型对战](match-examples-7.md) 中的规则集示例。
# 为大型对战自定义匹配算法
向规则集添加算法组件（如果尚不存在）。设置以下属性：
+ `strategy`（必填）– 将 `strategy` 属性设置为“平衡”。此设置会触发 FlexMatch 进行额外的赛后检查，以根据 `balancedAttribute` 属性中定义的指定玩家属性找到最佳的团队平衡。平衡的策略取代了使用自定义规则来组建势均力敌的团队。
+ `balancedAttribute`（必填）– 确定在对战中平衡团队时要使用的玩家属性。此属性必须具有数字数据类型（双精度或整数）。例如，如果您选择平衡玩家技能，FlexMatch 会尝试分配玩家，以便所有团队的总技能水平尽可能平衡。请务必在规则集的玩家属性中声明平衡属性。
+ `batchingPreference`（可选）– 选择您想在多大程度上强调为玩家打造尽可能低的延迟对战。此设置会影响在建立对战之前对对战票证的排序方式。选项包括：
+ 最大群体。FlexMatch 允许使用池中所有在至少一个共同位置具有可接受延迟值的票证进行匹配。因此，潜在的票证池往往很大，这使得更容易更快地填补对战。玩家可能被放置在延迟可接受但并不总是最佳延迟的游戏中。如果未设置 `batchingPreference` 属性，则这是 `strategy` 设置为“平衡”时的默认行为。
+ 最快的位置。FlexMatch 会根据池中报告最低延迟值的位置，对所有票证进行预排序。因此，往往会与报告相同位置低延迟的玩家进行对战。同时，每场对战的潜在票证池较小，这可能会增加填补对战所需的时间。此外，由于对延迟的优先级更高，因此对战中的玩家在平衡属性方面的差异可能更大。
以下示例将匹配算法配置为如下行为：(1) 对票池进行预排序，按票证具有可接受的延迟值的位置对票证进行分组；(2) 形成批量排序的票证进行匹配；(3) 批量创建带有票证的匹配并平衡队伍以平衡普通玩家技能。
```
"algorithm": {
"strategy": "balanced",
"balancedAttribute": "player_skill",
"batchingPreference": "largestPopulation"
},
```
# 声明玩家属性
至少，您必须声明在规则集算法中用作平衡属性的玩家属性。对战请求中，每个玩家都应包含此属性。您可以为玩家属性提供默认值，但是如果提供了玩家特定的值，则属性平衡效果最好。
# 定义团队
定义团队规模和结构的过程与小型对战相同，但 FlexMatch 填充团队的方式不同。这将影响在只有部分填充时对战可能呈现的外观。您可能想要更改响应中的最小团队规模。
FlexMatch 在向团队分配玩家时使用以下规则。首先：查找尚未达到其最低玩家要求的团队。其次：在这些团队中，查找具有最多空闲位置的团队。
对于定义多个同等规模团队的对战，玩家将按顺序添加到每个团队，直到填满。因此，即使对战没有满员，一场对战中的团队也总是有几乎相等的玩家人数。目前，还没有方法在大型对战中强制定义规模相同的团队。对于规模不对称的团队，过程稍微复杂一些。在这种情况下，玩家最开始会被分配给空闲位置最多的最大团队。然后，当空闲位置的数量在所有团队之间更均匀地分配，玩家开始被添加到更小的团队。
例如，假设您有一个由三支队伍组成的规则。红色团队和蓝色团队均设置为 `maxPlayers` = 10、`minPlayers` = 5。绿队设置为 `maxPlayers` = 3、`minPlayers` = 2。这是填充顺序：
1. 尚未有队伍到达 `minPlayers`。红色团队和蓝色团队有 10 个空闲位置，绿色团队有 3 个。前 10 个玩家被分配（每个团队 5 个）到红色团队和蓝色团队。这两个团队现在已达到 `minPlayers`。
1. 绿色团队尚未达到 `minPlayers`。接下来 2 个玩家被分配到绿色团队。绿队现已到达 `minPlayers`。
1. 在所有队伍都进入 `minPlayers` 的情况下，现在会根据空缺位置的数量分配更多玩家。红色团队和蓝色团队有 10 个空闲位置，绿色团队有 3 个。前 10 个玩家被分配（每个团队 5 个）到红色团队和蓝色团队。所有队伍现在都有 1 个空缺位置。
1. 剩下的 3 个玩家名额（每个 1 个）分配给队伍，顺序不分先后。
# 为大型对战设定规则
大型对战的对战主要依赖于平衡策略和延迟批处理优化。大多数自定义规则不可用。但是，您可以合并以下类型的规则：
+ 对玩家延迟设置硬性限制的规则。将 `latency` 规则类型与属性 `maxLatency` 一起使用。参阅 [延迟规则](match-rules-reference-ruletype.md#match-rules-reference-ruletype-latency) 引用。下面是一个将最大玩家延迟设置为 200 毫秒的示例：
```
"rules": [{
"name": "player-latency",
"type": "latency",
"maxLatency": 200
}],
```
+ 根据指定玩家属性中的接近程度对玩家进行批处理的规则。这与将平衡属性定义为大型对战算法的一部分不同，后者侧重于组建势均力敌的团队。此规则根据指定属性值（例如初学者或专家技能）的相似性对对战票证进行批处理，这往往会导致匹配在指定属性上紧密对齐的玩家。使用 `batchDistance` 规则类型，标识基于数字的属性，并指定允许的最大范围。参阅 [Batch 距离规则](match-rules-reference-ruletype.md#match-rules-reference-ruletype-batchdistance) 引用。以下是一个示例，要求对战的玩家彼此之间必须处于一个技能等级之内：
```
"rules": [{
"name": "batch-skill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 1
```
# 放宽大型对战要求
在小型对战中，您可以使用扩展来在可能没有有效匹配时随着时间推移放宽匹配要求。在大型对战中，您可以选择放宽延迟规则或团队玩家计数。
如果您在大型对战中使用自动匹配回填，请不要太快地放宽团队玩家计数。FlexMatch 仅在游戏会话启动后开始生成回填请求，在对战创建后的前几秒钟可能不会开始。在这段时间内，FlexMatch 可以创建多个部分填充的新游戏会话，尤其是在玩家计数规则降低时。因此，您最后将有多于所需的更多游戏会话，而且玩家将在这些会话之间过于稀疏地分布。最佳做法是给予玩家计数扩展的第一个步骤更长的等待时间，长到足够让游戏会话启动。由于为大型对战的回填请求提供了更高的优先级，传入玩家将在新游戏启动前被放入现有游戏。您可能需要进行实验来找到最适合您的游戏的等待时间。
下面是一个在更长的初始等待时间内逐渐降低黄色团队的玩家计数的示例。请记住，规则集扩展中的等待时间是绝对的，不是复合的。因此，第一次扩展在第五秒时进行，第二次扩展在五秒以后，即第十秒时进行。
```
"expansions": [{
"target": "teams[Yellow].minPlayers",
"steps": [{
"waitTimeSeconds": 5,
"value": 8
}, {
"waitTimeSeconds": 10,
"value": 5
}]
}]
```
# 教程：创建对战规则集
教程：创建规则集
在为 Amazon GameLift Servers FlexMatch 对战构建器创建对战规则集之前，我们建议您检查[规则集语法](match-rules-reference.md)。使用 Amazon GameLift Servers 控制台或 Amazon Command Line Interface（Amazon CLI）创建规则集后，您无法对其进行更改。
注意您可以在 Amazon 区域拥有的规则集最大数量有[服务限额](https://console.amazonaws.cn/servicequotas/home/services/gamelift/quotas/)，因此，最好将不使用的规则集删除。
**Topics**
------
#### [ Console ]
**创建规则集。**
1. 打开 Amazon GameLift Servers 控制台，地址：[https://console.aws.amazon.com/gamelift/](https://console.amazonaws.cn/gamelift/)。
1. 切换到您希望放置规则集的 Amazon 区域。在要使用规则集的对战配置中，将规则集定义到同一区域中。
1. 在导航窗格中，选择 **FlexMatch**，**对战规则集**。
1. 在**对战规则集**页面上，选择**创建规则集**。
1. 在**创建规则**页面上，执行以下操作：
1. 在**规则集设置**下，为**名称**输入一个唯一的描述性名称，您可以使用该名称在列表或事件和指标表中对其进行识别。
1. 在**规则集**中，以 JSON 格式输入您的规则集。有关设计规则集的信息，请参见[设计 FlexMatch 规则集](match-design-ruleset.md)。您也可以使用中的一个示例规则集[FlexMatch 规则集示例](match-examples.md)。
1. 选择**验证** 以验证您规则集的语法正确。规则集创建后您无法对其进行编辑，因此最好先对其进行验证。
1. （可选）在**标签**下，添加标签以帮助您管理和跟踪 Amazon 资源。
1. 选择**创建**。如果创建成功，对战构建器可以使用该规则集。
------
#### [ Amazon CLI ]
**创建规则集**
打开命令行窗口并使用 [create-matchmaking-rule-set](https://docs.amazonaws.cn/cli/latest/reference/gamelift/create-matchmaking-rule-set.html) 命令。
此示例创建设置单个团队的简单对战规则集。请确保创建规则集所在的 Amazon 区域，与将引用该规则集的对战配置的区域相同。
```
aws gamelift create-matchmaking-rule-set \
--name "SampleRuleSet123" \
--rule-set-body '{"name": "aliens_vs_cowboys", "ruleLanguageVersion": "1.0", "teams": [{"name": "cowboys", "maxPlayers": 8, "minPlayers": 4}]}'
```
如果创建请求成功，Amazon GameLift Servers 将返回一个 [MatchmakingRuleSet](https://docs.amazonaws.cn/gameliftservers/latest/apireference/API_MatchmakingRuleSet.html) 对象，其中包括您指定的设置。新规则集现在可由对战构建器使用。
------
------
#### [ Console ]
**删除规则集**
1. 打开 Amazon GameLift Servers 控制台，地址：[https://console.aws.amazon.com/gamelift/](https://console.amazonaws.cn/gamelift/)。
1. 切换到您在其中创建规则集的区域。
1. 在导航窗格中，选择 **FlexMatch**，**对战规则集**。
1. 在**对战规则集**页面上，选择要删除的规则集，然后选择**删除**。
1. 在**删除规则集**对话框中，选择**删除**以确认删除。
**注意**
如果对战配置使用规则集，Amazon GameLift Servers 会显示一条错误消息（**无法删除规则集**）。如果发生这种情况，请更改对战配置以使用其他规则集，然后重试。要了解一个规则集目前正被哪些对战配置使用，请单击该规则集名称，查看其详细信息页面。
------
#### [ Amazon CLI ]
**删除规则集**
打开命令行窗口，使用 [delete-matchmaking-rule-set](https://docs.amazonaws.cn/cli/latest/reference/gamelift/delete-matchmaking-rule-set.html) 命令删除对战规则集。
如果对战配置使用规则集，Amazon GameLift Servers 会返回一条错误消息。如果发生这种情况，请更改对战配置以使用其他规则集，然后重试。要获取当前使用某个规则集的对战配置列表，请使用命令 [describe-matchmaking-configurations](https://docs.amazonaws.cn/cli/latest/reference/gamelift/describe-matchmaking-configurations.html) 并指定该规则集名称。
此示例首先检查对战规则集的使用情况，然后删除该规则集。
```
aws gamelift describe-matchmaking-rule-sets \
--rule-set-name "SampleRuleSet123" \
--limit 10
aws gamelift delete-matchmaking-rule-set \
--name "SampleRuleSet123"
```
------
# FlexMatch 规则集示例
规则集示例
FlexMatch, 规则集可以涵盖各种对战情况。以下示例符合 FlexMatch 配置结构和属性表达式语言。完整复制这些规则集或根据需要选择组件。
有关使用 FlexMatch 规则和规则集的更多信息，请参阅以下主题：
**注意**
当评估包含多个玩家的对战票证时，请求中的所有玩家都必须满足对战要求。
**Topics**
+ [
# 示例：创建两个势均力敌的玩家团队
](match-examples-1.md)
+ [
# 示例：创建水平不对等的团队（猎人对战怪物）
](match-examples-2.md)
+ [
# 示例：设置团队级要求和延迟限制
](match-examples-3.md)
+ [
# 示例：使用显式排序以查找最佳对战游戏
](match-examples-4.md)
+ [
# 示例：在多个玩家属性之间查找交集
](match-examples-5.md)
+ [
# 示例：在所有玩家之间比较属性
](match-examples-6.md)
+ [
# 示例：创建大型对战
](match-examples-7.md)
+ [
# 示例：创建多团队大型对战
](match-examples-8.md)
+ [
# 示例：创建与属性相似的玩家的大型对战
](match-examples-9.md)
+ [
# 示例：使用复合规则创建与属性相似或选择相似的玩家的对战
](match-examples-10.md)
+ [
# 示例：创建使用玩家屏蔽名单的规则
](match-examples-11.md)
# 示例：创建两个势均力敌的玩家团队
此示例说明如何按照以下说明设置两个势均力敌的玩家对战团队。
+ 创建两个玩家团队。
+ 每个团队包含四到八个玩家。
+ 最终团队必须具有相同数量的玩家。
+ 附上玩家的技能水平 (如果未提供，则默认为 10)。
+ 选择与其他玩家技能水平相当的玩家。确保这两个团队的平均玩家技能在 10 点以内。
+ 如果未能快速填充对战游戏，则放宽玩家技能要求以在合理的时间内完成对战游戏。
+ 5 秒之后，扩大搜索范围以允许创建平均玩家技能在 50 点以内的团队。
+ 15 秒之后，扩大搜索范围以允许创建平均玩家技能在 100 点以内的团队。
使用此规则集的说明：
+ 此示例允许创建包含 4 到 8 位玩家的任何规模的团队 (但两个团队的规模必须相同)。对于在有效规模范围内的团队，对战构建器会尽量尝试匹配允许的最大玩家数量。
+ `FairTeamSkill` 规则集可确保根据玩家技能构建对战团队。要对每个新的潜在玩家评估此规则，FlexMatch, 会暂时将玩家加入团队并计算平均值。如果规则失败，则不会将潜在玩家添加到对战游戏。
+ 由于这两个团队具有相同的结构，您可以选择仅创建一个团队定义，并将团队数量设置为“2”。在这种情况下，如果您将团队命名为“aliens”，那么为您的团队分配的名称将为“aliens\$11”和“aliens\$12”。
```
{
"name": "aliens_vs_cowboys",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
}],
"teams": [{
"name": "cowboys",
"maxPlayers": 8,
"minPlayers": 4
}, {
"name": "aliens",
"maxPlayers": 8,
"minPlayers": 4
}],
"rules": [{
"name": "FairTeamSkill",
"description": "The average skill of players in each team is within 10 points from the average skill of all players in the match",
"type": "distance",
// get skill values for players in each team and average separately to produce list of two numbers
"measurements": [ "avg(teams[*].players.attributes[skill])" ],
// get skill values for players in each team, flatten into a single list, and average to produce an overall average
"referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10 // minDistance would achieve the opposite result
}, {
"name": "EqualTeamSizes",
"description": "Only launch a game when the number of players in each team matches, e.g. 4v4, 5v5, 6v6, 7v7, 8v8",
"type": "comparison",
"measurements": [ "count(teams[cowboys].players)" ],
"referenceValue": "count(teams[aliens].players)",
"operation": "=" // other operations: !=, <, <=, >, >=
}],
"expansions": [{
"target": "rules[FairTeamSkill].maxDistance",
"steps": [{
"waitTimeSeconds": 5,
"value": 50
}, {
"waitTimeSeconds": 15,
"value": 100
}]
}]
}
```
# 示例：创建水平不对等的团队（猎人对战怪物）
此示例描述了一组玩家搜捕单个怪物的游戏模式。玩家可以选择猎人或怪物角色。猎人指定他们希望对战的怪物的最低技能水平。可随时间推移放宽猎人团队的最小规模以完成对战游戏。此方案规定了以下说明：
+ 创建一个包含五个猎人的团队。
+ 创建一个包含单个怪物的团队。
+ 包含以下玩家属性：
+ 玩家的技能水平（如果未提供，则默认为 10）。
+ 玩家首选的怪物技能水平 (如果未提供，则默认为 10)。
+ 玩家是否想成为怪物 (如果未提供，则默认为 0 或 false)。
+ 根据以下条件选择将成为怪物的玩家：
+ 玩家必须请求怪物角色。
+ 玩家必须满足或超过已添加到猎人团队的玩家的首选最高技能水平。
+ 根据以下条件选择将加入猎人团队的玩家：
+ 请求怪物角色的玩家无法加入猎人团队。
+ 如果怪物角色已填充，玩家必须要有低于建议怪物技能的怪物技能水平。
+ 如果对战游戏未快速填满，则放宽猎人团队的最小规模，如下所示：
+ 30 秒后，允许启动猎人团队只包含四个玩家的游戏。
+ 60 秒后，允许启动猎人团队只包含三个玩家的游戏。
使用此规则集的说明：
+ 通过为猎人和怪物分别创建两个单独的团队，您可以根据不同的条件评估团队成员。
```
{
"name": "players_vs_monster_5_vs_1",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
},{
"name": "desiredSkillOfMonster",
"type": "number",
"default": 10
},{
"name": "wantsToBeMonster",
"type": "number",
"default": 0
}],
"teams": [{
"name": "players",
"maxPlayers": 5,
"minPlayers": 5
}, {
"name": "monster",
"maxPlayers": 1,
"minPlayers": 1
}],
"rules": [{
"name": "MonsterSelection",
"description": "Only users that request playing as monster are assigned to the monster team",
"type": "comparison",
"measurements": ["teams[monster].players.attributes[wantsToBeMonster]"],
"referenceValue": 1,
"operation": "="
},{
"name": "PlayerSelection",
"description": "Do not place people who want to be monsters in the players team",
"type": "comparison",
"measurements": ["teams[players].players.attributes[wantsToBeMonster]"],
"referenceValue": 0,
"operation": "="
},{
"name": "MonsterSkill",
"description": "Monsters must meet the skill requested by all players",
"type": "comparison",
"measurements": ["avg(teams[monster].players.attributes[skill])"],
"referenceValue": "max(teams[players].players.attributes[desiredSkillOfMonster])",
"operation": ">="
}],
"expansions": [{
"target": "teams[players].minPlayers",
"steps": [{
"waitTimeSeconds": 30,
"value": 4
},{
"waitTimeSeconds": 60,
"value": 3
}]
}]
}
```
# 示例：设置团队级要求和延迟限制
此示例说明如何设置玩家团队，并为每个团队应用规则集，而不是为每个玩家应用规则集。它使用单个定义创建三个平均的对战团队。它还会设置所有玩家的最大延迟。随着时间的推移可以放宽延迟最大值以完成对战游戏。此方案规定了以下说明：
+ 创建三个玩家团队。
+ 每个团队包含三到五个玩家。
+ 最终团队必须包含数量相同或基本相同的玩家 (一个团队中)。
+ 包含以下玩家属性：
+ 玩家的技能水平（如果未提供，则默认为 10）。
+ 玩家的人物角色 (如果未提供，则默认为“peasant”)。
+ 选择与对战游戏中其他玩家技能水平相当的玩家。
+ 确保每个团队的平均玩家技能在 10 点以内。
+ 将团队数量限制为“medic”角色的以下数量：
+ 整个对战游戏最多可以包含 5 个医生。
+ 仅匹配报告 50 毫秒或更少延迟的玩家。
+ 如果对战游戏未快速填满，则放宽玩家的延迟要求，如下所示：
+ 10 秒之后，允许将玩家的延迟时间值增加到 100 毫秒。
+ 20 秒之后，允许将玩家的延迟时间值增加到 150 毫秒。
使用此规则集的说明：
+ 规则集可确保根据玩家技能构建对战团队。为评估 `FairTeamSkill` 规则，FlexMatch 会暂时将潜在玩家加入团队并计算团队中玩家的平均技能。然后，它将规则与两个团队中的玩家平均技能进行比较。如果规则失败，则不会将潜在玩家添加到对战游戏。
+ 团队和对战游戏级别的要求 (医生总数) 通过一组规则实现。此规则类型会获取所有玩家的角色属性列表，并针对最大数量进行检查。使用 `flatten` 为所有团队中的所有玩家创建列表。
+ 根据延迟进行评估时，请注意以下几点：
+ 延迟数据在对战请求中作为玩家对象的一部分提供。它不是玩家属性，因此无需列出。要获得准确的延迟测量值，请使用 Amazon GameLift Servers 的 UDP ping 信标。这些端点使您能够测量玩家设备与每个潜在托管位置之间的实际 UDP 网络延迟，从而比使用 ICMP ping 更准确地做出放置决策。有关使用 UDP ping 信标测量延迟的更多信息，请参阅 [UDP ping 信标](https://docs.amazonaws.cn/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html)。
+ 对战构建器按区域评估延迟。延迟高于最大延迟的任何区域都将被忽略。要让对战游戏接受，玩家必须至少有一个区域的延迟低于最大延迟。
+ 如果对战请求忽略一个或多个玩家的延迟数据，则会拒绝所有对战游戏的请求。
```
{
"name": "three_team_game",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
},{
"name": "character",
"type": "string_list",
"default": [ "peasant" ]
}],
"teams": [{
"name": "trio",
"minPlayers": 3,
"maxPlayers": 5,
"quantity": 3
}],
"rules": [{
"name": "FairTeamSkill",
"description": "The average skill of players in each team is within 10 points from the average skill of players in the match",
"type": "distance",
// get players for each team, and average separately to produce list of 3
"measurements": [ "avg(teams[*].players.attributes[skill])" ],
// get players for each team, flatten into a single list, and average to produce overall average
"referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10 // minDistance would achieve the opposite result
}, {
"name": "CloseTeamSizes",
"description": "Only launch a game when the team sizes are within 1 of each other. e.g. 3 v 3 v 4 is okay, but not 3 v 5 v 5",
"type": "distance",
"measurements": [ "max(count(teams[*].players))"],
"referenceValue": "min(count(teams[*].players))",
"maxDistance": 1
}, {
"name": "OverallMedicLimit",
"description": "Don't allow more than 5 medics in the game",
"type": "collection",
// This is similar to above, but the flatten flattens everything into a single
// list of characters in the game.
"measurements": [ "flatten(teams[*].players.attributes[character])"],
"operation": "contains",
"referenceValue": "medic",
"maxCount": 5
}, {
"name": "FastConnection",
"description": "Prefer matches with fast player connections first",
"type": "latency",
"maxLatency": 50
}],
"expansions": [{
"target": "rules[FastConnection].maxLatency",
"steps": [{
"waitTimeSeconds": 10,
"value": 100
}, {
"waitTimeSeconds": 20,
"value": 150
}]
}]
}
```
# 示例：使用显式排序以查找最佳对战游戏
此示例设置了包含三个玩家的两个团队的简单对战游戏。它介绍了如何使用显式排序规则才能尽快找到最佳对战游戏。这些规则会为对战票证预排序，以根据特定的关键要求创建最佳对战游戏。此方案根据以下说明实现：
+ 创建两个玩家团队。
+ 每个团队只包含三个玩家。
+ 包含以下玩家属性：
+ 经验等级 (如果未提供，则默认为 50)。
+ 首选游戏模式 (可以列出多个值) (如果未提供，则默认为“coop”和“deathmatch”)。
+ 首选游戏地图，包括地图名称和首选权重 (如果未提供，则默认使用 `"defaultMap"` 和权重 100)。
+ 设置预排序：
+ 根据与基准点玩家相同的游戏地图的首选项来对玩家排序。玩家可以有多个最喜欢的游戏地图，因此本示例使用首选项值。
+ 根据玩家与基准点玩家的经验等级的接近程度对玩家排序。采用这种排序方式，所有玩家在所有团队中的经验等级会尽可能地接近。
+ 所有团队中的所有玩家必须至少选择一个共同的游戏模式。
+ 所有团队中的所有玩家必须至少选择一个共同的游戏地图。
使用此规则集的说明：
+ 游戏地图排序采用与 mapPreference 属性值进行比较的绝对排序。由于它是规则集中的第一个，此排序将首先执行。
+ 经验排序采用比较潜在玩家的技能级别与基准点玩家的技能的距离排序。
+ 排序按它们在规则集中的排列顺序执行。在这种情况下，玩家先按游戏地图首选项进行排序，然后按经验等级排序。
```
{
"name": "multi_map_game",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "experience",
"type": "number",
"default": 50
}, {
"name": "gameMode",
"type": "string_list",
"default": [ "deathmatch", "coop" ]
}, {
"name": "mapPreference",
"type": "string_number_map",
"default": { "defaultMap": 100 }
}, {
"name": "acceptableMaps",
"type": "string_list",
"default": [ "defaultMap" ]
}],
"teams": [{
"name": "red",
"maxPlayers": 3,
"minPlayers": 3
}, {
"name": "blue",
"maxPlayers": 3,
"minPlayers": 3
}],
"rules": [{
// We placed this rule first since we want to prioritize players preferring the same map
"name": "MapPreference",
"description": "Favor grouping players that have the highest map preference aligned with the anchor's favorite",
// This rule is just for sorting potential matches. We sort by the absolute value of a field.
"type": "absoluteSort",
// Highest values go first
"sortDirection": "descending",
// Sort is based on the mapPreference attribute.
"sortAttribute": "mapPreference",
// We find the key in the anchor's mapPreference attribute that has the highest value.
// That's the key that we use for all players when sorting.
"mapKey": "maxValue"
}, {
// This rule is second because any tie-breakers should be ordered by similar experience values
"name": "ExperienceAffinity",
"description": "Favor players with similar experience",
// This rule is just for sorting potential matches. We sort by the distance from the anchor.
"type": "distanceSort",
// Lowest distance goes first
"sortDirection": "ascending",
"sortAttribute": "experience"
}, {
"name": "SharedMode",
"description": "The players must have at least one game mode in common",
"type": "collection",
"operation": "intersection",
"measurements": [ "flatten(teams[*].players.attributes[gameMode])"],
"minCount": 1
}, {
"name": "MapOverlap",
"description": "The players must have at least one map in common",
"type": "collection",
"operation": "intersection",
"measurements": [ "flatten(teams[*].players.attributes[acceptableMaps])"],
"minCount": 1
}]
}
```
# 示例：在多个玩家属性之间查找交集
此示例说明如何使用集合规则，在两个或更多玩家属性中查找交集。在处理集合时，您可以对单个属性使用 `intersection` 操作，并对多个属性使用 `reference_intersection_count` 操作。
为了说明这种方法，此示例会在对战游戏中根据玩家的角色首选项来评估玩家。示例游戏是一种 “free-for-all” 风格，其中一场比赛中的所有玩家都是对手。每个玩家需要 (1) 为自己选择一个角色，(2) 选择他们希望作为对手的角色。我们需要一个规则，该规则可确保对战游戏中的每位玩家所使用的角色都位于所有其他玩家的首选对手列表中。
此示例规则集描述了一个具有以下特征的对战游戏：
+ 团队结构：一个团队 5 个玩家
+ 玩家属性：
+ *myCharacter*：玩家的选定角色。
+ *preferredOpponents*：玩家希望作为对手的角色的列表。
+ 对战游戏规则：如果每个正在使用的角色都位于各个玩家的首选对手列表中，则潜在的对战游戏是可接受的。
为了实施该对战游戏规则，此示例使用具有以下属性值的集合规则：
+ 操作 – 使用 `reference_intersection_count` 操作来评估测量值中的每个字符串列表与参考值中的字符串列表的相交情况。
+ 测量值 – 使用 `flatten` 属性表达式来创建一个字符串列表的列表，其中每个字符串列表包含一个玩家的 *myCharacter* 属性值。
+ 参考值 – 使用 `set_intersection` 属性表达式创建所有 *preferredOpponents* 属性值的字符串列表，这些属性值对于对战游戏中的每个玩家是通用的。
+ 限制 – `minCount` 设置为 1，以确保每个玩家的选定角色（测量值中的一个字符串列表）匹配至少一个对所有玩家通用的首选对手。（参考值中的字符串）。
+ 扩展 如果对战游戏在 15 秒内未满员，则放松最小交集要求。
此规则的流程如下：
1. 将一位玩家添加到潜在对战游戏。重新计算参考值 (字符串列表)，以便包含与新玩家的首选对手列表的交集。重新计算测量值 (字符串列表的列表)，以便将新玩家的选定角色作为新的字符串列表添加。
1. Amazon GameLift Servers 验证测量值 (玩家的选定角色) 中的每个字符串列表与参考值 (玩家的首选对手) 中的至少一个字符串相交。在本示例中，由于测量值中的每个字符串列表中仅包含一个值，因此交集为 0 或 1。
1. 如果测量值中的任何字符串列表与参考值字符串列表不相交，则该规则失败，并且从潜在对战游戏中删除该新玩家。
1. 如果对战游戏在 15 秒内未满员，则放弃对手匹配要求，以便在对战游戏中填满剩余的玩家位置。
```
{
"name": "preferred_characters",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "myCharacter",
"type": "string_list"
}, {
"name": "preferredOpponents",
"type": "string_list"
}],
"teams": [{
"name": "red",
"minPlayers": 5,
"maxPlayers": 5
}],
"rules": [{
"description": "Make sure that all players in the match are using a character that is on all other players' preferred opponents list.",
"name": "OpponentMatch",
"type": "collection",
"operation": "reference_intersection_count",
"measurements": ["flatten(teams[*].players.attributes[myCharacter])"],
"referenceValue": "set_intersection(flatten(teams[*].players.attributes[preferredOpponents]))",
"minCount":1
}],
"expansions": [{
"target": "rules[OpponentMatch].minCount",
"steps": [{
"waitTimeSeconds": 15,
"value": 0
}]
}]
}
```
# 示例：在所有玩家之间比较属性
此示例说明如何在一组玩家之间比较玩家属性。
此示例规则集描述了一个具有以下特征的对战游戏：
+ 团队结构：两个单人游戏团队
+ 玩家属性：
+ *gameMode*：玩家选择的游戏类型 (如果未提供，则默认设置为“基于次序”)。
+ *gameMap*：玩家选择的游戏世界 (如果未提供，则默认设置为 1)。
+ *character*：玩家选择的角色（无默认值，表示玩家必须指定角色）。
+ 对战游戏规则：匹配的玩家必须满足以下要求：
+ 玩家必须选择相同的游戏模式。
+ 玩家必须选择相同的游戏地图。
+ 玩家必须选择不同的角色。
使用此规则集的说明：
+ 为了实施该对战游戏规则，此示例使用比较规则来检查所有玩家的属性值。对于游戏模式和地图，该规则验证值是相同的。对于角色，该规则验证值是不同的。
+ 此示例使用一个玩家定义与数量属性来创建两个玩家团队。为团队分配了下列名称：“player\$11”和“player\$12”。
```
{
"name": "",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "gameMode",
"type": "string",
"default": "turn-based"
}, {
"name": "gameMap",
"type": "number",
"default": 1
}, {
"name": "character",
"type": "number"
}],
"teams": [{
"name": "player",
"minPlayers": 1,
"maxPlayers": 1,
"quantity": 2
}],
"rules": [{
"name": "SameGameMode",
"description": "Only match players when they choose the same game type",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[gameMode])"]
}, {
"name": "SameGameMap",
"description": "Only match players when they're in the same map",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[gameMap])"]
}, {
"name": "DifferentCharacter",
"description": "Only match players when they're using different characters",
"type": "comparison",
"operation": "!=",
"measurements": ["flatten(teams[*].players.attributes[character])"]
}]
}
```
# 示例：创建大型对战
此示例说明如何为超过 40 位玩家的对战设置规则集。当规则集描述 maxPlayer 总数大于 40 的团队时，该团队会被处理为大型对战。参阅[设计 FlexMatch 大型对战规则集](match-design-rulesets-large.md)了解更多信息。
此示例规则集使用以下说明创建对战：
+ 创建一个最多有 200 位玩家的团队，玩家人数最低要求为 175 位。
+ 平衡条件：根据相似的技能级别选择玩家。所有玩家均必须报告其技能级别才能被匹配。
+ 批处理首选项：在创建对战时按类似的平衡条件分组玩家。
+ 延迟规则：将可接受的最大玩家延迟设置为 150 毫秒。
+ 如果未能快速填充对战游戏，则放宽要求以在合理的时间内完成匹配。
+ 10 秒后，接受有 150 位玩家的团队。
+ 12 秒后，将可接受的最大延迟提高到 200 毫秒。
+ 15 秒后，接受有 100 位玩家的团队。
使用此规则集的说明：
+ 由于算法使用“最大群体”批处理首选项，玩家会根据平衡条件排序。因此，对战往往填得更满，包含技能更加类似的玩家。所有玩家均符合可接受的延迟要求，但可能无法在他们的位置获得可能的最佳延迟。
+ 此规则集中使用的算法策略“最大群体”是默认设置。要使用默认设置，您可以选择忽略此设置。
+ 如果您已启用了对战回填，请不要太快地放宽玩家计数要求，否则，您最后可能会有太多部分填充的游戏会话。参阅[放宽大型对战要求](match-design-rulesets-large-relax.md)了解更多信息。
```
{
"name": "free-for-all",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number"
}],
"algorithm": {
"balancedAttribute": "skill",
"strategy": "balanced",
"batchingPreference": "largestPopulation"
},
"teams": [{
"name": "Marauders",
"maxPlayers": 200,
"minPlayers": 175
}],
"rules": [{
"name": "low-latency",
"description": "Sets maximum acceptable latency",
"type": "latency",
"maxLatency": 150
}],
"expansions": [{
"target": "rules[low-latency].maxLatency",
"steps": [{
"waitTimeSeconds": 12,
"value": 200
}],
}, {
"target": "teams[Marauders].minPlayers",
"steps": [{
"waitTimeSeconds": 10,
"value": 150
}, {
"waitTimeSeconds": 15,
"value": 100
}]
}]
}
```
# 示例：创建多团队大型对战
此示例说明如何为有多个团队可能超过 40 位玩家的对战设置规则集。此示例说明如何使用一个定义创建多个相同的团队，以及规模不对称的团队如何在对战创建过程中填充。
此示例规则集使用以下说明创建对战：
+ 创建十个相同的“猎人”团队，每个团队最多有 15 位玩家，并创建一个刚好有 5 位玩家的“怪物”团队。
+ 平衡条件：根据怪物技能的数量选择玩家。如果玩家未报告其技能计数，请使用默认值 5。
+ 批处理首选项：根据玩家报告最快玩家延迟的区域分组玩家。
+ 延迟规则：将可接受的最大玩家延迟设置为 200 毫秒。
+ 如果未能快速填充对战游戏，则放宽要求以在合理的时间内完成匹配。
+ 15 秒后，接受有 10 位玩家的团队。
+ 20 秒后，接受有 8 位玩家的团队。
使用此规则集的说明：
+ 此规则集定义最多可能容纳 155 位玩家的团队，这让它成为大型对战。
+ 由于算法使用“最快区域”批处理首选项，玩家更可能被置于他们报告更快延迟的区域，而不是他们报告较高（但可接受）延迟的区域。同时，可能有更少玩家的对战和平衡条件（怪物技能的数量）可能会变化更大。
+ 当为多团队定义（数量 > 1）定义了扩展时，扩展将应用于使用该定义创建的所有团队。因此，通过放宽猎人团队的最低玩家设置，全部十个猎人团队都会受到均等的影响。
+ 由于此规则集经过优化以最大程度地减少玩家延迟，延迟规则将充当“捕获全部”方法来排除没有可接受连接选项的玩家。我们不需要放宽此要求。
+ 下面介绍了 FlexMatch 在有任何扩展生效之前如何针对此规则集填充对战：
+ 还没有团队达到 minPlayers 计数。猎人团队有 15 个空闲位置，怪物团队有 5 个空闲位置。
+ 前 100 个玩家被分配（每个团队 10 个）到十个猎人团队。
+ 接下来 22 个玩家按顺序分配（每个团队 2 个）到猎人团队和怪物团队。
+ 猎人团队已达到每个团队 12 个玩家的 minPlayers 计数。怪物团队有 2 个玩家，还未达到 minPlayers 计数。
+ 接下来的三个玩家被分配到怪物团队。
+ 所有团队均达到 minPlayers 计数。每个猎人团队都有三个空闲位置。怪物团队已满。
+ 最后 30 个玩家按顺序分配到猎人团队，确保所有猎人团队具有几乎相同的规模（加上或减去一个玩家）。
+ 如果您已为使用此规则集创建的对战启用了回填，请不要太快地放宽玩家计数要求，否则，您最后可能会有太多部分填充的游戏会话。参阅[放宽大型对战要求](match-design-rulesets-large-relax.md)了解更多信息。
```
{
"name": "monster-hunters",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "monster-kills",
"type": "number",
"default": 5
}],
"algorithm": {
"balancedAttribute": "monster-kills",
"strategy": "balanced",
"batchingPreference": "fastestRegion"
},
"teams": [{
"name": "Monsters",
"maxPlayers": 5,
"minPlayers": 5
}, {
"name": "Hunters",
"maxPlayers": 15,
"minPlayers": 12,
"quantity": 10
}],
"rules": [{
"name": "latency-catchall",
"description": "Sets maximum acceptable latency",
"type": "latency",
"maxLatency": 150
}],
"expansions": [{
"target": "teams[Hunters].minPlayers",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 20,
"value": 8
}]
}]
}
```
# 示例：创建与属性相似的玩家的大型对战
此示例说明如何使用 `batchDistance` 为两个团队的对战设置规则集。在示例中：
+ 该 `SimilarLeague` 规则确保一场对战中的所有玩家与其他玩家具有 2 以内的 `league`。
+ 该 `SimilarSkill` 规则确保一场对战中的所有玩家与其他玩家具有 10 以内的 `skill`。如果玩家等待 10 秒，则距离将扩大到 20 秒。如果玩家等待 20 秒，则距离将扩大到 40 秒。
+ 该 `SameMap` 规则确保对战中的所有玩家都提出同样的 `map`。
+ 该 `SameMode` 规则确保对战中的所有玩家都提出同样的 `mode`。
```
{
"ruleLanguageVersion": "1.0",
"teams": [{
"name": "red",
"minPlayers": 100,
"maxPlayers": 100
}, {
"name": "blue",
"minPlayers": 100,
"maxPlayers": 100
}],
"algorithm": {
"strategy":"balanced",
"balancedAttribute": "skill",
"batchingPreference":"fastestRegion"
},
"playerAttributes": [{
"name": "league",
"type": "number"
},{
"name": "skill",
"type": "number"
},{
"name": "map",
"type": "string"
},{
"name": "mode",
"type": "string"
}],
"rules": [{
"name": "SimilarLeague",
"type": "batchDistance",
"batchAttribute": "league",
"maxDistance": 2
}, {
"name": "SimilarSkill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 10
}, {
"name": "SameMap",
"type": "batchDistance",
"batchAttribute": "map"
}, {
"name": "SameMode",
"type": "batchDistance",
"batchAttribute": "mode"
}],
"expansions": [{
"target": "rules[SimilarSkill].maxDistance",
"steps": [{
"waitTimeSeconds": 10,
"value": 20
}, {
"waitTimeSeconds": 20,
"value": 40
}]
}]
}
```
# 示例：使用复合规则创建与属性相似或选择相似的玩家的对战
此示例说明如何使用 `compound` 为两个团队的对战设置规则集。在示例中：
+ 该 `SimilarLeagueDistance` 规则确保一场对战中的所有玩家与其他玩家具有 2 以内的 `league`。
+ 该 `SimilarSkillDistance` 规则确保一场对战中的所有玩家与其他玩家具有 10 以内的 `skill`。如果玩家等待 10 秒，则距离将扩大到 20 秒。如果玩家等待 20 秒，则距离将扩大到 40 秒。
+ 该 `SameMapComparison` 规则确保对战中的所有玩家都提出同样的 `map`。
+ 该 `SameModeComparison` 规则确保对战中的所有玩家都提出同样的 `mode`。
+ 如果满足以下任意条件，`CompoundRuleMatchmaker` 规则确保：
+ 一场对战中的玩家提出了同样的 `map` 和 `mode`。
+ 对战中的玩家具有不相上下的 `skill` 和 `league` 属性。
```
{
"ruleLanguageVersion": "1.0",
"teams": [{
"name": "red",
"minPlayers": 10,
"maxPlayers": 20
}, {
"name": "blue",
"minPlayers": 10,
"maxPlayers": 20
}],
"algorithm": {
"strategy":"balanced",
"balancedAttribute": "skill",
"batchingPreference":"fastestRegion"
},
"playerAttributes": [{
"name": "league",
"type": "number"
},{
"name": "skill",
"type": "number"
},{
"name": "map",
"type": "string"
},{
"name": "mode",
"type": "string"
}],
"rules": [{
"name": "SimilarLeagueDistance",
"type": "distance",
"measurements": ["max(flatten(teams[*].players.attributes[league]))"],
"referenceValue": "min(flatten(teams[*].players.attributes[league]))",
"maxDistance": 2
}, {
"name": "SimilarSkillDistance",
"type": "distance",
"measurements": ["max(flatten(teams[*].players.attributes[skill]))"],
"referenceValue": "min(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10
}, {
"name": "SameMapComparison",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[map])"]
}, {
"name": "SameModeComparison",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[mode])"]
}, {
"name": "CompoundRuleMatchmaker",
"type": "compound",
"statement": "or(and(SameMapComparison, SameModeComparison), and(SimilarSkillDistance, SimilarLeagueDistance))"
}],
"expansions": [{
"target": "rules[SimilarSkillDistance].maxDistance",
"steps": [{
"waitTimeSeconds": 10,
"value": 20
}, {
"waitTimeSeconds": 20,
"value": 40
}]
}]
}
```
# 示例：创建使用玩家屏蔽名单的规则
此示例说明了一个规则集，该规则集允许玩家避免与某些其他玩家对战。玩家可以创建屏蔽名单，对战构建器在为对战选择玩家时对其进行评估。有关添加屏蔽名单或避免列表特征的更多指导，参阅 [Amazon 游戏博客](https://www.amazonaws.cn/blogs/gametech/category/game-development/amazon-gamelift/)。
此方案规定了以下说明：
+ 创建两支由五名玩家组成的队伍。
+ 传入玩家的屏蔽名单，即玩家名单 IDs （最多 100 个）。
+ 将所有玩家与每位玩家的屏蔽名单进行比较，如果发现任何被封锁的玩家， IDs 则拒绝提议的对战。
使用此规则集的说明：
+ 在评估新玩家以加入拟议的对战（或填补现有对战中的位置）时，该玩家可能会因为以下任一原因而被拒绝：
+ 如果新玩家出现在任何已被选中参加对战的玩家的屏蔽名单上。
+ 如果新玩家的屏蔽名单上有已经被选中参加对战的玩家。
+ 如图所示，该规则集禁止将玩家与其屏蔽名单上的任何玩家进行匹配。您可以通过添加规则扩展并增加该`maxCount`值来将此要求更改为首选项（也称为“避免列表）。
```
{
"name": "Player Block List",
"ruleLanguageVersion": "1.0",
"teams": [{
"maxPlayers": 5,
"minPlayers": 5,
"name": "red"
}, {
"maxPlayers": 5,
"minPlayers": 5,
"name": "blue"
}],
"playerAttributes": [{
"name": "BlockList",
"type": "string_list",
"default": []
}],
"rules": [{
"name": "PlayerIdNotInBlockList",
"type": "collection",
"operation": "reference_intersection_count",
"measurements": "flatten(teams[*].players.attributes[BlockList])",
"referenceValue": "flatten(teams[*].players[playerId])",
"maxCount": 0
}]
}
```
# 创建对战配置
创建对战配置
要设置Amazon GameLift ServersFlexMatch媒人来处理配对请求，请创建配对配置。使用Amazon GameLift Servers控制台或 Amazon Command Line Interface (Amazon CLI)。有关创建对战构建器的更多信息，请参阅[设计 FlexMatch 对战构建器](match-configuration.md)。
**Topics**
+ [
# 教程：为 Amazon GameLift Servers 托管创建对战构建器
](match-create-configuration-withqueue.md)
+ [
# 教程：为独立版 FlexMatch 创建对战构建器
](match-create-configuration-standalone.md)
+ [
# 教程：编辑对战配置
](match-create-configuration-edit.md)
# 教程：为 Amazon GameLift Servers 托管创建对战构建器
教程：为 托管创建对战构建器
在创建配对配置之前，[请创建规则集](match-create-ruleset.md)和Amazon GameLift Servers[游戏会话队列](https://docs.amazonaws.cn/gameliftservers/latest/developerguide/queues-creating.html)以与匹配器一起使用。
------
#### [ Console ]
1. 在 [Amazon GameLift Servers 控制台](https://console.amazonaws.cn/gamelift/)的导航窗格中，选择**对战配置**。
1. 切换到您要创建媒人的 Amazon 区域。
1. 在**对战配置**页面上，选择**创建对战配置**。
1. 在**定义配置详细信息**页面的**对战配置详细信息**下，执行以下操作：
1. 在**姓名**中，输入可以帮助您在列表和指标中识别匹配者的姓名。对战构建器名称在区域中必须唯一。对战请求会使用其名称和区域标识要使用的对战构建器。
1. （可选）对于**描述**，添加有助于识别对战构建器的描述。
1. 对于**规则集**，从列表中选择要与对战构建器一起使用的规则集。该列表包含在当前区域中已创建的所有规则集。
1. 对于 **FlexMatch 模式**，请为 Amazon GameLift Servers 托管式托管选择**托管**。此模式会提示 FlexMatch 将成功的匹配传递到指定的游戏会话队列。
1. 对于 **Amazon 区域**，选择您配置要与对战构建器一起使用的游戏会话队列的区域。
1. 对于**队列**，选择要用于该对战构建器的游戏会话队列。
1. 选择**下一步**。
1. 在**配置设置**页面的**对战设置**下，执行以下操作：
1. 对于**请求超时**，键入对战构建器针对每个请求完成对战游戏的最长时间（以秒为单位）。FlexMatch 会取消超过此时间的对战请求。
1. 对于**回填模式**，请选择一种处理对战回填的模式。
+ 选择**自动**打开自动回填特征。
+ 要创建自己的回填请求管理或不使用回填特征，请选择**手动**。
1. （可选）对于**额外玩家人数**，请设置一场对战中要保持开放的玩家位置数量。FlexMatch 后续可以在这些位置加入玩家。
1. （可选）在**对战接受选项**下，在**需要接受**中，如果您想要求提议的对战中的每位玩家积极接受参与对战，请选择**必填**。如果您选择此选项，则在**接受超时**中，设置您希望对战构建器在取消对战之前等待玩家接受的时间（以秒为单位）。
1. （可选）在**事件通知设置**下，执行以下操作：
1. （可选）对于 **SNS 主题**，选择用于接收对战活动通知的 Amazon Simple Notification Service (Amazon SNS) 主题。如果您尚未设置，可以在以后通过编辑对战配置来添加此信息。有关更多信息，请参阅 [设置 FlexMatch 事件通知](match-notification.md)。
1. （可选）对于**自定义事件数据**，输入要与该对战构建器关联的、事件消息中的任何自定义数据。FlexMatch 会在与对战构建器关联的每个事件中包含此数据。
1. （可选）展开**其他游戏数据**，然后执行以下操作：
1. （可选）对于**游戏会话数据**，请输入您希望 FlexMatch 向使用此对战配置进行的匹配开始的新游戏会话提供的任何其他与游戏相关的信息。
1. （可选）对于**游戏属性**，添加包含有关新游戏会话信息的键值对属性。
1. （可选）在 “**标签**” 下，添加标签以帮助您管理和跟踪 Amazon 资源。
1. 选择**下一步**。
1. 在**查看和创建**页面上，查看您的选择，然后选择**创建**。如果创建成功，则对战构建器会立即准备好接受对战请求。
------
#### [ Amazon CLI ]
要使用创建配对配置 Amazon CLI，请打开命令行窗口，然后使用[create-matchmaking-configuration](https://docs.amazonaws.cn/cli/latest/reference/gamelift/create-matchmaking-configuration.html)命令定义新的匹配器。
此示例命令创建了一个新的对战配置，该配置需要玩家接受并启用自动回填功能。它还为 FlexMatch 保留了两个玩家位置，以便以后添加玩家，并提供一些游戏会话数据。
```
aws gamelift create-matchmaking-configuration \
--name "SampleMatchamker123" \
--description "The sample test matchmaker with acceptance" \
--flex-match-mode WITH_QUEUE \
--game-session-queue-arns "arn:aws:gamelift:us-west-2:111122223333:gamesessionqueue/MyGameSessionQueue" \
--rule-set-name "MyRuleSet" \
--request-timeout-seconds 120 \
--acceptance-required \
--acceptance-timeout-seconds 30 \
--backfill-mode AUTOMATIC \
--notification-target "arn:aws:sns:us-west-2:111122223333:My_Matchmaking_SNS_Topic" \
--additional-player-count 2 \
--game-session-data "key=map,value=winter444"
```
如果配对配置创建请求成功，则Amazon GameLift Servers返回一个包含您为匹配器请求的设置的[MatchmakingConfiguration](https://docs.amazonaws.cn/gameliftservers/latest/apireference/API_MatchmakingConfiguration.html)对象。新对战构建器已准备好接受对战请求。
------
# 教程：为独立版 FlexMatch 创建对战构建器
在创建对战配置之前，必须创建要与对战构建器一起使用的[规则集](match-create-ruleset.md)。
------
#### [ Console ]
1. 在家中打开[https://console.aws.amazon.com/gamelift/主Amazon GameLift Servers](https://console.amazonaws.cn/gamelift/)机。
1. 切换到您要创建媒人的 Amazon 区域。有关支持 FlexMatch 对战配置的区域的列表，请参阅[为对战构建器选择一个区域](match-configuration-regions.md)。
1. 在导航窗格中，选择 **FlexMatch**、**对战配置**。
1. 在**对战配置**页面上，选择**创建对战配置**。
1. 在**定义配置详细信息**页面的**对战配置详细信息**下，执行以下操作：
1. 在**姓名**中，输入可以帮助您在列表和指标中识别匹配者的姓名。对战构建器名称在区域中必须唯一。对战请求会使用其名称和区域标识要使用的对战构建器。
1. （可选）对于**描述**，添加有助于识别对战构建器的描述。
1. 对于**规则集**，从列表中选择要与对战构建器一起使用的规则集。该列表包含在当前区域中已创建的所有规则集。
1. 对于 **FlexMatch 模式**，请选择**独立**。这表明您有一个自定义机制，可以在 Amazon GameLift Servers 之外的托管解决方案上启动新的游戏会话。
1. 选择**下一步**。
1. 在**配置设置**页面的**对战设置**下，执行以下操作：
1. 对于**请求超时**，键入对战构建器针对每个请求完成对战游戏的最长时间（以秒为单位）。超过该时间的对战请求都将终止。
1. （可选）在**对战接受选项**下，在**需要接受**中，如果您想要求提议的对战中的每位玩家积极接受参与对战，请选择**必填**。如果您选择此选项，则在**接受超时**中，设置您希望对战构建器在取消对战之前等待玩家接受的时间（以秒为单位）。
1. （可选）在**事件通知设置**下，执行以下操作：
1. （可选）对于 **SNS 主题**，请选择一个 Amazon SNS 主题以接收对战活动通知。如果您尚未设置，可以在以后通过编辑对战配置来添加此信息。有关更多信息，请参阅 [设置 FlexMatch 事件通知](match-notification.md)。
1. （可选）对于**自定义事件数据**，输入要与该对战构建器关联的、事件消息中的任何自定义数据。FlexMatch 会在与对战构建器关联的每个事件中包含此数据。
1. （可选）在 “**标签**” 下，添加标签以帮助您管理和跟踪 Amazon 资源。
1. 选择**下一步**。
1. 在**查看和创建**页面上，查看您的选择，然后选择**创建**。如果创建成功，则对战构建器会立即准备好接受对战请求。
------
#### [ Amazon CLI ]
要使用创建配对配置 Amazon CLI，请打开命令行窗口，然后使用[create-matchmaking-configuration](https://docs.amazonaws.cn/cli/latest/reference/gamelift/create-matchmaking-configuration.html)命令定义新的匹配器。
此示例命令为需要玩家接受的独立对战构建器创建新的对战配置。
```
aws gamelift create-matchmaking-configuration \
--name "SampleMatchamker123" \
--description "The sample test matchmaker with acceptance" \
--flex-match-mode STANDALONE \
--rule-set-name "MyRuleSetOne" \
--request-timeout-seconds 120 \
--acceptance-required \
--acceptance-timeout-seconds 30 \
--notification-target "arn:aws:sns:us-west-2:111122223333:My_Matchmaking_SNS_Topic"
```
如果配对配置创建请求成功，则Amazon GameLift Servers返回一个包含您为匹配器请求的设置的[MatchmakingConfiguration](https://docs.amazonaws.cn/gameliftservers/latest/apireference/API_MatchmakingConfiguration.html)对象。新对战构建器已准备好接受对战请求。
------
# 教程：编辑对战配置
要编辑对战配置，请从导航栏中选择**对战配置**，然后选择要编辑的配置。您可以更新现有配置中除名称之外的任何字段。
更新配置规则集时，如果存在有效的对战票，则新规则集可能不兼容，原因如下：
+ 新的或不同的队伍名称或队伍数量
+ 玩家属性
+ 对现有玩家属性类型的更改
要对规则集进行任何更改，请使用更新的规则集创建新的对战配置。
# 设置 FlexMatch 事件通知
设置 事件通知
您可以使用事件通知来跟踪个人对战请求的状态。所有投入实际生产的游戏，或具有大量对战活动的预生产中的游戏都应使用事件通知。
有两个选项可用于设置事件通知。
+ 让您的对战构建器将事件通知发布到 Amazon Simple Notification Service 主题。
+ 使用自动发布的 Amazon EventBridge 事件及其工具套件来管理事件。
有关 Amazon GameLift Servers 发出的 FlexMatch 事件的列表，请参阅[FlexMatch 对战事件](match-events.md)。
**重要**
对于高吞吐量对战系统，我们建议使用标准（非 FIFO）Amazon SNS 主题，而不是 FIFO 主题。FIFO 主题的发布限制低于标准主题，这可能会导致在高负载期间出现节流异常。如果您在使用 FIFO 主题时遇到节流，则可能会丢失 FlexMatch 通知。
**注意**
Amazon GameLift Servers使用内置的重试逻辑自动处理 Amazon SNS 交付失败和限制。当 Amazon SNS 返回限制错误或暂时失败时，会在两Amazon GameLift Servers次尝试之间逐渐延迟重试通知传送。这有助于确保可靠地发送事件通知。但是，如果在所有重试尝试后仍然失败，或者出现不可重试的错误（例如授权失败或缺少主题），则通知可能会丢失。
**Topics**
+ [
## 设置 EventBridge 活动
](#match-notification-cwe)
+ [
# 教程：设置 Amazon SNS 主题
](match-notification-sns.md)
+ [
# 使用服务器端加密设置 Amazon SNS 主题
](queue-notification-sns-sse.md)
+ [
# 将主题订阅配置为调用 Lambda 函数
](match-notification-lambda.md)
## 设置 EventBridge 活动
Amazon GameLift Servers自动将所有配对活动发布到亚马逊 EventBridge。使用 EventBridge，您可以设置规则，将配对事件路由到目标进行处理。例如，您可以设置一条规则，将事件 “PotentialMatchCreated” 路由到处理玩家接受的 Amazon Lambda 函数。有关更多信息，请参阅[什么是亚马逊 EventBridge？](https://docs.amazonaws.cn/eventbridge/latest/userguide/eb-what-is.html)
**注意**
在配置媒人时，请将通知目标字段留空，或者如果您想同时使用两者，请引用 SNS 主题 EventBridge 和 Amazon SNS。
# 教程：设置 Amazon SNS 主题
您可以让 Amazon GameLift Servers 将 FlexMatch 对战构建器生成的所有事件发布到 Amazon SNS 主题中。
**为 Amazon GameLift Servers 事件通知创建 SNS 主题**
1. 打开 [Amazon SNS 控制台](https://console.amazonaws.cn/sns)。
1. 在导航窗格中，选择**主题**。
1. 在 **Topics**（主页）页面上，选择 **Create topic**（创建主题）。
1. 在 控制台中，创建一个主题。有关更多信息，请参阅《Amazon Simple Notification Service 开发人员指南》**中的[创建主题 Amazon Web Services 管理控制台](https://docs.amazonaws.cn/sns/latest/dg/sns-create-topic.html#create-topic-aws-console)。
1. 在主题的**详细信息**页面上，选择**编辑**。
1. （可选）在主题的**编辑**页面上，展开**访问策略**，然后将以下 Amazon Identity and Access Management (IAM) 策略声明中的粗体语法添加到现有策略的末尾。(为清晰起见显示了整个策略。) 请务必将 Amazon 资源名称（ARN）详细信息用于您自己的 SNS 主题和 Amazon GameLift Servers 对战配置。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:GetTopicAttributes",
"SNS:SetTopicAttributes",
"SNS:AddPermission",
"SNS:RemovePermission",
"SNS:DeleteTopic",
"SNS:Subscribe",
"SNS:ListSubscriptionsByTopic",
"SNS:Publish"
],
"Resource": "arn:aws:sns:us-east-1:111122223333:your_topic_name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333"
}
}
},
{
"Sid": "__console_pub_0",
"Effect": "Allow",
"Principal": {
"Service": "gamelift.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-1:111122223333:your_topic_name",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:gamelift:us-east-1:111122223333:matchmakingconfiguration/your_configuration_name"
}
}
}
]
}
```
------
1. 选择**保存更改**。
# 使用服务器端加密设置 Amazon SNS 主题
您可以使用服务器端加密 (SSE)，采用加密主题的方式传输敏感数据。SSE 使用在 Amazon Key Management Service ()Amazon KMS中管理的密钥保护 Amazon SNS 主题中的消息内容。有关 Amazon S3 如何执行加密的更多信息，请参阅 *Amazon Simple Storage Service 开发人员指南*中的[使用服务器端加密保护数据](https://docs.amazonaws.cn/sns/latest/dg/sns-server-side-encryption.html)。
要使用服务器端加密设置 SNS 主题，请查看下面的主题：
+ 《Amazon Key Management Service 开发人员指南》**中的[创建密钥](https://docs.amazonaws.cn/kms/latest/developerguide/create-keys.html)。
+ 将 S *imple Notification Service 开发人员指南*[中的主题启用 SSE](https://docs.amazonaws.cn/sns/latest/dg/sns-enable-encryption-for-topic.html)
创建 KMS 密钥时，请使用以下 KMS 密钥策略：
```
{
"Effect": "Allow",
"Principal": {
"Service": "gamelift.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:gamelift:your_region:your_account:matchmakingconfiguration/your_configuration_name"
},
"StringEquals": {
"kms:EncryptionContext:aws:sns:topicArn": "arn:aws:sns:your_region:your_account:your_sns_topic_name"
}
}
}
```
# 将主题订阅配置为调用 Lambda 函数
您可以使用发布到 Amazon SNS 主题的事件通知调用 Lambda 函数。配置对战构建器时，将通知目标字段设置为 SNS 主题 ARN。
以下 Amazon CloudFormation 模板将订阅名为的 SNS 主题配置为调用名`MyFlexMatchEventTopic`为的 Lambda 函数。`FlexMatchEventHandlerLambdaFunction`该模板创建了一个 IAM 权限策略，允许 Amazon GameLift Servers 写入 SNS 主题。然后，模板将调用 Lambda 函数的权限。
```
FlexMatchEventTopic:
Type: "AWS::SNS::Topic"
Properties:
KmsMasterKeyId: alias/aws/sns #Enables server-side encryption on the topic using an Amazon managed key
Subscription:
- Endpoint: !GetAtt FlexMatchEventHandlerLambdaFunction.Arn
Protocol: lambda
TopicName: MyFlexMatchEventTopic
FlexMatchEventTopicPolicy:
Type: "AWS::SNS::TopicPolicy"
DependsOn: FlexMatchEventTopic
Properties:
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: gamelift.amazonaws.com
Action:
- "sns:Publish"
Resource: !Ref FlexMatchEventTopic
Topics:
- Ref: FlexMatchEventTopic
FlexMatchEventHandlerLambdaPermission:
Type: "AWS::Lambda::Permission"
Properties:
Action: "lambda:InvokeFunction"
FunctionName: !Ref FlexMatchEventHandlerLambdaFunction
Principal: sns.amazonaws.com
SourceArn: !Ref FlexMatchEventTopic
```