翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ゲームクライアントへの FlexMatch の追加
このトピックでは、ゲームクライアントサービスに FlexMatch マッチメーキング機能を追加する方法について説明します。
ゲームクライアントがバックエンドのゲームサービスを通してゲームクライアントのマッチメーキングリクエストを行うことを強くお勧めします。Amazon GameLift Servers サービスとの通信にこの信頼できるソースを使用することで、ハッキングの試みや不正なプレイヤーデータからより簡単に保護できます。ゲームがセッションディレクトリサービスを使用している場合、これはマッチメーキングリクエストを処理するための優れたオプションです。Amazon GameLift Servers ホスティング FlexMatch およびスタンドアロンサービスとして Amazon GameLift Servers を使用する場合、サービスへのすべての呼び出しにバックエンドゲームサービスを使用することがベストプラクティスです。
Amazon GameLift Servers マネージドホスティングで FlexMatch を使用している場合も、別のホスティングソリューションでスタンドアロンサービスとして を使用している場合も、クライアント側の更新が必要です。 AWS SDK の一部である のサービス API を使用してAmazon GameLift Servers、次の機能を追加します。
+ 1 人以上のプレイヤーのマッチメーキングのリクエストを準備します (必須)。マッチメーキングルールセットによっては、このリクエストでプレイヤー属性やレイテンシーなど、特定のプレイヤー固有のデータが必要になる場合があります。
+ マッチメーキングリクエストのステータスを追跡します (必須)。一般的に、このタスクではイベント通知を設定する必要があります。
+ プレイヤーによる試合案 (オプション) の承諾をリクエストします。この機能では、マッチングの詳細を表示し、マッチングを承認または拒否するには、プレイヤーとの追加のインタラクションが必要です。
+ ゲームセッション接続情報を取得して、ゲームに参加します (必須)。新しいマッチングのゲームセッションが開始されたら、ゲームセッションの接続情報を取得し、それを使用してゲームセッションに接続します。
## 前提条件となるクライアント側のタスク
ゲームにクライアント側の機能を追加する前に、以下のタスクを実行する必要があります。
+ ** AWS SDK をバックエンドサービスに追加します。**バックエンドサービスは AWS SDK の一部である Amazon GameLift Servers API の機能を使用します。[Amazon GameLift Servers SDKs「 SDK for client services](https://docs.aws.amazon.com/gamelift/latest/developerguide/gamelift-supported.html#gamelift-supported-clients)」を参照してください。 AWS API の説明と機能については、「[Amazon GameLift Servers FlexMatch API リファレンス (AWS SDK)](reference-awssdk-flex.md)」を参照してください。
+ **マッチメーキングチケットシステムをセットアップします。**すべてのマッチメーキングリクエストに一意のチケット ID を割り当てる必要があります。一意のチケット ID を生成し、それを新しいマッチリクエストに割り当てるメカニズムが必要です。チケット ID には、最大 128 文字の文字列形式を使用できます。
+ **マッチメーカーに関する情報を収集します。**マッチメーキング設定とルールセットから次の情報を取得します。
+ マッチメーキング設定リソースの名前。
+ ルールセットで定義されているプレイヤー属性のリスト。
+ **プレイヤーデータを取得します。**マッチメーキングリクエストに含める各プレイヤーの関連データを取得する方法を設定します。プレイヤー ID とプレイヤー属性値が必要です。ルールセットにレイテンシルールが含まれている場合、またはゲームセッション配置時にレイテンシデータを使用する場合は、プレイヤーがゲームに配置される可能性のある各地理的ロケーションのレイテンシデータを収集してください。正確なレイテンシー測定値を取得するには、Amazon GameLift Servers の UDP ping ビーコンを使用します。これらのエンドポイントを使用すると、プレイヤーデバイスと潜在的な各ホスティングロケーション間の実際の UDP ネットワークレイテンシーを測定できるため、ICMP ping を使用するよりも正確な配置決定を行うことができます。UDP ping ビーコンを使用してレイテンシーを測定する方法の詳細については、「[UDP ping ビーコン](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html)」を参照してください。
# プレイヤーのマッチメーキングのリクエスト
ゲームバックエンドサービスにコードを追加し、FlexMatch マッチメーカーへのマッチメーキングリクエストを管理します。FlexMatch マッチメーキングをリクエストするプロセスは、FlexMatch ホスティングで Amazon GameLift Servers を使用するゲームと、スタンドアロンソリューションとして FlexMatch を使用するゲームでも同じです。
## マッチメーキングリクエストを作成するには:
Amazon GameLift Servers API [StartMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_StartMatchmaking.html) を呼び出します。各リクエストには、以下の情報が必要です。
**マッチメーカー**
リクエストに使用するマッチメーキング設定の名前。FlexMatch は各リクエストを指定されたマッチメーカーのプールに配置し、リクエストはマッチメーカーが設定されている方法に基づいて処理されます。これには、プレイヤーにマッチングの承諾をリクエストするかどうか、生成されたゲームセッションを配置する際にどのようなキューを使用するかなど、強制的な時間制限が含まれます。マッチメーカーとルール設定の詳細については、「[FlexMatch マッチメーカーの設計](match-configuration.md)」を参照してください。
**チケット ID**
リクエストに割り当てられている一意のチケット ID。イベントや通知などリクエストに関連するものすべてが、チケット ID を参照します。
**プレイヤーデータ**
マッチングを作成する対象のプレイヤーのリスト。リクエスト内のプレイヤーのいずれかが、マッチルールと最小レイテンシーに基づいてマッチ要件を満たしていない場合、マッチメーキングリクエストが成功することはありません。マッチリクエストには最大 10 人のプレイヤーを含めることができます。リクエストに複数のプレイヤーがいる場合、FlexMatch は 1 つのマッチを作成し、すべてのプレイヤーを同じチーム (ランダムに選択) に割り当てようとします。リクエストに含まれるプレイヤーが多すぎて、マッチチームの 1 つに収まらない場合、リクエストは一致しません。例えば、2v2 のマッチ (2 人のプレイヤーで構成される 2 つのチーム) を作成するようにマッチメーカーを設定した場合は、3 人以上のプレイヤーを含むマッチメーキングリクエストを送信することはできません。
プレイヤー (プレーヤー ID によって識別) は、一度に 1 つのアクティブなマッチメーキングリクエストにのみ含めることができます。プレイヤーの新しいリクエストを作成すると、同じプレイヤー ID のアクティブなマッチメーキングチケットは自動的にキャンセルされます。
リストされたプレイヤーごとに、次のデータを含めます。
+ *プレイヤー ID* - 各プレイヤーごとにユニークなプレイヤー ID の生成が必要です。「[プレイヤー ID の生成](https://docs.aws.amazon.com/gamelift/latest/developerguide/player-sessions-player-identifiers.html)」を参照してください。
**重要**
既存のアクティブなマッチメーキングリクエストにすでに含まれているプレイヤー ID を含む新しいマッチメーキングリクエストを作成すると、既存のリクエストは自動的にキャンセルされます。ただし、キャンセルされたリクエストには `MatchmakingCancelled` イベントは送信されません。既存のマッチメーキングリクエストのステータスをモニタリングするには、[DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html) を使用して、頻度の低い間隔 (30～60 秒) でリクエストステータスをポーリングします。キャンセルされたリクエストには、`CANCELLED` のステータスと理由「`Cancelled due to duplicate player`」が表示されます。
+ *プレイヤー属性* - 使用されているマッチメーカーがプレイヤー属性を呼び出した場合、リクエストは各プレイヤーにそれらの属性を提供する必要があります。必須のプレイヤー属性は、マッチメーカーのルールセット内で定義され、属性のデータ型も指定されます。プレイヤー属性は、ルールセットで属性のデフォルト値が指定された場合のみ、オプションとなります。マッチングリクエストが必要なプレイヤー属性をすべてのプレイヤーに提供しない場合、マッチメーキングリクエストは成功しません。マッチメーカーのルールセットおよびプレイヤー属性の詳細については、「[FlexMatch ルールセットの作成](match-rulesets.md)」および「[FlexMatch ルールセットの例](match-examples.md)」を参照してください。
+ *プレイヤーレイテンシー* - 使用されているマッチメーカーにプレイヤーレイテンシールールがある場合、リクエストは各プレイヤーのレイテンシーを報告する必要があります。プレイヤーレイテンシーデータは、プレイヤーごとに 1 つ以上の値が表示されたリストです。これは、マッチメーカーのキューのリージョンで、プレイヤーに発生するレイテンシーを表しています。プレイヤーのレイテンシー値がリクエストに含まれていない場合、プレイヤーがマッチングされることはなく、リクエストは失敗します。正確なレイテンシー測定値を取得するには、Amazon GameLift Servers の UDP ping ビーコンを使用します。これらのエンドポイントを使用すると、プレイヤーデバイスと潜在的なホスティング場所間の実際の UDP ネットワークレイテンシーを測定できるため、ICMP ping を使用するよりも正確な配置決定を行うことができます。UDP ping ビーコンを使用してレイテンシーを測定する方法の詳細については、「[UDP ping ビーコン](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html)」を参照してください。
## マッチングリクエストの詳細を取得するには
マッチングリクエストが送信されたら、リクエストのチケット ID を使用して [DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html) を呼び出すことで、リクエストの詳細を表示できます。この呼び出しは、現在のステータスを含むリクエスト情報を返します。リクエストが正常に完了すると、チケットにはゲームクライアントがマッチングに接続するために必要な情報も含まれます。
## マッチングリクエストをキャンセルするには
マッチングリクエストは、リクエストのチケット ID を使用して [StopMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_StopMatchmaking.html) を呼び出すことで、いつでもキャンセルできます。
# マッチメーキングイベントの追跡
マッチメーキングプロセスに関して Amazon GameLift Servers がマッチメーキングプロセスのために発行するイベントを追跡するために通知を設定します。SNS トピックを作成するか、Amazon EventBridge を使用することで、通知を直接設定できます。通知の設定の詳細については、「[FlexMatch イベント通知をセットアップする](match-notification.md)」を参照してください。通知を設定したら、必要に応じてイベントと応答を検出するために、クライアントサービスでリスナーを追加します。
また、通知なしでかなりの期間が経過した場合に、ステータスの更新を定期的にポーリングして、通知をバックアップすることをお勧めします。マッチメーキングのパフォーマンスへの影響を最小限に抑えるには、マッチメーキングチケットが送信されてから 30 秒以上待ってからか、最後に受信した通知の後にのみポーリングしてください。
[DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html) をリクエストのチケット ID とともに呼び出して、現在のステータスを含むマッチメーキングリクエストチケットを取得します。最大で 10 秒に 1 回ポーリングすることをお勧めします。この方法は、使用量が少ない開発シナリオでのみ使用します。
**注記**
本稼働前の負荷テストなど、大量のマッチメーキングを使用する前に、イベント通知を使用してゲームをセットアップする必要があります。パブリックリリースのすべてのゲームでは、ボリュームに関係なく通知を使用する必要があります。継続的なポーリング方法は、マッチメーキングの使用量が少ない開発中のゲームにのみ適しています。
# プレイヤーの承諾をリクエスト
プレイヤーの承諾が有効になっているマッチメーカーを使用している場合、クライアントサービスにコードを追加し、プレイヤーの承諾プロセスを管理します。プレイヤーの承諾をマネージドするプロセスは、FlexMatch マネージドホスティングで Amazon GameLift Servers を使用するゲームと、スタンドアロンソリューションとして FlexMatch を使用するゲームでも同じです。
**マッチング案のプレイヤー承諾をリクエストする。**
1. **マッチング案がプレイヤーの承諾を必要とするときを検出する。**マッチメーキングチケットをモニタリングし、ステータスの `REQUIRES_ACCEPTANCE` への変更を検出します。このステータスに変わったときに FlexMatch イベント `MatchmakingRequiresAcceptance` がトリガーされます。
1. **すべてのプレイヤーから承諾を得る。**提案されたマッチング詳細を、マッチメーキングチケットで各プレイヤーに提示するメカニズムを作成します。プレイヤーは、マッチング案の承諾または拒否を示すことができる必要があります。マッチングの詳細は、[DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html) を呼び出して取得できます。マッチメーカーがマッチング案を取り消して続行する前に、プレイヤーには返答のために限られた時間が与えられます。
1. **FlexMatch へのプレイヤーの応答のレポート。**[AcceptMatch](https://docs.aws.amazon.com/gamelift/latest/apireference/API_AcceptMatch.html) を呼び出し、プレイヤーの承諾または拒否の応答を報告します。マッチメーキングリクエストのすべてのプレイヤーが承諾した場合にのみマッチングが進められます。
1. **承諾されなかったチケットを処理する。**マッチング案でプレイヤーがマッチングを拒否するか、承諾の制限時間内に応答しなかった場合、リクエストは失敗します。試合を承諾したプレイヤーのチケットは、自動的にチケットプールに戻されます。試合を承諾しなかったプレイヤーのチケットは違反ステータスになり、処理が中断されます。複数のプレイヤーがいるチケットの場合、チケット内のいずれかのプレイヤーが試合を受け入れなかった場合、チケット全体が違反します。
# 試合に接続する
正常に完了したマッチング (ステータス `COMPLETED` またはイベント `MatchmakingSucceeded`) を処理するために、クライアントサービスにコードを追加します。これにはマッチングのプレイヤーへの通知と、ゲームクライアントへ接続情報の提供が含まれます。
Amazon GameLift Servers マネージドホスティングを使用するゲームでは、マッチメーキングリクエストが正常に実行されると、ゲームセッション接続情報がマッチメーキングチケットに追加されます。[DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html) を呼び出して、完了したマッチメーキングチケットを取得します。接続情報には、ゲームセッションの IP アドレスとポート、および各プレイヤー ID に対するプレイヤーセッション ID が含まれます。詳細については、「[GameSessionConnectionInfo](https://docs.aws.amazon.com/gamelift/latest/apireference/API_GameSessionConnectionInfo.html)」を参照してください。ゲームクライアントはこの情報を使用して、試合をホストしているゲームセッションに直接Connectします。接続リクエストには、プレイヤーセッション ID とプレイヤー ID が含まれている必要があります。このデータは接続されたプレイヤーを、チームの割り当てを含むゲームセッションのマッチングデータに関連付けます (「[GameSession](https://docs.aws.amazon.com/gamelift/latest/apireference/API_GameSession.html)」を参照)。
Amazon GameLift Servers FleetIQ など、他のホスティングソリューションを使用するゲームでは、試合のプレイヤーが適切なゲームセッションに接続を有効にできるようメカニズムを構築する必要があります。
# マッチメーキングリクエストのサンプル
これらのコードスニペットは、さまざまなマッチメーカーに対するマッチメーキングリクエストを構築します。説明されているように、リクエストではマッチメーカーのルールセットの定義に従い、使用されているマッチメーカーで必要なプレイヤー属性を提供する必要があります。提供された属性では、ルールセット内で定義されている同じデータ型、数値 (N)、または文字列 (S) を使用する必要があります。
```
# Uses matchmaker for two-team game mode based on player skill level
def start_matchmaking_for_cowboys_vs_aliens(config_name, ticket_id, player_id, skill, team):
response = gamelift.start_matchmaking(
ConfigurationName=config_name,
Players=[{
"PlayerAttributes": {
"skill": {"N": skill}
},
"PlayerId": player_id,
"Team": team
}],
TicketId=ticket_id)
# Uses matchmaker for monster hunter game mode based on player skill level
def start_matchmaking_for_players_vs_monster(config_name, ticket_id, player_id, skill, is_monster):
response = gamelift.start_matchmaking(
ConfigurationName=config_name,
Players=[{
"PlayerAttributes": {
"skill": {"N": skill},
"desiredSkillOfMonster": {"N": skill},
"wantsToBeMonster": {"N": int(is_monster)}
},
"PlayerId": player_id
}],
TicketId=ticket_id)
# Uses matchmaker for brawler game mode with latency
def start_matchmaking_for_three_team_brawler(config_name, ticket_id, player_id, skill, role):
response = gamelift.start_matchmaking(
ConfigurationName=config_name,
Players=[{
"PlayerAttributes": {
"skill": {"N": skill},
"character": {"S": [role]},
},
"PlayerId": player_id,
"LatencyInMs": { "us-west-2": 20}
}],
TicketId=ticket_id)
# Uses matchmaker for multiple game modes and maps based on player experience
def start_matchmaking_for_multi_map(config_name, ticket_id, player_id, skill, maps, modes):
response = gamelift.start_matchmaking(
ConfigurationName=config_name,
Players=[{
"PlayerAttributes": {
"experience": {"N": skill},
"gameMode": {"SL": modes},
"mapPreference": {"SL": maps}
},
"PlayerId": player_id
}],
TicketId=ticket_id)
```