Player Speed and Client prediction in Multiplayer

[Loonride]

I have some questions about my real-time multiplayer game. My game is already on the domain dinoman.io, but I think I need to redo how client prediction works. I sometimes notice that the movements of other players are quite choppy, and sometimes slower than the speed that they are supposed to be. Here is what I am currently doing:

I get the dt from the Phaser update loop: update(timestep, dt)

When the player presses an arrow key, I move them to a new position by the distance: speed * dt

I then send their new position to the server at the end of that update loop

The server checks that their speed is legitimate like this: It adds up the distance that they travel for a few seconds, then takes that distance and compares it to the time that passed on the server to see if it closely resembles the speed that the player should have had. However, I have to add some extra allowable distance to make sure that normal players aren't labelled cheaters. I thought this would be the best way to fight cheaters, but I'm wondering if there are better ways.

The server sends out the players new position to all other clients

The other clients do not move this player to that exact position in their update loop, but rather use their own dt in their update loop and the knowledge that this player should have a certain speed to move this player smoothly. If the predicted player position becomes too far away from the real position, the predicted position moves just far enough so that it is not too far away from the real position. This method seems to work most of the time, but there are times where I still see choppy movements from players, maybe because they are using really low-end devices. I almost never see choppy movements of players in popular IO games, and I am wondering where I went wrong.

 

I mentioned that I sometimes see players moving slower than expected. Shouldn't multiplying speed * dt in their client always fix this problem, regardless of how low-end their device is? I want to say that there are times when it seems I move slower than the speed I have set when I start playing my game, but maybe that is rendering lag or something. How could the dt possibly be wrong?

Thanks for the help, I know this is a lot!

[Antriel]

Phaser 3 smoothes the delta time, which could cause the issues you are seeing. You would want to either change phaser's timestep or calculate the dt yourself.

Also keep in mind that computers use crystals for tracking time and they don't exactly have high precision. With clock drift of around 20ppm, your time which can mean around 16ms difference between server and client within 7.5 minutes. Not much, but something for long plays, it can start showing.

[Loonride]

30 minutes ago, Antriel said:

Phaser 3 smoothes the delta time, which could cause the issues you are seeing. You would want to either change phaser's timestep or calculate the dt yourself.

Also keep in mind that computers use crystals for tracking time and they don't exactly have high precision. With clock drift of around 20ppm, your time which can mean around 16ms difference between server and client within 7.5 minutes. Not much, but something for long plays, it can start showing.

What exactly does smoothing delta time mean? I realize that Phaser 3 has a varying timestep. Would you simply calculate dt yourself by doing

dt = Date.now() - pastTime;
pastTime = Date.now();

each time in your update loop? Also, as long as I'm never comparing client and server timestamps, clock drift should not matter, correct?

[Antriel]

3 minutes ago, Loonride said:

What exactly does smoothing delta time mean? 

https://github.com/photonstorm/phaser/blob/15b544fc4689f7b45e96b07954b9a994d04287fd/src/boot/TimeStep.js#L508-L522
 

3 minutes ago, Loonride said:

Would you simply calculate dt yourself by doing

dt = Date.now() - pastTime;
pastTime = Date.now();

each time in your update loop?

Yeah.

3 minutes ago, Loonride said:

Also, as long as I'm never comparing client and server timestamps, clock drift should not matter, correct?

Yep. It's more about staying in sync with server. In my games I run prediction in the same rate as server runs its updates. Clocks drift could eventually mean the client would be too far behind/forward of the server and mess it up.
Just be careful of indirect comparisons, like assuming n-th update from server corresponds to n-th update of client.