GDC2015: Networking for Physics Programmers

物理模拟的问题

• 物理模拟需要是确定性的吗?
• 应该是发送物理对象的状态还是碰撞事件或者受力?
• 使用UCP还是TCP发送数据?
• 使用C/S还是P2P?
• 需要一个DS吗?
• 怎么隐藏玩家行为的延迟?
• 怎么防止作弊?
• 带宽

同步策略

帧同步

• 只同步输入, 不同步状态
• 优点: 带宽需求很低, 跟对象多少无关
• 难点: 需要保证物理模拟是确定性的, 而浮点数很难保证确定性
  
  • 随机数
  • 操作系统
  • 编译器
  • 硬件
• 缺点: 需要等待最慢的玩家, 人越多越卡, 建议不超过4个
• 带宽: 如果60帧/秒的同步频率, 不适合使用TCP, 因为TCP的包头有40字节
• 延迟: 为了保证平滑, 需要一个延迟缓冲区, 增加了100~250ms
• 问题: CPU瓶颈时不适合使用, UDP丢包也会导致顿卡
  

快照插值

• 只有服务器端进行物理模拟, 以固定频率发送对象状态快照, 客户端在快照之间进行插值
• 如果同步频率比较快(60帧/秒), 那就不需要同步速度
  
  • 
• 线性插值在曲线运动中的效果不是很好, 可以考虑使用Hermit曲线插值
  
  • 
  • 
• 缺点
  
  • 对带宽需求比较大, 需要花费大量精力进行数据压缩
    
    • 
  • 带宽占用会随着物理对象数目变化
  • 快照之间的插值会引入一些延迟
• 优点
  
  • 同步稳定性好, 能够容忍一定量的丢包
  • 方便扩展新的对象类型

状态同步

• 双方都进行物理模拟, 及时同步输入和对象状态变化, 不进行插值
• 对象需要同步全部的状态(包括速度)
  *
• 每次只同步一部分对象状态, 带宽可控
• 需要进行优先级排序和累加
  
  • 
  • 
  • 
• 只需要2~3帧的延迟来解决网络抖动
  
  • 
• 渲染对象时需要做一个平滑逼近应付跳动的情况
  
  • 
• 优点
  
  • 带宽优化的工作量比较小
  • 可控制最高带宽占用
  • 延迟比较小
• 缺点
  
  • 同步状态比较多
  • 比较难保证预测的质量
  • 扩展其它的对象类型比较麻烦(如载具, 关节等)

---