Skip to main content
このトピックを使用して、マルチプレイヤー セッションにおける高度な概念について学習します。 このトピックでは以下について説明します。

セッションの概要

Multiplayer Session Directory (MPSD) 内のセッションには、セッション名があり、セッション テンプレートのインスタンスとして識別されます。 セッション テンプレートは、セッションの既定設定を提供する JSON ドキュメントです。 セッション テンプレートは、GUID であるサービス構成識別子 (SCID) を持つサービス構成の一部です。 セッション テンプレートは Partner Center にあります。 サービス構成は、取り込み、管理、およびセキュリティ ポリシーに使用される開発者向けリソースです。 セッションが MPSD 経由でアクセスされる場合、Partner Center を通じて開発者が設定したアクセス ポリシーに従い、サービス構成に対して主体認証が実行されます。 セッション メンバーシップ検証などの二次的なアクセス チェックは、サービス構成へのアクセスが承認された後にセッションが読み込まれるときに、セッション レベルで実行されます。
テンプレートを通じて設定された機能は、MPSD への書き込みで変更することはできません。値を変更するには、必要な変更を含む新しいテンプレートを作成して送信する必要があります。テンプレートを通じて設定されていない項目は、MPSD への書き込みを通じて変更できます。

コントラクト バージョン番号

このトピックは、テンプレートが XBOX One (以降) の現在の MPSD で使用されているバージョンであるコントラクト バージョン 107 を使用していることを前提としています。

セッション参照

各 MPSD セッションは、マルチプレイヤー API で XblMultiplayerSessionReference 構造体によって表されるセッション参照によって一意に参照されます。 セッション参照には、以下の文字列値が含まれます。
  • サービス構成識別子 (SCID)
  • セッション テンプレート名
  • セッション名
セッション参照は、以下に示すように、セッションを識別するための URI にマップされます。 以下のマッピング例では、authority は sessiondirectory.xboxlive.com です。

セッションの要素

各セッションには、可変性とセキュリティ ルールを適用する要素のグループが含まれます。これらはセッション要素ごとに異なり、読み取り専用のハウスキーピング情報 (メタデータ) と共に存在します。 このセクションでは、セッションを構成する JSON ファイルおよび選択したテンプレートの JSON ファイルに含まれるセッション要素のグループについて説明します。
HTTP/REST 実装用にカスタム ラッパーを使用している場合、セッションとテンプレートは、実装の機能を正確に反映する JSON オブジェクトを定義する必要があります。
各要素グループ内には、2 つの内部オブジェクトがあります。
  • システム オブジェクト: これらのオブジェクトは、MPSD によって適用および解釈される固定スキーマを持ちます。これらは検証されマージされます。MPSD が意味を定義し理解しているため、これらに対して動作できます。各システム オブジェクトの完全な定義については、XblMultiplayerSession プレフィックスおよび Session Directory URI のリファレンスを参照してください。
  • カスタム オブジェクト: これらのオブジェクトは省略可能でスキーマを持ちません。マルチプレイヤー ゲームに関連するメタデータを保存するために使用されます。MPSD はこのデータを解釈できないため、それに対して動作しません。ゲーム データや保存された情報は、Title-Managed Storage (TMS) に保存する必要があります。TMS の詳細については、XBOX services Title Storage の概要 を参照してください。
以下はカスタム JSON オブジェクトの例です。

セッション定数

セッション定数は、作成時に作成者またはセッション テンプレートによってのみ設定されます。 /constants/system オブジェクトは、MPSD を通じて認識されるマルチプレイヤー システムの定数を定義するために使用されます。 このオブジェクトに関連付けられているラッパーは、XblMultiplayerSessionConstants 構造体で表されます。 /constants/system オブジェクトは、多数の項目を定義できます。これには、capabilities オブジェクト、metrics オブジェクト、managedInitialization (テンプレート コントラクト バージョン 104 または 105) または memberInitialization (コントラクト バージョン 107) オブジェクト、peerToPeerRequirements オブジェクト、peerToHostRequirements オブジェクト、および measurementsServerAddresses オブジェクトが含まれます。

セッション プロパティ

