示例
假设客户A领先服务器20毫秒,客户B领先服务器300毫秒(计算延迟和最大抖动),这意味着当两个车辆发生碰撞时,两个客户都会看到对方在另一个方向上相对于另一个车辆的速度落后320毫秒。在瑞典公路上迎面而来意味着差异16米/17.5码!
不要尝试的方法
由于我的车辆非常复杂,具有各种关节和身体,这些身体又具有线性和角位移、速度和加速度,更不用说用户输入的状态了,因此几乎不可能外推位置。
假设客户A领先服务器20毫秒,客户B领先服务器300毫秒(计算延迟和最大抖动),这意味着当两个车辆发生碰撞时,两个客户都会看到对方在另一个方向上相对于另一个车辆的速度落后320毫秒。在瑞典公路上迎面而来意味着差异16米/17.5码!
由于我的车辆非常复杂,具有各种关节和身体,这些身体又具有线性和角位移、速度和加速度,更不用说用户输入的状态了,因此几乎不可能外推位置。
在用户界面设计中,最小惊讶原则(或惊奇原则)指当界面的两个元素发生冲突或模糊时,行为应该是最不会让人类用户在冲突发生时感到惊奇的行为。
在您的示例中,每个用户都看到两辆车。他们自己的车和另一个玩家的车。用户期望自己的车辆表现出他们所控制的方式,因此我们无法改变模拟的这个方面。然而,用户无法确切知道其他用户如何控制他们的车辆,我会利用这种模糊性来隐藏用户的延迟。
以下是基本思路:
这样,每个用户仍然完全控制自己的车辆。当发生碰撞时,它不会是意料之外的。每个用户都会看到另一辆车向他们移动,他们仍然会感到实时模拟的感觉。好处是,这种方法在低延迟条件下反应良好。如果两个客户端与服务器的连接具有低延迟,则调整量将很小。当然,随着延迟的增加,最终结果会变得越来越差,但这是不可避免的。如果有人在连接具有数秒延迟的情况下玩快节奏动作游戏,他们简单地无法获得完整的体验。
很抱歉我的回答是“不要尝试”,但我从未听说过不涉及客户端预测结果的解决方案。考虑一个简化的例子:
客户端A静止不动,观察客户端B的车辆接近悬崖。客户端B的车辆能够在最后一刻立即减速到0,并在掉下悬崖之前做到这一点。
如果客户端A试图实时显示客户端B的状态,则客户端A别无选择,只能预测客户端B已经掉下悬崖。在许多设计为玩家角色能够在全速奔跑时立即停止的MMORPG中,您会看到这种情况。否则,客户端A可以随着状态更新而显示客户端B的状态,但在您的情况下,这是不可行的,因为客户端A需要能够与客户端B实时交互(我猜测)。
您是否可以尝试简化碰撞模型,以便进行实时预测?也许让您的“关节和身体”具有处理器不密集的物理模型,例如几个立方体或球体。我不太熟悉如何提高碰撞检测的效率,但我认为可以通过检测比视觉模型更简单的模型的碰撞来完成。
meshoffset=meshpos-physpos
,然后每帧设置 meshpos=physpos+meshoffset
,并逐渐减少 meshoffset
。编辑:最终我还是加入了Glen Fiedler(问题中提到的博主)在《战地2》中实现的“所有权”功能:每个客户端会暂时获得它们碰撞到的(动态)对象的所有权。这是必要的,因为否则在高延迟和高速情况下穿透会变得很深。当你看到GDC视频演示时,这种解决方案的效果就像你想象的那样好,我绝对推荐它!
一些想法。
因此,如果这是您自己的引擎,则切换到点对点。然后,根据其他对等方的按钮输入向前移动,将其车辆进行外推,以确定其当前位置。您可以设置碰撞,使其与其他车辆发生碰撞,就像它是世界上的东西一样。也就是说,您承受了打击。
这意味着当您与其他人相撞时,您会弹开,在对等方的网络上,他们会弹开,因此看起来大致正确。延迟越低,它的工作效果越好。
尝试以下事项 o)像p2p一样向前推算客户端以执行碰撞检测。 o)将碰撞结果发送回客户端并向前外推。
请注意,这永远不可能像p2p那样好。从根本上讲,高速和延迟=误差,因此消除延迟是最佳策略。P2P做到了这一点。