[MUD-Dev] Re: Wild idea.. :)

[Adam J. Thornton]

On Wed, Sep 02, 1998 at 11:05:38PM -0700, Caliban Tiresias Darklock wrote:
> On 09:41 PM 9/2/98 -0700, I personally witnessed Ben Greear jumping up to say:
> >So, who here is considering writing a server that talks (only)
> >with a graphical client.  And not just a web browser.  I'm talking
> >fully 3-d rendering with all the assembly (or whatever) that goes
> >with it.
> It might be really cool to do a graphical/text client. Something where you
> can have a text mode interface *and* a graphical interface. I'd like that a
> lot. I'd be really impressed by it. I'd jump from mode to mode depending on
> what I was doing. Hanging around chatting, use text mode. Exploring, use
> isomorphic. Fighting, use first person. That would rock.

I don't know if I'll ever be able to get it to work, but this is basically
what I'm doing with my model (by the way, the multiprocess/multithread
model is working beautifully with domain sockets now, although I had to
write a protocol to keep trying to sendmsg()/recvmsg() the open inet socket
descriptor, since it fails around 80% of the time, even when the sockets on
both ends are open (I think because the threading causes signals, and
that blows away the syscall, so it has to keep trying until it gets
lucky; eventually, I may mask the signals but I haven't thought through the
implications of turning off threading (in effect) in the fd distributor
code, so I'm not going to do that any time soon, since it works acceptably
now)).  

I have no plans to do 1st person because it's just too hard, but text and
tile-based graphics are planned to be two of the interface options.  The
idea is that the client and server will negotiate what is supported
(graphics--if so, what resolution and depth?, text, what sound
formats,speed of connection,whether to take longer and get the resource
data right or just fake it with generic equivalents if the download takes
too long, etc.) and the client can change its preferences at any point.

Since the actual room data is one data stream, and the description
resources are a second, this will be easy to do.  This will also let the
description resources live closer to the client than the room data.

All along I've been planning a multiple-server model, where each city (this
would be assuming that I get more than, say, 500 people to play, ever) gets
its own server; handoffs between them are pretty easy.  It does mean that I
need a master server that contains pointers to each city server and holds
game-wide unique data (players, basically: their object tree of possessions
gets copied when they move between servers, but you need to have a central
point of first contact on login that remembers where your character is,
marks it as "checked out", and places it in the correct city if it isn't
there already); this in practice probably should be at least two mirrored
servers running in a failover configuration, since if they crash the whole
game is screwed, although you could reconstruct much player data from the
individual servers' object trees.

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman