[MUD-Dev] Fighting Lag

[Steven J. Owens]

On Wed, Mar 12, 2003 at 10:56:44AM +0100, Elia Morling wrote:

> I'm currently working on a spartime project, Tildruin - a free
> online rpg. The game is hybrid between text-based and graphical
> interface, as the player can select his/her style of play. It is
> possible to turn off graphics altogether and play MUD-style, but I
> imagine most players will adopt a mixed style of point-and-click
> and text commands.

Interesting.  I've thought of trying something like this, mainly
because I think the classic (non LP and LP-derived, like diku) MUD
world is still light years ahead of the MMOG world, in terms of
actual game _design_.  But the public wants a clicky interface...
 
> 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 sure there are more knowledgable 3D programmers here, but maybe
I can get the ball rolling.  From various reading I've done, the
model most people use seems to be largely building more smarts into
the client side.

     1) Send updates to the client, not frames.  Let the client
     build the frames.

     2) Make sure updates contain atomic information, so you don't
     have to worry about out-of-sequence or just plain dropped
     packets.

     3) have the client *predict* what's going on and render based
     on those predictions; when updates arrive, correct the model
     and re-render (this is the source of the classic quake
     experience where you're pounding away at somebody who doesn't
     seem to notice you, then all of a sudden you're dead!  It
     sucks, but it seems to be the best we can do with current
     technology)
 
You can make the client predictions smarter by applying more
skullwork and coding.  I remember one article I came across that
talked about using a mathematical technique to model not only a
given object's vector, but the change in vector over time as well.
With that approach, the prediction would be more likely to be
accurate.

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

I'd definitely recommend building some sort of lag metering into the
protocol, though I don't know how much overhead that would add.

> I'm asking for general input and wise suggestions. There must be
> huge experience in this area. How have others solved this problem? 
> Are there any articles or books on the topic?

There're a buncha books out there; I did some looking, last year,
but didn't find much particular to networked game programming.  In
more general game programming, the Game Programming Gems seem to be
highly respected as a source of in-depth articles on various topics.

  http://www.amazon.com/exec/obidos/tg/detail/-/1584500492/qid=1047712213/sr=1-1/ref=sr_1_1/103-5217580-0895062?v=glance&s=books

Steven J. Owens
puff at darksleep.com

"I'm going to make broad, sweeping generalizations and strong,
 declarative statements, because otherwise I'll be here all night and
 this document will be four times longer and much less fun to read.
 Take it all with a grain of salt." - Me at http://darksleep.com


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