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

[Chris Gray]

[Hal Black:]

 >> 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;
 >
 >    player.hits = player.hits - weapon.hits;

Big shake of head. This only works if the data layout of a MUD world
object is defined to be the same as the data layout of your C++ object,
and you always have all of your objects directly available in memory.
When C++ objects have virtual functions (some form of which is likely
needed in a MUD language), I'm not sure if the layout of a C++ object
is even specified. My example does the work needed to fetch objects
'player' and 'weapon' from the on-disk database if needed, fetches
the values of the 'hits' property (perhaps inheriting from ancestors)
from them, then stores the result back on 'player', marking it as
needing eventual flush to the disk. Storing the result back to 'player'
may involve creating additional space in the 'player' object if it didn't
have one before (and was just using one inherited from an ancestor).
This is a very different object model from what C++ uses, but I can
argue that it is more appropriate for MUD world objects.

 >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.

I would argue against doing this. As has been mentioned before in this
thread, and in several others, one of the things you want to do with a
MUD system is to encourage as many people as possible to write scripts,
even simple ones, for the system. That's how you tap into the sources
of originality and artistry outside of the hard-core programmers. Telling
potential scripters "its a subset of C++" will make them walk away. And,
in my opinion, they would be doing the right thing (for them).

For performance, translating from the MUD language to the native language
should work well enough. Note that the cost of many MUD operations isn't
the things like adding integers, it is the many higher-level operations
going on: database activity, string operations, matching, network
operations, etc. As long as the system stuff that glues these things
together is reasonably efficient, the effect of switching between a
byte-code machine and native code isn't really that large. (There are
some things that are compute intensive, and the effect can be quite
noticeable. In my case its fractal terrain generation.)

Since we seem to be aiming for a flexible system here, one of the things
it seems to me that we can *not* do is to force static object layout.
Once you have done that, you have to recompile all of the modules and
rebuild the database in order to make a change. That seems to be
throwing away the flexibility and dynamicism of what I've seen being
talked about.

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