Unreal Engine RPC Optimization：ネットワークのパンクを防ぐTick処理の改善ガイド

すべてのMultiplayerゲーム開発者がいつかは直面するネットワークのボトルネックがあります。それは、144 FPSで動作しているクライアントが、カスタムの移動状態を毎フレーム（Tick）サーバーに送信しようとすることです。数秒のうちにサーバーのネットワークキューは冗長なRemote Procedure Calls (RPCs) で溢れかえり、深刻なラグやパケットロス、そして不可避な切断を引き起こします。これは実質的に、クライアントが自前のサーバーインフラに対して分散型サービス拒否（DDoS）攻撃を仕掛けているようなものです。

このシナリオは、Multiplayerゲームのアーキテクチャにおける最も一般的な落とし穴の一つです。プレイヤーの入力や複雑な車両の物理状態、連射メカニクスなどを実装する際、滑らかなレスポンスを実現するために Tick() 関数内にRPCを配置するのは論理的な選択に思えるかもしれません。しかし、Unreal EngineのNetworkingレイヤーは、中間にあるRPCを自動的に間引く（Cull）ことはしません。ゲームが毎フレームRPCをプッシュすれば、それらすべてがキューに入れられ、送信されます。

移動や位置の更新において、143フレーム分の中間データが必要になることはほとんどありません。他のクライアントにReplicationするために必要なのは、常に最新の絶対的な状態だけです。この包括的なガイドでは、Unreal Engine RPC Optimizationを深く掘り下げ、これらTickベースのネットワークコールをスロットリングし、スマートな状態蓄積を実装して、Multiplayerの帯域幅オーバーヘッドを劇的に削減する方法を解説します。

Tickに依存したネットワークイベントの危険性

解決策を実装する前に、問題の構造を理解することが重要です。Unreal EngineでRPC（Server、Client、または NetMulticast）を宣言すると、エンジン内のネットワークドライバーに対して関数パラメータをシリアライズし、送信パケットキューにプッシュするように指示することになります。

キューイングの問題点

Unreal Engineは、接続の NetUpdateFrequency と帯域幅制限に基づいて、送信RPCをパケットにまとめてバッチ処理します。クライアントが高フレームレートで毎フレームServer RPCを呼び出している場合、エンジンはそのすべての呼び出しを処理しようと試みます。

RPCが Reliable としてマークされている場合、状況は壊滅的です。Reliable RPCは到達と実行順序を保証します。ネットワークチャネルはすぐに一杯になり、バッファがオーバーフローすると、エンジンによって接続が強制的に閉じられ、プレイヤーは切断されます。

RPCが Unreliable の場合、キューが一杯になるとエンジンはパケットを破棄します。これにより強制切断は免れますが、深刻なラバーバンディング（位置の引き戻し）が発生します。サーバーがフレーム1と2を受信した後、フレーム3〜100を破棄し、その次にフレーム101を処理するといったことが起こるためです。その結果、動きは不安定でガタつき、プレイ体験を損ないます。これは、開発チームが fixing the Unreal Engine RPC replication issue breaking your states （ステートを破壊するUnreal EngineのRPCレプリケーション問題の修正）に取り組む際の一般的な根本原因です。

帯域幅の計算

具体的な数字を見てみましょう。Server RPCを介してシンプルなVector（12バイト）とRotator（12バイト）を送信していると仮定します。RPCヘッダーのオーバーヘッドを含め、1回の呼び出しを32バイトと見積もります。

• 30 FPSの場合：30 * 32バイト = 960バイト/秒（1クライアントあたり約1 KB/s）
• 144 FPSの場合：144 * 32バイト = 4,608バイト/秒（1クライアントあたり約4.6 KB/s）
• 240 FPSの場合：240 * 32バイト = 7,680バイト/秒

これをバトルロイヤルの64人のプレイヤーで掛け合わせると、サーバーは突如として毎秒500KB近い、純粋なRPCオーバーヘッドだけを処理することになります。これは基本的な移動トラッキングだけの話です。これではスケーラビリティを確保できません。

ステップ1：AccumulatorパターンによるTick依存の解消

