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

[Emmanuel Rivoire]

Hello,

At 23:56 25/05/2012, you wrote:
>In that case, wouldn't just typical multiplayer prediction logic be 
>better? I don't expect that you'd get 60Hz packets neatly over the 
>internet (you do over LAN though), but I could be wrong there.
>
>How about letting the server send out update packets for the ball; 
>position+velocity. The clients handle time offsets (wrt the server) 
>and ballPos=position+t*velocity.
>I do that type of interpolation (prediction really) in my racegame, 
>and it works better than expecting packets to drop in neatly every 
>1/60th of a second.
>
>You probably looked into this, otherwise check out Half-Life 2's 
>multiplayer page on prediction/lag. There's a bunch of ways to 
>either predict (HL2 really takes the last 2 packets and interpolates 
>between those; I take the latest packet and start interpolating from 
>there, to combat lag).
>The tricky part is getting a good client time offset (to calculate a 
>servertime which is quite correct on all clients; something which 
>can be tested by flashing the screen every second for example, quite 
>a nice visual test).
>
>The only real events for a tennis ball are when it gets hit, which 
>will be the main concern. But if clients predict this as a player 
>hits the ball, you'd see virtually no lag.


My game already uses prediction.
I don't have a client / server, but 2 peers running the game in 
parallel ; thus instead of having the server playing without lag and 
having the client playing with a Latency equals to the ping, I have 
both players in almost equal state having about half the ping of 
latency ; this is much more fair. (the time to go to A from B, and to 
go to B from A isn't always identical though, but most of times, it's 
pretty close)

So I don't send any coordinate, only input, which is 1 byte per 
frame, plus other few stuff to handle smoothly packet delay and loss.

The 60 packets/s rate is handled without problem in most cases. 
Before to start the game, I test the connection with about 15 
packets/s 1st and usually the latency during that phase is same than 
during the game itself when the rate is higher.

Prediction can only do so much good, and it cannot know the future 
for sure, thus the need to have the lowest latency possible. This 
mainly needed when the opponent player hits the ball, so there's no 
jerking on ball, or as little as possible, but also at other times, 
because we also need to know what is doing our opponent to decide 
where to position ourself and where to aim our next strike.

When the latency is high (above 300ms ping), my users already 
complain sometimes about their opponent movement. The game is still 
globally playable up to 500ms ping, though. I even allow to play up 
to 800ms ping.