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.
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