MPSD のセッション プロパティを定義するには、/properties/system オブジェクトを使用します。 このオブジェクトに関連付けられているラッパーは、XblMultiplayerSessionProperties 構造体です。 セッション プロパティは、セッション メンバーがいつでも書き込み可能です。 JSON 形式のセッション プロパティの例には、joinRestrictioninitializationSucceeded、および matchmaking オブジェクトがあります。 この要素グループの使用例については、ターゲット セッションの初期化と QoS を参照してください。

メンバー定数

セッション メンバーごとに参加時にメンバー定数を設定します。 JSON オブジェクトは /members/{index}/constants/system です。 セッション メンバーを表すラッパー クラスは、XblMultiplayerSessionMember 構造体です。 このトピックの先頭に戻る。

メンバー プロパティ

メンバー プロパティは、セッション メンバーのみが書き込み可能です。 これらは /members/{index}/properties/system オブジェクトに設定され、XblMultiplayerSessionMember 構造体の要素を反映します。 例を以下に示します。

サーバー要素

サーバーは、セッションに参加または招待された非ユーザーです。 関連する JSON オブジェクトは /servers/{server-name}/constants/system および /servers/{server-name}/properties/system です。 これらのオブジェクトは、サーバーのみが書き込み可能です。
/servers/{server-name}/constants/system オブジェクトは現在使用されていません。

セッション構成

以下の方法でセッションの構成を制御できます。
  • Partner Center を通じて取り込まれたセッション テンプレートを使用します。
  • マルチプレイヤーおよびマッチメイキング API または REST API への呼び出しを使用します。テンプレートは引き続き使用する必要がありますが、構成する値を含む必要はありません。ただし、タイトルは、テンプレートに既に設定されている定数を上書きできないことに注意してください。
セッション自体を定義するために、別の JSON ドキュメントが提供されます。 さらに、特定のタイトルに必要なラッパー機能を実装する必要があります。 JSON ドキュメントとラッパー コードの内容は、互いを正確に反映し、最新のテンプレート コントラクト バージョンを反映している必要があります。 セッションのスキーマは、セッション バージョン (メジャー バージョン) とプロトコル リビジョン (マイナー バージョン) でバージョン管理されます。 バージョンは、「100 * メジャー + マイナー」として X-Xbl-Contract-Version ヘッダーに結合されます。 たとえば、v1.7 タイトルは、最新のテンプレート コントラクト バージョン 107 を前提として、すべての REST リクエストに以下のヘッダーを含めます: X-Xbl-Contract-Version: 107。
ほとんどのタイトル (XBOX Services API (XSAPI) を使用) では、コントラクト バージョン 105 とセッション テンプレート バージョン 107 を使用することをお勧めします。

セッション テンプレート

各セッション テンプレートは JSON ドキュメントで、サービス構成の一部として、作成されるセッションのフレームワークを定義し、新しいセッションの定数を提供します。 詳細については、マルチプレイヤー セッション テンプレート を参照してください。 このトピックの先頭に戻る。

セッション機能

機能は、MPSD セッション内の定数で、MPSD がそのセッションに適用すべき動作を構成します。 セッション テンプレートで機能を設定するには、通常 Partner Center を使用します。 機能は /constants/system/capabilities オブジェクトに設定されます。 機能が不要な場合は、空の capabilities オブジェクトを使用します。
タイトルは、マルチプレイヤー API またはマッチメイキング API を使用してセッション機能を変更したりアクセスしたりすることはほとんどありません。
セッション機能は、XblMultiplayerSessionCapabilities 構造体で表されます。 これらは、セッションがサポートできる内容を示すブール値です。
  • 接続性
  • ゲームプレイ
  • 大規模サイズ
  • アクティブ メンバーの接続要件
XblMultiplayerSessionConstants 構造体には、セッション機能に関連する以下のプロパティを定義する SessionCapabilities メンバー (XblMultiplayerSessionCapabilities 型) が含まれます。
  • CapabilitiesConnectivity
  • CapabilitiesGameplay
  • CapabilitiesLarge
タイトルが動的セッション機能を定義する場合、対応するプロパティはセッション定数に対して true に設定されます。
このトピックの先頭に戻る。

セッション サイズ

MPSD セッションのサイズは、そのセッション内のメンバー数によって決定されます。

最大セッション サイズ

セッションの最大サイズは、収容できるセッション メンバーの最大数です。 これは XblMultiplayerSessionConstants::MaxMembersInSession プロパティで表されます。 最大メンバー サイズは /constants/system オブジェクトに設定します。 最大セッション サイズは 1 から 100 セッション メンバーの間で、作成時に設定されない場合は既定で 100 になります。 必要なサイズが 100 を超える場合、そのセッションは「大規模」セッションと呼ばれ、特別な方法で設定されます。

