マルチプレイヤー セッションの高度なトピック

このトピックを使用して、マルチプレイヤー セッションの高度な概念について学びます。

このトピックでは、以下の内容を説明します。

• セッションの概要
• メンバーのプロパティ
• セッションの機能
• セッション サイズ
• セッションのユーザーの状態
• 可視性と参加可能性
• セッション タイムアウト
• 1 台の本体にサインインした複数のユーザー
• プロセス ライフサイクル管理
• 非アクティブなセッションのクリーンアップ
• セッション アービター

セッションの概要

マルチプレイヤー セッション ディレクトリ (MPSD) のセッションはセッション名を持ち、セッション テンプレートのインスタンスとして識別されます。 セッション テンプレートは、セッションの既定の設定を提供する JSON ドキュメントです。

セッション テンプレートはサービス コンフィグ (Service Configuration) ID (SCID) を持つサービス コンフィグ (Service Configuration) の一部です。これは GUID です。 セッション テンプレートは、パートナーセンターにあります。

サービス コンフィグは、開発者向けのリソースであり、取り込み、管理、およびセキュリティ ポリシーに使用されます。 MPSD を介してセッションにアクセスすると、パートナー センターを通じて開発者が設定したアクセス ポリシーに従って、サービス コンフィグ (Service Configuration) に対し主要な承認が実行されます。 サービス構成へのアクセスが承認された後にセッションが読み込まれると、セッションのメンバーシップ検証などのセカンダリー アクセス チェックがセッション レベルで実行されます。

Important

テンプレートを使用して設定された機能は、MPSD への書き込みによって変更できません。 値を変更するには、必要な変更を行った新しいテンプレートを作成し、送信する必要があります。 テンプレートで設定されない項目はすべて、MPSD への書き込みによって変更できます。

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

このトピックでは、テンプレートが現在の Xbox One （またはそれ以降）向けの MPSD で使用しているバージョンであるコントラクト バージョン 107 を使用していることを前提としています。

セッション参照

各 MPSD セッションは、XblMultiplayerSessionReference 構造によって、マルチプレイヤー API で表されるセッション参照によって一意に識別されます。 セッションの参照には、次の文字列値が含まれます。

• サービス構成 ID (SCID)
• セッション テンプレート名
• セッション名

セッション参照は、次に示すように、セッションを識別するための URI にマップします。 次のマッピング例では、authority は sessiondirectory.xboxlive.com です。

https://{authority}/serviceconfigs/{service-config-id}/sessiontemplates/{session-template-name}/sessions/{session-name}

セッションの要素

各セッションには、可変性とセキュリティ ルールを適用する要素のグループが含まれます。 これらは、読み取り専用の家事情報 (メタデータ) と共に、セッション要素によって異なります。 ここでは、セッションを構成するために JSON ファイルに含まれるセッション要素のグループと、選択したテンプレートの JSON ファイルに含まれるセッション要素のグループについて説明します。

注意

HTTP/REST 実装にカスタム ラッパーを使用している場合、セッションとテンプレートは、実装の機能を正確に反映する JSON オブジェクトを定義する必要があります。

2 つの内部オブジェクトは、各要素グループ内にあります。

• システム オブジェクト: これらのオブジェクトには、MPSD によって適用および解釈される固定のスキーマがあります。 システム オブジェクトは検証およびマージされます。 MPSD は何を意味するのかを定義して知っているため、それらに影響を及ぼすことができます。 各システム オブジェクトの完全な定義については、「XblMultiplayerSession プレフィックスとセッション ディレクトリ URI 両方の参照」の参照資料を確認してください。

• カスタム オブジェクト: これらのオブジェクトはオプションであり、スキーマはありません。 マルチプレイヤー ゲームに関するメタデータを格納するために使用されます。 MPSD はこのデータを解釈することができないため、操作できません。 ゲーム データまたは保存される情報はタイトル管理ストレージ (TMS) に格納される必要があります。 TMS の詳細については、「Xbox サービス タイトル ストレージの概要」を参照してください。

カスタム JSON オブジェクトの例を次に示します。

    "custom": {
      "myField1": true,
      "myField2": "string",
      "myField3": 5.5,
      "myField4": { "myObject": null },
      "myField5": [ "my", "array" ]
    }

セッション定数

セッション定数は、作成時にのみ、作成者またはセッション テンプレートによって設定されます。 /constants/system オブジェクトは、MPSD を介して知られているマルチプレイヤー システムの定数を定義するために使用されます。 このオブジェクトに関連付けられているラッパーは、XblMultiplayerSessionConstants 構造で表されます。

/constants/system オブジェクトは、複数の項目を定義できます。 capabilities オブジェクト、metrics オブジェクト、managedInitialization オブジェクト (テンプレート コントラクト バージョン 104 または 105) または memberInitialization (契約バージョン 107) オブジェクト、peerToPeerRequirements オブジェクト、peerToHostRequirements オブジェクト、measurementsServerAddresses オブジェクトが含まれます。

セッションのプロパティ

MPSD のセッションのプロパティを定義するには、/properties/system オブジェクトを使用します。 このオブジェクトに関連付けられているラッパーは、XblMultiplayerSessionProperties 構造で表されます。 セッションプロパティは、いつでもセッションのメンバーによって書き込みができます。

JSON 形式のセッション プロパティの例として、joinRestriction、initializationSucceeded、matchmaking オブジェクトがあります。 この要素グループの使用例については、「ターゲット セッションの初期化と QoS」を参照してください。

メンバー定数

各セッション メンバーの参加時にメンバー定数を設定します。 JSON オブジェクトが /members/{index}/constants/system です。 セッション メンバーを示すラッパー クラスは、 XblMultiplayerSessionMember 構造です。

このトピックの先頭に戻る。

メンバーのプロパティ

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

