3
\$\begingroup\$

Imagine the following scene: The height one player can reach on jumping depends on how much time the button for jumping is pressed. When the player jumps, the input is sent to the server and physics are updated.

Now, imagine that for some reason, one input packet is lost or due to lag it begins to arrive late. From the point of view of server, the player is not jumping anymore, and its character will start its fall. Every other client will receive this information and let the character fall. Then, a new packet arrives that corrects this problem. From the perspective of the player, the character is still jumping. Maybe, thanks to this extra input the character can reach a higher slope. But from the point of view of the server and rest of clients, it wont make it.

This could happen, but online games that i have played (except for long jumps and high lag) it doesnt happen. My question then is: How does the server handle this situation? It cannot wait forever for input, it must update physics and acknowledge other clients on what's going on.

\$\endgroup\$

1 Answer 1

3
\$\begingroup\$

For this to be handled correctly you need to design your network protocol to do something called "continuous transitions". Client send's all time packages to the server with a order. This way the server has always the last state of the client, regardless of lag or lost packages.

Next step is you need to analyze the packages arrived.

Back to your jump example.

The user presses the jump button, and the client sends the following packages:

NKP = No Key Pressed JKP = Jump Key Pressed

[NKP] -> [JKP] -> [JKP] -> [JKP] -> [JKP] -> [JKP] -> [NKP] ...

Each package has a order.

So the server receives JKP and start's to update physics. Now the server doesn't receive packages of the client for any time.

Now u have 2 possibilities

  • Sign the client as Disconnected
  • Predict something

Most games are designed, that they predict something for a short period of time. So in our case, the server hasn't received the NKP package, so he predicts, the user is still jumping. This will happen for let's say 100ms. After that the server predicts that the user falls back to a default which in our case would be NKP.

After some time, the server receives again packages of the client. Corresponding to the correct order, he now knows the correct state of the last package of the Client send.

In our case still JKP. Now the server looks in his list and has 2 options:

  • Am I still predicting? Then correct to the state of the Client
  • Am I fallen back to default? Then correct the Client to the state of the Server

In the first case, what is happening, is exactly what people hate, when a lagging person enters any shooter game, that uses this prediction behavior. They start teleporting short distances.

In the other case, what is happening, is exactly what people see, when they cry for lagging server, because their characters start to flicker or teleport back.

You need to find the best prediction timings for your game design.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks for your answer. So, if i understand correctly, i can "teleport" on server if new state received is not equals to client and tell other clients this change, or tell this client that server has other plans and correct this player. Now, with this approach i have a question: Wouldn't both of them be too noticable for clients? Due to lag, no player would be able to play if it misses the "deadline". Shouldn't server be tolerant to some point? \$\endgroup\$ Commented Nov 4, 2015 at 17:06
  • \$\begingroup\$ The tolerance is defined with the mentioned prediction timings. At some point u will have to mark the client as disconnected. \$\endgroup\$ Commented Nov 5, 2015 at 18:58

You must log in to answer this question.

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