I am implementing networked asteroids over UDP. I was going to limit the user input messages the the client sends to just state changes. So only send a message when there is a key down or up on the arrow or space keys. This would greatly reduce the amount of packets sent from the client.
However, now that I have re-read Gaffers article on networked physics and his more complex one about making the UDP messages reliable I am rethinking. He states:
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.
So it is not caring if a packet is lost. Now I am thinking that the vital packet that indicates keydown to thrust the ship forward could be the one to be lost, and never resent, thus breaking the game.
Am I therefore right in saying that the client is instead forced to send more regular (up to every physics update, 50 times per second) dumps of actual keyboard state rather than state changes to fit in with this scheme that is tolerant of packet loss? Or is there a more noble way?
Based on a response to an identical question I asked over on gamedev: https://gamedev.stackexchange.com/questions/26840/send-regular-keyboard-samples-or-keyboard-state-changes-over-network the concensus seems to be to only send keyboard state when it changes (at the time of key down or key up only). This generates hardly any traffic. It necesitates ensuring that these messages are reliable. This will be a challenge to achieve as the messge is time critical. i.e. even though the client can proceed to move their own player (ala client side prediction), the other clients need to be informed of the change in the state of their competitor, via the server, and in “real time”.