3

我正在通过 UDP 实现联网小行星。我打算将客户端发送的用户输入消息限制为状态更改。因此，仅当箭头或空格键上有向下或向上键时才发送消息。这将大大减少从客户端发送的数据包数量。

然而，现在我重新阅读了 Gaffers 关于网络物理的文章以及他关于使 UDP 消息可靠的更复杂的文章，我正在重新考虑。他说：

The key to making this input stream tolerant of packet loss and out of order delivery is the inclusion of a floating point time in seconds value with every input rpc sent. The server keeps track of the current time on the server and ignores any input received with a time value less than the current time. This effectively drops any input that is received out of order. Lost packets are ignored.

因此，它不关心数据包是否丢失。现在我认为指示按下键以将船向前推进的重要数据包可能会丢失，并且永远不会怨恨，从而破坏游戏。

因此，我是否正确地说客户端被迫发送更多常规（最多每次物理更新，每秒 50 次）实际键盘状态的转储，而不是状态更改以适应这种容忍数据包丢失的方案？或者有没有更高尚的方法？

4

3 回答 3

2

正如我在评论中已经说过的那样，没有答案来统治它们。

但在你的情况下，我可能不会转移击键而是物理变化：

  • 仅传输物理变化，例如当物体（玩家、小行星）的加速度发生变化并更改为一般游戏状态（小行星/玩家爆炸、射击、得分）时
  • 当您这样做时，还要传输该对象的当前位置以补偿延迟（即使只有 3 毫秒，对象的位置也会略有不同）并更新适当对象的位置（有时看起来对象可能会跳了一下，但几乎每场比赛都有这个问题）。
  • 其他一切（世界物理，如重力）都可以在客户端本身上计算，不需要通过网络传输。
于 2012-04-05T09:06:18.010 回答
0

基于对我在gamedev上提出的相同问题的回答：https : //gamedev.stackexchange.com/questions/26840/send-regular-keyboard-samples-or-keyboard-state-changes-over-network 似乎一致仅在键盘状态发生变化时发送键盘状态（仅在按下键或按下键时）。这几乎不会产生任何流量。它需要确保这些消息是可靠的。这将是一个挑战，因为消息是时间紧迫的。即，即使客户端可以继续移动他们自己的播放器（ala 客户端预测），其他客户端也需要通过服务器“实时”获知其竞争对手状态的变化。

于 2012-04-05T16:57:24.037 回答
0

另一种方法是握手数据包并重复重新发送，直到实现握手。当然，您需要在两个方向上执行此操作。在过去的串行时代，这可以通过四根控制线完成，每端两根。

于 2016-11-16T09:22:18.793 回答