[Home] [Groups] - Message: [Prev in Group] [Next in Group]
8489: [MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)
[Full Header] [Plain Text]
From: Chris Gray <cg@ami-cg.GraySage.Edmonton.AB.CA>
Newsgroups: nu.kanga.list.mud-dev
Date: Wed, 21 Oct 1998 22:52:38 -0600
Organization: Kanga.Nu
[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@hits := player@hits - weapon@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@ami-cg.GraySage.Edmonton.AB.CA