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!

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.