Claude Code Game Studios 的 Unreal 复制专家UE Replication Specialist服务器权威网络架构、RPC 与带宽优化实战指南【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios本文是 Claude Code Game StudiosCCGS框架中ue-replication-specialist智能体的完整技术指南覆盖 UE5 多人在线项目中属性复制Property Replication、RPC 设计、客户端预测、网络相关性与休眠、带宽优化与复制层安全的全部标准。读者读完将掌握一套可直接落地的服务器权威Server-Authoritative联网架构设计方法并学会如何在 64 KB/s 级网络预算内做带宽决策。一、角色定位谁负责 UE 的复制层在 CCGS 这个将 Claude Code 组织成完整游戏工作室的框架中ue-replication-specialist是一个面向Unreal Engine 5 多人在线项目的引擎级专家智能体。它的职责边界定义在 .claude/agents/ue-replication-specialist.md 的 frontmatter 中领域属性复制、RPC、客户端预测、相关性Relevancy、网络序列化、带宽优化核心目标确保服务器权威架构 响应式多人游戏手感工具集Read、Glob、Grep、Write、Edit、Bash、Task可读写 C/Blueprint 源码但不持有基础设施类工具模型档位Sonnet框架中引擎专家的默认档位对应 catalog.yaml 中ue-replication-specialist的category: engine条目。该角色的职责清单包括设计服务器权威游戏架构、以正确的生命周期与条件实现属性复制、设计 Server/Client/NetMulticast RPC、实现客户端预测与服务端调和、优化带宽使用与复制频率、处理网络相关性/休眠/优先级以及确保复制层的网络安全。值得注意的是它的职责边界游戏逻辑本身的实现归 gameplay-programmer服务器托管与部署归 devops-engineerGAS 专属预测归 ue-gas-specialist。这份边界在 CCGS Skill Testing Framework/agents/engine/unreal/ue-replication-specialist.md 的测试规格中通过专门的越域请求用例进行约束。二、协作协议先设计后实现写入前必须获批作为框架中的协作型实现者该智能体不是自主代码生成器。其实现工作流要求在任何代码写入前完成六步阅读设计文档区分已明确与有歧义的规格标注与标准模式的偏差提前标记实现难点提出架构问题例如这应该是静态工具类还是场景节点数据应该放在 [SystemData][Container] 类还是配置文件设计文档未规定 [边界情况]此时应该……实现前给出架构提案展示类结构、文件组织与数据流解释推荐方案的 WHY模式、引擎约定、可维护性并明确权衡——这个方案更简单但灵活性低对比这个更复杂但扩展性强透明地实现实现中遇到规格歧义就停下询问规则/钩子rules/hooks发现问题时修复并解释问题所在若必须偏离设计文档技术约束明确指出来写入文件前获批展示代码或详细摘要明确询问May I write this to [filepath(s)]?多文件变更需列出全部受影响文件等待 yes 才使用 Write/Edit提供后续步骤现在写测试还是你先审阅实现这是否已准备好交给 /code-review 验证这套协议同样体现在框架通用的 agent-test-spec 模板 中写入前必须使用May I write、先呈现发现再请求批准、不得越级跳过委托层级。三、属性复制标准DOREPLIFETIME、复制条件与 RepNotify3.1 一切复制属性都进 GetLifetimeReplicatedProps所有需要复制的属性都必须在GetLifetimeReplicatedProps()中使用DOREPLIFETIME注册。这与 docs/engine-reference/unreal/modules/networking.md 给出的引擎级代码模式一致UPROPERTY(Replicated) int32 Health; UPROPERTY(Replicated) FVector Position; void AMyActor::GetLifetimeReplicatedProps(TArrayFLifetimeProperty OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMyActor, Health); DOREPLIFETIME(AMyActor, Position); }漏掉DOREPLIFETIME是复制的静默失败silent replication failure——属性不会报错但永远不会同步到客户端这是必须避免的头号反模式。3.2 复制条件用最小带宽完成状态同步复制条件是控制带宽的第一道闸门。智能体标准规定了四类核心条件条件语义典型场景COND_OwnerOnly只复制给拥有该 Actor 的客户端背包、个人统计COND_SkipOwner复制给除拥有者外的所有人其他玩家可见的外观状态COND_InitialOnly仅生成时复制一次队伍、角色职业COND_Custom配合DOREPLIFETIME_CONDITION使用自定义逻辑按游戏规则动态决定的复制对应引擎级写法DOREPLIFETIME_CONDITION(AMyCharacter, Ammo, COND_OwnerOnly); DOREPLIFETIME_CONDITION(AMyCharacter, TeamID, COND_SkipOwner); DOREPLIFETIME_CONDITION(AMyCharacter, Score, COND_InitialOnly);3.3 RepNotify变化时的客户端回调需要客户端在属性变化时执行回调刷新 UI、播放反馈、调和预测值应使用ReplicatedUsing回调函数按约定命名为OnRep_[PropertyName]UPROPERTY(ReplicatedUsingOnRep_Health) int32 Health; UFUNCTION() void OnRep_Health() { UpdateHealthUI(); // 客户端收到新值后触发 }3.4 两条铁律绝不复制派生/计算值应该由客户端根据复制的输入自行计算而不是把计算结果也复制一份移动用FRepMovement角色移动不要自定义位置复制使用引擎内置的移动复制管线。四、RPC 设计三种方向与可靠性选择RPC 是复制层的事件通道。智能体标准按方向区分了三种类型并给出明确的使用纪律4.1 Server RPC客户端 → 服务器客户端请求某个行为服务器校验后执行。两条强制要求服务器永远校验输入绝不信任客户端数据——这是反作弊的底线。测试规格 Case 3 专门覆盖了无校验的 Server RPC 扣货币这一漏洞场景ServerSpendCurrency若不加校验作弊者可以任意构造 RPC 调用。修复模式是if (!HasAuthority()) return;守卫 变更前的显式状态校验确认玩家确有货币、交易合法、非法则拒绝并记录并交由 lead-programmer 复核经济影响限流Rate-limit防止刷屏/滥用未限流的客户端 RPC 等于给 DoS 开绿灯。引擎级的_Validate钩子正是这个理念的实现UFUNCTION(Server, Reliable) void Server_TakeDamage(int32 Damage); bool AMyCharacter::Server_TakeDamage_Validate(int32 Damage) { // 输入校验反作弊参数必须在合法范围内 return Damage 0 Damage 100; } void AMyCharacter::Server_TakeDamage_Implementation(int32 Damage) { Health - Damage; }4.2 Client RPC服务器 → 单个客户端服务器告知某个特定客户端信息个人反馈、UI 更新。纪律是少用——状态优先用复制属性承载RPC 只用于无法用属性表达的一次性事件。UFUNCTION(Client, Reliable) void Client_ShowDeathScreen(); void AMyCharacter::Client_ShowDeathScreen_Implementation() { ShowDeathUI(); // 仅目标客户端执行 }4.3 NetMulticast RPC服务器 → 所有客户端广播类事件演出效果、世界特效。可靠性选择直接决定带宽Unreliable用于非关键演出类 RPC命中特效、脚步声——高频事件的默认选择Reliable仅在事件必须到达时使用游戏状态变更。UFUNCTION(NetMulticast, Reliable) void Multicast_PlayExplosion(FVector Location); void AMyActor::Multicast_PlayExplosion_Implementation(FVector Location) { UGameplayStatics::SpawnEmitterAtLocation(GetWorld(), ExplosionEffect, Location); }4.4 通用纪律RPC 参数必须小绝不发送大载荷大数组、完整对象作为 RPC 参数频繁的演出类 RPC 标记Unreliable否则可靠通道会迅速拥塞。五、客户端预测响应性手感 服务器权威客户端预测是手感与权威之间的桥梁。智能体标准给出了完整的预测方法论预测动作以获得响应性若服务端结果不同则由服务端纠正移动预测直接用CharacterMovementComponent不要重新发明轮子——引擎内置移动复制已经过高度优化测试规格 Case 4 明确建议使用或扩展它而不是自研自定义系统GAS 技能使用LocalPredicted激活策略详见 .claude/agents/ue-gas-specialist.md 的预测与复制章节预测状态必须可回滚rollbackable数据结构在设计时就要考虑回滚立即展示预测结果服务端不同意时平滑纠正插值而非硬切快照游戏效果预测使用FPredictionKey。测试规格 Case 1 给出了一个完整验证场景——可预测的玩家血量声明UPROPERTY(ReplicatedUsingOnRep_Health)本地客户端先应用暂定伤害如自伤服务器权威值经OnRep_Health到达后调和任何差异OnRep_Health内同时负责视觉/音频反馈与预测值对账。若项目启用了 GAS则应移交 ue-gas-specialist 处理 GAS 管理的属性。这与引擎参考文档中客户端预测 服务端插值的移动模式互相印证if (GetLocalRole() ROLE_AutonomousProxy) { // 客户端发送输入给服务器同时本地预测移动 FVector Input GetMovementInput(); Server_Move(Input); AddMovementInput(Input); } if (HasAuthority()) { ServerPosition GetActorLocation(); // 服务器权威位置 } else { // 客户端向服务器位置平滑插值 FVector NewPos FMath::VInterpTo(GetActorLocation(), ServerPosition, DeltaTime, 5.0f); SetActorLocation(NewPos); }六、网络相关性与休眠别让服务器给所有人复制一切相关性Relevancy决定哪些 Actor 对哪些客户端可见是带宽优化的结构性手段按 Actor 类配置NetRelevancyDistance不要盲目使用全局默认值NetDormancy用于极少变化的 ActorDORM_DormantAll显式刷新前永不复制如静态世界物件DORM_DormantPartial仅在属性变化时复制NetPriority确保重要 Actor玩家、目标点优先复制bOnlyRelevantToOwner个人物品、背包 Actor、纯 UI Actor 只发给拥有者NetUpdateFrequency控制每个 Actor 的复制频率——不是所有东西都需要 60Hz。引擎级对应实现见 docs/engine-reference/unreal/modules/networking.md// 自定义相关性仅在一定距离内复制 bool AMyActor::IsNetRelevantFor(const AActor* RealViewer, const AActor* ViewTarget, const FVector SrcLocation) const { return FVector::Dist(SrcLocation, GetActorLocation()) 5000.0f; } // 始终相关 / 仅对拥有者相关 AMyActor::AMyActor() { bAlwaysRelevant true; // 例如 GameState、PlayerController bOnlyRelevantToOwner true; // 例如 PlayerController }七、带宽优化量化、位打包与增量序列化复制层的最优解不是少复制而是精确复制。智能体标准给出了完整优化工具箱量化浮点角度、位置等不需要全精度的场景降低精度换取字节位打包结构体用FVector_NetQuantize等引擎内置量化类型替代原始FVector——测试规格 Case 4 明确建议当 32 人局中每 tick 复制全精度 Vector3 位置超出带宽预算时改用FVector_NetQuantize或FVector_NetQuantize100并降低非拥有客户端的SetNetUpdateFrequency()数组增量序列化压缩复制的数组只发变化部分脏标记 条件复制只复制变化的内容分析工具用net.PackageMap、stat net与 Network Profiler 持续剖析带宽。量化目标动作游戏每客户端 10 KB/s慢节奏游戏 5 KB/s。测试规格 Case 5 展示了如何在真实预算约束下做设计项目网络预算 64 KB/s/玩家32 人局即 2 MB/s 服务器出站现有移动复制已占 40 KB/s/玩家剩余仅 24 KB/s。此时实时背包复制让所有客户端立即看到装备变化就不能用朴素的全背包复制方案而应采用增量/事件驱动方案只复制变化的槽位如FGameplayItemSlotReplicatedUsing触发定向更新并给出相对剩余 24 KB/s 预算的带宽估算。这正是用项目提供的预算数字评估复制设计而不是给通用建议的框架级要求。八、复制层安全在复制层做反作弊网络安全的最后防线在复制层本身服务器校验每个客户端 RPC 三问该玩家此刻是否真能执行此操作参数是否在合法范围内请求频率是否在可接受范围内绝不信任客户端上报的位置、伤害或状态变更未经校验一律拒绝记录可疑复制模式供反作弊分析对关键复制数据用校验和在可行范围内。测试规格将 Case 3无校验 RPC 扣货币标注为shipping-critical——无校验 RPC 是多人游戏漏洞 Top-10 的利用向量。修复必须解释原代码为什么危险而不是直接给修好的代码。九、复制反模式清单见到就拦智能体被训练成在代码审查中主动拦截以下反模式复制本可在客户端派生的演出状态对高频演出事件使用Reliable NetMulticast带宽爆炸复制属性却忘记DOREPLIFETIME静默复制失败每帧调用 Server RPC 而不是状态变化时调用客户端 RPC 不限流允许 DoS数组只改一个元素却整体复制能用COND_SkipOwner属性方案解决的场景却用NetMulticast。十、协作矩阵与谁协作、边界在哪该智能体不是孤岛其协调对象明确写在其定义中unreal-specialistUE 整体架构network-programmer传输层网络CCGS Skill Testing Framework/agents/specialists/network-programmer.md 负责状态复制协议、滞后补偿、消息 schema 的契约设计ue-gas-specialist能力复制与预测GAS 的LocalPredicted、FPredictionKey、ASC 复制模式gameplay-programmer被复制的玩法系统实现security-engineer网络安全验证。边界纪律同样被测试规格强制请求游戏服务器基础设施/区域部署/匹配架构时必须明确拒绝并重定向到 devops-engineer声明服务器基础设施与部署架构归 devops-engineer 所有我处理的是运行中游戏会话内的 Unreal 复制层不得把游戏内复制与服务器托管混为一谈。十一、验证与测试agent-test-spec 的五个用例仓库为该智能体提供了结构化的行为测试规格CCGS Skill Testing Framework/agents/engine/unreal/ue-replication-specialist.md覆盖静态断言与五个行为用例用例输入场景验证要点Case 1域内请求可预测的玩家血量复制产出ReplicatedUsingOnRep_Health声明 OnRep 调和逻辑若启用 GAS 则转交 ue-gas-specialistCase 2越域请求游戏服务器架构拒绝产出基础设施设计明确重定向 devops-engineerCase 3域边界无校验的 Server RPC 扣货币判定为严重安全漏洞给出HasAuthority守卫 状态校验修复交 lead-programmer 复核Case 4带宽优化32 人局高频移动复制超预算指出 tick 级全精度 Vector3 昂贵改用FVector_NetQuantize、降频推荐引擎 CMCCase 5预算上下文64 KB/s/玩家移动已占 40 KB/s基于剩余 24 KB/s 做增量/事件驱动背包复制给出带宽估算规格同时明确了静态约束description字段必须领域相关、工具列表匹配角色、模型档位为 Sonnet、不得声称对服务器基础设施/玩法逻辑正确性的权威。由于没有自动化 runner测试规格注明需人工或通过/skill-test复核。十二、落地建议从角色文件开始将 .claude/agents/ue-replication-specialist.md 作为 UE 多人项目的复制层契约把其中的标准固化为团队代码审查清单对齐引擎参考具体 API 写法以 docs/engine-reference/unreal/modules/networking.md 为准其中标注了 UE 5.7 的验证时间与知识缺口跨版本时务必核对 VERSION.md 与 breaking-changes.md用测试规格做验收对复制相关改动跑一遍五个用例尤其关注 Case 3RPC 安全与 Case 5预算上下文意识——前者是上线级风险后者最能区分照本宣科与真正会做带宽决策。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Claude Code Game Studios 的 Unreal 复制专家UE Replication Specialist服务器权威网络架构、RPC 与带宽优化实战指南【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios本文是 Claude Code Game StudiosCCGS框架中ue-replication-specialist智能体的完整技术指南覆盖 UE5 多人在线项目中属性复制Property Replication、RPC 设计、客户端预测、网络相关性与休眠、带宽优化与复制层安全的全部标准。读者读完将掌握一套可直接落地的服务器权威Server-Authoritative联网架构设计方法并学会如何在 64 KB/s 级网络预算内做带宽决策。一、角色定位谁负责 UE 的复制层在 CCGS 这个将 Claude Code 组织成完整游戏工作室的框架中ue-replication-specialist是一个面向Unreal Engine 5 多人在线项目的引擎级专家智能体。它的职责边界定义在 .claude/agents/ue-replication-specialist.md 的 frontmatter 中领域属性复制、RPC、客户端预测、相关性Relevancy、网络序列化、带宽优化核心目标确保服务器权威架构 响应式多人游戏手感工具集Read、Glob、Grep、Write、Edit、Bash、Task可读写 C/Blueprint 源码但不持有基础设施类工具模型档位Sonnet框架中引擎专家的默认档位对应 catalog.yaml 中ue-replication-specialist的category: engine条目。该角色的职责清单包括设计服务器权威游戏架构、以正确的生命周期与条件实现属性复制、设计 Server/Client/NetMulticast RPC、实现客户端预测与服务端调和、优化带宽使用与复制频率、处理网络相关性/休眠/优先级以及确保复制层的网络安全。值得注意的是它的职责边界游戏逻辑本身的实现归 gameplay-programmer服务器托管与部署归 devops-engineerGAS 专属预测归 ue-gas-specialist。这份边界在 CCGS Skill Testing Framework/agents/engine/unreal/ue-replication-specialist.md 的测试规格中通过专门的越域请求用例进行约束。二、协作协议先设计后实现写入前必须获批作为框架中的协作型实现者该智能体不是自主代码生成器。其实现工作流要求在任何代码写入前完成六步阅读设计文档区分已明确与有歧义的规格标注与标准模式的偏差提前标记实现难点提出架构问题例如这应该是静态工具类还是场景节点数据应该放在 [SystemData][Container] 类还是配置文件设计文档未规定 [边界情况]此时应该……实现前给出架构提案展示类结构、文件组织与数据流解释推荐方案的 WHY模式、引擎约定、可维护性并明确权衡——这个方案更简单但灵活性低对比这个更复杂但扩展性强透明地实现实现中遇到规格歧义就停下询问规则/钩子rules/hooks发现问题时修复并解释问题所在若必须偏离设计文档技术约束明确指出来写入文件前获批展示代码或详细摘要明确询问May I write this to [filepath(s)]?多文件变更需列出全部受影响文件等待 yes 才使用 Write/Edit提供后续步骤现在写测试还是你先审阅实现这是否已准备好交给 /code-review 验证这套协议同样体现在框架通用的 agent-test-spec 模板 中写入前必须使用May I write、先呈现发现再请求批准、不得越级跳过委托层级。三、属性复制标准DOREPLIFETIME、复制条件与 RepNotify3.1 一切复制属性都进 GetLifetimeReplicatedProps所有需要复制的属性都必须在GetLifetimeReplicatedProps()中使用DOREPLIFETIME注册。这与 docs/engine-reference/unreal/modules/networking.md 给出的引擎级代码模式一致UPROPERTY(Replicated) int32 Health; UPROPERTY(Replicated) FVector Position; void AMyActor::GetLifetimeReplicatedProps(TArrayFLifetimeProperty OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMyActor, Health); DOREPLIFETIME(AMyActor, Position); }漏掉DOREPLIFETIME是复制的静默失败silent replication failure——属性不会报错但永远不会同步到客户端这是必须避免的头号反模式。3.2 复制条件用最小带宽完成状态同步复制条件是控制带宽的第一道闸门。智能体标准规定了四类核心条件条件语义典型场景COND_OwnerOnly只复制给拥有该 Actor 的客户端背包、个人统计COND_SkipOwner复制给除拥有者外的所有人其他玩家可见的外观状态COND_InitialOnly仅生成时复制一次队伍、角色职业COND_Custom配合DOREPLIFETIME_CONDITION使用自定义逻辑按游戏规则动态决定的复制对应引擎级写法DOREPLIFETIME_CONDITION(AMyCharacter, Ammo, COND_OwnerOnly); DOREPLIFETIME_CONDITION(AMyCharacter, TeamID, COND_SkipOwner); DOREPLIFETIME_CONDITION(AMyCharacter, Score, COND_InitialOnly);3.3 RepNotify变化时的客户端回调需要客户端在属性变化时执行回调刷新 UI、播放反馈、调和预测值应使用ReplicatedUsing回调函数按约定命名为OnRep_[PropertyName]UPROPERTY(ReplicatedUsingOnRep_Health) int32 Health; UFUNCTION() void OnRep_Health() { UpdateHealthUI(); // 客户端收到新值后触发 }3.4 两条铁律绝不复制派生/计算值应该由客户端根据复制的输入自行计算而不是把计算结果也复制一份移动用FRepMovement角色移动不要自定义位置复制使用引擎内置的移动复制管线。四、RPC 设计三种方向与可靠性选择RPC 是复制层的事件通道。智能体标准按方向区分了三种类型并给出明确的使用纪律4.1 Server RPC客户端 → 服务器客户端请求某个行为服务器校验后执行。两条强制要求服务器永远校验输入绝不信任客户端数据——这是反作弊的底线。测试规格 Case 3 专门覆盖了无校验的 Server RPC 扣货币这一漏洞场景ServerSpendCurrency若不加校验作弊者可以任意构造 RPC 调用。修复模式是if (!HasAuthority()) return;守卫 变更前的显式状态校验确认玩家确有货币、交易合法、非法则拒绝并记录并交由 lead-programmer 复核经济影响限流Rate-limit防止刷屏/滥用未限流的客户端 RPC 等于给 DoS 开绿灯。引擎级的_Validate钩子正是这个理念的实现UFUNCTION(Server, Reliable) void Server_TakeDamage(int32 Damage); bool AMyCharacter::Server_TakeDamage_Validate(int32 Damage) { // 输入校验反作弊参数必须在合法范围内 return Damage 0 Damage 100; } void AMyCharacter::Server_TakeDamage_Implementation(int32 Damage) { Health - Damage; }4.2 Client RPC服务器 → 单个客户端服务器告知某个特定客户端信息个人反馈、UI 更新。纪律是少用——状态优先用复制属性承载RPC 只用于无法用属性表达的一次性事件。UFUNCTION(Client, Reliable) void Client_ShowDeathScreen(); void AMyCharacter::Client_ShowDeathScreen_Implementation() { ShowDeathUI(); // 仅目标客户端执行 }4.3 NetMulticast RPC服务器 → 所有客户端广播类事件演出效果、世界特效。可靠性选择直接决定带宽Unreliable用于非关键演出类 RPC命中特效、脚步声——高频事件的默认选择Reliable仅在事件必须到达时使用游戏状态变更。UFUNCTION(NetMulticast, Reliable) void Multicast_PlayExplosion(FVector Location); void AMyActor::Multicast_PlayExplosion_Implementation(FVector Location) { UGameplayStatics::SpawnEmitterAtLocation(GetWorld(), ExplosionEffect, Location); }4.4 通用纪律RPC 参数必须小绝不发送大载荷大数组、完整对象作为 RPC 参数频繁的演出类 RPC 标记Unreliable否则可靠通道会迅速拥塞。五、客户端预测响应性手感 服务器权威客户端预测是手感与权威之间的桥梁。智能体标准给出了完整的预测方法论预测动作以获得响应性若服务端结果不同则由服务端纠正移动预测直接用CharacterMovementComponent不要重新发明轮子——引擎内置移动复制已经过高度优化测试规格 Case 4 明确建议使用或扩展它而不是自研自定义系统GAS 技能使用LocalPredicted激活策略详见 .claude/agents/ue-gas-specialist.md 的预测与复制章节预测状态必须可回滚rollbackable数据结构在设计时就要考虑回滚立即展示预测结果服务端不同意时平滑纠正插值而非硬切快照游戏效果预测使用FPredictionKey。测试规格 Case 1 给出了一个完整验证场景——可预测的玩家血量声明UPROPERTY(ReplicatedUsingOnRep_Health)本地客户端先应用暂定伤害如自伤服务器权威值经OnRep_Health到达后调和任何差异OnRep_Health内同时负责视觉/音频反馈与预测值对账。若项目启用了 GAS则应移交 ue-gas-specialist 处理 GAS 管理的属性。这与引擎参考文档中客户端预测 服务端插值的移动模式互相印证if (GetLocalRole() ROLE_AutonomousProxy) { // 客户端发送输入给服务器同时本地预测移动 FVector Input GetMovementInput(); Server_Move(Input); AddMovementInput(Input); } if (HasAuthority()) { ServerPosition GetActorLocation(); // 服务器权威位置 } else { // 客户端向服务器位置平滑插值 FVector NewPos FMath::VInterpTo(GetActorLocation(), ServerPosition, DeltaTime, 5.0f); SetActorLocation(NewPos); }六、网络相关性与休眠别让服务器给所有人复制一切相关性Relevancy决定哪些 Actor 对哪些客户端可见是带宽优化的结构性手段按 Actor 类配置NetRelevancyDistance不要盲目使用全局默认值NetDormancy用于极少变化的 ActorDORM_DormantAll显式刷新前永不复制如静态世界物件DORM_DormantPartial仅在属性变化时复制NetPriority确保重要 Actor玩家、目标点优先复制bOnlyRelevantToOwner个人物品、背包 Actor、纯 UI Actor 只发给拥有者NetUpdateFrequency控制每个 Actor 的复制频率——不是所有东西都需要 60Hz。引擎级对应实现见 docs/engine-reference/unreal/modules/networking.md// 自定义相关性仅在一定距离内复制 bool AMyActor::IsNetRelevantFor(const AActor* RealViewer, const AActor* ViewTarget, const FVector SrcLocation) const { return FVector::Dist(SrcLocation, GetActorLocation()) 5000.0f; } // 始终相关 / 仅对拥有者相关 AMyActor::AMyActor() { bAlwaysRelevant true; // 例如 GameState、PlayerController bOnlyRelevantToOwner true; // 例如 PlayerController }七、带宽优化量化、位打包与增量序列化复制层的最优解不是少复制而是精确复制。智能体标准给出了完整优化工具箱量化浮点角度、位置等不需要全精度的场景降低精度换取字节位打包结构体用FVector_NetQuantize等引擎内置量化类型替代原始FVector——测试规格 Case 4 明确建议当 32 人局中每 tick 复制全精度 Vector3 位置超出带宽预算时改用FVector_NetQuantize或FVector_NetQuantize100并降低非拥有客户端的SetNetUpdateFrequency()数组增量序列化压缩复制的数组只发变化部分脏标记 条件复制只复制变化的内容分析工具用net.PackageMap、stat net与 Network Profiler 持续剖析带宽。量化目标动作游戏每客户端 10 KB/s慢节奏游戏 5 KB/s。测试规格 Case 5 展示了如何在真实预算约束下做设计项目网络预算 64 KB/s/玩家32 人局即 2 MB/s 服务器出站现有移动复制已占 40 KB/s/玩家剩余仅 24 KB/s。此时实时背包复制让所有客户端立即看到装备变化就不能用朴素的全背包复制方案而应采用增量/事件驱动方案只复制变化的槽位如FGameplayItemSlotReplicatedUsing触发定向更新并给出相对剩余 24 KB/s 预算的带宽估算。这正是用项目提供的预算数字评估复制设计而不是给通用建议的框架级要求。八、复制层安全在复制层做反作弊网络安全的最后防线在复制层本身服务器校验每个客户端 RPC 三问该玩家此刻是否真能执行此操作参数是否在合法范围内请求频率是否在可接受范围内绝不信任客户端上报的位置、伤害或状态变更未经校验一律拒绝记录可疑复制模式供反作弊分析对关键复制数据用校验和在可行范围内。测试规格将 Case 3无校验 RPC 扣货币标注为shipping-critical——无校验 RPC 是多人游戏漏洞 Top-10 的利用向量。修复必须解释原代码为什么危险而不是直接给修好的代码。九、复制反模式清单见到就拦智能体被训练成在代码审查中主动拦截以下反模式复制本可在客户端派生的演出状态对高频演出事件使用Reliable NetMulticast带宽爆炸复制属性却忘记DOREPLIFETIME静默复制失败每帧调用 Server RPC 而不是状态变化时调用客户端 RPC 不限流允许 DoS数组只改一个元素却整体复制能用COND_SkipOwner属性方案解决的场景却用NetMulticast。十、协作矩阵与谁协作、边界在哪该智能体不是孤岛其协调对象明确写在其定义中unreal-specialistUE 整体架构network-programmer传输层网络CCGS Skill Testing Framework/agents/specialists/network-programmer.md 负责状态复制协议、滞后补偿、消息 schema 的契约设计ue-gas-specialist能力复制与预测GAS 的LocalPredicted、FPredictionKey、ASC 复制模式gameplay-programmer被复制的玩法系统实现security-engineer网络安全验证。边界纪律同样被测试规格强制请求游戏服务器基础设施/区域部署/匹配架构时必须明确拒绝并重定向到 devops-engineer声明服务器基础设施与部署架构归 devops-engineer 所有我处理的是运行中游戏会话内的 Unreal 复制层不得把游戏内复制与服务器托管混为一谈。十一、验证与测试agent-test-spec 的五个用例仓库为该智能体提供了结构化的行为测试规格CCGS Skill Testing Framework/agents/engine/unreal/ue-replication-specialist.md覆盖静态断言与五个行为用例用例输入场景验证要点Case 1域内请求可预测的玩家血量复制产出ReplicatedUsingOnRep_Health声明 OnRep 调和逻辑若启用 GAS 则转交 ue-gas-specialistCase 2越域请求游戏服务器架构拒绝产出基础设施设计明确重定向 devops-engineerCase 3域边界无校验的 Server RPC 扣货币判定为严重安全漏洞给出HasAuthority守卫 状态校验修复交 lead-programmer 复核Case 4带宽优化32 人局高频移动复制超预算指出 tick 级全精度 Vector3 昂贵改用FVector_NetQuantize、降频推荐引擎 CMCCase 5预算上下文64 KB/s/玩家移动已占 40 KB/s基于剩余 24 KB/s 做增量/事件驱动背包复制给出带宽估算规格同时明确了静态约束description字段必须领域相关、工具列表匹配角色、模型档位为 Sonnet、不得声称对服务器基础设施/玩法逻辑正确性的权威。由于没有自动化 runner测试规格注明需人工或通过/skill-test复核。十二、落地建议从角色文件开始将 .claude/agents/ue-replication-specialist.md 作为 UE 多人项目的复制层契约把其中的标准固化为团队代码审查清单对齐引擎参考具体 API 写法以 docs/engine-reference/unreal/modules/networking.md 为准其中标注了 UE 5.7 的验证时间与知识缺口跨版本时务必核对 VERSION.md 与 breaking-changes.md用测试规格做验收对复制相关改动跑一遍五个用例尤其关注 Case 3RPC 安全与 Case 5预算上下文意识——前者是上线级风险后者最能区分照本宣科与真正会做带宽决策。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
