[MUD-Dev] Fighting Lag

[ceo]

Elia Morling wrote:

> 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)
 
> 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.

Lots of research on this. Suggest for starters:

   1. Dead-reckoning, and the many improvements that have been
   spawned (used widely in US military battlefield simulators,
   should be lots of Google matches)

   2. Search the MUD-DEV-L archives for the email forwarded from
   John Carmack, explaining what Q3 did to deal with unreliable
   (high packet loss) connections. (I think posted by Brian Hook,
   IIRC, but could be completely wrong)

   3. PlanetQuake, which heavily modified the predictive estimation
   for players in networked Quake1, and vastly improved Q1's network
   performance.

That's three largely orthogonal directions of resarch (although
undoubtedly Carmack took on board PQ's improvements). If none of
them help, I can try digging up more detailed/varied sources.

Adam M


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