I'm creating an online game (2d platformer) and I'm having some trouble understanding what to send clients. I'm sampling each player's input and sending it to the server after a set amount of time. The input is then sent to other clients, while the position is sent to the local player (since that client is already aware of inputs).

This is all fine. However, everything I have read about online games has said to only send the position of the player. How do I inform clients about the actions the player took?

For example, if player A uses a dash skill, I need to render that on client B, and accelerate the player at that time. I could send client B data about the position and physics state before and after the skill was used, as well as the name of the skill, but isn't that overkill? It seems easier to me to simply send input data. Something like this: [{key: right, time: 5}, {key: dash}].

One problem with this though is if I'm sending the data using UDP, client B will not render the player's skill if the packet is lost, unless I send the information until client B has inform the server it has been seen, but surely that defeats the purpose? Should I be using TCP for crucial information such as player abilities?

And if sending just position data, how does one deal with acceleration? Wouldn't I have to send the physics state of the player as well? Do other games do this, or do they just interpolate positions instead of calculating the momentum of other entities?

I'm not sure if I'm missing something but if someone could help me understand how I need to go about updating clients I would really appreciate it.

  • \$\begingroup\$ "This is all fine." Then it sounds like there's no problem to solve here. "However, everything I have read about online games has said to only send the position of the player." That's a gap in your reading, not a problem with your code. "surely that defeats the purpose?" Why would it? Lots of games do exactly this, as you can find covered in past Q&A here and popular game networking guides like Glenn Fiedler's. \$\endgroup\$
    – DMGregory
    Commented May 30, 2022 at 11:00
  • \$\begingroup\$ Thanks, I was hoping my solution wasn't inefficient. I suppose I'll find out when I'm dealing with a lot of events being handled at the same time. \$\endgroup\$
    – Kaeru
    Commented May 30, 2022 at 15:17

1 Answer 1


I have an interest but limited experience with the development of online / networked games primarily in C but also in Python. I don't know what "everyone else" does.

I would stick with UDP to keep the network overhead down, especially if it's online. You should craft your communications between the client and the server in such a way that it won't matter if a packet gets lost. Don't mix UDP and TCP channels for communications between the clients and the server.

I wouldn't send each player's inputs to the other clients. Let the clients manage their own states. A client probably does not need to know that another client is using "dash", just that the other player is moving much more quickly. Have the clients fully process their own inputs, update their own location, direction, and speed, and send that to the server; then have the server send that already-processed information to the other clients. It's okay if the packet gets lost because the next one will update with the latest position, direction, and speed information. You'll have to decide if you want the information for every player sent to every client, or if you want to sent only the information for the other players who are within display distance of the client.

It's not generally necessary for other clients to know what skill you're using at any particular time, merely the results of using that skill: faster movement, higher jump, etc. What you should send is information about how the character should be displayed: health bar, shielded, magic aura, hunger bar, etc. Yes, you may need to send the client's physics state, I suppose, but I think that the physics state should be sent in absolute terms rather than relative terms, but I still think it would be better if you could encode that information in terms of position, direction, and speed.

The topic of "persistence" does change the relationship between server and client quite a bit, but doing things this way has helped my own designs.

  • 1
    \$\begingroup\$ Thanks a lot, this is quite helpful. I'm set on using UDP now with a custom layer for crucial information. Instead of sending inputs I'll send states for things that need to be rendered (such as the shield/hunger bar you mentioned) and try to handle the rest through interpolation since this seems like a much tidier approach. By persistence do you mean the ability to predict future player states/inputs? State changes will be easy to predict but inputs will not. \$\endgroup\$
    – Kaeru
    Commented May 31, 2022 at 20:07
  • \$\begingroup\$ By "persistence" in this context I mean that the game maintains a presence for the player even after the player's client has disconnected. In that case the server would have to manage at least part of the player's state on his behalf: what to do if attacked by another player, for example. In the old BBS door game "Tradewars 2002", when you ran out of turns you may park your ship in a fairly empty sector until the next day. Other players logging in later may see your ship just sitting in space and could interact with your it while you were offline, including attack it, etc. \$\endgroup\$
    – Ian Moote
    Commented Jun 2, 2022 at 1:05

You must log in to answer this question.

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