[MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)

[Adam Wiggins]

[coder at ibm.net:]
> On 20/02/98 at 02:35 AM, Jon Leonard <jleonard at divcom.umop-ap.com> said:
> >On Sun, Feb 15, 1998 at 11:55:11PM +0000, coder at ibm.net wrote: > On
> >> It makes a lot more sense to me to move away from TCP for MUD clients, and
> >> instead look to UDP and design the client and server to be tolerant of
> >> dropped packets.  Sure, things will get a bit jerky of occassion, but it
> >> sure beats waiting for the time-out and re-send of a dropped packet.
> 
> >I'd be extremely reluctant to do this.  It's very easy to redesign TCP
> >badly, and nearly impossible to do better.
> 
> No, you misunderstand.
> I am proposing that MUD clients move to a protocol and data model which is
> tolerant of data loss.  If packets get lost, or arrive far to late, the
> client won't care and will continue to offer a decent representation of
> what is happening in the game.  The main problem with telnet lag is *not*
> latency but dropped packets -- the whole damn client freezes while
> awaiting the lost packet.  Instead have the client be predictive and work
> on a best-effort basis.  It works with the data it gets, and ignores or
> attempts to generate the data it never sees for whatever reason.
> Raph has commented that UOL's client does this in some areas.

I've been idly pondering this area for a while now.  Both UO and Furcadia
are in a similar position - fast enough to be playable, slow enough to be
annoying and quickly tiresome, especially if your connection sucks.  IMO
part of the problem is that the frame rate on both of these seems to be
reflective of the speed of your connection.  Thus even a killer rig seems
slugish and unresponsive if your connection happens to be running a bit
behind.  So I'd say the number one thing would be to have an engine which
runs at 30 fps or higher all the time, regardless of the info it receives
from the server.
On a slighty more interesting and possibly less practical line of thought,
I've been considering using the timestamps on the packets in creative ways.
As long as the server and all clients were synced, and all packets were
timestamped with an extremelly high granularity timer (say, 1ms or lower)
then the server could actually "insert" the packets it receives from the
client at that point in time, and then recompute all the events that happened
since then.  In order for this to work you'd need a very robust event
system (like JC's) and predictable AI for the computer-controlled characters.
You'd also need to clip the timestamps on incoming packets to a resonably
small interval - probably three or four seconds.
On these same lines, I had a brief idea about systems actually being a
different places in "time" on different clients depending on the average
response (ping) time.  A system with a 500 ms ping time would be .5 seconds
ahead of the 'real' system time.  Thus a player can react to events in the
world at a pace seemingly on par to those with a 10ms ping time.  I would
imagine anyone over 1s would probably booted off with a message about
finding a better connection or a closer server.  (I suppose this depends
on how time-dependant your server really was.  A high-speed car game which
requires twitch responses might choose a number as low as 500ms; a slow
paced RPG might go for as much as 5s.)  Assuming that it works this way
(players at different locations in time), I'm not sure what would happen
when you had a whole bunch of players with wildly different connection
speeds all very near each other doing highly time-dependant stuff (namely
collisions of whatever manner).  Even though you may be ahead in time,
this only helps you avoid predictable things like walls in the way of your
spaceship travelling at high speed, or computer-controlled entities with
static AI.  You still wouldn't get the data about the other player's movements
until a little late, leaving you at a disadvantage - but hopefully better than
if it was just a straightforward "process packets as you get them" type server.

Now, assuming that we're using both high-framerate clients and the timeline
breaking I'm suggesting above, this is going to cause some incongruous stuff.
A simple case would be the aforementioned spacecraft, piloted by a player,
speeding towards a cliff wall.  The player's connection is slow.  On their
machine, they hit the up key just in time to clear the cliff face and
continue flying.  Everyone else sees their ship fly into the wall, and then
a moment later, as the server inserts the packets, they fly clear to safety.
Depending on your world, you could approach this different ways.  You could
have certain events (collisions being the main example) flaged as requiring
server confirmation.  Thus, everyone would see the player's ship disappear into
the cliff face, but they would only see an explosion and a rain of ship parts
once the server confirmed the crash.  Otherwise they just see the ship pop
out of the other side of the cliff, making it look more like a glitch in the
clipping routines than a total server botch.  I would also tend to, instead
of making the ship "pop" to its new location, speed up by some large amount
based on the distance from the old position to the new one, so that it appears
to hurry to the new place.  This will certainly look funny, but hopefully not
like a 'break' - and if you have ships which speed up and slow down easily
anyways, hopefully this should rarely cause anyone to think anything is
strange.  Sudden turns will have the effect of doing a larger, sweeping
turn - a sudden 45 degree turn by the lagging player should look more like
an overshot 60 degree turn, which then turns back to the new heading.

I haven't thought this through real thoroughly, nor attempted any complex
or hairy scenarios.  I'm sure once I do some problems will pop up, but at the
moment it seems much more appealing than the usual unresponsive clients.

I also used all sci-fi examples (ships) because client prediction would
tend to be more accurate with them (I imagine).  Thank's to Newton's first
law, a missed second or two of packets won't be a big deal unless something
unexpected (collision, sudden direction change) happens, and even then it
can be made to look relatively seemless.