次に例を示します。

    {
      // These flags control the member status and "activeTitle" and are mutually exclusive (it's an error to set both to true).
      // For each, false is the same as not present. The default status is "inactive"; that is, neither present.
      "ready": true,
      "active": false,

      // Base-64 blob, or not present. An empty string is the same as not present.
      "secureDeviceAddress": "ryY=",

      // During member initialization, if any members in the list fail, this member will also fail.
      // Can't be set on large sessions.
      "initializationGroup": [ 5 ],

      // List of the groups I'm in and the encounters I just had.
      // An encounter is a brief interaction with a group. When an encounter is reported, it counts as retroactively joining the group 30 seconds ago and just now leaving.
      // Group names use the session name validation rules (like case-insensitive).
      // On large sessions, groups are used to report who played with whom (rather than just session membership). Members
      // who are active in at least one group together at the same time are counted as playing together.
      // Empty lists are the same as no value specified.
      // The set of encounters is a point-in-time property, so it's immediately consumed and will never appear on a response.
      "groups": [ "team-buzz", "posse.99" ],
      "encounters": [ "CoffeeShop-757093D8-E41F-49D0-BB13-17A49B20C6B9" ],

      // Optional list of role preferences that the player has specified for role-based game modes.
      // All role names have to match across all members in the session. Role weights are
      // defined from 0-100.
      "RolePreference": { "medic": 75, "sniper": 25, "assault": 50, "support": 100 },

      // Quality of Service (QoS) measurements by lowercase device token.
      // Like all fields, "measurements" must be updated as a whole. It should be set once when measurement is complete, not incrementally.
      // Metrics can be omitted if they weren't successfully measured; that is, the peer is unreachable.
      // If a "measurements" object is set, it can't contain an entry for the member's own address.
      "measurements": {
        "e69c43a8": {
          "bandwidthDown": 19342,  // Kilobits per second.
          "bandwidthUp": 944,  // Kilobits per second.
          "custom": { }
        }

      // QoS measurements by game-server connection string. Like all fields, "serverMeasurements" must be updated as a whole, so it should be set once when measurement is complete.
      // If empty, it means that none of the measurements were completed within the "serverMeasurementTimeout".
      "serverMeasurements": {
        "server farm a": {
          "latency": 233  // Milliseconds.
        }
      },

      // Subscriptions for shoulder taps on session changes. The "profile" indicates which session changes to tap and other properties of the registration like the minimum time between taps.
      // The subscription is named with a title-generated GUID that's also sent back with the tap as a context ID.
      // Subscriptions can be added and removed individually, without affecting other subscriptions in the "subscriptions" object.
      // To remove a subscription, set its context ID to null.
      // (Like the "ready" and "active" flags, the "subscriptions" data is copied out and maintained internally, so the normal replace-all rule on system fields doesn't apply to "subscriptions".)
      // Can't be set on large sessions.
      "subscriptions": {
        "961dc162-3a8c-4982-b58b-0347ed086bc9": {
          "profile": "party",  // Or "matchmaking", "initialization", "roster", "queuehost", or "queue".
          "onBehalfOfTitleId": "3948320593",  // Optional decimal title ID of the registered channel. If not set, the title ID is taken from the token.
        },
        "709fef70-4638-4b94-905b-24cb02706eb5": null
      }
    }

サーバー要素

サーバーは、セッションに参加した、または招待された、ユーザーではないメンバーです。 関連する JSON オブジェクトは /servers/{server-name}/constants/system と /servers/{server-name}/properties/system です。 これらのオブジェクトはサーバーのみが書き込み可能です。

注意

/servers/{server-name}/constants/system オブジェクトは現在使用されていません。

セッションの構成

セッションの構成は、以下の方法で制御できます。

• パートナー センターで取り込まれたセッション テンプレートを使用します。
• マルチプレイヤー と マッチメイキング API またはREST API の呼び出しを使用します。 テンプレートを引き続き使用する必要がありますが、これに構成する値を含める必要はありません。 タイトルは、テンプレートで既に設定されている定数をオーバーライドできないことに注意してください。

別の JSON ドキュメントで、セッション自体を定義しています。 また、特定のタイトルに必要なラッパー機能を実装する必要があります。 JSON ドキュメントとラッパーコードのコンテンツは、相互に正確に反映され、最新のテンプレートのコントラクト バージョンを反映している必要があります。

セッションのスキーマは、セッション バージョン (メジャー バージョン) およびプロトコル リビジョン (マイナー バージョン) を使用してバージョン管理されます。 バージョンは、"100 * メジャー + マイナー" として X-Xbl-Contract-Version ヘッダーにまとめられます。 たとえば、v1.7 タイトルには、最新のテンプレート コントラクト バージョンが 107 であると仮定して、すべての REST 要求に X-Xbl-Contract-Version: 107 のヘッダーが含まれます。

注意

ほとんどのタイトル (Xbox サービスAPI (XSAPI) を使用) では、契約バージョン 105、セッション テンプレート バージョン 107 を使用することをお勧めします。

セッション テンプレート

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

このトピックの先頭に戻る。

セッションの機能

機能は、MPSD がそのセッションに適用する動作を構成する、MPSD セッション内の定数です。 最もよく使用されるのは、セッション テンプレートの機能を設定するパートナー センターです。

機能は、/constants/system/capabilities オブジェクトで設定されます。 機能が必要ない場合は、空の capabilities オブジェクトを使用します。

注意

タイトルが、マルチプレイヤー API やマッチメイキング API を使用して、セッション機能を変更したり、アクセスしたりすることはほぼ不可能です。

セッション機能は XblMultiplayerSessionCapabilities 構造によって表されます。 これらは、セッションがサポートできる内容を示すブール値です。

• Connectivity
• ゲームプレイ
• 大きいサイズ
• 接続にはアクティブなメンバーが必要

XblMultiplayerSessionConstants構造には、セッション機能を検討する次のプロパティを定義する SessionCapabilities メンバー (XblMultiplayerSessionCapabilities 型のメンバー) を含みます。

• CapabilitiesConnectivity
• CapabilitiesGameplay
• CapabilitiesLarge

注意

タイトルで動的なセッション機能を定義する場合は、セッション定数の対応するプロパティを true に設定します。

このトピックの先頭に戻る。

セッション サイズ

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

セッションの最大サイズ

セッションの最大サイズは、それが収容できるセッション メンバーの最大数です。 これは、XblMultiplayerSessionConstants::MaxMembersInSession プロパティで表されます。 メンバーの最大サイズが /constants/system オブジェクトに設定されます。

最大セッション サイズは 1 ～ 100 の範囲であり、作成時に設定しなければ、既定値の 100 になります。 必要なサイズが 100 を超える場合、セッションは「大きな」セッションと呼ばれ、特別な方法で設定されます。

切断

セッションの最大サイズを設定すると、特定の切断シナリオで、空きスロットが埋まっているように見える可能性があります。 たとえば、ネットワークまたは電源の障害によりプレイヤーが切断された場合、遅延はセッションに直ちに反映されません。 切断検知機能を使用すると、メンバーが非アクティブに設定されます。 詳細は、「マルチプレイヤー セッション ディレクトリの概要」の「MPSD の変更通知処理および切断検出」セクションを参照してください。

それに対し、ハートビートを使用して切断を検出するピア メッシュは、多くの場合、2 ～ 3 秒以内に切断を認識し、プレイヤー スロットを即時に開くことができます。 しかし、アービターは他のメンバーを削除できません。

大規模なセッション

大きな MPSD セッションは最大 1000 のメンバーを持つことができますが、すべてのメンバー一覧の取得など、いくつかのセッション機能が無効になります。 セッションの大きさはXblMultiplayerSessionCapabilities::Large プロパティで表されます。

このプロパティを true に設定して、大規模なセッションであることを示します。 "大規模な" 機能は /constants/system/capabilities オブジェクトで示されます。 詳細については、「セッション機能」を参照してください。

このトピックの先頭に戻る。

セッションのユーザーの状態

MPSD は、セッションに追加されたユーザーの状態としてユーザー状態を定義します。 ユーザー状態は、XblMultiplayerSessionStatus 列挙によって定義されます。 また、ユーザーはセッションに追加される前に、 「使用可能」な状態であると見なされます。

XblMultiplayerSessionCurrentUserSetStatus を使用して、セッションのユーザー状態を変更できます。 ゲーム セッションの JSON ドキュメントで /members/{index}/properties/system を正しく設定することで、REST 用にこの変更を行います。

予約済みのユーザーの状態

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

アクティブなユーザーの状態

ユーザーがアクティブな状態の場合、タイトルがユーザーの代わりにセッションに参加し、ユーザーはセッションにアクティブに参加します。 ユーザーがゲームをプレイしている限り、この状態が継続されます。

タイトルでは、最初に起動したとき、通常はセッションの状態をチェックすることによって、ユーザーが既にいずれかのセッションのメンバーかどうかを確認する必要があります。 ユーザーがセッション メンバーである場合、タイトルはすぐにゲームに移行し、参加しているすべてのローカル メンバーのユーザーの状態をアクティブに設定することができます。

セッションのプレイ中、ユーザーはアクティブな状態のままになります。 ユーザーがゲーム中 UI を使用してセッションを終了した場合、XblMultiplayerSessionLeaveを呼び出すことで、そのユーザーをセッションから削除する必要があります。 ユーザーが一時的にゲームを離れただけの場合は (タイトルが制限されたときのように)、適切な時間だけユーザーをアクティブ状態に保つ必要があります。

タイトルで指定されている時間が経過してもユーザーが戻らない場合は、ユーザーの状態を非アクティブに変更してください。

非アクティブなユーザーの状態

非アクティブ状態では、ユーザーは現在はゲームに参加していませんが、まだセッション内のスロットを確保しています。 つまり、ユーザーは、"アクティブではない" 状態です。

ユーザーをセッションで非アクティブなユーザーの状態に設定する責任があるのは、そのユーザー自身の本体です。 アービターがこれを行うことはできません。

ユーザーが非アクティブ状態になるシナリオの例を以下に示します。

• タイトルが Suspending イベントを受け取る。

• タイトルによって定義された時間、ユーザーの非アクティブ状態が続いた (入力またはコントローラーの応答がなかった)。 対戦型マルチプレイヤー ゲームの場合の推奨値は 2 分です。

• タイトルが、2 分、またはタイトルで定義されている時間より長く制限モードになっている。 この制限モードのタイムアウト時間は、ユーザーが関連アプリまたはタイトルに関係する他のエクスペリエンスを使用してタイトルから離れると予想される時間です。

• ユーザーがセッションから異常切断された。 詳細は、「マルチプレイヤー セッション ディレクトリの概要」の「MPSD の変更通知処理および切断検出」セクションを参照してください。

タイトルが起動し、特定のセッション メンバーのユーザーの状態が非アクティブに設定されている場合、タイトルが一時停止されているか、セッションでユーザーが長い間非アクティブになっています。 タイトルが再び起動しようとしているので、ユーザーが、自分が所属するゲーム セッションの続行を望んでいることを示しています。

タイトルの起動時にユーザーの状態がアクティブの場合は、おそらく、ネットワークの切断、またはタイトルが中断される前にユーザーを非アクティブに設定できなかった他のシナリオが原因です。 タイトルではどちらの場合も、ユーザーをゲームおよび他のユーザーと再接続してプレイを続けさせるか、ユーザーをセッションから削除するよう試みる必要があります。

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

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

このトピックの先頭に戻る。

可視性と参加可能性

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

セッション可視性

セッションの可視性は、セッションの作成時に設定される定数で表されます。 これは、通常、セッション テンプレートで定義され、セッションに対する読み取りアクセスと書き込みアクセスができるユーザーの種類を決定します。

セッションの可視性の値は、XblMultiplayerSearchHandleGetVisibility によって定義されます。 JSON ファイルの可視性定数に許容される設定は、open、visible、および private です。

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

オープン状態のゲーム セッションでは、プレイヤーの予約を必要としないため、招待プロセスが簡素化されます。

アービターは、招待が送信された後に MPSD でプレイヤーを予約せず、招待されたプレイヤーのローカルでの追跡のみを行います。 結果として、プレイヤーはすぐにアービターに接続して、セッションに参加するか、拒否されるか、待機するか (待機中のプレイヤーがサポートされている場合) を判断できます。

アービターが最終権限者です。 新しいメンバーがセッションに参加するか、退出するかを指示します。

ゲーム セッションの可視性に open を使用すると、招待されたプレイヤーは、最終決定が行われる前にタイトルを起動してアービターに接続する必要があります。 セッションがいっぱいの場合、または招待が拒否された場合は、ユーザーにエラー メッセージを表示できます。

アービターへの接続を確立するには、セキュア デバイス アドレスが必要です。 XblMultiplayerSessionProperties::HostDeviceToken プロパティを用いて、どのセッション メンバーがセッションの現在のアービターか、および招待されたプレイヤーがどのセキュア デバイス アドレスに接続する必要があるかを示します。

セッションの参加可能性

セッションの参加可能性は、セッションに参加できるユーザーの種類を決定します。 これはセッション中に動的に設定できます。

セッションの参加可能性で使用できる値は次のとおりです。

• None (既定): セッションに参加できるユーザーに関する制限はありません。
• ローカル: ローカル ユーザーのみがセッションに参加できます。
• Followed: ローカル ユーザーおよび他のセッション メンバーによってフォローされているユーザーのみが予約なしでセッションに参加できます。

セッションのアービターは、参加可能性の設定によってプライベート セッションを作成できます。 参加可能性を Local または Followed にすると、セッションへのアクセスが制限され、そのセッションはプライベートになります。

また、アービターは必要に応じて、セッションの参加可能性を追跡してホスト レベルで古いセッションへの招待を拒否できるようにする必要があります。 たとえば、セッションがいっぱいになるまで招待されたプレイヤーがセッションへの参加に至らなかった場合、アービターは、セッションがロックされており、セッションを離れる必要があることを、これから参加するプレイヤーに自動的に指示できます。

このトピックの先頭に戻る。

セッション タイムアウト

タイマーおよびその他の外部イベントによってセッションを変更できます。 セッション タイムアウトでは、自動的に非アクティブになる、またはセッションから削除される前に、セッション メンバーが特定の状態を維持できる期間を定義します。 MPSD では、セッションの有効期間を管理するためのタイムアウトもサポートされます。

注意

テンプレート コントラクト バージョン 104/105 の場合、タイムアウトの設定は /constants/system/timeouts または初期化の管理オブジェクト内で行います。 107 以降のバージョンの場合、設定は /constants/system または初期化の管理オブジェクト内で個別に行います。

タイマーの期限が切れると、MPSD は自動的にはセッションを更新せず、変化が起きたその時点でアービターに通知します。 セッションおよびタイムアウト状態は、読み取りまたは書き込み要求が送信される直前にだけ更新されます。 直前に更新することで、返されるデータが確実に最新のものになります。

注意

セッション タイムアウトはスタックされません。 各セッション メンバーの更新時の状態遷移に対して 1 回だけ適用されます。

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

ここでは、MPSD で現在定義されているタイムアウトについて説明します。

• すべてのタイムアウトはミリ秒単位で指定します。
• 即時のタイムアウトを示す 値 0 を指定できます。
• 値を持たないタイムアウトは無制限と見なされます。

タイムアウトには既定値があるため、タイムアウトを無期限にするには、null を明示的に指定してください。

evaluationTimeout

このタイムアウトは、セッション メンバーが評価の決定を行ってアップロードしなければならない時間を示します。 決定が受信されない場合、失敗としてカウントされます。 このタイムアウトは、初期化の管理オブジェクトに配置されます。

inactiveRemovalTimeout

このタイムアウトは、セッションに参加しているが、現在はゲームに参加していないセッション メンバーに対して設定されます。 既定では、メンバーは 2 時間後にセッションから削除されます。

注意

このタイムアウトは、テンプレート コントラクト バージョン 104 または 105 では非アクティブ タイムアウトと呼ばれています。

多くの場合、非アクティブ タイムアウトは 0 に設定することをお勧めします。 これにより、非アクティブ状態に設定されたユーザーは、すぐにセッションから削除されて、対応するスロットはクリアされます。 この動作は、ユーザーが非アクティブになるか非アクティブ状態に達した場合に、新しいプレイヤーをすぐに追加できるので、ほとんどの対戦型マルチプレイヤー ゲームに適しています。

協力型またはその他のマルチプレイヤー設計のタイトルでは、ユーザーが切断された場合またはしばらくタイトルに参加していない場合に、ユーザーが再接続できる時間をもう少し長くすることをお勧めします。 すべての設計シナリオに適合する単一のソリューションはありません。

joinTimeout

このタイムアウトは、ユーザーがセッションに参加しなければならないミリ秒数を示します。 セッションへの参加に失敗したユーザーの予約は削除されます。 このタイムアウトは、初期化の管理オブジェクトに配置されます。

measurementTimeout

このタイムアウトは、セッション メンバーが測定値をアップロードしなければならない時間を示します。 測定値のアップロードに失敗したメンバーには、失敗理由として "タイムアウト" が設定されます。 このタイムアウトは、初期化の管理オブジェクトに配置されます。

注意

マッチメイキング中に、QoS 測定に 45 秒間のタイムアウトが適用されます。 結果として、マッチメイキング中に 30 秒以内の測定タイムアウトを使用することをお勧めします。

readyRemovalTimeout

このタイムアウトは、セッションに参加していて、ゲームに参加しようとしているセッション メンバーに対して設定されます。 これは通常、シェルがタイトルに代わってユーザーを参加させ、タイトルが起動中であることを意味します。 既定では、メンバーはセッションから削除され、3 分後に非アクティブ状態になります。

注意

このタイムアウトは、コントラクト バージョン 104 または 105 では準備完了タイムアウトと呼ばれています。

reservedRemovalTimeout

このタイムアウトは、他のユーザーによってセッションに追加されたが、まだセッションに参加していないセッション メンバーに対して設定されます。 タイムアウト時間が経過すると、予約は削除され、メンバーは非アクティブと見なされます。 既定値は 30 秒です。

注意

このタイムアウトは、コントラクト バージョン 104 または 105 では予約タイムアウトと呼ばれています。

sessionEmptyTimeout

このタイムアウトは、セッションが空になってから削除されるまでのミリ秒数を示します。 既定値は 0 です。

注意

このタイムアウトは、契約バージョン 104 または 105 の sessionEmpty タイムアウトとして指定されます。

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

1. 4 人のプレイヤーでセッションが開始されます。

2. 2 人のプレイヤー A と B が電源障害によって切断されます。 プレイヤーのゲームでの状態はアクティブなままです。

3. 他の2人のプレーヤー、C と D は、XblMultiplayerSessionLeave を使用して正常に終了します。

4. セッションはオープンのままです。 プレイヤー A と B は接続が切断されていますが、まだアクティブ状態です。

5. 数日後、プレイヤー A が戻ってゲームを開始します。

6. プレイヤー A のゲームは、プレイヤー A がメンバーであるセッションをチェックし (読み取りを実行し)、孤立した数日前のセッションを見つけます。

7. セッションは、まだセッション内にいる 2 人のプレイヤー (A および B) に対して、プレゼンスのチェックを行います。

   1. プレイヤー A がタイトルを実行しているため、プレイヤー A に対するプレゼンス チェックは成功します。 試合中のプレイヤーのアクティブ状態は変わりません。
   2. プレイヤー B は、タイトルを実行していません。 その結果、プレイヤー B のプレゼンス チェックは失敗します。 サービスはプレイヤー B の状態を非アクティブに設定します。 この時点で、プレイヤー B の非アクティブなタイムアウトが始まります。

8. プレイヤー A は XblMultiplayerSessionLeave メソッドを使用してセッションを正常に終了します。

9. プレーヤー B の非アクティブなタイムアウトの有効期限が切れ、誰かの次の読み取りまたは書き込みが行われるセッションから削除されます。

10. セッションは、メンバーが 0 になったので、サービスから削除されます。

例のセッションの非アクティブ タイムアウトが 0 に設定されている場合、プレイヤー B は、手順 7.1 でのプレゼンス チェックの直後にタイムアウトし、セッション書き込みによっておそらく削除されます。 この場合、セッションは、セッションへの追加の読み取りまたは書き込みがなくても閉じられます。

このトピックの先頭に戻る。

1 台の本体にサインインした複数のユーザー

同じ本体に複数のユーザーがサインインした場合、ゲーム セッションに含まれるユーザーと、ゲーム セッションに含まれないユーザー、または現在のタイトルでアクティブではないユーザーが混在することがあります。 複数のユーザーがゲームの招待を受け取って受け入れる場合もあり、ゲーム セッションのメンバーシップに影響があります。 セッション メンバーシップのすべてのシナリオを正しく処理できるように、タイトルではこの情報を考慮してください。

一般的なシナリオでは、新しいプレイヤーがサインインし、ゲームでアクティブになり、既存のゲーム セッションに追加される必要があります。 新しいゲーム セッションの作成と同様に、タイトルはゲーム プレイ中の適切なときにのみ、ユーザーを追加する必要があります。

サインインしたユーザーが複数いる場合、その中の 1 人以上が別のゲーム セッションへの招待を受け取ることもあります。 タイトルではこのようなシナリオを特定の方法で処理する必要はありません。 セッションの状態およびメンバー イベントは、タイトルにゲーム セッションおよびユーザーのメンバーシップの更新プログラムについて通知を行います。

オンライン セッションにサインインした複数のユーザーを処理するために、タイトルはユーザーごとに別々の XboxLiveContext Class オブジェクトを使用して、すべてのユーザーについてショルダー タップをサブスクライブします。 タイトルは、XblMultiplayerSessionInfo::ChangeNumber プロパティを使用してセッション内の特定の変更を判断し、重複するショルダー タップを無視します。

このトピックの先頭に戻る。

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

非マルチプレイヤー タイトルと同様に、マルチプレイヤー セッション内のタイトルで、タイトルの一時停止やプロセス ライフサイクル イベントの終了が発生することがあります。 結果として、セッション アービターは定期的にセッション状態を保存する必要があります。

アービターが一時停止された場合、タイトルはアービターの移行を試みて、必要に応じてゲーム状態を保存する必要があります。 その後、新しいアービターはセッションの状態を復元できます。 セッションが MPSD でまだ有効である場合は、マルチプレイヤー セッション全体を一時停止し、後で再開することができます。

指定されているただ 1 つのピア (通常はゲーム ホスト) が、グローバルなゲーム状態を更新する必要があります。

ゲーム メタデータのストレージ

タイトルは、MPSD セッション内にゲーム メタデータを格納します。 ゲーム メタデータは、セッション データを表示し、タイトルがゲーム セッションを見つけて参加できるようにするために必要な情報です。

タイトルは、セッション メンバーのカスタム プロパティ セクションにプレイヤー固有のメタデータを格納します。 たとえば、プレイヤーの色、セッションで使用するプレイヤーの武器などがあります。 現在のマップのようなセッション全体のメタデータは、MPSD セッションのグローバル カスタム プロパティ セクションに格納されます。

ゲーム状態のストレージ

ゲームの状態は、タイトル ストレージ サービスを使用して TMS に保存されます。 この場所を使用するストレージにより、タイトルはアクセス許可の問題なしにアービターを移行できます。 詳細については、「アービターの移行」を参照してください。

注意

タイトルが、一時停止されている場合を除き、5 分に 1 回よりも高い頻度で TMS にゲーム状態を保存しないようにしてください。

このトピックの先頭に戻る。

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

sessionEmptyTimeout が 0 に設定されている場合、最後のプレイヤーがセッションを離れると、MPSD セッションは自動的に削除されます。 クラッシュ後または切断後に未使用のセッションにプレイヤーが含まれないようにする方法を調べるには、「マルチプレイヤー セッション ディレクトリの概要」の「MPSD の変更通知処理および切断検出」セクションを参照してください。 クラッシュまたは切断した後に、使用されていないセッションを不適切に処理すると、タイトルがプレーヤーのセッションをクエリするときに問題が発生することがあります。

非アクティブ セッションをクリーンアップするには、 XblMultiplayerGetSessionAsync を呼び出してセッションを評価し、タイトルに特定のユーザーのセッションすべてにクエリを実行させることをお勧めします。 タイトルのセッションが古くなった場合は、タイトルから、セッション内のローカルプレイヤーすべての XblMultiplayerSessionLeaveを呼び出します。 この呼び出しにより、メンバー カウントを 0 に落として、セッションをクリーンアップします。

このトピックの先頭に戻る。

セッション アービター

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

アービターの設定

セッションの作成時に、クライアントはアービターとして 1 つの本体を指定します。 詳細については、「マルチプレイヤー タスク」の「MPSD セッションのアービターの設定」セクションを参照してください。

セッション状態の保存

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

ゲーム セッションのメンバーと途中参加の管理

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

通知の受信

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

空のゲーム セッション スロットに入れるプレイヤーを探す

アービターは、次のいずれかの操作を使用して、空のゲーム セッション スロットに入れるプレイヤーを探します。

• タイトルが、ロビー セッションや遅れて参加できるメカニズムを使用している場合は、そのメカニズムを使用して新しいセッション メンバーを見つけます。
• 別のマッチ チケット セッションを作成します。

詳細については、「マルチプレイヤー タスク」の「マッチメイキング中に空きセッション スロットを埋める」セクションを参照してください。

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

アービターは、招待されたセッション メンバーを監視し、1 人のユーザーに対する招待間の最小間隔を適用する必要があります。 詳細については、マルチプレイヤー タスクのトピックの「ゲームへの招待を送信する」セクションを参照してください。