[MUD-Dev] Re: generic objects, behaviors

[clawrenc at cup.hp.com]

In <199705112319.SAA13451 at dfw-ix1.ix.netcom.com>, on 05/11/97 
   at 04:24 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:

>> From: Andy Davidoff <dert at pobox.com>

>> 
>> :I really want to to make objects generic.  I want some player to be
>> :able to take some clothes, a couple branches and a broomstick, make a
>> :scarecrow, cast a spell on it to animate it, and Voila!  Have a
>> :mobile.  I want a player to be able to take a couple pebbles, put them
>> :in a small box, seal the box, and instantly have a rattle.  It this
>> :interpretive behaviour of objects that I think is the *real* key.
>> 
>I would call these types of objects Assemblies, some might call it 
>aggregation.   A key question for implementation would be whether you
>allow the player complete creative license here?  Or attempt to 
>force a thematic consistency?
>
>For instance might I chose to build the "scarecrow golem" above by
>assembling a red rubber ball, a wooden pencil and animate spell and
>label or otherwise describe the final product as a "scarecrow golem"?
>Might I also use the exact same components to produce the rattle?
>Would other players be able to create the exact same assemblies
>through the use of completely different components?

Using the aggregate model, a possible solution is to have a "virtual"
golem type which defines a list of needed component body parts.  The
user then assembles a potential golem body out of parts and points the
virtual golem object at it.  The virtual golem object then attemots to
satisfy its internal list (and relative placements) of body parts (the
ball for the head, the pencil for the body, etc), and if successful in
populating its entire body part tree, gestalts into a real golem
instance.

Neat.  I like this idea.

If you wish to enforce some sort of thematic consistancy you could
have the virtual golem object restrict the list of objects that can be
used for various body parts (yes, a pumkin will make a head, but a
pigs bladder won't, nor will a mushroom).  

>I don't tend to like this approach so let me propose something a 
>little different.  I prefer a top down approach where the assembled
>object  is designed first much like any other normal object.  Any
>object may or may not have an abstract object called an assembly
>object  associated with it.  There are two types of assemblies, those
>whose parts  form a whole object which can be disassembled into
>component pieces  and those which cannot be disassembled into
>component pieces because a transformation has occurred to the
>components to form the assembled object (ala chemical reaction,
>etc.).

Nod.

>The "scarecrow golem" object's associated assembly object would
>contain two lists of assembled/disassembled components, two lists of 
>assembled/disassembled skills/spells and various attributes relating
>to  stability and transformation costs.  This object has two primary
>methods  assemble and disassemble.  Assemble checks to see if all the
>requisites are met and handles creation of the new object and
>destruction of the  components.  Disassemble handles the opposite
>changes.

Yeppirs.  I have a feeling this could also be a generic solution model
for anonymous groups (there are fifty balloons here, there a group of
orcs, etc).  Just have various virtual aggregate objects which attempt
to be applied to the current environment...

Essentially it means reversing the question from, "I have a bunch of
objects, do they make a group?" to "I have a bunch of possible group
types, which one applies to the current situation?".  Of course it
also means a lot of optimising as you can't have every group
considered for every view.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...