物理与网络同步
自动关联目录:物理与网络同步
1. 定位
物理模拟是网络同步里最难的部分——因为它是确定性的反义词:微小差异会被积分放大,两端很快跑出完全不同的结果。
一句话定位:能不用网络物理就不用。用"服务端算关键结果 + 客户端做表现"的方式,比同步刚体容易一个数量级。
2. 四种方案
| 方案 | 说明 | 适用 | 难度 |
|---|---|---|---|
| 不模拟,只查询 | 物理只做判定,不动 | 绝大多数场景 | 低 |
| 服务端模拟 + 复制变换 | 权威,但带宽高 | 少量重要物体 | 中 |
| 预测 + 校正 | 客户端先跑,服务端纠正 | 载具、玩家控制的物理体 | 高 |
| 只同步关键状态 | 位置 + 朝向 + 速度,客户端插值 | 常见折中 | 中 |
大多数"看起来需要网络物理"的需求,其实可以降级:
| 需求 | 降级做法 |
|---|---|
| 打碎一堆箱子 | 服务端算哪些碎 + 客户端本地演出 |
| 击飞尸体 | 服务端给一个冲量 + 客户端本地模拟(不要求一致) |
| 可推动的箱子 | 服务端权威位置 + 客户端插值 |
| 载具 | 才真的需要预测 + 校正 |
3. 复制什么
| 方案 | 复制内容 | 带宽 |
|---|---|---|
| 每帧复制变换 | 位置 + 旋转 | 高 |
| 只复制速度 + 关键事件 | 低 | 需要客户端能自行积分 |
| 复制"目标状态" | 客户端插值过去 | 中 |
实用做法:服务端权威 + 以较低频率复制"位置/朝向/速度"三元组,客户端用插值平滑(见 网络预测与回滚)。
4. 为什么两端会不一致
| 原因 | 说明 |
|---|---|
| 浮点非确定性 | 微小的初始差异被积分放大 |
| 帧率不同 | 积分步长不同 → 结果不同 |
| 碰撞顺序不同 | 解算顺序影响结果 |
| 客户端本地扰动 | 本地的碰撞事件只在一端发生 |
因此"让两端物理完全一致"在工程上基本不可行,可行的是"服务端权威 + 客户端尽量平滑地跟上"。
5. 代价与权衡
| 设计 | 收益 | 代价 | 什么时候不该用 |
|---|---|---|---|
| 完全不联网物理 | 最简单可靠 | 表现可能两端不同 | 要求严格一致时不行 |
| 每帧复制变换 | 一致 | 带宽高、抖动可见 | 大量物体不可用 |
| 预测 + 校正 | 手感好 | 实现最复杂,回滚难做 | 只有玩家直接控制的物体值得 |
| 低频复制 + 插值 | 折中 | 有延迟 | 对延迟不敏感的物体 |
| 服务端权威 | 防作弊(见 Security) | 延迟 | 关键判定必须有 |
6. 踩坑与排查
| 坑 | 现象 | 怎么验证 |
|---|---|---|
| 物理体参与复制 | 抖动、拉扯 | 降低复制频率 + 客户端插值 |
| 客户端改物理状态 | 被服务端覆盖,抖动 | 要走 Server RPC |
| 期望两端完全一致 | 永远做不到 | 物理不是确定性的(帧率/顺序都会影响) |
| 每帧复制所有物理体 | 带宽爆炸 | 只复制关键物体,降频 |
| 高速物理体穿透 | 客户端看不到 | 用 Sweep(见 碰撞与查询) |
| 修复抖动只加复制频率 | 治标 | 应该加插值/平滑 |
| 判定用客户端物理结果 | 可作弊 | 服务端权威 |
7. 排查顺序
1. 先问:真的需要联网物理吗?→ 能降级就降级
2. 抖动?→ 复制频率 + 客户端插值(不是只提频率)
3. 拉扯?→ 是否有客户端本地修改
4. 不一致?→ 接受它,改为服务端权威 + 表现层容错
5. 手感差?→ 才考虑预测 + 校正(成本最高)
6. 带宽?→ 只同步关键物体 + 降频参考
- 碰撞与查询 · 刚体与 Chaos 破坏 · 载具
- 网络预测与回滚 · RPC 语义与可靠性 · Security
- 项目资料:UE4 的物理同步、载具物理同步见本分类
Z Reference Link
许可协议:CC BY
作者:Davids
本文链接:https://hustjjd.github.io/c388a67a.html
更新于:2026年10月10日