[MUD-Dev] about MOO

[Dan Root]

In message <19991119141422.S25847 at kitenet.net>, Joey Hess writes:
>Dan Root wrote:
>> One significant flaw in MOO is it's use of an entirely memory based
>> system for persistence.  A large MOO can easily be 80 to 200 Megs in
>> memory.  TrekMOO and Lambda both claim those sorts of figures.  How much of
>> this bloat could be avoided is debatable, but the point remains that this
>> can be a serious drawback for using MOO in a environment where growth is a
>> significant meta-goal of the game.  See the list archives for various
>> debates on memory versus disk-based games.  JCL made a particularly
>> informative and persuasive post during one such discussion.
>
>There was once a disk based version of LambdaMOO, IIRC, though it may have
>never really gotten off the ground.

Lots of talk, but I never saw any code, nor anyone who claimed to have it,
other than, as you mention, LPMOO, which is amusing, but not really the
right way to run a MOO.  :)

>Other MOO variaents, like LPMOO, are disk based. There's nothing fundamental
>in the MOO model that requires everything be resident in memory. I've
>designed MOO's that can pull object information out of a SQL database, for
>example.

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.

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

	-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