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

[Brandon J. Rickman]

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.  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.  All this physics (I'm not talking about
real Newtonian physics, but whatever mathematical/philosophical system
devised for the mud world) can get computationally expensive.

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."  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!" 

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.

To tie in yet another thread, if the game comes across this kind of
problem that it can't seem to resolve (the elementals have been stuck in
one place for three days) then the admins should be able to invisibly
change things.  In such a case, one might say, "Yes, a crate is a valid
barrier, but there is a certain chance a monster will try to escape and
attack a crate."  This becomes a question of abuse (the actions are bad
for the game) versus exploitation (the actions are novel but shouldn't be
without risk).  As for problems with templates, even a clever human might
fail to recognize how one object may be used in a different way.  There is
a risk of being too confident or too aware of the physics of a game
world.

- Brandon Rickman
I have a .sig around here somewhere.
 


--
MUD-Dev: Advancing an unrealised future.