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

[Stefan Lundmark]

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 
> <manu.n02 at laposte.net <mailto:manu.n02 at laposte.net>> 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
>     ENet-discuss at cubik.org <mailto:ENet-discuss at cubik.org>
>     http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20120525/53c5f4fa/attachment.html>