[MUD-Dev] Fighting Lag

[Daniel.Harman at barclayscapital.com]

From: Elia Morling [mailto:elia at familjen.se] 
 
> 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.

Something I'm not clear on, is why you are tying the frame rate of
the gfx engine to the game engine clock of the server? You might
like to consider decoupling them and skirting the issue. How you do
so depends a lot on your interface, but if the player clicks on a
location to move there, typically you'd send the server that request
and it would then send the client instructions to move the player to
said location. In a more advanced implementation you might be
running the path finding routine both on the server and the client,
so that you can kick off the movement before receiving an ACK back
from the server. This gives the perception of low latency, but you
do sometimes end up with rubber banding etc. if the server then goes
on to deny the request. If you do take this approach it's a good
idea to use the same pathfinding code locally and on the server.

If you search the mud-dev archives, there is a lot of info on
networking, including a summary of the ingenious approach used in
Quake 3 which Brian Hook kindly obtained for us straight from the
horses mouth (John Carmack).

There is also some interesting overviews of Unreal's (v1) network
layer if you search on google. This covers a few issues you might
otherwise not consider.

I also recall seeing articles on http://gamedev.net/ and
www.gamasutra.com which pertain to the topic. IIRC one of the ones
on gamedev.net even discusses the problems of tying framerate to the
network packets directly and why not to do it.

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