如何在典型的网络游戏客户端/服务器设置中模拟两个客户端控制的车辆（明智地）碰撞？我确实读过this eminent blog post，其中介绍了一般如何进行分布式网络物理（没有传统的客户端预测），但是这个问题专门针对如何处理拥有对象的冲突。
示例
假设客户端A比服务器提前20毫秒，客户端B比服务器提前300毫秒（计算延迟和最大抖动）。这意味着，当两辆车发生碰撞时，两个客户将在另一辆车的速度相反的方向上看到对方落后320毫秒。瑞典高速公路上的头对头意味着相差16米/17.5码！
不可以尝试的东西
几乎不可能推断出位置，因为我也有非常复杂的车辆，其关节和车身遍布各处，而这些车辆又具有线性和角位置，速度和加速度，更不用说用户输入的状态了。
我不知道完美的解决方案，而且我有一种不存在的感觉。即使您可以准确地预测车辆的未来位置，也无法预测用户操作控件的方式。因此，问题归结为最大程度地减少了客户端/服务器延迟的负面影响。考虑到这一点，我将从principle of least astonishment的位置（维基百科释义）中解决这个问题：
在用户界面设计中，最小惊讶（或惊奇）的原则指出，当界面的两个元素发生冲突或模棱两可时，其行为应为在发生冲突时将使人类用户最不惊奇的行为。
在您的示例中，每个用户看到两辆车。自己的，以及其他玩家的。用户期望自己的车辆能够完全按照其控制的方式运行，因此我们无法进行该模拟操作。但是，用户无法确切知道其他用户如何控制车辆，因此我会使用这种模糊性来掩盖用户的滞后。这里是基本概念：
服务器必须决定即将发生的冲突。碰撞检测算法不必是100％完美的，它必须足够接近以避免明显的不一致。 - 一旦服务器确定两辆车将发生碰撞，它将向两个用户中的每一个发送一条消息，指示即将发生碰撞。
- 在客户A上，车辆B的位置被（实际）调整为保证发生碰撞。
- 在客户端B上，车辆A的位置被（实际）调整为保证发生碰撞。
- 在碰撞后，可以根据需要调整每辆车的位置，以使最终结果与游戏的其余部分保持一致。这部分正是MedicineMan在his answer中提出的。
- 这样，每个用户仍然可以完全控制自己的车辆。发生碰撞时，这不会是意外的。每个用户都会看到其他车辆向他们行驶，他们仍然会感觉到实时仿真。令人高兴的是，该方法在低延迟条件下反应良好。如果两个客户端都具有与服务器的低延迟连接，则调整量将很小。随着滞后的增加，最终结果当然会变得更糟，但这是不可避免的。如果某人在连接上玩快节奏的动作游戏时会有几秒钟的延迟，那么他们根本就无法获得全部的经验。
也许您能做的最好的事情不是实时显示实际碰撞，而是给人一种幻想，那就是实时发生。
很抱歉回答“不要尝试”，但我从未听说过不涉及预测客户端结果的解决方案。考虑一个简化的示例：
关于“什么不可以尝试”。您假设您需要进行完美的预测，但是您永远不会在复杂物理的游戏中找到完美的解决方案。近似值可能是您可以做的最好的事情（例如，大多数商业物理引擎可以将形状投射到物理场景中并返回碰撞的第一点）。
我最终最终要做的就是完全跳过预测，然后简单地这样做：
除了在客户端上预测其他用户的位置并向其发送冲突信息以及如何将其发送给服务器之外，大多数mmo要做的处理滞后的事情是他们让服务器“过去”运行它是。基本上，它们缓冲最近的输入，但仅对过去0.1秒内发生的事情做出反应。这使您可以在需要时“窥视未来”（即，当您的时间范围内将要发生冲突时，您可以查看缓冲的输入以查看将发生的情况并确定冲突是否真实）。
罗斯很有意思。您可以通过将其抽象为一些更简单的体积（例如，车辆的粗略四边形轮廓）来简化用于检测碰撞的模型。然后，当用户因“爆炸”而分心时，可以根据简单的体积进行预测，并根据精确的体积进行详细计算。它可能并不完美，但可以让您加快碰撞检测的速度。