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

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

> 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
http://www.gerbil.org/tom/

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
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the MUD-Dev mailing list