[MUD-Dev] Re: regulating player-created objects

[Marian Griffith]

In <URL:/archives/meow?group+local.muddev> on Sun 10 May, Brandon J. Rickman wrote:
> On Fri, 1 May 1998, Adam Wiggins wrote:

> > On Fri, 1 May 1998, Dan Shiovitz wrote:

> >> [stuff about templates for creating objects]

> > Long quote, but I think all of it is relevant.

> > Actually, now that you mention, Orion and I tossed around this idea a few
> > years back.  The idea was that the basic object types are only shapes.
> > These basic types can only ever be made of one material.  Thus you can
> > determine the number of sub-objects something should have by the number of
> > distinct forms, and the number of distinct materials.  Thus your average
> > axe has two objects: an axehead made of steel, and a shaft made of oak.
> > 'shaft' and 'axehead' are both primitive object forms; oak and steel are
> > two possible materials one can extract from the game world.  We originally
> > came up with this because we wanted an easy way to damage objects in a
> > specific way.  I wanted to be able to burn the axe and have a pile of ash
> > plus a charred axehead.  All objects in the world are defined this way,
> > including creatures.  No object can exist that is not a primitive - all
> > non-primitive objects are just containers for their primitives.  A human
> > would contain a whole bunch of limbs, for example.  A specific limb would
> > contain primitives in the form of a bone, some muscle, and some skin.
> > This makes things like damage a no-brainer.  It also makes it easy to add
> > cool effects like a 'turn bones to adamantite' spell.  Now you get all the
> > bonuses you'd expect from adamantite bones.

> > I see this as being very feasible in a text-based environment, but it
> > would require a pretty serious amount of attention to creating basic
> > objects.  Just getting the thing to a playable point would be a serious
> > chore, but at that point you'd have an incredible amount of freedom with
> > how your objects interact.

> As is my wont, I'm going to problematize this a bit.  This is somewhat in
> the spirit of "What does is add to the game?" and optimizing game
> resources to focus on player interaction and not pure "simulation".  And I
> can already see that my little apology is a bit pedantic, on with the
> content...

> If an #axe_handle and a #axehead are to be made into an #axe you probably
> need some way to join them together: friction, glue, a piece of cloth
> wrapped around the join, &c.  Okay, so you've built any or all of these
> physics into the system.  It seems that object templates must take into
> account the various ways in which component objects can legally be joined
> into new objects.  In some cases, the way an object is made can be
> important to effects on the object: if an axe, made of a shaft and head
> joined with a strip of cloth, is put into a fire the cloth may burn off
> and the axe would fall apart before the shaft caught fire.  This isn't as
> simple as "if one of the components of an object is destroyed, the
> template fails", because a tree-chopping machine (I'm thinking of a big
> wheel with axes sticking out, like something out of the Lorax) can still
> operate at a lower efficiency.  In other words, if you are going to damage
> objects you have to provide a kind of graceful degradation.  This behavior
> is typically foisted onto some dumb object variable which isn't very
> satifactory (if you consider characters who want to build/repair objects
> in a creative way instead of going to some dumb shop). 
> 
> But a far more complicated problem is getting the game system to recognize
> when a collection of components matches a template.  Player intention
> (% build table -> You take a leg... and build a table.) isn't enough,
> because we want to be able to find the functionality of the
> templates in already present world objects.  That big slab of rock over
> there works pretty well as a table.  A bed frame with a board across it
> makes a table.  Three petrified hobbits and a staff stuck in the dirt with
> a door placed horizontally on top makes a table.

In a way this is a problem of how detailed you want your game world to
be. I am all for having more realism in this but we have to be practi-
cal as well.
In this case  you might want to say  for the simplest objects  just what
physical properties would make a good example of it. Things like weight,
dimensions  and perhaps if you want to be that detailed, strengths.  The
last probably is too detailed for practical purposes  already.  Within a
game you rarely would be interested in knowing just how much weight will
cause a table to collapse. At least not often enough to go to the length
of taking care of it.
After you have those basic objects  you simply collect them  and combine
them into a finished object. There is no need to be detailed just how it
is done as the players will not care in the least to be that detailed a-
bout doing it themselves.  They just want to learn a certain skill (e.g.
wood joining)  and a type of object (e.g. a table)  and then be able  to
build tables if they so desire.

The more serious question is of course what use the players are going to
have for tables so they are going to want to build them (and go chopping
up trees for the table blade and legs).

> To identify a template,
> the components don't have to be 'primitive' components, they just have to
> match that component template.  Again, you might need some kind of physics
> in the system, so objects can withstand a certain amount of torque,
> compression, &c.  A stack of peanut butter and jelly sandwiches doesn't
> make a very good table leg.

I guess you are right, but how often is that relevant to a game?  To the
players the only thing that matters is that the axe handle burns and the
axe blade does not,  and that if you trow the thing in the fire  you end
up with a singed blade.  If they head falls off first is of no real con-
cern, the axe is useless in any case.

> The final problem: object templates are not hierarchical.  Let a bed be a
> surface that a person can comfortably lie on.  A table can behave like a
> bed, if it is big enough.  A bed can act like a table, if the bed isn't
> simply a pile of straw on the floor.  This is an area where 3d
> representation actually helps: visually, the player may recognize a table,
> or a bed, or a sacrificial altar without being told "There is a
> table/bed/altar here."

No, it only makes it easier for the player to recognise but the game still
must deal with eachof these objects differently. You do not want to sacri-
fice animals on the bed  any more than you want to eat from the altar. (as
the god that altar was dedicated to is going to be annoyed ;)

> But we need the game to recognize the object
> because the player may try to use it in a certain way.  Or we need the
> game to modify the object in some way so that it acquires some kind of
> functional relevance.  Or we need the game to tactfully inform the player:
> "That is not a table!" 

Indeed. How the object is represented is less important than how the game
thinks it can be used.

> Adam's story about a guy on UO trapping elementals with crates (from a
> different thread) ties into this:  
> >I also thought it was very cool, and the only "realism" problem I see
> >with it is that you can hold back fierce monsters with simple crates. 

> In this case, the game has gotten confused about when crates should be
> considered barriers.  (It could be an mob AI problem too, I suppose.  The
> elementals don't realize they are trapped, otherwise they would smash
> their way out.  But any sufficiently dumb creature could fall for that.)
> One should be able to make a crate barrier, but that doesn't preclude a
> crate from being "something one can climb on top of", if the crates were
> arranged in a stair-step.

I do not really understand what you are aiming at. Building a stair from
the crates is pretty much the same as building any other type of object?

Marian
--
Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...

Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey


--
MUD-Dev: Advancing an unrealised future.