I recently started working on my first multiplayer game and learning multiple game server mechanics. The game itself uses mouse movement.

For the first version I used a very simple approach, where the physics are run both on the client and the server side, and the client and the server both run at 60fps. The client only renders what it gets from the server and every collision/movement is processed server side.

Now every frame the client sends his mouse position to the server, where the players next position is processed and sent back to the player. This approach worked for some time, but at the time of writing the code, I didn't take the latency in account. For really good internet connections or locally for me, there isn't any issues, but for not so good internet connections there's lag obviosly.

So I started searching for a solution to my problem and I found this article - http://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html

I implemented the Client Side Prediction to my game with the Server reconciliation but now I noticed another problem. Because the collision detection happens server side, I can see that sometimes the collision happens much later than it should. Pretty obvious because the server is in the past.

So I was thinking, what would be the best solution to this problem? I could move the collision detection to the client side, but we all know, that the player can't be trusted, so I would need a way to verify this collision server side. And what if the player tampers with the code and disables collision detection (because some of these collisions are deadly), how could I known when the collision is happening?

Another issue I though of with the client side prediction, is if the player throws a grenade at some other player, but in reality the other player isn't at the specific position yet, because his position was also predicted. What would be the best way to handle this?

Another issue with the client side prediction is the client and server sync. Even locally with latency -20ms the client and the server object goes too far away one from each other. You can see this in happening in this video - https://www.dropbox.com/s/g2a6vit8s79pxbe/client-prediction.mov?dl=0 

You can see my current approach here, which doesn't use the client side prediction at all

1. Nobody said that Prediction is not allowed to predict the collision also, rather the opposite, the more accurate you predict, the better the result will be (-> you'll diverge less from the state the server sends). Hence run collision detection (and response) etc. on client side until you get the correcting values from the server.

2. it's common that the server accounts for your latency and checks what state you probably had on the client, then evaluates what happens. if your prediction was correct (e.g. the other player had linear motion), both sides should have a similar state and get (commonly) the same result.

https://www.youtube.com/watch?v=6EwaW2iz4iA

I failed to mention that in the video, the first circle is the player object with client prediction and the second (red) circle represents state in the server for the same player

There are two basic ways of dealing with client/server latency:

1. Client only displays what it's head from the server. Commands are queued through the server, and then echoed back. RTS games use this model. Command latency is hidden using "yes, sir!" animations when commands are given, for example.
2. Client simulates ahead based on local input for the player, but simulates other objects based on what it's heard from the server. This means the player will see "wrong" data and the display is in a continual state of "catching up" with what it hears "actually" happened from the server.

In option 2, there are in turn a few ways of dealing with how to display remote entities when the player is "ahead":

• Predict forward remote entities, based either on trajectory, or latest-known command, or some AI model of what players "ought" to do.
• Display the other players "behind."

In option 2, there are also multiple ways of breaking "ties" (such as "did I shoot you before you dove into cover?")

• Place the server entity back into the frame that the client should have seen it in when it shot. ("Counter-strike model")
• Accept the hit determination done on the client. (Mainly usable on consoles, because PCs are too open to cheating.)
• Run the hit detection on the server, and require that players "lead" their shots. ("Quake model.")

There are also different ways in doing the reconciliation (snapping, smoothing, re-play, etc) each time you receive data from the server, which will have been "in the past" compared to where the player is.

Each game has a different need for different trade-offs, and which specific combination of mechanisms you choose depends on gameplay needs. Only careful design, implementation, testing, and feeding back into design will let you know what's actually best for your own game.