Unreal Engine RPC Optimization: 如何避免在每个 Tick 中淹没网络

每一个 Multiplayer 游戏开发者最终都会面临同一个网络瓶颈：一个运行在 144 FPS 的 Client 决定在每一个 Tick 都向 Server 发送自定义移动状态。几秒钟内，Server 的网络队列就会被冗余的 Remote Procedure Calls (RPC) 完全淹没，导致严重的 Lag、丢包 (Packet Loss) 以及不可避免的断开连接。你的 Client 本质上是在对自己的 Server 架构进行分布式拒绝服务 (DDoS) 攻击。

这种情况代表了 Multiplayer 游戏架构中最常见的陷阱之一。当开发者需要发送自定义玩家输入、复杂的车辆物理状态或快速射击机制时，将 RPC 放在 Tick() 函数中似乎是实现平滑响应逻辑的选择。然而，Unreal Engine 的 Networking 层并不会自动剔除中间的 RPC。如果你的游戏在每个 Tick 都推送 RPC，所有这些调用都会进入队列并被传输。

对于移动和位置更新，你几乎从不需要关心那 143 帧的中间状态；你只需要最新的绝对状态来同步给其他 Client。在这份综合指南中，我们将深入探讨 unreal engine rpc optimization，教你如何对这些基于 Tick 的网络调用进行节流 (Throttle)，实现智能的状态累加 (State Accumulation)，并大幅降低你的 Multiplayer 带宽开销。

绑定 Tick 的网络事件之危险

在实施解决方案之前，了解问题的解剖结构至关重要。当你在 Unreal Engine 中声明一个 RPC 时，无论是 Server、Client 还是 NetMulticast，你都在指示 Engine 的网络驱动程序序列化函数参数并将其推入外发 Packet 队列中。

队列问题

Unreal Engine 会根据连接的 NetUpdateFrequency 和带宽限制，将外发的 RPC 批处理到 Packet 中。如果一个 Client 在高帧率下每个 Tick 都调用 Server RPC，Engine 将尝试处理每一个调用。

如果 RPC 被标记为 Reliable，情况将是灾难性的。Reliable RPC 保证交付和执行顺序。网络通道会迅速填满，如果缓冲区溢出，连接将被 Engine 强制关闭，导致玩家掉线。

如果 RPC 被标记为 Unreliable，Engine 会在队列满时丢弃 Packet。虽然这防止了硬断开，但会导致严重的 Rubber-banding。Server 可能会收到第 1 帧、第 2 帧，丢掉第 3-100 帧，然后处理第 101 帧。其结果是飘忽不定的抖动感，严重破坏游戏体验。当团队在修复破坏状态同步的 Unreal Engine RPC Replication 问题时，这通常是核心原因。

带宽计算

让我们看一些具体的数据。假设你正在通过 Server RPC 发送一个简单的 Vector (12 bytes) 和一个 Rotator (12 bytes)。加上 RPC Header 的开销，我们估计每次调用约为 32 bytes。

• 在 30 FPS 下：30 * 32 bytes = 960 bytes/second (每个 Client 约 1 KB/s)。
• 在 144 FPS 下：144 * 32 bytes = 4,608 bytes/second (每个 Client 约 4.6 KB/s)。
• 在 240 FPS 下：240 * 32 bytes = 7,680 bytes/second。

如果是 Battle Royale 中的 64 名玩家，你的 Server 每秒突然要处理近 0.5 MB 的纯 RPC 开销——仅仅是为了基础的移动追踪。这完全不具备扩展性 (Scale)。

步骤 1：使用 Accumulator Pattern 打破 Tick 依赖

实现 unreal engine rpc optimization 最有效的策略是将网络发送频率与 Client 的渲染帧率解耦。与其在 Tick() 中推送 RPC，不如每个 Tick 更新一个本地变量，然后使用 Timer 以固定且可预测的间隔（例如每秒 10 或 20 次）将数据 Flush 到 Server。

我们称之为 Accumulator Pattern (累加器模式)。Client 持续累加最新状态，但仅在网络“闸门”开启时才进行传输。

确定目标频率

你并不需要每秒 144 次更新来获得平滑的 Multiplayer 体验。大多数现代竞技射击游戏的 Server 频率通常在 30Hz 或 60Hz。因此，每秒发送 15 到 30 次 Client 更新通常绰绰有余，前提是你使用了正确的 Client-side Prediction 和 Server-side Interpolation。

通过将发送速率从无限制的 144Hz 降低到上限 20Hz，你可以立即为该特定操作减少超过 85% 的网络流量。

步骤 2：在 C++ 中实现速率限制器 (Rate-Limiter)

让我们看看如何在 C++ 中有效地实现这一机制。我们将创建一个系统，让 Client 每个 Tick 追踪其期望的目标 Location 和 Rotation，但仅根据预定义的网络发送速率发送 Server_UpdateTransform RPC。

