ゲームロビーのサンプル#

このサンプル は、Lobby パッケージと Relay パッケージを使用して典型的なゲームロビー体験を作成する方法を示しています。また、Vivox の音声チャットも含んでいます。プレイヤーは、他のプレイヤーが Public ロビーリストまたはロビーコードを使用して参加できるロビーをホストし、Relay に接続してプレイヤー間の基本的なリアルタイム通信に Unity Transport ("UTP") を使用することができます。また、Relay により、プレイヤー同士が接続の匿名性を保ちながら安全に通信できるようになります。ロビーに接続すると Vivox にも接続され、オーディオ入力デバイスが利用可能であれば音声チャットが有効になります。

機能#

• Auth による匿名ログイン: 永続化されたアカウントを使用せずにプレイヤーの認証情報を追跡します。
• ロビーの作成: プレイヤーが、他のプレイヤーが参加できるロビーをホストします。
• ロビーのクエリ: フィルターを使ってロビーリストを検索したり、ロビーコードを使用したりできます。
• Relay による難読化: ロビー内のプレイヤーを匿名 IP を通じて接続します。
• UTP 通信: プレイヤーが、ロビーのメンバーに基本データをリアルタイムで送信します。
• Lobby と Relay による接続管理: これらのサービスが連携して、新規接続や切断を自動的に処理します。
• Vivox による音声: ロビーに対してユーザーごとの音量コントロールやミュート機能を備えた音声チャンネルを作成して、音声通信を可能にします。

以下のビデオは、Lobby と Relay を使用してグローバルなマッチメイキングを設定する方法を説明しています:

サービス組織の設定#

Unity のマルチプレイヤーサービスを使用するには、プロジェクト用のクラウド組織 ID が必要です。まだ持っていない場合は、新しく組織を作るにはどうすればいいですか？ の記事に従ってクラウド組織を設定してください。

ID を用意したら、それを Edit (編集) > Project Settings (プロジェクト設定) > Services (サービス) でプロジェクトにリンクし、Unity Dashboard を使用してプロジェクトのサービスを管理します。

サービスの概要#

Lobby#

Lobby サービスにより、開発者はロビーを作成して、リアルタイムのネットワーク接続が確立される前にプレイヤー間でデータを共有できます。Relay などの他のサービスにユーザーを接続する際の最初のステップが簡素化され、プレイヤーが他のロビーを見つけるためのツールが提供されます。

この Lobby のドキュメント には、コードサンプルや、サービスに関する追加情報が含まれています。Lobby の使用に関する包括的な詳細や追加のコードサンプルが含まれており、ゲームロビーのサンプルをより深く理解するのに役立つ可能性があります。

Lobby サービスは Unity Dashboard で管理できます: https://dashboard.unity3d.com/lobby

Relay#

Relay サービスは、難読化されたホスト IP を使用して、ホストクライアントモデルでプレイヤーを接続します。これにより、Relay 自体と個人情報を共有するだけで、プレイヤー同士が直接接続しているかのように見えるネットワーク体験をホストできます。

Relay のドキュメント には、コードサンプルや、サービスに関する追加情報が含まれています。Relay の使用に関する包括的な詳細や追加のコードサンプルが含まれており、ゲームロビーのサンプルをより深く理解するのに役立つ可能性があります。

Relay サービスは Unity Dashboard で管理できます: https://dashboard.unity3d.com/relay

このサンプルでは、ロビーに接続されたプレイヤーが、UTP を介したリアルタイムのデータ転送を設定するために Relay を通じて接続されます。Lobby と Relay は、いずれも認証情報に Auth を使用します。このサンプルでは、Auth の匿名ログイン機能を使用して各プレイヤーに一意の半永久的な認証情報を作成しますが、開発者がプレイヤーのための永続化されたアカウントを保持する必要はありません。

Vivox#

Vivox サービスは、アプリケーション内コミュニケーションのための音声およびテキストチャットルームをプレイヤーに提供します。また、空間オーディオや、チャットのトランスクリプションなどの便利な機能もサポートしています。

Vivox の開発者向けドキュメントには、コードサンプルのほか、Vivox の使用に関する包括的な詳細も含まれており、ゲームロビーのサンプルをより深く理解するのに役立つ可能性があります: https://docs.vivox.com/v5/general/unity/5_15_0/en-us/Default.htm

