[MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Wed Oct 21 22:52:38 New Zealand Daylight Time 1998

[Hal Black:]

 >One thing I'd really like to see, is have the modules made from VM code
 >completely interchangable with modules made from native code.  That way,
 >it would be a lot easier to replace VM code bit-by-bit with native code if
 >you need to do so for performance purposes.  This would be especially nice
 >if, say, the driver part was in C++, and there was a C++ to VM compiler.
 >Then, you could swap stuff in and out of VM mode as desired for profiling,
 >debugging, security, and so forth.

As I mentioned in an earlier note, problems arise more from run-time
library or support environment than from strict language issues. In this
particular instance, please note that C++ is a very large language - building
a compiler for it is man-years worth of work. There are some available
parsers out there, but then the problem of licensing can come up.

An in-MUD language will typically have language elements that are added
to make in-MUD programming easier. Those won't exist in external languages,
and so that stuff would have to be translated into function calls,
possibly quite a lot of ugly ones. As an example, the statement:

    player at hits := player at hits - weapon at hits;

in my system, would have to be translated into something like:

    PutProperty(player, GetProperty(player, hits) -
			GetProperty(weapon, hits));

assuming you have simple values usable as database identififers.

Keeping the in-MUD language(s) for higher-level world/quest/NPC stuff and
the native compiled language(s) for lower-level things is probably a
good idea.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA

More information about the MUD-Dev mailing list