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

[Ruud van Gaal]

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>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
> http://lists.cubik.org/**mailman/listinfo/enet-discuss<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/3b5656bd/attachment-0001.html>