1
\$\begingroup\$

I'm creating a networked game and I have a huge problem understanding how to keep everything in sync. Right now I have a server and a client and the client can log in and move a character around using the keyboard arrows.

When a arrow key is hit I send data to the server, that then sends that data out to all the clients and then it moves the appropriate character in a specific direction.

However if I keep on hitting arrow keys eventually the result on two different clients will look different and they fall out of sync. So what is the best way to stop this from happening?

I've read that 1 method is to send data back and forth to figure out the latency between each client and then to include that into the movement, is that really the best method around at dealing with this? In which case would anyone be kind enough to explain in more detail how that works exactly?

Thanks

\$\endgroup\$

2 Answers 2

1
\$\begingroup\$

The simple answer is that you should not send key input, but rather their absolute position. This will make sure that the entities are always the exact same place on both your own client, other clients and the server.

To get smooth movement, you might want to consider adding additional client code that smooths it. A technique could be: If your game syncs every 50 ms(20 times a second), and the player moved 1 meter, estimate how much it should move, so that it's at the position at next sync. Heres a picture to describe it: enter image description here

Ps. This a technique I just made up, so theres probably other techniques that will give you even smoother movement, but this is pretty easy to implement.

\$\endgroup\$
2
  • \$\begingroup\$ Ah, right, yeah I get it now with this + some more reading. What's the best way to match the time up though? Would you syncronize clocks and send a timestamp along with each piece of data and compare the two? Or would it be better to calculate how long it takes to send data to each client and just go back in time that much when new data arrives? \$\endgroup\$ Commented Jul 18, 2015 at 22:42
  • \$\begingroup\$ If you're dealing with low latencies, it doesn't really matter - the server updates its internal state at a given frequency (aka tick rate) and the clients each get the latest possible version. If latency is an issue or accuracy is crucial, there are more advanced techniques to predict/smooth movement. This usually involves the server accepting out of date actions from a client and running a "what if.." simulation, then updating current state as appropriate. This is why sometimes in an FPS you can skip backwards slightly when shot. The server didn't know you were dead until a few frames later. \$\endgroup\$
    – Basic
    Commented Nov 16, 2015 at 21:52
1
\$\begingroup\$

Your goal is to have a stable game state across all clients and server. There are many ways to approach this, I will suggest one.

Let us consider a simple case, the position of a single object. Suppose we have 2 clients and 1 server.

Let the server hold the last position each client reported for the object. When the server receives a position update from client 1 it updates the value it has for the object reported by client 1 and then it sends a correction back to client 1 based on the difference from the average of client 1 and client 2. I think this should always converge, but no proof provided. This is a running average play. Recalculation each update isn't cheap but it should result in smoother movement as opposed to giant leaps the next method creates.

In this method the server is an arbiter ensuring that all client have the same state. Let the server retain 1 value for the objects position. The server then updates it's game state and notifies other clients. Periodically the server will request a hash each clients game state to ensure each client has the correct state.

Suppose client 2 has a much slower connection than client 1. Client 1 moves the object left 100m and client 2 moves it right 100m. Client 1 see's the object move left then move right as client 2's changes are applied. Client 2 might not even see the ball move at all as it receives the sum of both changes because it's initial game state is out of sync with the server.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .