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

[Adam Wiggins]

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

As amusing as this exmaple was, I'm confused as to what you're getting at.
Are you saying that my socket definition is too vague, or saying that it
makes sense?

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

Nods - your whole world is made out of tinker toys, leggos, and bristle
blocks.  It may not make perfect sense for every case (especially as your
world's technology level increases), but it should be fun regardless.

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

So?  If you could seek shelter from the rain under it, shouldn't it say
"You see here a rain-shelther."?  IMO it's not the server's job to list
out every possible use for a given composite object.  It *is* its job to
try to consolidate object descriptions by assigning the 'obvious' label to
something.

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

Right.  You could also append, "...and it's large enough that you could
seek shelter from the rain under it, or sleep on top of it."  Where do you
want to draw the line?

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

Huh?

> 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

Hrm, I consider those kinds of physics to be a given.  It's much too
difficult to model a "real"-seeming world without some basic rigid-body
physics; in this case, gravity, but also collision and possibly some
extras like surface friction, angular momentum, and fluid dynamics.  These
things are particularly easy to implement in a text world where you can
fudge things quite a bit.
Figuring out whether an object is going to stay steady on top of another
object is not difficult.  In the shape-based world that I've been
describing in this thread, I'd simply say that you can only set other
objects on top of 'plane' shapes whose size is >= the object's size, and
their chance of falling off is proportional to the plane's angle relative
to the angle of a given vector of force, where the main vector of force
that you are interested in is gravity.

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

Well, that is the idea with templates.  But the labels which templates
assign are just supposed to help classify the world in a way which is
reasonable to the players.  This shouldn't preclude them using the objects
in non-standard ways.  A common example is being able to use any object as
a weapon.  Generally there are certain things that you'd rather use as
weapons since they are more effective (in terms of both wieldability and
ability to do damage), but that shouldn't stop you from beating Bubba over
the head with your loaf of bread.  However, I don't believe that the
server should say, "There is a tasty looking loaf of broad here, which is
also useful for beating people over the head" when you enter the room.

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

Nods...again more ambiguity based on the fact that practially any object
can be used for any function if you try hard enough.  I implemented
swinging doors on a mud once; the open command gave a message like so:

You open the door, but as soon as you let go it swings back closed.

Later, when we had a slightly more advanced character state system, I made
it so that the open command would just leave you holding the door open
until you did something else that required your hands or moved you away
from the door.
This might be slightly confusing to someone, but the words "door" and
"open" still make sense in this context.
The word "door" doesn't make sense, IMO, for a curtain or a window.  Doors
are almost always hinged planes that block entryways until you open them.
This is the 'default' behavior for them, so if you see one that is
behaving this way, you shouldn't get any special message except for "you
see a door here."  Windows are similar.  If either of these things is
lying on the ground in the room, they should give special messages, since
they are NOT behaving in their normal fashion.  Ie, "You see an unhinged
door lying on the floor here."
A curtain, on the other hand, is not so well-defined as to its function.
Normally it covers something, but it can vary - it could cover a window,
or a door, or a dressing area, or a shower.  It is not implictly known
that the curtain forms an egress to another location.  Thus, one should
see "There is a curtain blocking a doorway here." or "There is a curtain
hanging in front of a window here."

To summarize: Templates describe both what an object is constructed of,
and what its implict function(s) are, if any.  Thus a curtain is defined
as a sheet of pliant material connected to some sort of sliding mechanism
(say, rings), but does not necessarily have implict function.  A door is
defined as a rigid plane attached to hinges.  Its implict function is to
stand in doorways.  Any other state should be specifically noted.

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

Erm, I don't find it very absurd.  When I go camping I sleep on the
ground.  If it's warm and dry out, I need no extra equipment.  Does this
mean that the earth qualifies as a bed?  I also have slept at my desk at
work, the computer lab at UCSD, people's cars, people's floors, lecture
halls, and a dozen other places.  The only thing that is really necessary
is that I be able to sit down; I can do that pretty much any place that
contains a semi-rigid surface.

I define a 'bed' as being a bedframe with a matress, a pillow, and a
blanket.  I have never refered to my desk as a bed or my keyboard as a
pillow, even though they have functioned that way on many occassions.

> able to find a bed/comfortable place to sleep?  A lake is not a good bed.

Again, material.  Too pliant, therefore doesn't support your weight.  Good
fluid dynamics should take care of this well (a creature which can float
on water could sleep in the lake just fine); if not, a simple test to see
if the material of the object you're trying to sleep on is not in a solid
state (meaning liquid, gaseous, or plasma) will do the trick quite nicely.

> The street is not a good place to sleep.

It's not a *good* place to sleep for a number of reasons.  One is it's not
comfortable.  This is a material property, just like the lake.  A street
made out of matresses is actually a great place to sleep.  The second
reason it's not a good place to sleep is that it's probably not very safe
and not protected from the elements.  Both of these things have nothing to
do with the object templates; if I built a street in my house, it would be
a perfectly safe place to sleep if not all that comfortable.

> We need to be able to find that
> functionality, or perhaps recognize its lack.  Hmm, that is something to
> think about.

The whole idea with the template system I have been describing is to
*avoid* defining as much functionality as possible.  Leave that to the
players.  We were trying to generalize to avoid garbage like:

> wield hammer
The hammer is a tool, not a weapon.
> sleep on table
The table is not a bed!
> put sword on bed
The bed is not a table!

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

None.  That's the point.

> 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

So he sees, "You see something that sparks and fizzes when you smash it
here."?  No, I think he'd see a several strange metal boxes, one of which
is large and has a colorful piece of glass on the front, another which has
many small boxes on it with strange markings.  This is the advantage of
templates - builders define objects by their components and then give them
general descriptions, so breaking it down into a description of the
objects it is made of is quite easy.

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

Which ones do you refer to?
And yes, I'd say this is a major problem with games these days in general.
People make the artwork and don't bother to make the thing function well,
if at all.  Players get excited when they see it, then quickly bored when
they try to manipulate it.

Adam



--
MUD-Dev: Advancing an unrealised future.