アプリケーションの Vivox サービスは Unity Dashboard で管理できます: https://dashboard.unity3d.com/vivox

設定#

Unity Dashboard の Lobby セクションと Relay セクションには、それぞれ独自の設定手順が含まれています。About & Support (概要とサポート) > Get Started (始める) を選択し、表示されるステップに従って、これらのサービスをプロジェクトに組み込んでください。

これらのサービスが設定され、プロジェクトがクラウド組織にリンクされたら、エディターで mainScene シーンを開いてゲームロビーのサンプルの使用を開始します。

サンプルの実行#

サンプルの全機能のデモを行うためには、2 人の “プレイヤー” が必要になります。スタンドアロンビルドを作成して、再生モードのエディターと一緒に実行します。Auth はマシンのレジストリを使用して匿名の認証情報を作成しますが、エディターとビルドは異なるレジストリエントリーを作成するため、異なる認証情報を持ちます。

Lobby の Join (参加) メニュー#

Lobby の Join (参加) メニューには、プレイヤーが Public ロビーリストまたはロビーコードを使用して互いにつながるためのハブとして機能する、ロビーリスト UI が含まれています。

A.Public ロビーリスト: Private に設定されていないすべてのロビーが表示されます。ロビーには、可視性を Public および非 Public に設定できる、開発者が定義したデータが含まれます。Lobby サービスは “ゾンビ” ルームをすべてクリーンアップして、このリストに表示されないようにします。このサンプルでは、ロビーの名前とプレイヤー数が表示され、“インゲーム” 状態のロビーは表示されません。ロビーを選択してから、Join (参加) を選択できます。

B.更新アイコン: ロビーリストを更新します。Lobby サービスでは、スパムを防ぐために、すべての API リクエストにレート制限が適用されます。レート制限以内に更新を試みても、何も起こりません (約 1.5 秒ごと、詳細については レート制限 を参照してください)。

C.フィルター: 特定の色のサーバーのみを表示するようにロビーリストを設定します。Lobby サービスでは、可視性が Public に設定されたデータを使用して、クエリをフィルターできます。このサンプルでは、プレイヤーは必要に応じて、ホストがロビーに対して設定した色を使用してフィルターできます。

D.Quick Join ボタン: リスト内の、フィルターに一致する最初の利用可能なロビーに参加します。

E.ロビーコードフィールド: 既存のロビーのロビーコードを入力します。Public ロビーリストに加えて、すべてのロビーに、そのコードを使用して参加することができます。プレイヤーはこれを使用して、ロビーへのアクセスを非公開に共有できます。

F.ロビーパスワードフィールド: パスワード設定があるロビーに参加するために、ロビーのパスワードを入力します。

G.Join (参加): Public ロビーリストの選択またはロビーコードによって、参加をリクエストします。プレイヤーがこのボタンを繰り返し押した場合、失敗したリクエストもスパムを防ぐためにレート制限されます。

H.Create (作成): 新しいロビーを作成できます。プレイヤーはロビー名と、Private ロビーを作成するかどうかを選択し、新しいロビーにホストとして接続します。

I.プレイヤー名: プレイヤー名を表示し、名前を変更できます。デフォルトでは、プレイヤーは匿名の Auth 認証情報に基づいて名前を割り当てられますが、認証情報に従って名前が変更されるため、すべてのプレイヤーに新しい名前が表示されます。

Lobby ビュー#

Lobby ビューの UI には、ロビー内のすべてのプレイヤーに関する Lobby と Relay からの情報が表示されます。新しいプレイヤーが参加すると、すぐにホストへの接続が開始され、その後、エモートと状態の変更が他のロビーメンバーと同期されます。

A.ロビー名: ロビーの作成時に設定され、変更はできません。

B.ロビーコード: Lobby サービスによって生成される共有可能なコード。このロビーへの参加を許可するために外部で他のプレイヤーに提供できます。

C.ロビーユーザー: ロビー内のプレイヤー。プレイヤーの名前、状態、エモートが表示されます。このデータは Relay と UTP を通じて同期されるため、プレイヤーが行った変更は接続しているすべてのプレイヤーに即時に表示されます。入ってくるプレイヤーには、接続した時点で現在のデータが送信されます。