Unreal Engine RPC Optimizationにおける最も効果的な戦略は、ネットワークの送信レートをクライアントのレンダリングフレームレートから切り離すことです。Tick() 内でRPCを直接プッシュする代わりに、毎フレームローカル変数を更新し、タイマーを使用してそのデータを固定の予測可能な間隔（例：秒間10回または20回）でサーバーに一括送信（Flush）します。

これを Accumulator（アキュムレーター）パターン と呼びます。クライアントは最新の状態を継続的に蓄積しますが、ネットワークのゲートが開いたときにのみ送信を行います。

適切な周波数の特定

スムーズなMultiplayer体験のために、秒間144回の更新は必要ありません。最新の競技用シューティングゲームの多くは、サーバーを30Hzまたは60Hzで動作させています。したがって、適切なクライアントサイド予測（Client-side Prediction）とサーバーサイド補間（Server-side Interpolation）を使用していれば、クライアントの更新を秒間15〜30回送信すれば通常は十分です。

送信レートを無制限の144Hzから上限20Hzに制限することで、その特定のアクションに関するネットワークトラフィックを即座に85%以上削減できます。

ステップ2：C++でのRate-Limiterの実装

これをC++で効果的に実装する方法を見てみましょう。クライアントが毎フレーム目標のLocationとRotationを追跡し、定義されたネットワーク送信レートに基づいてのみ Server_UpdateTransform RPCを送信するシステムを作成します。

ヘッダーファイル (.h)

まず、カスタムの APawn または ACharacter クラスで変数と関数を定義します。タイマーハンドル、更新レート、および未送信データを保持するための変数が必要です。

UCLASS()
class MYGAME_API AMyCustomPawn : public APawn
{
    GENERATED_BODY()

public:
    AMyCustomPawn();

    virtual void Tick(float DeltaTime) override;
    virtual void SetupPlayerInputComponent(class UInputComponent* PlayerInputComponent) override;

protected:
    virtual void BeginPlay() override;

    // サーバーにデータを送信するRPC。高速で継続的な更新のため、Unreliableとしてマーク。
    UFUNCTION(Server, Unreliable, WithValidation)
    void Server_SendTransformUpdate(FVector NewLocation, FRotator NewRotation);

private:
    // ネットワークFlush用のタイマーハンドル
    FTimerHandle NetworkUpdateTimerHandle;

    // サーバーに更新を送信する頻度（回/秒）
    UPROPERTY(EditDefaultsOnly, Category = "Network")
    float NetworkSendRate;

    // まだ送信されていない新しいデータがあるかどうかを追跡するフラグ
    bool bHasPendingNetworkUpdate;

    // 送信を待機している蓄積されたデータ
    FVector PendingLocation;
    FRotator PendingRotation;

    // タイマーによって呼び出され、データを送信する関数
    void FlushNetworkUpdate();
};

ソースファイル (.cpp)

次に、ロジックを実装します。BeginPlay でタイマーをセットアップし、Tick で保留中の変数を更新し、実際のネットワーク送信はタイマーに任せます。

#include "MyCustomPawn.h"
#include "TimerManager.h"

AMyCustomPawn::AMyCustomPawn()
{
    PrimaryActorTick.bCanEverTick = true;
    
    // デフォルトで秒間20回の更新を送信
    NetworkSendRate = 20.0f; 
    bHasPendingNetworkUpdate = false;
}

void AMyCustomPawn::BeginPlay()
{
    Super::BeginPlay();

    // ローカルで制御されているクライアントのみがネットワーク送信タイマーを実行する
    if (IsLocallyControlled())
    {
        float UpdateInterval = 1.0f / NetworkSendRate; // 例：1.0 / 20.0 = 0.05秒

        GetWorld()->GetTimerManager().SetTimer(
            NetworkUpdateTimerHandle,
            this,
            &AMyCustomPawn::FlushNetworkUpdate,
            UpdateInterval,
            true // ループさせる
        );
    }
}

void AMyCustomPawn::Tick(float DeltaTime)
{
    Super::Tick(DeltaTime);

    // ここでカスタムのクライアントサイド移動ロジックを実行
    // 例: FVector NewLoc = ...; FRotator NewRot = ...;
    // SetActorLocationAndRotation(NewLoc, NewRot);

    if (IsLocallyControlled())
    {
        // ここでRPCを呼び出す代わりに、最新の状態を保存するだけにする
        PendingLocation = GetActorLocation();
        PendingRotation = GetActorRotation();
        
        // 送信待ちの新しいデータがあることをマーク
        bHasPendingNetworkUpdate = true;
    }
}

