パートナー センターでマッチメイキングを構成する
このトピックでは、互換性のあるプレーヤーを選択するためにパートナー センターを構成する方法について説明します。
SmartMatch マッチメイキング ランタイム操作の構成
SmartMatch 構成時のチーム ルールの定義
SmartMatch マッチメイキング ランタイム操作の構成
SmartMatch マッチメイキングの構成はすべて、パートナー センターを通じて行われます。
マッチメイキング セッション テンプレートの構成
マッチメイキングには、2 種類の関連セッションがあります。
- マッチ チケット セッション。マッチメイキング サービスへの入力です。
- マッチ ターゲット セッション。これは出力です。
セッション テンプレートを構成するときは、セッションの種類ごとにテンプレートを作成する必要があります。
チケット セッションでは、専用テンプレートを使用できます。 または、ゲーム プレイへの使用を意図していないロビー セッションまたは他のセッション用にテンプレートを再利用できます。
Important
チケット セッションでは、[サービスの品質 (QoS)] のチェックを有効にしないでください。また、"ゲームプレイ"機能にマークを付けないでください。
ターゲット セッションでは、マッチメイキングされるゲーム プレイ向けのテンプレートを使用する必要があります。 ゲーム プレイの開始前にピア間の QoS チェックを有効にする設定が含まれている必要があり、"ゲームプレイ" 機能でマークされている必要があります。
パートナー センターの構成 UI では、各セッションを 1 つ以上のホッパーにマップできます。各ホッパーには、そのホッパーでセッションがどのようにマッチされるかを決定するルールが含まれます。 詳細については、後の「マッチメイキングの基本的なホッパー構成」を参照してください。
マッチメイキングの基本的なホッパー構成
このセクションでは、基本的なホッパー フィールドの構成に使用するフィールドを定義します。 構成した後、このトピックで後述する「ホッパー ルールの構成」に説明されているように、ホッパー ルールを構成する必要があります。 次のスクリーンショットはホッパー エディターを示しています。 以降のセクションでは、ここに挙げた手順について説明します。
名前
ホッパーの名前です。マッチメイキングにセッションを送信するときに使用されます。 この名前は、マッチ チケットの作成時に、XblMatchmakingCreateMatchTicketAsync メソッドにパラメーターとして渡される値と一致する必要があります。
最小/最大グループ サイズ
ホッパー内のセッションから作成されるプレイヤー グループの最小および最大サイズ。 マッチメイキング サービスは、マッチされるグループを、最大グループ サイズまで、可能な限り大きく作成しようとします。 ただし、マッチされるグループは、最小グループ サイズを満たすために十分なプレイヤーを集めることができる場合に作成します。
Should Rule Expansion Cycles (推奨ルールの拡張サイクル)
推奨ルールでのマッチメイキング サービスは、成功するマッチが見つからない場合、時間の経過とともに検索空間を増やし、提供されたマッチメイキング ルールの緩和を試みます。 このプロセスは、[Should Rule Expansion Cycles (推奨ルールの拡張サイクル)] フィールドを使用して指定される、複数のサイクルに対して実行されます。
最後の拡張サイクルで推奨ルールは削除されるため、チケットのマッチを妨げなくなります。 ただし、複数のチケットが使用可能な場合は、最適なマッチを判断するために引き続き使用されます。 Number と QoS 型のみが、削除される前に拡張されます。
詳細については、後の「ホッパー ルールの構成」セクションを参照してください。
[Should Rule Expansion Cycles (推奨ルールの拡張サイクル)] 設定の値を増加させると、推奨ルール拡張のサイクル数が増えます。 ただし、この値を増やすとマッチメイキングの時間も長くなります。 既定値は 3 で、ほとんどの構成で一般的に十分です。
重要
拡張サイクルは 5 秒の固定間隔で発生します。 最後の拡張サイクルで、すべての 推奨ルールは、残りのマッチメイキングを試行するときに考慮されなくなります。
Ranked hopper
通常、SmartMatch はブロックされているプレイヤーがマッチングされることを防ぎます。 [Ranked Hopper] がチェックされている場合、プレイヤーがこのシステムを使用してよりスキルの高いプレイヤーを回避することを防ぐために、このロジックがバイパスされます。
ホッパー ルールの構成
このセクションでは、ホッパー ルールの構成に使用するフィールドを定義します。
[Common Rule] フィールド
このセクションで定義されているフィールドはすべてのホッパー ルールに共通です。
[Rule Name:] 構成目的でルールに表示されるフレンドリ名。
[Rule Type:] ルールの種類。 オプションは [MUST (必須)] および [SHOULD (推奨)] です。
マッチメイキングが成功するには、MUST ルールが満たされる必要があります。
成功したマッチを見つけるには、推奨ルールを緩和、削除できます。
このプロセスの詳細については、このトピックで前述した「Should Rule Expansion Cycles (推奨ルールの拡張サイクル)」のセクションを参照してください。
[Data Type:] マッチメイキング ルールの属性のデータ型。 有効値は次に示すとおりです。
- [Number:] 単純な 32 ビットの数値を指定します。
- [String:] 最大 128 文字の Unicode 文字列を指定します。
- [Collection:] 文字列の配列を指定します。 この値を使用して、ダウンロード コンテンツ (DLC)、チーム メンバーシップ、またはプレイヤーの役割設定を識別します。
- [Quality of Service:] マッチメイキングにレイテンシー QoS データを含めるためのカスタム データ型を指定します。 このようなルールは、マッチメイキング ホッパーあたり 1 つだけ使用してください。
注意
この制限がタイトルで問題となる場合は、デベロッパー アカウント マネージャー (DAM) にお問い合わせください。
- [Total Value:] 送信されたマッチメイキング値を合計するカスタム データ型を指定します。 この値を使用して、結果として得られる合計を特定の範囲内に収める、または正確な値にすることができます。
- [Team:] マッチメイキング要求に含まれるプレイヤーのチームのカスタム データ型を指定します。 この値を使用して、単一のマッチ チケット内のプレイヤーが複数のチームに分散されるのを回避できます。
データ型固有のルール フィールド
このセクションでは、一部のデータ型に適用されるが、その他のデータ型には適用されないルールを定義するために使用するフィールドを定義します。 UI は、どのデータ型が特定のルールに適用されるかを明確に示すことができます。
[Allow Wildcards:] マッチ チケットで属性を省略できるかどうかを示す値。 省略される場合、チケットは、この属性の値に関係なく、その他のチケットと互換性を持つようになります。
[Attribute Source]: データ型の値のソース。 有効なソースは次に示すとおりです。
- [Title provided:] データ値は、マッチ チケットで送信されます。
- [User stat instance:] データ値は、
UserStatisticsサービスから自動的に取得されます。
[Attribute Name:] 属性値のソースの名前。 マッチ チケット内のプロパティ名またはユーザー統計情報の名前のいずれかです。
[Default Value:] マッチメイキング要求に対して値が指定されていない、または使用できない場合の、データ型の既定値。 [Allow Wildcards] フィールドが選択されていて、値が指定されていない場合、既定値は適用されません。
[Weight:] ルールの重要性。 Weight は、マッチメイキングおよびルール拡張中にどのルールを優先するかを示すために使用できます。 Weight の値は正数で、既定では 1 に設定されています。
[Flatten Method:] Number データ型のみ。 マッチを満たすために複数の値がどのように組み合わされるかを示す値。 単一のマッチ チケット内および複数のチケットにわたる異なるプレイヤーの複数の値に適用されます。 有効値は次のとおりです。
- [Min/Max:] 異なるマッチ チケットからの複数の値の最小または最大値を使用します。
- [Average:] 異なるマッチ チケットからの複数の値の平均値を使用します。
[Max Diff:] Number データ型のみ。 ルールを満たすために 2 つの比較される値の間で許容される数値の最大差。 推奨ルールの場合、この値はルール拡張の開始点です。
[Set Operation:] Collection データ型のみ。 設定値のグループのマッチ時に実行する操作。 次のようなオプションがあります。
[Intersection:] 2 つのコレクションを、それらの交差の量に基づいてマッチさせます。 この設定により、類似または同一のコレクション値になります。
[Difference:] 2 つのコレクションを、それらの差の量に基づいてマッチさせます。
[Role Preference:] 役割ベースのゲーム モードでプレイヤーの役割の設定に基づいてコレクションをマッチさせます。
[Target Intersection]: [Set Operation] 構成の一部。 マッチされる前の、2 つのコレクションの最小の交差または最大の差。
[Network Topology:] Quality of service データ型のみ。 QoS に使用されるネットワーク トポロジ。 可能な値は、[Peer to Peer]、[Peer to Host]、および [Client/Server] です。
[Maximum Latency/Scaling Maximum: ] Quality of service データ型のみ。 指定されたネットワーク トポロジ内でマッチメイキングを成功させるための最大遅延。
[Client-Server] の [Quality of service] 推奨ルールを使用するとき、この値は (必須の遅延ではなく) スケーリング値として扱われます。
注意
さらに、ホッパーには既定の評判ルールも適用されます。 これらのルールは削除できません。マッチメイキング中に評判の処理を正しく行うために使用されます。
[Allow Waiting for Roles:] Collection Role Preferences データ型のみ。 すべての利用可能な役割を埋めるためにマッチ サービスがマッチメイキング チケットを保持するかどうかを指定します。
拡張デルタ
送信されたルールを各拡張生成のためにどのぐらい緩和するかを示す値。 拡張デルタは、Max Diff 値に加えて適用されます。 詳しくは、後の例 1 (ルールの拡張) を参照してください。
拡張デルタを使用して、複数の数値を異なる速度で拡張することもできます。 すべてのルールに適用されるため、拡張サイクル構成設定を通じてこれを行うことはできません。 代わりに、小数の拡張値 (0.4 など) を使用します。
拡張は、新しい整数に達したときにのみ発生します。これにより、同じ数の拡張サイクルに対しても、異なる拡張速度が可能になります。
QoS 拡張 (ピア ツー ピア、ピア ツー ホスト)
ピア ゲーム用の QoS 型の拡張の場合、拡張デルタを構成することはできません。 代わりに、以下の拡張方法のいずれかを使用する必要があります。
MaxLatency が 256 より小さい
拡張は MaxLatency × 拡張サイクルで実行されます。
たとえば、初期値が 200 の場合、最初のサイクルで 200 が使用され、2 番目のサイクルでは 400 が使用されます。
MaxLatency が 256 以上
拡張は、50 から MaxLatency 256 まで線形的に行われます。
たとえば、初期値が 556 の場合、値は、サイクルの数にわたって 50 から 300 まで線形的に拡張します。 つまり、6 つのサイクルが選ばれた場合、値は 50、100、150、200、250、および 300 になります。 5 つのサイクルが選ばれた場合、値は 50、112.5、175、237.5、および 300 になります。
QoS 拡張 (クライアント/サーバー)
専用サーバーを使用しているとき、拡張は相対的な優先度に基づきます。 早期の拡張サイクルでは、最も優先度の高いサーバーのみが考慮されます。 時間が経過すると、より優先度の低い他のサーバーが使用されます。
適切な拡張を保証するために、Scaling Maximum と呼ばれる、MaxLatency に似た値が必要です。 また、許容できる最大の ping 時間に設定してください。 この値は ping 時間の絶対要件を提供するのではなく、プレイヤーによって提供される異なったサーバー ping 時間の相対的スケールを与えます。
許容できない ping 時間のサーバーを除外するには、それらのサーバーを要求内のリストから削除します。
例 1 (ルール拡張)
マッチメイキングにはプレイヤー レベルが使用されます。プレイヤーは、レベルの近さに基づいて大まかにマッチされます。 レベル間の違いが最も少ないプレイヤーが優先されます。
- プレイヤー レベルのルール
- [Rule Type]: SHOULD
- [Data Type]: Number
- [Max Diff]: 1
- [Expansion Delta]: 2
- [Flatten Method]: Average
既定では、プレイヤー レベルの必要な差は 1 以下です。
- この差の範囲内でマッチが見つかった場合、プレイヤーはマッチされます。
- 最初の一致が見つからない場合、プレイヤー レベル値は反復ごとに 2 拡張されます (既定では 3 反復)。
このシナリオの結果、レベル 20 のプレイヤーのマッチメイキング動作は次の表に示すようになります。
| 手順 | マッチ候補のレベル値 | マッチを成功させるための効果的なレベルの差 |
|---|---|---|
| 初期の送信値 | 19-21 | 1 |
| 拡張サイクル 1 | 17-23 | 3 |
| 拡張サイクル 2 | 15-25 | 5 |
| 拡張サイクル 3 | 13-27 | 7 |
拡張サイクルが続くにつれ、マッチを成功させるための効果的なレベルの差は、[Max Diff] 値を変更することなく増加します。 プレイヤー レベル値のみが緩和されます。
例 2 (コレクション ルール)
ゲームは、プレイヤーに対して利用可能な 3 種類の DLC をリリースします。 このマッチメイキング ルールは、"DLC のみ" のゲームプレイ マッチメイキングに適用されます。プレイヤーは、他のプレイヤーとマッチメイキングされるためには、少なくとも 1 つの DLC を所有している必要があります。
- プレイヤー DLC ルール
- [Rule Type]: MUST
- [Data Type]: Collection
- [Set Operation]: [Intersection]
- [Target Intersection]: 1
プレイヤーは、自分の DLC を評価し、次の表に示す値をマッチ チケットで送信します。
注意
次の表で、コレクション値は DLC の所有を示しています。 DLC をプレイヤーが利用可能な場合は 1 に設定され、利用可能でない場合は 0 に設定されます。 指定しない場合は、0 に設定されます。 |
| プレイヤー | コレクション値 | プレイヤーとのマッチ | 注意事項 |
|---|---|---|---|
| プレイヤー 1 | { "1", "1", "1"} | 3 | すべての DLC を所有 |
| プレイヤー 2 | { "0", "0", "0"} | なし | DLC を所有していない |
| プレイヤー 3 | { "1", "0", "0"} | 1 | 最初の DLC を所有 |
例において [Target Intersection] を 2 に設定した場合、交差は 1 のみであるため、プレイヤー 1 と 3 はマッチされません。
例 3 (以前のプレイヤーを避ける)
タイトルは、最近一緒にプレイしたプレイヤーとのゲームを避けることを優先します。
- [Rule Type]: MUST
- [Data Type]: Collection
- [Set Operation]: Difference
- [Target Intersection]: 0
SmartMatch 構成時のチーム ルールの定義
チーム ルールの構成
チーム ルールを設定するには、まずパートナー センターでチーム ルールを作成します。 ゲームがこのホッパーでマッチングされたチケットから作成するチーム サイズを入力します。
たとえば、4 対 4 を想定しているゲームでは、それぞれの最大サイズが 4 で、名前が異なる 2 つのエントリを作成する必要があります。
最小限のチーム サイズも用意されています。 チームの人数が少なくてもゲームができる場合に使用します。 それ以外の場合は、最大サイズと最小サイズを同じ値にします。
チーム ルールの使用
チーム ルールの構成後、ホッパー内のチケットは、分割なしで各グループをチームに組み込むことができない場合はマッチングされなくなります。 ルールによって、チーム割り当ての結果が members/constants/custom/matchmakingresult/initialTeam の下のターゲット セッションに書き込まれます。
注意
これは単なる割り当ての候補です。 タイトルは、プレイヤーを再編成することによりさらに良いゲームにできると判断することもできますが、その場合も、チケットが別々のチームに分割されないようにします。
進行中のゲームに対してチケットが作成される場合、チーム ルールは追加情報を必要とします。 たとえば、8 人のプレイヤーが 4 対 4 のゲーム内にいるときに、2 人のプレイヤーが離脱または接続解除したとします。 タイトルはそれらの空きを埋める必要がありますが、ゲームがプレイ中の間はチームを再編成できません。
進行中のゲームの補充を実行しようとしていることは、PreserveSessionフィールドがalwaysに設定されたチケットによって表されます。
このような場合、チームは既にプレイヤーに割り当てられているので、タイトルは現在のチーム割り当てを指定して、マッチで各チームの空き数がわかるようにする必要があります。
各プレイヤーがいるチームの名前を提供するために、各プレイヤーは自分のチーム名を members/me/properties/system/groups の下のゲーム セッションに書き込みます。
このフィールドは JArray です。
前述のプロパティがゲーム セッションに書き込まれると、1 人のプレイヤーが、さらにプレイヤーを探そうとして、そのセッションのチケットを作成します。 チケットが実行されると、マッチは参加するプレイヤーによる推奨チームを members/constants/custom/matchmakingresult/initialTeam に再び書き込みます。
同等サイズのチームを優先する
さらに、マッチはまず最もサイズの大きいチームによって作成されます。 このため、仮定の 4 対 4 ホッパーでは、4 プレイヤーのチケットが、4 プレイヤーのチケットがなくなるまで先にマッチングされます。 続いて 3 プレイヤーのチケットどうしがマッチングされ、その次は 2 プレイヤーのチケットのマッチングに進みます。
この方法では、同等サイズのチケットが存在し、他のルールで禁止されていなければ、通常は同等サイズのチケットどうしが対戦することになります。
注意
チーム ルールの優先度は他のルールよりもかなり高いことに注意してください。 たとえば、ユーザーが限られており、高スキルでサイズが 4 のチケットが 1 つ (A)、低スキルでサイズが 4 のチケットが 1 つ (B)、および高スキルでサイズが 1 のチケットが 4 つ (C ～ F) からなると仮定します。 チーム ルールにより、マッチでは A と C、D、E、F ではなく、A と B のマッチングが優先されます。
SHOULD variant (推奨ルールとの違い)
必須ルールは、すべての生成でチケットの分割を阻止し、同等サイズのチームを優先する分類を提供します。 推奨ルールは、最後の生成までは同じで、その後はチケットが分割される可能性がありますが、同等サイズのチームを優先する分類は引き続き有効です。