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

[Brandon J. Rickman]

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

Primitive axes are made with a split/forked piece of wood and the head
jammed in the split.  This is the type of axe more likely to be made by a
player lost in the woods, which I would think is a more likely reason for
someone to want to "make" an axe in the first place.

Woods
You are lost in the woods.
There is a piece of metal here.
% look metal
It is an axehead.  On the back you can read the words: "Forged by Chicago
Steel Ltd. Inc."
% get catalog from pack
You take a Sears Roebuck catalog from your pack.
% order axehandle from catalog
You flip through the catalog...
Flipping...
You can't find that item.
% search catalog for axehandle
You flip through the catalog to the index...
Axehandles .. page 83


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

Any kind of template system needs to be very robust and fairly fuzzy.  I
like the idea of standardized sockets, and this would certainly give an,
er, industrial feel to the game.  Can one really not fit a square peg in a
round hole?  In addition to being able to build things in the game, making
non-standard or jury-rigged things would enhance this kind of template
system.
 
> 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?!?!

But such an object could /act/ like a table - you could put things on top
of it, or seek shelter from the rain under it.

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

This is the computer playing dumb.  I would append "one might call it 
a table," to the description.  It is now excessively verbose.

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

I would say you do, because you want the game to understand what you are
trying to do.  If it doesn't recognize the idea of a table then objects
will never "fall off" the table.  (Short of a ridiculous amount of "real"
physics, which in my opinion would detract more from the game in their
misapplication than they ever add in the rare case of an object behaving 
"realistically" - an object falling off of a table.)  Players have an
intuitive sense of function: pointy things are weapons, top-heavy things
can be pushed over.  How can the game sense that which is obvious to the
player?

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

- Swinging doors don't stay open.
- A curtain can act as a door.
- A window can be used as a door.

The function of these different "doors" is clear to the player, even when
the object description is poor.  From the above, an unhinged door can be a
lot of fun for the admins: 'Well, today we got another 3 bug reports about
the broken door quest.'

> [...]
> 
> > 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?

In a very homogenous mud world (which is most of them) yes you can sleep
just about anywhere.  Is this not absurd?  But what is wrong with being
able to find a bed/comfortable place to sleep?  A lake is not a good bed.
The street is not a good place to sleep.  We need to be able to find that
functionality, or perhaps recognize its lack.  Hmm, that is something to
think about.

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

Ok, so what function would the caveman attribute to the table?  Probably a
good shelter from the rain.  And the knight a computer?  Something that
sparks and fizzes when you smash it.  The destruction of objects is tied
into their perceived function as well, as the pieces may be used to build
something similar yet different - a tabletop to a door, curtains to a
dress.

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

This is the illusion of 3d: it is easier to make something look like an
object than to make it behave like an object.  Building things
quickly loses its charm when the objects don't develop their own
behaviors.  I have seen enough super-high-tech 3d game engines (object
oriented! with behaviors!) to say that this is a major problem, that
these simulations lack any kind of large commercial appeal.

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

This makes me wonder why weapons of mass destruction are taboo in muds.

- Brandon Rickman
.sig


--
MUD-Dev: Advancing an unrealised future.