Hello!

I am searching for some suggestions how to improve the multiplayer communication in my game. Currently, it is done in the following way:

- I create a server game and other players can connect to it using the ip and the port

- They send information about their player and the server receives it

- Then the server sends the information to every other player

The commands are of the following way:

update player Radev 0.0 0.0 100 100 5000 5000 0.0

rotate player Radev -0.4332702160639106

shoot player Radev 0.0001 0.77878

Do you think I should try to encode it in some way or just make the commands shorter like:

upRadev 0.0 0.0 100 100 5000 5000 0.0

rpRadev -0.4332702160639106

spRadev 0.0001 0.77878

However this does not make the commands a lot shorter in any case.

Any ideas?

I use Java for my game.

I made the strings shorter by making the commands to be only by one character and accordingly the numbers to lose their precision.

Now, the commands are of the type:

rp yuyuyu -0.07 where yuyuyu is the name of the player

Before that the command was:

rotate player yuyuyu -0.4332702160639106

Since there aren't a lot of commands I think, maybe I can combine rp and -0.07 in a bit representation to save space.

I think I could help you better if you explain a bit what are you doing and how are you/do you want to do it. Answering those questions would be useful:

1. What kind of game are you working on and what amount of data do you need to send?
2. Is your game client also in Java?
3. What classes/libraries are you using for network communication?
4. How do you transmit the information through network? Are you using a library that allows you to send it as String, do you call String.getBytes and send it as a byte array...?
5. Is there any reason why aren't you using Serializable objects and alike?

If you are really sending the string "rp SomeAwesomeNick -0.07", well... the string "SomeAwesomeNick" is 13 bytes length. And the string "-0.07" is 5 bytes length. Using an int type for the player (relating each player name to an integer id) and a float type for the angle would save you 9 bytes for the player and one byte for the angle. And you could even use shorter types. If I wanted to serialize it manually, I could build a byte array with the first byte identifying the command, the next four bytes for the integer id and the last four bytes for the float angle. In nine bytes I'd had the command, the player and the angle with a lot more precision than the string way. Hey, if I'm sure I'll never have more than 256 players and 256 directions are enough for me, I even could do it in three bytes. My point is use objects, not strings, and serialize to byte arrays.

Without any further clarification I find difficult to provide some useful advice, but in case you are just trying to figure out how to do it, I'll explain how I would do it.

If your client is also Java, then using plain ol' Serializable objects saves a lot of headaches, and if you are using sockets or something alike, it requires you to send the data as a byte array anyways. I would have a class implementing java.io.Serializable for each command you need, and just serialize it to a byte array and send it through the socket. For instance:

public class RotatePlayer implements Serializable {
	
	private static final long serialVersionUID = -171890897880063974L;

	long playerId;
	
	double angle;
}

Repeat for each command and that's all you need to worry for. You can save some bits by changing the types to a shorter ones, if that worries you. Even you could use 'byte' for angle and transform it to degrees before and after transmission, for many cases I would find 256 possible directions to be enough.

Yeah, sure, you can save some bytes by implementing your own serialization system (*), but is really worth it?

More on serializing/deserializing: http://stackoverflow.com/questions/2836646/java-serializable-object-to-byte-array

(*) Of course, Serializable objects add some amount of data because Java needs to know how to deserialize the object later. I tested the class above and serialized is 73 bytes lenght, which is like 57 bytes more than the data I really want to send, but in most cases the tradeoff pays for its ease to use. If that amount is too much, I would implement my own serializing system, but I would send bytes, not strings, and I would have one class for each command. You could have the first one or two bytes (depending on the amount of classes you need to serialize) for identifying the class and then provide a constructor that with the rest of bytes could build the object. You'll probably need to do that way also if your client is not writen in Java.

Thank you. What I wanted was to make the commands shorter. I believe I will use your approaches. The problem was with the latency since the current commands were too long.