void AMyCustomPawn::FlushNetworkUpdate()
{
    // 新しいデータがない場合（例：プレイヤーが静止している場合）は帯域幅を無駄にしない
    if (!bHasPendingNetworkUpdate)
    {
        return;
    }

    // 蓄積された最新の状態をサーバーに送信
    Server_SendTransformUpdate(PendingLocation, PendingRotation);

    // 次のTickが状態を更新するまでフラグをリセット
    bHasPendingNetworkUpdate = false;
}

bool AMyCustomPawn::Server_SendTransformUpdate_Validate(FVector NewLocation, FRotator NewRotation)
{
    // ここにAnti-Cheatのバリデーションを追加。位置が妥当かどうかなど。
    return true; 
}

void AMyCustomPawn::Server_SendTransformUpdate_Implementation(FVector NewLocation, FRotator NewRotation)
{
    // サーバーはレート制限されたデータを受け取り、それを適用する
    SetActorLocationAndRotation(NewLocation, NewRotation);
    
    // 注意: サーバーは通常、標準のReplicatedプロパティを介してこれを他のクライアントに同期させる。
    // Multicast RPCは使用しないのが一般的。
}

なぜこのアーキテクチャが機能するのか

この構成は、ネットワークのパンク問題をエレガントに解決します。クライアントが30 FPSで動作していようが300 FPSで動作していようが、サーバーは（パケットロスがない限り）確実に秒間 NetworkSendRate 回の更新のみを受け取ります。

さらに、早期退出チェック (!bHasPendingNetworkUpdate) も実装しました。プレイヤーがコーヒーを買いに席を外した場合、クライアントはRPCの送信を完全に停止し、アクティブなプレイヤーのために重要な帯域幅を解放します。これは、サーバーのパフォーマンスを一定に保つ上で大きなメリットとなります。

ステップ3：他のクライアントでの状態補間（Interpolation）の処理

ネットワークの送信レートを下げると、サーバー上の動き、そして結果として他の接続されたクライアント上の動きが、カクついて見えるようになります。送信レートを10Hzにすると、60 FPSのモニターではキャラクターが1秒間に10回テレポートするように見えてしまいます。

これを修正するには、キャラクターを新しい位置に単純にスナップさせるのではなく、補間（Interpolation）を使用する必要があります。サーバーが NewLocation を Simulated Proxy（そのプレイヤーを観察している他のクライアント）にReplicationするとき、それらのクライアントは現在の位置から受信した目標位置まで、時間をかけて滑らかに FMath::VInterpTo させる必要があります。

これにより、5Hzや10Hzといった非常にアグレッシブなレート制限をかけても、視覚的には非常に滑らかな表現を維持できます。補間中にキャラクターが正しくスナップしないといった問題がある場合は、 how to fix player location desync in UEFN and Unreal Engine multiplayer （UEFNおよびUnreal Engineマルチプレイヤーでの位置同期ズレの修正方法）を確認してみてください。

ステップ4：複雑なRPCのためのStruct Batching

ゲームで複数の異なる変数を送信する必要がある場合、別々のRPCを複数送ってはいけません。すべてのRPCにはベースラインとなるヘッダーオーバーヘッド（最小で1〜2バイト程度ですが、ペイロードのシリアライズを考慮すると実際にはそれ以上）が存在します。

同じネットワークFlushのタイミングで Server_SendHealth()、Server_SendArmor()、Server_SendPosition() を呼び出すと、ヘッダーのコストを3回分支払うことになります。

代わりに、ネットワークペイロード専用のStruct（構造体）を作成します。

USTRUCT()
struct FPlayerNetworkState
{
    GENERATED_BODY()

    UPROPERTY()
    FVector Location;

    UPROPERTY()
    FRotator Rotation;

    UPROPERTY()
    uint8 CurrentWeaponIndex;

    UPROPERTY()
    bool bIsCrouching;
};

この単一のStructを、タイマーベースのRPCで渡します。Unreal EngineのReflectionシステムは、これらの変数を単一のパケットペイロードに効率的にパッキングし、通信のバイトフットプリントを最小限に抑えてくれます。

