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

[Ben Greear]

On Sat, 28 Feb 1998, Chris Gray wrote:

> [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
> 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.
> 
> :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'd like to throw my two cents in here....  First of all, when you're
talking about the mass and size of a decent space ship, a seconds time
isn't that long.  I mean, think of a 3 ton craft...F=MA gives you certain
turn-around time.

My proposal goes something like this:  You basically have two servers.
One is the real server running 'out on the net', in a well known location
like normal.  It has no GUI and lives to communicate with proto servers on
user's machines.  Now, code wise, these proto servers would be extremely
similar to the real server.  It would be predictive, hold many objects in
long term memory...   It would constantly (as possible) be receiving
status updates from the offical server.

So here's the fun.  You have to make it blend in the hard updates from the
server with it's current timeline, which will usually be slightly
different.  For instance one player (a) gives command to the main server
to launch a missile at player (b).  The server concurs, and the missile is
launched...and will arrive at target in 3 seconds.  Due to a one second
lag, player b only gets 2 seconds to react to the news.  I don't consider
this un-realistic.

A concept of having things 'appear' on the 'scanner' should be both
playable and realistic.  You could of course have you're ship programmed
with numerous auto-responses, which the original server would be aware of
and execute accordingly....

I envision the local proto server (pserver) as being connected to a GUI
via a socket, or lifo or something, the importance that it is two
different processes.  It will be written in C++ as is the server, but
the actual GUI code will be Java.  Of course, with the loose coupling, it
could be rewritten in C++ if the java proved too slow, and not too much
time would be lost.

One thing, if several ships got into a dogfight, then the communication
lag could break down somewhat.  I would propose that time 'slow down'...
The problem would be catching back up with the rest of the world..but I
don't really see that as too big of a deal...just magically make the ship
go a little faster than it really should be going to its next
destination...and others slightly slower coming in....

Still got a lot to work on, not least of which would be the predictive
nature of the pserver and having to 'fold in' events received from the
actual server.  I would make the GUI polygon based rendering with bitmaps.
I've no expertise, except for a decent understanding of math, in this
area, so any suggestions would be welcome.  Also, the interface between
the pserver and the GUI would be (reasonably!) well published, so that
anyone would be welcome to write their own...

If money became involved..it would be charged for connection to the main
server.  Could also sell a 'server license' to let ppl run their own, like
say on their local network.

However, it remains a hobby, and an unstarted one at the time being :)

> 
> --
> Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA
> 
> 


Ben Greear (greear at cyberhighway.net)  http://www.primenet.com/~greear 
Author of ScryMUD:  mud.primenet.com 4444
http://www.primenet.com/~greear/ScryMUD/scry.html