[MUD-Dev] Fighting Lag

[Ian Macintosh]

Hi Elia.

> The graphic engine uses isometric view and offers non turn based
> animation. The client estimates the servers current frame upon
> login, by evaluating pings. Each frame is 100 ms, which gives a
> going communication rate of 10 fps.

I gather from this that you're trying to run a synchronised
(synchronized if you live in the US :) game via UDP?

There is some nice info re networking (Age of Empires) that should
be useful at:

  http://www.gamasutra.com/features/20010322/terrano_pfv.htm

It uses an inbuilt lag where commands are queued for future
execution that may be relevant.  There are also other hints about
monitoring your game net performance that are good things to do as
well.

> In a perfect world all relayed messages would stick to the
> estimated fps for excellent perceived performance. It is not the
> general "lag" that proposes the largest challenge, it is an
> inconsistent "lag" which is the problem. The problems cloud when
> messages arrive too early and too late, causing jagged/unreliable
> animation. Up to this point we have tried:

>   1. Dropping frames (causing jumps of character location)

>   2. Catching up frames (causing speedy-gonzales effects)

What about using predictive and smoothing code al la Quake design?
Might trash your current design a lot though :(

Have the server pass positions, direction and velocity, and let the
client smooth and predict based on last known info.  Once that gets
badly out of date with a lost client, you'll have to freeze that
character till comms come back up.  Don't get too hung up on every
screen/player being totally identical and correct.  Small variations
in perceved reality are acceptable in most cases?

> I'm currently working on a solution where the client adopts its
> estimation of the servers current frame periodically based on
> current lag/round-trip.  This will cause the client to "rewind"
> and "fastforward" time to make up for the current lag, as the
> quality of the players connection is far from constant during an
> entire session and we need it to be as consitent as possible.

My experience is that lag can spike quite dramatically at any time.
Sometimes you get total packet loss for anything up to a minute, and
although that's an extreme example it does happen.  There are
frequent periods of multi-second packet loss though.

Just thinking of what you said earlier re speedy-gonzales, are you
using UDP or TCP?  I'd suspect TCP from that effect...  TCP isn't
the best way to go, I'd rather handle the problem directly with UDP,
using seperate streams for stuff you can afford to loose and ignore,
and other info that *must* get through, and in the correct sequence.

Hope those thoughts help.

Your game looks good btw.

Regards,

Ian.


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev