Sign in to follow this  

Delta compression with lots o' objects

This topic is 4665 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So, the server is thinking: "The client has just acked sequence 51 which I sent a while ago. I'll make up a packet with all the changes since then and send it over... dum de dum... working... doo dee doo dee doo. Oh, crap! The packet is full, and I haven't done all the objects that need to be updated!" This is a problem. If this packet is sent, the client will do the supplied updates, and ack this packet. As you can see the server will not be handing it the correct information on the next frame. Before I go on, it should be noted that this situation will be most common when a player joins a game. A solution would be easy if we knew that UDP packets would arrive all the time, in order, but this isn't the case. So, basically, how is this problem solved? I'd prefer not to hear "limit the total number of players/other special objects such that the update for all of them will fit in one packet." Some info for one object: char flags (nice and small for 7 values) short object_id char angle (angles truncated to 256) short x,y,z short vx,vy,vz This packet is 16 bytes. Since this would limit me to about 80 players, how could the nasty hypothetical situation be handled? I'm sure games like BF1942 have to worry about this.

Share this post


Link to post
Share on other sites
Since I'm thinking about a hypothetical situation (although 150 players is a fun thought :D), here's a solution:

The server picks it's current sequence and the client's last-acked sequence as where to start. Let's say the server is at frame 24 and the client's last ack is 22. For the next few sequences, the server will be sending the deltas from 24 with respect to 22. Suppose there are 120 objects. Say, object 0 to 40 are in seq 24. It will keep sending these until the client acks 24 or higher. When this happens (say, when the server is at sequence 30), the server sends deltas from 24 wrt 22 until the client acks 30 or higher.

All 120 objects might be done at server sequence 38. The client now knows everything about sequence 24. The server would then be sending deltas from sequence 38 to 24.

This is likely going to be a big change.

In this case, we might as well cycle through objects and HOPE information gets through. As long as packets arrive mostly in order, things should look okay on the client side. No deltas, just the current info, so, all 16 bytes as stated earlier, for each essential object.

Of course, we're talking if 80 people are on some guys screen at one time.

I'll probably write the network code to detect if this kind of problem exists.


Game development tip: Talk to yourself on a helpful development forum. You just might solve the problem by yourself.

Share this post


Link to post
Share on other sites
You can have 2 states:
-out of sync
-synchronized

While the client is out of sync send the current state (without delta-compression) in as many packets as needed and let it ack each one.

Share this post


Link to post
Share on other sites
You can store, per entity, per player connection, what the last acknowledged update for that entity is. Then you prioritize what entities go into your next update based on how relevant they are to the player, and how long ago they last got an update. When sending data, you send relative to the last ack you got per entity. For bit packing efficiency, you may want to sort entities within the packet by what sequence number they are relative to, so you can get run-length encoding of the sequence number itself, but with 8-bit sequence numbers, it's un-clear whether that will be a big win.

Share this post


Link to post
Share on other sites

This topic is 4665 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this