Amazon GameLift FlexMatch の仕組み - Amazon GameLift

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

Amazon GameLift FlexMatch の仕組み

このトピックでは、マネージド GameLift ソリューションの一部として利用できる FlexMatch マッチメーキングシステムの概要について説明します。このトピックでは、主要な機能、コンポーネント、およびマッチメーキングプロセスの仕組みについて説明します。マッチメーカーのセットアップやプレイヤーのマッチングのカスタマイズなど、FlexMatch をゲームに追加する方法の詳細については、「FlexMatch マッチメーキングの追加」を参照してください。

GameLift FlexMatch はカスタマイズ可能なマッチメーキングサービスです。ゲームに最適な方法でマッチメーキングエクスペリエンス全体を管理できる、柔軟性の高いツールが用意されています。FlexMatch では、ゲームマッチングのためのチームの構築、互換プレイヤーの選択、および利用可能な最高のホスティングリソースの手配を通じて最善のプレイヤーエクスペリエンスを実現できます。FlexMatch バックフィルを使用すると、既存のゲームの新しいプレイヤーを検索できます。これにより、ゲームはゲームセッション中に互換プレイヤーで満たされ、最善のプレイヤーエクスペリエンスが実現します。

FlexMatch では、ゲームモードとプレイヤーに合わせて、複数のマッチメーカーを作成し実行できます。たとえば、自由に参加できるケージマッチのチーム構築には、別のマッチメーカーを使用できます。

FlexMatch の主な特徴

  • プレイヤーマッチングのカスタマイズ。 プレイヤーにとって最も魅力的なタイプのマルチプレイヤーエクスペリエンスを設計して構築します。ゲームモードごとにチーム構造を定義し、他のゲーム属性を定義します。プレイヤー属性 (スキルレベルやロールなど) を評価するためのカスタムルールを構築し、ゲームの最善のプレイヤーマッチングを作成します。これらのルールを使用して、新しいマッチングのプレイヤーをグループ化したり、既存のマッチングで開いているスロットを埋めたりできます (「マッチバックフィル」)。カスタムマッチングの詳細については、「FlexMatchルールセットの例」を参照してください。

  • 大規模なマッチングを作成します。 FlexMatch は非常に大規模なマッチング (41~200 人のプレイヤー) の作成に使用でき、マッチングプロセスを効率化する大規模なマッチアルゴリズムが使用されます。大規模なマッチングを作成するときは、より類似性の高いプレイヤーとのより大規模なマッチングの作成、またはすべてのプレイヤーが最善のプレイヤーレイテンシーエクスペリエンスを得ることがきるマッチングの作成のいずれかから、優先度を高く設定するものを選択できます。

  • プレイヤーの承諾の取得。 すべてのプレイヤーがマッチング案を承諾した上で開始することを要求します。この機能を有効にすると、FlexMatch では、マッチングに割り当てられたすべてのプレイヤーが承諾するまで待ってからマッチングを開始します。

    プレイヤーパーティのサポート。​同じチームでプレイすることを希望するプレイヤーのグループに対してマッチングを生成します。必要に応じてマッチングを満たす追加のプレイヤーを見つけます。

  • レイテンシーに基づくプレイヤーのマッチング。プレイヤーのレイテンシー情報を使用して、マッチングされたプレイヤー間の応答時間を近づけます。この機能を使用すると、一部のプレイヤーが不当に有利になるような格差をゲームプレイで回避できます。これは、複数の地理的な領域にまたがるマッチングを作成するときに特に有益です。

  • プレイヤーのマッチングルールの段階的な緩和。 最適なプレイヤーマッチングを作成することと、優れたマッチングを高速にプレイヤーに提供することのバランスを取ります。プレイヤーを最小の待機時間でゲームに参加させるために、厳密なマッチングルールを緩和する場所と時期は、ユーザーが決定します。

  • 最適なホスティングリソースの検索。 ゲームとプレイヤー情報を使用して、最適なゲームプレイエクスペリエンスのためのマッチングをホストするために利用できる最適なリソースを選択します。

  • マッチングされたプレイヤーでゲームを満たし続ける。 FlexMatch バックフィルを使用して、ゲームセッションの有効期間中、空のプレイヤースロットを適切にマッチングした新しいプレイヤーで満たします。自動バックフィルを有効にするか、コードをゲームに追加してバックフィルを手動で管理するか選択できます。

