[MUD-Dev] Re: generic objects, behaviors

[Jon A. Lambert]

> From: Andy Davidoff <dert at pobox.com>
> 
> hi :)
> introduction to follow in a bit, i want to catch up with the archives
> first.

Hi, lots of great ideas here.  I think many of these can be classified
into categories and many might easily be implemented with some
reusability.  

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

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

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.

Let me attempt to break up your ideas into edible pieces.  
> agreed:
> i want a player to be able to fill a bucket with water from a river,

This is a traditional container thing.  Mostly handled in many muds.
However the river is an interesting case.  River is a supplier of water,
Forest is a supplier of wood, etc.  Descriptive writing of locations 
might indicate many of these supplier objects abound but its often
frustrating for a player who would like to effect a change:

You are standing in the middle of a dark forest.
>cut down tree
You don't see any tree here.
 
> suspend it over a couple of logs, 

Relative location handling.  We have a thread going on this.  ROM 2.4
makes an attempt to handle this with its furniture flags.  Not very
satisfactory but its a start.

> light the wood on fire, and boil the
> water out of the bucket in the form of steam.  i want the player to be
> able to cook, freeze/boil liquids at varying temperatures, crack glass
> with temperature change, & toss scalding hot liquid onto an enemy.
> i want a bucket of sea-water to boil off leaving a residual crust of salt.
> 

Object transformations.  Fire --> ashes and heat.  Water + heat --> steam.
This reminds me that temperature changes are not handled very well.
Are these objects or forces?  How localized are their affects?
Perhaps they can be fitted into my assembly/disassembly model above?

> i want a player to be able to buy a ball of string, enter a forest while
> trailing the string, and find his way out by rewinding the ball.

These appears to be a difficult one.  You have a ball which is in the 
process of being transformed into a line.  Considering many of us 
have locational based systems, you have an object that spans
multiple locations.
 
>  i want
> him to be able to add more string to the end of a line, and i want
> the enemy hunting him to be able to light the string on fire, or pull
> it out of the forest, with or without his quarry on the other end.
> 
More of same, plus you have an object that can be cut up into
smaller objects of the same type or made larger by adding more
objects of the same type.

> i want a player to be able to fill a bottle with oil, insert a rag, light,
> and toss onto an attacker or building.

An assembly.

> i want the building to burn.
> i want the resultant landscape to reflect the event. i want a forest
> to regrow after a fire. i want nearby villages to plant crops, harvest,
> etc.

Locations become a collective set of objects which affect/effect the
description of the location.  Many of these objects are supplier objects.
This requires an entire different approach to "building" I would
think.

 i want fire to make smoke. i want smoke to follow the wind. i
> want wind to follow the terrain, weather to be shaped by the land &
> seas. i want days to vary in length with the changing of the seasons.
>

Smoke and smells propagating and dispersing across the mud.  This
probably isn't too difficult to do in current muds.  It has some similarities 
to the string ball above.

Weather affecting terrain formation.  Hmmm.
 
> i want a player to be able to carve blocks of ice from a frozen lake
> for the construction of a functional igloo, or an ice-fishing hole.
> i want a player to be able to ski/sled down snow-covered mountains,
> melt snow for water, have a snowball fight, & follow footprints in snow.
> 
Supplier objects and assemblies.  Resulting built objects have an effect
on locational descriptions.

> any of these things are doable in diku, but in my mud i want objects
> to behave the way they do because it is their very nature to do so, not
> because someone spent 6 months writing a million lines of special
> procedures &/or user code to accurately model each and every possible
> scenario and circumstance. IMO this is the easy/fun stuff, however...

6 months? Yes probably more.  I don't think this would involve nearly million
of lines of code though.  With a proper server framework supporting this
kind of creativity, I would think most of time would be spent in actually 
"building" this environment.

JL


Some are born to sweet delight, some are born to endless night