2

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

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

4

6 回答 6

3

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

于 2009-06-01T13:35:46.850 回答
2

完整状态会定期同步或根据客户端请求同步。内插/外插可用于在等待完整位置更新时补偿数据包丢失。一些事件需要可靠交付,并且可以添加确认接收的方法。

Glenn Fiedler在他的博客上有一些关于网络游戏的优秀文章

这篇关于 Quake 3 网络的旧文章听起来很相似。增量状态表示从收到的最后一个客户端确认状态的更改。因此,如果服务器发现客户端落后,则将根据客户端状态和当前服务器状态之间的差异创建下一个增量。

于 2008-12-23T21:07:37.607 回答
0

如果不看实现,我会想象数据包 C 还包括数据包的 id,它是来自的增量(在本例中为数据包 B)。

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

于 2008-12-23T21:08:06.657 回答
-1

我猜他们每隔一段时间就会发送一个完整的快照。这就是为什么滞后游戏涉及人们在丢弃增量帧时以错误的速度运行,然后在完整快照出现时“传送”到正确的位置。

于 2008-12-23T21:04:25.243 回答
-1

从链接的文章:

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

于 2008-12-23T21:10:56.993 回答
-1

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

于 2008-12-23T21:34:13.967 回答