Unreal Engine RPC Optimization 5つのベストプラクティス

ローカルテストから数千人の同時実行プレイヤーまでゲームをスケールさせるために、ネットワークアーキテクチャの基礎となる以下のルールを採用してください：

1. ゲートなしでTick内でRPCを送信しない: これを厳格なルールとしてください。RPCが Tick() 内にある場合は、必ず時間チェック（例：if (TimeSinceLastRPC > 0.1f)）で保護するか、ループタイマーで管理する必要があります。
2. ReliableよりUnreliableを優先する: 継続的に更新されるデータ（移動、視点操作、ビーム攻撃など）には、常にUnreliable RPCを使用してください。パケットがドロップしても、コンマ数秒後に到着する次のパケットがそれを上書きします。Reliable RPCは、絶対的な状態変化（武器の発射、アイテムの拾得、プレイヤーの死亡など）のみに限定すべきです。
3. FloatとVectorのQuantizationを活用する: FVector データを送信する際、完全な浮動小数点精度が必要なケースは稀です。Unreal EngineではRPC内のVectorを量子化（Quantization）でき（例：FVector_NetQuantize100）、値を小数点以下2桁に丸めることで、送信に必要な帯域幅を大幅に削減できます。
4. ダウンストリームデータには標準のReplicationを優先する: クライアントはサーバーにデータを送るためにRPCを使用する必要がありますが、サーバーが継続的なデータをクライアントに送り返すためにMulticast RPCを使用することは避けるべきです。サーバーは UPROPERTY(Replicated) 変数を更新し、Unreal内蔵のReplicationマネージャーに帯域幅の最適化、優先順位付け、および関連性（Relevancy）のソートを自動で任せるべきです。
5. 早期かつ頻繁にプロファイリングを行う: net.DumpRelevantActors コマンドやネットワークプロファイラーツール（Engineバイナリ内にある NetworkProfiler.exe）を使用して、RPCが各フレームで具体的に何バイト消費しているかを確認してください。最適化の効果を推測で語るのではなく、経験的に測定してください。

インフラとBackendのスケーリングへの対応

Unreal EngineのNetcodeの複雑さをマスターするのは骨の折れる作業です。タイマーハンドルの調整、Vectorの量子化、同期ズレの軽減に何時間も費やし、専用サーバーの帯域幅制限を超えないように奮闘することになります。

ゲーム内のコードを最適化した後も、それらのサーバーをグローバルにデプロイし、スケールさせる必要があります。これを自前で行うには、フリートマネージャー、ロードバランサー、データベースのシャーディング、SSL証明書の管理などのセットアップが必要で、本来のゲームデザインから離れて4〜6週間の集中的なインフラ構築作業が必要になります。

horizOn を使用すれば、これらのBackendサービスはゲーム開発者向けに事前に構成されています。スケーラブルなDedicated Serverホスティング、リアルタイムのデータベース同期、堅牢なアナリティクスが標準で提供されるため、インフラではなくゲームの開発に集中してリリースを目指すことができます。

最後に

Unreal Engine RPC Optimizationの鍵は、ネットワーク帯域幅が有限で非常に不安定なリソースであることを認識することです。ネットワークレイヤーを標準のフレームバッファのように扱うことはできません。Tick駆動の実行から脱却し、Accumulatorパターンを採用することで、ゲームのデータ出力を完全に制御できるようになります。サーバー負荷を軽減し、パケットロスを抑え、インターネット接続が不安定なプレイヤーにも極めて滑らかな体験を提供できるようになります。

ゲームの最適化は継続的なプロセスであることを忘れないでください。ネットワークのパンクを防ぐために、エンジンのデフォルトの挙動だけに頼るのはやめましょう。データフローを明示的に制御してください。現在のプロトタイプにこれらのレート制限を実装し、ネットワークプロファイラーで前後のメトリクスを監視すれば、サーバーパフォーマンスが飛躍的に向上するのがわかるはずです。

新しく最適化されたMultiplayer Backendをスケールさせる準備はできましたか？horizOn を無料で試すか、 API docs をチェックして、プロフェッショナルなゲームインフラがいかにシンプルかを確認してください。

---

Source: Network: How not to send all PRC every tick?