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

[Caliban Tiresias Darklock]

On 10:58 AM 8/25/98 -0400, I personally witnessed Adam J. Thornton jumping
up to say:
>On Tue, Aug 25, 1998 at 05:44:18AM -0700, Caliban Tiresias Darklock wrote:
>
>> 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?  

I figure the more people I have using it, the more feedback I get, the more
feature requests I receive, the better the product ends up becoming.
Windows may be a crappy platform, but it's still the one everyone is using.
If I want this in the hands of thousands of people in a short period of
time, Windows is where I have to develop it. 

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

"Doctor, it hurts when I do this..." Correct me if I'm wrong, but aren't
stray pointers something you shouldn't have in the first place? Every
argument I've heard for W9x being a bad platform comes down to "If you
screw up, bad things happen". Well, call me arrogant, but I say just don't
screw up.

>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 much rather implement it under Be, myself, since I'm very excited by
this new O/S and the possibilities it offers, but virtually nobody is
running Be -- and the people that *are* will recommend things like "Why
didn't you subclass control X instead of writing your own version?" instead
of "I want a function to total up the current amount of gold carried by all
online players and distribute it equally among them." 


In other words, the people running Unix-based systems like these are not
going to provide the kind of feedback I want after the release is made.
Right now, they'll provide excellent feedback, and excellent ideas. But
once the initial development is finished and I have a server up for FTP,
their involvement should drop significantly relative to the unsophisticated
user who isn't building his own MUD, doesn't know how to build his own MUD,
and wouldn't know where to start learning. I think we have enough MUD
servers out there that an accomplished programmer and sysadmin can put up.
I'd like to build one similar to the old style door games of the BBS world;
open the readme, follow the five steps, and lo and behold you have a MUD. 

Basically, I want more *creative* people and fewer *technical* people
starting MUDs. We have enough MUDs out there being run by folks who are
into quantum theory and astrophysics and eighty thousand chessboard
problems. I want to see some that are being run by creative, artistic
people that want to build worlds. I want to make MUD servers accessible to
these people. I want it to be easier for them to build what they want and
make it do what they want. 

I think this will better the entire MUD community. We need new blood. 

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

I always *think* I'll remember what I was doing there and don't bother to
comment. Then I come back two weeks later and go "Uhh... what was I
thinking?" 

And then, of course, there was the time I wrote a CRC embedding program
which actually embedded the CRC in the data stream. I was drunk when I
wrote it, and while it *works*, I have never been able to figure out how.
I'm still having trouble admitting it's even *possible*. You can't embed it
in the data stream until you know what it is, and you can't know what it is
until it's in the data stream. I wish I still had that code. I never did
figure out how I managed to do it. On the bright side, it convinced me to
quit drinking.

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

I think Perl is a little *too* flexible and powerful for what I'm thinking
of, actually... with JavaScript, we're already working from a standpoint of
a limited language with limited features, while Perl can be used to write
entire full-featured applications. Same with Java. 

Not to mention there are a lot more people who know JavaScript than people
who know Perl. I think JavaScript is definitely the more accessible
technology... although there's an argument to be made for VBScript. I tend
to think VBScript is a toy, myself.

---
=+[ caliban at darklock.com ]=+=+=+=+=+=+=+=+=[ http://www.darklock.com/ ]+=
"It must be remembered that there is nothing more difficult to plan, more 
doubtful of success, nor more dangerous to manage than the creation of a 
new system. For the initiator has the enmity of all who would profit by 
the preservation of the old institution, and merely lukewarm defenders in 
those who would gain by the new one."              -- Niccolo Machiavelli
=+=+[ FREE KEVIN * http://www.kevinmitnick.com/ * IT COULD BE YOU ]+=+=+=