Just a bit of musing

[Carter T Shock]

> In the past, when I've been "lurking", reading everyones contributions,
there
> seems to be a lot of emphasis on making things more realistic (unique, I
> suppose, which is good), but it seems to me what is often overlooked is
the
> "fun" factor.  It's a game.  

Amen brother. Spent 3 years as an imp trying to convince the players of
that little fact... but that's another story altogether :)

Anyhow, as I see it, the discussion hasn't necessarily been about making
things real. The way most muds store their database (cuz that's what we're
really talking here folks) of rooms, critters, and objects is atrocious.
The code tends to be littered with for loops that iterate thru lists (room
lists, player lists, etc etc). I, among others, feel this is a Bad Thing
(tip o' the hat to coder@).

Most of the tricks,structures, algorithms being proposed have the primary
advantage of letting you store lots of data in reasonably efficient ways.
One of the side effects of this is that you can add more realistic physics
to your mud if you desire. It isn't a requirement. Now... let's start
another thread while we're here :)

I posit that, in general, command interpreters for muds are Bad Things. The
proposal runs sorta like this:
	The command interface to a mud can be viewed as a context free grammar. As
such, one should be able to whip up a command interpreter with lex/yacc.
I've started on it at least a dozen times but never managed to quite
finish. Is this worthwhile? Thoughts?

While I'm at it, let's try another pet peeve. Most mud codes I've run into
run as a unified process. That is to say, there is one huge executable that
does everything. One nasty side-effect is that any socket-related problems
can bring the game to a grinding halt (in particular, a user connects on
the mother socket and ends up in the queue. The OS then steps thru the
mother socket's queue and creates new sockets for everybody it finds there.
If one of the connections has died on the queue, you go into a linger state
regardless of the socket settings while the OS tries to find the socket it
thought was on the queue). The suggestion goes like this:
run the game as a daemon. run another process to host the mother socket.
For each connection on mom, spawn a new process that acts as a comm link
between the user and the daemon. We'll call this intermediary a proxy.
The proxy and daemon communicate through shared memory or semaphores or
some such. Advantages:
the proxy <-> daemon link conform to a single interface scheme
the proxy <-> user link can conform to several protocols... say one for
   text-based users, another for binary messages etc.
if the user has link troubles, or is idle or whatever, it's the proxy that
hangs.
the proxy-daemon comm method is thru semaphores/shared memory. daemon
writes updates to a shared segment that is read-only to all proxies. daemon
reads new info from one segment per proxy. If the proxy has trouble and the
segment isn't updated, the daemon skips it. Look ma... user A's troubles
don't cascade and screw user B. Thoughts?
	-Todd (who's now had some coffee... way too much coffee)

PS: one more advantage to splitting up the mud process. One huge process is
_much_ more likely to get swapped out by the OS than several "small"
processes. Extra bonus points if you're lucky enough to run on a
multi-processor. Who wants to open the can of worms called "MUDs in a
distributed processing environment"?