バックフィルチケットのライフサイクルを理解する

Last updated on February 4, 2026

注釈：本資料はAI技術を用いて翻訳されています。

概要

この記事では、バックフィルチケットのライフサイクルの概要を説明します。これは、マッチメイキングによってマッチが形成された後のセッションのデフォルトのエンドツーエンドフローを概説しています。ただし、ゲームのニーズに合わせてこのフローのいくつかの段階をカスタマイズすることが可能です。詳細については、Extendセクションを参照してください。

マッチメイキングは、各マッチプールのマッチングロジックを並列で実行するためにワーカーを使用し、キュー処理の中断を防ぐのに役立ちます。バックフィルプロセスは、利用可能なセッションがプレイヤーのリクエストを満たさない場合、新しいマッチを形成する前に既存のマッチが最適に埋められるように、新しいマッチ作成よりも優先されます。

バックフィルチケットは、空席を埋めるプレイヤーを見つけるためのAGSマッチメイキングへのリクエストを表します。これらのチケットは、専用サーバー（DS）またはP2Pホストによって手動で作成することも、マッチメイキングによって自動的に作成することもできます。

次の状況では、バックフィルは開始されません：

セッションが満員の場合。満員とは、ルールセットで設定された変数player_max_number（権威）であり、セッションで設定されたもの（例：パッチ操作でゲーム中に更新）ではありません。
セッションの参加可能性がCLOSEDの場合、セッションメンバーの構成を変更できません。

バックフィル中に注意すべきいくつかの点があります：

自動バックフィル：マッチが形成された直後にマッチメイキングがバックフィルチケットを自動的に作成するかどうかを決定します。手動作成の場合、バックフィルリクエストを送信するかどうかは、専用サーバー（DS）またはP2Pホストが決定します。
バックフィルチケット：バックフィルのリクエストを表します。バックフィルチケットは、セッションが満員になるか、チケットが期限切れになると、キューから削除されます。セッションが満員になると、対応するバックフィルチケットがキューから削除されるため、セッションテンプレートで最大プレイヤー数の値を適切に設定してください。サーバーは、空きスロットが利用可能になったときに新しいバックフィルチケットを作成できます。自動バックフィルがオンの場合でも、満員のセッションからプレイヤーが退出しても、自動バックフィルチケットの作成はトリガーされません。
バックフィル提案：サーバーが承認または拒否できる提案として、更新されたチーム構成が含まれます。バックフィル提案には、複数の追加されたマッチメイキングチケットが含まれる場合があり、DSはそれらを部分的に承認できます。バックフィル提案には有効期限があり、管理ポータルから設定できます。提案が承認、拒否、または期限切れになるまで、マッチメイキングは提案されたプレイヤーのチケットを他の誰ともマッチングしません。
バックフィル提案の自動承認：サーバーが進行中のゲームに参加するプレイヤーを承認するかどうかを制御したい場合は、マッチプールでバックフィル提案の自動承認設定を有効にする必要があります。
- 部分的なバックフィル承認：バックフィル提案には、複数の追加されたマッチメイキングチケットが含まれる場合があり、DSはそれらを部分的に承認できます。提案に複数の追加されたマッチメイキングチケットが含まれている場合、DSはそのうちのいくつかのみを承認し、他を拒否することを選択できます。これにより、DSはサーバーへの参加を許可する人を制御する柔軟性が得られます。これは、バックフィル提案の自動承認が有効になっている場合にのみ利用可能であることに注意してください

バックフィルチケットのライフサイクル

以下の図は、バックフィルチケットが作成され（手動および自動）、マッチメイキングによって処理され、バックフィルキューから削除されるライフサイクルを示しています。バックフィルチケットをキューから削除する方法は2つあります：

バックフィルチケットの有効期限切れ、または
バックフィルの停止リクエスト。これは、バックフィルチケットの削除または承認/拒否バックフィル提案中にトリガーできます。

Diagram of backfill ticket lifecycle

