概述
队列和规则系统提供了处理大量方案的灵活性。下面是一些较常见的匹配用例及其关联队列的示例。你可以使用 PlayFab API 直接提交每个配置。<!—the Matchmaking Admin API.—> 你还可以使用 Game Manager UI 设置这些选项。我的第一个队列，或“快速匹配”
每个游戏都应从这个简单的队列开始，以理顺其基本流程。此队列将两名玩家匹配在一起，并包含一条可选规则，要求玩家传入相同的版本字符串才能匹配。如果你未指定版本，则无论版本如何，该玩家都可以与此队列中的其他玩家匹配。多种游戏模式
游戏通常有不同的玩法。如果这些玩家永远不应相互匹配，将他们放在不同的队列中可以优化性能。跨游戏模式搜索
如果希望玩家跨游戏模式与其他玩家匹配，请使用单个队列并创建集合交集规则。玩家可以指定多种游戏模式，该规则将匹配限制为所有玩家至少包含一种共同游戏模式的匹配。要使此功能正常工作，各模式所需的玩家人数必须相同。
基于技能的混战游戏（带扩展）
一种常见方案是尝试根据技能将玩家匹配在一起。在此示例中，队列要求玩家的技能属性相差在 0.2 以内，并且此值会随时间增加到 0.5。对于等待超过 30 秒的票证，允许任何技能差异。 此示例中的值假定可用技能的范围介于 0 和 1 之间。请调整这些值，使其适合你的游戏用于跟踪玩家技能的值范围，以及相对于匹配速度对技能的重视程度。 此外，规则在 30 秒时变为可选，适用于玩一局技能不平衡的游戏总比完全玩不上更好的游戏。对于不平衡的对局完全是负面体验的游戏，请调整SecondsUntilOptional。如果将其完全删除，则规则将无限期保持活动状态。
自定义扩展
你可以自定义扩展，以在每个时间间隔中使用任意值。例如，你可能希望允许的技能差异在开始时缓慢增长，之后随时间推移更快地增长。玩家人数随时间扩展
有些游戏希望一开始就是满员的对局，但随着时间的推移，可能会接受越来越少的人数。例如，一款大逃杀风格的游戏设计为最多 50 名玩家开始，但在匹配超时后可以用更少的玩家继续。 由于MinMatchSize 和 MaxMatchSize 不包含扩展，你可以使用 MatchTotalRule 修改对局所需的玩家人数。每个玩家将关联的属性设置为 1。该规则对这些值求和，以动态强制执行对局所需的玩家人数。
如果你未指定
MaxOverrides 或 MinOverrides 数组，则改用规则原始的 Max 或 Min 值。标准 4v4 风格（基于技能）
PlayFab Matchmaking 支持面向团队的对局。指定团队后，你在同一票证中一起提交的玩家都会被分配到同一个团队，并且不会被强制相互对战。 PlayFab Matchmaking 还支持各种团队规则，以帮助确保团队平衡。此示例适用于 4v4 对局，可确保各团队之间的技能保持平衡。多人游戏服务器
队列可以自动接入 PlayFab 的多人游戏服务器功能，分配服务器并向其提供已匹配玩家的列表。此队列提供了此类配置的最简示例，即ServerAllocationEnabled 标志，以及表示应启动哪个服务器版本的 BuildId。
将 ServerAllocationEnabled 标志设置为 true 时，还必须包含 RegionSelectionRule，以指示应在何处为每个对局分配服务器。
大型团队对战（12 对 12）
较大规模的团队游戏可能有额外的要求。在此示例中，队列配置为创建多人游戏服务器，管理具有如此多玩家的游戏通常需要多人游戏服务器。此配置与上一个示例类似。 除了技能之外，再添加另一条团队规则以促进团队相似性。每一方只允许一个大型团队，从而避免预组团队与大量随机玩家匹配的常见情况。大逃杀风格游戏
大逃杀风格游戏将许多人放入一个竞技场。在此示例中，游戏设置为四人一队。目前，在此类团队方案中最多允许 32 名玩家。此限制将在未来得到改进。 此示例还包含专用服务器的多人游戏服务器设置信息，对于具有大量玩家的游戏，这通常是必要的。此配置与上一个示例类似。处理不对称的跨平台游戏偏好
由于玩家可以选择不同的跨平台游戏设置，因此匹配偏好是不对称的。启用跨平台游戏的玩家愿意与任何平台匹配，而禁用跨平台游戏的玩家只想与自己平台上的玩家匹配。 你可以使用字符串相等规则或集合交集规则来实现能够处理此类不对称性的匹配队列。此特定示例使用字符串相等。 如果玩家禁用跨平台游戏，客户端会指定其DeviceType（例如 "xbox"、"playstation"），该规则将其限制为同平台匹配。如果玩家启用跨平台游戏，客户端将完全省略 DeviceType 属性，而值为 MatchAny 的 AttributeNotSpecifiedBehavior 允许他们与任何平台匹配。
当一组玩家一起提交票证时，服务会将该组视为一个单元，不会将该组拆分到不同的对局或团队中。你的游戏客户端应在提交票证之前验证组的构成。例如，如果某个玩家禁用了跨平台游戏，请在创建票证之前阻止其加入跨平台组。
主机/搜索者或基于角色的要求
PlayFab Match 使用基于票证的匹配系统，不会提前选择游戏主机。但是，它可以使用MatchTotalRule 限制对局中允许的主机数量，从而模拟主机-搜索者系统。
然后，票证可以通过指定 1 来提前表明它是主机。每个对局必须恰好包含一个主机。
如果主机数量远远超过搜索者数量（或反之），这种不平衡可能会导致所有玩家的匹配时间变慢。请考虑匹配设计的影响，以确保任何给定的子群体中都有足够的玩家来满足你的匹配规则和所需的平均匹配时间。
MatchTotalRule 来要求这些角色。
重要性不同的规则
规则通过限制哪些票证有资格相互匹配以及选择这些票证的挑选顺序来指导匹配。当存在多条规则时，系统会考虑它们的所有限制。但是，游戏可能会针对剩余的符合条件的票证优先考虑某条规则的偏好。 在此示例中，玩家必须处于一定的技能和经验等级范围内。但是，如果许多票证都在指定的技能和经验 范围内，此队列会优先选择技能更接近的票证，而不是经验等级更接近的票证。 在评估满足限制的票证时，技能差异的权重是经验差异的三倍 。DLC 包
通过使用各种 DLC 包，玩家可以选择使用SetIntersectionRule 仅查找拥有匹配 DLC 的其他玩家。每个玩家传入他们拥有的 DLC 包，对局要求一个组至少共享一个 DLC 包。
30 秒后，该规则变为可选，因此玩家无需共享 DLC 即可匹配。
启用统计信息
启用统计信息后，你的游戏可以显示有关队列的信息。当玩家选择想要玩的游戏模式时，这些信息可用于设定玩家的预期。 相反，游戏可能希望隐藏这些信息，可能是出于商业智能目的，也可能是为了避免将玩家引导到高流量队列中。 此队列同时启用了查看队列中玩家人数的功能以及票证匹配所需的估计时间。服务器始终可以检索此信息。以下配置仅控制是否也允许用户进行此调用。