1. 项目概述为什么我们需要一个物理同步示例如果你在Unity里做过网络游戏尤其是那种带点物理效果的——比如赛车碰撞、角色被击飞、或者一堆箱子可以被推来推去——那你大概率遇到过这个让人头疼的问题为什么我本地跑得好好的一联机物体的运动就飘了、卡了或者干脆不同步了这正是《Unity-Mirror网络框架-从入门到精通之RigidbodyPhysics示例》这个项目要解决的核心痛点。它不是一个简单的“Hello World”网络消息示例而是直击网络游戏开发中最硬核的领域之一权威服务器下的确定性物理同步。Mirror作为Unity社区里备受欢迎的高层网络API它封装了底层传输让开发者能更专注于游戏逻辑。但是它并没有也不可能为你解决所有问题物理同步就是其中最典型的一个。很多新手会想当然地认为给一个GameObject挂上NetworkTransform组件和RigidbodyMirror就能自动处理好一切。但现实是如果你真这么做了在网络上看到的将是各种“灵异现象”物体瞬移、穿模、或者客户端和服务器看到的位置完全不一样。这是因为物理计算尤其是Unity的PhysX物理引擎默认是在本地、每一帧独立进行的。在权威服务器的架构下物理状态位置、旋转、速度必须由服务器计算并同步给所有客户端客户端只能进行表现层的预测和插值而不能“各自为政”地计算物理。这个RigidbodyPhysics示例正是为了演示如何在Mirror框架下正确地构建一套服务器权威的物理对象同步系统。它不仅仅是一个代码片段更是一套完整的设计模式和实践方案涵盖了从网络身份、状态同步、输入处理到客户端预测与服务器校正的全流程。对于任何想要开发具备可靠物理交互的多人游戏如竞技场对战、合作解谜、模拟经营等的开发者来说深入理解这个示例是从“网络编程入门”迈向“精通”的必经之路。2. 核心设计思路服务器权威与客户端表现分离在深入代码之前我们必须先确立一个核心原则服务器是唯一的状态仲裁者。对于物理对象而言这意味着所有物理计算受力、碰撞、运动只在服务器端进行。服务器上的Rigidbody是“真实”的。客户端不进行任何会影响游戏状态的物理模拟。客户端的Rigidbody可能被禁用或者仅用于视觉效果如布娃娃系统的客户端表现。客户端将输入如键盘指令发送给服务器由服务器根据输入施加力或改变速度计算新的物理状态。服务器定期将物理状态位置、旋转、速度同步给所有客户端。客户端收到服务器状态后通过插值Interpolation或预测Prediction来平滑地更新本地对象的位置以掩盖网络延迟。这个设计思路直接回答了网络搜索片段中提到的问题“在Mirror中由于需要在服务器上获取速度计算物理效果使用本地的 Rigidbody 组件是无法完成这个效果的而且也无法实现同步控制。” 因为如果客户端也用本地的Rigidbody去模拟由于网络延迟和帧率差异很快就会和服务器状态分道扬镳。2.1 网络身份与组件结构设计一个典型的可同步物理对象在Mirror中的组件结构应该是这样的YourPhysicsObject (GameObject) ├── NetworkIdentity (Mirror组件标识这是一个网络对象) ├── NetworkTransform (Mirror组件用于同步位置/旋转但需谨慎配置) ├── Rigidbody (Unity物理组件) └── YourPhysicsSyncScript (自定义脚本继承自NetworkBehaviour)这里的关键在于NetworkTransform和YourPhysicsSyncScript的分工。NetworkTransform可以负责基础的位置旋转同步但对于物理对象我们通常需要更精细的控制比如同步速度velocity和角速度angularVelocity。因此更常见的做法是方案A简化使用NetworkTransform同步位置和旋转在自定义脚本中使用[SyncVar]或[Command]/[ClientRpc]来同步Rigidbody.velocity。方案B推荐完全不用NetworkTransform所有状态位置、旋转、速度、角速度都在自定义脚本中通过[SyncVar]钩子函数或自定义序列化进行同步。这提供了最大的控制权。在RigidbodyPhysics示例中我们倾向于采用方案B因为它能让我们清晰地掌控同步的每一个环节特别是处理物理状态的特殊性。2.2 同步策略选择SyncVar、SyncList 还是自定义消息Mirror提供了多种同步机制[SyncVar]最适合同步简单的值类型int, float, Vector3等。当服务器端的SyncVar值改变时会自动同步给所有客户端。我们可以用它来同步位置、旋转、速度。[SyncVar(hook nameof(OnVelocityChanged))] private Vector3 syncedVelocity;[Command]和[ClientRpc][Command]让客户端调用服务器上的函数[ClientRpc]让服务器调用所有客户端的函数。适合用于触发一次性的、事件驱动的同步比如“施加一个冲击力”。[Command] void CmdApplyForce(Vector3 force) { // 只在服务器端执行 rigidbody.AddForce(force); // 然后可能需要通过SyncVar或Rpc同步新的状态 }自定义网络消息最灵活但需要手动管理。适合同步非常规的、结构化的数据包比如一整帧的物理状态快照。对于连续变化的物理状态[SyncVar]配合hook钩子函数是最常用和高效的方式。钩子函数允许我们在值同步到客户端时执行自定义的逻辑比如更新Rigidbody的速度或进行插值计算。注意事项[SyncVar]的同步频率受NetworkManager中Sync Interval的影响。对于高速运动的物理对象你可能需要降低这个间隔比如从默认的0.1秒降到0.02秒但这会增加网络带宽。需要在流畅度和带宽之间做权衡。3. 核心脚本解析构建一个可同步的物理对象让我们来拆解一个名为NetworkRigidbodySync的核心脚本。这个脚本将附着在我们的物理对象上并处理所有网络同步逻辑。3.1 脚本框架与变量声明using UnityEngine; using Mirror; [RequireComponent(typeof(Rigidbody))] public class NetworkRigidbodySync : NetworkBehaviour { // 引用本地Rigidbody组件 private Rigidbody rb; // 同步变量服务器权威的位置、旋转和速度 [SyncVar(hook nameof(OnSyncedPositionChanged))] private Vector3 syncedPosition; [SyncVar(hook nameof(OnSyncedRotationChanged))] private Quaternion syncedRotation; [SyncVar(hook nameof(OnSyncedVelocityChanged))] private Vector3 syncedVelocity; [SyncVar(hook nameof(OnSyncedAngularVelocityChanged))] private Vector3 syncedAngularVelocity; // 插值平滑参数 [SerializeField] private float positionLerpSpeed 15f; [SerializeField] private float rotationLerpSpeed 15f; // 用于客户端插值的目标状态 private Vector3 targetPosition; private Quaternion targetRotation; private Vector3 targetVelocity; private Vector3 targetAngularVelocity; // 标记是否已收到第一次服务器状态用于初始化 private bool receivedInitialState false; private void Awake() { rb GetComponentRigidbody(); // 在客户端我们可能希望禁用Rigidbody的物理模拟只用于插值或表现 if (!isServer) { // 注意不能直接禁用rb因为插值可能需要它。改为设置isKinematic。 // 更优的方案是使用一个独立的、用于表现的Rigidbody。 // 这里我们先保持简单仅作说明。 // rb.isKinematic true; } } }关键点解析继承自NetworkBehaviour这是所有Mirror网络脚本的基类提供了isServer、isClient、isLocalPlayer等属性和网络生命周期方法。[SyncVar]与 Hook我们定义了四个同步变量来存储最核心的物理状态。每个SyncVar都关联了一个hook方法。当服务器更新这些变量时Mirror会自动将新值同步给客户端并触发对应的hook方法。在hook方法里我们通常将接收到的值赋给一个“目标值”然后在Update或FixedUpdate中平滑地插值过去。客户端处理在Awake中我们注意到一个关键决策客户端Rigidbody的角色。直接禁用(rb.isKinematic true)是最简单的这意味着客户端Rigidbody完全由脚本驱动不参与物理引擎的力计算。这对于仅同步位置/旋转的物体可行。但如果需要同步速度并在客户端也产生物理交互比如与其他客户端本地物体碰撞则需要更复杂的“客户端预测”架构这超出了基础示例的范围。本示例采用服务器权威客户端仅做表现。3.2 服务器端的物理模拟与状态同步服务器端需要做两件事1. 进行真实的物理模拟2. 定期将状态广播给客户端。public class NetworkRigidbodySync : NetworkBehaviour { // ... 之前的变量声明 ... // 同步间隔避免每帧都同步节省带宽 private float syncInterval 0.05f; // 每秒20次 private float lastSyncTime; public override void OnStartServer() { base.OnStartServer(); // 服务器初始化确保Rigidbody是模拟的 rb.isKinematic false; // 初始化同步状态 syncedPosition rb.position; syncedRotation rb.rotation; syncedVelocity rb.velocity; syncedAngularVelocity rb.angularVelocity; lastSyncTime Time.time; } [ServerCallback] private void FixedUpdate() { if (!isServer) return; // 服务器端进行物理模拟FixedUpdate是物理更新周期 // 这里就是你的游戏逻辑施加力、处理碰撞等。 // 例如可以响应来自客户端的命令 // if (Input.GetKey(KeyCode.W)) { rb.AddForce(Vector3.forward * 10f); } // 定期将最新的物理状态更新到SyncVar if (Time.time - lastSyncTime syncInterval) { UpdateSyncVars(); lastSyncTime Time.time; } } [Server] private void UpdateSyncVars() { // 直接更新SyncVarMirror会自动检测变化并同步 syncedPosition rb.position; syncedRotation rb.rotation; syncedVelocity rb.velocity; syncedAngularVelocity rb.angularVelocity; } // 示例一个从客户端接收指令的命令 [Command] public void CmdMove(Vector3 direction) { if (!isServer) return; // 在服务器端施加力 rb.AddForce(direction * 500f); // 状态会在下一个FixedUpdate中的UpdateSyncVars()里同步 } }关键点解析OnStartServer当该对象在服务器上生成时调用。在这里我们确保服务器的Rigidbody是活动的isKinematic false并初始化同步变量。[ServerCallback]这个属性告诉Mirror这个FixedUpdate方法只在服务器端调用。我们在FixedUpdate中进行物理状态同步的检查因为物理更新是在FixedUpdate中进行的。UpdateSyncVars方法这是状态同步的核心。我们直接将服务器Rigidbody的当前状态赋值给[SyncVar]。Mirror底层会检查这些值是否发生变化如果变了就将其序列化并通过网络发送给所有客户端。[Command]CmdMove是一个命令。它可以从拥有此对象权限的客户端通常是本地玩家控制的物体调用。注意命令的方法名必须以Cmd开头。服务器收到命令后执行施加力的操作。所有改变游戏状态的操作都必须通过命令发送到服务器执行。3.3 客户端的状态接收与平滑插值客户端的工作是接收服务器发来的状态并尽可能平滑地应用到本地对象上以创造流畅的视觉体验。public class NetworkRigidbodySync : NetworkBehaviour { // ... 之前的变量和服务器端代码 ... // SyncVar 的 Hook 方法在客户端执行 private void OnSyncedPositionChanged(Vector3 oldPos, Vector3 newPos) { if (!isClient) return; targetPosition newPos; if (!receivedInitialState) { // 第一次收到状态直接设置避免插值导致的跳跃 rb.position newPos; receivedInitialState true; } } private void OnSyncedRotationChanged(Quaternion oldRot, Quaternion newRot) { if (!isClient) return; targetRotation newRot; if (!receivedInitialState) { rb.rotation newRot; } } private void OnSyncedVelocityChanged(Vector3 oldVel, Vector3 newVel) { if (!isClient) return; targetVelocity newVel; // 对于速度我们可能希望立即应用或者也进行插值。这里选择立即应用以快速响应方向变化。 rb.velocity newVel; } private void OnSyncedAngularVelocityChanged(Vector3 oldAngVel, Vector3 newAngVel) { if (!isClient) return; targetAngularVelocity newAngVel; rb.angularVelocity newAngVel; } private void Update() { if (!isClient || !receivedInitialState) return; // 在Update中进行位置和旋转的插值渲染平滑 // 使用Lerp进行线性插值也可以使用SmoothDamp获得更平滑的缓动效果 rb.position Vector3.Lerp(rb.position, targetPosition, positionLerpSpeed * Time.deltaTime); rb.rotation Quaternion.Slerp(rb.rotation, targetRotation, rotationLerpSpeed * Time.deltaTime); // 注意对于高速运动的物体纯Lerp可能导致“滞后感”。 // 更高级的方案是使用“状态快照插值”即缓冲多个过去的状态在正确的渲染时间点进行插值。 // Mirror的NetworkTransform内部就采用了这种机制。对于物理对象如果要求高可以自己实现类似逻辑。 } // 客户端输入示例由本地玩家调用 private void HandleLocalInput() { if (!isLocalPlayer) return; // 确保只有本地玩家控制的对象才处理输入 Vector3 moveInput new Vector3(Input.GetAxis(Horizontal), 0, Input.GetAxis(Vertical)); if (moveInput.magnitude 0.1f) { // 将输入发送到服务器执行 CmdMove(moveInput.normalized); } } private void Update() { // ... 上面的插值代码 ... HandleLocalInput(); } }关键点解析Hook方法这是同步发生时的客户端入口。我们在这里将服务器发来的最新状态newPos,newRot等赋值给targetXXX变量。receivedInitialState标志位用于处理第一次同步避免从默认位置如原点插值到目标位置产生的跳跃感。插值Lerp/Slerp在Update中我们使用Vector3.Lerp和Quaternion.Slerp将物体的当前位置/旋转平滑地向目标位置/旋转过渡。positionLerpSpeed和rotationLerpSpeed参数控制平滑速度。值越大跟随越快但也可能更突兀。速度的同步对于速度和角速度我们选择了立即赋值rb.velocity newVel。这是因为速度是瞬时量直接影响运动趋势。立即同步能让客户端的运动方向快速与服务器对齐尽管位置可能因为延迟仍有偏差但通过位置的持续插值可以弥补。本地输入处理HandleLocalInput检查是否是本地玩家控制的对象isLocalPlayer。如果是则收集输入如键盘然后通过CmdMove命令将输入方向而非计算结果发送给服务器。切记不要在客户端根据输入直接修改Rigidbody的状态如位置、速度这会导致状态不一致。所有状态改变必须经由服务器。实操心得插值速度的调优positionLerpSpeed和rotationLerpSpeed的设定是个经验活。值太小物体会明显滞后于服务器状态感觉“很肉”值太大物体会紧贴服务器状态在网络波动时会产生抖动。一个不错的起始值是15-20。你需要根据物体的运动速度赛车和箱子的最佳值肯定不同和预期的网络延迟RTT进行测试和调整。对于非常高速的物体可能需要结合预测算法。4. 高级议题预测、补偿与防作弊基础的服务器权威同步能解决大部分问题但对于要求高响应性的游戏如FPS、动作游戏纯粹的“等服务器-插值”模式会导致操作延迟感明显。这就需要引入客户端预测Client-side Prediction和服务器回滚补偿Server Reconciliation。4.1 客户端预测的基本概念核心思想客户端不等待服务器确认立即根据本地输入模拟动作并将输入序列发送给服务器。服务器同样按顺序模拟这些输入并将结果状态同步回来。客户端收到服务器状态后与自己的预测状态进行对比和纠正。对于物理对象预测意味着客户端收到输入如按下W键时立即在本地对Rigidbody施加一个力rb.AddForce并记录这个输入和当前时间戳。同时客户端将这个输入命令发送给服务器通过[Command]。服务器收到命令后在服务器的时间线上对权威的Rigidbody施加相同的力。服务器将计算出的状态位置、速度同步回客户端。客户端收到服务器状态后与本地预测的状态进行比较。如果差异在可接受范围内则可能忽略或轻微纠正如果差异很大可能是由于网络延迟、丢包或作弊则需要进行“回滚”将物体状态重置到服务器状态并可能用缓存的输入重新模拟从那个时间点到现在的过程。实现预测是一个复杂的主题它需要确定性的物理模拟确保客户端和服务器在相同输入下产生完全相同的结果。这可能意味着要固定物理步长、避免使用随机数甚至使用自定义的、确定性的物理引擎。输入缓冲与队列客户端需要缓存已发送但未经服务器确认的输入。状态快照与插值不仅要插值当前状态还要能访问过去的状态进行回滚和重演。在Mirror中没有内置的预测系统你需要自己实现这套逻辑。对于刚接触网络物理同步的开发者建议先扎实掌握基础的服务器权威同步再逐步挑战预测。4.2 防作弊考量服务器权威架构本身是防作弊的第一道防线。因为所有关键逻辑伤害计算、物品拾取、物理效果都在服务器执行客户端只是一个“视图”。但针对物理同步仍有需要注意的地方状态验证服务器在收到客户端的移动命令时不能完全信任。需要做基本的合理性检查。例如一个物体的速度是否有上限从一个位置到另一个位置所需的时间是否合理防止瞬移对于我们的CmdMove可以检查施加的力是否在合理范围内。[Command] public void CmdMove(Vector3 direction) { if (!isServer) return; // 防作弊检查方向向量是否单位化力的大小是否合理 if (direction.magnitude 1.1f) { // 允许轻微浮点误差 Debug.LogWarning($可疑的移动指令方向向量长度异常: {direction.magnitude}); return; // 拒绝执行 } float forceMagnitude 500f; // 可以进一步根据玩家状态如是否眩晕动态调整forceMagnitude rb.AddForce(direction * forceMagnitude); }同步频率与精度更高的同步频率能让作弊者更难利用客户端和服务器状态之间的短暂不一致例如在两次同步之间快速修改本地位置并声称自己命中了目标。但也要平衡带宽。关键事件服务器裁决比如碰撞伤害。不应该由客户端报告“我打中了他”而应该由服务器根据双方权威的位置和碰撞体信息进行计算。5. 常见问题与调试技巧实录在实际开发中你会遇到各种各样奇怪的问题。下面是一些典型问题及其排查思路。5.1 物体抖动或抽搐这是网络物理同步中最常见的问题。原因1插值参数不当。Lerp速度太快或太慢。排查在客户端脚本中暴露插值速度参数到Inspector在运行时动态调整观察效果。解决找到适合当前物体运动特性的平滑值。对于慢速物体值可以小一些如5-10对于快速物体值需要大一些如20-30。也可以考虑使用Mathf.SmoothDamp代替Lerp它能提供更自然的缓动。原因2网络延迟波动大。服务器状态到达时间不稳定导致targetPosition跳跃。排查使用Mirror的NetworkManagerHUD显示当前的RTT往返时间和抖动。观察抖动是否与物体抽搐相关。解决实现状态缓冲。不要一收到服务器状态就立即将其设为插值目标而是将其放入一个按服务器时间戳排序的缓冲区。在客户端渲染每一帧时从缓冲区中取出两个时间戳包围当前渲染时间的状态进行插值。这能有效对抗网络抖动。这就是NetworkTransform内部的做法对于要求高的物理同步可以考虑借鉴或直接使用经过修改的NetworkTransform组件。原因3客户端和服务器帧率/物理步长不一致。如果物理计算与帧率相关会导致不同步。排查确保服务器和客户端的Time.fixedDeltaTime物理固定时间步长设置一致。在Project Settings - Time中检查。解决将Fixed Timestep设置为一个固定的值如0.02秒即50Hz并确保所有客户端和服务器使用相同的值。避免使用Time.deltaTime进行物理相关的计算尽量用FixedUpdate和Time.fixedDeltaTime。5.2 物体穿模或碰撞检测不同步原因客户端出于性能或延迟考虑可能使用了简化的碰撞体如将网格碰撞体换成盒碰撞体或者客户端的Rigidbody被设置为isKinematic导致它不会与场景中的其他动力学刚体发生物理交互。排查对比服务器和客户端预制体上的碰撞体组件和Rigidbody设置是否完全相同。解决对于静态环境确保服务器和客户端使用相同的场景几何体。环境碰撞体必须完全一致。对于动态物体间碰撞在纯服务器权威模式下只有服务器上的物理碰撞是“真实”的。客户端之间的物体不会发生物理交互因为它们本地的Rigidbody可能是Kinematic的。服务器在检测到碰撞后需要将结果如A被B撞飞通过状态同步告知所有客户端。客户端收到状态后通过插值更新位置看起来就像发生了碰撞。对于需要即时视觉反馈的碰撞如子弹击中服务器需要快速发送一个[ClientRpc]来触发客户端的特效和音效。5.3 带宽占用过高原因同步频率太高syncInterval太小或者同步的数据量太大比如同步了整个Rigidbody的所有属性。排查使用Unity Profiler的Network窗口或者Mirror的NetworkDiagnostics查看每秒的消息数和字节数。解决降低同步频率对于运动缓慢或不重要的物体将syncInterval调大如0.1秒或0.2秒。压缩数据使用[SyncVar]的hook进行自定义压缩。例如位置和旋转可以用Vector3和Quaternion同步但Quaternion是4个float。如果旋转变化不大可以考虑只同步欧拉角的Y轴用于水平旋转或者使用精度较低的Half类型如果Mirror支持。差值同步只同步变化量超过某个阈值的状态。例如只有当位置变化超过0.01单位或旋转角度变化超过1度时才触发同步。优先级与距离剔除Mirror支持为NetworkIdentity设置更新优先级并为观察者玩家设置更新距离。远处的、不重要的物体同步频率可以更低。5.4 本地输入响应延迟感强原因这是服务器权威架构的固有特性。从按下按键到命令发送到服务器服务器处理状态同步回来客户端再渲染有一个完整的RTT延迟。解决这就是引入客户端预测的主要原因。如前所述预测允许客户端立即响应本地输入。对于物理对象一个简化的“视觉预测”是在发送CmdMove的同时在客户端本地也施加一个力但不将此力产生的结果作为权威状态。当服务器状态同步回来时如果发现本地预测的位置与服务器位置偏差很大则进行纠正可能会有一瞬间的“拉扯”感。更复杂的方案需要实现完整的输入预测和状态回滚。调试时一个非常有用的技巧是在编辑器中同时运行服务器和客户端。在Unity中你可以通过ParrelSync等工具复制项目一个打开作为服务器构建另一个作为客户端构建并连接localhost。这样你可以在同一台机器上运行两者并使用Unity的调试器同时附加到两个进程单步跟踪服务器和客户端的逻辑观察变量如何变化这是理解网络交互最直观的方式。最后网络物理同步没有银弹。你需要根据游戏的具体类型是回合制还是实时竞技物理精度要求多高目标受众的网络环境如何来选择和调整策略。RigidbodyPhysics示例提供了一个坚实可靠的起点掌握了它你就有了解决更复杂网络物理问题的基石。记住测试、测试、再测试在各种网络条件下高延迟、丢包测试你的同步效果是确保最终用户体验的唯一途径。
Unity网络游戏物理同步：Mirror框架下Rigidbody权威同步实战
发布时间：2026/7/11 5:59:47
1. 项目概述为什么我们需要一个物理同步示例如果你在Unity里做过网络游戏尤其是那种带点物理效果的——比如赛车碰撞、角色被击飞、或者一堆箱子可以被推来推去——那你大概率遇到过这个让人头疼的问题为什么我本地跑得好好的一联机物体的运动就飘了、卡了或者干脆不同步了这正是《Unity-Mirror网络框架-从入门到精通之RigidbodyPhysics示例》这个项目要解决的核心痛点。它不是一个简单的“Hello World”网络消息示例而是直击网络游戏开发中最硬核的领域之一权威服务器下的确定性物理同步。Mirror作为Unity社区里备受欢迎的高层网络API它封装了底层传输让开发者能更专注于游戏逻辑。但是它并没有也不可能为你解决所有问题物理同步就是其中最典型的一个。很多新手会想当然地认为给一个GameObject挂上NetworkTransform组件和RigidbodyMirror就能自动处理好一切。但现实是如果你真这么做了在网络上看到的将是各种“灵异现象”物体瞬移、穿模、或者客户端和服务器看到的位置完全不一样。这是因为物理计算尤其是Unity的PhysX物理引擎默认是在本地、每一帧独立进行的。在权威服务器的架构下物理状态位置、旋转、速度必须由服务器计算并同步给所有客户端客户端只能进行表现层的预测和插值而不能“各自为政”地计算物理。这个RigidbodyPhysics示例正是为了演示如何在Mirror框架下正确地构建一套服务器权威的物理对象同步系统。它不仅仅是一个代码片段更是一套完整的设计模式和实践方案涵盖了从网络身份、状态同步、输入处理到客户端预测与服务器校正的全流程。对于任何想要开发具备可靠物理交互的多人游戏如竞技场对战、合作解谜、模拟经营等的开发者来说深入理解这个示例是从“网络编程入门”迈向“精通”的必经之路。2. 核心设计思路服务器权威与客户端表现分离在深入代码之前我们必须先确立一个核心原则服务器是唯一的状态仲裁者。对于物理对象而言这意味着所有物理计算受力、碰撞、运动只在服务器端进行。服务器上的Rigidbody是“真实”的。客户端不进行任何会影响游戏状态的物理模拟。客户端的Rigidbody可能被禁用或者仅用于视觉效果如布娃娃系统的客户端表现。客户端将输入如键盘指令发送给服务器由服务器根据输入施加力或改变速度计算新的物理状态。服务器定期将物理状态位置、旋转、速度同步给所有客户端。客户端收到服务器状态后通过插值Interpolation或预测Prediction来平滑地更新本地对象的位置以掩盖网络延迟。这个设计思路直接回答了网络搜索片段中提到的问题“在Mirror中由于需要在服务器上获取速度计算物理效果使用本地的 Rigidbody 组件是无法完成这个效果的而且也无法实现同步控制。” 因为如果客户端也用本地的Rigidbody去模拟由于网络延迟和帧率差异很快就会和服务器状态分道扬镳。2.1 网络身份与组件结构设计一个典型的可同步物理对象在Mirror中的组件结构应该是这样的YourPhysicsObject (GameObject) ├── NetworkIdentity (Mirror组件标识这是一个网络对象) ├── NetworkTransform (Mirror组件用于同步位置/旋转但需谨慎配置) ├── Rigidbody (Unity物理组件) └── YourPhysicsSyncScript (自定义脚本继承自NetworkBehaviour)这里的关键在于NetworkTransform和YourPhysicsSyncScript的分工。NetworkTransform可以负责基础的位置旋转同步但对于物理对象我们通常需要更精细的控制比如同步速度velocity和角速度angularVelocity。因此更常见的做法是方案A简化使用NetworkTransform同步位置和旋转在自定义脚本中使用[SyncVar]或[Command]/[ClientRpc]来同步Rigidbody.velocity。方案B推荐完全不用NetworkTransform所有状态位置、旋转、速度、角速度都在自定义脚本中通过[SyncVar]钩子函数或自定义序列化进行同步。这提供了最大的控制权。在RigidbodyPhysics示例中我们倾向于采用方案B因为它能让我们清晰地掌控同步的每一个环节特别是处理物理状态的特殊性。2.2 同步策略选择SyncVar、SyncList 还是自定义消息Mirror提供了多种同步机制[SyncVar]最适合同步简单的值类型int, float, Vector3等。当服务器端的SyncVar值改变时会自动同步给所有客户端。我们可以用它来同步位置、旋转、速度。[SyncVar(hook nameof(OnVelocityChanged))] private Vector3 syncedVelocity;[Command]和[ClientRpc][Command]让客户端调用服务器上的函数[ClientRpc]让服务器调用所有客户端的函数。适合用于触发一次性的、事件驱动的同步比如“施加一个冲击力”。[Command] void CmdApplyForce(Vector3 force) { // 只在服务器端执行 rigidbody.AddForce(force); // 然后可能需要通过SyncVar或Rpc同步新的状态 }自定义网络消息最灵活但需要手动管理。适合同步非常规的、结构化的数据包比如一整帧的物理状态快照。对于连续变化的物理状态[SyncVar]配合hook钩子函数是最常用和高效的方式。钩子函数允许我们在值同步到客户端时执行自定义的逻辑比如更新Rigidbody的速度或进行插值计算。注意事项[SyncVar]的同步频率受NetworkManager中Sync Interval的影响。对于高速运动的物理对象你可能需要降低这个间隔比如从默认的0.1秒降到0.02秒但这会增加网络带宽。需要在流畅度和带宽之间做权衡。3. 核心脚本解析构建一个可同步的物理对象让我们来拆解一个名为NetworkRigidbodySync的核心脚本。这个脚本将附着在我们的物理对象上并处理所有网络同步逻辑。3.1 脚本框架与变量声明using UnityEngine; using Mirror; [RequireComponent(typeof(Rigidbody))] public class NetworkRigidbodySync : NetworkBehaviour { // 引用本地Rigidbody组件 private Rigidbody rb; // 同步变量服务器权威的位置、旋转和速度 [SyncVar(hook nameof(OnSyncedPositionChanged))] private Vector3 syncedPosition; [SyncVar(hook nameof(OnSyncedRotationChanged))] private Quaternion syncedRotation; [SyncVar(hook nameof(OnSyncedVelocityChanged))] private Vector3 syncedVelocity; [SyncVar(hook nameof(OnSyncedAngularVelocityChanged))] private Vector3 syncedAngularVelocity; // 插值平滑参数 [SerializeField] private float positionLerpSpeed 15f; [SerializeField] private float rotationLerpSpeed 15f; // 用于客户端插值的目标状态 private Vector3 targetPosition; private Quaternion targetRotation; private Vector3 targetVelocity; private Vector3 targetAngularVelocity; // 标记是否已收到第一次服务器状态用于初始化 private bool receivedInitialState false; private void Awake() { rb GetComponentRigidbody(); // 在客户端我们可能希望禁用Rigidbody的物理模拟只用于插值或表现 if (!isServer) { // 注意不能直接禁用rb因为插值可能需要它。改为设置isKinematic。 // 更优的方案是使用一个独立的、用于表现的Rigidbody。 // 这里我们先保持简单仅作说明。 // rb.isKinematic true; } } }关键点解析继承自NetworkBehaviour这是所有Mirror网络脚本的基类提供了isServer、isClient、isLocalPlayer等属性和网络生命周期方法。[SyncVar]与 Hook我们定义了四个同步变量来存储最核心的物理状态。每个SyncVar都关联了一个hook方法。当服务器更新这些变量时Mirror会自动将新值同步给客户端并触发对应的hook方法。在hook方法里我们通常将接收到的值赋给一个“目标值”然后在Update或FixedUpdate中平滑地插值过去。客户端处理在Awake中我们注意到一个关键决策客户端Rigidbody的角色。直接禁用(rb.isKinematic true)是最简单的这意味着客户端Rigidbody完全由脚本驱动不参与物理引擎的力计算。这对于仅同步位置/旋转的物体可行。但如果需要同步速度并在客户端也产生物理交互比如与其他客户端本地物体碰撞则需要更复杂的“客户端预测”架构这超出了基础示例的范围。本示例采用服务器权威客户端仅做表现。3.2 服务器端的物理模拟与状态同步服务器端需要做两件事1. 进行真实的物理模拟2. 定期将状态广播给客户端。public class NetworkRigidbodySync : NetworkBehaviour { // ... 之前的变量声明 ... // 同步间隔避免每帧都同步节省带宽 private float syncInterval 0.05f; // 每秒20次 private float lastSyncTime; public override void OnStartServer() { base.OnStartServer(); // 服务器初始化确保Rigidbody是模拟的 rb.isKinematic false; // 初始化同步状态 syncedPosition rb.position; syncedRotation rb.rotation; syncedVelocity rb.velocity; syncedAngularVelocity rb.angularVelocity; lastSyncTime Time.time; } [ServerCallback] private void FixedUpdate() { if (!isServer) return; // 服务器端进行物理模拟FixedUpdate是物理更新周期 // 这里就是你的游戏逻辑施加力、处理碰撞等。 // 例如可以响应来自客户端的命令 // if (Input.GetKey(KeyCode.W)) { rb.AddForce(Vector3.forward * 10f); } // 定期将最新的物理状态更新到SyncVar if (Time.time - lastSyncTime syncInterval) { UpdateSyncVars(); lastSyncTime Time.time; } } [Server] private void UpdateSyncVars() { // 直接更新SyncVarMirror会自动检测变化并同步 syncedPosition rb.position; syncedRotation rb.rotation; syncedVelocity rb.velocity; syncedAngularVelocity rb.angularVelocity; } // 示例一个从客户端接收指令的命令 [Command] public void CmdMove(Vector3 direction) { if (!isServer) return; // 在服务器端施加力 rb.AddForce(direction * 500f); // 状态会在下一个FixedUpdate中的UpdateSyncVars()里同步 } }关键点解析OnStartServer当该对象在服务器上生成时调用。在这里我们确保服务器的Rigidbody是活动的isKinematic false并初始化同步变量。[ServerCallback]这个属性告诉Mirror这个FixedUpdate方法只在服务器端调用。我们在FixedUpdate中进行物理状态同步的检查因为物理更新是在FixedUpdate中进行的。UpdateSyncVars方法这是状态同步的核心。我们直接将服务器Rigidbody的当前状态赋值给[SyncVar]。Mirror底层会检查这些值是否发生变化如果变了就将其序列化并通过网络发送给所有客户端。[Command]CmdMove是一个命令。它可以从拥有此对象权限的客户端通常是本地玩家控制的物体调用。注意命令的方法名必须以Cmd开头。服务器收到命令后执行施加力的操作。所有改变游戏状态的操作都必须通过命令发送到服务器执行。3.3 客户端的状态接收与平滑插值客户端的工作是接收服务器发来的状态并尽可能平滑地应用到本地对象上以创造流畅的视觉体验。public class NetworkRigidbodySync : NetworkBehaviour { // ... 之前的变量和服务器端代码 ... // SyncVar 的 Hook 方法在客户端执行 private void OnSyncedPositionChanged(Vector3 oldPos, Vector3 newPos) { if (!isClient) return; targetPosition newPos; if (!receivedInitialState) { // 第一次收到状态直接设置避免插值导致的跳跃 rb.position newPos; receivedInitialState true; } } private void OnSyncedRotationChanged(Quaternion oldRot, Quaternion newRot) { if (!isClient) return; targetRotation newRot; if (!receivedInitialState) { rb.rotation newRot; } } private void OnSyncedVelocityChanged(Vector3 oldVel, Vector3 newVel) { if (!isClient) return; targetVelocity newVel; // 对于速度我们可能希望立即应用或者也进行插值。这里选择立即应用以快速响应方向变化。 rb.velocity newVel; } private void OnSyncedAngularVelocityChanged(Vector3 oldAngVel, Vector3 newAngVel) { if (!isClient) return; targetAngularVelocity newAngVel; rb.angularVelocity newAngVel; } private void Update() { if (!isClient || !receivedInitialState) return; // 在Update中进行位置和旋转的插值渲染平滑 // 使用Lerp进行线性插值也可以使用SmoothDamp获得更平滑的缓动效果 rb.position Vector3.Lerp(rb.position, targetPosition, positionLerpSpeed * Time.deltaTime); rb.rotation Quaternion.Slerp(rb.rotation, targetRotation, rotationLerpSpeed * Time.deltaTime); // 注意对于高速运动的物体纯Lerp可能导致“滞后感”。 // 更高级的方案是使用“状态快照插值”即缓冲多个过去的状态在正确的渲染时间点进行插值。 // Mirror的NetworkTransform内部就采用了这种机制。对于物理对象如果要求高可以自己实现类似逻辑。 } // 客户端输入示例由本地玩家调用 private void HandleLocalInput() { if (!isLocalPlayer) return; // 确保只有本地玩家控制的对象才处理输入 Vector3 moveInput new Vector3(Input.GetAxis(Horizontal), 0, Input.GetAxis(Vertical)); if (moveInput.magnitude 0.1f) { // 将输入发送到服务器执行 CmdMove(moveInput.normalized); } } private void Update() { // ... 上面的插值代码 ... HandleLocalInput(); } }关键点解析Hook方法这是同步发生时的客户端入口。我们在这里将服务器发来的最新状态newPos,newRot等赋值给targetXXX变量。receivedInitialState标志位用于处理第一次同步避免从默认位置如原点插值到目标位置产生的跳跃感。插值Lerp/Slerp在Update中我们使用Vector3.Lerp和Quaternion.Slerp将物体的当前位置/旋转平滑地向目标位置/旋转过渡。positionLerpSpeed和rotationLerpSpeed参数控制平滑速度。值越大跟随越快但也可能更突兀。速度的同步对于速度和角速度我们选择了立即赋值rb.velocity newVel。这是因为速度是瞬时量直接影响运动趋势。立即同步能让客户端的运动方向快速与服务器对齐尽管位置可能因为延迟仍有偏差但通过位置的持续插值可以弥补。本地输入处理HandleLocalInput检查是否是本地玩家控制的对象isLocalPlayer。如果是则收集输入如键盘然后通过CmdMove命令将输入方向而非计算结果发送给服务器。切记不要在客户端根据输入直接修改Rigidbody的状态如位置、速度这会导致状态不一致。所有状态改变必须经由服务器。实操心得插值速度的调优positionLerpSpeed和rotationLerpSpeed的设定是个经验活。值太小物体会明显滞后于服务器状态感觉“很肉”值太大物体会紧贴服务器状态在网络波动时会产生抖动。一个不错的起始值是15-20。你需要根据物体的运动速度赛车和箱子的最佳值肯定不同和预期的网络延迟RTT进行测试和调整。对于非常高速的物体可能需要结合预测算法。4. 高级议题预测、补偿与防作弊基础的服务器权威同步能解决大部分问题但对于要求高响应性的游戏如FPS、动作游戏纯粹的“等服务器-插值”模式会导致操作延迟感明显。这就需要引入客户端预测Client-side Prediction和服务器回滚补偿Server Reconciliation。4.1 客户端预测的基本概念核心思想客户端不等待服务器确认立即根据本地输入模拟动作并将输入序列发送给服务器。服务器同样按顺序模拟这些输入并将结果状态同步回来。客户端收到服务器状态后与自己的预测状态进行对比和纠正。对于物理对象预测意味着客户端收到输入如按下W键时立即在本地对Rigidbody施加一个力rb.AddForce并记录这个输入和当前时间戳。同时客户端将这个输入命令发送给服务器通过[Command]。服务器收到命令后在服务器的时间线上对权威的Rigidbody施加相同的力。服务器将计算出的状态位置、速度同步回客户端。客户端收到服务器状态后与本地预测的状态进行比较。如果差异在可接受范围内则可能忽略或轻微纠正如果差异很大可能是由于网络延迟、丢包或作弊则需要进行“回滚”将物体状态重置到服务器状态并可能用缓存的输入重新模拟从那个时间点到现在的过程。实现预测是一个复杂的主题它需要确定性的物理模拟确保客户端和服务器在相同输入下产生完全相同的结果。这可能意味着要固定物理步长、避免使用随机数甚至使用自定义的、确定性的物理引擎。输入缓冲与队列客户端需要缓存已发送但未经服务器确认的输入。状态快照与插值不仅要插值当前状态还要能访问过去的状态进行回滚和重演。在Mirror中没有内置的预测系统你需要自己实现这套逻辑。对于刚接触网络物理同步的开发者建议先扎实掌握基础的服务器权威同步再逐步挑战预测。4.2 防作弊考量服务器权威架构本身是防作弊的第一道防线。因为所有关键逻辑伤害计算、物品拾取、物理效果都在服务器执行客户端只是一个“视图”。但针对物理同步仍有需要注意的地方状态验证服务器在收到客户端的移动命令时不能完全信任。需要做基本的合理性检查。例如一个物体的速度是否有上限从一个位置到另一个位置所需的时间是否合理防止瞬移对于我们的CmdMove可以检查施加的力是否在合理范围内。[Command] public void CmdMove(Vector3 direction) { if (!isServer) return; // 防作弊检查方向向量是否单位化力的大小是否合理 if (direction.magnitude 1.1f) { // 允许轻微浮点误差 Debug.LogWarning($可疑的移动指令方向向量长度异常: {direction.magnitude}); return; // 拒绝执行 } float forceMagnitude 500f; // 可以进一步根据玩家状态如是否眩晕动态调整forceMagnitude rb.AddForce(direction * forceMagnitude); }同步频率与精度更高的同步频率能让作弊者更难利用客户端和服务器状态之间的短暂不一致例如在两次同步之间快速修改本地位置并声称自己命中了目标。但也要平衡带宽。关键事件服务器裁决比如碰撞伤害。不应该由客户端报告“我打中了他”而应该由服务器根据双方权威的位置和碰撞体信息进行计算。5. 常见问题与调试技巧实录在实际开发中你会遇到各种各样奇怪的问题。下面是一些典型问题及其排查思路。5.1 物体抖动或抽搐这是网络物理同步中最常见的问题。原因1插值参数不当。Lerp速度太快或太慢。排查在客户端脚本中暴露插值速度参数到Inspector在运行时动态调整观察效果。解决找到适合当前物体运动特性的平滑值。对于慢速物体值可以小一些如5-10对于快速物体值需要大一些如20-30。也可以考虑使用Mathf.SmoothDamp代替Lerp它能提供更自然的缓动。原因2网络延迟波动大。服务器状态到达时间不稳定导致targetPosition跳跃。排查使用Mirror的NetworkManagerHUD显示当前的RTT往返时间和抖动。观察抖动是否与物体抽搐相关。解决实现状态缓冲。不要一收到服务器状态就立即将其设为插值目标而是将其放入一个按服务器时间戳排序的缓冲区。在客户端渲染每一帧时从缓冲区中取出两个时间戳包围当前渲染时间的状态进行插值。这能有效对抗网络抖动。这就是NetworkTransform内部的做法对于要求高的物理同步可以考虑借鉴或直接使用经过修改的NetworkTransform组件。原因3客户端和服务器帧率/物理步长不一致。如果物理计算与帧率相关会导致不同步。排查确保服务器和客户端的Time.fixedDeltaTime物理固定时间步长设置一致。在Project Settings - Time中检查。解决将Fixed Timestep设置为一个固定的值如0.02秒即50Hz并确保所有客户端和服务器使用相同的值。避免使用Time.deltaTime进行物理相关的计算尽量用FixedUpdate和Time.fixedDeltaTime。5.2 物体穿模或碰撞检测不同步原因客户端出于性能或延迟考虑可能使用了简化的碰撞体如将网格碰撞体换成盒碰撞体或者客户端的Rigidbody被设置为isKinematic导致它不会与场景中的其他动力学刚体发生物理交互。排查对比服务器和客户端预制体上的碰撞体组件和Rigidbody设置是否完全相同。解决对于静态环境确保服务器和客户端使用相同的场景几何体。环境碰撞体必须完全一致。对于动态物体间碰撞在纯服务器权威模式下只有服务器上的物理碰撞是“真实”的。客户端之间的物体不会发生物理交互因为它们本地的Rigidbody可能是Kinematic的。服务器在检测到碰撞后需要将结果如A被B撞飞通过状态同步告知所有客户端。客户端收到状态后通过插值更新位置看起来就像发生了碰撞。对于需要即时视觉反馈的碰撞如子弹击中服务器需要快速发送一个[ClientRpc]来触发客户端的特效和音效。5.3 带宽占用过高原因同步频率太高syncInterval太小或者同步的数据量太大比如同步了整个Rigidbody的所有属性。排查使用Unity Profiler的Network窗口或者Mirror的NetworkDiagnostics查看每秒的消息数和字节数。解决降低同步频率对于运动缓慢或不重要的物体将syncInterval调大如0.1秒或0.2秒。压缩数据使用[SyncVar]的hook进行自定义压缩。例如位置和旋转可以用Vector3和Quaternion同步但Quaternion是4个float。如果旋转变化不大可以考虑只同步欧拉角的Y轴用于水平旋转或者使用精度较低的Half类型如果Mirror支持。差值同步只同步变化量超过某个阈值的状态。例如只有当位置变化超过0.01单位或旋转角度变化超过1度时才触发同步。优先级与距离剔除Mirror支持为NetworkIdentity设置更新优先级并为观察者玩家设置更新距离。远处的、不重要的物体同步频率可以更低。5.4 本地输入响应延迟感强原因这是服务器权威架构的固有特性。从按下按键到命令发送到服务器服务器处理状态同步回来客户端再渲染有一个完整的RTT延迟。解决这就是引入客户端预测的主要原因。如前所述预测允许客户端立即响应本地输入。对于物理对象一个简化的“视觉预测”是在发送CmdMove的同时在客户端本地也施加一个力但不将此力产生的结果作为权威状态。当服务器状态同步回来时如果发现本地预测的位置与服务器位置偏差很大则进行纠正可能会有一瞬间的“拉扯”感。更复杂的方案需要实现完整的输入预测和状态回滚。调试时一个非常有用的技巧是在编辑器中同时运行服务器和客户端。在Unity中你可以通过ParrelSync等工具复制项目一个打开作为服务器构建另一个作为客户端构建并连接localhost。这样你可以在同一台机器上运行两者并使用Unity的调试器同时附加到两个进程单步跟踪服务器和客户端的逻辑观察变量如何变化这是理解网络交互最直观的方式。最后网络物理同步没有银弹。你需要根据游戏的具体类型是回合制还是实时竞技物理精度要求多高目标受众的网络环境如何来选择和调整策略。RigidbodyPhysics示例提供了一个坚实可靠的起点掌握了它你就有了解决更复杂网络物理问题的基石。记住测试、测试、再测试在各种网络条件下高延迟、丢包测试你的同步效果是确保最终用户体验的唯一途径。
