マッチメイキングキューの構成

概要

キューの周りの構成センターと一致します。これは、チケットが相互に対応する場所を表します。 各キューには、一致に必要なものについての一般的な構成がいくつか含まれています。 さらに、チケットの照合方法についてさらに制限を与える一連のルールが含まれている場合もあります。

キューの構成

キューレベルでは、チケットをキュー内でどのように照合するか、キューに関する統計情報を取得する方法についての基本的な要件も構成で示されます。

キュー名

特定のキューの名前。 長さは 1 ~ 64 文字で、大文字と小文字が区別されます。 英数字に加えて、アンダースコアとハイフンで始まり、文字または数字で始まります。 通常、キュー名は、"4v4CaptureTheFlag" や "UnrankedRace" などのゲームをプレイするための手段を表します。 マッチメイキングチケットを作成するときに、キュー名を指定して、どのキューを入力するべきかを特定する必要があります。

対戦人数

対戦で許可されているプレイヤーの範囲。 最小一致サイズは2以上でなければなりません。また、最大一致サイズは100以上でなければなりません (teams を使用している場合は、この制限は32になります)。

さらに、対戦の最小要件を満たしている場合でも、1つ以上の他のチケットと一致するように、一致が返されることはありません。 ただし、チケットが一致の最大要件を満たしている場合は、拒否されます。

プレイヤーが利用できる統計

これにより、 GETQUEUESTATISTICS APIを通じてプレイヤーに公開されるキューの統計情報が決まります。 サーバーは常にすべての統計情報にアクセスできます。 詳細については、「タイトルのチュートリアルでキューの統計情報を表示する」を参照してください。

ここでは、次の2つのオプションを制御できます。

  1. 対戦相手の数を表示する-対戦相手の人数がプレイヤーに対して公開されているかどうかを示します。 タイトルは、この方法を使用して、モードの相対的な人気を非表示にしたり、ビジネス上の理由でプレイヤーのカウントを非表示にしたりすることができます。
  2. 統計情報と一致する時刻を表示します。一致する統計情報 (average と百分位) がプレイヤーに公開されているかどうかを示します。

Teams

キューにはチームの構成を含めることができます。これにより、対戦サービスが teams にプレイヤーを割り当てることができます。 他のチーム固有のルールを使用して、チームの割り当て方法を制御することができます。 さらに、対戦サービスを利用すると、同じチケットで一緒に対戦しているプレイヤーが、異なるチームに割り当てられることはありません。

