[MUD-Dev] Languages for MUD drivers
iman at issystems.co.nz
Wed Nov 17 18:56:14 New Zealand Daylight Time 1999
> Laurent Bossavit
> 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.
> 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
I know LambdaMOO very well, and from your comment re Java conversion,
I presume you do to. What about it doesn't fit your list?
Distributed processing support can be handled by running multiple
processes and interconnecting them. I've always thought that this is
a better way of handling large systems and a large number of users.
ie, segment areas (zones) onto different servers and link them.
I'm not sure of what you are refering to when you say concurrent
processing support? I understand the term, but I don't understand the
context re reactive worlds?
Perhaps you could also elaborate reflective capabilities?
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev