UE5.8 Gameplay Cues 同步与表现 - 和平哥的学习笔记

从一个早晨的 bug 说起

小林上周刚把角色的受击闪光接进 GAS。他在 GA_HitReaction 里调了一段播放 Niagara 的逻辑，本地测试一切正常，特效、音效、震屏都准时出现。周五合进测试分支后，策划跑来拍桌子：多人对战里，客户端看到的闪光要么慢半拍，要么干脆没有，偶尔还会连闪三次。

我跟着他一起看了一上午。问题很典型：表现逻辑和伤害判定写在了同一个地方，网络同步的权限又没理清楚。服务器只关心血量扣多少，客户端却拿着这份伤害事件去播放特效，延迟、丢包、权限错乱全赶上了。

Gameplay Cues 就是 Epic 给这类问题准备的答案。它把「发生了什么」和「看起来发生了什么」拆成两条线，让服务器继续算它的数值，客户端专心把效果演好。这篇文章把我们在 UE5.8 里踩过的坑整理一遍，从概念到实现，再到同步和优化，全部摊开讲。

表现与逻辑分离：Gameplay Cue 的定位

GAS 里，Gameplay Effect 负责改变属性、施加标签、触发 Gameplay Ability。这些都是规则层面的东西，服务器说了算。但玩家眼睛看到的闪光、听到的音效、屏幕的震动，本质上属于表现层，不该混在规则里。

Gameplay Cue 就是 GAS 的表现层接口。它由 Gameplay Effect 或 Ability 触发，在客户端上执行 Niagara、音效、震屏、Post Process 这些纯视觉听觉操作。服务器可以通知客户端去播放某个 Cue，但具体怎么演、演多久、用什么资源，由 Cue 自己决定。

这种拆分带来几个实际好处。第一，网络流量变干净。服务器只需要说「这个对象被冰冻了」，不需要传送粒子系统的每一帧参数。第二，权限变得简单。表现只在本地客户端处理，不需要做 server RPC 去同步每一束火花。第三，复用性变高。同一个受击 Cue 可以被近战、陷阱、环境伤害共用，只要它们挂上同一个 Gameplay Cue Tag。

Cue Tag 的规划最好在项目早期就定下来。我见过有团队把 Tag 命名为 GameplayCue.Skill.FireSword.Hit、GameplayCue.Skill.IceArrow.Hit，每个技能一个 Tag。结果后期想做统一的受击闪白就麻烦了，因为每个 Tag 都要单独处理。更好的做法是分层：GameplayCue.Damage.Hit 作为通用受击，下面再挂 GameplayCue.Damage.Fire、GameplayCue.Damage.Ice 作为元素差异。通用表现走父 Tag，个性表现走子 Tag，维护起来轻松很多。

下面这张图把 GAS 里的两层拆开来看。

architecture-beta
    group ue(engine)[UE5.8 Gameplay Ability System]

    service gameplay_effect[Gameplay Effect] in ue
    service gameplay_ability[Gameplay Ability] in ue
    service gameplay_cue[Gameplay Cue] in ue
    service attributes[Attribute Set] in ue
    service niagara[Niagara System] in ue
    service audio[Audio Component] in ue
    service camera[Camera Shake] in ue

    gameplay_effect:Server Logic
    gameplay_ability:Server Logic
    attributes:Server Logic
    gameplay_cue:Presentation Layer
    niagara:Presentation Layer
    audio:Presentation Layer
    camera:Presentation Layer

    gameplay_effect:T -- B:attributes
    gameplay_ability:T -- B:attributes
    gameplay_effect:R -- L:gameplay_cue
    gameplay_ability:R -- L:gameplay_cue
    gameplay_cue:R -- L:niagara
    gameplay_cue:R -- L:audio
    gameplay_cue:R -- L:camera

图里左边是规则层，右边是表现层。Gameplay Cue 是中间那道门，所有从规则层过来的通知都先经过它，再分发到具体的 Niagara、音效或者震屏组件。这道门很重要，后面讲同步和优化时你会反复看到它。

AddGameplayCue 与 ExecuteGameplayCue

UE 提供了两个主要入口来触发 Gameplay Cue：AddGameplayCue 和 ExecuteGameplayCue。名字只差一个词，行为却完全不同，用错地方就会出小林那种连闪三次的 bug。

AddGameplayCue 是持续性的。调用之后，Cue 会挂在目标身上，只要对应的 Gameplay Effect 还在，Cue 就一直存在。它适合用来表现持续状态，比如燃烧、冰冻、护盾光环。对应的移除时机由 GAS 自动管理，Effect 结束或被移除时，Cue 也会跟着走。

