GDC2015: Networking for Physics Programmers

物理模拟的问题

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

同步策略

帧同步

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

快照插值

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

状态同步

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

你可能感兴趣的:(动画物理)