FlexMatch のコンポーネント

Amazon GameLift FlexMatch では、以下の 3 つの主要コンポーネントの連携が必要です。

  • プレイヤーマッチングをトリガーするメカニズム。 1 つのメカニズムにより、プレイヤーのマッチメーキングをいつ開始するか決定されます。2 番目の (オプション) メカニズムにより、既存のマッチング (バックフィル) で空のスロットに対していつ新しいプレイヤーを見つけるかが決定されます。マッチメーキングおよびマッチングバックフィルリクエストは、処理のためにマッチメーカーに渡されます。

  • プレイヤーを評価し、マッチングを作成する FlexMatch マッチメーカー。 マッチメーカーにより、受け取られるリクエストから可能な最善のプレイヤーマッチングが構築されます。これには、マッチングのチーム構造を定義し、マッチングのプレイヤーを評価するときに使用する条件を設定するルールセットがあります。ゲームには複数のマッチメーカーがあり、それぞれが異なるタイプのマッチングを構築します。

  • 新しいマッチングを配置するゲームセッションキュー。 ゲームセッションキューは、マッチングをホストするために使用可能なコンピューティングリソースを検索します。リソースを探す場所 (リージョン) と、各マッチングに利用できる最適なホストを選択する方法を決定します。

以下のセクションでは、マッチングで新しいゲームマッチングを作成する方法、または既存のゲームマッチングの新しいプレイヤーを検索する方法の詳細を説明します。

マッチメーキングプロセス

