マルチプレイヤー機能の概要 このドキュメントでは、これらの機能を活用して、シームレスなマルチプレイヤー体験を実現するためのアプローチについて説明します。
Meta Questのマルチプレイヤーは、複数のユーザーが同期的、非同期的、または同じ場所にいる場合のいずれにおいても、共通の目標に向かって協力または競争するエクスペリエンスです。マルチプレイヤーコンテンツがうまくデザインがされているなら、ユーザーはアプリをもう一度使いたくなり、繰り返しその体験を楽しむようになるでしょう。
マルチプレイヤーエクスペリエンスでは、
バーチャル体験に関する行動規範 (CCVE)に違反しているプレイヤーの行動についてユーザーが開発者に報告できる仕組みを提供することも必要です。ユーザーにガバナンスツールを提供することで、アプリのコミュニティをキュレートし、アプリに思い描いているコミュニティを構築することができます。
同期、非同期、コロケートされたマルチプレイヤーエクスペリエンス 同期マルチプレイヤーエクスペリエンスとは、ユーザーがリアルタイムで同時に同じアクティビティに参加するエクスペリエンスです。同期型マルチプレイヤーは、一般的に対面、ローカルマルチプレイヤー、オンラインマルチプレイヤーのいずれかで実現されます。
非同期マルチプレイヤーエクスペリエンスとは、ユーザーが目標に向かって前進するのに同時にプレイしたり、同じアクティビティに参加したりする必要がないエクスペリエンスです。非同期マルチプレイヤーエクスペリエンスには、リーダーボードの順位を競うようなものや、ユーザーが自作のコンテンツをアップロードしたり、他のユーザーも一緒に体験して楽しめるような共通の目標を目指したりできるアプリが含まれます。
同じ場所にいるマルチプレイヤーエクスペリエンスは、ユーザーが現実の同じ場所でゲームや体験をプレイするマルチプレイヤーエクスペリエンスです。コロケートされたエクスペリエンスでは、共有空間アンカーのようなものを利用して、複合現実(MR)体験を提供します。MRエクスペリエンスは、ユーザーをつなぐ新しい方法で、共有仮想空間で交流したり、新しいマルチプレイヤーエクスペリエンスを一緒に楽しんだりできるようになります。
Questのエコシステム全体において、マルチプレイヤーアプリやゲームには、ユーザーのエンゲージメントが一貫して高く、再度体験したいという強いモチベーションをユーザーに抱かせるものとなっています。
Questのエコシステムでは、マルチプレイヤーアプリはPlatform SDKを基盤として構築されており、このSDKには没入型アプリのマルチプレイヤー対応を可能にするAPIが含まれています。さらに、プラットフォームAPIを統合すると、
Meta Horizon開発者センター にあるマルチプレイヤー分析ツールとテストツールが使えるようになります。
Platform SDKには、さまざまな移動機能も含まれています。移動機能により、ユーザーはデスティネーションを行き来したり、友達やフォロワーを招待したりすることができるようになります。
アプリで移動を可能にするには、以下の機能を使います。
デスティネーション - デスティネーションは、アプリ内に設定可能な場所で、グループプレゼンスで表示することができます。アプリにデスティネーションを設定するには、デスティネーションの概要 をご覧ください。グループプレゼンス - アプリで管理される以下の情報を含みます。
ユーザーがどのアプリにいるか 対戦中であるか ロビーにいるか 特定のデスティネーションにいるか 合流可能かどうか、つまり現在自分がいるデスティネーションにほかのユーザーを招待できるかどうか アプリへの招待 - フォロワーや最近一緒にプレイしたユーザーを既存のロビーに招待できます。参加者リスト - 参加者リストにより、ユーザーは一緒にゲームに参加している人を確認できます。再参加 - 再参加により、ユーザーは中断後に友達とのセッションに戻るかどうかを決められます。Webhooks - Webhooksを利用すると、アプリ内のマルチプレイヤーエクスペリエンスに関連した変更に関するリアルタイムのHTTP通知を受け取ることができます。招待リンク - オープンな招待リンク。これをほかの人にシェアするとアプリ内で会うことができます。クイック招待 - クイック招待により、開発者はMeta Questオーバーレイがなくても招待をアプリエクスペリエンスに統合できます。以下は、一般的な移動のユースケースとエクスペリエンスの例です。これらは、ユーザーが移動のシステムや機能を通常どのように操作するかを代表的に示したものです。
注 : これらのサンプルは、テストユーザーAliceとBobが登場する
SharedSpacesサンプルアプリ がベースになっています。このアプリには、一連の部屋(赤、緑、青、紫)があり、それぞれにデスティネーションが設定されています。さらに、このアプリではネットワーキングソリューションとしてPhotonを使っています。
このフローには、デスティネーション、グループプレゼンス、招待、ディープリンクの使い方が示されています。
ユーザーAのAliceがアプリを起動します。
アプリケーションが招待に応じてではなく通常の方法で起動すると、イベントはそのユーザーのグループプレゼンス情報を設定します。
デスティネーションAPI名は、デフォルトのデスティネーション「Lobby」に設定され、マップされます。 Aliceはこのロビーに行きますが、セッションロビーIDがまだ設定されていないので、ランダムなIDが新しく作成されます。この例では「Lobby_123」を使います。マッチセッションIDはクリアされています。 次のステップは、Photonを使用してトランスポート層を確立することです。彼女のロビーセッションID「Lobby_123」と同じ名前のルームがあれば参加し、なければ作成します。この新しい名前は作成されたばかりなので、彼女用に作成されたルームで、彼女が最初にルームにいる人となります。 UE4のレベルで、彼女は自分のPhotonルームのマスタークライアントであるため、彼女は自分のヘッドセット上でUE4サーバーのホスティングを始めます。 Aliceは自分のいるlobby_123にBobを招待します。
Bobはその招待を、ゲーム中あるいはHorizonホームで受け取ります。 Bobが招待を受け入れると、Aliceのグループプレゼンスを含むディープリンクを使ってアプリケーションが起動され、Aliceの現在のデスティネーション「Lobby」、ロビーセッション「Lobby_123」、マッチIDなしの状態で完了します。 その同じデスティネーションを使用するよう、Bobのグループプレゼンスが更新されます。これはロビーに参加する招待なので、BobのロビーIDもAliceのロビーIDと同じになるように更新されます。 Photonレベルで、Bobはまったく同じフローをたどります。Lobby_123というルームがあれば参加し、なければ作成するという操作を試みます。ルームがすでに存在するため、単に通常のクライアントとして参加することになります。 Unreal Engineレベルでは、アプリは彼を通常のクライアントとして(現在のPhotonルームのマスタークライアントである) Aliceに接続します。 以下は、現在進行中のマッチに参加するユーザーの例です。
Bobが青色ルームに入ります。
入った時点で彼のmatch_IDが青色ルームのIDに設定されます。このプライベートルームIDは、アタッチしているロビーに由来し、「BlueRoom_for_lobby_123」のようになります。
青色ルームは、Aliceのロビーlobby_123に関連したプライベートルームです。 特定のロビーにいるユーザーは、それにリンクされているどのプライベートルームにも参加できます。例えば、Bobがこのルームに参加すると、彼のmatch_session_IDにちなんで名付けられたPhotonルームがあればそれに参加し、なければそれが作成されます。 彼がその部屋の最初の人なら、新しいPhotonルームが作成され、彼は現在のマスタークライアントに割り当てられます。マスタークライアントのBobが、自分のヘッドセット上で、対応するUE4サーバーをホストします。BobはUE4サーバーを初期化し、そのサーバーの最初のクライアントとなり、開始位置が確立されます。 Aliceが青色ルームに入ります。
彼女のマッチIDが、青色ルームのID「BlueRoom_for_lobby_123」に設定されます。 現在Bobがホストなので、彼女はBobのサーバーに接続します。(UE4) これでAliceはBobと共存関係になります。 彼らは同じロビーID「lobby_123」と同じマッチID「BlueRoom_for_lobb_123」を共有しています。 以下のプロセスは、アプリのデスティネーションにいるあなたに合流するよう、友達やフォロワーに招待を送信するユースケースを示します。
青ルームで、Aliceが参加者リストを開きます。
彼女とBobは同じチームを代表しています。なぜなら彼らのロビーIDはどちらも同じ「lobby_123」だからです。 Aliceが参加者リストの下のほうにある招待ボタンをクリックすると、招待パネルが表示されます。 次に彼女は、招待パネルからCharlieを選びます。 Charlieは、Meta Questヘッドセットの任意の場所から招待を受け取って、それを受け入れます。
GroupPresenceJoinIntentを受け取ります。これは、その招待に基づいて、デスティネーションAPI名、ロビーID、マッチIDを設定するために使用されます。 それによりNetworkLaunchカスタムイベントが発行されます。これは招待によって開始されたため、「青ルーム」のデスティネーションに関する情報、ロビーlobby_123、マッチBlueRoom_for_lobby_123という情報があるディープリンクメッセージが使用されます。 これはマッチへの招待なので、Charlieのグループプレゼンスは、そのデスティネーションとロビーの情報で更新されます。 しかし、CharlieのロビーセッションIDは変更されません。それまでと同じままか、ロビーセッションIDがまだない場合はランダムなIDが新規で生成されます。したがって彼のロビーセッションは、ボブとアリスが共有したものとは違っています(例えば「Lobby_456」)。 BlueRoom_for_Lobby_123というPhotonルームに接続すると、CharlieにBobがホストであることが知らされます。CharlieがBobに接続します。 AliceとBobとCharlieが青ルームで共存状態になります。 友達やフォロワーをロビーに招待して、一緒にマッチに移動する 次のユースケースでは、ユーザーが自分のロビーに友達やフォロワーを招待し、パーティーを結成した後に、マッチデスティネーションに移動します。
皆で青ルームを出てロビーに戻ります。
彼らのマッチIDがNULLに設定されます。 AliceとBobは共有ロビーID「lobby_123」のAliceのロビーに戻ります。 Charlieは彼自身のロビーID「lobby_456」に一人で戻ります。 Aliceが自分のロビーからCharlieに招待を送ります。彼女は複数のマッチをまたいで一緒に移動し、同じロビーに戻るようにしたいと思っています。
Charlieが招待を受け入れます。 グループプレゼンス情報の設定に使用されるGroupPresenceJoinIntentを受け取ります。
デスティネーションAPI名、ロビーID「lobby_123」、招待ディープリンクメッセージに基づくマッチID。 これにより、BobのグループプレゼンスロビーIDが、AliceのロビーID「lobby_123」に更新されます。 これにより彼はPhotonルームに関連付けられます。 Charlieのグループプレゼンスが更新され、ロビーIDがAliceとBobのものと同じになります。 AliceとBobとCharlieはロビーに同時に存在しており、一緒にマッチに参加した後、同じロビーに戻ることができます。 進行中のマッチに途中参加しようとする、またはユーザーが参加不可のデスティネーションにいる 次のユースケースは、ユーザーが進行中のロビーやセッションに参加しようとしている場合、または参加不可のデスティネーション(メインメニューやオプションメニュー)にいる場合を示しています。
Aliceは、Bobの友達のリストで彼の現在のデスティネーションを表示するグループプレゼンスから、Bobが現在ゲームロビーにいることを知ります Bobのゲーム状態は現在参加不可であるため、彼のグループプレゼンスis_joinableはfalseに設定されています。
Bobのis joinableがfalseに設定されているため、AliceはBobが現在いるデスティネーションでBobに合流することができません。 Bobが、マッチやセッションの進行中でも参加可能なデスティネーションにいる場合、is_joinableはtrueのままになります。
Aliceが参加しようとすると、Bobの現在のデスティネーションについてGroupPresenceJoinIntentを受け取ります
Bobの現在のゲームセッションは一時停止され、Bobやそのほかのパーティーメンバーはロビーに戻されます。 Aliceがルームに参加すると、彼女のロビーIDはボブのロビーIDと同じに設定されます。 AliceはBobとその他ロビーにいるメンバーと共存関係になります。 AliceとBobがグループとして、ゲームやアプリエクスペリエンスを一緒に進行できるようになります。 質問: マルチプレイヤー機能とはどのようなもので、なぜ重要なのですか?
回答: プラットフォームマルチプレイヤーの機能により、場所に関係なくユーザーがほかの人との調整を図り、アプリに招待することができます。アプリの中にいる人、VR内の他の場所にいる人、またはモバイルデバイス上の人が、招待を受けることができます。これらの機能をアプリに統合することで、オーディエンスを広げ、新規ユーザーの参加を促し、マルチプレイヤーの煩わしさを軽減できます。
質問: どうすれば、マルチプレイヤー機能をアプリに統合できますか?
回答: マルチプレイヤー機能をゲームに組み込む方法は、開発者によって異なります。アプリにはそれぞれのニーズがあり、既存コードはさまざまなソリューションを必要とするからです。とはいえ、
上記のセクション に示されているユースケースでは、さまざまなマルチプレイヤー機能、移動、ユーザーのインタラクションに関して共通に見られるシナリオのいくつかが示されています。
注: 現在マルチプレイヤー機能は没入型アプリでのみサポートされており、2Dパネルアプリや標準的なAndroidアプリなど、非没入型環境では利用できません。 質問: 情報量が多いのですが、マルチプレイヤー機能をどんな優先順位で利用すればよいでしょうか?
質問: マルチプレイヤーのテストケースはどのようなもので、なぜ重要なのですか?
回答: マルチプレイヤーのテストケースは、ハッピーパスの招待と参加のフローが開発されたらマルチプレイヤーアプリが取り扱わなければならないエッジケースになります(マルチプレイヤーを実装する際に、それらについて考慮することは非常に重要です)。
「テストケース」セクション にある一般的なシナリオを考慮することにより、ユーザーの煩わしさを軽減できます。