ゲーム セッションの可視性と参加可能性
Xbox One（以降）では、ゲーム セッションとゲーム パーティーの可視性と参加可能性の設定により、マルチプレイヤー エクスペリエンスへのアクセスが制御されます。 セッションへの参加、ゲームセッションやパーティへの招待など、優れたユーザー エクスペリエンスを提供するためには、これらの設定を理解する必要があります。
このトピックでは、可視性と参加可能性の違いについて説明します。 また、このトピックでは、お客様に最高のマルチプレイヤー ユーザー フローを提供するために、タイトルが使用することを推奨する特定の設定についても説明します。
ゲーム セッションの可視性
マルチプレイヤー セッション ディレクトリ (MPSD) のセッション アクセスは、セッションの可視性とセッションの参加可能性という 2 つの設定によって制御されます。 これらの設定を使用すると、セッションへのアクセスを MPSD レベルで制限できます。
1 番目のアクセス制御方法はセッションの可視性です。 セッションの可視性は、セッションの作成時に設定される定数です。
セッションの可視性は、通常、セッション テンプレートで定義され、セッションに対する読み取りアクセスと書き込みアクセスができるユーザーの種類を決定します。
可視性設定の値は次のとおりです。
オープン: すべてのユーザーがセッションを読み書きできます。
ビジブル: セッションの読み取りはすべてのユーザーが可能ですが、セッションの書き込みは参加済みで予約済みのプレイヤーだけが可能です。
プライベート: 参加済みで予約済みのプレイヤーだけがセッションを読み書きできます。
注意
可視性を"プライベート" に設定すると、招待されたプレイヤーは join() を繰り返し呼び出すことが必要になる場合があります。 招待がプラットフォーム UI を介して送信される場合は、そのプレイヤーがセッションで予約される前に、他のプレイヤーがそれを受信する可能性があります。 このような競合状態では、参加しているプレイヤーに対する予約が "プライベート セッション"または "可視セッション "で必要になるため、招待されたプレイヤーに対する join() の呼び出しが失敗する場合があります。
予約が存在しない場合、セッションでアクセス エラー (HTTP/403) が発生します。 招待されたプレイヤーは、join() 操作を再試行する必要があります。 ただし、再試行するときは 5 秒以上の間隔を置く必要があります。 プレイヤーに対する参加フローの間の競合状態を避けるため、タイトルではセッション可視性を"オープン"に設定することをお勧めします。
ゲーム セッションの参加可能性
2 番目のアクセス制御方法は参加可能性です。 参加可能性は、セッションの有効期間の間に動的に設定でき、セッションに参加できるユーザーの種類を決定します。
セッションの参加可能性の値は次のとおりです。
なし: (既定値) - セッションに参加できるユーザーに制限はありません。
ローカル: ローカル ユーザーのみがセッションに参加できます。
Followed: ローカル ユーザーおよび他のセッション メンバーによってフォローされているユーザーのみが予約なしでセッションに参加できます。
アービター またはセッション ホストは、参加可能性の設定を使用して "プライベート"セッションを作成できます。参加可能性をローカルまたは Followed にすると、ゲーム セッションへのアクセスを制限してプライベートにできます。
さらに、必要に応じて過去のセッション招待をホスト レベルで拒否できるように、セッション アービターまたはホストはセッションの参加可能性を追跡する必要があります。 例えば、招待されたプレイヤーがセッションやパーティーに参加するためにまだ到着していない場合、アービターやホストは、参加するプレイヤーにセッションがロックされていることを指示することができます。 その場合はセッションまたはパーティーを自動的に終了する必要があります。
注意
ゲーム セッションの参加可能性は、パーティー アプリの UI には反映されません。 参加可能性が制限されている場合でも、パーティー アプリの招待 UI および ShowSendInvitesAsync ではゲーム セッションへの招待が可能です。
ゲーム パーティーの参加可能性
MPSD セッションの制御に加えて、タイトルはゲーム パーティーの参加可能性状態を制御することもできます。 この設定を使用して、ゲーム パーティーのアクセスをパーティー レベルで制限できます。
ゲーム パーティーを作成すると、パーティーの参加可能性を動的に変更できます。 ゲーム パーティーの参加可能性の状態はパーティー招待 UI に反映されます。
参加可能性の状態は次の値に設定できます。
招待制: ゲーム パーティーに参加するためには招待が必要です。
フレンドなら参加可能 (既定値) — プレイヤーがゲーム パーティーに参加するためにはフレンド関係が必要です (パーティーに参加するには、パーティー メンバーが参加しているプレイヤーをフォローしている必要があります)。
参加可能性を使用して、招待のみのゲーム パーティーを作成できます。 パーティへの参加を制限し、プレイヤーが招待を受けていないと参加できないようにするには、参加可能性を"招待のみ"に設定します。
注意
パーティー参加可能性はセッション参加可能性に影響しません。 しかし、パーティの参加可能性はパーティー アプリの UI に反映されます。 プレイヤーは、タイトルの外部でパーティー アプリのパーティーの参加可能性を手動で変更できます。
推奨事項
以下の推奨事項は、最も一般的なタイトル シナリオに適用されます。 タイトルは可能な限りこれらの設定に従うべきであり、新規プレイヤーがセッションに参加するかどうかの最終的な判断はタイトル内のロジックで行うべきです。
ゲーム セッションの推奨される可視性: オープン
オープン ゲーム セッションの場合は、プレイヤーの予約は必要ありません。 これにより、招待のフローが簡単になります。
セッション アービターやホストは、招待状が送られてきた後、セッション ドキュメントでプレイヤーを予約しません。 その代わり、セッション アービターやホストは、招待されたプレイヤーをローカルで追跡するだけです。 これにより、プレイヤーはホストに即座に接続し、セッションに参加すべきか、拒否されるか、あるいは待つべきかを判断することができます（待機プレイヤーがサポートされている場合）。
アービターまたはホストは最終的な権限であり、新しいメンバーにセッションに留まるか退出するかを応答および指示します。
注意
招待されたプレイヤーは、最終的な決定が行われる前に、タイトルを起動してアービターまたはホストに接続する必要があります。 セッションに空きがない場合、または招待が拒否された場合は、ユーザーにエラー メッセージを表示してもかまいません。
注意
アービターまたはホストへの接続を確立するには、セキュア デバイス アドレスが必要です。 どのセッション メンバーがセッションの現在のアービターまたはホストか、および招待されたプレイヤーがどのセキュア デバイス アドレスに接続する必要があるかということは、セッションの HostDeviceToken を使用して示す必要があります。
推奨されるゲーム セッションの参加可能性: 既定 (設定しない)
現在、ゲーム セッションの参加可能性はパーティー アプリ UI に反映されず、ユーザーには表示されません。 タイトルのフローを単純にするため、ゲームの参加可能性は既定値のままにする必要があり、すべての参加権限はアービターまたはホストによって処理される必要があります。
ゲーム パーティーの推奨される参加可能性
ゲーム パーティーの参加可能性は、タイトルがユーザーに提供しようとしているセッションの種類に依存します。
次の 2 つのシナリオがあります。
ゲームを開く: オープン ゲームの場合、ゲーム パーティーの参加可能性は既定値 "Joinable by Friends" のままにする必要があります。これにより、フレンドは招待なしでゲーム パーティー (および延長版のゲーム セッション) に参加できます。
プライベート ゲーム: プライベートまたはクローズド ゲームの場合、ゲーム パーティーの参加可能性は "招待のみ" に設定する必要があります。これにより、他のプレイヤーが招待なしでパーティー (および延長、ゲーム セッション) に参加できないように制限されます。
注意
プレイヤーは、パーティー アプリを使用してゲーム セッションの参加可能性を手動で変更できます。
どちらの種類のゲームについても、アービターまたはホストはセッションへの参加を許可されるユーザーを決定する最終的な権限であり続ける必要があります。 これにより、open から private にゲーム フローを切り替えることで発生する可能性がある競合状態を解決します。 アービターかホストがプレイヤーを拒否した場合、拒否されたタイトル インスタンスは、そのプレイヤーをセッションから削除し、プレイヤーがパーティーを離れることもできるようにするためのゲーム内 UI を表示する必要があります。
セッションの最大サイズ
セッションの最大メンバー サイズを使用して、ゲーム セッションに参加しているプレイヤーの数を制限できます。
しかし、この制限により、特定の切断シナリオでは、開いているスロットがまだ埋まっているように見えることがあります。 たとえば、ネットワークのトラブルまたは停電によりプレイヤーが切断された場合、遅延はセッションに直ちに反映されません。
プレゼンス サービスが切断を検知すると同時に、メンバーは非アクティブに設定されます（最大20秒）。 非アクティブなタイムアウトが期限切れになった後、プレイヤーは削除されます。
一方、ハートビートを使用して切断を検出するピア メッシュは、通常、2 ～ 3 秒以内に切断を認識して、プレイヤー スロットをすぐに空けることができます。 ただし、アービターまたはホストは他のメンバーを削除できません。
この問題に対処するには、セッション メンバーの最大サイズを常に、タイトルが実際にサポートしているプレイヤーの最大数よりも大きい値に設定する必要があります。 たとえば、プレイヤー数が 8 の場合、最大セッション サイズを 12 などと設定する必要があります。 これにより、以前のプレーヤーがまだタイムアウトになっていない場合でも、新しいプレイヤーを参加させることができます。
アービターやホストは、セッションがいっぱいになったかどうかを判断し、新しいプレイヤーがまだ参加できるかどうかを判断するカスタムセッションプロパティを設定します。 (IsFull : "true")。
これにより、セッションが参加可能である場合、プレイヤーの参加をすばやく確認できます。
また、アービターまたはホストは、インデックスによって、タイムアウトしたメンバーを示すカスタム プロパティを維持する必要があります (たとえば、TimedOutPlayers : "3, 5, 9")。
これにより、新しいプレイヤーは現在のセッション メンバーを正しく識別できます。
待機しているプレイヤーへの通知
タイトルでは、ゲーム パーティーに加えて、キュー内のプレイヤー リストを管理することによって待機しているプレイヤーをサポートできます。 プレイヤーがホストに接続したときにゲーム セッションに空きがない場合、プレイヤーはホストの内部待機リストに追加されます。
キューに入れられたプレイヤーは、ゲーム セッションには参加しませんが、ゲーム パーティーには留まっています。 ネットワーク トラフィックを最小限に抑えるために、この時点では、待機中のプレーヤーはホストから切断します。
ゲームセッションのスロットが待機中のプレーヤー用に開くと、アービターまたはホストが XblMultiplayerSessionAddMemberReservation を呼び出してプレーヤーの予約を追加します。
この時点では、待機中のプレイヤーはまだこの予約に気づいていません。 その結果、アービターまたはホストが
PullReservedPlayersAsyncのメソッドを呼び出す必要があります。 これにより、通知設定やタイトルのフォーカス状態に応じて、予約したすべてのプレイヤーに UI 通知またはGameSessionReady通知が行われます。この通知を受信すると、新しいプレーヤーがホストに再接続し、セッションに参加します。
あるいは、プレイヤーはホストに接続したままにして、スロットが空いたことをホストがプレイヤーに通知した時点でセッションに参加することもできます。 しかし、このフローでは、タイトル以外の UI 通知を表示することができません。
注意
タイトルが中断または終了した場合、プレイヤーはゲーム パーティーから自動的に削除されます。 これ以降プレイヤーへの通知は行われません。
クライアント マルチプレイヤーのフロー
