1
\$\begingroup\$

I have started work on a new game project where users are in an open environment and fight each other in a fast-paced shoot-out. I know that compressing all of the WebSocket's payload data using zlib can be a significant improvement over non-compressed data in terms of bandwidth, but does the latency of packing/unpacking data have more advantages over not packing it?

I know using zlib on the data can have some advantages - less bandwidth and harder for hackers to read the data, but it also has a disadvantage - takes time to [un]pack.

Should I use zlib in a game where latency could be the difference between life or death?

\$\endgroup\$
  • \$\begingroup\$ Have you measured your current bandwidth use, or the time taken to compress/decompress your packets, so see whether you have a problem with either approach? \$\endgroup\$ – DMGregory May 24 at 3:36
1
\$\begingroup\$

The time it takes to pack and unpack the data is likely negligible.

But there is a different problem: Compression works best when you have a lot of data to compress. So if you want compression to be effective, you might end up withholding data until you have enough of it that it is worth compressing. This is at odds with the goal of reaching low latency.

Also, most of the data you send in a typical "fast-paced shoot-out" won't be very compressible anyway.

However, there might be situations where you need to send a lot of well-compressible data at once. In these situations, compressing the message payload might be a worthwhile endeavour.

\$\endgroup\$
  • \$\begingroup\$ "Compression works best when you have a lot of data to compress." I've seen game data transmission compression systems that evolve a data model from past packets in order to more efficiently compress the next packet — so some advantages of compressing a large stream of data don't rely on all of that data being handled in one batch. \$\endgroup\$ – DMGregory May 24 at 17:01
1
\$\begingroup\$

TL;DR: Will compression hurt? No. But it probably won't help you if your goal is a very responsive game.

You have two problems to solve with connectivity...

Can I get enough data to the client in time?
In other words, is my bandwidth enough? Is the "pipe" I have to send data big enough to carry the data? If you can't send enough data in time, then compressing it helps as it lets you send more down that pipe in the same amount of time.

Can I get data to the client fast enough?
In other words, is my latency low enough? Is there enough "pressure" in the pipe I have high enough to push data quickly? If you can't get data fast enough, then compression doesn't help. If you can send all the data you want, but not fast enough (no matter how small the data packet), latency is important.

Bandwidth ("Can I get enough data to the client on time?") is where compression will help you. Think like streaming a high quality video - you need to send as much as possible as fast as possible. But unless you are watching a live event where seeing what happens immediately is important, you don't care if it's a few seconds behind.

Latency ("Can I get data to the client fast enough?") is where compression will not help you. It doesn't matter how much data you can send if you can't send it fast enough. Compression doesn't make it faster, it just means you can send more. You could want to send only 1 byte really fast, but, if the connection is slow (high latency), compression won't do a thing for you.

So based on your desire for a very responsive game, then no - compression won't help you. That's because you want very low latency. If a player presses a button to trigger an action, you want your message to get to the other player as fast as possible.

If you do think your latency is low but your data still lags, then yes maybe compression will help. But you're better off focusing on

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.