Ghost Actor Reappearance: 针对可破坏网格结构的 Multiplayer Network Replication Desync Fix

您的玩家挥舞着采集工具，木墙在他们的屏幕上瞬间破碎，但 80 毫秒后它又闪现重现并处于满血状态，接着在 400 毫秒后永久消失。这种视觉异常（俗称 “ghost build”）是 client-side prediction 不匹配和 out-of-order replication 的典型表现。在快节奏的 multiplayer 环境中，这些短暂的状态回滚会破坏玩家的沉浸感并引入视觉杂乱。为了解决这个问题，开发者必须实现一个强大的 multiplayer network replication desync fix，以协调即时的本地反馈与权威的服务器校验。

Anatomy of a Ghost Build: Prediction 与 Replication

在构建网络游戏玩法时，创作者必须在响应速度与服务器权威之间取得平衡。为了使移动和破坏具有即时感，客户端会在收到服务器确认之前预测行动的结果。例如，当玩家攻击可破坏结构时，客户端的游戏逻辑会立即运行伤害计算，禁用 collision，并触发粒子效果。

在底层，这会产生转瞬即逝的分歧，即客户端模拟领先于服务器。在标准的 netcode 模型中，一旦服务器处理了客户端的输入 RPC 并将新状态复制回来，这种分歧就会得到解决。然而，如果数据包延迟，或者服务器 tick rate（通常为 20Hz 到 30Hz）落后于客户端 frame rate（60Hz 到 120Hz），就会发生 race condition。client-side prediction 移除了 actor，但服务器的下一次 replication 更新仍包含该 actor 的较旧状态（存活且有生命值）。

这种特定的 race condition 在木质结构上非常明显。与石头或金属相比，木头的生命值上限较低（例如 90 HP vs. 300 HP），这意味着它一击即碎。这使得玩家操作与服务器确认之间的时间窗口变得极其短暂。任何 replication 延迟都会迫使客户端的网络驱动程序协调状态，由于服务器仍报告其存活，因此会重新构建 actor。

Packet Loss 与 Tick Rates 的影响

当 packet loss 发生时，客户端预测的破坏会处于悬而未决的状态。如果客户端发送的伤害数据包丢失，服务器将永远不会处理它，但客户端却假设伤害已应用。随后，客户端在 actor 已消失的错误假设下继续进行模拟。当服务器传输下一次状态更新时，不匹配就会显现出来，迫使客户端将 actor 重新生成到世界中。这种协调过程会产生令人不适的视觉突变（visual pop），尤其是在 packet loss 达到 1.5% 到 3% 且频繁发生丢包的情况下。

底层原理：Actor Lifecycle 与 Channel Teardown

Unreal Engine 和类似的现代 multiplayer 引擎使用专用的网络连接 channels 来同步 actor 的存在。每个被复制的 actor 都会被分配一个 actor channel。当 actor 在服务器上被销毁时，服务器会关闭该 channel，并向客户端发送 channel 关闭控制消息（NetGUID retirement）。

关键问题在于，property replication 和 channel 关闭并不共享相同的 replication 路径。属性更新（例如结构体 Health 变量的更新）被序列化，并作为 actor 常规 replication 包的一部分发送。如果服务器处理了伤害事件，但尚未对该 actor 进行 garbage collection，它可能会在 actor 被完全标记为销毁之前序列化最后一次属性更新。如果包含属性更新 of UDP packet 比包含 channel 关闭的 packet 先到达，客户端会更新 actor 的生命值，并覆盖本地预测的破坏效果。

这种行为与其他的 netcode 同步问题密切相关，例如我们在针对破坏状态的 Unreal Engine RPC replication 问题的 multiplayer desyncs 修复指南中讨论的问题。在该指南中，我们分析了 RPC 与属性之间的执行顺序不匹配是如何破坏世界状态的。同样，在处理玩家定位时，开发者也经常遇到类似的差异，详见我们的如何修复 Uefn 和 Unreal Engine multiplayer 中的玩家位置去同步指南。

当客户端处理乱序的 replication packet 时，它发现该 actor 在服务器上仍然存活，从而迫使该 actor 重新进入活跃池。客户端不得不等待 channel closure packet 最终到达（通常在 0.4 秒后），以永久删除该 actor。

