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

[Brandon J. Rickman]

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

I was just considering how an Industrial Age mud might play.  Having
access to machine tooled and standardized parts is not a normal part
of a medieval mud.  But adding some kind of deviation key in addition to
the socket type could disguise this nicely.  For example:

You are trying to build a garden hoe.  A hoe has three parts: a wooden
shaft, a metal handle, and a hoe blade.  A shaft has two male sockets,
let us say Class C Round Socket, and both the handle and blade have female
Class C Round Sockets.

In a standardized world, putting the hoe together would be
straightforward.  But if each socket has a slight deviation from the
standard (not a statistical deviation, but more like small flaws or
special characteristics - a little split in the wood, not perfectly round
- abstracted into a number) then things won't always fit perfectly.

The shaft has two ends, {male Class C Round, 1138}, {male Class C
Round, 76118}.  A handle with {female Class C Round, 65024} might fit on
the second end ( | 76118 - 65024 | < some minimum fit value) , but not on
the first.

So it isn't merely a matter of finding all the right parts, but finding
parts that fit together well.  This is a bit on the micro-management side
of things, where every little component has to be manually or otherwise
evaluated to actually put something together.  A good use for a tinker
skill.
 
> > 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.

Think about scale.  To a mouse, or a mouse-sized man, an "ordinary table" 
may look more like a "rain shelter".  But then in my case it is less
important that the server gets the _name_ of an object correct, more
important for it to get the _implied function_ of the object correct.

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

If an object isn't recognized as a table then it can't behave like a
table.  Perhaps there is a special event when something falls off a table,
a different event than when something falls off a shelf, or out of your
pocket.  (In a traditional MOO setup, tables might "contain" objects, a
particularly horrible but consistent implementation.)

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

But how can the system be made to recognize specifically when a particular
set of physical characteristics fits into a template?  Hmm, this is going
in circles. 

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

How I'm trying to invert the problem: It doesn't matter what the player
sees, but what the system thinks that the player is seeing.  Because the
system has to decide between:

Bubba is holding a loaf of bread.

or 

Bubba is wielding a loaf of bread.

(Does it matter how Bubba's command was parsed, whether he typed
'hold bread' versus 'wield bread'?  Or that Bubba is a known bastard?
That a metal rod has been baked into the bread?)

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

This is a builder problem, and an implementer problem.  Builders can be
notoriously crafty in their descriptions - to know about the runes you
have to look at the altar (sometime the alter), to know about the altar...
- and may not know how to describe something like "an unhinged door".  But
then the implementers rarely provide much in the way of specific style
guidelines for the builders to use.  This problem has carried over into
object based environments, there can generally be only one
name per object, because implementers think that all those messy
exceptions will slow down the code.  ;)

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

When a player types "sleep", shouldn't that be interpreted as "if there is
a comfortable place try to sleep here, otherwise get confirmation"?  And
back to templates and object function, is there not a greater benefit from
sleeping in a bed-template?  Do people only sleep in actual beds, in
actual houses, to avoid being attacked by random monsters?  [If so, do you
not realize how condemning this is of the mud industry?  Hm, I don't have
time to go into an anti-testosterone rant here, and Adam's post certainly
doesn't justify one.]

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

So you _do_ want to allow players to sleep on a table?

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

"quite easy," he said.
 
> > 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.

Some of the latest generation engines.  But I'm also trying to draw some
conclusions about the general trend of high-tech game engines.  The 3d is
blindingly fast (if you use pathetic lighting) but ... there ... is ...
no ... content.  There is no audience appeal.  3D is easy, given the
present computing power.  Perhaps if we even took some of the features out
of the 3d engine and applied that cpu to some kind of usable interface...

- Brandon Rickman
What kind of future was that?