切断

セッションの最大サイズを設定すると、特定の切断シナリオで空きスロットが満員として表示される可能性があります。 たとえば、プレイヤーがネットワークまたは電源障害の結果として切断された場合、その遅延は即座にセッションに反映されません。 メンバーは切断検出機能を使用して非アクティブに設定されます。詳細については、Multiplayer Session Directory の概要トピック内の MPSD 変更通知処理と切断検出 セクションを参照してください。 比較として、切断を検出するためにハートビートを使用するピア メッシュは、2〜3 秒以内に切断を認識することが多く、プレイヤー スロットを即座に開放できます。 ただし、アービターは他のメンバーを削除できません。

大規模セッション

大規模 MPSD セッションは最大 1,000 メンバーを持てますが、すべてのメンバーのリストを取得するなど、一部のセッション機能が無効になっています。 セッションの大規模性は、XblMultiplayerSessionCapabilities::Large プロパティで表されます。 このプロパティは、大規模セッションを示すために true に設定されます。「large」機能は、/constants/system/capabilities オブジェクトに示されます。 詳細については、セッション機能 を参照してください。 このトピックの先頭に戻る。

セッション ユーザー状態

MPSD は、ユーザー状態をセッションに追加されたユーザーの状態として定義します。 可能なユーザー状態は XblMultiplayerSessionStatus 列挙型で定義されています。 ユーザーは、セッションに追加される前にも「available」状態にあると見なされます。 セッション ユーザー状態を変更するには、XblMultiplayerSessionCurrentUserSetStatus を使用できます。 REST の場合、ゲーム セッション JSON ドキュメント内の /members/{index}/properties/system を正しく設定してこの変更を行います。

Reserved ユーザー状態

アービターがセッション内の空きスロットの 1 つを埋めるためにユーザーを選択したとき、ユーザーは Reserved ユーザー状態に置かれます。 この状態では、ユーザーはまだ正式にはセッションへの招待を承諾したり、セッションに参加してピアとの接続を開始したりしていません。

Active ユーザー状態

ユーザーが Active 状態にある場合、タイトルはユーザーに代わってセッションに参加しており、ユーザーはセッションに積極的に参加しています。 ユーザーは、ゲームをプレイしている限り、この状態を維持します。 タイトルが最初に起動されたとき、通常はセッション状態をチェックすることにより、ユーザーが既に何らかのセッションのメンバーであるかどうかをチェックする必要があります。 ユーザーがセッション メンバーである場合、タイトルは直接ゲームに入り、参加しているローカル メンバーを Active ユーザー状態に設定できます。 ユーザーは、セッションでプレイしている間、Active 状態を維持する必要があります。 ユーザーがゲーム内 UI を使用してセッションを離脱する場合は、XblMultiplayerSessionLeave を呼び出してセッションから削除する必要があります。 ユーザーがタイトルが制約状態にある場合など、一時的にゲームから離れている場合、タイトルは適切な時間だけユーザーを Active 状態のままにする必要があります。 ユーザーがタイトル指定の期間内に戻らない場合、ユーザー状態を Inactive に変更するのが適切です。

Inactive ユーザー状態

Inactive 状態では、ユーザーは現在ゲームに関与していませんが、セッションに保存されたスロットを持っています。 つまり、ユーザーは「非アクティブ」です。 セッション内でユーザーを Inactive ユーザー状態に設定する責任はユーザー自身のコンソールにあります。 アービターはこれを行うことはできません。 ユーザーが Inactive 状態に置かれる例のシナリオには以下のようなものがあります。
  • タイトルが Suspending イベントを受信する。
  • ユーザーがタイトル定義の期間 (入力またはコントローラーの応答なし) の間、非アクティブであった。競技型マルチプレイヤー ゲームの場合、2 分を推奨します。
  • タイトルが 2 分を超える、またはタイトル定義の期間、制約モードにあった。この制約モードのタイムアウト期間は、ユーザーがタイトルに関連するアプリや他の体験を使用してタイトルから離れる可能性のある予想時間です。
  • ユーザーがセッションから正常に切断されなかった。詳細については、Multiplayer Session Directory の概要トピック内の MPSD 変更通知処理と切断検出 セクションを参照してください。
