Server reconciliation for multiplayer games

Question

Reading the usual resources on multiplayer games (1, 2, 3); I have started working on my own multiplayer game.

I used a naïve approach that for every input I receive from a client, I immediately run it on the server.

For simple units (soldiers) everything works well, however I have an issue with "always moving" units (such as jet fighters); They require queuing inputs on the server (small delay, less than 100ms) and performing them in delay - and I read elsewhere (1, 2) that you should allow a window to receive inputs longer than said delay, since latency is variable (and could easily reach over 100ms) and reconcile the player's input.

Now I understand how this works for simple input such as movement, but what about using weapons / more advanced input?

What happens if player input comes with a delay, where he wishes to fire his weapon - what do I do? When do I notify other players of the shot? What about it's result? What if my cool-downs are out of sync due to this reconciliation?

Thanks.

Answer 1

"I used a naive approach that for every input I receive from a client, I immediately run it on the server." Sounds like you are sending the input to the server. This can be great for an anticheat system, but is not well suited for controlling units. I've seen many MMO and RTS games that send the target destination for a selected unit, and then the server handles the rest -- and this works quite well. I'm guessing this game your making is an RTS game, so just send a units destination once.

If your going for no network latency in interface, you can predict what the server will do, then get a confirmation from the server later. IE, send unit 3 to destination X. Client generates and draws a path of motion and starts drawing movement. Server sends actual path later and confirms movement of time, taking precedence.

Answer 2

Your 3rd link answers your question:

This screenshot was taken on a listen server with 200 milliseconds of lag (using net_fakelag), right after the server confirmed the hit. The red hitbox shows the target position on the client where it was 100ms + interp period ago. Since then, the target continued to move to the left while the user command was travelling to the server. After the user command arrived, the server restored the target position (blue hitbox) based on the estimated command execution time. The server traces the shot and confirms the hit (the client sees blood effects).

 

To address your specific questions (based on the method Source Engine decided to use above):

What happens if player input came in delay, where he wishes to fire his weapon what do I do?

When the server receives the delayed player input, it calculates where the target was at the time of input.

When do I notify other players of the shot?

As soon as the server receives the delayed input.

What about it's result?

The target is hit. The Source Multiplayer Networking docs goes on to admit this might result in some weird "paradoxes." But it seems like the fairest method.

Network latencies and lag compensation can create paradoxes that seem illogical compared to the real world. For example, you can be hit by an attacker you can't even see anymore because you already took cover. What happened is that the server moved your player hitboxes back in time, where you were still exposed to your attacker. This inconsistency problem can't be solved in general because of the relatively slow packet speeds. In the real world, you don't notice this problem because light (the packets) travels so fast and you and everybody around you sees the same world as it is right now.