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

[Ben Greear]

On Thu, 3 Sep 1998, Adam J. Thornton wrote:

> 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)).  

That 80% sounds like it could kill you if you were running under any kind
of volume...but thats just a guess.

> 
> 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.

I think it would be easier to do first person.  Let the computer calculate
the layout from a few, rather simple, equations (velocity, time,
accelleration, and possible delta-acceleration if you really want to
be fancy).  Tiles limit you to a finite universe.  Auto (and manual)
generation of objects based on primitive shapes (triangles + textures)
could be almost infinite, especially when you realize you can place
them in any possible arangement.

> 
> 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.

Yes, I like that idea a lot...cache as much as possible on the local
HD/CD-rom/DVD-ROM/1-gig Ram-disk/whatever!

> 
> 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.

One issue I was working on:  each object must have a unique identifier
across the entire universe of servers.  This is for permanent storage
problems, ie DB key, however you do your DB.  I will use a unique ID
for each server, and increment a 64 bit number on the server itself.  If
it wraps..well, then the game is over, big bang kinda thing! :)

> 
> Adam
> -- 
> adam at princeton.edu 
> "There's a border to somewhere waiting, and a tank full of time." - J. Steinman
> 
> -- 
> MUD-Dev: Advancing an unrealised future.
> 


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