General compression (zlib, lzma, etc) on packets should be a last resort. Usually, the results are quite disappointing, and you will be adding a lot of overhead to your networking (anywhere from 2x to 20x or more overhead per byte sent). There is nothing wrong with compressing specific things known to compress decently, such as verbose messages (e.g. a long quest description, pages of a book, etc), but you don't want to just mass-compress everything over the network.

First, figure out what exactly is taking so much bandwidth. Add an aggregate counter to your server to keep track of how much data is sent per each packet ID, then start working on the most expensive stuff. Often times, excessive bandwidth can be found in:

1. Possible client-side caching. Don't send full game messages (e.g. "You got # gold") to the client. Instead, store this all on the client, and just send the unique ID of the game message and the parameters, and let the client take care of the rest.

2. Sending too much of the same thing. If you are sending the new position of entities every tick (and aren't using UDP with the intention of a low-latency game like a FPS), your bandwidth will definitely take a big hit.

3. Lack of delta updates. If a single stat changes, don't send the new value for all the stats. If a character's name or sprite changes, don't send every bit of data to recreate them. Send updates on what has changed, nothing more. Though don't get carried away with this one before profiling, as it can make maintenance much more difficult.

4. Too many bits. If you have tile-based maps < 255x255, don't send a 32-bit integer as the position. If you have a bunch of bools, don't send them each as a byte. Though again, don't go overboard with this, as it puts some expansion limitations on you. A good bit stream library can be really helpful here.

Quake3 used Huffman encoding to compress their final packets. I don't know if it is a dynamic or static table though.

But yeah, in general, that sort of compression should be a last resort. If you send too much data, then the problem is elsewhere, and you should look at minimising the transmission. Compressing packets is more like an optimisation rather than a solution to a problem.

There are schemes such as delta-encoding that can work for you as well. But your best saving will be in managing the network tick and prioritise entity updates.

Quote: if you have a lot of small ( < 1000 bytes) packets

A 1000 byte packet is *huge* for games.

If your entire upstream is 8 kB/sec, which should include voice chat, that would mean you could only send 8 packets/second.

Both Sony and Microsoft put the upstream "sweet spot" (99% coverage) at 8 kB/sec, btw.

The way I like to view it is that games apply compression at a much higher (semantic) level. Entropy coding style compression (be it lzw, huffman, or something else) can help some (say, 30%?) but the big gains (thousands of percent) come from the application layer.

After all, a game is nothing more than a really big, advanced query that runs 60 times per second :-)

"select pixel from .... where input=..." :-)