Hey,

I need to integrate server reconciliation in a multiplayer platformer game. I have found some links about it, but didn't really get it. In my game, client sends one of these movement requests to the server: ACTION_MOVE_LEFT, ACTION_MOVE_RIGHT, ACTION_MOVE_STOP. And server sends an update packet every 1/20 sec with players positions and velocities. Currently, when I start moving, because of prediction, character starts moving instantly, then server sends an update packet, character snaps back to previous position and start moving then. So I found reconciliation is an answer.

How could I implement it? Should I attach a current movement state variable in an update packet and ignore position updates until it matches with the last sent one?

Currently, when I start moving, because of prediction, character starts moving instantly, then server sends an update packet, character snaps back to previous position and start moving then.

First, the server and client need a synchronized clock representing in-game time. The client needs to timestamp the input message with the game-time when the button was pressed. When the server receives this input, it needs to apply it at that particular time in the simulation (which may require rewinding the game-state). When the server sends updated game-states to the clients, these must also be timestamped. When the client then receives updates from the server, these updates should be put into a buffer that's keyed by timestamp. The client can then use this buffer of known states to estimate a movement curve from multiple timestamp+position pairs (and/or it's own predictions).

If done correctly, no reconciliation is required, as the server and client will exactly agree on the state of the world. In the case of packet loss, or mis-predictions due to the actions of other players, you've got all the data that you need to smoothly "snap" the client to the correct position.

@Hodgman, seems quite messy and would kinda break a few things, so I don't think I can really use it. Also, "my player" would not look so great for "other players".

@Ashaman73, this seems quite an attractive solution. What could be other downsides apart from possible cheating? What should be max ping for it to work properly? Will "my player" look good for "other players"?

Any other solutions or ideas to consider?

The input stack / rewind is what's commonly used for server / client interactions and corrections.

You 'can' not do that, and have the client being directly in charge of his character, and the server occasionally correcting the client when the client becomes way out of line (mostly logic, like elevators, doors being opened / not opened). These type of interactions might have a higher level of 'glitchiness', because there is not one singular authority in charge of the game state, so you'll get competing interactions.

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

That's the generally accepted method of client / server input control, where you can perform input prediction on clients, and lag compensation on server (mainly for hit scan detection). THis ensures that the server is the only singular authority in the game, thus keeping a consistent game state, while clients remain responsive (unaffected by lag, up to a point).

Players can still cheat, but that's mainly things like timestamp tampering, input cheats (mouse X / Y orientations for aimbots), or unrelated like wallhacks.

I'm also with Hodgman on this one. It can make the game seem jumpy for people who have bad connections, but it provides the best security against cheating. 5-10 years ago I'd have given different advice, but most people who play online games have really good connections now.