[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 CEST 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-archive
mailing list