设计 FlexMatch 规则集 - Amazon GameLift
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

设计 FlexMatch 规则集

在最基本的层面上,对战规则集有两个作用:安排对战游戏的团队结构和规模,以及告知对战构建器如何评估玩家以查找可能的最佳匹配。但是,它能够做的比这些要多得多。例如,您还可以通过规则集解决地址匹配问题,如:

  • 为您的游戏优化匹配算法。

  • 为大型对战(> 40 位玩家)触发特殊的匹配处理。

  • 强制实施最低玩家延迟要求以保护游戏质量。

  • 如果无法进行匹配,则逐步放宽团队要求或匹配规则。

  • 为包含多个玩家(各方聚合)的对战请求定义特殊处理。

本主题介绍规则集的基本结构以及如何将它们用于最多 40 位玩家的对战游戏。超过 40 位玩家的对战游戏需要不同的规则集结构,因为 FlexMatch 使用简化的算法来快速匹配大量玩家。在 设计 FlexMatch 大型对战规则集 中了解有关构建大型对战游戏的更多信息。

相关主题

定义规则集组件

所有规则集包含部分或全部组件,如FlexMatch 规则集架构中的一般规则集架构中所述。本主题介绍每个规则集组件的设计问题:

需要规则集来构建超过 40 位玩家的对战游戏? 了解如何设计 FlexMatch 大型对战规则集

描述规则集

提供规则集的详细信息。

  • name(可选)– 这是规则集语法中的描述性标签,不能供 Amazon GameLift 以任何有意义的方式使用。不要将此值与规则集名称混淆,规则集名称在创建规则集时与规则集语法一同设置。

  • ruleLanguageVersion(必需) 这是用于创建 – 规则的属性表达式语言的版本。FlexMatch此值必须等于“1.0”。

自定义匹配算法

您可以选择修改默认匹配算法的某些元素。从设计上讲,默认算法针对大多数游戏进行了优化,以便快速高效地处理对战请求,从而使玩家可在最短的等待时间内加入到可接受的对战游戏。您可以自定义算法并调整对战优先级,以更好地满足您的游戏需求。

默认 FlexMatch 对战过程如下所示:

  1. 所有开放对战票证和回填票证都放置在票证池中。

  2. 票证随机分组为一个或多个批次以进行匹配。仅当票证池变得太大以获得最佳匹配时,才会形成多个批次。

  3. 每个批次按票证期限进行排序。

  4. 从最旧的票证开始,将对批处理中的所有票证进行评估以找到可接受的匹配项。

以下建议的自定义会影响对战过程的不同阶段。要自定义匹配算法,请将 algorithm 组件添加到规则集架构中。有关完整的参考信息,请参阅FlexMatch 规则集架构

添加批处理前排序

您可以将 FlexMatch 配置为在形成批次之前对票证池进行排序。这种类型的自定义与往往具有非常大的票证池的游戏最有效。前批处理排序可用于帮助加快对战过程,它还有助于在某些特征中构建具有更高玩家性能的对战游戏。

在算法属性 batchingPreference 中定义了预批量排序方法。 默认设置为“随机”,这指示没有发生预排序。

用于自定义预批量排序的选项包括:

  • 按玩家属性排序。 提供要对票证池进行预排序的玩家属性列表。此自定义会导致 FlexMatch 在排序的属性中创建更加一致的批处理。例如,如果您按玩家技能对票证池进行预先排序,则具有相似技能级别的票证往往会被批处理在一起。如果您的规则集还包含基于玩家技能的对战规则,则预批量排序可以显著提升对战效率。

    要启用此自定义,请将算法属性 batchingPreference 设置为“sorted”,并将属性 sortByAttributes 设置为玩家属性的列表。列表中的每个属性在规则集的 playerAttributes 组件中均有声明。

    在以下示例中,FlexMatch 首先根据玩家的首选游戏地图,然后按玩家技能对票证池进行排序。生成的批次更有可能包含希望使用相同地图的技能类似的玩家。

    "algorithm": { "batchingPreference": "sorted", "sortByAttributes": ["map", "player_skill"], "strategy": "exhaustiveSearch" },
  • 按延迟进行排序。 在下列选项之一之间进行优先选择:(1) 将玩家置于可用延迟最低的对战中,或 (2) 快速将玩家置于可接受延迟的对战中。此自定义适合用于组成大型对战游戏的规则集 (超过 40 位玩家);算法属性 strategy 必须设置为“balanced”,这会显著限制规则语句的可用类型。请参阅 设计 FlexMatch 大型对战规则集

    此自定义会导致 FlexMatch 根据报告的延迟数据通过以下方式之一对票证进行预排序:

    • 让玩家进入延迟最低的区域。票证池按玩家报告其最低延迟值的区域预先排序。这会导致 FlexMatch 批处理在同一区域中报告低延迟的票证,从而倾向于将玩家匹配到其最快区域并改善整体游戏体验。它还会减少每个批次中的票数,因此对战游戏可能需要更长时间才能完成。要启用此自定义,请将算法属性 batchingPreference 设置为值“fastestRegion”,如以下示例所示。

      "algorithm": { "batchingPreference": "fastestRegion", "strategy": "balanced" },
    • 快速让玩家进入可接受的延迟匹配。票证轮询按玩家在其中报告任何可接受的延迟值的区域预先排序。此方法往往会形成更少的批次,每个批次包含大量在同一区域中具有可接受延迟的票证。每个批次中的票证越多,查找足够的可接受对战往往更轻松快捷。要启用此自定义,请将属性 batchingPreference 设置为值“largestPopulation”,如以下示例所示。(此方法是使用平衡策略的规则集的默认行为。)

      "algorithm": { "batchingPreference": "largestPopulation", "strategy": "balanced" },

