[MUD-Dev] Re: Modular MUD [Was:Finer points of Telnet programming ...]

[Adam J. Thornton]

On Tue, Aug 25, 1998 at 05:44:18AM -0700, Caliban Tiresias Darklock wrote:
> Well, this is the general concept... you have a basic kernel, much like an
> operating system, that handles telnet connections and ONLY telnet
> connections. When a connection is first created, it is passed to a
> "starting" module somehow (I'm still in design stages) which handles the
> decision of where to pass it next. This starting module could perform some
> complex logic; I'm expecting that a MUD which looks just like a Diku would
> simply get the user name and password, authenticate, and then pass the user
> into the game module itself. 

s/game module/process responsible for the room in which the player exists/
and you have basically the same model (although the initial connection
needs to both authenticate and tell where the player object currently *is*
before sending it there.

> modules, chaining together into a huge web of DLLs or (preferably) script
> files which make up the whole MUD.

This is one thing I don't understand.  Why would you want to run a game on
a W95 box?  NT I can see, since you at least get something close to a POSIX
environment and it's pretty stable, but with W95/8, a stray pointer can
crash the whole machine.  Linux and FreeBSD are both free, and you get much
better process isolation, plus more portable code, since it'll be trivial
to take ANSI C and make it run on W32 platforms as a console app, modulo
things like pthreads support that Windows may not have.

> I'd like to state in big letters here that THIS CAN BE ABUSED. Otherwise
> people will start posing "what if" questions about things like incompatible
> modules, etc. I'm trying to define the interface between modules in such a
> way that you can't *make* incompatible modules, but that's an impossible
> task which will have to be curtailed at some point of diminishing returns. 

True, but if you carefully specify the API and make sure to repeat over and
over and over that it's the caller's responsibility to initialize space
that the called module overwrites and returns a pointer to, you could have
a workable model.

> level editor from their web site, myself... I've also been repeating my
> 15-year-old effort of reverse engineering the data files from Might and
> Magic 1,

You too?  I wasted a weekend doing this with my Apple II.

 and considering the possibility of writing a character editor for
> Windows... I rarely avail myself of preconfigured "cheat" programs, but
> I've always had this desire to write one, if only so lesser gamers will bow
> their heads in deference. :)

I did, but after I did the M&M hack, I realized that *I* already had a hex
editor and knew what all the slots were for, so what was the point?  That's
always been my experience with character editors: the fun part is
deciphering the format, and writing the editor is just tedious.

> I try to write code with the assumption that the next person to work on it
> will be a homicidal psychotic who knows where I live, which tends to make
> it much friendlier. ;)

I try to write it with the assumption that I'm going to be back and want to
fix it in three months.  Of course that might just be a special case of
your scenario.  I also tend toward the obvious rather than the clever code;
my compiler can worry about trying to make it clever.  I want to understand
what it's doing.

> Ideally, and if I can manage to come up with something powerful enough (and
> *fast* enough) I may do this, the modules which make up the actual MUD
> activity would be scripted and not compiled. I may even use some sort of
> object interface compatible with JavaScript, since I would hazard the guess
> that there are no other scripting languages which approach that level of
> power and flexibility with even *half* the user recognition.

Uh, Perl?  But then, Perl is my answer to everything, and right now I wish
I were writing my current project in it, except that I don't think it's
going to be fast enough for the core.

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