FlexMatch で新しいゲームマッチングのリクエストを処理する方法は以下のとおりです。この説明では、クライアント側のゲームサービスがマッチメーキングリクエストを作成し、マッチメーキングチケットのステータスを追跡していることを前提としています。

  1. リクエストのマッチメーキング。プレイヤーが、[Join Now] ボタンをクリックする、プレイヤーのグループがパーティーを形成するなど、マッチメーキングをトリガーするアクションをゲームで実行します。ゲームで、使用するマッチメーカーを識別し、マッチングする 1 人以上のプレイヤーを含めて、マッチメーキングリクエストを開始します。このリクエストには、スキルレベルや設定など、マッチメーカーがマッチングを構築するために必要なプレイヤー情報が含まれます。各リクエストは、ゲームがリクエストのステータスを追跡し、必要に応じてアクションを実行するために使用するマッチメーキングチケット ID を取得します。

  2. マッチング候補の検出。 すべてのマッチメーキングチケットは指定されたマッチメーカーに渡され、処理のためにチケットプールに配置されます。チケットはマッチングされるまで、またはマッチメーカーの最大制限時間に達するまで、チケットプールに残ります。

    マッチメーカーは通常 (大規模ではない) マッチングのプレイヤーマッチングを検索するために、チケットプールを通じて連続的に引き渡しを行います。各パスで、マッチメーカーはプールの最も古いチケットから開始し、それに対する他のチケットを評価して、最適なマッチングを探します。マッチメーカーのルールセットにより、(1) マッチング用に作成するチームの数、(2) 各チームに割り当てるプレイヤーの数、(3) 各プレイヤー候補を評価する方法が決定されます。ルールにより、個別のプレイヤー、チーム、またはマッチングの要件が設定される場合があります。たとえば、ルールでは、マッチングしたすべてのプレイヤーに特定の力を与えることや、チームの少なくとも 1 人のプレイヤーが特定のキャラクターを演じることを要求する場合があります。一般的に使用されるルールでは、マッチングのすべてのプレイヤーが、類似したスキル評価を持つことが要求されます。

    大規模なマッチングのプロセスは少し異なります。FlexMatch は、各プレイヤーを一連のルールに対して評価する代わりに、1 つのキーバランス属性に対して利用可能なマッチメイキングチケットを比較検討し、類似した属性値を持つプレイヤーをグループ化します。これはレイテンシー要件にも適用されます。プレイヤー間でより類似性が高い大規模なマッチングを作成するか、プレイヤーに最善のレイテンシーエクスペリエンスを提供するマッチングにプレイヤーを配置するかのいずれかを選択できます。最初のマッチングが見つかると、FlexMatch は最終マッチングが利用可能な最善のソリューションであることを確認するために一連のテストを実施します。

    マッチメーカーがチケットを評価する際は、チケット全体を合格にするか不合格にします。複数のプレイヤーが存在するチケットの場合、マッチメーカーはこれらのプレイヤーが一緒にプレイすることを希望していると想定して、すべてのプレイヤーを同じマッチングに配置することを試みます。つまり、すべてのマッチング候補で、チケットのすべてのプレイヤーが受け入れ可能である必要があります。いずれかのプレイヤーがルールに不合格となった場合、チケット全体がマッチングではないと見なされます。不合格となったチケットにはチケットプールに残り、次の引き渡しで再度評価されます。マッチング候補が満たされると、マッチングのすべてのチケットのステータスが更新されます。

  3. プレイヤーの承諾の取得。プレイヤーによるマッチング候補の承諾がマッチメーカーから要求された場合、FlexMatch は各プレイヤーが承諾するまでマッチングを続行できません。マッチメーキングチケットのステータスが変更され、承認が必要なことを示します。これにより、ゲームに対して、一致した各チケットのすべてのプレイヤーからの承諾が要求されます。

    プレイヤーは、潜在的なマッチングを承諾するか拒否するかを選択できます。ゲームでは、プレイヤーからレスポンスを収集して FlexMatch に報告します。マッチング候補のすべてのプレイヤーは、続行するには特定の時間制限内にマッチングを受諾する必要があります。いずれかのプレイヤーがマッチングを却下するか、時間制限までに返答しないと、マッチメーカーはマッチング案を破棄します。マッチングを承諾したプレイヤーのチケットは、マッチメーカーのリクエストプールに戻されます。マッチングを承諾しなかったプレイヤーのチケットは失敗ステータスになり、処理が中断されます。

  4. マッチングをホストするリソースの検索。マッチング案が作成されて承諾されると、FlexMatch は利用可能なホスティングリソースを手配し、マッチングの配置を試みます。マッチメーカーは特定のゲームセッションキューを使用するように設定され、マッチング候補を配置のためにそのキューに渡します。キューは、一連のルールを使用して、マッチングをホストするために利用可能な最善のサーバープロセスのリージョンとフリートを検索します。元のマッチメーキングリクエストにプレイヤーのレイテンシーデータが含まれている場合、キューはこの情報を使用して、マッチングのプレイヤーに対して最小のレイテンシーと最も一貫性が高いゲームプレイエクスペリエンスを提供するリソースを検索します。

    Amazon GameLift は、利用可能なサーバープロセスが確認されると、チーム構造とサイズ、プレイヤーの割り当て、関連するプレイヤー属性を含むゲームプロパティとマッチメーカーデータでゲームセッションレコードを作成します。

  5. 新しいゲームセッションを開始します。 新しいゲームセッションを開始するときに、Amazon GameLift はゲームセッションおよびマッチメーカー情報と共に、開始リクエストをサーバープロセスに送信します。サーバープロセスには、この情報を使用して、マッチングされたゲーム用に新しいゲームセッションを開始します。ゲームセッションでプレイヤーを受け入れる準備が整うと、サーバープロセスが Amazon GameLift に通知します。

  6. プレイヤーを新しいゲームセッションに接続します。 プレイヤーに対してゲームセッションの準備が整うと、Amazon GameLift はマッチングのすべてのプレイヤー用に新しいプレイヤーセッションを作成します。次に、すべてのマッチメーキングチケットを更新し、チケットのステータスを変更して成功を示して、すべてのプレイヤーの接続情報を追加します。チケットステータスのこの変更により、ゲームクライアントへの接続情報の中継がゲームに求められます。これにより、プレイヤーはゲームに参加し、マッチングで自分のスロットとチームの割り当てを要求できます。