确定回填票证的优先级

如果您的游戏实施自动回填或手动回填,您可以自定义 FlexMatch 如何根据请求类型(新对战请求或回填请求)处理对战票证。默认情况下,两种类型的请求都得到相同处理。此自定义会导致 FlexMatch 先尝试填充回填票证,或者仅在无法进行新的对战时尝试填充。它还可能会影响托管资源的使用 –,方式是将玩家打包到较少的游戏会话或者创建更多部分填充的游戏会话。

回填优先级会影响在对票证进行批处理后的处理方式;它不会影响票证批处理过程。您可以根据需要实施预批量排序和回填优先级。仅将回填优先级用于使用详尽搜索策略的规则集。

要更改回填票证的优先级,请设置属性 backfillPriority,如下所示:

  • 首先匹配回填票证。此选项提示 FlexMatch 在创建新对战之前评估并尝试完成回填票证。这意味着,传入玩家被放入现有游戏中的可能性更高。将属性 backfillPriority 设置为“high”。

    如果您的游戏使用的是自动回填,请启用此自定义项作为最佳实践。自动回填最常用于游戏,具有较短的游戏会话时间范围和高度玩家周转。自动回填有助于这些游戏快速形成最小可行的对战游戏并开始,即使 FlexMatch 搜索更多玩家来填充空闲位置。首先尝试填充回填票证有助于优化此方法。

    "algorithm": { "backfillPriority": "high", "strategy": "exhaustiveSearch" },
  • 匹配回填票证最后。此选项将提示 FlexMatch 忽略回填票证,直到所有其他票证都已评估。这意味着,仅在传入玩家无法匹配到新游戏时,才将他们回填到现有游戏中。将属性 backfillPriority 设置为“low”。

    当您想要使用回填作为最后一项通道选项来让玩家进入游戏时 (例如,当玩家太少而无法组成新对战时),此选项很有用。取消回填票证的优先级不应与自动回填一起使用。

    "algorithm": { "backfillPriority": "low", "strategy": "exhaustiveSearch" },

首选具有扩展的旧票证

自定义 FlexMatch 如何应用扩展规则,以便在对战游戏难以完成时放宽匹配条件。GameLift 在部分完成的对战游戏中的票证达到特定期限时应用扩展规则。票证的创建时间戳确定何时应用规则;默认情况下,FlexMatch 跟踪最近匹配的票证的时间戳。

要在应用扩展规则时进行更改,请设置属性 expansionAgeSelection,如下所示:

  • 根据最新票证进行扩展。此选项根据添加到潜在对战游戏的最新票证应用扩展规则。每次匹配新票证时,都会重置时钟。使用此选项,应用扩展会更加困难;生成的对战游戏往往会获得更高的质量,但玩家的等待时间可能会更长,对战请求在完成前可能会超时。将属性 expansionAgeSelection 设置为“新”(这是默认值)。

  • 根据最旧的票证进行扩展。此选项根据潜在对战游戏中最早的票证(通常是(但并非总是)添加到对战游戏的第一个票证)应用扩展规则。使用此选项,扩展的应用速度往往更快,这可以缩短最早的匹配玩家的等待时间,同时降低所有玩家的匹配质量。将属性 expansionAgeSelection 设置为“oldest”。

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

声明玩家属性

