Sign in to follow this  

bandwidth issues

This topic is 3776 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

Hello, im having some issues getting my game to fit a 64kbps upstream bandwidth limit on the server. I want to limit this to 64kbps so ppl with crappy connections can also play. 98-100% of my bandwidth usage comes from sending "actor updates". Ie the world matrix of all the actors on the map. (Im talking about the server only here). My game has a limit of 8 players, 7 clients and 1 server. Iv tried to limit the size of the "update" package by using a 3x3 16-bit float matrix for global pose. (throwing away 1 vector and calculating it with a cross from the other two) 3x16-bit float vectors for velocity etc. But its far from enough when sending to 8players at 10 updates per sec for say 30 actors. I was thinking about only sending updates for actors that are in view of the player receiving the updates, but in a worst-case scenario, all 8 players could be overviewing all actors at the same time, so its an issue that must be solved anyway. Anyone got any suggestions? Zipping a batchpacket of actor updates of around 1000bytes (or mtu limit) didn't do much, i guess it aint very good for binary data. How low could i drop the updates/second? Im sending 10 per actor per second atm, its a realtime game with collision between players and environment etc. Any help greatly appreciated!

Share this post


Link to post
Share on other sites
I'm a little confused. Is your 64kbps limit a limit on the maximum amount of data the server can send total for all connected clients, or the maximum data rate to send to a single client.

What you may want to try: is instead of sending information for all actors every frame, only send changes. If an actor is stationary, no need to keep sending position/velocity, since it doesn't change. This will make the game bursty, as in when they first enter a popuilated area there will be a touch of lag while the states of all new visible actors arrive, but once that initial state has been established, updates are much fewer.

--Zims

Share this post


Link to post
Share on other sites
First: orientations can be sent as a normalized quaternion. In fact, you can drop one of the values, and send just three floats, and re-derive the fourth (because the quaternion is normalized). This gets orientation down to six bytes (with 16-bit floats). Assume position is 3x16 bits as well, and assume you derive velocity from successive updates (not great, but saves bandwidth).

Let's do the math:

Each player needs to know about 7 other players (assume client is authoritative for itself for now -- let's deal with cheating/corrections later).
This means each update packet is at least 7*(6+6) bytes, or 84 bytes, plus the 28 byte UDP overhead. This assumes the location of the updates within the packets are pre-determined.
84 bytes times 7 players equals 588 bytes per "tick." Not that bad.
64 kbps gives you about 8000 bytes per second, so you can do about 14 ticks per second before you saturate the connection.
However, this doesn't account for interactions (like firing weapons in an FPS), objects (like grenades in an FPS), player chat or overhead for correcting clients that are out of sync. You also want to actually send velocity, rather than derive it, for better interpolation.

Even with a 10 ticks per second rate, it's unclear whether you can actually host a well performing 8-person action game on a 64 kbps uplink.

Share this post


Link to post
Share on other sites
There are many ways to compress your data, all of which come down to the concept of sending information rather than data. eg. Is this an FPS or similar? If so, orientation typically only changes around the up axis, so don't always send the others. Are you tracking a projectile? Their position and velocity can typically be derived using calculus as soon as they're fired, so you don't need to send a further message until a collision happens. Is an actor behind you or otherwise invisible? If so, you may not need to know their orientation at all.

Share this post


Link to post
Share on other sites

This topic is 3776 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