头文件 (.h)

首先，在我们的自定义 APawn 或 ACharacter 类中定义变量和函数。我们需要一个 Timer Handle、一个更新速率，以及保存未发送数据的变量。

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;

    // The RPC to send data to the server. Marked as Unreliable for rapid, continuous updates.
    UFUNCTION(Server, Unreliable, WithValidation)
    void Server_SendTransformUpdate(FVector NewLocation, FRotator NewRotation);

private:
    // Timer handle for our network flush
    FTimerHandle NetworkUpdateTimerHandle;

    // How many times per second we want to send updates to the server
    UPROPERTY(EditDefaultsOnly, Category = "Network")
    float NetworkSendRate;

    // Flag to track if we have new data that hasn't been sent yet
    bool bHasPendingNetworkUpdate;

    // The accumulated data waiting to be sent
    FVector PendingLocation;
    FRotator PendingRotation;

    // The function called by the timer to flush data
    void FlushNetworkUpdate();
};

源文件 (.cpp)

现在，我们实现逻辑。我们在 BeginPlay 中设置 Timer，在 Tick 中更新 Pending 变量，并让 Timer 处理实际的网络传输。

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

AMyCustomPawn::AMyCustomPawn()
{
    PrimaryActorTick.bCanEverTick = true;
    
    // Default to sending 20 updates per second
    NetworkSendRate = 20.0f; 
    bHasPendingNetworkUpdate = false;
}

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

    // Only the local controlling client should run the network flush timer
    if (IsLocallyControlled())
    {
        float UpdateInterval = 1.0f / NetworkSendRate; // e.g., 1.0 / 20.0 = 0.05 seconds

        GetWorld()->GetTimerManager().SetTimer(
            NetworkUpdateTimerHandle,
            this,
            &AMyCustomPawn::FlushNetworkUpdate,
            UpdateInterval,
            true // Loop continuously
        );
    }
}

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

    // Run your custom client-side movement logic here
    // e.g., FVector NewLoc = ...; FRotator NewRot = ...;
    // SetActorLocationAndRotation(NewLoc, NewRot);

    if (IsLocallyControlled())
    {
        // Instead of calling the RPC here, we just store the latest state
        PendingLocation = GetActorLocation();
        PendingRotation = GetActorRotation();
        
        // Mark that we have fresh data waiting to be sent
        bHasPendingNetworkUpdate = true;
    }
}

void AMyCustomPawn::FlushNetworkUpdate()
{
    // If there is no new data (e.g., the player is standing still), don't waste bandwidth
    if (!bHasPendingNetworkUpdate)
    {
        return;
    }

    // Send the latest accumulated state to the server
    Server_SendTransformUpdate(PendingLocation, PendingRotation);

    // Reset the flag until the next tick modifies the state again
    bHasPendingNetworkUpdate = false;
}

bool AMyCustomPawn::Server_SendTransformUpdate_Validate(FVector NewLocation, FRotator NewRotation)
{
    // Add anti-cheat validation here. Is the location reasonable?
    return true; 
}

void AMyCustomPawn::Server_SendTransformUpdate_Implementation(FVector NewLocation, FRotator NewRotation)
{
    // The server receives the rate-limited data and applies it
    SetActorLocationAndRotation(NewLocation, NewRotation);
    
    // Note: The server would then replicate this to other clients, 
    // typically via standard Replicated properties, NOT by Multicasting.
}

为什么这种架构有效

这种方案优雅地解决了网络淹没问题。无论 Client 运行在 30 FPS 还是 300 FPS，Server 都保证每秒仅接收 NetworkSendRate 次更新（假设无丢包）。

此外，我们实现了一个提前退出检查 (!bHasPendingNetworkUpdate)。如果玩家离开座位去倒杯咖啡，Client 就会完全停止发送 RPC，为活跃玩家腾出关键带宽。这对于维持一致的 Server 性能是一个巨大的胜利。

步骤 3：处理其他 Client 的状态插值 (Interpolation)

当你降低网络发送速率时，Server 上的移动——以及随之而来的其他已连接 Client 上的移动——会变得断断续续。如果你以 10Hz 发送更新，Character 在 60 FPS 的显示器上每秒会肉眼可见地跳变 10 次。

要修复这个问题，你不能简单地将 Character “吸附” (Snap) 到新位置。你必须使用插值 (Interpolation)。当 Server 将 NewLocation 同步给 Simulated Proxies（观察该玩家的其他 Client）时，这些 Client 必须随着时间推移，平滑地使用 FMath::VInterpTo 从当前位置插值到同步的目标位置。

