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

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

设计 FlexMatch 规则集

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

  • 优化游戏的匹配算法。

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

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

  • 如果没有可以进行匹配,逐渐放宽团队要求或匹配规则。

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

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

相关主题

定义规则集组件

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

需要设置规则来构建对战有 40 位以上玩家? 了解如何设计 FlexMatch 大型匹配规则集

描述规则集

提供规则集的详细信息。

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

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

自定义匹配算法

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

默认的 FlexMatch 配对流程如下:

  1. 所有开放的配对门票和回填门票都放在门票池中。

  2. 票证随机分组为一个或多个批次进行匹配。只有当票证池太大无法进行最佳匹配时,才会形成多个批次。

  3. 每批都按门票年龄排序。

  4. 从最早的门票开始,一批中的所有门票都将评估是否可接受的匹配。

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

添加预批量分类

您可以配置 FlexMatch 以在形成批处理之前对票证池进行排序。这种类型的自定义对于往往拥有非常大的门票池的游戏来说最有效。预批量排序可用于帮助加快配对过程,而且它也倾向于在某些特征上形成具有更大的玩家均匀性的匹配。

在算法属性中定义了预批量排序方法batchingPreference. 默认设置为 “随机”,表示不会进行预先排序。

自定义批量预排序的选项包括以下内容:

  • 按玩家属性排序。提供玩家属性列表以对票池进行预先排序。这种自定义使 FlexMatch 能够在排序的属性中创建具有更大一致性的批次。例如,如果你按玩家技能对票池进行预先排序,那么具有相似技能水平的门票往往会被批处理在一起。如果你的规则集还包含基于玩家技能的比赛规则,那么预批量排序可以显著提高配对效率。

    要启用此自定义功能,请设置算法属性batchingPreference为 “已排序”,然后设置属性sortByAttributes到玩家属性列表中。列表中的每个属性都要在playerAttributes组件是规则集。

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

    "algorithm": { "batchingPreference": "sorted", "sortByAttributes": ["map", "player_skill"], "strategy": "exhaustiveSearch" },
  • 按延迟排序。选择以下选项之一的优先级:(1) 让玩家参加可用延迟最低的比赛,或 (2) 以可接受的延迟快速让玩家进入比赛。这种自定义适用于组建大型比赛的规则集(超过 40 名玩家);算法属性strategy必须设置为 “平衡”,这大大限制了可用的规则声明类型。请参阅设计 FlexMatch 大型匹配规则集

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

    • 让玩家进入延迟最低的区域。门票池按玩家报告其最低延迟值的地区进行预先排序。这导致 FlexMatch 批量报告相同地区低延迟的门票,这往往会将玩家匹配到他们最快的区域和整体上更好的游戏体验。它还减少了每批票的数量,因此完成比赛可能需要更长的时间。要启用此自定义功能,请设置算法属性batchingPreference将值改为 “FastRegion”,如以下示例中所示。

      "algorithm": { "batchingPreference": "fastestRegion", "strategy": "balanced" },
    • 快速让玩家进入可接受的延迟比赛。票务调查按玩家报告任何可接受的延迟值的地区进行预先排序。这种方法往往形成较少的批次,每个批次都包含大量在同一地区具有可接受延迟的票证。随着每批门票的更多,找到足够可接受的比赛往往会更容易、更快捷。要启用此自定义功能,请设置属性batchingPreference将值改为 “LargestPule”,如以下示例中所示。(此方法是使用平衡策略的规则集的默认行为。)

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

优先处理回填票证

如果您的游戏实现了自动回填或手动回填,则可以根据请求类型(新匹配或回填请求)自定义 FlexMatch 处理配对票的方式。默认情况下,两种类型的请求都被平等对待。这种自定义会导致 FlexMatch 要么首先尝试填写回填票证,要么仅在无法进行新匹配的情况下填写。它还有可能影响托管资源的使用 —— 要么将玩家打包到更少的游戏会话中,或者通过创建更部分填充的游戏会话。

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

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

  • 首先匹配回填票。此选项提示 FlexMatch 在创建新匹配之前评估并尝试完成回填票证。这意味着即将进入的玩家有更高的机会被插入现有游戏。设置属性backfillPriority变为 “高”。

    如果你的游戏使用自动回填,请启用此自定义作为最佳实践。自动回填最常用于游戏会话时间较短且玩家周转率高的游戏中。自动回填有助于这些游戏快速形成最低可行的比赛并开始比赛,即使 FlexMatch 搜索更多玩家以填补空缺的老虎机。首先尝试填写回填单有助于优化这种方法。

    "algorithm": { "backfillPriority": "high", "strategy": "exhaustiveSearch" },
  • 最后匹配回填票。此选项会提示 FlexMatch 忽略回填票证,直到评估了所有其他票证。这意味着,只有在无法匹配到新游戏的时候,才会将其回填到现有游戏中。设置属性backfillPriority变为 “低”。

    当你想使用回填作为让玩家进入游戏的最后机会选项时,例如当玩家太少无法组建新比赛时,此选项非常有用。取消回填票的优先级不应与自动回填一起使用。

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

