在网络游戏中通过UDP发送键盘输入

Question

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

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

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次）实际键盘状态的转储而不是状态更改以适应容忍数据包丢失的这种方案？还是有更高尚的方式？

Answer 1

正如我在评论中所述，没有答案可以统治所有人。

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

• 仅传输物理变化，例如：当物体（球员，小行星）的加速度发生变化并改变为一般游戏状态（小行星/玩家爆炸，射击，得分）时
• 当你这样做时，也要转移该对象的当前位置以补偿滞后（即使只有3ms，对象的位置会略有不同）并更新相应对象的位置（有时可能看起来像对象会跳跃一点，但几乎每个游戏都有这个问题。）
• 其他一切（世界物理学如引力）可以在客户端本身计算，不需要通过网络传输。

Answer 2

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

Answer 3

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