What kind of game is it?

You'll have to structure your game so it can handle not being in sync. Each entity will probably need a local state, last known "real" state and extrapolated current real state. When the local and the real state differs, you begin moving towards the extrapolated real state. You may not need to care about how an entity wound up in a specific place, all you need to care about is finding a way to get to that position within the game rules.

[edit]

Disclaimer: I have never written a game using this kind of synchronization. I'm writing an RTS with input command synchronization which comes with a completely different set of challenges. The above is just from the top of my head.

Thanks for your response.

I'm writing a 2D sidescroller multiplayer shooter game. To simplify things, like a Super Mario but with multiplayer and weapons.

I read your tips and I have some doubts: the first one is about extrapolation. Isn't it a bit "dangerous"? We're getting data from the "future", so I don't think it will be accurate enough. The second one is about data storing: what about the previous known snapshots from the server? Do they matter? Or only the last one?

How "dangerous" it is to extrapolate depends on the game. You _will_ end up in incorrect states and positions, but for most games this isn't a problem unless the difference is huge. For your game however, it might be slighly more problematic since I'm guessing it'll be prone to butterfly effects. It's really hard to sync those kinds of games.

A typical problem is when a player is on a platform running forward, intending to jump when he reaches the very end of that platform. If another client just extrapolates his position, it may have him of the platform falling down before receiving the jump information. If the game is very fast paced, you might get away with a "super jump" in the air or even teleporting when the states go to far appart. For a slower paced game, chances are bigger that you'll receive the information before the problem arises.

If you do entity extrapolation, you don't want to be triggering any sensors or running physics on those remote entities -- just display them extrapolated, and do basic collision checking so they don't go through walls on the screen. The real physics should ideally happen on the server, or if you're server-less and don't mind cheating, on the controlling client for each player.

If you do entity extrapolation, you don't want to be triggering any sensors or running physics on those remote entities -- just display them extrapolated, and do basic collision checking so they don't go through walls on the screen. The real physics should ideally happen on the server, or if you're server-less and don't mind cheating, on the controlling client for each player.

Sure, but I mean, wouldn't be safer to delay the rendering on the client and interpolate the received data between two packages?

Sure, but I mean, wouldn't be safer to delay the rendering on the client and interpolate the received data between two packages?

Yes, it would be safer, but now you are limiting the client responsiveness to the latency from the server. Depending on the type of game, this could result in unsatisfactory gameplay.

Yeah, imagine if you drop a packet. A player who keeps running would appear to stop for a split second and then continue. So it's not optimal.