メインコンテンツへスキップ

概要

キューとルールのシステムにより、多数のシナリオに柔軟に対応できます。ここでは、より一般的なマッチメイキングのユース ケースとそれに関連するキューの例をいくつか紹介します。これらの各構成は、PlayFab API を使用して直接送信できます。<!—the Matchmaking Admin API.—> これらのオプションは、Game Manager UI を使用して設定することもできます。

最初のキュー、または “クイック マッチ”

すべてのタイトルは、基本的なフローを確立するために、このシンプルなキューから始める必要があります。このキューは 2 人のプレイヤーをマッチさせ、マッチするためにプレイヤーが同じビルド文字列を渡すことを要求する省略可能なルールを 1 つ含みます。ビルドを指定しない場合、プレイヤーはビルドに関係なく、このキュー内の他のプレイヤーとマッチできます。

複数のゲーム モード

タイトルには、多くの場合、さまざまなゲームの遊び方があります。これらのプレイヤー同士が決してマッチすべきでない場合は、別々のキューに配置することでパフォーマンスが最適化されます。

ゲーム モードをまたいだ検索

プレイヤーがゲーム モードをまたいで他のプレイヤーとマッチすることを想定している場合は、単一のキューを使用して Set Intersection ルールを作成します。プレイヤーは複数のゲーム モードを指定でき、ルールによって、すべてのプレイヤーが少なくとも 1 つの共通のゲーム モードを含むマッチに限定されます。
この機能が正しく動作するには、プレイに必要なプレイヤー数がモード間で同じである必要があります。

拡張を使用したスキルベースのバトル ロイヤル (フリー フォー オール) ゲーム

一般的なシナリオとして、スキルに基づいてプレイヤー同士をマッチさせようとする場合があります。この例では、キューはプレイヤーのスキル属性の差が 0.2 以内であることを要求し、この値は時間の経過とともに 0.5 まで増加します。30 秒を超えて待機しているチケットについては、スキルの差がいくらであっても許可されます。 この例の値は、利用可能なスキルの範囲が 0 から 1 の間であることを前提としています。タイトルでプレイヤーのスキルを追跡するために使用する値の範囲と、マッチの速さよりもスキルをどの程度重視するかに合わせて、これらの値を調整してください。 さらに、ルールが 30 秒で省略可能になるのは、まったくプレイしないよりもスキルの不均衡なゲームをプレイするほうがよいゲームを想定しています。不均衡なゲームが完全に悪い体験となるゲームでは、SecondsUntilOptional を調整してください。完全に削除すると、ルールは無期限にアクティブなままになります。

拡張のカスタマイズ

各時間間隔で任意の値を使用するように拡張をカスタマイズできます。たとえば、許容されるスキルを最初はゆっくりと広げ、後で時間の経過とともにより速く広げることができます。

時間の経過に伴うプレイヤー数の拡張

一部のタイトルでは、最初はフル マッチを優先しますが、時間の経過とともにより少ない人数でも満足できる場合があります。その一例が、最大 50 人のプレイヤーで開始するように設計されているものの、マッチメイキングのタイムアウト後はより少ないプレイヤーで続行できるバトル ロイヤル スタイルのゲームです。 MinMatchSize と MaxMatchSize には拡張が含まれていないため、MatchTotalRule を使用して、マッチに必要なプレイヤー数を変更できます。各プレイヤーは、関連する属性を 1 に設定します。ルールはこれらの値を合計して、マッチに必要なプレイヤー数を動的に適用します。
MaxOverrides または MinOverrides 配列を指定しない場合は、代わりにルールの元の Max または Min 値が使用されます。

標準的な 4 対 4 スタイルのスキルベース

PlayFab Matchmaking は、チーム指向のマッチをサポートしています。チームを指定すると、同じチケットでまとめて送信したプレイヤーはすべて 1 つのチームに割り当てられ、互いに対戦させられることはありません。 PlayFab Matchmaking は、チームのバランスを確保するためのさまざまなチーム ルールもサポートしています。この例は 4 対 4 のマッチ用で、チーム間でスキルのバランスが取れるようにします。

マルチプレイヤー サーバー

キューは PlayFab のマルチプレイヤー サーバー機能に自動的に連携でき、サーバーを割り当てて、マッチしたプレイヤーのリストをサーバーに渡すことができます。このキューは、そのような構成の最小限の例を示しています。それは、ServerAllocationEnabled フラグと、開始するサーバーのビルドを表す BuildId です。 ServerAllocationEnabled フラグを true に設定する場合は、各マッチに対してサーバーを割り当てる場所を示す RegionSelectionRule も含める必要があります。

大規模チーム バトル (12 対 12)

大規模なチーム ゲームには、追加の要件がある場合があります。この例では、キューはマルチプレイヤー サーバーを作成するように構成されています。これは、これほど多くのプレイヤーを含むゲームを管理するために必要になることがよくあります。この構成は、前の例と似ています。 スキルに加えて、チームの類似性を促すために別のチーム ルールを追加します。各陣営で許可される大規模チームは 1 つだけであり、事前に編成されたチームが多数のランダムなプレイヤーとマッチするというよくある状況を防ぎます。

