Both are 32 bits, unless there is something you are not telling us.
- Use integers instead of floats. I don't generally need the precision for x,y movement coords.
How is that smaller?
- Send local grid coordinates not world coordinates.
Why base 62? Your goal is to reduce the number of bits sent, that would increase the number.
- base 62 encoding of string id's
- don't send data if it hasn't changed since last update
- 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.
Only two of those items above actually reduces the number of bits. Do more things that reduce the number of bits.
If anyone has ideas on best compression algorithms, or other tricks to keep bandwidth usage down, let me know!
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.