Unreal Engine 4のネットワーク最適化

少し前、vkの公式UE4グループで、コミュニティがどのトピックに興味があるかを尋ねました:)最も人気のあるクエリの1つは、エンジン上のネットワークでの作業でした。

初めは、このトピックを何らかの形で明らかにしたり言及したりするつもりはありませんでしたが、自分やチームにとっても「ベストプラクティス」を設計するのは良いことだと思いました。

ですから、 Armored Warfare：Assaultのネットワークを作成した方法に興味があるなら、catへようこそ。

---

エンジンのすべてのバージョンを通過するライトモチーフであるUnreal Tournamentから分離されたUnreal Engineを想像することはできません。 その結果、UE4の強みの1つは、基本レベルでエンジンに統合された強力なネットワークツールキットです。 私の個人的な評価では、同じレベルの質問について同様に綿密なエンジンはQuake 3エンジンだけです。

高品質のテクノロジーの存在は、開発において考える必要性を私たちから奪いません。 残念ながら、ネットワークの組織に対する無責任な態度が悲惨な結果をもたらした多くのプロジェクトを見てきました。

この記事は決して「初心者向けガイド」または「仕組みの詳細な説明」ではありません。 いいえ、これは、ネットワークを効果的に最適化できる原理の特定の誇張されたビューです。

仕組み

UE4でマルチプレーヤーでの作業を開始するには、使用可能な3つの通信パスを理解する必要があります。

• 変数の複製：サーバーからクライアントへ、そうでない場合。 どのような状況でもクライアントは変数を変更して、サーバー上の値を変更することはできません。
• RPC：サーバーからクライアントへ。
• RPC：クライアントからサーバーへ。

3番目の方法は、クライアントからサーバーにデータを報告する唯一の方法です。 変数複製（最初のパス）は、サーバーとクライアント間でセクターの状態を同期するために使用されます。 サーバーからクライアントへのRPCの送信（2番目の方法）は、特定のデータを送信するためのイベントモデルです。

つまり、このように機能します。 複製された各セクターにはNetUpdateFrequencyパラメーターがあります。このパラメーターは、「ネットワーク上で何を交換するか」について、セクターが1秒間に何回ステータスをチェックするかを設定します。 デフォルトでは、このパラメーターは非常識な100.fです。つまり 、 セクターがレプリケートされる場合、データの同期と送信の試行はすべてティックになります。

結果は明白で悲しいものです。パケットでネットワークを接続することは基本的なタスクになります。 サーバーのCPUの負荷が増加します。 一見シンプルなプロジェクトでも同じ精神で、すべてが遅れ、「何も機能しない」、「キャラクターがテレポートされる」、「他のプレイヤーが震えている」などです。

したがって、最初のルールに到達します。 複製されたすべてのセクターに適切なNetUpdateFrequencyを設定します。

「適切」とは、いつものように未解決の質問です。 筋金入りの地震のような射手にとって、キャラクターに関係するすべてのもの-彼の動きと武器-は、最大周波数と同期されるべきです。 しかし、これは特定のケースであり、そのようなプロジェクトに取り組んでいる場合、十分な「基本的な」知識とアプローチはありません。高品質の製品を入手したい場合は、さらに掘り下げてください。

特定の「平均的な」ケース-アーケード、MOBA、モバイル玩具、およびタンクなどの「スローシューター」では、ネットワーク更新の頻度をはるかに低くすることができます。 AW：Assaultでは、戦車のリフレッシュレートを1秒間に10回使用します。 また、メインキャラクターのネットワーク更新の頻度に基づいて動作するプロジェクトを1秒間に6〜8回知っています。

その他のオブジェクト-さまざまな「キャプチャポイント」、「フラグ」、「カートリッジ」、「ゲームの状態」-更新頻度はさらに低くなります。 良い例：デフォルトでは、PlayerStateエンジンクラスは1秒間に1回だけ複製されます。 セクタの状態の突然の変更が可能な限り迅速に配信される必要がある場合、 ForceNetUpdate（）を呼び出す機会が常にあります。

