设计FlexMatch规则集 - 亚马逊 GameLift
描述规则集（必填）自定义匹配算法声明玩家属性定义比赛队伍 为玩家匹配设定规则允许要求随着时间的推移而放松
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

设计FlexMatch规则集

本主题介绍规则集的基本结构以及如何为不超过 40 名玩家的小型比赛建立规则集。配对规则集有两件事:列出比赛的团队结构和规模，并告诉媒人如何选择球员以形成最佳比赛.

但是您的配对规则集可以做得更多. 譬如，您可以：

  • 优化游戏的配对算法。

  • 设置最低玩家延迟要求以保护游戏质量。

  • 随着时间的推移，逐渐放宽球队要求和比赛规则，这样所有活跃的玩家都可以在需要时找到可以接受的比赛。

  • 使用派对聚合定义群组配对请求的处理。

  • 处理 40 名或更多玩家的大型比赛。有关建造大型比赛的更多信息，请参阅设计FlexMatch大型比赛规则集。

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

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

描述规则集（必填）

提供规则集的详细信息。

  • 名称（可选）-供您自己使用的描述性标签。此值与您在使用 Amazon 创建规则集时指定的规则集名称无关GameLift。

  • ruleLanguageVersion— 用于创建FlexMatch规则的属性表达式语言的版本。值必须为1.0。

自定义匹配算法

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

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

  1. FlexMatch将所有未打开的婚介门票和回填门票放入票池中.

  2. FlexMatch将池中的门票随机分组为一个或多个批次。随着票证池的增大，会FlexMatch形成额外的批次以保持最佳批次大小。

  3. FlexMatch在每批中按年龄对门票进行排序。

  4. FlexMatch根据每批最旧的门票进行匹配。

要自定义匹配算法，请向规则集架构添加组algorithm件。有关完整FlexMatch规则集架构的参考信息，请参见。

使用以下可选的自定义设置来影响配对过程的不同阶段.

添加预批次排序

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

使用算法属性batchingPreference定义预批次排序方法。默认设置为 random。

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

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

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

    在以下示例中，根据玩家的首选游戏地图，然后按玩家技能对门票池进行FlexMatch排序。由此产生的批次更有可能包含想要使用相同地图的技能相似的玩家。

    "algorithm": {
    "batchingPreference": "sorted",
    "sortByAttributes": ["map", "player_skill"],
    "strategy": "exhaustiveSearch"
},

  • 按延迟排序。以最低的可用延迟创建匹配项或以可接受的延迟快速创建匹配项。此自定义对于形成超过 40 名玩家的大型比赛的规则集很有用。

    将算法属性设置strategy为balanced。平衡策略限制了规则声明的可用类型。有关更多信息，请参阅设计FlexMatch大型比赛规则集：

    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"
},

偏爱带有扩展功能的旧门票

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

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

  • 根据最新门票进行扩展。此选项根据添加到潜在比赛中的最新门票应用扩展规则。每次FlexMatch匹配一张新票时，时钟都会重置。使用此选项，生成的匹配往往质量更高，但需要更长的时间才能匹配；如果匹配请求需要很长时间才能完成，则匹配请求可能会在完成之前超时。设置expansionAgeSelection为newest。 newest是默认。

  • 根据最旧的门票进行扩展。此选项根据潜在比赛中最早的门票应用扩展规则。使用此选项，可以更快地FlexMatch应用扩展，这样可以缩短最早匹配的玩家的等待时间，但会降低所有玩家的比赛质量。将 expansionAgeSelection 设置为 oldest。

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

声明玩家属性

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

  • 当规则集包含依赖于玩家属性的规则时。

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

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

  • 名称（必填）-此值必须是规则集的唯一值。

  • 类型（必填）-属性值的数据类型。有效数据类型为数字、字符串或字符串映射。

  • 默认（可选）-输入在配对请求未提供属性值时使用的默认值。如果未声明默认值且请求不包含值，则FlexMatch无法完成请求。

定义比赛队伍

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

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

  • 名称（必填）-为每个团队分配一个唯一的名称。你可以在规则和扩展中使用这个名字，也可以在游戏会话中FlexMatch引用配对数据。

  • MaxP layers（必填）-指定分配给团队的最大玩家人数。

  • minP layers（必填）-指定分配给团队的最小玩家人数。

  • 数量（可选）-使用此定义指定要组建的队伍数量。FlexMatch创建比赛时，它会为这些球队提供所提供的名字和附加的数字。例如Red-Team1Red-Team2、和Red-Team3。

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

为玩家匹配设定规则

创建一组规则声明，评估玩家是否接受比赛。规则可以设置应用于单个玩家、团队或整个对战的要求。当亚马逊GameLift处理匹配请求时，它会从可用玩家库中年龄最大的玩家开始，然后围绕该玩家进行比赛。有关创建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
        }]
    }]

对于启用了自动回填功能的媒人，不要过快地放宽对玩家人数的要求。新游戏会话需要几秒钟时间启动并开始自动回填。更好的方法是在游戏自动回填开始后开始扩展。扩展时间因您的团队构成而异，因此请进行测试以找到适合您游戏的最佳扩展策略。