[MUD-Dev] Fighting Lag

Tom Hubina tomh at 3dgamedev.com
Fri Mar 14 14:22:59 New Zealand Daylight Time 2003

At 01:56 AM 3/12/2003, Elia Morling wrote:

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

I think your biggest problem is that you're trying to use a fixed
time step. This definitely won't work.

 From what I remember, client/server synchronization can be done
 with something like the following:

There is a single global time that all events are relative to. This
time is the server's clock. All of the clients attempt to
synchronize to the master clock. You can look into the NTP protocol
to get some ideas about how to do this kind of synchronization, but
just sending an absolute time value to the client periodically is
probably sufficient.

All events coming from the server are stamped with the time the
event happened. When a client receives the event, it can either
start playing it immediately, or it can extrapolate from the time
the event occurred and draw the result in the "current" location.

For example, someone casts a spell and on the client you get some
nifty particles. It's fine that particles start when the event is
received since it is merely cosmetic. Another example would be
someone firing an arrow. When the "fire arrow" event is received the
client can interpolate the proper arrow position from the time the
arrow was launched and draw it at the correct position for "now".

Other things you can (and should) do is predict where you think
things will be between updates. If you include velocity vectors with
positions you can have the entities continue along those vectors
until a new bit of information is received (most likely with time
limits for disconnects). This will help make things smoother.

To further smooth things out, you can attempt to blend from your
predicted position to the real position.

When a client generates events to be sent to the server you can
either trust the client to use the right time (in which case it
stamps it's event with what it thinks the server time is before it
sends it out) or you can say that the event doesn't happen until it
reaches the server. In most cases, I'd go for the latter approach as
it helps reduce client trust issues (always a dangerous thing).

You could get more info about this stuff on the algorithms list
(check the archives .. there's been a lot of threads over the years
on this and similar topics):



MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list