セクターのコンポーネントはネットワーク更新の頻度を継承するため、1つのセクターを更新頻度の異なる部分に「分割」することはすぐに思い浮かぶことに注意してください。タスクは簡単ではありません。 より正確に言えば、一部のコンポーネントが全体として生活できるセクターとは異なる周波数を必要とする場合、慎重に別のエンティティにカットする必要があります。 コンポーネントが所有者より「遅い」ネットワーク上に存在できる場合、所有者はすべてのティックを更新するわけではありません-これは正常な状態です。

ルール2： 信頼できるRPCは真剣に正当化される必要があります 。 私たちの部署では、信頼できるすべてのrpc機能が「署名」によってヘッドの発行されるというジョークを持っています。 すべてのジョークにはジョークがあります。

それは高価であることを心に留めておく必要があります。 とても。 RPC自体のオーバーヘッドは、考えられる結果ほど大きくありません。 ニトログリセリンのボトルと同様に慎重に取り扱ってください。 特にマルチキャストの場合。 「テレポート」を停止した後に起こる可能性のある最悪の事態は、信頼できるバッファなどのオーバーフローが原因でサーバーからクライアントを切断することです。 このようなイベントに基づいて構築されたネットワークアーキテクチャは、pingおよびパケット損失に対して過敏になります。

簡単な例：アクションに関する通知をサーバーからクライアントに送信したい場合。 アルコールシミュレーターをオンラインで作成し、キャラクター内の各キャラクターが肝臓を再生するとします。肝臓は別個のコンポーネントとして存在します。 すべてのクライアントは、「治療」の各ステップを画面上に美しく表示するために本当に必要です（マルチキャスト、信頼できる）。 送信する各ティックはRPC LiverHealed（float HealedHeath）です。 2つのクライアントのエディターでのテスト：美しさ、誰もが幸せです。 そして今、生活状況：クライアントが足を踏み入れ、パケット損失、0.5秒以上蓄積したすべてのRPCを送信する必要があり、患者がサーバーから喜んでクラッシュする方法を発見します。

明らかに、少なくともサーバーのティックごとにRPCを送信する必要はありません。NetUpdateFrequencyが数倍少ない場合は、単にキューを杭打ちします。 これらの値を蓄積し、送信頻度を減らす必要があります。 そして、これが信頼できるデータであるかどうかをもう一度考えてください。そうである場合は、変数を複製せずに行うことができ、そうでない場合は、信頼できないデータにします。 多くの場合、クライアントがゲームの世界に関するデータに基づいてイベントが発生したかどうかをクライアント自身が計算できるかどうかを検討する価値もあります（キャラクターの肝臓の同じ扱いは、クライアントのダニの健康の変化です）。

概念的なトラップ

または、言及する価値のあるいくつかのこと。

• 変数-複製されたUObjectが無効化された場合-OnRepは呼び出されず、今後クライアントで呼び出されなくなります。 バグのように聞こえますが、正直に言って、なぜそのように機能するのか覚えていません。 これについて知って、開発中に考慮するだけで十分です。 UE 4.18の総合テストをチェックしました。すべてが正常に機能するため、情報は関係ありません。
• サーバー上でクライアントRPCを呼び出しても、サーバー上で機能自体は実行されません。クライアント上で実行するコマンドを送信するだけです。 サーバーで実行する必要がある場合は、実装を手動で呼び出す必要があります。
• ネットワーク上でectorがめったに更新されない場合（たとえば、PlayerState）、注意して2回信頼性の高いRPCを使用してください。 同期と同期の間、考えなくても簡単にバッファを埋めることができます。 理想的には、このような特別なネットワーククラスは、ネットワーク上で1次の頻度でチェックおよび更新される必要があります。

ネットワークのトリックとトリック

これらは、ネットワークの負荷を最適化することと、CPUの負荷を最適化することの両方を目的としています。

グローバルな状態

ところで、3番目のルール： セクターを複製せずにできる場合は、それを行います 。

AWからの2つの例：アサルト。このルールを実装しますが、方法は異なります。

• 破壊可能な木。 これらはゲームプレイにとって重要ではないため、単純に複製されません。 各クライアントは、利用可能なデータに基づいて、独自のツリーを削除します。 この点で世界の実際の状況がサーバー、クライアント間、クライアント間で異なることはまったく怖くないです。
• 環境の破壊可能なオブジェクト。 フェンス、車、障壁。 それらはゲームプレイに直接影響し、オブジェクトが破壊されるまでそれらの背後に「隠す」ことができます。 したがって、すべてのクライアント上のこれらのオブジェクトが実際の状況を反映している必要があります。 同期には、これと同じグローバル状態が使用されます。

2番目の例では、概念全体を次のように説明できます。

/** Array of bit masks for minimization of space used for destructible actors states. Replication handled by OnRep_DestructableMasks method */ UPROPERTY(ReplicatedUsing=OnRep_DestructableMasks) TArray<int32> DestructedActorsMasks; /** Handles replication of destructible actors masks */ UFUNCTION() void OnRep_DestructableMasks();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各int32は、最大32個のオブジェクトの状態をエンコードします 。 ステージでは、このようなオブジェクトを1000個以上持つことができます。 最大1024個のオブジェクトをエンコードする場合、2つのint32（ビットマスクの乗算）で処理できますが、今のところ、配列の複製は残しておきます。 現在のソリューションでも、ネットワークをロードせずに機能します。 マップのロード段階では、ネットワークを介した条件付き40 intの送信は大きなデータではなく、戦闘中に同時に多くのオブジェクトが死ぬことはありません。 エンジンは、フィールドの一部を変更するときに配列の最適な複製を処理します。

このアプローチは、静的オブジェクトがサーバーとクライアントの両方で明確なロード順序を持つことに基づいて機能します。 それらは配列にキャッシュでき、変更されたオブジェクトのインデックスのみを複製できます。 また、バイナリロジックのみが実装（生存/破棄）されている場合でも、追加のフィールド（たとえば、「健康」と「浸透」）が表示される場合でも、このアプローチは正当化されます。 これらは、マップ上に多数住んでいる同種のセクターです。

壁から完全に破壊可能な世界を作りたいですか？ そのような状態を通して彼らと協力してください。 ビットマスクの形のいくつかのintは数千の破壊可能なオブジェクトをコード化するのを可能にするでしょう 。 このような各セクターを個別に複製する「標準」パスは、サーバーのネットワークとCPUの両方を簡単に殺します（誰が複製する必要があるか、誰に、誰に複製しないかを確認します）。

データのパッケージ化

一般に、上記のポイントはすでに間接的にこのトピックに触れていました。そこでは、シーン上の何千ものオブジェクトの状態に関する情報をビットマスクの配列にパックします。 ただし、複製されたセクター内のフラグにも同じ手法を適用する必要があります。

ある段階で、タンクには通常の複製された10個以上のブールフラグがあるという結論に達しました。 これらは、「戦車は沈む」、「放火する」、「ターゲットがロックされている」、「死亡した」などの通常のゲームプレイ状態です。

その結果、コアプログラマーは、 そのような状態を複製するためのプロキシクラスを作成しました 。 使用方法は次のとおりです。

  RepOwnerFlags .Add(&bEnableLockTarget) .Add(&bCanMove) .Add(&bIsDrowning) .Add(&bInWater) .Build(); RepPublicFlags .Add(&bIsDying, this, "OnRep_IsDying") .Add(&bIsMoving, this, "OnRep_IsMoving") .Add(&bIsTurning, this, "OnRep_IsTurning") .Add(&bIsInFire) .Add(&bIsEngineBurning, this, "OnRep_IsEngineBurning") .Add(&bHasMinimapObservers) .Build();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RepOwnerFlagsおよびRepPublicFlagsは、uint64のラッパーのように機能する複製されたクラス変数です 。 変数自体は通常のものになり、エンジンブールの観点からは複製できません。

  /** Notifies of death */ UFUNCTION() void OnRep_IsDying(); /** Identifies if pawn is in its dying state */ UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = Death) bool bIsDying;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

boolをuint8：1にパックすることもお勧めです。 複製された構造内に複数ある場合は1です。

はい、同様の規則がRPC関数に適用されます。 いくつかのブールを送信します-それらをパックします。 int32の代わりにvectorとint8（可能であれば）にfloatを使用すると、同じ状況になります。

ファッティエクターズ

