次の方法で共有

サーバー バックフィル チケットを使用する

  • [アーティクル]

サーバーでホストされているゲームは、他のプレイヤーの検索を必要とする場合があります。 ほとんどの場合、ゲームの進行中に 1 人または複数のプレイヤーが切断されたときにプレイヤーの検索が発生します。 サーバー バックフィル チケットを使用すると、ゲームサーバーは、現在プレイされているゲームに適合する追加のプレイヤーを検索できます。

サーバー バックフィル チケットは、通常のマッチメイキング チケットとさまざまな点で異なります。

  1. マッチング
    • バックフィル チケットは、互いに一致させることができません。
    • バックフィル チケットには、検索中に優先順位が与えられます。 これにより、プレイヤー ベースの断片化が減少します。
  2. コントラクト
    • バックフィル チケットは、ServerDetails フィールドを使用して作成できます。 これにより、サーバーは、マッチしたプレイヤーがどのように接続するかを表示できます。
    • バックフィル チケットは、チーム アサインメントを使用して作成できます。 これにより、ゲーム チームはチームの情報を保持できるようになります。
  3. キュー プロパティ
  4. 所有権
    • バックフィル チケットは、ユーザーではなく、ゲーム サーバーによって所有されます。 ユーザーは、どのような方法でもバックフィル チケットを表示したり操作したりすることはできません。

サーバー バックフィル チケットを作成する

バックフィル プロセスは、通常のマッチメイキング チケットの作成と同様に開始されますが、CreateServerBackfillTicket の呼び出しが、CreateServerMatchmakingTicket の呼び出しに代わって使用されます。 ゲーム サーバーは、現在ホストしているゲームのすべてのメンバー情報を提供する必要があります。 これは、前回のマッチング結果で返された属性を格納することによって最も効率的に行われます。 GetMatch を ReturnMemberAttributes フラグを使用して、これらの属性を取得することができます。 または、ゲーム サーバーがユーザーに属性情報を照会することもあります。

メンバーに加えて、ゲーム サーバーでは 2 つの追加情報を指定できます。

ServerDetails

この構造体は、GetMatch 呼び出しで返される構造と同じであり、サーバーが接続に必要な情報を指定するのを可能にします。 バックフィル チケットが一致すると、ServerDetails 構造体は、結果の一致で GetMatch を呼び出すプレイヤーに返されます。 この構造のすべてのフィールドはオプションです。 タイトルでは、クライアントがゲームサーバーに接続するために十分な情報を提供するために、これらのサブセットのみが必要になる場合があります。

注意

この IPV4Address フィールドは検証されず、クライアントに任意の接続文字列情報を提供するために使用される場合があります。

{
  "ServerDetails": {
    "IPV4Address": "123.234.123.234",
    "Ports": [
      {
        "Port": {
          "Name": "portname",
          "Num": 12345,
          "Protocol": "UDP"
        }
      }
    ],
    "Region": "EastUS"
  }
}

チーム割り当て

バックフィル チケットがチームのキューに送信される場合、各メンバーには、現在参加しているチームを示す、TeamId が指定されていることがあります。 このメンバーシップは、マッチが返されたときに保持されます。 ユーザーに対して TeamId が指定されていない場合、その ID は任意のチームに配置される可能性があります。

{
  "Members": [
    {
      "TeamId": "red",
      "Entity": {
        "Id": "6570DE3537DC9DF6",
        "Type": "title_player_account",
        "TypeString": "title_player_account"
      },
      "Attributes": {
        "DataObject": {
          "Skill": 25
        }
      }
    }
  ]
}

バックフィル チケットとのやりとり

作成された後、バックフィル チケットは、規則の条件を満たす通常のマッチメイキング チケットの検索を開始します。 バックフィル チケットのフローは、通常のマッチメイキング チケットの動作と同じですが、このような場合は、独自の規則を使用する API を除きます。 ゲーム サーバーは、GetServerBackfillTicket を呼び出すことによって、チケットの状態を確認する場合があります。 また、CancelServerBackfillTicket を呼び出すことで、チケットをキャンセルすることもできます。

注意

クライアントは、その中にあるバックフィル チケットを取り消すことができません。 クライアントが 4v4 マッチ中で、敵チームのプレイヤーが脱落したとします。 クライアントは、自分が入っていたバックフィル チケットを継続的にキャンセルすることによって、その利点を維持できます。 これを防ぐために、ゲーム サーバーのみがバックフィル チケットをキャンセルする可能性があります。

メンバーシップの制限と失われたバックフィル チケットの回復

通常のマッチメイキング チケットと似ていますが、ユーザーはいつでもキューごとに 1 つのバックフィル チケットしか存在できません。 この制限は、クライアントが制御する正規のチケットとは別に追跡されます。

ゲームサーバーがバックフィル チケットを作成し、クラッシュした場合、メンバーシップの制限により、失われたバックフィル チケット内のすべてのユーザーは別のバックフィル チケットに送信できません。 ゲーム サーバーは、エラー MatchmakingTicketMembershipLimitExceeded を受け取り、errorDetails 本文に未処理のバックフィル チケットがあることを示すユーザーの一覧を表示することで、これを検出します。

{
    "code": 400,
    "status": "BadRequest",
    "error": "MatchmakingTicketMembershipLimitExceeded",
    "errorCode": 2055,
    "errorMessage": "User is a member of too many backfill tickets.",
    "errorDetails": {
        "UsersExceedingMembershipLimit": [
            "title_player_account!562D72A5B184F612"
        ]
    }
}

ゲームサーバーは、CancelAllServerBackfillTicketsForPlayer を呼び出すことによって、この状況からユーザーを回復することができます。これにより、ユーザーが持っているすべてのバックフィル チケットが削除されます。 ListServerBackfillTicketsForPlayer は、プレイヤーがどのバックフィル チケットを使用できるかを検出するためのメソッドとしても提供されます。

領域選択ルールとのやりとり

通常、地域の選択ルールでは、チケットが属性の待機時間の値の配列を指定する必要があります。 ただし、バックフィル チケットは、特定のデータ センターで既に進行中のゲームを表します。 待機時間の測定値の代わりに、作成要求で ServerDetails 構造体に地域を指定する必要があります。 チケットがバックフィル チケットと一致するためには、バックフィル チケットによって指定された領域に対して受け入れ可能な ping 時間が必要です。

チームチケット サイズの類似ルールによる操作

チームチケット サイズの類似ルールは、大規模なプレイヤー グループが他の大規模なプレイヤー グループとのマッチを強制します。 ただし、バックフィル チケットには、グループとしてゲームに参加したプレイヤーの情報は含まれません。 そのため、バックフィル チケットを照合する場合、チケット サイズの類似ルールは無視されます。