Skip to main content
Multiplayer SDK の使用を強く推奨します。リアルタイム メッセージのサポートが含まれており、ポーリングの必要性が低減され、マッチメイキング体験が改善し、遅延が減少します。サーバー バックフィル チケットの使用 - Multiplayer SDK
サーバー上でホストされているゲームでは、追加のプレイヤーを探す必要が生じることがあります。多くの場合、これはゲームが進行中に 1 人以上のプレイヤーが切断したときに起こります。サーバー バックフィル チケットにより、ゲーム サーバーは現在プレイ中のゲームに適合する追加のプレイヤーを検索できます。 サーバー バックフィル チケットは、通常のマッチメイキング チケットとは以下の点で異なります。
  1. マッチング
    • バックフィル チケットは互いにマッチできません。
    • バックフィル チケットは検索時に優先されます。これにより、プレイヤーベースの断片化が軽減されます。
  2. コントラクト
    • バックフィル チケットは ServerDetails フィールド付きで作成できます。これによりサーバーは、マッチしたプレイヤーがどのように接続すべきかを示すことができます。
    • バックフィル チケットはチーム割り当てを伴って作成できます。これによりチームのあるゲームでは、チーム情報を維持できます。
  3. キューのプロパティ
    • バックフィル チケットは Multiplayer Server の割り当て をトリガーしません。
    • バックフィル チケットは キュー統計 には反映されません。これは、それらのプレイヤーは既にゲームをプレイ中であり、待ち時間を不正確に偏らせるためです。
  4. 所有権
    • バックフィル チケットはユーザーではなく、ゲーム サーバーが所有します。ユーザーはバックフィル チケットを表示したり操作したりすることはできません。

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

バックフィル プロセスの開始は通常のマッチメイキング チケットの作成と類似していますが、CreateServerMatchmakingTicket 呼び出しの代わりに CreateServerBackfillTicket 呼び出しを使う点が異なります。ゲーム サーバーは、現在ホスト中のゲームのすべてのメンバー情報を提供する必要があります。これは、前回のマッチ結果で返された属性を保存することで最も効率的に実行できます。これらの属性は、ReturnMemberAttributes フラグを付けて GetMatch を呼び出すことで取得できます。あるいは、ゲーム サーバーはユーザーに属性情報を問い合わせることもできます。 メンバーに加えて、ゲーム サーバーは 2 つの追加情報を指定できます。

ServerDetails

この構造体は、GetMatch 呼び出しで返される構造体と同一で、サーバーへの接続に必要な任意の情報を指定できます。バックフィル チケットがマッチされると、その ServerDetails 構造体は、生成されたマッチに対して GetMatch を呼び出したすべてのプレイヤーに返されます。この構造体のすべてのフィールドは任意です。タイトルは、クライアントがゲーム サーバーに接続するのに十分な情報を提供するために、これらの一部しか必要としない場合があります。
IPV4Address フィールドは検証されず、クライアントに任意の接続文字列情報を提供するために使用できます。

チーム割り当て

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

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

作成されると、バックフィル チケットはルール条件を満たす通常のマッチメイキング チケットの検索を開始します。バックフィル チケットのフローは、対応する API を使用する点を除いて、通常のマッチメイキング チケットの動作と同じです。ゲーム サーバーは、GetServerBackfillTicket を呼び出してチケットのステータスを確認できます。また、CancelServerBackfillTicket を呼び出してチケットをキャンセルすることもできます。
クライアントは自分が含まれているバックフィル チケットをキャンセルすることはできません。たとえば、あるクライアントが 4 対 4 のマッチに参加していて、対戦相手チームのプレイヤーが離脱した場合を考えます。そのクライアントが自分の含まれるバックフィル チケットを継続的にキャンセルすることで、優位性を維持できてしまいます。これを防ぐため、バックフィル チケットをキャンセルできるのはゲーム サーバーのみです。

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

通常のマッチメイキング チケットと同様に、ユーザーはキューあたり同時に 1 つのバックフィル チケットにしか参加できません。この上限は、クライアントが制御する通常のチケットとは別に追跡されます。 ゲーム サーバーがバックフィル チケットを作成した後にクラッシュした場合、失われたバックフィル チケット内のユーザーは、メンバーシップ制限のため、別のバックフィル チケットに登録できなくなります。ゲーム サーバーは、errorDetails 本体に未処理のバックフィル チケットに含まれるユーザーのリストとともにエラー MatchmakingTicketMembershipLimitExceeded を受信することで、この状況を検出します。
ゲーム サーバーは、CancelAllServerBackfillTicketsForPlayer を呼び出してユーザーが所属するすべてのバックフィル チケットを削除することで、この状況からユーザーを回復できます。プレイヤーが参加している可能性のあるバックフィル チケットを検出する方法として、ListServerBackfillTicketsForPlayer も提供されています。

Region Selection Rule との相互作用

Region Selection ルールは通常、チケットに属性としてレイテンシ計測値の配列を指定するよう要求します。ただし、バックフィル チケットは特定のデータセンターで既に進行中のゲームを表します。レイテンシ計測の配列の代わりに、作成される要求では ServerDetails 構造体で Region を指定する必要があります。チケットがバックフィル チケットとマッチするには、バックフィル チケットで指定されたリージョンに対して許容できる ping 時間を持っている必要があります。

Team Ticket Size Similarity Rule との相互作用

Team Ticket Size Similarity ルールは、大きなグループのプレイヤーを他の大きなグループのプレイヤーとマッチさせることを保証します。ただし、バックフィル チケットには、どのプレイヤーがグループとしてゲームに参加したかの情報は含まれていません。したがって、バックフィル チケットのマッチング時には、Ticket Size Similarity ルールは無視されます。
最終更新日 2026年8月13日