バックフィルプロセス

FlexMatch で既存のマッチング用の新しいプレイヤーを見つける方法は次のとおりです。マッチメーキングのバックフィルでは、ゲームセッションでプレイヤースロットの可用性に関する最新情報を必要とするため、ゲームサーバーからマッチングバックフィルリクエストを開始することをお勧めします。もう 1 つのオプションは、ゲームセッションとプレイヤーアクティビティを追跡する、セッションディレクトリサービスなどのクライアント側のゲームサービスを使用することです。ゲームへのマッチングバックフィル機能の追加の詳細については、「を使用した既存のゲームのバックフィルFlexMatch」を参照してください。

マッチメイキング設定で自動バックフィルが有効になっている場合のプロセスは類似しています。唯一の違いは、最初のバックフィルリクエストはユーザーのコードではなく GameLift によって生成されることです。自動バックフィルリクエストは、ゲームセッションにプレイヤースロットの空きがある場合にトリガーされます。

  1. バックフィルマッチメーキングをリクエストします。 マッチングしたゲームには、埋める必要がある空のプレイヤースロットがあります。ゲームがバックフィルリクエストを開始し、使用するマッチメーカーを識別して、ゲームセッションの現在のプレイヤーを示します。各リクエストには、ゲームがリクエストのステータスを追跡し、必要に応じてアクションを実行するために使用するマッチメーキングチケット ID があります。自動バックフィルでは、このチケット ID はゲームセッションのマッチメイキングデータに追加されます。

  2. マッチング候補の検出。 バックフィル用のマッチメーキングチケットは、指定されたマッチメーカーに渡され、新しいマッチング用のチケットと同じプールに配置されます。大規模なマッチングの場合のみ、バックフィルチケットは新しいマッチングのチケットよりも優先されます。

    マッチメーカーは、チケットが新しいプレイヤー用であるか、バックフィルリクエスト用であるかを問わず、チケットとプレイヤーを均等に評価します。1 つの例外として、潜在的なマッチングで複数のバックフィルチケットを持つことはできません。バックフィルチケットは、マッチメーカーのルールで、空のプレイヤースロットをマッチングに備えることを許可する場合でも、正常に完了するには、少なくとも、もう 1 つのチケットでマッチングされる必要があります。マッチング候補が満たされると、マッチングのすべてのチケットのステータスが更新されます。

  3. プレイヤーの承諾の取得。 承諾が必要な場合、新しいプレイヤーのみがバックフィルマッチを受け入れる必要があり、このステップはマッチメーキングリクエストで説明しているように処理されます。現在のプレイヤーは、既にプレイしているマッチングを受諾する必要はありません。その結果、バックフィルリクエストのチケットステータスで承諾が必要であることが示されていても、ゲームでアクションを実行する必要はありません。

    制限時間内に、提案された新しいプレイヤーがマッチングを受諾しなかった場合、マッチング候補は削除され、新しいプレイヤーは既存のマッチングに追加されません。これが発生すると、バックフィルリクエストのチケットは処理のためチケットプールに戻されます。

  4. 新しいマッチングデータで既存のゲームセッションを更新します。 バックフィルマッチが正常に行われた場合、新しいゲームセッションを配置する必要はありません。代わりに、Amazon GameLift は既存のゲームセッションのマッチングデータを更新し、新しいプレイヤーとチームの割り当てを追加します。Amazon GameLift は更新されたゲームセッション情報を、既存のゲームをホストしているサーバープロセスに送信します。

  5. 新しいプレイヤーを既存のゲームセッションに接続します。Amazon GameLift は新しいプレイヤー用のプレイヤーセッションを作成し、現在のステータス、プレイヤーセッション、および接続情報でマッチメーキングチケットを更新します。新しいプレイヤーのチケットステータスを追跡しているクライアントゲームサービスは、接続情報をゲームクライアントに中継します。これで、プレイヤーは既存のゲームに参加し、プレイヤースロットを要求できます。