在底层，replication packets 受到最大传输单元（MTU）的限制，通常为 1400 字节。如果您的游戏连接速率受到限制（例如将 MaxClientRate 设置为 15000 字节/秒），更新将会排队并拆分到多个 UDP packets 中。由于关闭 channel 的控制消息是可靠发送的，因此必须得到确认，而属性更新通常是不可靠发送的。如果网络拥塞或 packet loss 发生，可靠的 channel closure 消息可能会滞后于较旧的、不可靠的属性数据包，从而导致客户端重新构建 actor 的不匹配情况。

在 C++ 中实现 Predictive State Buffer

为了修复 ghost builds，我们必须在客户端拦截那些被预测为已销毁 actor 的传入 replication 更新。通过实现一个 client-side prediction buffer，我们可以在特定的时间窗口内（例如 500 毫秒）抑制属性对齐，从而为服务器的 channel-closure packet 预留足够的到达时间。以下是一个完整的、可运行的预测性可破坏 actor 的 C++ 实现。它重载了 replication 行为，并使用本地时间戳来确定是否应抑制 replication。

// PredictedDestructibleActor.h
#pragma once

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "PredictedDestructibleActor.generated.h"

UCLASS()
class MULTIPLAYERGAME_API APredictedDestructibleActor : public AActor
{
    GENERATED_BODY()

public:
    APredictedDestructibleActor();

protected:
    virtual void BeginPlay() override;
    virtual void GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const override;
    
    // Server-authoritative health variable
    UPROPERTY(ReplicatedUsing = OnRep_Health)
    float Health;

    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Destruction")
    float MaxHealth;

    // Triggered when health changes on the client
    UFUNCTION()
    void OnRep_Health();

    // Client-side prediction tracking flags
    bool bClientPredictedDestroyed;
    float ClientPredictionTime;
    
    // Maximum time (in seconds) the client will suppress server updates
    UPROPERTY(EditAnywhere, Category = "Networking")
    float PredictionTimeout;

    // Visual effect helper function
    void TriggerDestructionEffects();

public:
    // Called when the local player destroys the structure client-side
    UFUNCTION(BlueprintCallable, Category = "Destruction")
    void PredictDestruction();

    // Resets the predicted state if the server rejects the destruction
    void ResetPredictionState();

    virtual void Tick(float DeltaTime) override;
};

以下是相应的实现文件，展示了如何过滤传入的服务器状态：

// PredictedDestructibleActor.cpp
#include "PredictedDestructibleActor.h"
#include "Net/UnrealNetwork.h"
#include "Kismet/GameplayStatics.h"

APredictedDestructibleActor::APredictedDestructibleActor()
{
    PrimaryActorTick.bCanEverTick = true;
    bReplicates = true;
    
    // Set a moderate update frequency to balance bandwidth and responsiveness
    NetUpdateFrequency = 33.0f; 
    
    MaxHealth = 100.0f;
    Health = MaxHealth;
    bClientPredictedDestroyed = false;
    ClientPredictionTime = 0.0f;
    PredictionTimeout = 0.5f; // 500ms safety window
}

void APredictedDestructibleActor::BeginPlay()
{
    Super::BeginPlay();
}

void APredictedDestructibleActor::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
{
    Super::GetLifetimeReplicatedProps(OutLifetimeProps);
    DOREPLIFETIME(APredictedDestructibleActor, Health);
}

void APredictedDestructibleActor::OnRep_Health()
{
    // If the client has predicted this actor's death, suppress server property updates
    if (bClientPredictedDestroyed)
    {
        return;
    }

    if (Health <= 0.0f)
    {
        TriggerDestructionEffects();
    }
}

void APredictedDestructibleActor::PredictDestruction()
{
    // Prediction only runs on the client that simulated the event
    if (GetNetMode() == NM_Client)
    {
        bClientPredictedDestroyed = true;
        ClientPredictionTime = GetWorld()->GetTimeSeconds();
        
        // Hide the actor and disable collision immediately for responsive local feedback
        SetActorEnableCollision(false);
        SetActorHiddenInGame(true);
        
        // Spawn local particles and audio instantly
        TriggerDestructionEffects();
    }
}

void APredictedDestructibleActor::ResetPredictionState()
{
    bClientPredictedDestroyed = false;
    SetActorEnableCollision(true);
    SetActorHiddenInGame(false);
}

