Sorry your browser is not supported!

So this might be a pretty broad subject as there's probably more than one network data optimization practice I'm not aware of.

First of all I have a game that can host up to 16 players (server being one of them). The only thing that the Client sends is the X, Y and Z position of it's player object. BUT that client is also supposed to receive a data package containing the X, Y and Z positions of All other players that the host assembles and sends back.

So
1. I only gave the client send the position data IF the position has changed.
2. ?

What else have I not thought of?
The key is to lower latency.

Oh and another thing. For some reason when I send the Float value of the player object x, y z, it's getting received by the host, where IT applies those values to a dummy player 2 object, the movement is very steppy, almost like it's not receiving floats but integers. I checked both Add Message and Read Message functions. both match the sequence (since the position is read correctly) and when I print the values received, they are indeed in floats.

more likely to be the delay between receiving the updates.
not sure you can do much as there really isn't that much being sent anyway but you could try sending the data in bytes instead of float - no idea if it would make a difference though.
i would suggest making the host do some momentum maths (work out the general direction the player is travelling and if he's speeding up/slowing down etc based on previous data) in between updates so that the movement is more fluid and not only updating when a packet is received (if that is not already the case)... then when you overwrite this data with the received data it should look much more natural.

I'm not a specialist in networking and I'm sure here are many programmer who can correct me if i'm wrong...but I will tell you what I think of it...
Maybe a bit picky but when I hear "latency", I think of the time a package needs to travel from the client over the server to another client and this depends on the physical attributes of the network, so you can't change that.
But what you can do, is to balance between the size of the packages or the amount of packages needed, and the quality of the player experience.
If you send a lot of large packages you will fill up the memory faster than the packages are send or received.
Now there is something called prediction and lag compensation.
Prediction is what smallg tried to explain because you don't want the client to decide if he can go forward (for example) because then you make it easy to cheat.
You want the server to decide if the client is able to move forward and make plausibility checks on the inputs received.
But if you send so many packages so it doesn't feel lagy for the player you would flood the server with packages again.
So the solution is to send less packages but to predict the players movement on the client side and on the server side, interpolate between the packages and if they differ from each other you correct the client.
I have to say that I never implemented the whole system, I only made it so the server decides the movement and the client interpolates the movements between the packages which was pretty good because I had not much to send and therefore had a higher frequency.

If you use the message commands, the smallest amount of data that you can add to your package is 4 bytes, so player_ID + X + Y + Z is 16 bytes (with integers anyway). If you use socket commands, the smallest amount you can add is a byte. Depending on how big your playfield is, you can do some tricks that minimize the amount of data needed to be sent. I have a playfield that is 1280x720, I divide that playfield into quadrants. Starting from top left, the first quadrant is X 1 to 256 and Y 1 to 256, the next quadrant is X 257 to 512 and Y 1 to 256, I continue like this to the bottom right corner of the playfield. You can the have 256 quadrants (or more, but then you need to send more data). My playfield is 2D, your seems to be 3D, so you need a second quadrant byte to be sent, the Y position of the quadrant, 256 X quadrants, and 256 Y heights of X quadrants. You X planes can be 16 x 16 quadrants (or any other dimensions that is less than or adds up to 256), then there can be up to 256 of these planes (the Y quadrants, the "height" of the X quadrant that the players are in). Now, you have sent which quadrant the player is in, then you can specify what X, Y and Z position the player has in one of these quadrants. (X = 1 to 256, Y = 1 to 256 and Z = 1 to 256). Do notice that when you add a byte to a socket, the range is -128 to 127, so you need to modify your data to fit this range when you send, and then convert it back at receivers end.

A socket message could look like this:

AddSocketByte(socket_ID,player_ID)
AddSocketByte(socket_ID,X_quadrant)
AddSocketByte(socket_ID,Y_quadrant)
AddSocketByte(socket_ID,X_in_quadrant)
AddSocketByte(socket_ID,Y_in_quadrant)
AddSocketByte(socket_ID,Z_in_quadrant)

This requires only 6 bytes of data to be added to the network data.

If this rambling doesn't make sense, I can draw some models that explain this better. I have reduced network lag with this method.

Alright so:

The issue with Client dummy object in the host application moving with integer increments was solved. The temp variable I was using to store the floats were actually integers so fml.
Second, I have rounded the floats of the objects positions that are being sent out to the nearest 2 decimals. The return X, Y and Z position floats were returning values like 204.0346343 which I neither to use, nor do I need to send a position update packet every time it changes a thousands of a decimal value.

This has pretty much solved my delays between client movement and server updating the position

Before:


After:

@ Cybermind

I like you quadrant idea.

I had an idea of combining data for sending, then disassembling it once received.

Haven't yet played with the multiplayer/networking stuff yet, but I will definitely keep your map quadrant using sockets idea in mind.


lol Life is good man.

That was a simple oversight with an easy solution.

Glad you figured it out.