规则可能会根据各个玩家的特性选择对战游戏的玩家。如果您创建了依赖于玩家属性的规则,则必须在本部分中声明。声明的玩家属性的值应该包含在使用此规则集发送对战构建器的每个对战请求中。

您可能还需要将某些玩家属性传递到游戏会话中,即使规则集在玩家评估期间不使用这些属性。例如,您可以传递选择的玩家角色。要执行此操作,请在此处声明您的玩家属性,并在对战请求中包含每个玩家的属性值。

在声明玩家属性时,请包含以下信息:

  • name(必需)– 此值在规则集中必须唯一。

  • type(必需)– 这是属性值的数据类型。有效数据类型为数字、字符串或字符串映射。

  • default(可选)– 输入在未为玩家提供值时要使用的默认值。如果没有声明默认值,玩家也没有提供值,则无法匹配该玩家。

定义对战团队

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

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

  • name(必需)– 为每个团队分配一个唯一名称。此名称在规则和扩展中使用,并在用于游戏会话的对战数据中引用。

  • maxPlayers(必填) 指定可以分配给团队的玩家的最大数量。–

  • minPlayers(必填) 指定要使对战成功必须分配给团队的玩家的最小数量。–

  • quantity(可选)– 如果您希望 FlexMatch 根据此定义创建多个团队,请指定数量。FlexMatch 创建对战游戏时,会为这些团队提供指定名称并附加一个编号。例如,“Red-Team_1”、“Red-Team_2”、“Red-Team_3”等。

FlexMatch 始终会尝试将团队填充到最大玩家规模,但在创建团队时则会设置最小玩家规模允许的较少的玩家数量。如果您希望对战游戏的所有团队都具有相同规模,可以创建相应的规则。有关“EqualTeamSizes”规则的示例,请参阅 FlexMatch 规则集示例主题。

设置玩家匹配规则

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

  • name(必需)– 这是用于在规则集中唯一标识规则的有意义的名称。规则名称也可在跟踪与此规则相关的活动的事件日志和指标中引用。

  • description(可选)– 使用此元素可附加自由格式文本描述。此信息不可供对战构建器使用。

  • type(必需)– 类型元素标识处理规则时要使用的操作。每个规则类型都需要一组额外属性。例如,若干规则类型需要一个引用值来衡量玩家的属性。有关有效的规则类型和属性的列表,请参阅 FlexMatch 规则语言

  • 规则类型属性(可能是必需的)– 根据定义的规则类型,您可能需要设置某些规则属性。例如,对于距离和比较规则,必须指定要衡量的玩家属性。在 FlexMatch 规则语言 中了解有关属性以及如何使用 FlexMatch 属性表达式语言的更多信息。

允许要求随时间推移放宽

扩展允许您在无法完成对战时随着时间推移放宽匹配条件。此功能可确保在不可能有完美匹配时,进行“现有最佳”匹配。您可以使用扩展来放宽玩家技能要求,提高可接受的玩家延迟级别,或减少团队中所需的最小玩家数量。通过利用扩展放宽规则,您可以逐渐扩展可接受对战游戏的玩家池。

当未完成匹配中最新票证的期限与扩展等待时间匹配时,将触发扩展。在对战游戏中添加新票证时,可能会重置扩展等待时间时钟。您可以在规则集的 algorithm 部分中自定义如何触发扩展。请记住, 中的扩展步骤等待时间是绝对的,它们不会相互复合。因此,如果您有两个步骤,一个步骤设置为 15,另一个步骤设置为 30,则第一个步骤将在第一个步骤后 15 秒触发。

下面是一个扩展的示例,该扩展会逐步提高对战游戏所需的最低技能级别。规则集使用名为“SkillDelta”的距离规则语句来要求对战游戏中的所有玩家都在 5 个技能级别以内。如果在 15 秒内没有进行新的匹配,则此扩展允许技能级别差异 10,然后 10 秒允许差异 20。

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

启用自动回填的对战构建器不会太快地放宽玩家计数要求。新游戏会话需要几秒钟时间启动并开始自动回填。如果您的扩展步骤具有非常短的等待时间,FlexMatch 可能会在新启动的游戏会话发送回填请求之前创建大量部分填充的对战。更好的方法是仅在您的游戏开始自动回填后触发扩展。这有助于 FlexMatch 更快、更高效地让玩家进入游戏(新游戏或现有游戏)。扩展时间因您的团队构成而异,因此,预计会进行一些测试来找到最适合您的游戏的扩展策略。

设计 FlexMatch 大型对战规则集