void APredictedDestructibleActor::TriggerDestructionEffects()
{
    // Spawn local visual effects (e.g. wood splinters, dust clouds)
    // and play destruction audio.
}

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

    if (GetNetMode() == NM_Client && bClientPredictedDestroyed)
    {
        float CurrentTime = GetWorld()->GetTimeSeconds();
        
        // If the timeout expires and the server hasn't torn down the channel, 
        // the server must have rejected the damage. We must roll back.
        if (CurrentTime - ClientPredictionTime > PredictionTimeout)
        { 
            ResetPredictionState();
        }
    }
}

通过使用这个 predictive buffer，我们能够阻止传入的 OnRep_Health 回调重置 actor 的视觉可见性。这使得客户端的 actor 保持隐藏且无 collision 状态，直到 channel close packet 到达。如果服务器不同意该破坏（例如，由于 anti-cheat 验证不匹配），超时将强制执行回滚，从而确保模拟不会发生永久性的去同步。

处理回滚与验证拒绝

此 replication 修复方案的关键组成部分是处理服务器拒绝玩家操作的情况。如果服务器的验证逻辑判定玩家不可能击中该结构，它就会拒绝该伤害。在这种情况下，客户端必须回滚预测的破坏以防止永久去同步，这就是为什么在 500 毫秒内没有收到服务器确认时，超时机制会恢复 actor 的 collision 和可见性。

手动实现负担 vs. 专用 Backend

虽然上述 C++ 解决方案修复了单个 actor 的 ghosting 问题，但要在整个游戏环境中应用该方案非常复杂。游戏开发者必须为每种可破坏对象类型手动编写预测和回滚代码，跟踪活跃的 prediction buffers，优化 actor 的 tick rates，并管理 network replication 优先级。对于独立团队来说，构建和测试这些边缘情况很容易就需要耗费 4 到 6 周的专属网络工程时间。

自行构建这一套系统需要设置 load balancers、数据库分片以及复杂的 WebSockets/UDP 服务器。通过 horizOn，这些 backend 服务均已预先配置完毕，让您可以直接发布游戏，而无需管理网络基础设施。horizOn 的实时大厅管理和会话编排可确保玩家状态和比赛属性以低于 50 毫秒的延迟进行可靠同步，从而缓解导致 ghost builds 的 replication 延迟。

针对 Multiplayer Network Replication Desync Fix 的实用最佳实践

在针对可破坏对象优化 netcode 时，请遵循以下指南以保持世界状态同步：

1. 将视觉资源与 Actor 生命周期解耦：避免依赖立即执行 AActor::Destroy() 来获取视觉反馈。设置一个布尔 replication 标志（如 bIsDead）并立即触发本地粒子系统。这样您就可以在客户端禁用 collision，而无需等待服务器的清理例程。
2. 优先处理 Channel 销毁而非属性更新：在可破坏物上设置 bOnlyRelevantToOwner 或提高 NetPriority，以确保网络驱动程序优先处理销毁更新。这可以确保它们不会落后于常规的环境属性 replication。
3. 设置活跃的 Prediction 超时窗口：绝不要让 client-side prediction 无限期运行。始终实现一个安全超时（通常是最大可接受 RTT 的 1.5 到 2 倍，外加服务器 tick 偏差的余量），以便在服务器拒绝操作时强制客户端回滚。这可以防止在发生 packet loss 时 actor 保持永久隐藏。
4. 调整 NetUpdateFrequency：在正常情况下保持可破坏结构的更新率较低（例如 10-15Hz）。仅在它们受到伤害时，动态地将更新频率提高到 33Hz，从而在保持响应速度的同时减少空闲带宽。这可以在玩家频繁交互期间平衡网络占用。
5. 优化服务器验证管线：确保服务器端伤害验证快速且轻量。如果服务器验证命中需要超过 100 毫秒，客户端 prediction buffer 很可能会超时，从而引发明显的 jitter。简化验证代码以最大程度地减少处理延迟。

总结与后续步骤

解决 replication desyncs 需要深入理解引擎的网络管线。通过在客户端预测已销毁的 actor 上抑制服务器属性更新，您可以消除 ghost builds，并为玩家提供无缝、高响应的体验。

准备好扩展您的 multiplayer backend 并减少同步问题了吗？免费试用 horizOn 或查阅 API docs，了解如何在您的下一个项目中实现低延迟会话管理。

---

来源：Ghost builds appear shortly after breaking wooden player build structures