6
« on: 2012-09-10, 05:36:15 PM »
You can make reliable connections on UDP the same way TCP does, using ACKs and packet numbers to ensure full packet delivery in the correct order. The difference is that you can make it more efficient than TCP because TCP must ipso facto be generalized for any purpose and therefor is inefficient when you know more specifically what you're sending.
There are plenty of things you can do with this in mind. For example:
If you can get away with it, only sending deltas can additionally speed up data transfers considerably. By that I mean determine only what changed from the previous transmission to this one and send only that data. For example, the player moves horizontally X pixels. This is all the remote client needs to know. Other data, such as Y position, are not necessary
You can keep track of remote data loss and account for that by sending bigger deltas instead of re-sending dropped packets. For example, the player moves X pixels horizontally. It then moves Y pixels vertically for the next transmission, and finally Z pixels vertically for the next. The naive approach sends each packet (X,Y,Z) sequentially. If any packet is not acknowledged, it, and each packet after, are re-sent. Rather than simply sending the three packets with deltas X, Y, and Z, hoping each arrives, you could send each packet as (X), (X,Y), (X,Y+Z), accumulating deltas until you receive acknowledgement of receipt of any of those packets, then reset the delta from there. For example, if you receive acknowledgement of receipt of the packet containing the data X, then your next packet only needs to send (Y+Z) instead of (X,Y+Z). With this approach, you definitely need to keep track of packet numbers. That would be how you specify what the delta refers to.
In our previous example, packet 1 would send X, referring to a base NULL packet. Without receiving acknowledgement of receipt of packet 1, packet 2 would send (X,Y), referring to the same base NULL packet. Then you receive acknowledgement of packet 1. Then packet 3 would send (Y+Z), referring to a base packet 1 instead of NULL.
You can use interpolation on the remote client. For example, we know the player's previous velocity. Assume they keep going on that trajectory until we are told otherwise. Then update with the actual position based on the data received. You would also need to make sure your interpolation doesn't get skewed by a quick change of position due to an updated actual position.