这确保了即使使用了非常激进的速率限制（如每秒 5 或 10 次更新），视觉表现依然丝滑顺畅。如果你在处理插值过程中的位置跳变问题，建议查看如何修复 UEFN 和 Unreal Engine Multiplayer 中的玩家位置不同步。

步骤 4：复杂 RPC 的结构体打包 (Struct Batching)

如果你的游戏需要发送多个不同的变量，不要发送多个独立的 RPC。每个 RPC 都有基础的 Header 开销（通常至少 1-2 bytes，但在考虑有效载荷序列化时实际上更多）。

如果你在同一次网络 Flush 中调用 Server_SendHealth()、Server_SendArmor() 和 Server_SendPosition()，你支付了三次 Header 成本。

相反，为你的网络 Payload 创建一个专用结构体 (Struct)。

USTRUCT()
struct FPlayerNetworkState
{
    GENERATED_BODY()

    UPROPERTY()
    FVector Location;

    UPROPERTY()
    FRotator Rotation;

    UPROPERTY()
    uint8 CurrentWeaponIndex;

    UPROPERTY()
    bool bIsCrouching;
};

通过基于 Timer 的 RPC 传递这单个结构体。Unreal Engine 的反射系统会将这些变量高效地打包进单个 Packet Payload 中，从而最大限度地减小连接的字节占用。

Unreal Engine RPC Optimization 的 5 项最佳实践

为了确保你的游戏能从本地测试扩展到成千上万的并发玩家，请在网络架构中遵循以下基本规则：

1. 绝对不要在不带限制的情况下在 Tick 中发送 RPC： 这是一个硬性规则。如果 RPC 位于 Tick() 内，它必须由时间检查（例如 if (TimeSinceLastRPC > 0.1f)）保护，或通过循环 Timer 进行管理。
2. 优先使用 Unreliable 而非 Reliable： 对于持续更新的数据（移动、视角转动、持续射线武器），始终使用 Unreliable RPC。如果 Packet 丢失，一小段时间后到达的下一个 Packet 反正会覆盖它。Reliable RPC 应严格保留给绝对的状态更改（例如：开火、捡起物品、玩家死亡）。
3. 对 Float 和 Vector 使用量化 (Quantization)： 在发送 FVector 数据时，你很少需要完整的浮点精度。Unreal Engine 允许你在 RPC 中对 Vector 进行量化（例如 FVector_NetQuantize100），这会将值四舍五入到小数点后两位，从而大幅削减所需的带宽。
4. 下游数据优先使用标准 Replication： 虽然 Client 必须使用 RPC 将数据发送给 Server，但 Server 极少应该使用 Multicast RPC 将持续数据下发。Server 应该更新一个 UPROPERTY(Replicated) 变量，让 Unreal 内置的 Replication Manager 自动处理带宽优化、优先级排序和相关性 (Relevancy) 剔除。
5. 尽早且经常进行 Profiling： 使用 net.DumpRelevantActors 命令和 Network Profiler 工具（位于 Engine 二进制目录下的 NetworkProfiler.exe）来直观查看你的 RPC 每帧消耗了多少字节。永远不要猜测优化效果，要进行实证测量。

处理基础设施和 Backend 扩展

精通 Unreal Engine Netcode 的复杂性是一项艰巨的任务。你可能花费数小时调整 Timer Handle、量化 Vector 并缓解 Desync，仅仅是为了让你的 Dedicated Server 在不超出带宽限制的情况下平稳运行。

一旦你的游戏代码终于完成了优化，你仍需要全球化部署并扩展这些 Server。自行构建这些设施需要设置 Fleet Manager、Load Balancer、数据库分片以及 SSL 证书管理——这通常意味着 4-6 周高强度的基础设施工作，让你偏离了实际的游戏设计。

通过 horizOn，这些 Backend 服务已专为游戏开发者预先配置好。你可以开箱即用地获得可扩展的 Dedicated Server 托管、实时数据库同步和强大的 Analytics，让你专注于交付游戏，而不是基础设施。

总结

unreal engine rpc optimization 的关键在于意识到网络带宽是一种有限且高度不稳定的资源。你不能像处理标准的帧缓冲区那样对待网络层。通过从 Tick 驱动执行转变为拥抱 Accumulator Pattern，你可以完全控制游戏的数据输出。你降低了 Server 负载，缓解了丢包，并为网络波动环境下的玩家创造了极其顺畅的体验。

记住，优化游戏是一个持续的过程。不要指望 Engine 的默认行为能让你免于网络淹没。主动接管你的数据流。在当前的 Prototype 中实现这些速率限制，使用 Network Profiler 监测前后的指标，见证你的 Server 性能飞跃。

准备好扩展你新优化的 Multiplayer Backend 了吗？免费试用 horizOn 或查阅 API 文档，看看专业级的游戏基础设施可以多么简单。

---

来源: Network: How not to send all PRC every tick?