ExecuteGameplayCue 是一次性的。它触发一次 OnExecute，播完就结束，不会留下任何持续状态。适合用来表现瞬时事件，比如爆炸、受击闪光、弹着点火花。

两者的底层网络行为也不一样。AddGameplayCue 会跟随 Gameplay Effect 的同步，客户端收到 Effect 激活时自动创建 Cue，Effect 移除时自动销毁。ExecuteGameplayCue 则走一条独立的 RPC 路径，服务器会显式通知所有相关客户端执行一次。

我们用一张流程图把这两个路径画出来。

flowchart TD
    A[Gameplay Effect Spec 生效] --> B{是否携带 Gameplay Cue Tag?}
    B -->|是| C[解析 Cue 类型]
    C --> D{Add 还是 Execute?}
    D -->|AddGameplayCue| E[创建 GameplayCueNotify 实例]
    E --> F[调用 OnActive / OnApply]
    F --> G[持续表现: BUFF 光环/灼烧]
    G --> H[Gameplay Effect 结束或被移除]
    H --> I[调用 OnRemove / OnDeactivate]
    I --> J[销毁 Cue 实例]
    D -->|ExecuteGameplayCue| K[单次触发 OnExecute]
    K --> L[瞬时表现: 受击闪光/爆炸]
    L --> M[立即释放]

小林一开始把受击闪光写成了 AddGameplayCue，结果每次伤害事件都会添加一个持续 Cue，而移除逻辑又没写对，Cues 越堆越多，客户端自然就连闪。改成 ExecuteGameplayCue 后，一次伤害只闪一次，世界清净了。

// 持续性 BUFF 光环，适合 AddGameplayCue
UAbilitySystemBlueprintLibrary::AddGameplayCue(
    TargetCharacter,
    FGameplayTag::RequestGameplayTag(FName("GameplayCue.Buff.ShieldAura")),
    EffectContext);

// 受击闪光，适合 ExecuteGameplayCue
UAbilitySystemBlueprintLibrary::ExecuteGameplayCue(
    TargetCharacter,
    FGameplayTag::RequestGameplayTag(FName("GameplayCue.Damage.HitFlash")),
    EffectContext);

这两行代码本身不难，关键是想清楚你要的是一段持续状态，还是一个瞬时事件。这个判断做对了，后面同步和性能的问题会少很多。

GameplayCueNotify 与 GameplayCueNotify_Actor

触发 Cue 之后，真正干活的是 GameplayCueNotify 或 GameplayCueNotify_Actor。前者是 UObject 派生，轻量，适合附着在目标 Skeletal Mesh 上播放特效；后者是 AActor 派生，有完整的生命周期和世界位置，适合需要在场景中独立存在的爆炸、范围光环。

GameplayCueNotify 最常见的子类是 GameplayCueNotify_Burst 和 GameplayCueNotify_Looping。Burst 就是一次性爆发，比如击中敌人时的火花。Looping 会持续播放，直到 Cue 被移除，比如护盾光环、灼烧粒子。

GameplayCueNotify_Actor 更独立。它可以在世界任意位置生成，处理更复杂的时序，比如爆炸后先闪光、再震屏、再留下一个持续伤害区域。因为它是一个真正的 Actor，所以可以使用 Root Component、Timeline、Collision，甚至再触发其他 Ability。

我们用一个序列图展示这两类 Notify 的激活过程。

sequenceDiagram
    participant S as Server
    participant ASC as AbilitySystemComponent
    participant C as Client
    participant CN as GameplayCueNotify
    participant CNA as GameplayCueNotify_Actor

    S->>ASC: Apply Gameplay Effect
    ASC->>ASC: 计算 Cue 集合
    ASC->>C: Replicate Effect Spec + Cue Tags
    C->>CN: 实例化 GameplayCueNotify
    CN->>CN: OnActive / OnExecute
    CN->>C: 绑定到 Skeletal Mesh Socket
    CN->>C: 触发 Niagara / 音效
    alt 需要独立 Actor
        C->>CNA: Spawn GameplayCueNotify_Actor
        CNA->>CNA: 设置世界位置/旋转
        CNA->>CNA: 执行 Timeline 或多阶段效果
    end
    ASC->>C: Effect Removed
    C->>CN: OnRemove / OnDeactivate
    C->>CNA: Destroy

这里有一个细节容易忽略：GameplayCueNotify 默认只在客户端实例化，服务器上不存在对应的 UObject。如果你在服务器端调用 AddGameplayCue，GAS 会把 Tag 同步下去，客户端收到后再创建实例。GameplayCueNotify_Actor 也遵循同样的原则，只在客户端生成，服务器不会为它付出 Actor 同步开销。

小林的项目里，爆炸特效一开始用的是 Niagara Component 直接 Attach 到角色上，结果角色移动时火花跟着跑，看起来很假。换成 GameplayCueNotify_Actor 后，在世界位置生成，爆炸点就定在原地，效果好了一大截。

网络同步与权限

这是 GAS 最容易让人头大的部分。Gameplay Cue 的同步遵循一个核心原则：服务器决定发生什么，客户端决定怎么看。

Gameplay Effect 本身会从 Authority 同步到 Owning Client 和 Simulated Proxies。AddGameplayCue 借助这个同步路径，自动到达所有需要看到的客户端。ExecuteGameplayCue 则通过 AbilitySystemComponent::ExecuteGameplayCue 内部的 RPC 广播给相关客户端。

但这里有几个权限细节必须注意。

第一，调用 ExecuteGameplayCue 的位置必须是 Authority。在客户端调用不会自动传到服务器，也不会广播给其他客户端。如果你在做本地预测，客户端可以先执行一次本地 Cue，但 authoritative 的那一次必须由服务器发起。

第二，Cue 的触发条件会检查目标 Tag。如果 Cue 关联的 Gameplay Effect 被目标免疫，或者目标在服务器端被判定为不可见，Cue 不会同步到该客户端。

第三，GameplayCueSet 里的 Cue 数量不要无限增长。每个 Gameplay Effect Spec 都会带一个 Cue 列表，如果这个列表太大，同步包也会变大。 Epic 建议在项目早期就规划好 Cue Tag 的命名空间，比如 GameplayCue.Damage.Fire、GameplayCue.Buff.Heal，而不是给每个技能都造一个独立 Tag。

Owning Client 和 Simulated Proxy 看到的表现可以不一样。比如玩家自己被打，需要强烈的震屏和闪白；远处一个队友被打，也许只需要一个轻量的受击特效，甚至只播音效。这个差异可以在 GameplayCueNotify 里通过判断 MyTarget 的 Role 和本地控制器关系来实现。不要在服务器上做这种区分，服务器只发统一的 Cue Tag，具体弱化多少由客户端自己决定。

我们用一张图展示同步的数据流。

graph LR
    A[Server Authority] -->|Effect Spec + Cue Tags| B[Owning Client]
    A -->|Effect Spec + Cue Tags| C[Simulated Proxy Client]
    B -->|本地实例化| D[GameplayCueNotify]
    C -->|本地实例化| D
    D -->|播放| E[Niagara]
    D -->|播放| F[Sound]
    D -->|触发| G[Camera Shake]
    B -.->|预测性本地 Cue| H[Local FX]
    H -.->|服务器校正| A

图里实线是权威同步，虚线是本地预测。预测这条线后面会详细讲，这里先记住：客户端可以偷跑，但最终要听服务器的。

同步延迟可以用一个简单公式描述。设服务器触发 Cue 的时刻为 $T_{server}$ ，客户端收到并播放的时刻为 $T_{client}$ ，那么：

$T_{client} = T_{server} + \frac{RTT}{2} + \delta_{jitter}$

其中 $RTT$ 是往返时延， $\delta_{jitter}$ 是网络抖动。这个延迟对受击反馈影响很大。格斗游戏里 100ms 的延迟就能让玩家觉得手感发黏，所以才有了后面要说的本地预测。

与 Niagara、音效、震屏的联动

Gameplay Cue 本身不绑定任何具体表现，它只是通知。真正干活的是 Niagara、Audio、Camera Shake 这些子系统。UE5.8 里，GameplayCueNotify_Burst 可以直接配置 Niagara System、Sound Cue、Camera Shake、Decal，甚至 Force Feedback。对于 looping Cue，还支持 Niagara System Looping 和 Sound Looping。

小林的项目里，战士的护盾光环是一个持续 Cue。我们在 GameplayCueNotify_Looping 里挂了一个 Niagara System，Tag 为 GameplayCue.Buff.ShieldAura。Effect 激活时，Niagara 自动出现在角色脚下；Effect 移除时，Niagara 停止发射并进入死亡阶段，优雅退场。

震屏的处理要稍微小心。Camera Shake 是本地客户端的体验，不同玩家对震屏强度偏好不同。我们把它放在 GameplayCueNotify 里，而不是 Ability 里，这样只有真正看到这次攻击的玩家才会震。同时可以在设置里给玩家一个强度滑块，乘到 Camera Shake 的 Scale 上。

音效的同步有一个常见坑。3D Sound 的位置由 Cue 的 Spawn Location 决定。如果 Cue Attach 到角色上，而角色在高速移动，音源位置会跟着跑。对于爆炸这种应该定在原地的效果，要用 GameplayCueNotify_Actor，并把 Sound 的 Attenuation 调好，避免声音忽远忽近。

下面是一个简化但完整的 GameplayCueNotify_Burst 配置思路，代码不多，主要是展示调用链。

// 在 GameplayCueNotify_Burst 子类里重写 OnBurst
UFUNCTION(BlueprintCallable, Category = "GameplayCue")
void OnBurst(AActor* MyTarget, const FGameplayCueParameters& Parameters)
{
    Super::OnBurst(MyTarget, Parameters);

    const FVector SpawnLocation = Parameters.EffectContext.GetHitResult()->ImpactPoint;
    const FRotator SpawnRotation = Parameters.EffectContext.GetHitResult()->ImpactNormal.Rotation();

    UNiagaraFunctionLibrary::SpawnSystemAtLocation(
        this, ExplosionSystem, SpawnLocation, SpawnRotation);

    UGameplayStatics::PlaySoundAtLocation(
        this, HitSound, SpawnLocation, 1.0f, 1.0f, 0.0f, HitAttenuation);

    APlayerController* PC = UGameplayStatics::GetPlayerController(this, 0);
    if (PC && PC->IsLocalController())
    {
        PC->ClientStartCameraShake(HitCameraShake, 1.0f);
    }
}

这段代码只有十几行，但它把 Niagara、音效、震屏三件事串在了一起。注意最后一行检查了 IsLocalController，确保只有本地玩家才会震屏。这个检查不难，漏掉的话就会出现其他玩家震你的屏这种离谱 bug。

性能优化：GC 过多怎么办

Gameplay Cue 用多了，Profiler 里会看到两个常客：Spawn Actor 开销和 UObject 创建开销。尤其是快节奏游戏里，每一刀都带一个 ExecuteGameplayCue，每秒可能创建几十个临时 UObject。

优化的思路分几条。

第一条，区分 Burst 和 Looping，不要把一次性事件做成 Looping。Looping Cue 会持有 Niagara Component 直到 Effect 结束，生命周期长，内存占用也高。Burst Cue 播完就释放，压力小很多。

第二条，复用 Niagara Component。GameplayCueNotify_Burst 内部会在目标身上临时创建 Niagara Component，如果同一帧触发大量相同 Cue，可以考虑池化。Epic 在 UE5.4 之后对 Niagara Component 的创建路径做了不少优化，但如果你的项目还是吃紧，可以自己在 Cue 里维护一个 Niagara Component Pool。

第三条，减少 Cue 同步次数。ExecuteGameplayCue 会发一次 RPC，如果同一帧有多个 Effect 都触发同一个 Cue，GAS 会尝试合并。你可以利用这个机制，把同类型的视觉反馈集中到一次 Cue 里。

第四条，控制 Cue 可见距离。大世界或者多人游戏里，远处的爆炸特效完全可以不播。可以在 Cue 里根据距离做 LOD，或者直接让服务器不往远距离客户端同步这个 Effect。

我们用一张关系图把优化方向串起来。

graph TD
    A[Gameplay Cue 性能问题] --> B[GC 频繁]
    A --> C[同步包大]
    A --> D[渲染压力大]
    B --> E[误用 Looping 做 Burst]
    B --> F[Niagara Component 创建过多]
    C --> G[单个 Effect 带太多 Cue Tag]
    C --> H[高频 ExecuteGameplayCue]
    D --> I[全距离播放]
    D --> J[粒子发射数过高]
    E --> K[改用 Burst]
    F --> L[组件池化]
    G --> M[精简 Cue Tag]
    H --> N[合并同类 Cue]
    I --> O[按距离裁剪]
    J --> P[降低 Niagara Budget]

实际调优时，先用 stat gameplaycue 和 Niagara 的 Stat 命令定位热点。如果是 UObject 创建过多，检查 Looping 数量；如果是网络带宽高，检查 Effect Spec 带的 Cue Tag 数量；如果是 GPU 压力大，检查 Niagara 的发射率和屏幕覆盖面积。

几个我常用的排查命令：在控制台输入 stat gameplaycue 可以看到当前激活的 Cue 数量和类型分布；stat niagara 会列出 Niagara 的 CPU 和 GPU 开销；net stat 配合 Packet Lag 模拟可以观察高延迟下 Cue 是否还会正确触发。发现 Looping Cue 泄漏时，重点查 Gameplay Effect 的 Duration Policy 和移除条件，很多泄漏是因为 Effect 没有正确结束，而不是 Cue 本身的问题。