D.エモート:  プレイヤーのエモートと、ユーザーがマイクを接続している場合は音声チャット用のコントロールが表示されます。

E.Vivox の音声コントロール: オーディオアイコンをクリックすると、そのユーザーがミュート/ミュート解除されます。

F.Relay IP: Relay によって生成される匿名サーバー IP。これはプレイヤーに表示する必要はなく、単に Relay が機能していることを示す目的でここに表示されます。

G.Relay コード: Relay の接続中に使用される、Relay によって生成される内部的な参加コード。これはプレイヤーに表示する必要はなく、単に Relay が機能していることを示す目的でここに表示されます。

H.エモートアイコン: プレイヤーのエモートを設定し、UTP を使用して同期されます。

I.ロビーの色: (ホストのみ) ロビーリスト内でフィルタリングするためのロビーの色を設定します。これは Lobby を通じて同期されますが、Lobby のクエリはレート制限されているため、変更は即時にはすべてのプレイヤーに表示されません。レート制限 を参照してください。

J.Ready (準備完了): プレイヤーに準備完了状態を設定します。すべてのプレイヤーが準備完了になると、ホストは “インゲーム” 状態へのカウントダウンを開始し、ロビーは Public ロビーリストに表示されなくなります。

アーキテクチャ#

ゲームロビーのサンプルは、マルチプレイヤーのロビーのバーティカルスライスとして設計されているため、ゲームの本番制作全体で必要とされる可能性がある追加のインフラストラクチャや、複数のサービスを連携させるためのコンポーネントも備えています。そのため、ニーズによっては、コードベースのすべてが関係するとは限りません。ほとんどのコンテンツは自己文書化されていますが、いくつかの大まかなポイントを以下に示します。

• Auth、Lobby、および Relay サービスを使用するためのロジックは、それぞれ独自のディレクトリにカプセル化されています。API の使用法の多くは、便宜上抽象化されています。

  • 例えば、LobbyAPIInterface には Lobby API の実際の呼び出しが含まれていますが、LobbyAsyncRequests にはそれらの呼び出しの結果に対する追加の処理と、API 呼び出しのタイミングを適切に設定するために必要ないくつかの構造体が含まれています。
  • また、Relay ディレクトリには、機能するためにトランスポートが必要なため、Unity Transport (UTP) を使用するためのロジックが含まれています。

• Game ディレクトリには、ゲームの単純なフレームワークを表す、サンプル自体を実行するためのコアとなる “グルー” クラスが含まれています。

  • GameManager は、サンプルを実行するためのすべてのコアロジックを含んでいます。サービスと UI を設定し、ゲームの状態を管理し、他のコンポーネントからのメッセージを処理します。
  • ここには、サンプルの複数のコンポーネントの状態を管理し、Lobby と Relay のデータに対するサンプルのニーズとそのデータの構造体の間をサービス内でリモートで橋渡しするために、他にもさまざまなクラスが存在します。

• Infrastructure ディレクトリには、全体的な機能に関連するがどのサービスにも特化していない、重要なタスクに使用されるクラスが含まれています。

  • Locator は、サービスロケーターパターンを模倣しており、シングルトンになる可能性がある動作を容易にスワップイン/アウトできるようにします。
  • Messenger は、無関係なクラスを分離しておき、代わりに、興味深い出来事が発生したときに任意のリスナーに対してメッセージが送信されるようにするためのシンプルなメッセージングシステムを作成します。例えば、ロビーが更新されたときや、プレイヤーがリレーから切断したときなどです。
  • Observer パターンは、すべての UI 要素と、リモートの Lobby および Relay のデータのローカルコピーに使用されます。Observer は監視しているデータが変更されるたびにアラートを受け取り、そのデータの所有者は誰が監視しているかを知る必要がありません。

• UI ディレクトリには、サンプルの UI と、関連するデータの監視のためのロジックが厳密に含まれています。これらのファイルは Observer パターンの使用方法を示していますが、これらを見ることは、サービス自体の使用方法を理解するために必要ではありません。

  • ObserverBehaviour を実装しただけのクラスを含むファイルがいくつか存在します。これは、Unity では MonoBehaviour が同じ名前のファイル内に存在している必要があるためです。
  • UI の多くは CanvasGroup のアルファによって可視性を設定されるため、一部の動作はプレイヤーには見えなくても実行され続けることに注意してください。

