Answers:
不喜欢长答案的人的总结...
可以做到，但是如果有任何延迟，就不可能完成完美的多人游戏。解释了延迟为什么会影响物理的原因，然后提供了减少延迟对物理模拟的影响的提示。
创建多人物理游戏可能会充满危险。创建“完美”的在线多人物理体验是不可能的。您可以做一些事情来改善它，但是假设任何延迟，都无法实现完美的物理效果。
问题是，物理必须快速且对现实具有响应能力，但同时必须基于所有因素的综合作用来计算，这意味着所有参与者的综合作用。而且，如果存在延迟，则无法实时完成。
作为开发人员，您需要决定是否可以控制各种因素，并了解如果延迟时间过长，播放器的体验会下降。如果您可以接受（并且您的玩家可以接受），那就去吧。有关如何使事情保持平稳运行的一些说明，请参阅本文末尾。
展示如何弄乱事物的示例
想象一个游戏，其中有两个玩家（客户端）连接到服务器。一条消息从客户端到服务器通过Internet花费100毫秒（1/10秒）。玩家做某事时，会向服务器发送一条消息，说明他们做了什么。然后，服务器将消息广播给其他玩家，以便他们都知道代理玩家的所作所为。
现在创建一个场景，其中两个玩家在地面上有一个板条箱，这是一个物理对象。玩家A一侧击球，使其朝某个方向移动。但是，与此同时，玩家B在另一侧击中它，从而向其发送了另一个方向。
让我们看一下处理此问题的不同方法以及结果是什么...
如果仅在服务器上计算物理量怎么办？
假设我们仅在服务器上计算了物理场。玩家A向服务器发送“我以此方式击中箱子”消息，服务器在1/10秒后收到消息。玩家B发送了“我以其他方式击中箱子”的消息。服务器根据这两个动作的组合来计算物理变化，然后将消息发送回两个玩家，说：“好吧，它就这样运动。” 完美的物理表现是基于两个参与者的综合行动来完成的。
但是问题是，任一位玩家看到板条箱做出反应都将是2/10秒。来自两个播放器的消息都需要1/10秒才能到达服务器，然后再用1/10秒的时间发送给两个播放器的服务器计算结果。
底线是游戏延迟。
如果只是在客户端上计算物理量怎么办？
假设我们仅在客户端上计算了物理学。让我们从玩家A的角度来看它。玩家A击中板条箱，它立即开始向其方向移动。还会向服务器发送一条消息，说明玩家A做了什么。
但是，与此同时，B命中了他们，看到了箱子朝他们的方向前进，并向服务器发送了关于他们所做的消息。
2/10秒后，一条消息从服务器到达客户端。A被告知B做了什么，B被告知A做了什么。两位客户都说，问题在于，“好手X可能已经在该位置击中了，但是该位置不再有板条箱，因此他们的命中什么也没做。”
最重要的是，两场比赛不同步，玩家没有共同的经历。如果多人游戏看到不同的事物，那又有什么意义呢？
如果在客户端和服务器上都计算物理量怎么办？
在这种情况下，物理是在客户端上计算的，因此玩家会立即看到无延迟反应，但是它也在服务器上进行了计算，因此对所有玩家都是“正确的”。
两名球员都按各自的方向击中了板条箱，并且每个人都仅根据击中板条箱看到了移动。但是随后2/10秒后，服务器又回来了，并说：“实际上，你们俩都错了。板条箱就这样走了。” 突然，两个玩家都看到了板条箱彻底改变了方向，并将小故障转移到了新的位置。
最重要的是，一个小故障游戏。
结论
基本上，如果存在任何类型的延迟，就无法与多个玩家一起制作完美的物理游戏。您可以制作出不错的游戏，但始终会有过度延迟的风险，从而给某些玩家带来糟糕的体验。但是，您可以采取一些措施来保持良好的游戏体验。
您可以做的使多人游戏运行良好的事情
使用简单的碰撞体积。当简单的立方体形状可以完成时，不要理会用物理方法对形状的每个细节建模。尖刺球不必建模为物理上的尖刺球。而是将其建模为一个球体。
使小的无关紧要的对象仅作为客户端项目。一个例子可能是破碎的窗户上的碎玻璃碎片。您可以让每个客户端自己模拟它，如果它们不同，则实际上并不重要。
仅当需要使对象成为物理对象以使活动物理对象的数量保持较低时，才使它们成为物理对象。
在进行多人游戏时，请以慢动作运行游戏。想想“子弹时间”。慢动作游戏可以补偿延迟，并允许多个玩家一起与物理互动。
允许玩家一起设置某种情况，然后根据提示对两个玩家进行物理模拟，并观察他们组合动作的结果。直到序列完成，玩家才可以干预序列。
分开播放器，以免彼此干扰。这对于保龄球或台球这样的游戏非常有用，一次只能由一个玩家控制，或者每个玩家都有自己的“沙盒”（如保龄球道）。
如果您无法击败'em，请加入'em，并使物理滞后成为您游戏的一部分。想象一下一个故事，它处于一个故障的宇宙中，具有破裂的物理定律或其他东西:)
附录：射击游戏如何处理
射击游戏通过不做过于复杂的物理处理它。它们确实使用了客户端副作用，因此玩家可以快速看到事物，但是服务器随后对发生的事情进行最后的呼叫。
想象一个场景，玩家A射击玩家B。您的典型射击游戏将执行以下操作：
那么，当A小姐B看起来像打他们时，又如何呢？因为B可能已经移动，但是A尚未看到它，因为服务器尚未发送“ B移到这里”消息给客户端。
Valve在他们的网站上对此有很好的文章。参见http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
我在这里写了一系列有关该主题的文章：http : //www.gabrielgambetta.com/fpm1.html
前三篇文章介绍了该主题，客户端预测，服务器对帐和实体插值（这是回答您的特定问题的部分）的介绍。第四篇文章（即将发布）将涉及“射击内容” :)
蒂姆·霍尔特（Tim Holt）的答案差不多。我的文章有几个图表可以帮助您了解正在发生的事情，但是Tim和我基本上是在说同样的话。
最后，所有关于使用可用网络资源的事情。理想情况下，我们将生活在一个零延迟的世界中，并且所有内容都可以完美同步。实际上，您每隔100、200、300毫秒更新一次客户端，并且在客户端中需要有适当的逻辑以使发生的事情看起来更流畅。“流畅性”非常重要，最终，即使在客户端和服务器之间发生一些混乱的同步，游戏也只需要保持流畅即可。
可以找到一个好的帖子和更好的答案：
问题实际上不是延迟。可以很好地补偿和预测它，以隐藏引起它的任何问题。数据包丢失也不是问题-网络系统应该写得健壮并且可以容忍数据包丢失。但是，问题是滞后峰值和不可预测的延迟。数据包不同步到达，其中某些数据包仅由于延迟波动而丢失，由于延迟波动无法预测和内插等。