最近总有朋友问我用UE5做双人或者四人Coop合作游戏网络同步到底该从哪下手。这个问题我比较有发言权因为早期做多人Demo的时候我把同步做成了“哪哪都对不上”主机看到门开了客户端的门纹丝不动队友倒地了救援进度条只有施救者自己能看见。后来把UE5的同步机制完整捋了一遍才明白Coop玩法要稳核心就一句话所有玩家共享的“事实”都必须在服务器上发生客户端只负责输入、预测和表现。这篇文章围绕UE5网络同步与Coop实现把架构、属性同步、RPC、移动和动画同步、调试排错串成一条能直接落地的链路。适合两类人一是刚开始做多人Coop、想搞懂同步基本盘的开发二是功能写完了但发现“不同步”问题一堆的老哥照着排查思路能省不少时间。1. Coop项目先想清楚服务端权威模型与游戏架构1.1 为什么Coop必须服务端权威Coop和竞技在同步上的侧重点不太一样。竞技游戏可以靠大量客户端预测来保证手感击杀判定最终由服务器兜底而Coop更注重全队共享状态任务阶段、Boss血量、门有没有开、队友能不能被救。这些状态如果由每个客户端自己算大家看到的世界就完全分叉了。服务端权威模型的意思是服务器拥有所有关键状态的最终决定权客户端只是发送输入、显示服务器广播的结果。UE5的多人框架从根上就是按这个思路设计的GameMode在服务器上跑Actor的属性需要勾选Replicated才会被广播客户端调用Server RPC也只是“请求服务器做事”真正改状态的一定是服务器。我见过不少朋友在单人Demo里逻辑全写在BeginPlay一到多人就翻车。原因很简单BeginPlay在客户端也会执行你辛辛苦苦算的刷怪逻辑每个客户端各算一遍结果自然不同步。做Coop时拿到一个共享Actor第一反应应该是看当前端有没有权威。蓝图里用Has Authority节点判断或者用Get Local Role看一下是不是Authority这比靠猜靠谱得多。1.2 GameMode、GameState、PlayerState 怎么分工Coop项目最容易乱的就是这几个类各管什么。我的经验是先想清楚状态的作用域再决定放在哪个类里顺序不能颠倒。GameMode只存在于服务器负责游戏规则、角色生成、回合倒计时、复活逻辑。Coop里“这一波刷几个怪”“玩家全灭后怎么判定失败”“比赛结束后切到结算界面”这类流程控制都放这里。客户端拿不到GameMode实例所以不要尝试在客户端调用GameMode函数你调不到。GameState全局存在服务器和所有客户端都有一份且会在所有客户端之间保持同步。适合放“当前任务阶段”“团队总进度”“Boss血量”“地图可打开的门列表”。比如合作任务里要求两队推进度进度值放GameState最稳因为它的生命周期覆盖整个关卡不会因为某个Actor被销毁就丢数据。PlayerState是每个玩家一份所有客户端都能看到适合放玩家昵称、角色类型、个人金币、倒地状态。Coop中常见错误是把“玩家倒地了没”放在Character上然后通过复杂引用去读实际上放PlayerState更合适即使角色重生了PlayerState还在。PlayerController是玩家与服务器之间的桥梁在服务器和该玩家自己的客户端都有。本地输入、HUD、相机控制放PC没问题但跨玩家共享的数据不要塞在PC里因为每个PC只属于一个玩家其他客户端不便读取。1.3 复制标志、网络角色与生成规则在Coop项目里Actor能不能共享给所有玩家取决于两个设置Replicates和Replicate Movement。前者决定属性是否参与复制后者决定MovementComponent是否自动同步位置和旋转。注意Replicates勾选后不是立刻全局广播它表示这个Actor“有资格”被复制具体还要看网络相关性、更新频率这些参数。理解网络角色也很关键。打开Actor的Role和RemoteRole主要会遇到这几种情况Authority当前端对这个Actor有最终控制权。服务器上绝大多数Actor是Authority单机时也是。AutonomousProxy拥有者客户端的Pawn是这个状态。本地玩家控制自己的角色时有输入预测权限。SimulatedProxy其他玩家看到的角色只能接收位置和动画状态不能自行修改。本地方是Authority别人看到的就是SimulatedProxy。排查“为什么只有我看得到这个Actor”时先看Role是不是Authority再看Spawn是不是发生在服务器。还有一个容易被忽略的规则需要共享的Actor必须由服务器Spawn。如果客户端直接SpawnActor即便勾了Replicates引擎也可能警告甚至不同步。Coop里刷怪、掉落物、可交互机关都必须在服务器生成然后引擎负责把生成通知和初始状态广播给客户端。本地只做纯装饰的特效Actor可以客户端Spawn但不要让它承载游戏逻辑。2. 属性同步与RepNotify让世界状态保持一致2.1 属性同步的原理和触发现象属性同步是Coop中最高频用到的手段。服务器修改一个勾选了Replicated的变量引擎会按Net Update Frequency把脏属性打包发送到客户端客户端收到值变化后更新本地。这里的“脏属性”不是每帧都发而是按网络更新频率批量处理。所以频率越高越及时但也越耗带宽。如果想让客户端在收到新值时执行逻辑比如更新血条UI、播放开门动画就需要RepNotify。在蓝图里把变量设为Replicated Using指定一个回调函数客户端在该变量值变化时会调用这个回调。注意服务器自己修改变量时不会触发OnRep回调因为OnRep本身就是给收到复制数据的一端用的。所以如果你在服务器上修改了血量想在服务器也刷新一下UI需要自己手动调用一次刷新函数或者用Has Authority分支加一个同步处理。C里写法也很简单核心代码大概是这样UPROPERTY(ReplicatedUsing OnRep_Health) int32 Health; UFUNCTION() void OnRep_Health(); void AMyCoopCharacter::GetLifetimeReplicatedProps(TArrayFLifetimeProperty OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMyCoopCharacter, Health); }ReplicatedUsing的好处是你不必写单独的心跳轮询来检查值变化只要服务器改完客户端自然收到反馈。2.2 蓝图里把变量设置成复制回调纯蓝图做属性同步也不复杂按下面步骤操作即可在蓝图变量列表里新建一个变量比如Health。右键变量选择Replication-Replicated或Replicated Using。如果选了Replicated Using会要求你选择一个回调函数。直接新建OnRep_Health事件或者选已有的。在OnRep_Health事件里写客户端表现逻辑比如更新角色身上的Widget Component。在服务器端修改Health的代码路径里手动多调一次UpdateHealthUI保证服务器端界面也即时刷新。这里有个很常见的坑你明明在服务器把血量改成0了客户端血条却半天不动。排查的时候先看变量有没有勾选Replicated再看回调是OnRep_Health还是别的名字最后确认是不是在客户端手动改了相同变量导致本地值与服务器冲突。我见过不少人是把“本地血量”和“服务器血量”混用客户端一改服务器广播回来又冲突最终表现成血条来回跳。2.3 用RepNotify做合作任务进度、Boss血量和开关门Coop里状态同步最典型的三个场景我都用RepNotify做过沉淀下来一些心得。任务阶段进度在GameState上放一个CurrentStage变量Replicated Using配OnRep_Stage。服务器推进阶段时改这个变量所有客户端收到后更新任务面板、触发新目标的UI提示。关键是任务阶段是全局状态放GameState能保证每个玩家的进度一致不用各自去读某个Actor的引用。Boss血条Boss的Health和MaxHealth做属性同步服务器在伤害结算的时候修改血量客户端通过OnRep刷新顶部血条。动作类Coop游戏比如大家常聊的那些近战共斗Boss血条同步本质上也是这套机制。伤害具体怎么判定可以交给服务器但血条显示走属性同步最稳定。如果你在客户端直接调用Destroy或者扣血你只会在自己的机器上看到Boss死了队友那边Boss还在打人。开关门门的状态用bIsOpen布尔变量同步。服务器在合适时机把它设为true客户端OnRep里播开门动画或开锁声音。服务器端如果要播动画直接调用本地表现函数就行不需要等OnRep。我之前做“双人合作开门”时把门的动画放在客户端OnRep结果主机能看到门打开客户端却因为动画逻辑依赖了一个本地布尔永远不同步。后来把所有“门状态”统一到Replicated变量上表现逻辑全部基于这个变量才彻底解决。2.4 性能与带宽别把属性同步当车载电台属性同步不是免费的复制得越多网络包越大。做Coop时一定要控制数量我这里有三条硬经验第一不要每帧修改复制变量。比如门既然只有开和关两种状态就别复制“开门进度从0到1”的连续值。服务器只需要复制bIsOpen客户端用本地动画表现过程即可。如果你真需要进度条比如救援读条也尽量用0到1的百分比值并控制更新频率。第二慎用大数组。数组一旦参与复制默认行为是每次序列化整个数组元素一多、改得又频繁带宽直接爆炸。Coop里有50个AI的阵营标记数组我一开始天真地做了Replicated结果PIE里三四人联机就开始卡。后来改成服务器只复制一个版本号客户端到了固定节点再拉详情好很多。第三浮点尽量压缩。血量百分比如果只用0到100整数复制开销比浮点小很多如果必须传0到1的精度也可以换算成uint8牺牲一点点精度换带宽。很多优化不是做完才想而是刚开始做Coop框架时就应该定好原则。3. 远程调用RPC与Coop交互从开关门到复活队友3.1 RPC三种类型和调用规则属性同步适合低频状态但Coop里还有大量“瞬间动作”需要广播玩家按了开门按钮、角色挥刀、复活队友、Boss进入二阶段。这些用RPC更合适。UE5里RPC分三种Server RPC客户端调用服务器执行。用于客户端“请求服务器做某事”。Client RPC服务器调用拥有该Actor的客户端执行。用于“服务器单独通知某个玩家”。Multicast RPC服务器调用所有端执行。用于“广播一个世界事件”。调用规则很容易记客户端能调Server服务器能调Client和Multicast反过来不行。如果客户端直接调用Multicast只会自己机器上执行其他玩家根本看不到。这是我早期经常踩的坑想在客户端按一下就让所有人听到开门声直接把Multicast放在键盘事件里结果只有自己听得到。蓝图里设置RPC很简单给自定义事件命名然后在Details面板里把Replicates改成对应类型。C则是用UFUNCTION(Server, Reliable)这类描述符。关键逻辑建议用Reliable比如复活、开门这种一旦丢失体验就很糟的用Reliable保证送达普通特效、刀光可以Unreliable。3.2 双人协作门的完整实现两块压力板刚才提过门的问题现在补一个完整方案。这道门需要两个玩家同时踩住压力板才打开这非常适合练手包含了属性同步、Server RPC、Multicast三件套。整体流程是做两个压力板ActorBP_PressurePlate带BoxComponent和Replicated变量bPressed。玩家踩上去时BoxComponent产生Overlap事件。在事件里先判断Has Authority因为Overlap在服务器和客户端可能都会被触发但只有服务器有资格修改bPressed。服务器把该压力板的bPressed设为true并且检查另一块板是否也是true。如果两块板都是true调用门Actor上的服务器函数或直接在服务器逻辑里把bIsOpen设为true然后执行Multicast播放门打开的动画和音效。客户端收到bPressed的OnRep后播放压力板下压的动画作为“踩中”的视觉反馈。实战中容易翻车的点是客户端也检测到了Overlap如果不判断权威客户端会直接把bPressed改成true然后试图给门发RPC。看似本地一切正常但服务器端的另一块板还是false门永远开不了。更麻烦的是如果客户端与服务器同时改同一个变量还会引发属性冲突表现成压力板忽上忽下。这个案例背后的思路是所有可交互状态都走服务器客户端只负责把“我踩上去”这个意图以Overlap的形式传达给服务器逻辑。只要你把状态变更收敛到服务器后期改门锁、条件、计时都方便。3.3 倒地救援Server RPC 定时器Coop玩法的灵魂是“队友倒了我能救”但救援系统的同步细节不少。我做过的方案大概是这样玩家血量降到0后不直接死亡而是进入倒地状态。倒地状态用Character上一个Replicated变量bIsDowned表示客户端收到后切换倒地动画和视角。其他玩家靠近长按交互键E触发客户端ServerStartRevive。服务端收到RPC后做合法性校验距离够不够近、倒地者是否真的倒地、施救者是否在忙然后启动一个服务器计时器比如5秒。计时期间救援进度存储在ReviveProgress变量上并参与复制通过OnRep显示施救者和倒地者屏幕上的进度条。这里一定要用服务器计时器不要在客户端用Delay因为客户端延迟、掉线都会导致计时不一致。计时结束服务器把倒地者的Health恢复到一定数值、bIsDowned设为false、清除倒地方向并调用Multicast播放一段“救援成功”的特效和音效。如果中途施救者松手或倒地者被攻击服务器重置进度并同步给所有端。这套方案的关键是进度条和状态都要通过服务器广播而不是靠在本地“感觉”进度。因为Coop里所有玩家看到同一个救援条你本地进度到100%而服务器进度还在30%的话队友就会看到你傻站了几秒钟什么也没发生。3.4 移动端双指触摸和网络同步的解耦最近看到有人问“UE5双指触摸蓝图怎么做”想做成Coop手游。这里必须说一个设计原则输入永远只是输入它不参与状态同步。UE5的Enhanced Input把触摸动作映射到Pawn的移动输入上最终是由CharacterMovementComponent走网络同步的。双指手势旋转视角、缩放镜头只影响本地相机不需要复制。如果某个触摸动作想触发“合作机关”比如两个玩家同时点击两个按钮开门那触摸事件里做的只是调用Server RPC让服务器去改变门的Replicated状态。所以不要试图把手指坐标、触摸状态直接Replicate。你要复制的只是“按钮有没有被触发”“服务器要不要执行动作”而不是“玩家手指在哪”。本地输入负责体验手感服务器负责游戏事实这个边界一旦划清移动端Coop和PC Coop在同步框架上就没有区别。4. 移动同步与动画同步Coop体验的核心细节4.1 CharacterMovementComponent和客户端预测Coop里玩家体验最敏感的其实是“其他玩家的移动”。你控制自己的角色时感觉顺滑是因为UE5本身有客户端预测你的输入先在本机模拟移动同时发给服务器验证服务器校正后再同步给其他玩家。其他玩家看到你的角色是SimulatedProxyUnity里俗称“插值体”引擎会平滑他们的位置和旋转。如果Coop测试时经常看到队友瞬移、滑步先检查是不是网络延迟高再看CharacterMovementComponent里的Network Smoothing Mode和Network Max Position Error。大部分项目不需要大幅调整默认插值对Coop已经够用。真正要小心的是自己改速度、瞬移、传送时记得用SetActorLocation加bSweep并通知服务器否则客户端和服务器位置会产生巨大偏差。大世界的Coop还要考虑Net Update Frequency。一个玩家关心的怪物可能只有几十个但每个怪物都按100Hz同步位置就太奢侈了。做海量怪物的Coop时我通常会根据怪物类型把更新频率调到10~20视觉表现依然能接受。4.2 攻击、Montage和特效的同步方法近战Coop最需要动画同步。以刀光材质/挥刀动作为例正确流程是客户端按攻击键调用Server RPC发起攻击。服务器确认可以攻击开始播放Montage。服务器通过Multicast让所有客户端也播放同样的Montage。攻击判定放在Montage的Notify窗口里由服务器在合适时机做一次射线或者范围判定。刀光特效、挥砍音效用Multicast触发。这里容易出的问题是如果只在客户端播放Montage那只有你自己能看到挥刀动作队友那边角色只是摆着站姿伤害却能打出来看起来非常怪。反过来如果让服务器每帧同步每个玩家的骨骼朝向带宽又不够。Montage广播是中等特效型同步的标准答案。刀光材质、Niagara特效在UE5里默认不参与网络复制必须通过Event/Multicast现场触发。用SpawnSystemAtLocation在Multicast里生成一个临时的Niagara特效会比把特效组件挂在武器上来得可靠因为Niagara的Simulation状态一旦复制起来非常重。4.3 Ragdoll、死亡和动画蓝图的常见坑Coop里角色倒地、死亡是常态但Ragdoll同步是我踩过最深的一个坑。正常情况下骨骼网格体动画由本地AnimBP驱动一旦开启物理模拟CharacterMovement停止角色开始受物理影响如果只有服务器开启物理模拟客户端角色还会保持站立姿势极其出戏。正确做法是在服务器设置Mesh-SetSimulatePhysics(true)同时用Multicast让所有端执行同样的设置并且同步修改碰撞响应、关掉CapsuleComponent的碰撞。Ragdoll的物理表现细节不可能完全一致但至少所有端都能看到角色“倒下了”这个事实。动画蓝图方面尽量用服务器同步下来的状态变量驱动动画而不是直接复制动画曲线。比如bIsRunning由MovementComponent自然地影响AnimBPbIsDowned、bIsAttacking这些布尔变量复制下来AnimBP混合出对应姿势。如果发现动画有时多播一次有时又没播可以先查是不是在本地和服务器都调了Montage导致客户端播了两遍解决方法是把动画播放入口统一收口到Multicast或属性回调里。5. 常见问题与排查不同步时别慌5.1 症状与原因速查表我把自己做Coop时遇到的高频问题整理成一张表排查时直接对照。现象可能原因排查方向其他客户端看不到某个Actor该Actor没有勾选Replicates或者只在客户端Spawn检查Actor复制设置确认服务器Spawn属性值服务器改了客户端不变变量没勾Replicated或OnRep回调没写确认Replication菜单在客户端打印OnRep客户端调Server RPC没反应调用者不是Actor的Owner或Actor没有复制检查拥有权和Get Local Role使用Has Authority调试Multicast只在本地生效客户端直接调用了Multicast改成服务器调用或用Server RPC转发玩家位置频繁跳变移动同步没开或客户端预测关闭勾选Replicate Movement检查CharacterMovement配置门/机关只对一个人同步逻辑在客户端执行而没有走服务器把状态变更收敛到服务器RPC主机正常客户端生成的角色逻辑错乱刷怪/生成逻辑只在主机上跑但每个客户端又各自Spawn统一由服务器Spawn这只是一半另一半是很多“不同步”根本不是网络问题是因为本地引用了错误的Actor实例。比如蓝图里把玩家角色硬引用到关卡蓝图联网后每个客户端引用的实例不同自然各看各的。5.2 调试命令和PIE多客户端配置排查同步问题PIE里一定要开多客户端。不要只在单机PIE里点Play那样你永远不知道网络分支有没有跑。推荐两种方式PIE多人联机项目设置里的Play把Number of Players设为2或3Net Mode选Play As Listen Server。这样会在本地起一个服务器加客户端适合快速验证。单独客户端把Net Mode选成Play As Client方便模拟纯客户端视角观察服务器广播过来的状态。控制台命令也很有用。net PktLag500能模拟500ms延迟stat Net、stat RPC能看网络流量和RPC数量Log LogNet Verbose能把同步日志打到Output Log里。开发期我习惯在蓝图里用Print String打印当前Actor的Role和RemoteRole一眼就能看出当前端是否拥有权威。经验之谈出了问题先不要急着改代码先确认“哪个端在哪个时刻拥有Authority”。你可以给角色头顶加一个开发用Widget不同网络角色显示不同颜色或文字。比如Authority红色、AutonomousProxy蓝色、SimulatedProxy绿色这样多开客户端时马上能看出当前操作的是哪个端。5.3 Coop项目的同步优化思路Coop玩到后期最疼的往往不是“不同步”而是“同步太多导致性能崩”。优化思路有几个方向。第一缩小同步范围。UE5的Actor复制有相关性机制不是所有Actor都需要同步给所有人。比如玩家B和玩家A相隔十万八千里A周围的小怪可以不同步给B。用Net Cull Distance Squared或自定义相关性能省大量带宽。第二别让GameState背太多高频数据。GameState虽然全局存在但它一旦复制高频变量所有客户端都会被轰炸。低频的任务阶段、团队分数可以放GameState高频的单个Boss血量可以放Boss Actor上毕竟只有靠近的玩家才关注。第三AI行为走服务器客户端只看移动。Coop里几十个怪物追踪玩家如果每个怪物的目标、行为状态都复制带宽很容易爆。正确做法是服务器跑AI逻辑客户端只看到怪物的ReplicatedMovement配合简单的死亡/攻击状态同步即可。很多大型Coop游戏都是这么干的。最后分享一个小技巧这篇写到的每一条基本都是从项目现场爬出来的。早期我做Coop喜欢先把表现做好再补同步结果每次补同步都在重构。后来我换了个顺序先定Actor的权威关系再想变量要不要复制最后才做UI和表现效率高很多。如果你刚开始做建议直接搭一个最小循环两个玩家开关一扇门、救援倒地队友、一个小Boss把同步链路完整走通后面加玩法都是往框架里填。开发期间给Actor头顶打印Network Role的颜色标记红色是Authority蓝色是AutonomousProxy绿色是SimulatedProxy一眼就能分辨当前端到底有没有权威这比任何同步教程都直观。 UE5网络同步实战：Coop合作游戏从零到稳定联机
最近总有朋友问我用UE5做双人或者四人Coop合作游戏网络同步到底该从哪下手。这个问题我比较有发言权因为早期做多人Demo的时候我把同步做成了“哪哪都对不上”主机看到门开了客户端的门纹丝不动队友倒地了救援进度条只有施救者自己能看见。后来把UE5的同步机制完整捋了一遍才明白Coop玩法要稳核心就一句话所有玩家共享的“事实”都必须在服务器上发生客户端只负责输入、预测和表现。这篇文章围绕UE5网络同步与Coop实现把架构、属性同步、RPC、移动和动画同步、调试排错串成一条能直接落地的链路。适合两类人一是刚开始做多人Coop、想搞懂同步基本盘的开发二是功能写完了但发现“不同步”问题一堆的老哥照着排查思路能省不少时间。1. Coop项目先想清楚服务端权威模型与游戏架构1.1 为什么Coop必须服务端权威Coop和竞技在同步上的侧重点不太一样。竞技游戏可以靠大量客户端预测来保证手感击杀判定最终由服务器兜底而Coop更注重全队共享状态任务阶段、Boss血量、门有没有开、队友能不能被救。这些状态如果由每个客户端自己算大家看到的世界就完全分叉了。服务端权威模型的意思是服务器拥有所有关键状态的最终决定权客户端只是发送输入、显示服务器广播的结果。UE5的多人框架从根上就是按这个思路设计的GameMode在服务器上跑Actor的属性需要勾选Replicated才会被广播客户端调用Server RPC也只是“请求服务器做事”真正改状态的一定是服务器。我见过不少朋友在单人Demo里逻辑全写在BeginPlay一到多人就翻车。原因很简单BeginPlay在客户端也会执行你辛辛苦苦算的刷怪逻辑每个客户端各算一遍结果自然不同步。做Coop时拿到一个共享Actor第一反应应该是看当前端有没有权威。蓝图里用Has Authority节点判断或者用Get Local Role看一下是不是Authority这比靠猜靠谱得多。1.2 GameMode、GameState、PlayerState 怎么分工Coop项目最容易乱的就是这几个类各管什么。我的经验是先想清楚状态的作用域再决定放在哪个类里顺序不能颠倒。GameMode只存在于服务器负责游戏规则、角色生成、回合倒计时、复活逻辑。Coop里“这一波刷几个怪”“玩家全灭后怎么判定失败”“比赛结束后切到结算界面”这类流程控制都放这里。客户端拿不到GameMode实例所以不要尝试在客户端调用GameMode函数你调不到。GameState全局存在服务器和所有客户端都有一份且会在所有客户端之间保持同步。适合放“当前任务阶段”“团队总进度”“Boss血量”“地图可打开的门列表”。比如合作任务里要求两队推进度进度值放GameState最稳因为它的生命周期覆盖整个关卡不会因为某个Actor被销毁就丢数据。PlayerState是每个玩家一份所有客户端都能看到适合放玩家昵称、角色类型、个人金币、倒地状态。Coop中常见错误是把“玩家倒地了没”放在Character上然后通过复杂引用去读实际上放PlayerState更合适即使角色重生了PlayerState还在。PlayerController是玩家与服务器之间的桥梁在服务器和该玩家自己的客户端都有。本地输入、HUD、相机控制放PC没问题但跨玩家共享的数据不要塞在PC里因为每个PC只属于一个玩家其他客户端不便读取。1.3 复制标志、网络角色与生成规则在Coop项目里Actor能不能共享给所有玩家取决于两个设置Replicates和Replicate Movement。前者决定属性是否参与复制后者决定MovementComponent是否自动同步位置和旋转。注意Replicates勾选后不是立刻全局广播它表示这个Actor“有资格”被复制具体还要看网络相关性、更新频率这些参数。理解网络角色也很关键。打开Actor的Role和RemoteRole主要会遇到这几种情况Authority当前端对这个Actor有最终控制权。服务器上绝大多数Actor是Authority单机时也是。AutonomousProxy拥有者客户端的Pawn是这个状态。本地玩家控制自己的角色时有输入预测权限。SimulatedProxy其他玩家看到的角色只能接收位置和动画状态不能自行修改。本地方是Authority别人看到的就是SimulatedProxy。排查“为什么只有我看得到这个Actor”时先看Role是不是Authority再看Spawn是不是发生在服务器。还有一个容易被忽略的规则需要共享的Actor必须由服务器Spawn。如果客户端直接SpawnActor即便勾了Replicates引擎也可能警告甚至不同步。Coop里刷怪、掉落物、可交互机关都必须在服务器生成然后引擎负责把生成通知和初始状态广播给客户端。本地只做纯装饰的特效Actor可以客户端Spawn但不要让它承载游戏逻辑。2. 属性同步与RepNotify让世界状态保持一致2.1 属性同步的原理和触发现象属性同步是Coop中最高频用到的手段。服务器修改一个勾选了Replicated的变量引擎会按Net Update Frequency把脏属性打包发送到客户端客户端收到值变化后更新本地。这里的“脏属性”不是每帧都发而是按网络更新频率批量处理。所以频率越高越及时但也越耗带宽。如果想让客户端在收到新值时执行逻辑比如更新血条UI、播放开门动画就需要RepNotify。在蓝图里把变量设为Replicated Using指定一个回调函数客户端在该变量值变化时会调用这个回调。注意服务器自己修改变量时不会触发OnRep回调因为OnRep本身就是给收到复制数据的一端用的。所以如果你在服务器上修改了血量想在服务器也刷新一下UI需要自己手动调用一次刷新函数或者用Has Authority分支加一个同步处理。C里写法也很简单核心代码大概是这样UPROPERTY(ReplicatedUsing OnRep_Health) int32 Health; UFUNCTION() void OnRep_Health(); void AMyCoopCharacter::GetLifetimeReplicatedProps(TArrayFLifetimeProperty OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMyCoopCharacter, Health); }ReplicatedUsing的好处是你不必写单独的心跳轮询来检查值变化只要服务器改完客户端自然收到反馈。2.2 蓝图里把变量设置成复制回调纯蓝图做属性同步也不复杂按下面步骤操作即可在蓝图变量列表里新建一个变量比如Health。右键变量选择Replication-Replicated或Replicated Using。如果选了Replicated Using会要求你选择一个回调函数。直接新建OnRep_Health事件或者选已有的。在OnRep_Health事件里写客户端表现逻辑比如更新角色身上的Widget Component。在服务器端修改Health的代码路径里手动多调一次UpdateHealthUI保证服务器端界面也即时刷新。这里有个很常见的坑你明明在服务器把血量改成0了客户端血条却半天不动。排查的时候先看变量有没有勾选Replicated再看回调是OnRep_Health还是别的名字最后确认是不是在客户端手动改了相同变量导致本地值与服务器冲突。我见过不少人是把“本地血量”和“服务器血量”混用客户端一改服务器广播回来又冲突最终表现成血条来回跳。2.3 用RepNotify做合作任务进度、Boss血量和开关门Coop里状态同步最典型的三个场景我都用RepNotify做过沉淀下来一些心得。任务阶段进度在GameState上放一个CurrentStage变量Replicated Using配OnRep_Stage。服务器推进阶段时改这个变量所有客户端收到后更新任务面板、触发新目标的UI提示。关键是任务阶段是全局状态放GameState能保证每个玩家的进度一致不用各自去读某个Actor的引用。Boss血条Boss的Health和MaxHealth做属性同步服务器在伤害结算的时候修改血量客户端通过OnRep刷新顶部血条。动作类Coop游戏比如大家常聊的那些近战共斗Boss血条同步本质上也是这套机制。伤害具体怎么判定可以交给服务器但血条显示走属性同步最稳定。如果你在客户端直接调用Destroy或者扣血你只会在自己的机器上看到Boss死了队友那边Boss还在打人。开关门门的状态用bIsOpen布尔变量同步。服务器在合适时机把它设为true客户端OnRep里播开门动画或开锁声音。服务器端如果要播动画直接调用本地表现函数就行不需要等OnRep。我之前做“双人合作开门”时把门的动画放在客户端OnRep结果主机能看到门打开客户端却因为动画逻辑依赖了一个本地布尔永远不同步。后来把所有“门状态”统一到Replicated变量上表现逻辑全部基于这个变量才彻底解决。2.4 性能与带宽别把属性同步当车载电台属性同步不是免费的复制得越多网络包越大。做Coop时一定要控制数量我这里有三条硬经验第一不要每帧修改复制变量。比如门既然只有开和关两种状态就别复制“开门进度从0到1”的连续值。服务器只需要复制bIsOpen客户端用本地动画表现过程即可。如果你真需要进度条比如救援读条也尽量用0到1的百分比值并控制更新频率。第二慎用大数组。数组一旦参与复制默认行为是每次序列化整个数组元素一多、改得又频繁带宽直接爆炸。Coop里有50个AI的阵营标记数组我一开始天真地做了Replicated结果PIE里三四人联机就开始卡。后来改成服务器只复制一个版本号客户端到了固定节点再拉详情好很多。第三浮点尽量压缩。血量百分比如果只用0到100整数复制开销比浮点小很多如果必须传0到1的精度也可以换算成uint8牺牲一点点精度换带宽。很多优化不是做完才想而是刚开始做Coop框架时就应该定好原则。3. 远程调用RPC与Coop交互从开关门到复活队友3.1 RPC三种类型和调用规则属性同步适合低频状态但Coop里还有大量“瞬间动作”需要广播玩家按了开门按钮、角色挥刀、复活队友、Boss进入二阶段。这些用RPC更合适。UE5里RPC分三种Server RPC客户端调用服务器执行。用于客户端“请求服务器做某事”。Client RPC服务器调用拥有该Actor的客户端执行。用于“服务器单独通知某个玩家”。Multicast RPC服务器调用所有端执行。用于“广播一个世界事件”。调用规则很容易记客户端能调Server服务器能调Client和Multicast反过来不行。如果客户端直接调用Multicast只会自己机器上执行其他玩家根本看不到。这是我早期经常踩的坑想在客户端按一下就让所有人听到开门声直接把Multicast放在键盘事件里结果只有自己听得到。蓝图里设置RPC很简单给自定义事件命名然后在Details面板里把Replicates改成对应类型。C则是用UFUNCTION(Server, Reliable)这类描述符。关键逻辑建议用Reliable比如复活、开门这种一旦丢失体验就很糟的用Reliable保证送达普通特效、刀光可以Unreliable。3.2 双人协作门的完整实现两块压力板刚才提过门的问题现在补一个完整方案。这道门需要两个玩家同时踩住压力板才打开这非常适合练手包含了属性同步、Server RPC、Multicast三件套。整体流程是做两个压力板ActorBP_PressurePlate带BoxComponent和Replicated变量bPressed。玩家踩上去时BoxComponent产生Overlap事件。在事件里先判断Has Authority因为Overlap在服务器和客户端可能都会被触发但只有服务器有资格修改bPressed。服务器把该压力板的bPressed设为true并且检查另一块板是否也是true。如果两块板都是true调用门Actor上的服务器函数或直接在服务器逻辑里把bIsOpen设为true然后执行Multicast播放门打开的动画和音效。客户端收到bPressed的OnRep后播放压力板下压的动画作为“踩中”的视觉反馈。实战中容易翻车的点是客户端也检测到了Overlap如果不判断权威客户端会直接把bPressed改成true然后试图给门发RPC。看似本地一切正常但服务器端的另一块板还是false门永远开不了。更麻烦的是如果客户端与服务器同时改同一个变量还会引发属性冲突表现成压力板忽上忽下。这个案例背后的思路是所有可交互状态都走服务器客户端只负责把“我踩上去”这个意图以Overlap的形式传达给服务器逻辑。只要你把状态变更收敛到服务器后期改门锁、条件、计时都方便。3.3 倒地救援Server RPC 定时器Coop玩法的灵魂是“队友倒了我能救”但救援系统的同步细节不少。我做过的方案大概是这样玩家血量降到0后不直接死亡而是进入倒地状态。倒地状态用Character上一个Replicated变量bIsDowned表示客户端收到后切换倒地动画和视角。其他玩家靠近长按交互键E触发客户端ServerStartRevive。服务端收到RPC后做合法性校验距离够不够近、倒地者是否真的倒地、施救者是否在忙然后启动一个服务器计时器比如5秒。计时期间救援进度存储在ReviveProgress变量上并参与复制通过OnRep显示施救者和倒地者屏幕上的进度条。这里一定要用服务器计时器不要在客户端用Delay因为客户端延迟、掉线都会导致计时不一致。计时结束服务器把倒地者的Health恢复到一定数值、bIsDowned设为false、清除倒地方向并调用Multicast播放一段“救援成功”的特效和音效。如果中途施救者松手或倒地者被攻击服务器重置进度并同步给所有端。这套方案的关键是进度条和状态都要通过服务器广播而不是靠在本地“感觉”进度。因为Coop里所有玩家看到同一个救援条你本地进度到100%而服务器进度还在30%的话队友就会看到你傻站了几秒钟什么也没发生。3.4 移动端双指触摸和网络同步的解耦最近看到有人问“UE5双指触摸蓝图怎么做”想做成Coop手游。这里必须说一个设计原则输入永远只是输入它不参与状态同步。UE5的Enhanced Input把触摸动作映射到Pawn的移动输入上最终是由CharacterMovementComponent走网络同步的。双指手势旋转视角、缩放镜头只影响本地相机不需要复制。如果某个触摸动作想触发“合作机关”比如两个玩家同时点击两个按钮开门那触摸事件里做的只是调用Server RPC让服务器去改变门的Replicated状态。所以不要试图把手指坐标、触摸状态直接Replicate。你要复制的只是“按钮有没有被触发”“服务器要不要执行动作”而不是“玩家手指在哪”。本地输入负责体验手感服务器负责游戏事实这个边界一旦划清移动端Coop和PC Coop在同步框架上就没有区别。4. 移动同步与动画同步Coop体验的核心细节4.1 CharacterMovementComponent和客户端预测Coop里玩家体验最敏感的其实是“其他玩家的移动”。你控制自己的角色时感觉顺滑是因为UE5本身有客户端预测你的输入先在本机模拟移动同时发给服务器验证服务器校正后再同步给其他玩家。其他玩家看到你的角色是SimulatedProxyUnity里俗称“插值体”引擎会平滑他们的位置和旋转。如果Coop测试时经常看到队友瞬移、滑步先检查是不是网络延迟高再看CharacterMovementComponent里的Network Smoothing Mode和Network Max Position Error。大部分项目不需要大幅调整默认插值对Coop已经够用。真正要小心的是自己改速度、瞬移、传送时记得用SetActorLocation加bSweep并通知服务器否则客户端和服务器位置会产生巨大偏差。大世界的Coop还要考虑Net Update Frequency。一个玩家关心的怪物可能只有几十个但每个怪物都按100Hz同步位置就太奢侈了。做海量怪物的Coop时我通常会根据怪物类型把更新频率调到10~20视觉表现依然能接受。4.2 攻击、Montage和特效的同步方法近战Coop最需要动画同步。以刀光材质/挥刀动作为例正确流程是客户端按攻击键调用Server RPC发起攻击。服务器确认可以攻击开始播放Montage。服务器通过Multicast让所有客户端也播放同样的Montage。攻击判定放在Montage的Notify窗口里由服务器在合适时机做一次射线或者范围判定。刀光特效、挥砍音效用Multicast触发。这里容易出的问题是如果只在客户端播放Montage那只有你自己能看到挥刀动作队友那边角色只是摆着站姿伤害却能打出来看起来非常怪。反过来如果让服务器每帧同步每个玩家的骨骼朝向带宽又不够。Montage广播是中等特效型同步的标准答案。刀光材质、Niagara特效在UE5里默认不参与网络复制必须通过Event/Multicast现场触发。用SpawnSystemAtLocation在Multicast里生成一个临时的Niagara特效会比把特效组件挂在武器上来得可靠因为Niagara的Simulation状态一旦复制起来非常重。4.3 Ragdoll、死亡和动画蓝图的常见坑Coop里角色倒地、死亡是常态但Ragdoll同步是我踩过最深的一个坑。正常情况下骨骼网格体动画由本地AnimBP驱动一旦开启物理模拟CharacterMovement停止角色开始受物理影响如果只有服务器开启物理模拟客户端角色还会保持站立姿势极其出戏。正确做法是在服务器设置Mesh-SetSimulatePhysics(true)同时用Multicast让所有端执行同样的设置并且同步修改碰撞响应、关掉CapsuleComponent的碰撞。Ragdoll的物理表现细节不可能完全一致但至少所有端都能看到角色“倒下了”这个事实。动画蓝图方面尽量用服务器同步下来的状态变量驱动动画而不是直接复制动画曲线。比如bIsRunning由MovementComponent自然地影响AnimBPbIsDowned、bIsAttacking这些布尔变量复制下来AnimBP混合出对应姿势。如果发现动画有时多播一次有时又没播可以先查是不是在本地和服务器都调了Montage导致客户端播了两遍解决方法是把动画播放入口统一收口到Multicast或属性回调里。5. 常见问题与排查不同步时别慌5.1 症状与原因速查表我把自己做Coop时遇到的高频问题整理成一张表排查时直接对照。现象可能原因排查方向其他客户端看不到某个Actor该Actor没有勾选Replicates或者只在客户端Spawn检查Actor复制设置确认服务器Spawn属性值服务器改了客户端不变变量没勾Replicated或OnRep回调没写确认Replication菜单在客户端打印OnRep客户端调Server RPC没反应调用者不是Actor的Owner或Actor没有复制检查拥有权和Get Local Role使用Has Authority调试Multicast只在本地生效客户端直接调用了Multicast改成服务器调用或用Server RPC转发玩家位置频繁跳变移动同步没开或客户端预测关闭勾选Replicate Movement检查CharacterMovement配置门/机关只对一个人同步逻辑在客户端执行而没有走服务器把状态变更收敛到服务器RPC主机正常客户端生成的角色逻辑错乱刷怪/生成逻辑只在主机上跑但每个客户端又各自Spawn统一由服务器Spawn这只是一半另一半是很多“不同步”根本不是网络问题是因为本地引用了错误的Actor实例。比如蓝图里把玩家角色硬引用到关卡蓝图联网后每个客户端引用的实例不同自然各看各的。5.2 调试命令和PIE多客户端配置排查同步问题PIE里一定要开多客户端。不要只在单机PIE里点Play那样你永远不知道网络分支有没有跑。推荐两种方式PIE多人联机项目设置里的Play把Number of Players设为2或3Net Mode选Play As Listen Server。这样会在本地起一个服务器加客户端适合快速验证。单独客户端把Net Mode选成Play As Client方便模拟纯客户端视角观察服务器广播过来的状态。控制台命令也很有用。net PktLag500能模拟500ms延迟stat Net、stat RPC能看网络流量和RPC数量Log LogNet Verbose能把同步日志打到Output Log里。开发期我习惯在蓝图里用Print String打印当前Actor的Role和RemoteRole一眼就能看出当前端是否拥有权威。经验之谈出了问题先不要急着改代码先确认“哪个端在哪个时刻拥有Authority”。你可以给角色头顶加一个开发用Widget不同网络角色显示不同颜色或文字。比如Authority红色、AutonomousProxy蓝色、SimulatedProxy绿色这样多开客户端时马上能看出当前操作的是哪个端。5.3 Coop项目的同步优化思路Coop玩到后期最疼的往往不是“不同步”而是“同步太多导致性能崩”。优化思路有几个方向。第一缩小同步范围。UE5的Actor复制有相关性机制不是所有Actor都需要同步给所有人。比如玩家B和玩家A相隔十万八千里A周围的小怪可以不同步给B。用Net Cull Distance Squared或自定义相关性能省大量带宽。第二别让GameState背太多高频数据。GameState虽然全局存在但它一旦复制高频变量所有客户端都会被轰炸。低频的任务阶段、团队分数可以放GameState高频的单个Boss血量可以放Boss Actor上毕竟只有靠近的玩家才关注。第三AI行为走服务器客户端只看移动。Coop里几十个怪物追踪玩家如果每个怪物的目标、行为状态都复制带宽很容易爆。正确做法是服务器跑AI逻辑客户端只看到怪物的ReplicatedMovement配合简单的死亡/攻击状态同步即可。很多大型Coop游戏都是这么干的。最后分享一个小技巧这篇写到的每一条基本都是从项目现场爬出来的。早期我做Coop喜欢先把表现做好再补同步结果每次补同步都在重构。后来我换了个顺序先定Actor的权威关系再想变量要不要复制最后才做UI和表现效率高很多。如果你刚开始做建议直接搭一个最小循环两个玩家开关一扇门、救援倒地队友、一个小Boss把同步链路完整走通后面加玩法都是往框架里填。开发期间给Actor头顶打印Network Role的颜色标记红色是Authority蓝色是AutonomousProxy绿色是SimulatedProxy一眼就能分辨当前端到底有没有权威这比任何同步教程都直观。