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

[Adam Wiggins]

Been in the process of moving to CA and my internet connection has been mostly
unavailible, so I'll be catching up on old messages for a while...

[J C Lawrence:]
> Adam Wiggins<nightfall at user1.inficad.com> wrote:
> > So here's a question to you, Chris, and all those that have remained
> > silent on this thus far: which do you prefer - a client whose speed
> > is directly proportional to the speed of your internet connection so
> > that you can rely on every client always being 100% "correct", or
> > one which runs at its own framerate (hopefully 30fps or better)
> > attempting to display what data it has about the world as best it
> > can, resulting in some inconsistencies (or perhaps many if your
> > connection is very unstable)?  
> > I know which one I'd choose, but I
> > wonder how many people feel the same?  Or perhaps there should be
> > some sort of consistency sliders in the options screen which change
> > how much prediction it does on its own, and how much it relies on
> > the server for?
> 
> Possible, but rather expensive to implement...

The idea I had was this.  The entire system is event based.  Everything, from
something obvious like an explosion, to something simple like an object moving
from point A to point B, is an event.  All event types are assigned a "severity"
level.  A sample might be:

Event Type            Severity
----------            --------
Movement                 1
Projectile Fired         5
Object Collision         10

If your slider bar was down at 0, the client would wait for ALL events to be
confirmed by the server, thus slowing your client down to the speed of your
internet connection.  Objects moving across your field of vision would jerk as
their positions were updated very slowly (~1 time per second in most cases).
Move the bar up to 3, and now movements are smooth as the client projects
where objects are headed based on former velocities, but things like shots
being fired by NPCs aren't shown until confirmation from the server is
recieved, nor are collisions reported (although the user may witness two
objects seeming to pass through each other for a moment before the collision
event is received).  Move the slider bar up to 7 and now NPC ships fire
projectiles when your client predicts they will, but collisions still wait for
confirmation.  Move the bar all the way to 10 and now all events are predicted
by the client.  This means that two objects colliding will immediately begin
their destruction animations (probably a big explosion).  If the server
reports that there was a change in heading of one of the objects just prior to
the collision, the client has to suddenly "snap" the objets out of their
explosion and put them in their new positions, ending the destruction
animation quite suddenly.

That was my thought.  As long as all actions are carefully encoded into the
event system (probably with container events containing many sub events), this
bar should be quite easy to implement, and will give users a large amount of
control as to the level of prediction (accuracy versus update speed).