Unetを使用したUnityのローカルマルチプレイヤー

みなさんこんにちは！ 今日は、Unityでローカルマルチプレイヤーを作成する方法の1つについてお話ししたいと思います。 このソリューションは、ショーケース、機能テスト、またはローカルマルチプレイヤーに適しています。 たとえば、プレーヤーが何をしているかを見たいが、追加のリソースを費やしてADBを使用してスクリーンキャストを撮るようにAndroidに伝えたくない場合は、電話で動作するアプリケーションのコピーとしてマシンのサーバーを選択して送信できますプレーヤーのアクションに関する情報があります。





UnetでHLAPIを使用してこれを行う方法を簡単に説明しますが、NetworkingManager経由ではなく、少し低いレベルで説明します。 良い伝統により、そのようなクライアントとサーバーの相互作用の実装例を添付します。 このソリューションのアーキテクチャは価値がなく、将来多くの問題を引き起こすことを完全に理解しているため、例を厳密に判断しないでください。 私の目標は、可能な限り迅速に（週末に）システムを記述し、ネットワークを操作する原則を示すことでした。 また、私が直面しなければならなかった問題を言います。 この実装例では、サーバーもUnityアプリケーションであると想定しています。



インターネットでは、マルチプレイヤーの作り方の最も一般的な例はチャットですが、私はゲームが好きで、チャットをするのは退屈に思えました。 したがって、三目並べの例を使用してマルチプレイヤーを作成する方法を決定することにしました。 ゲームのすべてのロジック、勝者の決定、動きの変更などが書かれていて、サーバーを固定する必要があるとします。 最も簡単な場合、三目並べでは、2つのメッセージを処理する必要があります。 コースの順序の決定（IDの配布）およびセルのキャプチャ。







一般に、この例のゲームは非常に簡単に機能します。 2つのシーンがあります。 ブートとゲームプレイ。 ゲームプレイシーンをロードすると、プレイヤーがプレイするフィールドが生成されます。 勝利条件のチェックがあり、UIの動作、移動の順序、ゲームの全体的なロジックを担当するクラスがありますが、特に興味はありません。 グリッドを担当する主なクラスは、サーバー、クライアント、NetManager、NetMessagesメッセージ用の個別のファイル、およびその中で定義されている列挙型MyMsgTypeです。 Unetツールのラッパーです。 Unetの観点から、使用する主なクラスはNetworkClient、NetworkServer、MessageBase、およびMsgTypeです。 これらのクラスは何ですか？



最も単純なクラスは、MessageBaseとMsgTypeです。 最初のクラスは、クライアントとサーバー間でメッセージを転送するためにすべてのメッセージを継承する必要がある抽象クラスです。 MsgTypeは、Unetに縫い付けられた特定のメッセージセットを処理する定数を格納するクラスです。







NetworkServerは、リモートクライアントとの通信を処理する機能を提供するシングルトンです。 内部では、NetworkServerSimpleのインスタンスを使用し、基本的にその上で便利なラッパーです。 まず、特定のポートでサーバーを起動する必要があります。 これを行うには、 Listen（int serverPort）メソッドを呼び出します。このメソッドはserverPortポートでサーバーを起動します。 （0から1023の範囲のすべてのポートはシステムポートであり、このメソッドのパラメーターとして使用しないでください）



サーバーは正常に動作しており、ポートをリッスンしています。 今、彼はメッセージに応答する必要があります。 これを行うには、 RegisterHandlerメソッド（短いmsgType、Networking.NetworkMessageDelegateハンドラー）を使用してハンドラーを登録します。 このメソッドは、パラメータとしてメッセージタイプとデリゲートを受け入れます。 次に、デリゲートはNetworkMessage入力パラメーターを受け入れる必要があります。 プレーヤーがサーバーに参加し、ゲームプレイシーンの読み込みが開始され、プレーヤーの識別子が聞こえる瞬間が必要だとします。 次に、対応するメッセージのハンドラーを登録するとともに、登録のデリゲートとして渡すメソッドを実装する必要があります。



次のようになります。





