[MUD-Dev] Languages for MUD drivers

bruce at puremagic.com bruce at puremagic.com
Mon Nov 15 21:45:05 New Zealand Daylight Time 1999

On November 15, 1999,  "Laurent Bossavit" <laurent at netdive.com> wrote:
> As my quest for the perfect M* server design continues (I've been a 
> deep lurker on the list for over one year, though some of you might 
> remember my interest at one time in porting LambdaMOO to Java (done, 
> but not the panacea I hoped)) I am more and more convinced that the 
> crucial parts are the underlying (implementation) and visible (world-
> building) languages - ideally both being the same.

Very much a familiar story!  Main difference is that I'm coming from the
ColdC camp rather than the MOO side, but they aren't that different at all

> A lot of the issues M* server designers and implementors struggle 
> with are in fact active areas of programming language research. These 
> are in approximate order of importance (for M* writers!)
>  - distributed processing support (for large worlds)
>  - concurrent processing support (for reactive worlds)
>  - object orientation (for modular worlds)
>  - object persistence (as in MOO)
>  - run-time mutability (aka dynamic recompilation, as in MOO/ColdC)
>  - reflective capabilities (so programs can modify themselves)
>  - security (to enable in-game access to world code by 'wizards')
> If we assume a language with the above properties, writing a M* 
> driver is almost trivial. A thin layer of network code will handle 
> client connections; a command parser will probably provide the most 
> challenging exercise in low-level programming, writing core 
> character/monster/item classes would almost belong to the 'world 
> design' category.

I agree with all of those things above, although I'm of the opinion that
with a good language, a number of them can be relegated to the libraries
rather than being integral to the language.  One thing I didn't like about
Cold was that too many things were integral to the language, and often,
there was at least one instance in which that made things extremely

> If you agree (or disagree) with the above assessment, or have 
> pointers to languages which would make good candidates for 
> implementing a M* server, please speak up. ;)

I like TOM (as do a few other people who will speak up if they feel like
it, but can remain anonymous if they prefer).  Info on TOM can be found at

Once I've found motivation to do anything outside of work beyond sleep,
TOM is what I'm planning on using to write a new server.

 - Bruce

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list