如果您的规则集创建的对战允许 41 到 200 位玩家,则需要对规则集配置做出一些调整。这些调整会优化对战算法,使其可以构建可行的大型对战,同时确保玩家等待时间较短。因此,大型对战规则集将耗时的自定义规则替换为针对常见对战优先级进行了优化的标准解决方案。

下面介绍如何确定您是否需要针对大型对战优化您的规则集:

  1. 对于规则集中定义的每个团队,获取 maxPlayer 的值。

  2. 将所有 maxPlayer 值相加。如果总数超过 40,您有大型对战规则集。

要针对大型对战优化您的规则集,请按以下所示进行调整。请参阅 大型对战的规则集架构 中的大型对战规则集架构以及 示例 7:创建大型对战 中的规则集示例。

为大型对战自定义对战算法

将算法组件添加到规则集 (如果尚不存在)。设置以下属性。

  • strategy(必需)– 将 strategy 属性设置为“balanced”。此设置将触发 FlexMatch 进行其他对战后检查,以根据指定的玩家属性查找最佳团队平衡。使用 balancedAttribute 属性设置玩家属性。平衡策略可免除自定义规则构建平均对战团队的需求。

  • balancedAttribute(必需)– 标识在对战中平衡团队时要使用的玩家属性。此属性必须具有数字数据类型(双精度或整数)。例如,如果您选择平衡玩家技能,FlexMatch 会尝试分配玩家,以便所有团队拥有尽可能均匀的技能级别。必须在规则集的玩家属性中声明平衡属性。

  • batchingPreference(可选)– 选择您希望为玩家构建最低延迟的对战游戏的强调。此设置会影响在构建对战游戏之前对战游戏票证的排序方式。选项包括:

    • 最大群体。FlexMatch 允许对战池中所有具有可接受延迟值且在至少一个区域中共有的票证。因此,潜在票证池往往很大,从而可以更轻松地更快地填充匹配项。玩家可能会被放入具有可接受但并非始终最佳的延迟的游戏中。如果未设置此属性,则这是当 strategy 设置为“balanced”时的默认行为。

    • 最快的区域。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

  2. 绿色团队尚未达到 minPlayers。 接下来 2 个玩家被分配到绿色团队。绿色团队现已达到 minPlayers

  3. 所有团队现在位于 minPlayers,现在将根据空闲位置的数量分配其他玩家。红色团队和蓝色团队各有 5 个空闲位置,绿色团队有 1 个。接下来 8 个玩家将被分配(每个团队 4 个)到红色团队和蓝色团队。所有团队现在都有 1 个空闲位置。

  4. 剩下的 3 个玩家位置分配(每个位置 1 个)到团队中,无特定顺序。

为大型对战设置延迟规则

大型对战的对战主要取决于平衡策略和延迟批处理优化。大多数自定义规则不可用。但是,您可以创建一个对玩家延迟设置硬性限制的规则。

要创建此规则,请使用属性为 latencymaxLatency 规则类型。 以下示例将最大玩家延迟设置为 200 毫秒:

"rules": [{ "name": "player-latency", "type": "latency", "maxLatency": 200 }],

放宽大型对战要求

在小型对战中,您可以使用扩展来在可能没有有效匹配时随着时间推移放宽匹配要求。对于大型对战,您可以选择放宽延迟规则或团队玩家计数。

如果您在大型对战中使用自动匹配回填,请不要太快地放宽团队玩家计数。FlexMatch 仅在游戏会话启动后开始生成回填请求,在对战创建后的前几秒钟可能不会开始。在这段时间内,FlexMatch 可以创建多个部分填充的新游戏会话,尤其是在玩家计数规则降低时。因此,您最后将有多于所需的更多游戏会话,而且玩家将在这些会话之间过于稀疏地分布。最佳做法是给予玩家计数扩展的第一个步骤更长的等待时间,长到足够让游戏会话启动。由于为大型对战的回填请求提供了更高的优先级,传入玩家将在新游戏启动前被放入现有游戏。您可能需要进行实验来找到最适合您的游戏的等待时间。

下面是一个在更长的初始等待时间内逐渐降低黄色团队的玩家计数的示例。请记住,规则集扩展中的等待时间是绝对的,不是复合的。因此,第一次扩展在第五秒时进行,第二次扩展在五秒以后,即第十秒时进行。

"expansions": [{ "target": "teams[Yellow].minPlayers", "steps": [{ "waitTimeSeconds": 5, "value": 8 }, { "waitTimeSeconds": 10, "value": 5 }] }]