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?

One thought. Instead of sending direction commands, send absolute positions (client is now at postion P there with velocity V). The server accepts this movement as long as it doesn't violate some rules/thresholds (moving too fast, ignoring barriers etc.). The same for the client, if the server sends his view, the client can ignore it as long as it is inside a valid range.

This way the client is the leading entity and the server trust in the client most of the time. The advantage is, that the client control is really fluently, the disadvantage is, that it is not 100% secure versus cheating (speed hack = move entity as far as possible, but still in threshold of server check).

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?

Hodgman's suggestion is actually how many, many, high-end games do networking. It's the "best trade-off" in most cases, with the caveat that you really do have to pay attention to how you present remote entities to local players.

Sending position/velocity updates from each player is simple, and might be an expedient way of getting things to "seem right" quickly if you have a game already built that wasn't built with multiplayer networking in mind from the ground up, but it will be more susceptible to cheating, and it will have more conflicts where different players will believe different things happened, and the job of the server to tie-break what actually happened will be harder.

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.

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.

Note though that this technique originated in the 56k modem era! :D
It delivers a fair and smooth experience in that era too.

http://www.gabrielgambetta.com/fpm2.html

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.

Note though that this technique originated in the 56k modem era!
It delivers a fair and smooth experience in that era too.

I was more speaking of wifi issues than actual bandwidth, actually. Overall wifi performance has improved dramatically in the last decade. I remember FPS games playing much better on my dad's ethernet-connected el-cheapo desktop than my gaming laptop with wifi, even when I was in the same room as the router, while less time-exact games (IE WoW) played much better on the laptop.