UNET-Unity 3Dの新しいネットワークテクノロジー

しばらく前に、Unite Asiaカンファレンスで、Unity開発者向けの新しいマルチプレイヤーツール、テクノロジー、サービスの開発を発表しました。 このプロジェクトの内部名はUNETであり、これは単にUnity Networkingを意味します。 しかし、私たちの計画は単純なネットワークをはるかに超えています。 ご存知のとおり、Unityの主な目標は、ゲーム開発プロセスを民主化することです。 Unity Networkingチームは、マルチプレイヤーゲームの開発を民主化したいと考えています。 すべてのゲーム開発者が、あらゆるタイプのマルチプレイヤーゲームを任意の数のプレーヤーで開発できるようにしたいと考えています。 もちろん、これは最も簡単なタスクではありませんが、過去にすべて解決しており、本当にやり直したいと思っています（本当にクールだからです！）。 私たちは、共通の目標をいくつかのフェーズに分割することにしました。これらのフェーズは、Unity開発者になじみがあるはずです。 このアプローチに従って、フェーズ1をリリースし、ユーザーフィードバックを取得し、作業中にそれらを検討して、次のフェーズをさらに改善し、このサイクルを繰り返します。 UNETの場合、フェーズ1はMultiplayer Foundationと呼ばれるものになります。これについては後で説明します。 フェーズ2は、フェーズ1に基づいて構築され、以下の記事でシミュレーションサーバーと呼ばれるサーバー上で承認されたゲームを作成するための技術を提供します。 フェーズ3では、マスターシミュレーションサーバーシステムを使用して複数のシミュレーションサーバーを調整する機能を追加します。 いつものように、特にユーザーからのフィードバックの集まりを考えると、正確なリリース日を指定することは不可能です。 しかし、フェーズ1は5.xリリースサイクルの一部であり、フェーズ2は現在研究段階にあると言えます。



Unityに参加する前は、ネットワークチームのメンバーは主にウルティマオンライン、ロードオブザリングオンライン、ダンジョンズアンドドラゴンズオンライン、マーベルヒーローズ、ニードフォースピードオンライン、ワールドオブウォークラフトなどのMMOを担当していました。 マルチプレイヤーゲーム、テクノロジー、インフラストラクチャの作成には多くの熱意と豊富な経験があります。 Unityの使命は私たち全員に知られており、常に非常に魅力的でした。 マルチプレイヤーの分野でこの夢を実現するなど、本当に素晴らしいことをする機会を拒否することはできませんでした。 そこで私たちは以前の仕事を辞め、Unityに参加してこの夢を実現しました。 誰もがマルチプレイヤーゲームの夢を実現できるように、現在これらのツール、テクノロジー、サービスに一生懸命取り組んでいます。

では、フェーズ1のマルチプレイヤー財団はどういう意味ですか？ 主な部分は次のとおりです。

-すべてのタイプのゲームをサポートする高性能UDPベースのトランスポートプロトコル

-低レベルAPI（低レベルAPI-LLAPI）、ソケットのようなインターフェースを介した完全な制御を提供

-シンプルで安全なクライアント/サーバーモデルを提供する高レベルAPI（HLAPI）

-マッチメーカーサービス。部屋を作成し、プレイヤーがお互いを見つけられるようにする基本的な機能を提供します。

-リレーサーバー、ファイアウォールを介して接続しようとするプレイヤー間の通信の問題を解決

歴史的に確立された制限と壮大な目標を考えると、ゼロから始めなければならないことが明らかになりました。 すべての種類のゲームと任意の数の接続をサポートすることが目標だったため、UDPに基づく新しい高性能トランスポートレイヤーから始めました。 多くのゲームには十分なTCPがありますが、TCPは最後のパケットが順不同で到着すると遅延するため、高速のゲームには依然としてUDPが必要です。

この新しいトランスポート層に基づいて、2つのAPIを構築しました。 高レベルAPI（HLAPI）は、シンプルで安全なクライアントサーバーモデルを提供します。 あなたがネットワークエンジニアではなく、マルチプレイヤーゲームを作りたいだけなら、HLAPIに興味があるでしょう。

