🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Delta Compression: how much compression?

Started by
11 comments, last by tromtrom 6 years ago

You don't need a history buffer on the client when you apply the state in the incoming packets. There are some interpolation mechanisms that will work better if you do, but that's not for communications purposes. You just need to know the packet number that you get. Discard packets that are out of order. Applying the state when you receive it (assuming it's not out-of-order) is sufficient to get the object to a state that you know it has had on the server.

If you miss a packet, the server will just re-send the deltas that were in that packet (or, more accurately, deltas for objects that were in that packet, but with later state) in the next update, because you're not going to acknowledge that packet. And if you discard a packet that arrives out-of-order, that's the same as that packet being dropped.

This assumes that you send ALL the objects that have outstanding changes in each packet. If you want to schedule updates across different packets, it gets a lot more complicated, and you do need at least a "last packet per object" counter, if not the full state, to make it work. So, this delta compression works best for systems with fewer moving objects (dozens, not hundreds or thousands.)

enum Bool { True, False, FileNotFound };
Advertisement
14 hours ago, Hodgman said:

To get rid of the history-buffer concept, you need to use a reliable protocol like TCP, to ensure no deltas are lost and the order of changes is preserved.

Well I'm trying this out in the context of a web browser game, so TCP it is anyway.

Thank you for all the good suggestions :)

This topic is closed to new replies.

Advertisement