タイトルが起動し、特定のセッション メンバーのユーザー状態が Inactive に設定されている場合、タイトルが中断されたか、ユーザーがセッションに長時間非アクティブでいた可能性があります。 タイトルが再度起動しているため、これはユーザーが所属するゲーム セッションを続行したいという指示です。 タイトル起動時にユーザーの状態が Active である場合、この状況はおそらくネットワーク切断や、割り込みを受ける前にタイトルがユーザーを Inactive に設定できなかった別のシナリオが原因です。 これらのケースのいずれにおいても、タイトルはユーザーをゲームに再接続し、他のユーザーがプレイを続行できるようにするか、ユーザーをセッションから削除する必要があります。

セッション終了時のユーザー状態

セッションが終了すると、ゲームプレイは中止されます。 タイトルは、すべてのユーザーが XblMultiplayerSessionLeave を使用して自分自身を削除できるようにする必要があります。 ユーザーに関連付けられていたセッション アクティビティは、ユーザーがセッションを離れると自動的にクリアされます。 このトピックの先頭に戻る。

可視性と参加可能性

セッション アクセスは、セッションの可視性とセッションの参加可能性の 2 つの設定によって MPSD レベルで制御されます。 このトピックで行う可視性と参加可能性の推奨事項は、最も一般的なタイトル シナリオに適用されます。 タイトルは可能な限りこれらの設定に従うべきです。新しいプレイヤーがセッションに受け入れられるかどうかの最終的で権威ある決定を行うには、タイトル内ロジックを使用する必要があります。

セッションの可視性

セッションの可視性は、セッション作成時に設定される定数で表されます。 通常はセッション テンプレートで定義され、どの種類のユーザーがセッションに対して読み取りおよび書き込みアクセスを持つかを決定します。 セッションの可視性の可能な値は、XblMultiplayerSearchHandleGetVisibility で定義されます。 JSON ファイル内の可視性定数に許可される設定は、openvisible、および private です。

推奨されるゲーム セッションの可視性: open

Open ゲーム セッションはプレイヤーの予約を必要とせず、これにより招待プロセスが簡素化されます。 アービターは招待が送信された後に MPSD でプレイヤーを予約せず、招待されたプレイヤーをローカルでのみ追跡します。 その結果、プレイヤーは即座にアービターに接続し、セッションに参加するか、拒否されるか、または待機する必要があるか (待機プレイヤーがサポートされている場合) を決定できます。 アービターは究極の権威です。彼らは応答し、新しいメンバーにセッションに留まるか離脱するかを指示します。 Open ゲーム セッションの可視性を使用するには、招待されたプレイヤーが最終決定が行われる前にタイトルを起動してアービターに接続する必要があります。 セッションが満員であるか、招待が拒否された場合には、ユーザーにエラー メッセージを表示できます。 アービターへの接続を確立するには、セキュア デバイス アドレスが必要です。 XblMultiplayerSessionProperties::HostDeviceToken プロパティは、どのセッション メンバーが現在のセッションのアービターであるか、および招待されたプレイヤーが接続に使用すべきセキュア デバイス アドレスを判別するために使用されます。

セッションの参加可能性

セッションの参加可能性は、どの種類のユーザーがセッションに参加できるかを決定します。 セッション中に動的に設定できます。 セッション参加可能性の可能な値は次のとおりです。
  • None (既定値): 誰がセッションに参加できるかに関する制限はありません。
  • Local: ローカル ユーザーのみがセッションに参加できます。
  • Followed: ローカル ユーザーおよび他のセッション メンバーによってフォローされているユーザーのみが、予約なしでセッションに参加できます。
セッション アービターは、参加可能性設定を通じてプライベート セッションを作成できます。 参加可能性を local または followed のいずれかにすると、セッションへのアクセスが制限され、プライベートになります。 アービターはまた、セッションの参加可能性を追跡する必要があります。これにより、必要に応じてホスト レベルで古いセッション招待を拒否できます。 たとえば、セッションが既に満員になるまでに招待されたプレイヤーがセッションに参加できていない場合、アービターは参加しようとしているプレイヤーに対してセッションがロックされていることを通知し、彼らはセッションを自動的に離脱する必要があります。 このトピックの先頭に戻る。

セッション タイムアウト