キューには2つ以上のチームを定義できます。

  • [チーム名-このチームで使用する名前です。 チーム名は、長さが 1 ~ 64 文字で、大文字と小文字が区別されます。 英数字は英数字で、アンダースコアとハイフンは英数字で始まり、文字または数字で開始されます。 また、キュー内で一意である必要があります。
  • チームのサイズ-チームに参加できるプレイヤーの最小数と最大数。 マッチメイキングは、できるだけ多くのプレイヤーとチームを形成しようとします。

チームとそのサイズを定義するだけでなく、マッチメイキングで teams を処理する方法に役立つ追加ルールを有効にすることができます。 チーム固有のルールの詳細については、以下を参照してください。

ルールの構成

ルールは、キューに対して必要に応じて定義することができます。 構成すると、マッチメイキングアルゴリズムによって、どのチケットを組み合わせるべきかを判断するのに役立ちます。 各ルールは、プレーヤーメタデータの1つの属性に適用されます。 1つのキューに対して最大20個のルールを定義できます。

ルールにはさまざまな種類があります。 各要素には、特定の種類のルールに固有の要素と共に、いくつかの一般的な構成要素が含まれています。 さらに、ルールの多くでは、時間の経過によってルールが制限されることがなくなります。

一般的なルール要素

以下の要素は、多くの場合、すべてのルールで使われます。

  • ルール名-名前は、1 ~ 255 文字の範囲内で指定する必要があります。長さは英数字 + アンダースコアとハイフンで、先頭は英字または数字にする必要があります。 ルール名は、キュー内で一意である必要があります。

  • 重み-ルールの重要性を変更する方法。 一般的なルールには、制限と、対象となる残りのチケットを並べ替える手段が用意されています。 ウエイトは、並べ替えのためのルールの重要性を変更する乗数です。

  • 属性ソース-ルールは、提供されている情報に基づいて処理されることがよくあります。 このフィールドでは、この情報のソースの2つのオプションについて説明します。

    1. ユーザー属性は、create または join チケット要求で選手と共に送信されます。
    2. Player エンティティ-属性は、プレーヤーに関連付けられているプレーヤーエンティティから取得されます。 これらは、 SETOBJECTS APIを使って設定できます。
  • 属性パス-属性に到達するためのパス。 ユーザー属性ソースを使う場合は、単に属性の名前です。 Player エンティティ属性ソースを使う場合は、などのエンティティから特定の項目を取得するJsonpathです$.playerSkill.Mean

  • 属性が指定されていない場合の動作-ルールに属性が必要ですが、指定されていない場合、ルールは次の2つの動作のいずれかで構成されている可能性があります。

    1. 属性の既定値を指定する場合があります。
    2. このシグナルは、チケットがルールによって指定された制限を満たしていることを示すシグナルとして使用されることがあります。 これは、たとえば一部のプレーヤーが好みを表現していて、別のプレーヤーがすべての人と一致することを望む場合に便利です。 優先度が設定されていないプレイヤーは、属性を指定して他のプレイヤーと一致させることができます。

標準ルールの種類

各ルールの種類は、その目的、一般的な使用、ルールに必要な特定の構成など、次の一覧に示しています。

規則の種類 説明 一般的な用途 ルール固有のフィールド
文字列の等価性 一致するすべてのチケットで文字列属性が同じであることを確認します。 一致するビルドバージョンまたは他の特定の項目が必要です none
異なる部分 一致する2つのチケットの間で、数値属性の絶対差が構成された最大差よりも小さくなるようにします。 スキル、経験、その他の数値比較によってプレイヤーをグループ化する Merge 関数-複数のプレーヤーの値を、チケットを表す1つの値に結合する方法を選択します。 選択肢は、最小値、最大値、平均値です。 既定値は average です。
交点を設定する 指定した属性が文字列のリストであるかを確認します。一致するすべてのチケットは、少なくとも、構成されている多くの値を共有します。 DLC または地図の選択 最小交差サイズ-一致する共有アイテムの最小数。
合計の照合 一致するすべてのプレイヤーにわたる数値属性の合計が、構成された範囲内にあることを確認します。 役割の選択、ホスト/サーバーマッチのエミュレート、時間の経過に伴うプレーヤーのカウント制限の調整 最小/最大合計-属性の合計は、この包括的な範囲内にある必要があります。
地域の選択 一致するすべてのユーザーの共通データセンターへの遅延が、構成されている最大値よりも小さくなるようにします。 マルチプレーヤーサーバーの統合に必要 この最大待ち時間内の最大待ち時間のみのデータセンターは、一致の対象になります。

チームルールの種類

チームルールを設定できるのは、[チームがキューの構成に含まれている場合のみです。 チーム間のバランスを要求するその他の方法を提供します。 次のチームルールを使用できます。

規則の種類 説明 一般的な用途 ルール固有のフィールド
チームの相違点 一致に含まれるチームが、特定の属性 (スキルなど) に対して構成された相違内にあることを確認します。 これは、標準の相違点と非常に似ていますが、値の比較は各チームの合計値である点が異なります。 チーム間でのバランスの調整 none
チームのサイズの残高 最大と最小のチーム間でのプレイヤーの数の差がしきい値を超えていないことを確認します。 たとえば、このルールを使って、3v3 と4v4 の一致が許可されるキューを作成することもできますが、3v3 は使用できません。 チーム間でのプレイヤーの数の残高 許可されているチームサイズの違いは、各チームに割り当てられているプレイヤーの数の差で測定される、チームの不均等なものです。
チームチケットサイズの類似性 すべてのチームが、大規模なパーティーを所有しているか、または大人数を持っていないことを確認します。 大規模なパーティは、最大チームのサイズの少なくとも半分として定義されます。 パーティ (事前にチーム) が solo プレイヤーのグループと一致しないようにします。 none

拡張され、オプションになります

ルールは時間の経過に応じてオプションで制限される可能性があります。そのため、一定の時間待機したチケットを検索すると、一致する可能性が高くなります。 この動作を制御するには、次の2つの方法があります。

  1. (省略可能) までの秒数-ルールがアクティブになっている時間の長さを示します。 この時間が経過したチケット間の一致は、ルールによって制限されなくなりました。

  2. 展開プロセス-ルールは、時間の経過によって構成されたしきい値を段階的に調整します。 たとえば、差ルールによっては、特定の最大差で一致する必要があります。 チケットが待機すると、ルールによって、最大の違いが拡張され、チケットの範囲が大きく、大きくなり、完全な対戦相手が利用できない場合でも、このルールが一致するようになります。

拡張は、直線的またはカスタムのいずれかになります。 直線的な展開では、時間の経過に伴って値が長くなり、一定の間隔で固定された変更が使用されます。 線形展開でカスタマイズされた項目は次のとおりです。

  • 展開の間隔 (秒): ルールの各インスタンス間の制限を変更する時間です。
  • 差分: 値の変化。
  • Endの値を指定します。 ルールは、この時点を超えて展開されることはありません。

カスタム展開では、ルールによって制限が変更されるたびに、任意の値を使うことができます。 次のフィールドが使用されます。

  • 展開の間隔 (秒): ルールの各インスタンス間の制限を変更する時間
  • 展開中にルールを変更する1 つ以上のユーザー設定フィールド。 各フィールドは、各展開の間隔で使用される別の値を表すためにセミコロンで区切られています。 この期間中にルールがアクティブではないことを示すために、値の代わりに "null" という単語を使うことができます。

変更された正確なフィールドは、ルールによって異なります。 次の表では、展開の種類と、展開によって変更されるフィールドについて説明します。

規則の種類 直線的な展開が許可されていますか? カスタム展開が許可されていますか? 拡張中に変更された属性
文字列の等価性 いいえ ルールがアクティブであるかどうか
異なる部分 使用できる差分の最大値
交点を設定する 最低限必要な共通部分
合計の照合 いいえ 必要な最小および最大合計
地域の選択 許可される待ち時間の上限
チームの相違点 チーム値での許可された相違点
チームのサイズの残高 チームあたりのプレイヤー数に対して許可されている差
チームチケットサイズの類似性 いいえ いいえ 該当なし

構成の使用例と例の詳細については、「マッチメイキングシナリオと構成例」を参照してください。