Exactly. The ball doesn't change its direction after being sent away, so
there's no reason to keep updating it if that way if you predict the
next tick's position on the client.
On 2012-05-25 18:56, Ruud van Gaal 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.
Ruud
On Fri, May 25, 2012 at 4:51 PM, Emmanuel Rivoire
<[email protected] <mailto:[email protected]>> wrote:
At 19:55 25/05/2012, you wrote:
In that case it sounds like the optimization chances are more
at your end, trying to aggregrate information. If overhead is
larger than the data, you're probably sending too little data. ;-)
Damn, I sweat my brain off to get the smallest data needed to go
over the network, and got blamed for it..! ;-)
More seriously, I have to send 60 packets / second, coz sending
only 30 packets/s would mean to add 16.67ms of latency and that'd
be bad for my game : it's a tennis game, it's very latency
dependant ; for example, the ball can travel almost 1 meter during
16.67ms on the start of the service.
I did a lot of things to fight back the latency at the game level
and network level, but the 1st thing is to have the smallest
packet possible sent 60 times / second, thus my concerns about all
optimizations.
_______________________________________________
ENet-discuss mailing list
[email protected] <mailto:[email protected]>
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
