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

[Caliban Tiresias Darklock]

On 04:51 PM 8/24/98 -0700, I personally witnessed Jynx (Wyrm / Tygr / Myth)
Ryn jumping up to say:
>Caliban Tiresias Darklock wrote:
>> 
>> I've thought about doing something like this... I have this hairbrained
>> idea of a modular MUD, where the internal networking code is in one module
>> and everything else hooks into it from external plugins. So the question of
>
>Modular MUD, eh? Well, from my past experience, MUDs are all
>modular, having such things as zone/room/mobile files and the 
>like, but I'd love to see the design for your version. 

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. If you wanted to get more complex, it could
pass the user to any of several alternate modules -- say, an administrator
interface, a builder interface, a player interface, etc. -- and even into
different modules to handle text mode, graphics mode, whatever. Each
module, in turn, could access its own databases and its own additional
modules, chaining together into a huge web of DLLs or (preferably) script
files which make up the whole MUD. The idea is to make the game flexible to
the point of idiocy. If you prefer a different combat system, you could
just replace the combat module. If you prefer a different character
generation system, you plug one in. If you want a new command, you can plug
it into the command module. And so on, and so forth.


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. 

>Because 
>of my experience as a hacker/gamer, my one complaint with most 
>comercial games is that they aren't easily hac ... I mean,
>customized. 

I think we probably come at games from the same general vicinity. I've been
having great fun editing the text files in Dungeon Keeper and using the
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, 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. :)

>Yeah ... that's the ticket. I always wanted to
>add more stuff to games like Warcraft and the such, so I always 
>found myself saying, "This would kick ass if it was MODULAR!" 

I always found myself saying "I wish I had the source code!" -- and then
eventually I started *getting* the source code to a few games, and realised
that the vast majority of game developers don't know how to comment and
have a sadistic predilection for making bad puns with variables. (I'm sure
everyone thought "do while(diddy->diddy==dum.diddy->doo)" was really cute,
but that doesn't make it suitable for inclusion in a real product.) 

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

>Well ... having the capability to add plug-in-races/classes/clans/etc. 
>would make MUD development much easier, just like adding 
>scripting into a MUD does. I wonder ....

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. There are
certainly more robust and less buggy options, but I keep asking myself --
is it worth giving up the advantage of a huge existing userbase? Thus far,
I don't think so. On the other hand, I'm not convinced that a scripted
solution will have the appropriate speed to handle large numbers of
players, and I also think requiring compilation has a tendency to weed out
some of the more clueless implementations.

---
=+[ 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 ]+=+=+=