SmartMatch マッチメイキング実行時操作の構成
すべての SmartMatch マッチメイキング構成は Partner Center を介して行われます。マッチメイキング セッション テンプレートの構成
マッチメイキングには、2 種類の関連するセッションがあります。- マッチ チケット セッション。マッチメイキング サービスへの入力
- マッチ ターゲット セッション。出力
チケット セッションでは、サービス品質 (QoS) チェックを有効にしてはならず、“gameplay” 機能でマークしてはなりません。
マッチメイキング用の基本ホッパー構成
このセクションでは、基本ホッパー フィールドを構成するために使用されるフィールドを定義します。 この構成の後、このトピックで後述する「ホッパー ルールの構成」セクションで説明されているように、ホッパー ルールを構成する必要があります。次のスクリーンショットは、ホッパー エディターを示しています。以降のセクションで説明します。
名前
セッションをマッチメイキングに送信するときに使用されるホッパーの名前。 この名前は、マッチ チケットの作成中に XblMatchmakingCreateMatchTicketAsync メソッドにパラメーターとして渡される値と一致する必要があります。最小/最大グループ サイズ
ホッパー内のセッションから作成されるプレイヤー グループの最小および最大サイズ。 マッチメイキング サービスは、最大グループ サイズまで、可能な限り大きなマッチしたグループを作成しようとします。 ただし、最小グループ サイズを満たすのに十分なプレイヤーを集めることができれば、マッチしたグループを作成します。Should ルール拡張サイクル数
SHOULD ルールについて、マッチが成立しない場合、マッチメイキング サービスは、時間の経過とともに検索空間を広げ、指定されたマッチメイキング ルールを緩和しようとします。 このプロセスは、Should ルール拡張サイクル数フィールドを使用して指定される、複数のサイクルにわたって実行されます。 最後の拡張サイクルでは、チケット同士のマッチをそれ以上妨げないように SHOULD ルールが除外されます。 ただし、複数のチケットが利用可能な場合には、最良のマッチを決定するために引き続き使用されます。 数値と QoS タイプのみが除外される前に拡張されます。 詳細については、このトピックで後述する「ホッパー ルールの構成」セクションを参照してください。 Should ルール拡張サイクル数の設定の値を増やすと、SHOULD ルールの拡張のためにより多くのサイクルが提供されます。ただし、これによってマッチメイキング期間も長くなります。 既定値は 3 で、通常はほとんどの構成に対して十分です。拡張サイクルは 5 秒の固定時間間隔で発生します。最後の拡張サイクルでは、マッチメイキング試行の残りの期間、すべての SHOULD ルールは考慮されなくなります。
ランク付きホッパー
通常、SmartMatch はブロックされたプレイヤーがマッチングされないようにします。 ランク付きホッパーが選択されている場合、プレイヤーがこのシステムを使用してより高いスキルのプレイヤーを回避しないようにするために、このロジックはバイパスされます。ホッパー ルールの構成
このセクションでは、ホッパーのルールを構成するために使用されるフィールドを定義します。共通ルール フィールド
このセクションで定義されているフィールドは、すべてのホッパー ルールに共通です。- ルール名: 構成目的でルールに対して表示されるわかりやすい名前です。
-
ルール タイプ: ルール タイプ。オプションは MUST および SHOULD です。
- MUST ルールは、マッチメイキングを成功させるために満たされる必要があります。
- SHOULD ルールは、マッチを成功させるために緩和または削除できます。 このプロセスの詳細については、このトピックで前述した「Should ルール拡張サイクル数」セクションを参照してください。
-
データ型: マッチメイキング ルールの属性のデータ型。
可能な値は次のとおりです。
- Number: シンプルな 32 ビット数値を指定します。
- String: 最大 128 文字の Unicode 文字列を指定します。
- Collection: 文字列の配列を指定します。この値を使用して、プレイヤーのダウンロード可能なコンテンツ (DLC)、分隊メンバーシップ、または役割の設定を特定します。
- Quality of Service: マッチメイキングに遅延 QoS データを含めるためのカスタム データ型を指定します。マッチメイキング ホッパーごとにそのようなルールを 1 つだけ使用する必要があります。
[!NOTE] この制限がタイトルにとって問題である場合は、開発者アカウント マネージャー (DAM) に連絡してください。
- Total Value: 送信されるマッチメイキング値を合計するカスタム データ型を指定します。この値を使用して、結果として得られる合計が特定の範囲内であること、または正確な値であることを確認できます。
- Team: マッチメイキング要求に含まれるプレイヤーのチームのためのカスタム データ型を指定します。この値を使用して、単一のマッチ チケット内のプレイヤーが複数のチームに分割されないようにできます。
データ型固有のルール フィールド
このセクションでは、一部のデータ型に適用され、他のデータ型には適用されないルールを定義するために使用されるフィールドを定義します。UI では、特定のルールに適用されるデータ型を明確にできる必要があります。- ワイルドカードの許可: 属性をマッチ チケットで省略できるかどうかを示す値。 省略されている場合、その属性の値に関係なく、チケットは他のあらゆるチケットと互換性を持つようになります。
-
属性ソース: データ型の値のソース。可能なソースは次のとおりです。
- タイトル指定: データ値はマッチ チケットで送信されます。
- ユーザー統計インスタンス: データ値は
UserStatisticsサービスから自動的に取得されます。
- 属性名: 属性値ソースの名前。 マッチ チケット内のプロパティ名またはユーザー統計の名前のいずれかです。
- 既定値: マッチメイキング要求に値が指定されていないか、利用できない場合の、データ型の既定値。 ワイルドカードの許可フィールドが選択されており、値が指定されていない場合、既定値は適用されません。
- 重み: ルールの重要性。 重みは、マッチメイキングとルール拡張中にどのルールが優先されるかを示すために使用できます。 重みの値は正の数でなければならず、既定値は 1 です。
-
フラット化方式: Number データ型のみ。
マッチを満たすために複数の値がどのように結合されるかを示す値。
これは、単一のマッチ チケット内の異なるプレイヤーの複数の値、および複数のチケットにまたがる複数の値に適用されます。可能な値は次のとおりです。
- Min/Max: 異なるマッチ チケットから得られる複数の値のうち、最小または最大値を使用します。
- Average: 異なるマッチ チケットから得られる複数の値の平均値を使用します。
- 最大差: Number データ型のみ。 ルールを満たすために比較される 2 つの値の間に許容される最大の数値差。SHOULD ルールの場合、この値はルール拡張の起点になります。
-
セット操作: Collection データ型のみ。
セット値のグループのマッチングで実行する操作。可能なオプションは次のとおりです。
- 積集合: 2 つのコレクション間の共通部分の量に基づいて、それらをマッチングします。この設定により、類似または同一のコレクション値になります。
- 差集合: 2 つのコレクション間の差の量に基づいて、それらをマッチングします。
- 役割の設定: 役割ベースのゲーム モードにおけるプレイヤーの役割の設定に基づいてコレクションをマッチングします。
- ターゲット共通部分: セット操作構成の一部。 2 つのコレクションがマッチングされる前の最小の共通部分または最大の差。
- ネットワーク トポロジ: Quality of Service データ型のみ。 QoS に使用されるネットワーク トポロジ。 可能な値は、Peer to Peer、Peer to Host、および Client/Server です。
-
最大遅延/スケーリング最大値: Quality of Service データ型のみ。
指定されたネットワーク トポロジ内でマッチメイキングを成功させるための最大遅延。
Client/Server の Quality of Service SHOULD ルールを使用する場合、この値は (必要な遅延ではなく) スケーリング値として扱われます。
[!NOTE] さらに、既定のレピュテーション ルールもホッパーに適用されます。これらのルールは削除できず、マッチメイキング中のレピュテーションの正しい処理を確実にするために使用されます。
- 役割の待機の許可: Collection の役割設定データ型のみ。 利用可能なすべての役割を埋めるためにマッチ サービスがマッチメイキング チケットを保持するかどうかを指定します。
拡張デルタ
各拡張世代で送信されたルールをどれだけ緩和するかを示す値。 拡張デルタは、最大差の値に加えて適用されます。 詳細については、このトピックで後述する「例 1 (ルール拡張)」を参照してください。 拡張デルタを使用して、複数の数値を異なる速度で拡張することもできます。 これは、拡張サイクル構成設定を通じては可能ではありません。これはすべてのルールに適用されるためです。 代わりに、10 進数の拡張値 (例: 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 拡張 (client/server)
専用サーバーを使用する場合、拡張は相対的な優先度に基づきます。 早い拡張サイクルでは、最も優先されるサーバーのみが考慮されます。 時間の経過とともに、他の優先度の低いサーバーが使用されます。 適切な拡張を確保するために、MaxLatency と類似した Scaling Maximum と呼ばれる値が必要です。この値は、依然として許容できる最大の ping 時間に設定する必要があります。ただし、この値は、ping 時間の絶対的な要件を提供するのではなく、プレイヤーが提供する異なるサーバーの ping 時間に対して相対的なスケールを提供します。 許容できない ping 時間を持つサーバーを、要求内の一覧から削除することで除外できます。 このトピックの先頭に戻る。例 1 (ルール拡張)
マッチメイキングにプレイヤー レベルが使用され、プレイヤーは、レベルの近さに基づいて緩やかにマッチングされます。 レベルの差が最も少ないプレイヤーが優先されます。- プレイヤー レベル ルール
- ルール タイプ: SHOULD
- データ型: Number
- 最大差: 1
- 拡張デルタ: 2
- フラット化方式: Average
- この差の範囲内でマッチが見つかった場合、プレイヤーはマッチングされます。
- 最初のマッチが見つからなかった場合、プレイヤー レベルの値は反復ごとに 2 ずつ拡張されます (既定では 3 回の反復)。
例 2 (コレクション ルール)
ゲームが、プレイヤーが利用可能な 3 種類の DLC をリリースします。 このマッチメイキング ルールは、「DLC のみ」のゲームプレイ マッチメイキングに適用され、プレイヤーは、他のプレイヤーとマッチメイキングされるために少なくとも 1 つの DLC を所有する必要があります。- プレイヤー DLC ルール
- ルール タイプ: MUST
- データ型: Collection
- セット操作: 積集合
- ターゲット共通部分: 1
次の表では、コレクション値は DLC の所有を示します。DLC がプレイヤーに対して利用可能な場合、値は 1 に設定されます。そうでない場合、0 に設定されます。 |
この例でターゲット共通部分が 2 に設定されている場合、プレイヤー 1 とプレイヤー 3 の間の共通部分は 1 のみのため、マッチしません。
例 3 (以前のプレイヤーを回避)
タイトルは、直前にプレイしたプレイヤーとのゲームを回避することを優先します。- ルール タイプ: MUST
- データ型: Collection
- セット操作: 差集合
- ターゲット共通部分: 0
SmartMatch 構成中のチーム ルールの定義
チーム ルールの構成
チーム ルールをセットアップするには、まず Partner Center で作成することから始めます。 このホッパーでマッチされたチケットから作成されることをゲームが想定するチーム サイズを入力します。 たとえば、4 対 4 を想定するゲームの場合、それぞれ最大サイズが 4 で異なる名前を持つ 2 つのエントリを作成する必要があります。 最小チーム サイズもあります。少ないプレイヤーでゲームをプレイできる場合はこれを使用します。 そうでない場合、最小と最大は同じ値である必要があります。チーム ルールの使用
チーム ルールが構成された後、ホッパー内のチケットは、グループを分割せずにチームに収める方法がない場合、マッチングされないようになります。 ルールは結果としてのチーム割り当てをターゲット セッションの members/constants/custom/matchmakingresult/initialTeam の下に書き込みます。これは単に提案された割り当てです。タイトルは、プレイヤーを並べ替えることによって、チケットを異なるチームに分割することを防ぎながら、より優れたゲームを作成できることに気付く場合があります。
PreserveSession フィールドが always に設定されたチケットによって表されます。
このような場合、チームは既にプレイヤーに割り当てられているため、Match が各チームに何人分のスペースが空いているかを認識できるように、タイトルは現在のチーム割り当てを指定する必要があります。
各プレイヤーが所属するチームの名前を提供するために、各プレイヤーはゲーム セッションの members/me/properties/system/groups の下に自身のチーム名を書き込みます。
このフィールドは JArray です。
前述のプロパティがゲーム セッションに書き込まれた後、1 人のプレイヤーがさらにプレイヤーを見つけようとしてセッションのチケットを作成します。
チケットが履行されると、Match は再び、参加するプレイヤーの提案されたチームを members/constants/custom/matchmakingresult/initialTeam に書き込みます。
均等なチームの優先
さらに、マッチは、最も大きなチームから最初に作成されます。 つまり、仮想的な 4 対 4 のホッパーでは、4 人のプレイヤーのチケットが最初に一緒にマッチされ、4 人のチケットが残らなくなるまで続きます。 その後、3 人のチケットが続き、必要に応じてシングルトンを引き込み、以下同様に続きます。 この方法では、他のルールで妨げられていない限り、同じようなサイズのチケットは通常、互いに対戦することになります。これにより、チーム ルールは他のルールよりもかなり強い優先順位を持ちます。