また、古いシステムのレビューも考慮しました。一部のユーザーは、より詳細な制御のために低レベルのアクセスを取得したいと考えました。 現在、トランスポート層によりソケットに似たインターフェースを提供する低レベルの低レベルAPI（LLAPI）があります。 ネットワークエンジニアであり、独自のネットワークモデルを構築したり、ネットワークパフォーマンスを微調整したい場合は、LLAPIが役立ちます。

マッチメイカーのマッチメイキングサービスは、マルチプレイヤーゲームでルームを設定し、プレイヤーがお互いを見つけられるようにするために使用されます。 Relay Serverは、プレーヤーが常に相互に接続できるようにします。

私たち自身の経験から、マルチプレイヤーゲームの作成には多くの苦痛が伴うことがわかりました。 Multiplayer Foundationは、マルチプレイヤーゲームを簡単に作成するための、使いやすいプロフェッショナルネットワーキングテクノロジー、ツール、およびインフラストラクチャの新しいセットです。 マルチプレイヤーゲームを作成するには、ネットワークとプロトコルについての十分な知識が必要であると言えます。 苦しいほど急な学習曲線を自分で克服するか、ネットワークエンジニアを探しています。 これを経て、プレイヤーにお互いを検索する手段を提供するという問題を解決する必要があります。 この問題を解決したら、プレーヤーが互いに接続する能力を提供することに対処する必要があります。これは、NATファイアウォールの背後にいる場合は非常に困難です。 これらすべてに対処するには、適切なサイズのインフラストラクチャを作成する必要がありますが、これは特に快適ではなく、ゲーム開発とは関係ありません。 その後、インフラストラクチャを動的にスケーリングすることを検討する必要があります。通常、その正しい実装にはある程度の経験が必要です。

フェーズ1は、これらすべての痛みを伴う問題からあなたを救います。 HLAPIにより、ネットワークテクノロジーを深く理解する必要がなくなります。 ただし、ネットワークエンジニアであり、すべてを独自の方法で実行したい場合は、LLAPIをいつでも利用できます。 仲人は、プレイヤーにお互いを見つける機会を提供することであなたの問題を解決します。 Relay Serverは、プレイヤーに真に相互接続する能力を提供するという問題を解決します。 また、必要なインフラストラクチャの構築とその動的なスケーリングの問題も解決します。 マッチメーカーとリレーサーバーは、Unity Multiplayer Cloudに存在します。 したがって、物理サーバーだけでなく、プロセスも需要に応じてスケーリングされます。

高レベルAPI UNETおよびSyncVar

はじめにと要件

いくつかの背景情報。 ネットワークゲームでは、オブジェクトを所有するサーバーと、これらのオブジェクトのデータが変更されたことを通知する必要があるクライアントを使用することが一般的です。 たとえば、戦闘ゲームでは、プレーヤーの人生はすべてのプレーヤーに見えるはずです。 これには、スクリプトクラスのメンバー変数が必要です。この変数は、サーバー上で変更されるとすべてのクライアントに送信されます。 簡単な戦闘クラスの例を次に示します。

class Combat : MonoBehaviour { public int Health; public bool Alive; public void TakeDamage(int amount) { if (amount >= Health) { Alive = false; Health = 0; } else { Health -= amount; } } } 

サーバー上のプレイヤーがダメージを受けた場合、すべてのプレイヤーにそのプレイヤーの新しいライフ値を通知する必要があります。

単純に思えますが、CPU、メモリ、帯域幅の点で効率的で、開発者が使用したいすべてのタイプをサポートするのに十分な柔軟性を備えたコードを作成する開発者にシステムを見えなくすることが困難です。 したがって、このシステムの具体的な目標は次のとおりです。

1.変数のシャドウコピーを保存しないことにより、メモリ使用量を最小限に抑える

2.実際に変更された状態のみを送信することにより、帯域幅の使用を最小限に抑えます（増分更新）

3.状態が変化したかどうかを常に確認しないことで、CPU使用率を最小限に抑えます

4.開発者にシリアル化関数を手動で作成させることなく、プロトコルとシリアル化の矛盾を最小限に抑える

5.開発者が変数を直接ダーティとしてフラグすることを要求しない

6. Unityがサポートするすべてのプログラミング言語で作業する

7.現在の開発プロセスを中断しないでください

8.開発者がシステムを使用するために必要な手動の手順を入力しないでください

9.メタデータ（カスタム属性）によってシステムをガイドできるようにします

10.単純型と複合型の両方を処理する

11.実行時に反射を使用しないでください。

要件の非常に野心的なリスト！

古いネットワークシステム

既存のUnityネットワークシステムには、OnSerializeNetworkView（）関数を提供して状態の同期を実行する「ReliableDeltaCompressed」タイプの同期があります。 この関数は、NetworkViewコンポーネントを使用してオブジェクトに埋め込まれ、開発者によって書き込まれたシリアル化コードは、提供されたバイトストリームに書き込まれます（または読み込まれます）。 このバイトストリームの内容はエンジンによってキャッシュされ、次回関数が呼び出されると、結果がキャッシュされたバージョンと一致しない場合、オブジェクトはダーティと見なされ、その状態がクライアントに送信されます。 可能なシリアル化関数の例を次に示します。

 void OnSerializeNetworkView (Bitstream stream, NetworkMessageInfo info) { float horizontalInput = 0.0f; if (stream.isWriting) { // Sending horizontalInput = Input.GetAxis ("Horizontal"); stream.Serialize (horizontalInput); } else { // Receiving stream.Serialize (horizontalInput); // ... do something meaningful with the received variable } } 

このアプローチは、上記のリストの要件の一部を満たしますが、すべてではありません。 OnSerializeNetworkView（）はネットワーク経由でデータを送信する頻度でエンジンによって呼び出され、開発者は変数をダーティとしてマークする必要がないため、実行時に自動的に機能します。 アセンブリプロセスに追加の手順を追加したり、現在の開発プロセスを中断したりすることはありません。

しかし、そのパフォーマンスは特に高くありません-特に多くのネットワークオブジェクトがある場合。 比較にはCPU時間を要し、バイトストリームのキャッシュコピーはメモリを使用します。 また、同期する必要がある新しいメンバー変数を追加するときに手動で更新する必要があるため、シリアル化関数の不一致エラーが発生しやすくなります。 メタデータによってガイドされないため、エディターおよびその他のツールは、同期されている変数を見つけることができません。

SyncVarsのコード生成

UNETで新しい状態同期システムに取り組んでいる間、私たちのチームはカスタム属性に基づいてコードを生成するソリューションを考案しました。 ユーザーコードでは、次のようになります。

 using UnityEngine.UNetwork; class Combat : UNetBehaviour { [SyncVar] public int Health; [SyncVar] public bool Alive; } 

この新しいカスタム属性は、HealthおよびAliveインスタンス変数を同期する必要があることをシステムに伝えます。 コードジェネレーターにはカスタム属性からのデータがあるため、開発者はシリアル化関数を記述する必要がありません。これに基づいて、正しい順序と型で優れたシリアル化および逆シリアル化関数を生成できます。 生成された関数は次のようになります。

 public override void UNetSerializeVars(UWriter writer) { writer.WriteInt(Health); writer.WriteBool(Alive); } 

この関数はUNetBehaviour基本クラスの仮想関数を再定義するため、ゲームオブジェクトをシリアル化すると、スクリプト変数は自動的にシリアル化されます。 その後、適切な逆シリアル化機能を使用して、もう一方の端で展開されます。 新しい[SyncVar]変数が追加されると、コードが自動的に更新されるため、不一致は発生しません。

このデータはエディターで使用できるようになったため、インスペクターウィンドウに詳細情報を表示できます。



しかし、このアプローチでは、まだ多くの問題が残っています。 この関数は常に状態全体を送信します。増分ではないため、オブジェクトの1つのメンバーが変更されると、オブジェクト全体の状態が送信されます。 そして、シリアル化関数をいつ呼び出すかをどのようにして知るのでしょうか？ 何も変更されていない場合、状態を送信することはあまり効率的ではありません。

プロパティとダーティフラグでこれを克服しました。 各[SyncVar]変数は、変更時にダーティラベルを配置するプロパティでラップできるのは自然なことです。 このアプローチは部分的に成功しています。 ダーティマークのあるビットマスクの存在により、コードジェネレーターはインクリメンタル更新を実行できました。 生成されたコードは次のようになり始めました。

 public override void UNetSerializeVars(UWriter writer) { Writer.Write(m_DirtyFlags) if (m_DirtyFlags & 0x01) { writer.WriteInt(Health); } if (m_DirtyFlags & 0x02) { writer.WriteBool(Alive); } m_DirtyFlags = 0; } 

これで、シリアル化関数はダーティラベルを使用してマスクを読み取り、ストリームに書き込む必要がある変数のみをシリアル化できます。 帯域幅を効率的に使用し、オブジェクトが汚れているかどうかを確認できます。 ユーザーにとっては、これはまだ完全に自動化されています。 しかし、これらのプロパティはどのように機能しますか？

[SyncVar]インスタンス変数をラップしようとしているとします：

 using UnityEngine.UNetwork; class Combat : UNetBehaviour { [SyncVar] public int Health; // generated property public int HealthSync { get { return Health; } set { m_dirtyFlags |= 0x01; Health = value; } } } 

このようなプロパティはタスクを実行しますが、無効な名前があります。 上記の例のTakeDamage（）関数は、HealthSyncではなくHealthを使用するため、プロパティを無視します。 コード生成が実行される前に存在しないため、ユーザーはHealthSyncプロパティを直接使用することはできません。 最初の段階で自動コードが生成され、2番目の段階でユーザーが自分のコードを更新すると、2段階で実行できますが、これは非常に脆弱です。 このアプローチは、大きなコードを書き直さなければ修正できないコンパイルエラーの影響を受けます。

別のオプションは、開発者が各[SyncVar]変数に対して上記のプロパティを記述することです。 このアプローチは、プログラマに作業を追加し、潜在的にエラーが発生しやすくなります。 ユーザーと生成されたコードのビットマスクは正確に一致する必要があるため、[SyncVar]変数の追加または削除は非常にデリケートなプロセスになります。

モノセシルの紹介

したがって、ラッパープロパティを生成し、存在が疑われない場合でもソースコードにそれらを使用させる必要があります。 幸いなことに、MonoにはCecilというツールがあり、まさにそれを実行します。 Cecilは、ECMA CIL形式でMonoアセンブリをダウンロードし、それらを変更して書き戻すことができます。

この瞬間、すべてが少しおかしくなります。 UNETコードジェネレーターはラッパープロパティを作成し、ソース変数が使用されているコード内のすべての場所を見つけ、これらの変数への参照をラッパープロパティへの参照に置き換えます。 ユーザーコードは、ユーザーの作業を必要とせずに、新しく作成されたプロパティを呼び出すようになりました。

CecilはCILレベルで動作するため、すべての言語が1つの形式にコンパイルされるため、すべての言語のサポートという形で追加の利点があります。

スクリプトでアセンブリに挿入される最終シリアル化用に生成されたCILは、次のようになります。

 IL_0000: ldarg.2 IL_0001: brfalse IL_000d IL_0006: ldarg.0 IL_0007: ldc.i4.m1 IL_0008: stfld uint32 [UnityEngine]UnityEngine.UNetBehaviour::m_DirtyBits IL_000d: nop IL_000e: ldarg.1 IL_000f: ldarg.0 IL_0010: ldfld uint32 [UnityEngine]UnityEngine.UNetBehaviour::m_DirtyBits IL_0015: callvirt instance void [UnityEngine]UnityEngine.UNetwork.UWriter::UWriteUInt32(uint32) IL_001a: ldarg.0 IL_001b: ldfld uint32 [UnityEngine]UnityEngine.UNetBehaviour::m_DirtyBits IL_0020: ldc.i4 1 IL_0025: and IL_0026: brfalse IL_0037 IL_002b: ldarg.1 IL_002c: ldarg.0 IL_002d: ldfld valuetype Buf/BufType Powerup::mbuf IL_0032: callvirt instance void [mscorlib]System.IO.BinaryWriter::Write(int32) IL_0037: nop IL_0038: ldarg.0 IL_0039: ldc.i4.0 IL_003a: stfld uint32 [UnityEngine]UnityEngine.UNetBehaviour::m_DirtyBits IL_003f: ret 

幸いなことに、ILSpyはCILをC＃に、またはその逆に変換できるため、生成されたCILをC＃として見ることができます。 ILSpyは、優れたMono / .Netビルドツールです。 C＃は次のようになります。

 public override void UNetSerializeVars(UWriter writer, bool forceAll) { if (forceAll) { this.m_DirtyBits = 4294967295u; } writer.UWriteUInt32(this.m_DirtyBits); if ((this.m_DirtyBits & 1u) != 0u) { writer.Write((int)this.mbuf); } this.m_DirtyBits = 0u; } 

これが要件を満たす方法を見てみましょう。

1.変数のシャドウコピーなし

2.増分更新

3.ステータス変更チェックなし

4.手書きのシリアル化機能はありません

5.直接のダーティコールなし

6. Unityがサポートするすべてのプログラミング言語で動作します

7.使い慣れた開発プロセスには影響しません

8.開発者による手作業は必要ありません

9.メタデータに基づく

10.すべてのタイプで動作（新しいUWriter / UReaderシリアライザーを使用）

11.実行時に反射を使用しません

すべて完了したようです。 システムは効率的で開発者に優しいものになります。 Unityでのマルチプレイヤーゲームの開発が誰にとっても簡単になると信じたい。

また、Cecilを使用してRPC呼び出しを実装し、リフレクションを使用して名前で関数を検索しないようにします。 これについては、今後の記事で説明します。

低レベルLLAPIおよびUNETトランスポート層

Unityの新しいネットワークライブラリの設計に着手し、理想的なライブラリがどのように見えるかを理解したいと考えました。 （大まかに言って）2種類のユーザーがいることがわかりました。

1.ネットワークツールを使用して、最小限の労力で理想的な結果をすぐに使用できるようにする（理想的にはまったく労力をかけない）ユーザー。

2.ネットワーク指向のゲームを開発し、非常に柔軟で強力なツールが必要なユーザー。

これらの2つのタイプに基づいて、ネットワークライブラリを2つの異なる部分に分割しました。高レベルHLAPI（高レベルAPI）と低レベルLLAPI（低レベルAPI）です。

このパートでは、次の原則に基づいた低レベルAPIとライブラリの構造について説明します。

パフォーマンス、生産性、生産性

LLAPIはUDPソケットの上にある薄い層です。ほとんどの作業は別のストリームで行われます（したがって、LLAPIはメインストリームのみを使用するように構成できます）。 動的なメモリ割り当てや重度の同期はありません（ライブラリのほとんどは、少数のアトミックなインクリメント/デクリメント操作でメモリバリア同期に基づく同期を使用します）。

C＃で何かできる場合は、それをしなければなりません

ユーザーに本当に必要なものだけにアクセスを許可することにしました。 BSDソケットと同様に、LLAPIは1つの抽象化（生のバイナリメッセージング）のみをサポートします。 tcpのようなストリーム、シリアライザー、またはRPC呼び出しはなく、低レベルのメッセージのみがあります。

柔軟性とカスタマイズ性？ はい、お願いします...

TCPでのソケットの実装を見ると、変更可能な多くのパラメーター（タイムアウト、バッファー長など）が表示されます。 同様のアプローチを選択し、ユーザーがライブラリのほとんどすべてのパラメーターを変更して、ニーズに合わせて調整できるようにしました。 シンプルかフレキシブルかの選択に直面して、私たちは柔軟性を選びました。

シンプルさと快適さ

できる限りBSDソケットAPIに似たLLAPIを設計しようとしました。

ネットワーク層とトランスポート層

論理的には、低レベルUNETライブラリは、「ネットワーク」層と「トランスポート」層を含むUDP上に構築されたネットワークプロトコルのセットです。 ネットワーク層は、ノード間の接続、パケットの配信、および可能なフローと輻輳の制御に使用されます。 トランスポート層は、さまざまな通信チャネルに属する「メッセージ」で機能します。



チャネルには2つの目的があります。メッセージを論理的に分離し、異なる配信保証とサービス品質（配信許可またはサービス品質）を提供できます。

チャネルチューニングはチューニング手順の一部であり、今後の記事で取り上げます。 とりあえず、「私のシステムには最大10個の接続が含まれ、各接続には5つのチャンネルがあり、チャンネル0にはこのタイプがあり、チャンネル1には異なるタイプがあります」というようになります。 文の最後の部分は次のように定義されます：



2番目のパラメーターはチャネル番号、最後はチャネルのタイプまたはチャネルのサービス品質（配信許可）です。

（現時点では）UNETは次のQOSをサポートしています。

-信頼性の低い：UDPパケットと同様に、ネットワークの問題または内部バッファのオーバーフローにより失われる可能性のある信頼性の低いメッセージ。 例：短いログエントリ。

-UnreliableFragmented：最大パケット長は変更されませんが、「大きな」メッセージを送信したい場合があります。 このタイプのチャネルは、送信前にメッセージをフラグメントに解析し、受信する前に収集します。 このような質の高いサービスは信頼できないため、配信は保証されません。 例：長い雑誌。

-UnreliableSequenced：チャネルは配信順序を提供しますが、このサービス品質は信頼できないため、メッセージが失われる可能性があります。 例：音声、ビデオ。

-信頼性：チャネルは配信（または切断）を保証しますが、順序は保証しません。 例：損傷の転送。

-ReliableFragmented： UnreliableFragmentedと同じですが、それに加えて配信を保証します。 例：グループ損害。

-ReliableSequenced： UnreliableSequencedと同じですが、さらに配信を保証します。 このQOSはTCPストリームに似ています。 例：ファイルとパッチの転送。

-StateUpdate：信頼できないチャネルタイプ。受信/送信より古いパケットを強制的にドロップします。 送信中にバッファに複数のメッセージが含まれる場合、最新のメッセージのみが送信されます。 読み取り中に受信者のバッファに複数のメッセージが含まれている場合、最新のメッセージのみが配信されます。 例：ロケーション転送。

-AllCostDelivery： Reliableに非常に似ていますが、違いがあります。 信頼できるチャネルは、動的に決定される往復時間値（RTT）に基づいてメッセージを再送信しますが、AllCostDeliveryは一定の期間（設定で指定）後にメッセージを自動的に転送します。 これは、小さいながらも重要なメッセージに役立ちます。「プレーヤーAの頭を打ちました」または「ミニゲームが始まります。」 例：弾丸が飛び散るようなゲームイベント。

典型的なLLAPI関数呼び出しを見てみましょう：

1.ライブラリの初期化



2.ネットワークのセットアップ：トポロジ、チャネル数、タイプ、さまざまなタイムアウト、バッファサイズ（これについては他の記事で説明します）。

3.ソケットの作成



この関数は、すべてのネットワークインターフェイスでポート5000のソケットを開き、ソケットの説明として整数値を返します

4.別のノードへの接続



この関数は、接続要求を127.0.0.1/6000の別のノードに送信します。 このノードへの接続の説明として整数値を返します。 接続が確立されると接続イベントを、接続が確立できない場合は中断イベントを受け取ります。

5.メッセージを送信する



最後の関数は、チャネル1を使用してconnectionIdノードを記述するためにhostIdに記述されたソケットを介してバッファに含まれるバイナリデータを送信します（この場合は「信頼できるチャネル」であるため、メッセージ配信が保証されます）

6.ネットワークイベントの受信

ネットワークイベントを受信するには、調査モデルを選択します。 ユーザーはUTransport.Receive（）関数をポーリングして、ネットワークイベントの通知を受信する必要があります。 このモデルは、タイムアウトがゼロの通常のselect（）呼び出しに非常に似ていることに注意してください。 この関数は4つの異なるイベントを受け取ります。

UNETEventType.kConnectEvent-誰かがあなたに接続しているか、接続が正常に確立されており、UTransport.Connect（）によって簡略化されています

UNETEventType.kDisconnectEvent-誰かがあなたから切断するか、エラーコードが報告する何らかの理由でUTransport.Connect（）によって要求された接続を確立できません。

UNETEventType.kDatatEvent-新しいデータを受信しました

UNETEventType.kNothing-興味深いことは何も起こりませんでした



7.切断するリクエストを送信する

この関数呼び出しは、connectionIdから切断する要求をhostIdでホストに送信します。 接続はすぐに閉じられ、将来再利用される可能性があります。

注釈

1.この記事は、英語のブログUnityの3つのエントリで構成されています。

UNETの発表-新しいUnityマルチプレイヤーテクノロジー
UNET SyncVar
Unityネットワークトランスポートレイヤーについて

2.写真形式のソースコードの例は、英語のオリジナル記事にありました。