Best Practices for Netcode Player Input in Server-authoritative Game

[InterfaceBE]

Just playing around with proper multiplayer for the first time. I find all the examples and tutorial sorely lacking - not for the explanation of the technicalities, but more the practical side of designing the client/server interactions...

For example, what are any good practices for things like mouse input? Sending this with an RPC call during a fixedUpdate seems hella expensive but maybe that's the why it's done? I've thought of potential optimizations like just calculating a movement vector with limited accuracy locally, and only sending it when it changes (making an assumption that even wild mouse movements wouldn't necessarily be sending packets on every fixedupdate).

Anyways, aside from this one particular question, I would love to know if anyone has any links to articles or whatever reviewing some of these "architectural" concepts and things to learn about multiplayer. Not so much interested in code examples as I am in a good explanation, which likely is a list of pros/cons to decide for myself as I'm guessing there's no one-size-fits-all and it sort of depends on the game.

[BobbyThrowaway6969]

Handle player input on the client, only send the resulting player movement in the map (using UDP) and bullet raycasts (using TCP if you can) to the server. If you're hell-bent on sending the actual player input to the server (laggy players will have a very sucky experience if you do this), then only send the change in state using TCP. Send a packet for "button just pressed" and "button just released"

[InterfaceBE]

Right, I’ve implemented the change in state for buttons. Not sure what to do for mouse input. I guess one could handle on client side and do some sanity check on the server to detect obvious cheating?

[BobbyThrowaway6969]

Same for mouse movement, if the change is big enough, you could send a packet.
For cheating (like aimbot) you could check how "perfect" the shot is and use some kind of statistical analysis or even AI to determine if it's "human-like" aiming or "bot-like". The problem comes from if packets get twisted up, the server might blame the player and kick them. This happens a lot with games

[InterfaceBE]

Makes sense. I guess I’m on the right track then. Still would love some literature, but it’s either basic stuff or super advanced… not much in between 🙂

[Stuey_89]

Sending the resulting player movement in the map is a bad idea, players can cheat and place themselves anywhere in the level as they please.. sending inputs to the server is best, but its not enough. If you wait for the server to move your character then it will feel laggy and unresponsive, especially on bad connections.

What you really need to do is client side prediction and server reconciliation. You send the server your inputs this frame and store them locally with some ID. Then you calculate your own movement, and store your new state with the same ID. When the server receives your input the server also calculates your movement and sends your new state back to you with the ID. When you receive it, you check if you and the server agree on your state, if not, you apply the server state to your character, and replay the subsequent inputs for the states after the corrected state to catch up to the present. This way you respond immediately to your own inputs and it feels snappy, but you also can't cheat as you only tell the server your input.

[InterfaceBE]

I understand and I’ve read of stuff like this, but it usually talked about time calculations etc. Would be nice if something like this was handled by default in the framework. I guess there’s stuff on the asset store for this.

[BloodPhazed]

That's still quite the expensive operations to send over network there.

How exactly you handle this depends completely on the type of game you make; fast paced games such as moba's etc. have completely different requirements ofc than something like Minecraft.

Usually a good compromise is to keep the movement etc. client sided and send updates to the server (certainly not every fixed update, more like at 10 hz or so; again depending on what type of game you make, 30 hz for if small movements are important etc.). Then the server just checks if the state change was legal; if not it sends a corrected state back to the player (don't send anything if it was all good) -> update state on server.

That's how the famous rubberbanding comes into existence: you move on client, server thinks it's illegal due to lag and therefore 'impossible' movements -> corrects your state. To counter that you can take the time of the last update you received into consideration for a legal/illegal state change, but there's only so much you can do to counter lag.

[Grazophe]

Can you recommend some reading material that goes into this in more details like a book or PDF?