7. 优化(Optimizations)

7.1 Ability 批处理（Ability Batching）

在一个帧内激活、可选地发送TargetData到服务器并结束的GameplayAbilities可以通过批处理将两到三个RPC合并为一个RPC。这些类型的能力通常用于命中扫描枪。

7.2 Gameplay Cue 批处理（Gameplay Cue Batching）

如果您同时发送许多GameplayCues，请考虑将它们批处理为一个RPC。目标是减少RPC的数量（GameplayCues是不可靠的NetMulticasts）并尽可能少地发送数据。

7.3 AbilitySystemComponent 同步模式（AbilitySystemComponent Replication Mode）

默认情况下，ASC处于Full Replication Mode。这将所有GameplayEffects同步到每个客户端（这对于单人游戏是可以的）。在多人游戏中，将玩家拥有的ASCs设置为Mixed Replication Mode，将AI控制的角色设置为Minimal Replication Mode。这将使应用于玩家角色的GEs仅同步到该角色的所有者，而应用于AI控制角色的GEs将永远不会同步到客户端。GameplayTags仍将同步，GameplayCues仍将是不可靠的NetMulticast到所有客户端，无论Replication Mode如何。这将减少不需要所有客户端看到的GEs的网络数据。

7.4 Attribute 代理同步（Attribute Proxy Replication）

在像《堡垒之夜》（Fortnite）这样的大型多人游戏中，会有许多ASCs存在于始终相关的PlayerStates上同步大量的Attributes。为了优化这个瓶颈，堡垒之夜禁用了ASC及其AttributeSets在模拟玩家控制代理上的同步，位于PlayerState::ReplicateSubobjects()中。自主代理和AI控制的Pawns仍然根据其Replication Mode完全同步。相反，堡垒之夜在玩家的Pawn上使用一个同步的代理结构。当服务器的ASC上的Attributes发生变化时，它们也会在代理结构上发生变化。客户端从代理结构接收同步的Attributes并将更改推送回其本地ASC。这允许Attribute同步使用Pawn的相关性和NetUpdateFrequency。这个代理结构还同步一个小的白名单GameplayTags集作为位掩码。这种优化减少了网络上的数据量，并允许我们利用pawn的相关性。AI控制的Pawns将其ASC放在Pawn上，已经使用其相关性，因此不需要这种优化。

我不确定在其他服务器端优化（如同步图等）之后是否仍然有必要，并且这不是最可维护的模式。

Epic的Dave Ratti对社区问题#3的回答

7.5 ASC 延迟加载（ASC Lazy Loading）

《堡垒之夜》（Fortnite）世界中有许多可损坏的AActors（树木、建筑物等），每个都有一个ASC。这可能会增加内存成本。堡垒之夜通过仅在需要时（当它们首次受到玩家伤害时）延迟加载ASCs来优化这一点。这减少了整体内存使用，因为在一场比赛中某些AActors可能永远不会受到伤害。