[MUD-Dev] Objects (was Re: DBMS in MU*'s)

[s001gmu at nova.wright.edu]

On Mon, 20 Jul 1998, quzah wrote:

> 
> -----Original Message-----
> From: s001gmu at nova.wright.edu <s001gmu at nova.wright.edu>
> To: mud-dev at kanga.nu <mud-dev at kanga.nu>
> Date: Monday, July 20, 1998 12:51 PM
> Subject: [MUD-Dev] Re: DBMS in MU*'s
> 
> [Snipped comments from quzah (me) about material types, and objects
>  made up of more than one thing]
> 
> >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?
> 
> That's one of the things I have yet to decide on. I am not sure how to
> do something like:
> 
> Bubba has a bronze longsword. Bubba hears that werewolves can only be
> wounded by silver weapons. Bubba, being the kind who does not want to
> be killed by a werewolf, goes to the silversmith.
> 
> %hold longsword with tongs
> You grasp your longsword with some iron tongs.
> 
> %dip longsword into vat
> You dip the longsword into a vat of molten silver, thus coating it
> with said material.
> 
> Now what? Ok, sure I could just let people not silvercoat their items,
> but that'd be no fun. (Yeah, it's not something that happens every day
> but my *ideal* mud is a place where you can attempt almost anything.)
> 
> So, so the longsword now has the characteristic of being silver coated.
> Its core is bronze, however the outside (visible portions) are covered
> in silver, and you would have no way of seeing the bronze.

I've spent some time thinking about this, and finnaly managed to get
something worked out.  :)  I think you can model this behavior nicely
with a few simple objects/relations.  This assumes an OO approach, and
again, if I had more time, I'd be able to tell you the OO design pattern.
:)

I propose the following class structure:

              Object
              ^    ^
              |    |
      Container    Composite 

Object is your basic object.  It is made of one material type, and has
whatever other phsyical properties you want to model.  The important thing
is that it is made of ONE material.
Composite and Container both add a list of Objects.  For Composite,
those Objects are what make up the new, composite Object, which has a new
function beyond that of its components, but dependant on their existance
(and placement if you wanna model that too). Container's list is a list of
the objects contained.  The Container has its own function, which should
have nothing to do with the objects within.  Depending on the nature of
the Container, you may or may not be able to easily modify the contents.
Compiste does not set a matieral type.. or maybe it jsut sets it to
'composite', whereas conatiner DOES set a material type.

For example, I would model the 'silver coated sword' by making a 
'<material> coating' container, with no entrance/egress.  The space w/i
the container is set to exactly the space occupied by the contents being
coated.  When the werewolf's damage is calcualted, the 'weapon' is asked
"what is your material?"  The container intercepts this message and
returns 'silver', and the damage calculation continues.

This should sound a lot like JC's spoofs, just an implementation limited
to the physical aspects being modeled.

This still doesn't address the larger problem of not modeling emergant
function.  I think it adds a lot to the basic object model, but it does it
by 'faking it', to borrow a phrase form Chris Gray.  :)

> As for the goblet. It would just be a "goblet-item", made up of one 
> piece, which is composed solely of crystal. Crystal would have a tensil
> strength of X, and each action would need to do something like:

<...sample code...> 

> Something like that. You'd need to find some way to determine your noise
> factor, ie: if it is made of glas primarily, then you would hear more of
> a shattering sound than you would a splintering sound from the wooden part
> of whatever.

<OO high horse>
    Model the 'composed of' property with an object.  You ask that object
    its tensile strength, and when it breaks, you ask it for the noise
    description.
</OO high horse>
 
> One piece items would be by far the easiest to deal with, as you wouldn't
> have to thread through the linked list of item pieces (or however you had
> it set up) to determine the resulting sound/effect of the object breaking.

Nod... the base case is always the easiest... and by far the least
rewarding.  :)
 
> My idea is to give every action effects, picking up something would have a
> a very tiny effect on its tensil strength applied to a do_break type of
> thing, it would also have some effect on its contents, [shaken not stirred]
> and so on, depending on each action. -- For every action, there is an...
> 
> [snip]
> >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:
> 
> [snip]
> 
> Yes, and above, the silver coating on the bronze longsword would not
> be able to be disasembled -- So I guess you would need to decide at
> what point in creating/modifying an object, the object no longer is
> able to be disassembled. Also, some commands such as:

See my above comments on the 'silver coated sword' object.
The Container would have to have the get, put, look in, etc, overriden,
but that shouldn't be a problem.  If it was coated with something less
resiliant than silver, say gum, you'll want to have access to the contents
(it shouldn't be all that hard to remove the sword from the gum), but it
won't be as easy as pulling the sword from it's sheath.  Obviously, some
thought needs to go into how you override the verbs, but it shouldn't be
too difficult.
 
> %pry gem from goblet
> You pry a small gem from the silver gem encrusted goblet.
> 
> %look goblet
> The silver goblet is ..blah blah.. however, it seems to be missing one
> of its gems.

Composite objects know what should be in them, and if one item is missing
it should be pretty simple to generate a message like the above.  Think of
a composite as a template, if you will.
 
> I haven't quite decided on how to work with broken objects either.
> Perhaps I'd just create X number of "pieces" from the object. So, an
> axe handle broken in two pieces would produce two small pieces. shrug.

*nod*  That's where my thoughts are leaning, but does it add anything to
the game play?

-Greg