セッションは、タイマーおよびその他の外部イベントによって変更されることがあります。 セッション タイムアウトは、セッション メンバーが特定の状態に留まることができる期間を定義し、それを過ぎるとセッションから自動的に非アクティブにされたり削除されたりします。 MPSD はまた、セッションのライフタイムを管理するためのタイムアウトをサポートしています。
タイムアウト設定は、テンプレート コントラクト バージョン 104 または 105 の場合、/constants/system/timeouts 内、または managed initialization オブジェクト内で行います。バージョン 107 以降の場合、設定は /constants/system 内または managed initialization オブジェクト内で個別に行います。
タイマーの期限切れ時、MPSD はセッションを自動的に更新したり、その時点で変更をアービターに通知したりしません。 セッションおよびタイムアウトの状態は、読み取りまたは書き込み要求が送信される直前にのみ更新されます。 即時更新により、返されるデータが最新であることが保証されます。
セッション タイムアウトはスタックしません。更新時に各セッション メンバーに対する状態遷移には 1 つだけが適用されます。

現在定義されているタイムアウト

このセクションでは、MPSD で現在定義されているタイムアウトについて説明します。
  • すべてのタイムアウトはミリ秒単位で指定されます。
  • 値 0 は許可されており、即時タイムアウトを示します。
  • 値のないタイムアウトは無限と見なされます。
タイムアウトには既定値があるため、無限タイムアウトを明示的に指定するには null を指定する必要があります。

evaluationTimeout

このタイムアウトは、セッション メンバーが評価決定を行いアップロードするための時間量を示します。 決定が受信されない場合、その決定は失敗としてカウントされます。 このタイムアウトは managed initialization オブジェクトに配置されます。

inactiveRemovalTimeout

このタイムアウトは、セッションに参加したが現在ゲームに関与していないセッション メンバーに対して設定されます。 既定では、メンバーは 2 時間後にセッションから削除されます。
このタイムアウトは、テンプレート コントラクト バージョン 104 または 105 の場合、inactive タイムアウトと指定されます。
多くの場合、inactive タイムアウトを 0 に設定することをお勧めします。これにより、Inactive 状態に設定されたユーザーは即座にセッションから削除され、対応するスロットがクリアされます。 この動作は、ユーザーが非アクティブになった、または Inactive 状態に達した場合、新しいプレイヤーをすばやく追加できるため、ほとんどの競技型マルチプレイヤー ゲームで望ましいものです。 協力プレイやその他のマルチプレイヤー デザインの場合、ユーザーが切断されたり、一定期間タイトルに関与していない場合に、再接続のためにユーザーにより多くの時間を許可することをタイトルに望む場合があります。 すべての設計シナリオに合う単一の解決策はないことに注意してください。

joinTimeout

このタイムアウトは、ユーザーがセッションに参加するために必要なミリ秒数を示します。 セッションへの参加に失敗したユーザーの予約は削除されます。 このタイムアウトは managed initialization オブジェクトに配置されます。

measurementTimeout

このタイムアウトは、セッション メンバーが測定値をアップロードするために必要な時間量を示します。 測定値のアップロードに失敗したメンバーは、「timeout」の失敗理由でマークされます。 このタイムアウトは managed initialization オブジェクトに配置されます。
マッチメイキング中、QoS 測定に 45 秒のタイムアウトが適用されます。その結果、マッチメイキング中は 30 秒以下の測定タイムアウトを使用することをお勧めします。

readyRemovalTimeout

このタイムアウトは、セッションに参加してゲームに入ろうとしているセッション メンバーに対して設定されます。 これは通常、シェルがタイトルに代わってユーザーを参加させ、タイトルが起動されていることを意味します。 既定では、メンバーは 3 分後にセッションから削除され、Inactive 状態に置かれます。
このタイムアウトは、コントラクト バージョン 104 または 105 の場合、ready タイムアウトと指定されます。

reservedRemovalTimeout

このタイムアウトは、誰かによってセッションに追加されたが、まだセッションに参加していないセッション メンバーに対して設定されます。 タイムアウトが期限切れになると、予約は削除され、メンバーは非アクティブと見なされます。 既定値は 30 秒です。
このタイムアウトは、コントラクト バージョン 104 または 105 の場合、reserved タイムアウトと指定されます。

sessionEmptyTimeout

