游戏网络物理碰撞

Jon*_*röm 50 network-programming physics

如何在网络游戏的典型客户端/服务器设置中模拟两个客户端控制的车辆(明智地)发生冲突?我确实读过这篇关于如何进行分布式网络物理的博客文章(没有传统的客户端预测),但这个问题具体是关于如何处理自有对象的冲突.

假设客户端A比服务器提前20毫秒,客户端B提前300毫秒服务器(计算延迟和最大抖动).这意味着当两辆车相撞时,两个客户都会看到另一辆车落后320毫秒 - 与另一辆车的速度方向相反.在瑞典高速公路上的对决意味着相差16米/17.5码!

什么不试试

实际上不可能推断出位置,因为我也有非常复杂的车辆,车身上有关节和车身,而车身又有线性和角度位置,速度和加速度,更不用说用户输入的状态了.

e.J*_*mes 13

我不知道一个完美的解决方案,我感觉一个人不存在.即使您可以准确预测车辆的未来位置,您也无法预测用户操作控制的方式.所以问题归结为最小化客户端/服务器延迟的负面影响.考虑到这一点,我会从最不惊讶原则(从维基百科转述)的立场来处理这个问题:

在用户界面设计中,最小惊讶(或惊讶)原则指出,当界面的两个元素冲突或模糊时,行为应该是在冲突发生时最不会使人类用户感到惊讶的行为.

在您的示例中,每个用户看到两辆车.他们自己和另一名球员.用户期望他们自己的车辆的行为与他们控制它的方式完全一致,因此我们无法使用模拟的那个方面.然而,用户无法准确知道其他用户如何控制他们的车辆,并且我将使用这种模糊性来隐藏用户的滞后.

这是基本的想法:

  1. 服务器必须决定即将发生的冲突.碰撞检测算法不必100%完美,它必须足够接近以避免明显的不一致.
  2. 一旦服务器确定两辆车将发生碰撞,它就会向两个用户中的每一个发送一条消息,表明即将发生碰撞.
  3. 在客户A上,(实际地)调整车辆B的位置以保证发生碰撞.
  4. 在客户B上,(实际地)调整车辆A的位置以保证发生碰撞.
  5. 在碰撞之后,可以根据需要调整每辆车的位置,以使最终结果与游戏的其余部分保持一致.这部分正是MedicineMan在他的回答中提出的.

以这种方式,每个用户仍然完全控制他们自己的车辆.发生碰撞时,不会出现意外情况.每个用户都会看到其他车辆向他们移动,他们仍然会有实时模拟的感觉.好消息是这种方法在低滞后条件下反应良好.如果两个客户端都具有到服务器的低延迟连接,则调整量将很小.当然,随着滞后的增加,最终结果会变得更糟,但这是不可避免的.如果某人正在通过几秒钟延迟的连接玩一个快节奏的动作游戏,他们根本就不会获得完整的体验.

  • 这可能会正面碰撞,但是太天真了,因为大多数碰撞都只是轻微的反弹.例如,考虑在其拖车顶部装有吉普车的卡车.或两辆赛车相互驱动.服务器模拟分歧太快. (2认同)

Med*_*Man 6

也许你能做的最好的事情不是那么实时地展示实际的碰撞,而是给出实时发生事情的错觉.

由于客户端在服务器后面(滞后),并且服务器需要显示冲突的结果,也许您可​​以做的,客户端,是显示闪光或爆炸或其他图形分散用户并购买足够的服务器端计算碰撞结果的时间.完成预测后,将其发送回客户端进行演示.


Jon*_*röm 1

我最终所做的只是完全跳过预测并简单地这样做:

  1. 客户对自己的立场有很大的发言权,
  2. 服务器(几乎)仅在与另一个动态对象(即不是静态环境)发生“高能量”碰撞时才说明拥有客户端的位置。
  3. meshoffset=meshpos-physpos客户端在接收到来自服务器的位置更新时进行设置,然后设置meshpos=physpos+meshoffset每一帧并逐渐减小meshoffset

大多数时候(在低延迟情况下)它看起来相当不错,我什至不需要slerp我的四元数来获得平滑的过渡。

跳过预测可能会给高延迟客户带来糟糕的体验,但如果我要发布这款独立游戏,我就没有时间考虑这一点。偶尔创建一个效果足够好但最好的半途解决方案是件好事。;)

编辑:我最终添加了 Glen Fiedler(问题中提到的博主)为《雇佣兵 2》实现的“所有权”功能:每个客户端都获得与它们碰撞一段时间的(动态)对象的所有权。这是必要的,因为否则在高延迟和高速情况下渗透会变得更深。该解决方案的效果正如您在观看 GDC 视频演示时所想象的那样出色,绝对可以推荐它!