[MUD-Dev] Re: DBMS in MU*'s

[s001gmu at nova.wright.edu]

On Sun, 19 Jul 1998, quzah wrote:

> 
> -----Original Message-----
> From: Adam J. Thornton <adam at phoenix.Princeton.EDU>
> To: mud-dev at kanga.nu <mud-dev at kanga.nu>
> Date: Sunday, July 19, 1998 10:48 AM
> Subject: [MUD-Dev] Re: DBMS in MU*'s
 
[Adam T. on: multiple inheritance... 'glass' from 'fragile']
 
> I am thinking of doing something along the lines of defining the pieces
> that make up the object [perhaps not, as this may be too resource hungry]
> such as, an axe would have a handle and a head/blade. The handle would be
> "made of" a material type, in this case, wood, the blade/head would have
> another material, in this case, hmm.. bronze sounds good. It'll be bronze.

I like this idea better.  Instead of making the matieral the parent class,
make it a property of the class.  This way, it can be changed on the fly,
and you can get away with smaller code (think static instances).  You can
also create a linked list and have multiple material properties.  If I'd
read the Design Patterns book more thuroughly, I do believe I could name
the pattern this fits, but I have had insufficeint time to absorb it
(alas).

I don't see how building objects out of component's answers his question..
what components would you build a crystal goblet of?  How does that
address breaking it?

making the material properties of the object in question a property of the
class (hmm... what coincidence... properties... property... how odd) makes
it simple.  just have the "global" verb methods defined in the base
"generic_object" class, and all it does is step through the list of
material properties and calls the property.<verb> method.  To get magic
effects like "indestructible", you use JC's spoofs to spoof the main 
object and filter all synonyms for 'destroy' verbs.  (btw, JC, you've won
me over on the spoof's idea.  I had decided to *cough* borrow the watchers
before, and had been deliberating on spoffs.  *bow*)

the list also works nicely with a RDB.  Simply define a tweener table that
ties properties to objects.  Or, if you want only one property available
at a time, just add it as a field to the object table.

composite objects would simply implement a 'dissasemble' verb, which
allows you to (with sufficeint means) break a composite into its
components.  'Normal' verbs would simply be passed onto each component:

  >look axe

  You see a small axe, with a wooden handle and a metal head.

  >disassemble axe

  you pry and prod and eventually manage to remove the head of the axe.

  >i

  you hold a wooden handle and a metal axe head

  >build axe from handle and head

  you wield your mighty axe making skill and create a beautiful axe from
  the wooden handle and metal head.

  >break axe

  you (rather unjudiciously) slam the axe around a bit shattering the
  wooden handle and sending the metal head flying.

Short of some titanic force, no unaided mortal will break the axe head,
but the handle is quite breakable.  Now, another can of worms is opened
when I ask, "uh.. what happens to the handle?  is it 2 distinct 'broken
wooden axehandle' objects?"  I choose not to address that, atm.  :)  Words
of wisdom from the peanut gallery?

[...]

If my above ramblings are unclear, or could use some visual clarification,
I can draw up a simple object diagram and sample code and pass it along.
I don't wanna do the Bad Ascii Art, or put the effort into doing a real
drawing, atm.

-Greg