Limiting packet sending
Author
Ok, so my current model is set up with a peer host (acting as server) connected to a bunch of clients.
The game is an FPS. I'm sending packets every time a player moves or changes orientation to the host, who sends this to all the other players.
I noticed a dramatic buildup of packets when sending orientation information (on mouse movement), so I figured I'm sending too many packets. I don't know the correct way to do this, but this is what I figured:
1.) Clients send movement packets to host, only if it has been ~50 ms since last send. (20 updates per second)
2.) Host compares timestamps of received packets, and only broadcasts movement if it has been ~50 ms since last sent packet.
What is the correct way of doing this?
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.
- 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!
Btw: latency is even worse. At the 10% exclusion point, latency is 250 milliseconds; at the 1% exclusion point, it's 540 milliseconds!
Author
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
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.
They use this buffer to interpolate between the last 2 received packets.
Author
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]
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
