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

[Felix A. Croes]

Hal Black <hal at moos.ml.org> wrote:

> On Wed, Oct 21, 1998 at 10:52:38PM -0600, Chris Gray wrote:
>[...]
> > 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.

There are some good reasons for doing as much as possible in the
mud's internal language.  Most of all, it makes programming simpler,
since the internal language is of course simpler than the powerful
language required to implement the type of server that is being
discussed.  Also, it makes the server itself simpler.  A server
with a lot of hardcoded game support must have a correspondingly
large interface with the internal language.


> Agreed to keep the system-level stuff out of the VM.  But what I would like
> to suggest as an idea would be to have the mud-relevant parts of the native
> mode language compilable to VM code.  And not set the role for the game
> engine to be "VM only".  Maybe some subset of C++ for instance would work
> there.
>   The main reason I'd want to do this would be for performance purposes.
> For instance, if there is an operation that is costly in time that processes
> in-game objects, you are kind of sunk if you only allow VM code to do that.
> What I'm suggesting is interchangable versions of LPC's lfun and efuns, but
> at the object level.  I believe DGD does the opposite of what I'm suggesting:
> compiles Mud-Code LPC to native code.  That would be a good solution also.  I
> don't know how well this would perform, however.

DGD can compile LPC code to C code, which can then be compiled to
native code together with DGD itself.  As LPC is pretty close to
being a subset of C/C++, this is easy to do and results in a large
speedup.  I am not sure what the advantage of compiling C++ to
internal VM code would be.  If the end result has to be VM code,
why not write it in the internal language to begin with?

Felix Croes