物理模拟的问题
- 物理模拟需要是确定性的吗?
- 应该是发送物理对象的状态还是碰撞事件或者受力?
- 使用UCP还是TCP发送数据?
- 使用C/S还是P2P?
- 需要一个DS吗?
- 怎么隐藏玩家行为的延迟?
- 怎么防止作弊?
- 带宽
同步策略
帧同步
- 只同步输入, 不同步状态
- 优点: 带宽需求很低, 跟对象多少无关
- 难点: 需要保证物理模拟是确定性的, 而浮点数很难保证确定性
- 随机数
- 操作系统
- 编译器
- 硬件
- 缺点: 需要等待最慢的玩家, 人越多越卡, 建议不超过4个
- 带宽: 如果60帧/秒的同步频率, 不适合使用TCP, 因为TCP的包头有40字节
- 延迟: 为了保证平滑, 需要一个延迟缓冲区, 增加了100~250ms
- 问题: CPU瓶颈时不适合使用, UDP丢包也会导致顿卡

快照插值
- 只有服务器端进行物理模拟, 以固定频率发送对象状态快照, 客户端在快照之间进行插值
- 如果同步频率比较快(60帧/秒), 那就不需要同步速度

- 线性插值在曲线运动中的效果不是很好, 可以考虑使用Hermit曲线插值


- 缺点
- 对带宽需求比较大, 需要花费大量精力进行数据压缩

- 带宽占用会随着物理对象数目变化
- 快照之间的插值会引入一些延迟
- 优点
- 同步稳定性好, 能够容忍一定量的丢包
- 方便扩展新的对象类型
状态同步
- 双方都进行物理模拟, 及时同步输入和对象状态变化, 不进行插值
- 对象需要同步全部的状态(包括速度)

- 每次只同步一部分对象状态, 带宽可控
- 需要进行优先级排序和累加



- 只需要2~3帧的延迟来解决网络抖动

- 渲染对象时需要做一个平滑逼近应付跳动的情况

- 优点
- 带宽优化的工作量比较小
- 可控制最高带宽占用
- 延迟比较小
- 缺点
- 同步状态比较多
- 比较难保证预测的质量
- 扩展其它的对象类型比较麻烦(如载具, 关节等)
完整PDF:
链接:https://pan.baidu.com/s/1RoEkOuY8i_XPM-c3_KUyag
提取码:hfej
https://www.gdcvault.com/play/1022195/Physics-for-Game-Programmers-Networking