2
\$\begingroup\$

Assume that we have a multiplayer game and the users are moving their characters (might be a circle) on the game area. At every game loop some changes can be happened. Should clients send their changes at every game loop to the server ? What would be best practice to comunicate clients each others by avoding overloading server?

Note: I'm asking this question for mostly HTML5 multiplayer games and will be using Box2D.

Improve this question
\$\endgroup\$
3
\$\begingroup\$

I'm far from an expert but I've been working on an HTML5 version of Pong that uses Websockets for multiplayer so I can share what's been working for me. The general maxim I've been living by is: 

"Send the minimal amount of information necessary as infrequently as possible."

In my case I maintain the state of the keyboard by listening for the keyup and keydown events in the client. When one of these events is fired the client sends a message to the server and then updates its own state. This allows the client to employ client-side prediction (see this article for more details) and gives the server the minimal amount of information it needs to execute the move.

When the server receives one of these events it updates its own internal state and then rebroadcasts the event to all other clients so they can handle it as well.

To keep everything in sync the server will periodically (every 10 ticks of the engine in my case) send a "sync state" message to all of the clients giving them the exact positions of all players. You never want to sync the state of a client to the server as that opens up all sorts of cheating opportunities.

EDIT

To be clear, state syncing should only ever go from the server to the client, never the other way around.

END EDIT

I found Maple.js to be quite useful as a reference for a concrete implementation in Javascript.

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ I believe you meant "never sync the server to the client", although I don't want to just make that edit in case I misunderstood you. \$\endgroup\$ – jhocking Jan 19 '14 at 13:27
  • \$\begingroup\$ @jhocking I think you misunderstood him. He says "the server will .... send a "sync state" message to all of the clients", and that is correct. You only want to send movement events to the server, not the player position, because the server will then run the same logic for everyone, so it will effectively limit the type of client side cheating. When the server syncs to the client, it sends the correct positions, not the possibly cheated ones. \$\endgroup\$ – Pip Jan 19 '14 at 13:55
  • \$\begingroup\$ hm perhaps what I'm misunderstanding here is the directionality of the expression "sync A to B". To me, that would mean making the state of A match the state of B, whereas it sounds like you mean the other way around. \$\endgroup\$ – jhocking Jan 19 '14 at 13:58
  • \$\begingroup\$ @jhocking Is this the sentence you are referring to: "You never want to sync the state of a client to the server as that opens up all sorts of cheating opportunities." Based on the comments I think we're all thinking the same things, but my original statement is not clearly worded. I've editing my answer to clarify this point. \$\endgroup\$ – NoobsArePeople2 Jan 19 '14 at 20:20
  • \$\begingroup\$ looks good to me, at this point \$\endgroup\$ – Pip Jan 19 '14 at 20:24
1
\$\begingroup\$

There is usually no good reason for the clients to send their positions at every game loop, because in most situations their positions will either not change at all or change in a very predictable way (because they are moving with a constant speed in a constant direction).

To avoid a storm of lots of redundant network packages, you should just report changes in movement.

Also keep in mind that all game mechanics should happen on the server. When a client says that it moves towards point x:y, the server should treat this as a request to do so, and only relay it to the other clients when its actually able to do it according to the game mechanics. When you don't do this, players will be easily able to cheat.

Improve this answer
\$\endgroup\$
1
\$\begingroup\$

What happens generally is that clients send their timestamped inputs to the server, then the server uses them to compute a new "world state", and sends it back to the clients.

That's it in a nutshell, but the devil is in the details. And there are tons of details :) I've written extensively about the topic, details and all, here: http://gabrielgambetta.com/fast_paced_multiplayer.html

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

I'm not an expert but i thought that the best practice is send the player input from the client side only when change (for example if the player is moving to left, not send infinite packages with 'left', only when starts or stop moving), and do all the game mechanics in the servers-side.

Improve this answer
\$\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.