1
\$\begingroup\$

So I've just started trying to make a multiplayer pong game and I have read a lot of different ways to code the connections. However, I read somewhere that you should have the inputs sent to the server queue up and then the server just processes it at fixed intervals. However, if this is done, how does the server know, process, and send accurate data based on the time the action was sent? Because if the data is just queued up, if something happens like 100 ms after another but the server processes them at the same time, wouldn't that mess up the synchronization of the game? Should the server instead be coded to handle the client actions immediately even if it costs a lot of cpu etc in larger games?

\$\endgroup\$
  • \$\begingroup\$ why the down vote? \$\endgroup\$ – J leong Mar 9 '16 at 18:09
  • \$\begingroup\$ Not the downvoter, but the questions is very close to several OT areas - "how to get started", "too broad" and "opinion based". Answers will largely depend on the kind of game (which you did not provide, making it even broader). \$\endgroup\$ – Kromster Mar 9 '16 at 19:49
  • \$\begingroup\$ @KromStern I said i was trying to code pong \$\endgroup\$ – J leong Mar 9 '16 at 21:07
1
\$\begingroup\$

You don't need to process a packet immediately to know timing information. Just record the timestamp when a message is received, along with current latency measurements/estimations.

When you do eventually process the message you then know when the message originated. With the latency measurements, you can even estimate when the user initiated the action, e.g. if the server takes 50ms to process a packet and the network has 70ms of latency, you can estimate that the user pressed the key 120ms in the past.

This information can then be used by the server to alter its simulation. With pong, for instance, you can both set the paddle's velocity and teleport the paddle a little bit to account for the time difference. You can even rewind the pong ball and replay its collisions with the paddle after said adjustments, so the player is less likely to just barely miss the ball.

The client can do the same sort of time adjustment. It has an estimated latency to the server as well, and also can have estimated latency for the opponent. Using this information, the client can adjust the visual locations of the opponent or the pong ball. For instance, if the server sends an update on the ball position and direction, the client can extrapolate the ball's position using the estimated server latency.

Do be careful with doing both server and client time correction. It's hard to wrap your head around mathematically (it took me a while, anyway) and it's very easy to think you understand it when you really don't. Doing time correction on both server and client will exasperate any problems stemming from misunderstandings. I'd probably start with client extrapolation and build up from there, if you even need to.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ oh ok thanks! I have like the most basic understanding of what is supposed to be happening but then when I go to implement it I just got confused. is it better to interpolate the second paddle and extrapolate the ball? \$\endgroup\$ – J leong Mar 9 '16 at 23:21
  • \$\begingroup\$ sorry i just thought of another thing when I was working on it, if i were to make my game time dependent, what kind of packet would I send to the server? What i mean is do I send the delta time along with the speed of the paddle so the server calculates position based on the delta time instead of the amount it moves per frame? Actually that doesn't really sound like a good idea... How would I make it time dependent because all I can think about is how to make it frame dependent because by sending the server dt, it is basically making the client authoritative. \$\endgroup\$ – J leong Mar 10 '16 at 0:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.