小林的项目里，我们一开始把每次暴击都做成了 GameplayCueNotify_Actor，结果一打群架帧率掉到 35。改成 Burst 后，只有真正需要长时间留存的技能才用 Actor，帧率回到了 58。这个取舍没有固定答案，得看具体效果需要持续多久、占用多少资源。

本地预测与服务器校正

最后聊聊本地预测。网络延迟客观存在，玩家按下攻击键后，如果等服务器回包再播特效，手感会明显发飘。格斗、射击、动作游戏一般都会让客户端先执行本地反馈，同时把输入发给服务器，服务器权威判定后再校正。

Gameplay Cue 也可以走预测路径。客户端在本地先 ExecuteGameplayCue，给玩家一个即时反馈。服务器收到请求后做真正的伤害判定，再向客户端广播 authoritative 的 Cue。如果客户端的预测和服务器结果一致，玩家什么异样都感觉不到；如果不一致，比如服务器判定这次攻击被闪避了，客户端需要把错误的本地 Cue 清理掉。

这个清理在 GAS 里通常通过 RemoveGameplayCue 或者 FActiveGameplayEffectHandle 实现。预测时创建的 Cue 最好带上一个 Predictive 标签，方便后面识别和撤销。

本地预测有一个代价：它会让客户端多播一次 Cue。对受击闪光这种单次反馈，问题不大；对爆炸、范围伤害这种影响多个目标的效果，要谨慎使用预测，避免客户端看到一次假的爆炸。

我们用一张序列图展示预测流程。

sequenceDiagram
    participant LC as Local Client
    participant S as Server
    participant OC as Owning Client
    participant SP as Simulated Proxy

    LC->>LC: 玩家输入攻击
    LC->>LC: 预测性播放 GameplayCue
    LC->>S: Send Gameplay Ability Input
    S->>S: 权威判定命中
    S->>OC: RPC ExecuteGameplayCue
    S->>SP: RPC ExecuteGameplayCue
    OC->>OC: 播放权威 Cue
    SP->>SP: 播放权威 Cue
    alt 预测命中但服务器未命中
        S->>LC: 校正：未命中
        LC->>LC: 移除预测 Cue
    end

公式化地说，预测的误差可以用 $E = |P_{predict} - P_{server}|$ 表示，其中 $P_{predict}$ 是客户端预测结果， $P_{server}$ 是服务器权威结果。当 $E = 0$ 时，预测成功；当 $E > 0$ 时，需要回滚或补偿。动作游戏里，这个 $E$ 的主要来源是命中判定、移动插值和网络延迟。

UE5.8 的 AbilitySystemComponent 对预测的支持已经比较成熟，但 Gameplay Cue 的预测仍然需要你自己管理生命周期。我的建议是：只在玩家自己的控制器上做预测，且只针对即时反馈；对于影响世界状态的效果，比如爆炸破坏场景，老老实实等服务器回包。

回滚错误预测有一个稳妥的做法：给预测 Cue 加一个 Predictive 标签，比如 GameplayCue.Damage.HitFlash.Predictive。收到服务器校正后，遍历 ASC 上所有带这个标签的 Cue，调用 RemoveGameplayCue 清理。不要直接清理所有同类型 Cue，否则可能把服务器刚播的正确 Cue 也清掉。小林项目早期就踩过这个坑，一击被闪避后，连之前几刀命中的闪光也一起没了，看起来像角色在鬼畜。

写在最后

Gameplay Cues 不是 GAS 里最耀眼的部分，但它是把一套技能系统从「能跑」变成「好看、好打、好同步」的关键。小林的项目在经历了受击闪光不同步、BUFF 光环不消失、爆炸特效乱飘这几个典型问题后，我们把所有表现层逻辑都迁到了 Gameplay Cue 上，服务器的代码一下子干净了不少。

几个我自己会反复检查的点：

持续效果用 Add，瞬时效果用 Execute，别混。
需要 attach 到角色身上的用 GameplayCueNotify，需要独立在世界里的用 GameplayCueNotify_Actor。
震屏、音效这些本地体验一定要加 LocalController 判断。
高频 Cue 优先 Burst，必要时做池化或按距离裁剪。
本地预测能带来手感提升，但要给错误预测留好回滚路径。

GAS 的设计哲学一直很明确：服务器管规则，客户端管表现。Gameplay Cues 就是这条边界上的守门人。把它用顺了，多人项目的技能表现会稳很多。