请求玩家对战
将代码添加到您的游戏后端服务来管理对 FlexMatch 对战构建器的对战请求。对于使用 FlexMatch 和 Amazon GameLift Servers 托管的游戏，以及使用 FlexMatch 作为独立解决方案的游戏，申请 FlexMatch 对战的过程是相同的。
创建对战请求：
调用 Amazon GameLift Servers API StartMatchmaking。每个请求都必须包含以下信息。
- 对战构建器
-
要用于请求的对战配置的名称。FlexMatch 将各个请求放置到指定对战构建器的池中，并将根据对战构建器的配置方式来处理请求。这包括强制施加时间限制，是否请求玩家接受匹配，在放置生成的游戏会话时使用哪个队列，等等。在 设计 FlexMatch 对战构建器 中了解有关对战构建器和规则集的更多信息。
- 票证 ID
-
分配给请求的唯一票证 ID。与请求相关的所有信息（包括事件和通知）都将引用票证 ID。
- 玩家数据
-
您要为其创建对战的玩家的列表。如果根据对战规则和延迟最低值，请求中的任意玩家不满足对战要求，则对战请求绝不会生成成功的对战。您可在一个对战请求中包括最多十位玩家。当一个请求中有多个玩家时，FlexMatch 尝试创建单个对战并将所有玩家分配到相同团队中（随机选择）。如果请求包含的玩家数太多，无法放在一个对战团队中，则对战请求失败。例如，如果您设置了对战构建器，以创建 2 对 2 对战（两个团队，每个团队两个玩家），您无法发送包含两个以上玩家的对战请求。
注意
一个玩家 (通过其玩家 ID 标识) 一次只能包括在一个有效对战请求中。在您为玩家创建新请求时，将自动取消任何具有相同玩家 ID 的有效对战票证。
对于每个列出的玩家，请提供以下数据：
-
玩家 ID – 每个玩家必须具有一个唯一的玩家 ID，该 ID 由您生成。参阅生成玩家 ID。
重要
如果您创建的新对战请求包含已存在于现有有效对战请求中的玩家 ID，则现有请求将被自动取消。但是，系统不会为被取消的请求发送
MatchmakingCancelled事件。要监控现有对战请求的状态，请使用 DescribeMatchmaking 以不频繁的间隔（30-60 秒）轮询请求状态。被取消的请求将显示状态为CANCELLED，原因标记为Cancelled due to duplicate player。 -
玩家属性 – 如果所使用的对战构建器需要玩家属性，请求必须为每个玩家提供这些属性。必需的玩家属性在对战构建器的规则集中定义，同时还会指定属性的数据类型。玩家属性仅在规则集指定属性的默认值时是可选的。如果对战请求未提供所有玩家的必需玩家属性，对战请求可能永远无法成功。在构建 FlexMatch 规则集和FlexMatch 规则集示例中了解有关对战构建器规则集和玩家属性的更多信息。
-
玩家延迟 – 如果所使用的对战构建器有玩家延迟规则，请求必须报告每个玩家的延迟。玩家延迟数据是显示每个玩家的一个或多个值的列表。它表示对战构建器的队列中各个区域的玩家体验的延迟。如果请求中未包含延迟值，玩家将无法匹配，请求将失败。
-
检索对战请求详细信息
发送对战请求后，您可以通过调用包含请求票证 ID 的 DescribeMatchmaking 查看请求详细信息。此调用将返回请求信息，包括当前状态。成功完成请求之后，票证还将包含游戏客户端连接到对战所需的信息。
取消对战请求
您随时可以通过调用包含请求票证 ID 的 StopMatchmaking 取消对战请求。