本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 设计 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
}]
}]
```