バトル ロイヤル スタイルのゲーム

バトル ロイヤル スタイルのゲームでは、多くの人が 1 つのアリーナに配置されます。この例では、ゲームは 4 人のチームで設定されています。現在、このようなチーム シナリオで許可されるプレイヤー数には 32 人という制限があります。この制限は今後改善される予定です。 この例には、専用サーバー用のマルチプレイヤー サーバーのセットアップ情報も含まれています。これは、多数のプレイヤーを含むゲームで必要になることがよくあります。この構成は、前の例と似ています。

非対称なクロスプレイ設定の処理

プレイヤーはさまざまなクロスプレイ設定を選択できるため、マッチメイキングの設定は非対称になります。クロスプレイを有効にしたプレイヤーはどのプラットフォームとでもマッチすることをいといませんが、クロスプレイを無効にしたプレイヤーは自分と同じプラットフォームのプレイヤーとのみマッチすることを望みます。 文字列の等価性ルールまたはセットの交差ルールを使用して、この種の非対称性に対応できるマッチメイキング キューを実装できます。この例では、文字列の等価性を使用しています。 プレイヤーがクロスプレイを無効にした場合、クライアントはそのプレイヤーの DeviceType (たとえば、"xbox"、"playstation") を指定し、ルールによって同じプラットフォームのマッチに限定されます。プレイヤーがクロスプレイを有効にした場合、クライアントは DeviceType 属性を完全に省略し、MatchAny の AttributeNotSpecifiedBehavior によって、どのプラットフォームともマッチできるようになります。
プレイヤーのグループがまとめてチケットを送信する場合、サービスはそのグループを 1 つの単位として扱います。グループがマッチやチームをまたいで分割されることはありません。ゲーム クライアントは、チケットを送信する前にグループの構成を検証する必要があります。たとえば、プレイヤーがクロスプレイを無効にしている場合は、チケットが作成される前に、そのプレイヤーがクロスプラットフォーム グループに参加できないようにします。
マッチメイキングの時間が予想よりも長い場合は、プラットフォームごとに個別のキューを作成し、クロスプレイをサポートするために必要に応じてクロスプラットフォーム キューを作成することを検討してください。

ホスト/検索者またはロールベースの要件

PlayFab Match はチケットベースのマッチング システムを使用しており、ゲーム ホストは事前に選択されません。ただし、MatchTotalRule を使用してマッチで許可されるホストの数を制限することで、ホスト/検索者システムをエミュレートできます。 その後、チケットは 1 を指定することで、ホストであるかどうかを事前に指定できます。各マッチには、ホストがちょうど 1 人含まれている必要があります。
ホストの数が検索者の数を大幅に上回る場合、またはその逆の場合、この不均衡により、すべてのプレイヤーのマッチメイキング時間が長くなる可能性があります。マッチメイキング設計の影響を考慮し、任意のサブ集団に、マッチメイキング ルールと目標とする平均マッチ時間を満たす十分な数のプレイヤーが存在するようにしてください。
ゲームにはロールの要件がある場合があります。たとえば、ゲームでドラマー 1 人、ギタリスト 2 人、ボーカリスト 1 人が必要な場合があります。あるいは、タンク 1 人、DPS (damage per second) 2 人、サポート 1 人が必要な場合もあります。ゲームでは、MatchTotalRule を使用してこれらのロールを要求できます。

重要度の異なるルール

ルールは、どのチケットが他のチケットとマッチする資格があるかを制限することと、それらのチケットが選択される順序を決定することの両方によって、マッチメイキングを導きます。複数のルールが存在する場合、システムはそれらすべての制限を考慮します。ただし、タイトルは、残りの適格なチケットに対して、あるルールの優先度を高くすることができます。 この例では、プレイヤーは特定のスキルと経験レベルの範囲内にいる必要があります。ただし、指定されたスキルと経験の 範囲内に多くのチケットがある場合、このキューは、経験レベルが近いチケットよりもスキルが近いチケットを優先します。 制限を満たすチケットを評価する際、スキルの差は経験の差の 3 倍 として計算されます。

DLC パック

さまざまな DLC パックを使用する場合、プレイヤーは SetIntersectionRule を使用して、一致する DLC を持つ他のプレイヤーのみを探すことを選択できます。各プレイヤーは所有する DLC パックを渡し、マッチではグループが少なくとも 1 つの DLC パックを共有している必要があります。
30 秒後にルールは省略可能になるため、プレイヤーは DLC を共有していなくてもマッチできます。

統計の有効化

統計を有効にすると、タイトルでキューに関する情報を表示できます。この情報は、プレイヤーがプレイしたいゲーム モードを選択する際に、プレイヤーの期待値を設定するのに役立ちます。 逆に、タイトルによっては、ビジネス インテリジェンスの目的で、またはプレイヤーを混雑しているキューに誘導しないようにするために、この情報を非表示にしたい場合があります。 このキューでは、キュー内に存在するプレイヤーの数と、チケットがマッチするまでの推定時間の両方を表示できるようにします。
サーバーはいつでもこの情報を取得できます。次の構成は、ユーザーもこの呼び出しを行うことを許可するかどうかのみを制御します。
最終更新日 2026年10月20日