通过扩展支持较旧的机票

自定义 FlexMatch 如何应用扩展规则,在比赛难以完成时放宽匹配标准。当部分完成的比赛中的门票达到一定年龄时,GameLift 应用扩展规则。票证的创建时间戳决定何时应用规则;默认情况下,FlexMatch 会跟踪最近匹配票证的时间戳。

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

  • 根据最新票证扩展。此选项根据添加到潜在比赛中的最新票证来应用扩展规则。每次匹配新票时,时钟都会重置。有了这个选项,应用扩张更加困难;结果的比赛质量往往更高,但是玩家的等待时间可能会更长,并且比赛请求可能会在完成之前超时。设置属性expansionAgeSelection改为 “最新”(这是默认值)。

  • 根据最旧的票证进行扩展。此选项应用基于潜在比赛中最早的门票的扩展规则,该门票通常是(但并非总是)添加到比赛中的第一张门票。有了这个选项,扩张通常会更快地应用,这可以缩短最早匹配球员的等待时间,但也降低了所有玩家的比赛质量。设置属性expansionAgeSelection到 “最古老的”。

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

声明玩家属性

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

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

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

  • 名称(必需)— 此值在规则集中必须唯一。

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

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

定义对战团队

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

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

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

  • MaxPlayers(必需)— 指定可以分配给团队的玩家的最大数量。

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

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

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

设置玩家匹配规则

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

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

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

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

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

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

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

当未完成比赛中最新票的时间与扩展等待时间相匹配时间时,将触发扩展。当新票添加到比赛中时,扩展等待时间时钟可能会重置。您可以在algorithm设置规则集的部分。请记住,扩张步骤等待时间是绝对的,它们彼此不会复杂。因此,如果你有两个步骤,一个设置为 15,一个设置为 30,第二步将在第一步后 15 秒触发。

以下是一个扩张的例子,它逐渐提高了比赛所需的最低技能水平。规则集使用名为 “SkillDelta” 的距离规则语句来要求对战游戏的所有玩家在 5 个技能级别以内。如果 15 秒钟内没有进行新的比赛,则这种扩展允许技能水平差异 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财产改为 “平衡”。此设置会触发 FlexMatch 进行额外的赛后检查,以根据指定的球员属性找到最佳球队余额。使用设置玩家属性balancedAttribute财产。平衡策略取代了对自定义规则的需求,以建立均匀匹配的团队。

  • balancedAttribute(必需)— 确定在对战中平衡团队时要使用的玩家属性。此属性必须具有数值数据类型(双精度或整数)。例如,如果你选择平衡球员技能,FlexMatch 会尝试分配球员,以便所有球队拥有尽可能均匀匹配的总技能水平。平衡属性必须在规则集的玩家属性中声明。

  • batchingPreference(可选)— 选择你想强调多少重点来为玩家打造尽可能的最低延迟比赛。此设置影响匹配票在建立匹配之前的排序方式。选项包括:

    • 最大群体。FlexMatch 允许使用池中至少在一个共同区域具有可接受延迟值的所有票证。因此,潜在的门票池往往很大,这使得更快地填补比赛变得更容易。玩家可能会被放置在游戏中的延迟时间可以接受但并非总是最佳的。如果未设置此属性,则这是在以下情况下的默认行为。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.

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

  3. 现在所有团队都在minPlayers现在,根据打开的空闲位置数分配额外玩家。红色和蓝队各有 5 个空缺槽,而绿队有 1 个。接下来的 8 个玩家将被分配(每个团队 4 个)到红色团队和蓝色团队。所有球队现在都有 1 个开放时隙。

  4. 剩余的 3 个玩家位置将按特定顺序分配(每个团队 1 个)。

为大型比赛设置延迟规则

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

要创建此规则,请使用latency具有属性的规则类型maxLatency. 下面是一个将最大玩家延迟设置为 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 }] }]