新しいマッチが形成されると、マッチメイキングはセッションを作成し、必要に応じて設定されている場合はチケットをバックフィルします。マッチメイキングは、セッションを作成する際に、地域、クライアントバージョン、その他の属性などのプレイヤー情報を渡します。デフォルトでは、マッチメイキングプロセスはこの時点で終了します。ただし、マッチルールセットでauto_backfillが有効になっている場合、マッチメイキングはバックフィルチケットを作成し、バックフィルキューに追加し、バックフィルチケットIDでセッションを更新します。
DSまたはP2Pリーダーがマッチメイキングにバックフィルチケットを送信します DSまたはP2Pホスト/リーダーは、セッションに空席があるかどうかを判断し、より多くのプレイヤーを追加したいと考えています。彼らは、埋めるためのsessionIDを含むバックフィルチケットをマッチメイキングに送信できます。
バックフィルチケットは、関連するマッチルールセットで定義されたプレイヤー属性でハイドレートされます。各マッチプールには、プール内から適切なマッチを見つけるためにマッチ関数が使用すべきプレイヤー属性と基準を定義する関連マッチルールセットがあります。バックフィルのリクエストを受信すると、マッチメイキングは、セッション属性、地域、アクティブプレイヤー、クロスプラットフォーム属性でチケットをハイドレートします。
バックフィルチケットは、マッチプール内のプレイヤーチケットと評価され、有効なマッチを見つけます。バックフィルチケットがセッション属性でハイドレートされた後、マッチメイキングサービスは、有効なマッチを見つけるために、マッチプール内のチケットを評価するために関連するマッチ関数を呼び出します。処理中にマッチが見つからない場合、バックフィルチケットは再度評価されるためにキューに戻されます。デフォルトでは、AGSマッチメイキングは、マッチを見つけるロジックとして関連するルールセットで指定された基準を使用します。ただし、必要に応じて、より複雑なロジックで拡張できます。詳細については、Extendを参照してください。
マッチメイキングは新しいチーム構成を見つけ、必要に応じてサーバーに提案します。

マッチメイキングがセッションとプレイヤーの両方の基準を満たす新しいチーム構成を見つけた後、サービスは提案を形成します。
- バックフィル提案の自動承認が無効になっている場合、サービスはDSHubを介してサーバーに提案を送信します。この場合、サーバーはP2Pホストまたは専用サーバー（DS）のいずれかです。

{
    "Payload": {
        "BackfillTicketID": "{backfill ticket ID}",
        "CreatedAt": "{backfill ticket creation time}",
        "AddedTickets": [
            {
              "Namespace": "{namespace}",
              "PartySessionID": "{party ID-1}",
              "TicketID": "{ticket ID-1}",
              "MatchPool": "{match pool}",
              "CreatedAt": "{proposal creation time}",
                "Players": [
                    {
                        "PlayerID": "{user ID A}",
                        "PartyID": "",
                        "PlatformID": "",
                        "Attributes": {}
                    }
                ],
                "TicketAttributes": {
                    "client_version": "0.8.1",
                    "{User ID A}": {
                        // attributes
                    },
                    "TicketInformation": "",
                    "Latencies": {
                        "ap-northeast-2": 228,
                        "ap-southeast-1": 160,
                        "ap-southeast-2": 283,
                        "eu-central-1": 26,
                        "sa-east-1": 203,
                        "us-east-2": 100,
                        "us-west-2": 152
                    },
                    "ExcludedSessions": ""
                }
            }
        ],
        "ProposedTeams": [
            {
              "TeamID": "{proposed team ID}",
              "UserIDs": [
                // existing list of users
              ],
              "Parties": [{
                "partyID": "party-ID",
                "userIDs": []
              },
              {
                "partyID": "party-ID",
                "userIDs": []
              },
              {
                "partyID": "party-ID",
                "userIDs": []
              }
             ]
          }
        ],
        "ProposalID": "{proposal ID}",
    "MatchPool": "{match pool}",
    "MatchSessionID": "{game session ID}",
    "Attribute": ""
    }
}

サーバーが迅速に応答することが重要です。マッチメイキングは、バックフィル提案が期限切れになるまで、進行中のゲームに参加するプレイヤーとセッションを含む提案を保持するためです。サーバーが提案を拒否した場合、バックフィルチケットとプレイヤーチケットは再評価のためにキューに戻されます。

進行中のゲームに参加するプレイヤーは、マッチ結果とゲームセッションへの招待を受け取ります。新しいチーム構成を含む提案が承認されると、マッチメイキングはセッションを更新して、セッションサービスがそのセッション内の現在のアクティブプレイヤーにメンバーの変更を通知し、進行中のゲームに参加するプレイヤーを招待できるようにします。
バックフィルチケットが期限切れになるか、セッションが最大容量に達すると、チケットはバックフィルキューから削除されます。オープンセッションでは、プレイヤーが出入りする可能性があり、マッチメイキングにバックフィルチケットをキューに入れるタイミングを知ることがサーバーの責任になります。

概要​

バックフィルチケットのライフサイクル​

概要

バックフィルチケットのライフサイクル