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

[Adam Wiggins]

On Sat, 9 May 1998, Brandon J. Rickman wrote:
> On Fri, 1 May 1998, Adam Wiggins wrote:
> > 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.
> 
> 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

Hrm - that's adding in a whole 'nother layer.  I like it :)
Of course, it's a pretty complicated layer.  I was assuming that the
shapes would have basic "socket" types, allowing them to be composited
together with shapes that fit into that socket.  This allows you to avoid
going into detail about *what*, exactly, is holding that axehead in place.
Ie, an axehead has a cylinder socket.  A wooden shaft has two cylinder
ends.  This of course, also begs the question of whether you want to store
orientation data for the composited objects, or if they just get shoved
together into a big mush.

> 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",

That's what I was intending on.  An 'axe' template is defined by an
axehead connected to a shaft.  If the shaft turns to ash, it becomes a
pile of ashes which is not a valid component of the axe, and the axe
object disappears.

> 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

Yeah - this is where extra data like orientation would come in handy.
We never planned to take it this far, mainly because the world we were
trying to model at the time didn't have anything this complex anyways!
However, now that I think of it, your tree-chopping machine should work
just fine.  Moreover, a player could easily turn it into an paddling
machine by just pulling out all the axes and inserting a bunch of paddles,
or a tennis-playing machine by inserting tennis rackets, or a fan or
whatever else you want.  The 'work' in the system would be defining the
components (in this case, the spinning cylinder to which all the sockets
belong).  From there players could do whatever they like.
If there were special-case templates which were too complex to be (easily)
handled by this, some special logic (soft or hard code, doesn't matter)
could be inserted to handle it...although I'd stay away from anything that
requires this sort of complexity, since the whole idea of this system is
to avoid special casing like this.

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

Yup.

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

Um, for purposes of what we're discussing, they do NOT make a table.
I would be quite confused if I saw:

> n
Dirt Field
There is a table here.
> l table
The table is made of three people and a staff with a door across the top.
> say wtf?!?!

I would much rather see:

> n
Dirt Field
There are three people and a staff support a piece of wood with a knob on
it.
>

Remember, the whole *purpose* of the templates is for identification.
Rather than telling people every time they see a table that they are
looking at "Four wooden legs supporting a flat piece of wood", they
just see a wooden table.  The templates do not necessarily identify
function - I would assume that, if you had rudimentary physics in the
world, you can easily place objects on any flat surface and expect them
to stay there.  You don't need an object template for that, nor do you
want one.

BTW, I'm assuming for the same reason that a 'door' is defined as a wooden
plane (possibly include a knob, or knocker, or handle) attached to hinges
and set in a doorframe.  This is to avoid the confusion of:

> l
You are in a room.  There is a door here.
> open door
You push the door around a little bit.
> enter door
You crawl under the door and try to hide.
> say wtf?
> l door
The door is a piece of wood with a knob attached.
> bug The door in this room doesn't work!!!

Now, users able to name things anything they want (I believe I've detailed
our system on this several times before), you could get a situation like
this:

You place the piece of wood on top of the three poeple and the staff.
> smile
You smile.
> name three people+staff+wood "a table"
You will now refer to the three people, the staff, and the wood as "a table."
> l
You see a table.

Of course, to someone else's perspective:

> n
Dirt Field
You see three people and a staff supporting a piece of wood with a
doorknob on it.
Bubba the Troll is standing here.
> say hey bubba, what's going on
Bubba says, 'Check out my new table.'
> peer
You peer around.
> say table?  you mean this thing?
> point wood
Bubba nods, 'Yeah.  My table.'
> roll
You roll your eyes.

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

*shrug* Server side computations never worry me.  If it's commercial, I'll
just buy more processors or more machines.  If it's a hobby thing, then
I'll limit the number of players or size of the world to match whatever I
have at my disposal.

But yes, some simple physics to keep totally ridiculous things from
happening is not hard.  From the start Orion's combat stuff allowed you to
use any object you wanted as a weapon.  This meant storing things like the
malleability of the object to make getting hit with a club much less fun
than with a nerf bat.  I would assume similar checks would be made on the
materials used to build something.

You could probably tell how much physics you're going to need based on
what kind of relationships you're going to allow.  There's the very simple
'support' relationship we are discussing here.  (Note that relationships
do not, and shouldn't, have to be restricted to templates.)  Thus a table
leg made of tin will bend under a certain amount of weight, that number is
just different from the amount of weight (stress) at which the PB'n'J
sandwhich is going to bend.

> The final problem: object templates are not hierarchical.  Let a bed be a
> surface that a person can comfortably lie on.

By that definition, practically anything in the world is a bed.  If we're
going to use definitions that broad, what's the point in having templates?

> A table can behave like a bed, if it is big enough.

Again I think it should come down to 'what do I see when I walk in the
room'?  A table is not a bed, from this standpoint.

Note that you can handle different folks (from different upbringings,
probably) have different familiarity with different templates.  A cave man
might not know what a table or a bed was, and so when walking into the
room would just see strange contraptions of wood and metal.  Ditto for a
medieval knight seeing a computer.

>  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

Right - that was the whole point with templates, was trying to lump things
into categories for purposes of display, while still retaining the
'atomic' functionality of the components.  As I mentioned before in this
thread, if you have a 3d view the need for that starts to disappear.  The
great thing would be that players *could* build brand new things by
attaching materials to other materials (no need for sockets, really) in
whatever they configuration they wanted.  If they were good they'd produce
something which other players would recognize as serving a specific
function, as well as actually serving that function.

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

I would definitely want to avoid that.  What does the game care about what
is defined as a table?  As you said before, it's just a flat surface.  You
can set things on it, just like any surface.  If the physics are descent,
it will only support so much weight before the materials start to buckle.
Nowhere in there does it care that it's a table, a bed, an altar, the
ground, a big rock, or anything else.

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

Nods - being able to destroy any object and get the result you expect is
one of the main benefits of the template system.  UO could not do this,
really, because they need new art for the 'ruined crate'.  When someone
destroys a template crate, they are left with a description of some ruined
boards in a pile, generated by the system - a luxury of using text instead
of fixed 2d artwork.

> There is a risk of being too confident or too aware of the physics of a
> game world.

Many folks believe that the sentence is equally true if you remove the
word 'game'.  Ie: is being able to split the atom a Good Thing?

Adam




--
MUD-Dev: Advancing an unrealised future.