これで、ユーザーが接続するたびにOnConnectメソッドが呼び出されます。 この実装では、IDが進行の順序を決定するため、最初の接続でクライアントとサーバーのIDが選択されることを明確にする価値があります。 残りのクライアントは自動的に-1のIDを取得します。これは、このクライアントが観客であることを意味します。



シンプルなサーバーがあります。 今では顧客は邪魔になりません。 これを行うには、NetworkClientクラスを使用します。 サーバーに参加するには、 Connectメソッド（string serverIp、int serverPort）を呼び出すだけです。 ポートとして、サーバーがリッスンするポートを設定し、サーバーとして使用する同じマシンまたはローカルネットワーク上のIPコンピューターでアプリケーションをテストする場合、IPとしてlocalhostを設定します（ネットワーク設定で見つけることができます、またはサーバーとして機能するコンピューターでipconfigコマンドを使用して、コンソールで）。



素晴らしい、私たちは接続できます。 サーバーが識別子を配布すると以前に言われました。 そのため、まず、識別子に関するメッセージを送信し、このメッセージのハンドラーをクライアントに登録する必要があります。 前述のように、すべてのメッセージはMessageBaseから継承する必要があります。 最初に、それらを定義しましょう（別のファイルでこれを行うことを好みます）：





このメッセージを送信するには、クライアントでSendメソッド（短いmsgType、Networking.MessageBase msg）を呼び出します。このメソッドは、msgメッセージ "type" msgTypeをサーバーに送信します。 SendToClient（int connectionId、短いmsgType、Networking.MessageBase msg） 、connectionIdは特定のクライアントのIDです。



別のアプリケーションから送られてきたカスタムメッセージを読むには、 reader.ReadMessage（）を使用します。 例：





原則として、すべて。 さらなる使用は特定です。 ゲームプレイに応じて必要なメッセージを作成し、送信します。 tic-tac-toeでは、ポイントの取得を担当する別のメッセージも特定しました。 プロジェクトの完全な実装については、 こちらをご覧ください 。



私が他に言いたいこと、そして私が時間を費やさなければならなかったことは、あなたがネットワークで仕事をしていないならあなたには明らかでないかもしれないいくつかのことです。



1. TCPおよびUDPを介して通信するために、Unity Editorがファイアウォールによってブロックされていないことを確認します。 ファイアウォールにアクセスして目的のポートを例外に設定しましたが、エディターがブロックされていないことは確認していませんでしたが、これにしばらく時間を費やしました。



2.メッセージで値型またはシリアル化可能な参照型を渡し、MonoBehaviorの相続人も渡しません。 また、この場合の参照型はオブジェクト自体ではなくオブジェクトのコピーを送信するため、それに応じて処理する必要があることを理解することも重要です。



ローカルネットワークと以前から知られているハードウェアについて話している場合、「実際の」マルチプレイヤーの場合には多くの問題は発生しません。 遅延、変動、パケット損失などについて考える必要はほとんどありません。 したがって、このようなソリューションは有用ですが、これらの問題は特定の制限に対するこのようなアプローチで解決できます。 NetworkManager、NetworkBehaviorなどを介したUnetの高レベルの抽象化と比較して、クライアントが異なるシーンなどをロードする必要がある場合、より理解可能で明白な柔軟性を提供しますが、サーバーが使用されているとしましょう、ストリーミングのように、プレーヤーのデバイスに表示されるものを表示し、彼の位置を取得し、彼の側で起こっていることを回して+複製します。 また、ソリューションがより迅速に必要になり、ネットワークを操作できる場合、Unetはトランスポートレベルで書き込む機能を提供します。



私はまた、私の意見ではgithubの決定を明確にしたいと思っています（ツールの観点からではなく、アーキテクチャへのアプローチの観点から）。これは例です。 ゲーム自体のアーキテクチャは言うまでもなく、問題はクライアントとサーバーのロジックが独立していると見なされることです。 クライアント/サーバーアーキテクチャで適切なマルチプレイヤーを実装する場合、ゲームの状態をサーバーに保存してクライアントに複製し、クライアントがサーバー上のゲームの状態を変更するコマンドを送信する方が適切です。 もちろん、これも多くの要因に依存しますが、平均的にはそのようなアプローチです。



ここにソリューションへのリンクを複製します。



ご清聴ありがとうございました！