[MUD-Dev] about MOO

[bruce at puremagic.com]

Dan Root wrote:
> In message <19991119141422.S25847 at kitenet.net>, Joey Hess writes:
> >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.

(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?

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.

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

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.

 - Bruce



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