i'm working an a very simple multiplayer experience (for now node.js, later will probably remake all in c++, but my question is more about theory).

All guides and tutorial i saw about making something multiplayer Always speak about sending all the "world" information, once per tick, deciding optimal tickrate, making smooth movements on client side with interpolation or stuff like that.

Honestly i thought of another way, and i really cant see why its never mentioned. My idea would be the following:

  • Client sends to server when input happens; eg if you move with arrows, you send to the server a message only when your moving status changed. If you was moving right and then start moving upright, then you send a message about you changing your movement.
  • Server recives the messages, sets variable on player object for its movement, and sends to all other clients information about the change. Also sends current time and current position in the server at the moment of movement change.
  • Clients recive a movement status update, place the player object in recived coordinates moved by the new movement * ping delay. That way position in all clients should Always be up to date with the server.

Why should i send hundreds of positions to each client per each player every x milliseconds when i can just send the changes?

I feel like its about polling vs interrupt... (yeah i know its not polling anyway, but the concept is sending the change vs keep sending everything)

  • \$\begingroup\$ Just to make sure, in your question, you propose to have the server simply used as an input broadcaster, is that it? \$\endgroup\$
    – Vaillancourt
    Commented May 17, 2018 at 0:55
  • \$\begingroup\$ more like a "changes broadcaster". It would send also when a projectile hits something for example. @AlexandreVaillancourt \$\endgroup\$
    – Barnack
    Commented May 17, 2018 at 1:16

1 Answer 1


I am leaving my answer for posterity, but it seems that I've failed to answer the user's question. The user seems to be looking for a justification that guides are sending updates about everything, not for the "correct" thing to do.

As indicated by others in the comments, the guides are doing the "dumb" thing because optimizations are generally saved for once you understand the code and the impact of these optimizations. F.E. Frustrum culling is learned after learning how to draw everything on the screen; even though 3/4ths or even 100% of your geometry will not actually be drawn on screen while you move your camera around.

Sending exacting information is actually not only inefficient, but generally bad. The more you correct the client when it is approximating the correct thing, the more you encounter stuttering or other issues that let the client know that some of their information is being dropped. In general you want the experience to be as seamless as possible so that the user feels in control and immersed in the game. Faking it and correcting things only when necessary is generally going to make it seem like they have an excellent connection even when they don't.

An example can be walking in an FPS. If you lose a couple frames worth of information when your connection drops you will notice that you move backwards 10 feet (or w/e.) If instead the server says "well.. they didn't tell me to stop moving, I'm going to keep moving them in this direction" then most of the time when packets are dropped your user will only get a jarring experience IF they are doing something at that exact moment that would alter their Character but instead the predictive model had them do something else. This is generally acceptable as regular lag (your gun didn't fire, you didn't aim correctly, you thought you rounded a corner but didn't, or some other such thing.)

Disclaimer: I haven't implemented this yet, so take it with a grain of salt

I believe this type of this is normally handled by sending "objectives" and not "constant updates." This is to say, if something is told to go to position X, the server is moving that unit towards position X and the client is doing that, but the server has the "truth." The client has an "approximation."

The client and server are running similar code, so in theory things will line up reasonably. Then you simply update things on the client when it matters. Did something fire? Put that projectile oriented correctly on the client. The client should do the right thing in general. Did smething die? Let the client know.

The client only needs an outline of what's changed to update itself and the Server should always have the truth; sending what little information needs to be sent to keep the client on track.

This not only abstracts your clients' ability to cause bad data on the server (as in, the server doesn't care at all about the client other than its inputs) but it also minimizes the data that needs to be sent to and fro.

Let the client estimate what is going on and only correct it as needed. Some things will be off due to dropped packets, lag, etc, in which case you should occasionally correct the client I imagine. Don't worry about giving the exact state of the server (very often.) I suggest looking at Path of Exile for a game that started off having desync issues and has become fairly reliable even on mediocre wifi connections. It looks smooth most of the time and feels pretty good, and I believe most of it is because it's not micromanaging what's happening, but instead it's approximating and correcting things as it goes.

  • \$\begingroup\$ what you describe is closer to what i described than it is to what tutorials and guides say though... \$\endgroup\$
    – Barnack
    Commented May 17, 2018 at 0:43
  • \$\begingroup\$ If that makes my answer unhelpful, help me understand why so I can potentially adjust it into a more helpful format. It sounded to me like you were updating everything and I'm suggesting that you only update the things that changed when they change. This should reduce the amount of information you're sending by an order of magnitude. I am quite sure something along these lines is how Path of Exile (among many other games) actually work. Note: an FPS is likely to be much more exacting, but still relies on a predictive model. This why you stutter step, miss accurate shots, etc. \$\endgroup\$
    – blurry
    Commented May 17, 2018 at 1:11
  • \$\begingroup\$ i'm actually looking for a reason TO update everything in range a fixed amount of times per second; since it seems inefficient to me but most guides do exactly that \$\endgroup\$
    – Barnack
    Commented May 17, 2018 at 1:14
  • 1
    \$\begingroup\$ Most guides are showing you the simple/blunt way, on the assumption that you'll apply the obvious efficiencies where needed once you've mastered the basics. \$\endgroup\$
    – DMGregory
    Commented May 17, 2018 at 2:39
  • \$\begingroup\$ @Barnack I've amended my answer. Apologies for the misunderstanding. It may have helpful information in it now, but if nothing else it clarifies my misunderstanding for future readers. (and that clarification may help you to get better answers.) \$\endgroup\$
    – blurry
    Commented May 17, 2018 at 2:52

You must log in to answer this question.

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