セクターの複製の開始にかなりの時間がかかる状況を想像するのは簡単です。 たとえば、私たちの場合の戦車の装甲に関するデータ（戦車の内部は、レベルに応じてパラメーターが異なる多数のピースで構成されています）。

データの大きなチャンクが1つのセクターから複製のために到着すると、ネットワークは過負荷であると見なされ、他のセクターもこの間複製されません 。

この場合、ネットワークの飽和を回避する良い方法は、このデータを配列の一部に配置し、飽和の可能性をチェックして、 断片的に複製することです。

 bool AMyActor::ReplicateSubobjects(class UActorChannel **Channel, class FOutBunch **Bunch, FReplicationFlags **RepFlags) { bool WroteSomething = Super::ReplicateSubobjects(Channel, Bunch, RepFlags); auto NetDriver = Channel->Connection->GetDriver(); for (int32 i = 0; i < MyDataArray.Num(); i++) { // Check for saturation if (((Channel->Connection->QueuedBits) + Channel->Connection->SendBuffer.GetNumBits() + Bunch->GetNumBits()) >= 0) { return WroteSomething; } auto DataObject = MyDataArray[i]; if (DataObject != nullptr) { WroteSomething |= Channel->ReplicateSubobject(DataObject, **Bunch, **RepFlags); } } return WroteSomething; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MyDataArrayは同じデータです。 このアプローチは、ネットワーク上でセクターを作成するときに、ネットワーク全体の「フリーズ」を回避します。

この場合、すべてのプロパティが複製される前に、ectorが作成、表示、およびアニメーション化されることを検討する価値があります。 これらのプロパティがその外観と動作を決定する場合、完全なネットワーク初期化が終了するまで非表示にすることをお勧めします。

結果ではなく状態

ネットワーク最適化の観点からは、計算の最終結果ではなく、計算を生成する条件を顧客に複製するのが正しいでしょう。 たとえば、キャラクターが「見る」ポイントに関する情報は、クライアントで計算および平滑化できる回転と照準に関するすべての計算を引き起こす可能性があります。

コインの反対側には、顧客の最適化があります。 クライアントが考慮しなければならないほど、同じ携帯電話でプレイすることはより快適になります。

量子化ベクトル

ベクターを完全な精度で複製する必要はほとんどありません。 したがって、 ベクターを複製するには、このビジネスに最適化された特別なクラス FVector_NetQuantize、FVector_NetQuantize10、FVector_NetQuantize100、FVector_NetQuantizeNormal を使用する必要があります 。

個人的な慣習から：FVector_NetQuantize100を超える精度は必要ありません。絶対的な大多数では、FVector_NetQuantizeとFVector_NetQuantizeNormalがネットワークに使用されます。

ネットワーク関連性を使用する（しない）

ゲームキャラクターのネットワーク関連性が必要な理由がわからない場合は、無効にすることをお勧めします。 エンジンのデフォルト設定は、地震のようなシューティングゲーム（UTの耳、すでに述べた）向けに設計されています。 それらは、（視覚的に）開かれた世界を持つゲームには適さず、「脂肪」セクターの場合もあまり快適ではありません。

ectorとプレーヤー間のNetCullDistanceSquared（距離の2乗）に基づくサーバーは、このectorが特定のクライアントに存在する必要があるかどうかを決定します。 それらの間の距離が大きい場合、セクターはクライアントから削除され、小さい場合、クライアント上で再作成されます。 この操作は、5秒のタイムアウトで実行されます（デフォルト値はRelevantTimeoutです）。

ここでキーが再作成されます。 fat ectorの場合、このプロセスは、オブジェクトのスポーン時にネットワークを詰まらせるか、フリーズを引き起こす可能性があります（そのリソースがメモリからアンロードされた場合）。 オープンワールドの場合、それは「どこからでもない」場所の真ん中に現れることでもあります。 あなたのセクターが常に「境界線上」で実行されている場合（デフォルトでは、キャラクターから150メートル実行されます）、このプロセスは不快な場合があります。

同時に、適切に調整された関連性は、ゲームプレイでこれを行うことができる場合、トラフィックと神経を大幅に節約できます 。 AWAの場合、ネットワークの関連性は一切使用されません。「戦車は検出された場合にのみクライアントに表示される」という通常のスキームとは対照的に、マップ全体で敵の戦車を見ることができます。

もちろん、組み込みのメカニズムに基づいて関連性を制御できるだけでなく、 AActor :: IsNetRelevantFor （...）を再定義することでも関連性を制御できます。 ネットワーク最適化の考慮事項により、不正行為から保護するために、これが必要になる場合があります。 たとえば、MOBA：戦争の霧の中に隠されたキャラクターは、最も平凡なマップハックを避けるためにクライアントに複製されるべきではありません。 データなし-キャンディーなし。

ネットワークのデバッグ

プレイテスト

プレイ。 それをテストします。 ご覧ください。 編集者や温室の条件ではなく、実際の条件で-組み立てられたクライアントとサーバーが戦闘条件で展開されています。 開発マシン上のローカルサーバーは 、特に4000 flopsのパフォーマンスの仮想マシンを使用する場合は特に悪い考えです。

そして、はい、エディターでのネットワークのテストがどれほど便利であっても、特にコンソールやモバイルデバイスに関しては、実際のアセンブリはまだ別の世界です。 不完全な状態での顧客の行動は異なります。

ネットワークプロファイラー

エンジンを完備した素晴らしいユーティリティ： NetworkProfiler

つい最近、これは特定のタンクの接続解除の原因を検索する方法です。

プロファイラーには奇妙な機能があり、モバイルデバイスでの使用は制限されていますが、ネットワークデータの全体像を理解することができます 。

これは、疑わしい「脂肪」データとネットワークスパイクを識別するのに最も役立ちます。 使用する必要があります。

貧弱なネットワークシミュレーション

プレイテストでは、明らかなネットワークの問題のみを特定できます。 残念なことに、有料ユーザーが遠くの村に座って、Wi-Fiルーターと家に3メートルのアンテナがあり、そこからインターネットがこのルーターに行き、3キロ離れた携帯電話の塔から本当の問題が始まります。 pingが十分に適切であるという事実にもかかわらず、 この構成ではパケットに何が起こる可能性があります 。

UE4は、「箱から出してすぐに」、pingの待ち時間、パケット損失、誤った順序など、さまざまなネットワーク状態をシミュレートできます。 詳細については、こちらをご覧ください： ネットワークベースのエクスプロイトを見つける

叙事詩記事の例では、iniでパラメーターを指定してネットワークを構成していますが、テストではこれはあまり便利ではありません。 さらに、完全なテストを行うには、エディターを再起動せずに、実行時に複数のプリセットを用意してそれらを切り替えるほうが便利です。

これは次のように行われます。UE4/ Engine / Binaries /フォルダーで、このコンテンツを使用して、network_bad.txtなどのファイルを作成します

 Net PktLoss=1 Net PktOrder=0 Net PktDup=0 Net PktLag=120 Net PktLagVariance=0 p.netshowcorrections 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、エディタのコンソールでexec network_bad.txtを直接呼び出して、説明されている設定を適用できます。 既に理解したように、これは単なるファイルに「パック」されたコンソールコマンドのセットです。

交通監視

専用に上げます。 プレイテストを準備します。 単一のポートでトラフィックを監視します。 入場と退場の平均トラフィック量を見積もります。

この点は非常に明白ですが、何らかの理由で多くの人がそれを無視しています。

あとがき

anrialでマルチプレーヤーで作業するときに、一般的なレベルで基本的に重要だと思うすべてのことについて簡単に話そうとしました。 遅延補正、ネットワーク補間/外挿、ネットワークアーキテクチャの機能については無限に語ることができますが、これらはすべて上記と同じ原理とアプローチに基づいています。 はい、別の記事に値します。

AW：Assaultでの結果-問題や重大な遅延なしに3Gネットワ​​ークでプレイする能力。 （安定した接続ではあるが）Edgeでも十分と言えます。 私の意見では、これらは16人のプレーヤーのマルチプレーヤーにとって非常にまともな数字です。 チャンネルの厚さに加えて、他の多くのゲームとは異なり、pingに対しても重要ではありません。

補足、反論、議論することがあれば、コメントを歓迎します！ :)