[MUD-Dev] about MOO

Dan Root dar at thekeep.org
Fri Nov 19 14:36:15 New Zealand Daylight Time 1999


In message <16201972205211 at alternaterealitynet.com>, "Ilya, Game Commandos" wri
tes:
>Okay, just a brief inquiry for those of you knowledgeable in this area,
>which I suspect are more than just a few.  Why not MOO?  Meaning,
>it seems a reasonable set of code to start with, even for coding some-
>thing a bit more goal-oriented than it seems it's usually used for.
>
>Are there obvious (or less obvious) restrictions or catches or
>gotchas which should direct one away from serious exploration?
>
>Many thanks to Ian M. who has already given me a very brief
>intro.

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.

Another issue frequently mentioned by MOO softcode programmers themselves
is the lack of multiple-inheritence.  Some people love it, some people hate
it, but in MOO's environment it would make many things a lot easier and
cleaner.  Mixins could go a long way towards reducing some of the bloat in
most of the available core libraries.

There are some other minor gotchas, mostly related to MOO's particluar
model of persistence and 'threading', but those are just that, minor.  All
in all though, the core is really the biggest drawback.  LambdaCore (and
the other common ones, such as JHMCore) is really meant to be a social
community setup.  If you were to write a core from scratch, it would be
about as much work as doing an entire mudlib for something like an LPC or
ColdC server, with no appreciable gains over doing so.

If one particularly liked the model that MOO lends itself to, CoolMUD might
be a better choice.  It lacks a bit of the polish that MOO has developed in
the past 6 or 7 years, but the language is still very similar, and the
server is generally better as a whole.

	-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



More information about the MUD-Dev mailing list