0
\$\begingroup\$

I'm creating a multiplayer platformer game with 4 players in multiple rooms. I've read a lot of articles and researched about client prediction and lag compensations. I think I can somehow manage to understand how to update "my client". But what would be the best approach in the multiplayer platformer game to update "other clients". This is what I'm thinking:

Approach 1: the client sends input "left" to the server -> server increases the velocity of the player -> the server sends the actual input "left" of this client to all other clients -> other clients run the physics on the input.

Apporach 2: the client sends the input to the server -> server adds velocity, update state -> game loop in server updates the position of every single client back to everyone, sends it to all clients -> client gets it and updates.

What would be a better approach? or please if there is a better approach, tell me I am very stuck..

\$\endgroup\$
  • \$\begingroup\$ What issue do you have with these approaches? What do you want to achieve and what do you want to avoid? "The best XXX" doesn't mean a thing when there are no criteria. \$\endgroup\$ – Vaillancourt Dec 24 '17 at 0:43
  • \$\begingroup\$ With the approach 2, I'm sending out the position about 10 times per second. And it feels very choppy. I was just wondering if there is a "right" way to do it. But i guess there isnt. \$\endgroup\$ – Jason Dec 24 '17 at 2:12
2
\$\begingroup\$

Approach 1) is traditionally used in RTS types of games where timing is very important. However, this approach has the downside of increasing by a lot the chances of clients cheating. Since the client simulates the physics and everything else, it has to know the whole state to keep it in sync with other clients. In order to do that, it has to know of the whole state of your simulated world. A clever cheater could just sniff the current state of the memory and know everything there is to know and take advantage of it.

You did not mention it, and I think that's what you're missing: With approach 2), you can broadcast only what the client needs to know: limit that to a region of interest. If the screen covers only a 300 units diameter, there is absolutely no need to tell the player's client what's going on above this region of interest. This limits the amount of data the server needs to send to the client, and reduces the range of available cheats.

\$\endgroup\$
1
\$\begingroup\$

1 - Client send input.

2 - Server calculate and broadcast: destination, direction, velocity and timing function (if you need acceleration or jump curve).

3 - Unit start moving (on server and on clients with tiny lag difference).

Don't send anything until unit vector changed or user input comes.

\$\endgroup\$

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.