[MUD-Dev] about MOO

[Dan Root]

In message <199911201824.KAA31012 at portland.puremagic.com>, bruce at puremagic.com 
writes:
>Dan Root wrote:
>> This is quite true.  However, the question was opinions on MOO (in
>> particular, LambdaMOO) and why it would or wouldn't make a good basis for a
>> game if one wrote a core that was biases towards more goal-oriented game
>> play.  As it stands, stock LambdaMOO keeps stuff in memory, which can be
>> rather expensive if you assume the traditional style of 'one room, item or
>> mob to one MOO object'.  An object in MOO has a lot more overhead in terms
>> of data items stored for things such as owner and permissions than in a
>> server like Diku.  And even with inheritence for the all the private data,
>> that's a lot of space, memory-wise.  I've heard rumors of core systems that
>> were written to keep large amounts of 'game items' in a single MOO object,
>> but was never able to lay hands on one.
>
>(About objects that keep a lot of objects in a single object) Why should
>you compromise the design of your system to make up for a failing in the
>base architecture?  Why not just use something with a better base
>architecture?

Indeed, but as you mention below, one of MOO's strengths is that it's got a
rather large base of people who know the internal coding language and have
a fair grasp of how the system works overall.

>As for nothing being written in MOO that would be impacted by switching to
>a disk-based mechanism, I think that would probably prove to be incorrect
>if you were aiming for a high-performing system.  Keeping trace of the
>size of your cache (in your head as you design), and how the object access
>patterns you are creating will load or unload large amounts of objects is
>importnat to do.  If you have a system that requires a large number of
>objects to be loaded to read some properties from them, or to execute a
>method on them, you'll be creating a lot of disk I/O and will slow the
>system down.  Imagine getting a index of mail messages in a mail folder.

CoolMUD's database does this, and seems to do a pretty decent job.  That
said, more than something like a mail index, the place you'll lose most
heavily is on MOO's inheritence.  Most game cores (Lambda and JHM both
suffer from this) have a fairly deep and sometimes rather broad object
inheritance trees.  It's possible to have a siginificant portion of your
cache filled with nothing but items that are inherited in your active
objects.  

OTOH, it's certainly possible to cache quite a bit and still see a
significant reduction in active memory usage.  LambdaMOO was using upwards
of 256 megs of memory at one point, and I'm sure that number isn't going
down.  If even 1/10th of your objects were simultaneously active, and that
many more needed for the inheritence of the active objects, that's still
reducing your active memory image by nearly 4/5ths.

And that doesn't even begin to deal with things like storing and caching
things at a per-attribute rather than per-object level, which may or may
not increase performance.

>> I would love to see someone take MOO and add a nicer database layer to it.
>> Then all you'd have to add in would be CoolMUD's dictionary/tables, object
>> based security and YO protocol, and you'd have a very nice server overall.
>> (An alternative method to get the same effect would be to add MOO's
>> persistent processes and 7 years worth of language syntatic sugar to
>> CoolMUD.  Both alternatives produce approximately the same result).
>
>Or, you could start with Cold and add persistent processes and be done.
>YO-style stuff can already be written in Cold inside the DB rather than in
>the driver.  That said, I'm moving on from Cold to something newer.

The downside to this is removal of the MOO-based language that Lambda and
CoolMUD share (more or less).  ColdC is nice, but by virtue of being a lot
more powerful and expressive, somewhat harder to use.  And again, you lose
your audience of MOO-capabale programmers.

My first reaction to ColdC was to see syntax constructs like 
 	(| [(> s <), 'si] |)
and think, "What sort of emoticon is that, a demented clown wearing a
balancing a traffic cone on his head?". :)   Not precisely what one would
call a friendly language to a fledgling coder.

Cool and MOO's languages are not quite identical, but close enough that
anyone using one can use the other, more or less.  The primary differences
are around the features of the languages.  Cool has tables/dictionaries,
which MOO doesn't, so MOO makes up by having some more powerful list
manipulation features instead, as an example.

>MOO's advantage as I see it is in the number of people who have heard of
>it and can work with it, and the presence of a really cool DB in the Jay's
>House stuff.  CoolMUD has a nice driver, but no one who has used it and no
>available DBs that I've ever heard of.  Cold is fast and has a fairly good
>driver, but while the DB is large and complete, fails to be consistent in
>a number of areas internally.

Lacking a good core DB is definitely a problem for many game drivers out
there, Cool being no exception.

Heck, UberMUD would still be a decent system with the addition of a nice
core DB.

	-DaR
--
/* Dan Root   -   XTEA cipher */  static unsigned D=0x9E3779B9,l=0xC6EF3720,s;
/* t=64bit text, k=128bit key */  #define m(x,y) ((x<<4^x>>5)+(x^s)+k[s>>y&3])
void enc(int*t,int*k){for(s=0;s!=+l;){t[0]+=m(t[1],0);s+=D;t[1]+=m(t[0],11);}}
void dec(int*t,int*k){for(s=-l;s!=0;){t[1]-=m(t[0],11);s-=D;t[0]-=m(t[1],0);}}



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev