Limiting packet sending

On a game I'm working on, we did a few things to reduce traffic:

- Host only sends an object's info to a client if the client would be able to see the object (we actually compute frustum culling for the object's bounding sphere on the host to determine this). We also send a small bitfield that tells the client to hide objects that it should not be able to see, in case the object suddenly teleports into or out of view.

- We send object updates in an every-Nth-frame manner, with objects closer to a given client using a lower N.

- We use an unreliable protocol for object position/orientation so that if the clients drop a packet of updates, we don't have to resend it. We just send updates for the newest posision/orientation only. We piggy-back a reliable messaging system on top of the unreliable data.

- We don't have a way to limit host-receive flooding caused by too many clients trying to send updates, so we just arbitrarily limited the maximum number of clients.

Generally, there will be a "packet rate," and a new packet will be generated every packet rate pulse. Whatever needs to go into that packet, is put into that packet at that time, which may be almost nothing (if everyone's standing still), or a lot (if everyone's moving). You should make sure to structure your networking such that you can guarantee an upper bound on bandwidth. If an update is 16 bytes per active player, say, then for an 8-player game, with a tick rate of 20, that will be 16 * 7 * 8 * 20 bytes sent by the server each second, which is about 18 kB per second, plus some overhead for framing and packet headers. At 20 kB per second, 90% of internet gaming connections will be able to keep up -- but this means 10% won't! (Stats taken from data released by Bungie in the Halo 3 beta)
Btw: latency is even worse. At the 10% exclusion point, latency is 250 milliseconds; at the 1% exclusion point, it's 540 milliseconds!

Alright, this is what I did:

1.) I ended up only sending orientation and position packets if the time since the last packet sent was greater than 25 milliseconds.

2.) Sent packets sequenced (but still reliable) to drop old packets.

I played around with the numbers and this had the best smoothness/performance ratio. It now looks MUCH better.

In theory, if I increased the required update time to something like 75-100 ms (which would look choppy) and somehow interpolated between the previous and current positions quickly enough, would this look and perform better? Is this something that games do?

Thanks for the help guys

Valve actually runs the client "in the past" compared to the server, so that there's kind of a "time buffer" between the client's displayed state and the actual known state.
They use this buffer to interpolate between the last 2 received packets.

I just added in a simple routine to interpolate a single point in between the previous and current position, and render the interpolated point 1 frame before rendering the current position. This makes 20 updates per second look like 50 updates per second, smoothness wise, and it still seems very accurate with the active positions.

Do games usually use a single interpolation point, or do they do more to make it even smoother? Like 10 updates per second with 3 interpolation points over 3 frames?

[Edited by - Chris Reynolds on November 9, 2009 3:42:15 PM]

Quote:

Is this something that games do?

Absolutely! If you read the Forum FAQ, you'll find some pointers to various articles on the subject of interpolation/extrapolation.