[ENet-discuss] Questioning a server without connecting to it

[Emmanuel Rivoire]

Hello,

At 18:01 29/05/2012, you wrote:
>That's interesting; you may have a lot of lag but still enough 
>bandwidth to push through 60 input states per second.
>
>I can imagine with 500ms ping, the delay of moving a tennis player 
>around can cause a miss when striking the ball.
>So how do you handle the moving tennis ball? Does it move the same 
>(the same time) on both clients, or is there some sort of lag 
>between what one client is seeing vs the other?
>Do you also send 60 pkt/sec with the ball position? I'd expect a lot 
>of jerks when trying to update the ball like that; you'd need a bit 
>of filtering to avoid timing issues and have a jittering ball on the screen.

There are 2 levels of processing : the input delay, and the prediction.

The game runs in parallel on both PCs, and basically, each game sees 
the same than if both players were physically on the PC, playing with 
2 gamepads (for example). So only the local input (pad direction & 
fire buttons) is sent to the distant PC, from each PC. No other game 
related information is sent (except at game start, to ensure the 
initial states match on both PC ; and during the game some other 
little infos are sent to know if the games are still in sync).
But as one player is distant, the trick to make it work is to delay 
the local input until the distant input is received. This delay must 
be fixed and cannot be different between the 2 PCs : this is the main 
downside of this technique. It means if the fixed delay is under the 
actual latency, then the game will pause and wait to receive the 
distant input. You can adapt the delay to the conditions, though, but 
it's not as easy & convenient than in a standard client/server 
configuration as it must be done on both PCs on the exact same game frame.

This technique is commonly used for RTS game network code (with some 
variants), where the maximum number of players is not too high.

So at 500ms ping, that requires at least 250ms input delay to make 
the game runs normally.
It means that your player starts to move 250ms after you actually 
pressed the movement key. Which is totally unplayable... ;)  I know 
well because the game used to be only that, without prediction, and 
the maximum enjoyable delay was around 100ms.

So above that, I added a prediction module.

It's always possible to predict our player movement, as all the local 
input in stocked locally and can be used to know where our player will go.

We can predict a bit our opponent movement, by using any input packet 
already arrived, and by predictable behavior (for example : he will 
usually run to the ball), but this prediction can be wrong often, so 
I can't push it too much, and I smooth the distant player's 
coordinates over several frames to avoid jerkiness when prediction 
went wrong ; so in average the perceived latency on the distant 
player movement for the local gamer's eyes will be usually around 
125ms. It's not great, but it's good enough to give an enjoyable 
online experience.

It's always possible to predict where the ball will go, as it's 
deterministic, except after our opponent hits it, coz we won't know 
for sure where he sent it before the next 250ms. So here, I need to 
predict where the distant player will aim and as it's not always 
possible to do it exactly, the ball will jerk sometimes a bit between 
the wrongly predicted position and its real position that will be 
known once all 250ms of input will be received.