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

[Adam Wiggins]

[Chris Gray:]
> [Vadim Tkachenko:]
> :Pretty realistic - today my wife was driving and had to brake real hard
> :not to hit the guy who changed the lane right before the red light. We
> :stopped, thought it was over. Two seconds later, the next car hit us
> :from behind.
> :
> :What I would do in such a situation is not to give the user the 'it's
> :over' feeling, but just defer the complete decision about what is really
> :happening for some reasonable amount of time, depending on the network
> :delays.
> 
> I'm not convinced the two are equivalent. In the MUD case, full evaluation

I'd say that they aren't at all.  I like this line of thinking, though -
depending on the exact circumstances of the engine (theme, really), you
could 'cover up' all kinds of net glitches with this sort of thing.
A simple example might be the screen shaking, the ship's HUD displaying
'collision imminent', etc - and a moment later your either flying clear
or cutting to a nice cinematic shot of your ship blowing into a thousand
fragments.  This, to me, is much better than having to wait on net lag
for every single thing I ever do in the game - a few seconds of inaccuracy
cleverly concealed versus an unresponsive client.

> of the situation by the "ahead" client indicated that the incident was
> over, but then action by the "behind" player has an effect which undoes
> that conclusion. My instinct says that you are going to run into some
> very difficult to solve problems. I don't have a more extensive example,
> however.

I'd point back to my original post which included event flags for priority.
Explosion would always require server confirmation - thus through either
netlag or innacuracies in the client's representation of what actually happened
(due to poorly timed event packets) you see ships passing partially or even
completely through each other, but never an explosion until the server has
actually sent the event.  On a slow connection this means that all collisions,
including weapons fire, has a delayed explosion effect, but the client
engine still runs at full framerate.

> :Say, if it's a spaceship, I'd pretend to have some sort of a self-check,
> :which takes some time to complete and switches on in any dangerous
> :situation. And, if your fuel tank got hit, you don't explode
> :immediately, do you?
> 
> No, but once your fuel tank is hit, the physics of the situation proceeds
> apace and it explodes. Look at it the other way around - the action by
> the "behind" player prevents a quicker explosion, that the "ahead" player
> has already seen. So, the "ahead" player sees his ship start to explode,
> and then a second or two later, the explosion is mysteriously cancelled,
> with no record of it every actually happening. As a player, I'm not sure
> I'd like that.

I should hope that the above would take care of that.  The only thing that
would take some getting used to would be the client inaccuracies; the nature
of the thing should be stated up front to the users, and complaints of "but
I saw my shot go right through his ship!" would be ignored.  IMO this is a fair
tradeoff until the net gets more reliable.

This is good stuff, though.  I probably need to formulate some complex
scenarios and post them in order that we can pick holes in something a little
more specific.