Members - Reputation: 132
Posted 27 June 2014 - 05:08 PM
Members - Reputation: 3857
Posted 27 June 2014 - 10:00 PM
My player would send a movement datagram, saying that he moved to the left.
The server may/may not receive this. If it does receive this, the server will then send back an acknowledgement. If the client does not receive this after a certain amount of time (I set an alarm which is equal to double the ping), then we assume the datagram was dropped and we send the exact same data (move left) to the server and the process repeats until we have an acknowledgement.
How is this any better than just using TCP? If you don't also have sequence numbers and protection against delayed duplicates, this will actually be much worse than TCP (i.e. it's broken).
2) Is this system really necessary? In other words, do I really need to worry about datagrams being dropped?
They will be dropped. Whether you need to worry about it is another question that is highly dependent on all sorts of game-specific factors, like how important it is in your game's architecture to get every message. The server for example can continuously stream positions to the client. If the client misses some of those updates there will be no reason to retransmit them since there will be a new update on its way. The retransmission would be a pointless use of bandwidth just to send stale data.
There are a myriad of ways to get the client inputs up to the server fairly reliably. The client can stream input state or retransmit commands. Queuing a message for every input event and reliably delivering it (with sequencing and retransmission) has many advantages, though it's certainly not the only way. In such a case you will need message sequence IDs and a system to retransmit non-acked messages.
There is going to need to be some advanced logic on both client and server to make the lag (independent of dropped packets!) tolerable. The server needs to deal with the fact that it doesn't know about player input until some time after the player produced that input and the client needs to deal with the fact that it doesn't know what other players did until some time after the server found out. In particular, you may find that you need a model where the player moves instantly on his local client and uses the server updates as hints rather than authoritative positions, as otherwise all player input lags on a round-trip to the server and feels horrible.
I highly suggest you read and then re-read:
Note these have some contradictory approaches. There is no best way to do something for all games, so you will need to evaluate the models for your specific game to choose a satisfactory solution. You'll also notice that a considerable amount of thought and effort has to go into hiding lag/latency.