实时多人游戏(概念问题)

时间:2008-12-23 20:59:42

标签: networking compression real-time multiplayer

我一直在阅读Valve的this article,它似乎解释了他们的多人游戏系统的架构。它们似乎延迟了客户端上几个滴答的渲染,因此它们可以处理丢弃的数据包,但它们也会将数据包作为“增量快照”(两个相邻状态之间的差异)发送。

假设我们有时间A,B,C,并且客户端在时间A是正确的但是将数据包丢弃在B处,然后在C处接收该数据包。如何在时间C正确地推断出状态? C处的数据包只告诉(我认为)状态B和C之间的差异,而客户端只知道A处的状态。我在这里缺少什么?

6 个答案:

答案 0 :(得分:3)

增量不必相对于之前发送的消息(通过增量或快照)。相反,它们将相对于最后一个已确认的状态。因此,在上面的示例中,C处的更新可能是相对于A的增量。因此,丢失消息B变得不方便,因为增量越来越大(并且可能正在累积错误),但最终消息将通过并被确认,并且服务器可以开始相对于更新状态发送增量。

答案 1 :(得分:2)

定期或根据客户要求同步完整状态。 Interpolation / extrapolation可用于在等待完整位置更新时补偿数据包丢失。有些活动需要重新递送,并且可以添加确认收据的方式。

Glenn Fiedler在他的excellent articles上有一些关于网络游戏的blog

This old article about Quake 3 networking听起来很相似。增量状态表示从上次收到的客户端确认状态的更改。因此,如果服务器发现客户端落后,那么将根据客户端状态和当前服务器状态之间的差异创建下一个增量。

答案 2 :(得分:0)

在不查看实现的情况下,我认为数据包C还包括数据包的id,它是delta(在本例中是数据包B)。

当客户端收到数据包A之后的数据包C时,它会知道它还没有看到数据包B,因此可以从服务器请求完整更新。

答案 3 :(得分:-1)

我猜他们偶尔发送一个完整的快照。这就是为什么滞后游戏会让人们在三角形帧被丢弃时以错误的速度运行,然后在完整快照进入时“远程传送”到正确的位置。

答案 4 :(得分:-1)

来自链接文章:

  

通常,只有在游戏开始或客户端遭受大量数据包丢失几秒钟时才会发送完整(非增量)快照。客户端可以使用cl_fullupdate命令手动请求完整快照。

答案 5 :(得分:-1)

服务器可能会定期发送完全同步(即不是增量)但不太频繁。这就是我正在做的事情,至少。