• コア動作とコードの一部のエッジケースのデモンストレーションを行うための複数の Tests ディレクトリが含まれています。特に、Lobby と Relay の再生モードのテストを使用すると、サービスへの接続が正しく機能していることを確認できます。

• エディターでは、サンプル開発中に変更を加える際に便利なように、プロジェクトアセットがネスト状のプレハブに分割されています。それらの詳細は重要ではありませんが、シリアル化されたイベントハンドラーに依存する UI 要素があります。

考慮事項#

ゲームロビーのサンプルは単なる Lobby サービスと Relay サービスの最小限の実装以上のものを表していますが、包括的ではなく、より迅速または判読性の高い開発のためにいくつかの設計上の決定が行われています。

• Lobby と Relay を使用するすべての操作は、非同期 API 呼び出しに依存しています。サンプルコードには、任意のタイミングで結果を受信することで発生する可能性のある問題を処理するためのロジックがいくつか含まれていますが、設定およびクリーンアップ時にユーザーが開始する呼び出しをエンキューするためのロジックは含まれていません。ロビーに出入りする際に急速な操作を行うと、予期しない動作が発生する可能性があります。

• Relay はホスト移行をサポートしていませんが、Lobby はサポートしています。ロビーのホストが切断された場合、Lobby が切断を検出するまで、クライアントにはロビーが動作し続けているように見える場合があります。実際には、データがすぐに同期しなくなる可能性があるケースでは、ホストとクライアントの間に追加の定期的なハンドシェイクを実装することをお勧めします。

• このサンプルでは、接続を維持するために Lobby と Relay に heartbeat ping を設定しますが、ロビーの継続時間には何の制限も適用されません。実際の使用では、最大ゲーム時間などの最大継続時間を設定することを検討してください。

• HTTP エラーがコンソールに表示されます。これらは、さまざまな理由で Lobby および Relay の API 呼び出しから返されます。一般的に、これらはサンプルの実行には影響しませんが、サンプルではこれらのエラーが発生したときの説明 UI が提供されないため、プレイヤーにとって予期しない動作が発生する可能性があります。

  • 404 (“見つかりません”) エラー は、Lobby サービスが複数の着信 API 呼び出しを任意の順序で処理するとき (通常はロビーから退出するとき) に発生する可能性があります。また、無効なロビー (削除済みだが更新前にロビーリストにまだ表示されているロビーなど) への参加を試みた場合にも発生します。

  • 429 (“リクエストが多すぎます”) エラー は、レート制限されている操作が速すぎるペースで行われた場合に発生します。特に、ロビーリストを速すぎるペースで更新すると、QueryLobbiesAsync の呼び出しから 429 エラーが返されます。詳細については、Lobby のドキュメントを参照してください。

  • 401 (“未承認”) エラー は、Auth のサインインが完了する前にユーザーがロビーメニューに入った場合に発生します。これは、Lobby と Relay のすべての操作に Auth の認証情報が必要なためです。

  • 409 (“競合”) エラー は、プレイヤーが別のプレイヤーと同じ認証情報を使用してロビーに参加しようとした場合に発生します。特に、これは複数のスタンドアロンビルドをテストしようとした場合に発生します。それらはマシン上で同じレジストリエントリーを共有しているためです。1 つのマシン上で 3 人以上のプレイヤーのテストを行うには、以下のようにします。

    • オリジナルのアセットとパッケージへのシンボリックリンクを持つ複製プロジェクトを作成して、同じアセットを使用するようにします。プロジェクト設定もコピーしますが、それらをオリジナルにリンクしないでください。シンボリックリンクを作成するためのプロセスは、OS によって異なることに注意してください。
    • このプロジェクトを 2 つめのエディターで開きます。
    • Edit (編集) > Project Settings (プロジェクト設定) > Player (プレイヤー) で、Product Name (製品名) を変更します。これにより、複製プロジェクトは新しいレジストリエントリーを持つことになるため、Auth によって新しい認証情報が割り当てられます。
    • サンプルを再生モードまたはスタンドアロンビルドで実行すると、オリジナルとは異なるデフォルトのプレイヤー名が割り当てられることを確認します。これは、Auth 認証情報が異なり、409 エラーが発生しなくなることを示します。