このタイムアウトは、セッションが空になってから削除されるまでのミリ秒数を示します。 既定値は 0 です。
このタイムアウトは、コントラクト バージョン 104 または 105 の場合、sessionEmpty タイムアウトと指定されます。

セッション タイムアウトの例

  1. 4 人のプレイヤーでセッションが開始されます。
  2. 2 人のプレイヤー A と B は、電源障害のために切断されます。ゲーム内での彼らのステータスは Active のままです。
  3. 他の 2 人のプレイヤー C と D は、XblMultiplayerSessionLeave を使用して正しく終了します。
  4. セッションは開いたままです。プレイヤー A と B は切断されていますが、まだ Active 状態にあります。
  5. 数日後、プレイヤー A が戻ってきてゲームを起動します。
  6. プレイヤー A のゲームは、プレイヤー A がメンバーであるセッションをチェックし (読み取りを実行)、数日前の孤立したセッションを見つけます。
  7. セッションはまだセッション内にいる 2 人のプレイヤー (A と B) に対して presence チェックを実行します。
    1. プレイヤー A がタイトルを実行しているため、プレイヤー A に対する presence チェックは成功します。マッチ内のプレイヤーの Active 状態は変わりません。
    2. プレイヤー B はタイトルを実行していません。その結果、プレイヤー B に対する presence チェックは失敗します。サービスはプレイヤー B の状態を Inactive に設定します。この時点で、プレイヤー B の inactive タイムアウトが開始します。
  8. プレイヤー A は XblMultiplayerSessionLeave メソッドを使用してセッションを正しく終了します。
  9. プレイヤー B の inactive タイムアウトが期限切れになり、誰かによる次の読み取りまたは書き込みでセッションから削除されます。
  10. セッションのメンバーが 0 になり、サービスから削除されます。
例のセッションの inactive タイムアウトが 0 に設定されている場合、プレイヤー B は手順 7.1 の presence チェックの直後にタイムアウトし、おそらくセッションの書き込みで削除されます。 この場合、セッションはセッションからのさらなる読み取りや書き込みを必要とせずに閉じます。 このトピックの先頭に戻る。

1 台のコンソールでの複数のサインイン ユーザー

同じコンソールで複数のユーザーがサインインしている場合、一部のユーザーはゲーム セッションに参加しており、他のユーザーはセッションに参加していないか、現在のタイトルでアクティブでない可能性があります。 ゲーム招待も複数のユーザーに対して受信および承諾でき、ゲーム セッション メンバーシップに影響を与える可能性があります。 タイトルがすべてのセッション メンバーシップ シナリオを正しく処理できるように、この情報を考慮してください。 一般的なシナリオでは、新しいプレイヤーがサインインし、ゲーム内でアクティブになり、既存のゲーム セッションに追加される必要があります。 新しいゲーム セッションを作成するときと同様に、タイトルはゲームプレイ中に適切なタイミングでのみユーザーを追加する必要があります。 複数のサインイン ユーザーがいる場合、1 人以上のユーザーが別のゲーム セッションへの招待を受け取ることもあります。 タイトルは、これらのシナリオを特別な方法で処理する必要はありません。 セッション状態およびメンバー イベントは、ゲーム セッションおよびユーザー メンバーシップに対するすべての更新をタイトルに通知します。 オンライン セッションで複数のサインイン ユーザーを処理するには、タイトルはユーザーごとに別々の XboxLiveContext Class オブジェクトを使用して、すべてのユーザーのショルダー タップを購読します。 タイトルは、XblMultiplayerSessionInfo::ChangeNumber プロパティを使用してセッションの特定の変更を判別し、重複したショルダー タップを無視します。 このトピックの先頭に戻る。

プロセス ライフサイクル管理

非マルチプレイヤー タイトルと同様に、マルチプレイヤー セッション内のタイトルもタイトルの中断やプロセス ライフサイクル イベントの終了に遭遇する可能性があります。 その結果、セッション アービターは定期的にセッション状態を保存する必要があります。 アービターが中断された場合、タイトルはアービター移行を試みてゲーム状態を適切に保存する必要があります。新しいアービターはその後、セッション状態を復元できます。 その後、セッションが MPSD でまだ有効な場合、完全なマルチプレイヤー セッションを中断し後で再開することが可能です。 指定された 1 つのピア (通常はゲーム ホスト) のみがグローバル ゲーム状態を更新する必要があります。

