MUD-Dev
mailing list archive

[ Other Periods  | Other mailing lists  | Search  ]

Date:  [ Previous  | Next  ]      Thread:  [ Previous  | Next  ]      Index:  [ Author  | Date  | Thread  ]

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



[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




[ Other Periods  | Other mailing lists  | Search  ]