I would like to inform myself on how does CSP work with player to player collisions, the issue I'm facing is that in my game, all clients are rendered in the past, and, if a local player (with CSP) would collide with them, the collision would always be different than the one on the server, due to that time difference.

1. Local player moves 10 units
2. Other client gets in the way of local player
3. Local player doesn't see it yet, so it keeps moving
4. Server says: you should have collided with other player
5. Prediction mismatch and reconciliation

How do devs solve this? Thanks!

First: This is THE problem in networked real-time games.

Second: To make everything “perfect,” you need to be input synchronous, and delay displaying the outcome of local player actions until the server round-trip has happened. There's no other way.

Third: If that's not acceptable, then you need to fake it somehow.

• Extrapolating other clients is helpful, because as long as they run in a straight line, you will predict them perfectly
• Turning off player/player collisions will work pretty well in practice, unless physical meelee is a thing you plan for (but then, that generally doesn't work well in this situation)
• To hide the fact that a player might collide with another player locally, you can display the other player in a displaced position, where they “avoid” the local player when they get really close
• When you get a correction from the server (if you need player collisions,) then you can apply it over a small amount of time, like 200 ms, rather than immediately; this will impact the player experience less

There are other mechanisms you can use, too, depending on the specifics of your particular gameplay. Good articles include the “source multiplayer networking article”, the “ggpo networking article”, and the “1500 archers article". (Just web search those titles, you'll find them.)

@hplus0603 Point number 4 is interesting….

I don't know if you have played Minecraft but there the collisions are not solid and sharp is more of a “pushing away” the player over several frames to the authoritative position, that might be a good middle ground between perfect collisions and not having player collisions, for what I'm making, collisions are really not that important so I think I can make it work. Still, I don't understand how games like Csgo have such perfect collisions, without any snap or correction, AFAIK source uses entity interpolation, so no extrapolating there..

CS Go does not have perfect collision, it just hides the corrections.

And I have at times ran right beside some teammate, and kept getting corrected back (and they did, too) – even though they were behind me on my machine.

Unless you go delayed-commands (like RTS games,) you will have to cheat and hide the corrections somehow. Exactly how you do that, is specific to each game!

Is it a racing game? Just obscure it with smoke and dirt effects :-)

It is a real time first person game.

I don't know why I had this idea that reconciliation meant “snapping back" the player to an authoritative position. There are many ways you can reconciliate: you could push, interpolate, snap, apply effects, forces, or combinations of them, as long as a player ends where it is supposed to be it will be ok. So based on the scope of my game I just pushed the player away towards the desired position! And it works, it is not perfect sharp but players will rarely collide with each other. Thanks!

razcodes said:

@hplus0603 Point number 4 is interesting….

I don't know if you have played Minecraft but there the collisions are not solid and sharp is more of a “pushing away” the player over several frames to the authoritative position, that might be a good middle ground between perfect collisions and not having player collisions, for what I'm making, collisions are really not that important so I think I can make it work. Still, I don't understand how games like Csgo have such perfect collisions, without any snap or correction, AFAIK source uses entity interpolation, so no extrapolating there..

Oh cool, I didn't know that Minecraft did this since I haven't played it much. I had come up with a similar idea which I haven't implemented yet. Basically, you collide with what your see on your client. Because of lag this means that you can end up with two characters in the same place once everything is resolved. However, if the collision algorithm basically produces a force in the opposite which pushes the character apart. Each client resolves its own collision this way.

I thought of a few corner cases with this. For instance, let's say both characters jump in a pit where only one can fit. Then you do end up with two characters in the same place after the server resolves it, because the force would push against the geometry which would constrain movement. But I'm not sure this is a bid deal. Once one character jumps out of the pit it will resolve itself.

Where solutions like this start to stuggle is when there are 3rd ‘bodies’ involved, such as another player, or a physics joint or constraint, etc. The simulations can get unstable under these circumstances, especially since what would normally be resolved in one iteration in a local simulation can now oscillate over a longer period of time as the forces get transmitted back and forth across the internet.