Informing clients of player actions in 2d platformer

Question

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.

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.