★ FEATURED ARTICLE 1. 从一次联机延迟说起为什么RPC和属性同步是UE网络开发的分水岭做过UE联机项目的朋友大概率都遇到过这种场景本地跑得好好的角色一联机就出现“瞬移”“技能放空”“血条回跳”这类问题。排查半天代码逻辑没问题最后发现根子出在网络同步机制上——要么是RPC调用时机不对要么是属性同步的配置写错了。这类问题在单机开发阶段完全暴露不出来一旦进入多人环境就会集中爆发。RPC和属性同步是UE网络框架里最核心的两块基石。RPC负责“事件”的传递比如玩家按下技能键、触发一次交互、服务器广播一条消息属性同步负责“状态”的复制比如血量、位置、背包数量这些需要持续保持一致的数据。两者分工明确但实际项目里经常被混用导致带宽浪费、逻辑错乱、延迟感严重。这篇文章面向的是已经写过一些UE C或蓝图、准备深入联机开发的从业者也适合正在被同步问题折磨、想系统梳理一遍底层逻辑的开发者。我会从设计思路、核心机制、实操配置到问题排查把这两块内容拆开揉碎讲清楚尽量用项目里真实会遇到的场景来举例而不是停留在API文档的层面。2. 整体设计思路事件驱动与状态复制为什么要分开2.1 网络同步的本质是“让多台机器看到同一个世界”UE的网络模型是典型的客户端-服务器架构服务器是权威端客户端是表现端。服务器上跑着真正的游戏逻辑客户端负责输入采集和画面呈现。要让所有玩家看到一致的世界就必须解决两个问题一是“发生了什么”二是“现在是什么状态”。“发生了什么”对应事件比如A玩家开了一枪、B玩家捡起一个道具。这类信息是瞬时的、一次性的适合用RPC来传递。“现在是什么状态”对应数据比如每个角色的血量、位置、朝向。这类信息是持续的、需要不断校正的适合用属性同步来复制。把这两者分开设计好处非常明显。事件用RPC可以精确控制调用时机和目标避免每帧都去检查状态变化状态用属性同步可以自动处理增量复制和可靠性不需要手动写一堆同步代码。如果混在一起用比如用RPC去同步位置那每帧都要发RPC带宽直接爆炸反过来用属性同步去传递一次性事件又会出现事件被重复触发或者丢失的问题。2.2 RPC的三种类型与适用场景UE把RPC分成了三类这个分类不是随便定的背后对应的是不同的网络传输语义。Server RPC客户端调用服务器执行。典型场景是玩家输入比如按下跳跃键、使用技能。客户端没有权限直接修改游戏状态所以必须把意图发给服务器由服务器来裁决。Client RPC服务器调用指定客户端执行。典型场景是服务器通知某个客户端播放特效、显示UI提示。比如服务器判定玩家中毒了发一个Client RPC让该客户端播放中毒特效。NetMulticast RPC服务器调用所有客户端执行。典型场景是全局事件比如Boss登场、天气变化。这类事件所有玩家都要看到用多播最合适。这三种RPC的选择逻辑其实很简单谁有权限发起谁需要知道。客户端有输入权限但没有状态修改权限所以输入用Server RPC服务器有状态修改权限需要通知特定玩家就用Client RPC需要通知所有人就用NetMulticast。2.3 属性同步的可靠性设计与增量复制属性同步的核心是“服务器改客户端跟”。但UE并不是每帧把所有属性都发一遍那样带宽根本扛不住。它用的是增量复制加可靠性机制。增量复制的意思是只有属性值发生变化时才会同步。比如血量从100变成90服务器会把这个变化发给客户端。如果血量一直是100就不会产生同步流量。这个机制靠的是属性标记和脏标记系统服务器每帧检查哪些属性被标记为脏只同步这些。可靠性方面属性同步默认是可靠的但有一个例外如果某个属性在短时间内频繁变化UE可能会合并中间的更新只发最终值。这个设计是为了避免网络拥塞但也会导致客户端看不到中间过程。比如一个快速掉血再回血的技能客户端可能只看到最终血量中间的变化被合并了。如果业务逻辑依赖中间过程就需要用RPC来补充事件通知。2.4 为什么不能全用RPC或全用属性同步有些开发者图省事所有同步都用RPC结果就是每帧发大量RPC带宽飙升延迟增加。另一些开发者所有同步都用属性同步结果就是一次性事件被重复触发或者事件丢失。正确的做法是状态用属性同步事件用RPC。状态是持续的属性同步可以自动处理增量和可靠性事件是瞬时的RPC可以精确控制调用时机和目标。两者配合使用才能既保证一致性又控制带宽。举个例子角色释放技能。技能冷却时间、当前血量这些是状态用属性同步技能释放这个动作是事件用NetMulticast RPC通知所有客户端播放特效。如果全用属性同步客户端可能因为属性变化合并而看不到技能释放的瞬间如果全用RPC冷却时间这种需要持续校正的数据就得每帧发RPC完全不现实。3. 核心细节解析RPC配置与属性同步的实操要点3.1 RPC声明与实现的完整流程在UE C里声明一个RPC需要用到UFUNCTION宏配合Server、Client、NetMulticast关键字。这三个关键字决定了RPC的类型和调用方向。// Server RPC客户端调用服务器执行 UFUNCTION(Server, Reliable, WithValidation) void Server_UseSkill(int32 SkillId); // Client RPC服务器调用指定客户端执行 UFUNCTION(Client, Reliable) void Client_ShowDamageEffect(float DamageAmount); // NetMulticast RPC服务器调用所有客户端执行 UFUNCTION(NetMulticast, Unreliable) void Multicast_PlaySkillEffect(int32 SkillId);这里有几个关键点需要注意。Reliable和Unreliable决定RPC是否可靠。可靠的RPC会保证一定到达但会增加带宽和延迟不可靠的RPC可能会丢失但开销小。选择原则是关键逻辑用Reliable表现效果用Unreliable。WithValidation是Server RPC特有的用于在服务器端验证客户端传来的参数是否合法。这个机制非常重要因为客户端是可以被篡改的如果不做验证作弊者可以发送非法参数来破坏游戏逻辑。bool AMyCharacter::Server_UseSkill_Validate(int32 SkillId) { // 验证SkillId是否在合法范围内 return SkillId 0 SkillId MaxSkillCount; } void AMyCharacter::Server_UseSkill_Implementation(int32 SkillId) { // 服务器端执行技能逻辑 if (Skills.IsValidIndex(SkillId)) { Skills[SkillId]-Activate(); } }实现RPC时函数名必须加_Implementation后缀验证函数加_Validate后缀。这是UE的命名约定不遵守的话编译会报错。3.2 RPC的调用时机与常见陷阱RPC不是随便什么时候都能调的。最常见的坑是在Actor初始化阶段调用RPC这时候网络连接可能还没建立RPC会直接失败。另一个坑是在客户端调用Server RPC时如果这个客户端没有该Actor的权限RPC会被忽略。比如一个由服务器生成的Actor客户端没有它的所有权就不能调用它的Server RPC。解决方法是设置Actor的Owner或者用PlayerController来转发。还有一个容易被忽略的点是RPC的执行顺序。UE不保证RPC的到达顺序即使都是Reliable的RPC也可能因为网络路径不同而乱序到达。如果业务逻辑依赖顺序需要在RPC里带一个序列号在接收端做排序。注意在Actor的BeginPlay里调用RPC要特别小心因为BeginPlay在客户端和服务器上的执行时机不同。服务器上BeginPlay可能在网络连接建立之前就执行了这时候发RPC会丢失。稳妥的做法是在PlayerController的BeginPlay或者网络初始化完成后再发RPC。3.3 属性同步的声明与条件复制属性同步的声明比RPC简单用UPROPERTY宏加上Replicated关键字就行。UPROPERTY(Replicated, BlueprintReadOnly) float Health; UPROPERTY(ReplicatedUsing OnRep_Health) float MaxHealth;Replicated表示这个属性会被同步ReplicatedUsing可以指定一个回调函数在属性同步到客户端后执行。这个回调非常有用比如血量变化后更新UI、播放受击特效。void AMyCharacter::OnRep_Health() { // 血量同步到客户端后更新血条UI UpdateHealthBar(Health); }但要注意OnRep函数只在客户端执行服务器上不会调用。而且如果属性值没有变化OnRep也不会触发。所以不要在里面写必须每帧执行的逻辑。属性同步还需要在GetLifetimeReplicatedProps里注册否则不会生效。void AMyCharacter::GetLifetimeReplicatedProps(TArrayFLifetimeProperty OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMyCharacter, Health); DOREPLIFETIME_CONDITION(AMyCharacter, MaxHealth, COND_OwnerOnly); }DOREPLIFETIME是默认复制DOREPLIFETIME_CONDITION可以指定复制条件。COND_OwnerOnly表示只同步给拥有者适合那些只有自己需要知道的属性比如背包内容。COND_SkipOwner表示跳过拥有者适合那些自己不需要知道但别人需要知道的属性比如隐身状态。3.4 属性同步的性能优化条件复制与优先级属性同步虽然比RPC省带宽但如果配置不当也会成为性能瓶颈。优化的核心是减少不必要的同步。条件复制是第一层优化。除了COND_OwnerOnly和COND_SkipOwner还有COND_SimulatedOnly只同步给模拟代理不同步给拥有者、COND_AutonomousOnly只同步给自主代理等。根据属性的实际用途选择合适的条件可以大幅减少同步流量。第二层优化是同步优先级。UE允许给Actor设置NetPriority值越高同步频率越高。玩家角色应该比场景道具优先级高因为玩家角色的状态变化更频繁、更影响游戏体验。AMyCharacter::AMyCharacter() { NetPriority 3.0f; // 默认是1.0玩家角色设高一些 NetUpdateFrequency 30.0f; // 每秒同步30次默认是100 }NetUpdateFrequency控制同步频率默认100Hz对大多数游戏来说太高了。降到20-30Hz通常就够用能省不少带宽。但要注意降低频率会增加延迟感需要根据游戏类型权衡。竞技类游戏可能需要高一些休闲类游戏可以低一些。4. 实操过程从零搭建一个可同步的技能系统4.1 项目准备与网络模式配置先创建一个基础的UE C项目模板选第三人称。然后在项目设置里确认网络模式。UE默认支持客户端-服务器模式但需要在编辑器里设置Play模式为“Play As Listen Server”或者“Play As Client”才能模拟联机环境。在编辑器里点Play按钮旁边的小三角选“Advanced Settings”把“Play Number of Clients”设为2这样就能在一个编辑器里模拟一个服务器和一个客户端。这是调试网络同步最方便的方式比打包出来跑两个进程快得多。4.2 角色类的基础网络配置打开角色类的头文件先加上必要的网络配置。// MyCharacter.h #pragma once #include CoreMinimal.h #include GameFramework/Character.h #include MyCharacter.generated.h UCLASS() class MYGAME_API AMyCharacter : public ACharacter { GENERATED_BODY() public: AMyCharacter(); protected: virtual void BeginPlay() override; virtual void GetLifetimeReplicatedProps(TArrayFLifetimeProperty OutLifetimeProps) const override; // 血量属性带同步回调 UPROPERTY(ReplicatedUsing OnRep_Health, BlueprintReadOnly, Category Stats) float Health; // 最大血量只同步给拥有者 UPROPERTY(Replicated, BlueprintReadOnly, Category Stats) float MaxHealth; // 技能冷却时间所有客户端都需要知道 UPROPERTY(Replicated, BlueprintReadOnly, Category Skill) float SkillCooldown; UFUNCTION() void OnRep_Health(); public: // 请求使用技能Server RPC UFUNCTION(Server, Reliable, WithValidation) void Server_UseSkill(int32 SkillId); // 播放技能特效NetMulticast RPC UFUNCTION(NetMulticast, Unreliable) void Multicast_PlaySkillEffect(int32 SkillId); // 显示伤害数字Client RPC UFUNCTION(Client, Reliable) void Client_ShowDamageNumber(float Damage); };在构造函数里初始化属性值并设置网络相关参数。// MyCharacter.cpp AMyCharacter::AMyCharacter() { PrimaryActorTick.bCanEverTick true; Health 100.0f; MaxHealth 100.0f; SkillCooldown 0.0f; // 网络优先级和同步频率 NetPriority 3.0f; NetUpdateFrequency 30.0f; // 允许属性同步 bReplicates true; bAlwaysRelevant true; }bReplicates必须设为true否则这个Actor不会被同步。bAlwaysRelevant表示这个Actor始终与所有客户端相关适合玩家角色。如果是场景道具可以设为false让UE根据距离自动裁剪。4.3 属性同步的注册与回调实现在GetLifetimeReplicatedProps里注册需要同步的属性。void AMyCharacter::GetLifetimeReplicatedProps(TArrayFLifetimeProperty OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); // 血量同步给所有客户端 DOREPLIFETIME(AMyCharacter, Health); // 最大血量只同步给拥有者 DOREPLIFETIME_CONDITION(AMyCharacter, MaxHealth, COND_OwnerOnly); // 技能冷却同步给所有客户端 DOREPLIFETIME(AMyCharacter, SkillCooldown); }实现血量的同步回调。void AMyCharacter::OnRep_Health() { // 只在客户端执行 if (IsLocallyControlled()) { // 更新本地UI UpdateHealthUI(Health); } // 播放受击特效 if (Health MaxHealth) { PlayHitEffect(); } }这里用IsLocallyControlled判断是否是本地控制的角色因为UI通常只需要更新自己的。但受击特效所有客户端都要看到所以放在判断外面。4.4 Server RPC的实现与验证实现技能使用的Server RPC。bool AMyCharacter::Server_UseSkill_Validate(int32 SkillId) { // 验证技能ID是否合法 if (SkillId 0 || SkillId 10) { return false; } // 验证冷却是否结束 if (SkillCooldown 0.0f) { return false; } return true; } void AMyCharacter::Server_UseSkill_Implementation(int32 SkillId) { // 服务器端执行技能逻辑 // 设置冷却 SkillCooldown 5.0f; // 广播技能特效 Multicast_PlaySkillEffect(SkillId); // 如果技能造成伤害通知目标客户端 // 这里简化处理假设对自身造成10点伤害 Health - 10.0f; // 如果血量低于0处理死亡 if (Health 0.0f) { Health 0.0f; // 处理死亡逻辑 } }验证函数里做了两层检查技能ID是否在合法范围内冷却是否结束。这两层检查缺一不可因为客户端可能被篡改发送非法ID或者绕过冷却。4.5 NetMulticast RPC与Client RPC的配合使用实现技能特效的多播和伤害数字的客户端RPC。void AMyCharacter::Multicast_PlaySkillEffect_Implementation(int32 SkillId) { // 所有客户端都会执行包括服务器 // 播放技能特效 if (SkillEffects.IsValidIndex(SkillId)) { UGameplayStatics::SpawnEmitterAtLocation( GetWorld(), SkillEffects[SkillId], GetActorLocation(), GetActorRotation() ); } } void AMyCharacter::Client_ShowDamageNumber_Implementation(float Damage) { // 只有指定的客户端会执行 // 显示伤害数字UI ShowDamageNumberWidget(Damage); }多播RPC在所有客户端执行适合特效这种所有人都要看到的内容。Client RPC只在指定客户端执行适合伤害数字这种只有自己需要看到的内容。4.6 在蓝图中调用与调试在角色蓝图里可以这样调用技能// 在输入绑定里调用 void AMyCharacter::OnSkillPressed() { // 客户端调用Server RPC if (IsLocallyControlled()) { Server_UseSkill(0); } }调试网络同步时可以在控制台输入以下命令net.ShowReplicatedProperties显示当前同步的属性net.NetworkProfiler打开网络分析器stat net显示网络统计信息这些命令在PIE模式下非常有用可以实时看到哪些属性在同步、带宽占用多少。5. 常见问题与排查技巧实录5.1 RPC不执行或执行多次的排查思路RPC不执行是最常见的问题排查时按以下顺序检查检查项可能原因解决方法Actor是否有Owner没有Owner的Actor无法调用Server RPC设置Actor的Owner为PlayerController是否在客户端调用Server RPC只能在客户端调用确认调用端是客户端网络连接是否建立初始化阶段网络未就绪延迟到网络初始化完成后再调用函数是否标记为Reliable不可靠RPC可能丢失关键逻辑改用Reliable是否在服务器上调用Client RPCClient RPC只能在服务器调用确认调用端是服务器RPC执行多次通常是因为在Tick里调用了RPC或者RPC被重复绑定。检查Tick逻辑确保RPC只在事件触发时调用一次。5.2 属性同步延迟或不同步的常见原因属性同步延迟通常是因为NetUpdateFrequency设得太低或者网络拥塞。可以适当提高频率但要注意带宽限制。属性不同步的原因比较多常见的有忘记在GetLifetimeReplicatedProps里注册bReplicates没有设为true属性在客户端被修改导致服务器和客户端不一致条件复制设置错误导致该收到的人没收到提示属性同步是单向的只能从服务器同步到客户端。客户端修改属性不会影响服务器而且会在下一次同步时被覆盖。所有状态修改都必须在服务器端进行。5.3 带宽优化与同步频率调优带宽优化是个持续的过程以下是一些实用的调优技巧降低NetUpdateFrequency从默认的100降到20-30使用条件复制减少不必要的同步对不重要的Actor设置bOnlyRelevantToOwner使用NetPriority区分重要程度对频繁变化的属性做量化处理比如位置精度从float降到int16可以用stat net命令查看当前带宽占用找出占用最高的Actor和属性针对性优化。5.4 联机调试的实用技巧与工具PIE模式下的多客户端调试是最方便的但有些问题只在真实网络环境下才会出现。可以用以下方法模拟真实网络在编辑器里设置网络模拟参数模拟延迟和丢包使用Net PktLag和Net PktLoss命令动态调整打包出来跑两个进程用局域网连接调试时建议打开net.ShowReplicatedProperties可以直观看到哪些属性在同步、同步频率是多少。这个命令在排查属性同步问题时非常有用。6. 我个人在实际项目中的几点体会RPC和属性同步这块我踩过的坑主要集中在两个地方一是RPC的调用时机二是属性同步的条件配置。早期项目里经常在BeginPlay里发RPC结果客户端收不到排查了半天才发现是网络还没建立。后来养成了习惯所有网络相关的初始化都放到PlayerController的BeginPlay或者网络初始化回调里。属性同步的条件复制也是容易出错的地方。有一次给背包物品设置了COND_OwnerOnly结果其他玩家看不到装备的外观排查后发现装备外观需要同步给所有人而背包内容只需要同步给拥有者。这两个属性混在一起配置就出了问题。后来我把属性按用途分类表现类的用默认复制数据类的用条件复制清晰了很多。还有一个经验是不要过度依赖属性同步来传递事件。属性同步适合状态不适合事件。事件用RPC状态用属性同步这个原则坚持下来网络逻辑会清晰很多。如果发现某个属性变化需要触发客户端逻辑优先考虑用RPC而不是OnRep回调因为OnRep可能因为属性合并而丢失中间状态。最后分享一个小技巧在开发阶段把NetUpdateFrequency设高一点方便调试在发布前再降下来优化带宽。这样既能保证开发效率又能保证最终性能。
阅读完成 · 觉得有帮助？
