Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualfrob

Posted 24 August 2013 - 10:47 PM

- Use integers instead of floats. I don't generally need the precision for x,y movement coords.

Both are 32 bits, unless there is something you are not telling us.

- Send local grid coordinates not world coordinates.

How is that smaller?

- base 62 encoding of string id's

Why base 62? Your goal is to reduce the number of bits sent, that would increase the number.

- don't send data if it hasn't changed since last update

Excellent.

- partial coordinates. Only send coordinate values that have changed by a certain threshold. So a client might get a vector with x being empty, which means use the last known value.

Excellent.

If anyone has ideas on best compression algorithms, or other tricks to keep bandwidth usage down, let me know!

Only two of those items above actually reduces the number of bits. Do more things that reduce the number of bits.

When you encode and decode your larger packets you should generally have some form of bit packer. If there are only 3 options don't add a full int (32 bits) to the message, you can represent it with just 2 instead of 32. If your integer has a small numeric range, reduce the number of bits to those that contain the range. If your number can be reasonably represented by a 16-bit float, use that instead of a 32-bit float. Delta-encoding is another way to reduce the number of bits; if you know something can only have moved up to /n/ distance in the most extreme case, subtract the new value and store only the necessary log2(n) bits rather than 32. Repeat the process of stripping out unused bits for each of the messages that you need to send.

If your messages are STILL too large, use a compression algorithm. For TCP you can use a stream-based general purpose compression algorithm, for UDP you might be able to use a stream algorithm, but you sadly might need to compress each packet individually. Stream-based may require take more data to go through but can give better overall results. Message-based compression is hard because the algorithms only have a few bytes to encode, and hopefully they are high-entropy due to the encoding already mentioned so the compressor will struggle to improve it.

#3frob

Posted 24 August 2013 - 10:45 PM

- Use integers instead of floats. I don't generally need the precision for x,y movement coords.

Both are 32 bits, unless there is something you are not telling us.

- Send local grid coordinates not world coordinates.

How is that smaller?

- base 62 encoding of string id's

Why base 62? Your goal is to reduce the number of bits sent, that would increase the number.

- don't send data if it hasn't changed since last update

Excellent.

- partial coordinates. Only send coordinate values that have changed by a certain threshold. So a client might get a vector with x being empty, which means use the last known value.

Excellent.

If anyone has ideas on best compression algorithms, or other tricks to keep bandwidth usage down, let me know!

Only two of those items above actually reduces the number of bits. Do more things that reduce the number of bits.

When you encode and decode your larger packets you should generally have some form of bit packer. If there are only 3 options don't add a full int (32 bits) to the message, you can represent it with just 2 instead of 32. If your integer has a small numeric range, reduce the number of bits to those that contain the range. If your number can be reasonably represented by a 16-bit float, use that instead of a 32-bit float. Delta-encoding is another way to reduce the number of bits; if you know something can only have moved up to /n/ distance in the most extreme case, subtract the new value and store only the necessary bits. Repeat the process of stripping out unused bits for each of the messages that you need to send.

If your messages are STILL too large, use a compression algorithm. For TCP you can use a stream-based general purpose compression algorithm, for UDP you might be able to use a stream algorithm, but you sadly might need to compress each packet individually. Stream-based may require take more data to go through but can give better overall results. Message-based compression is hard because the algorithms only have a few bytes to encode, and hopefully they are high-entropy due to the encoding already mentioned so the compressor will struggle to improve it.

#2frob

Posted 24 August 2013 - 10:44 PM

- Use integers instead of floats. I don't generally need the precision for x,y movement coords.

Both are 32 bits, unless there is something you are not telling us.

- Send local grid coordinates not world coordinates.

How is that smaller?

- base 62 encoding of string id's

Why base 62? Your goal is to reduce the number of bits sent, that would increase the number.

- don't send data if it hasn't changed since last update

Excellent.

- partial coordinates. Only send coordinate values that have changed by a certain threshold. So a client might get a vector with x being empty, which means use the last known value.

Excellent.

If anyone has ideas on best compression algorithms, or other tricks to keep bandwidth usage down, let me know!

Only two of those items above actually reduces the number of bits. Do more things that reduce the number of bits.

When you encode and decode your larger packets you should generally have some form of bit packer. If there are only 3 options don't add a full int (32 bits) to the message, you can represent it with just two. If your integer has a small numeric range, reduce the number of bits to those that contain the range. If your number can be reasonably represented by a 16-bit float, use that instead of a 32-bit float. Delta-encoding is another way to reduce the number of bits; if you know something can only have moved up to /n/ distance in the most extreme case, subtract the new value and store only the necessary bits. Repeat the process of stripping out unused bits for each of the messages that you need to send.

If your messages are STILL too large, use a compression algorithm. For TCP you can use a stream-based general purpose compression algorithm, for UDP you might be able to use a stream algorithm, but you sadly might need to compress each packet individually. Stream-based may require take more data to go through but can give better overall results. Message-based compression is hard because the algorithms only have a few bytes to encode, and hopefully they are high-entropy due to the encoding already mentioned so the compressor will struggle to improve it.

#1frob

Posted 24 August 2013 - 10:40 PM

-  Use integers instead of floats.  I don't generally need the precision for x,y movement coords.

Both are 32 bits, unless there is something you are not telling us.

- Send local grid coordinates not world coordinates.

How is that smaller?

- base 62 encoding of string id's

Why base 62? Your goal is to reduce the number of bits sent, that would increase the number.

- don't send data if it hasn't changed since last update

Excellent.

- partial coordinates.  Only send coordinate values that have changed by a certain threshold.  So a client might get a vector with x being empty,   which means use the last known value.

Excellent.

If anyone has ideas on best compression algorithms, or other tricks to keep bandwidth usage  down, let me know!

Only two of those items above actually reduces the number of bits. Do more things that reduce the number of bits.

When you encode and decode your larger packets you should generally have some form of bit packer. If there are only 3 options don't add a full int (32 bits) to the message, you can represent it with just two. If your integer has a small numeric range, reduce the number of bits to those that contain the range. If your number can be reasonably represented by a 16-bit float, use that instead of a 32-bit float. Since you know the details about your data you can prune out the non-data bits.

If your messages are STILL too large, use a compression algorithm. For TCP you can use a stream-based general purpose compression algorithm, for UDP you'll unfortunately need to compress each packet individually. Stream-based may require take more data to go through but can give better overall results. Message-based compression is hard because the algorithms only have a few bytes to encode, and hopefully they are high-entropy due to the encoding already mentioned so the compressor will struggle to improve it.

PARTNERS