ゲーム メタデータの保存

タイトルはゲーム メタデータを MPSD セッションに保存します。 ゲーム メタデータは、セッション データを表示し、タイトルがゲーム セッションを見つけて参加できるようにするために必要な情報です。 タイトルは、プレイヤー固有のメタデータをセッション メンバーのカスタム プロパティ セクションに保存します。たとえば、プレイヤーの色やセッションで好むプレイヤー武器などです。 現在のマップなどのセッション全体のメタデータは、MPSD セッションのグローバル カスタム プロパティ セクションに保存されます。

ゲーム状態の保存

ゲーム状態は、Title Storage サービスを使用して TMS に保存されます。 この場所を使用したストレージにより、タイトルはアクセス許可の問題なしにアービターを移行できます。 詳細については、アービターの移行 を参照してください。
タイトルは、中断されている場合を除き、5 分に 1 回より頻繁にゲーム状態を TMS に保存しようとしてはいけません。
このトピックの先頭に戻る。

非アクティブ セッションのクリーンアップ

sessionEmptyTimeout が 0 に設定されている場合、最後のプレイヤーがセッションを離れると MPSD セッションは自動的に削除されます。 クラッシュや切断後に使用されていないセッションにプレイヤーが含まれることを防ぐ方法については、Multiplayer Session Directory の概要トピック内の MPSD 変更通知処理と切断検出 セクションを参照してください。 クラッシュや切断後の使用されていないセッションを不適切に処理すると、タイトルがプレイヤーのセッションをクエリするときに問題が発生する可能性があります。 非アクティブ セッションをクリーンアップするには、タイトルが XblMultiplayerGetSessionAsync を呼び出して特定のユーザーのすべてのセッションをクエリし、それらのセッションを評価することをお勧めします。 タイトルが古いセッションに遭遇したとき、タイトルはセッション内のすべてのローカル プレイヤーに対して XblMultiplayerSessionLeave を呼び出します。 この呼び出しにより、最終的にメンバー数が 0 になり、セッションがクリーンアップされます。 このトピックの先頭に戻る。

セッション アービター

一部のマルチプレイヤー メソッドは、ゲーム セッション内の 1 つのクライアントによってのみ呼び出されるべきです。 このクライアントは、セッションに参加しているコンソールの 1 つで、アービターまたはホストと呼ばれます。 少なくとも 1 人のセッション メンバーがゲーム内にいる場合、セッションには進行中の参加を監視するアービターがいる必要があります。

アービターの設定

セッションがクライアントによって作成されるとき、1 つのコンソールをアービターとして指定します。 詳細については、Multiplayer タスクトピック内の MPSD セッションのアービターを設定する セクションを参照してください。

セッション状態の保存

プロセス ライフサイクル管理 セクションで説明したように、アービターは定期的にセッション状態を保存する必要があります。 タイトルによるアービター移行の場合、新しいアービターはセッション状態を復元できる必要があります。 詳細については、アービターの移行 を参照してください。

ゲーム セッション メンバーおよび進行中の参加の管理

セッション アービターの最も重要な役割は、プレイするためにゲーム セッションに参加するユーザーを管理することです。 これには、ゲーム招待の処理、待機中のプレイヤーへの通知、およびゲームを終了するプレイヤーへの対応が含まれます。

通知の受信

アービターは、XblMultiplayerSessionChangedHandler を使用して、ゲーム セッションに参加したい新しいプレイヤーをリッスンする必要があります。

空きゲーム セッション スロットを埋めるためのプレイヤーの発見

アービターは、以下のいずれかの操作を使用して、空きゲーム セッション スロットを埋めるためのプレイヤーを見つけます。
  • タイトルが遅延参加を許可するためにロビー セッションまたは他のメカニズムを使用している場合、そのメカニズムを使用して新しいセッション メンバーを見つけます。
  • 別のマッチ チケット セッションを作成します。
詳細については、Multiplayer タスクトピック内の マッチメイキング中に空きセッション スロットを埋める セクションを参照してください。

招待されたセッション メンバーの処理

アービターは、招待されたセッション メンバーを監視し、単一ユーザーへの招待の間に最小間隔を適用する必要があります。 詳細については、Multiplayer タスクトピック内の ゲーム招待の送信 セクションを参照してください。
最終更新日 2026年8月25日