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

[Adam Wiggins]

On Sat, 23 May 1998, Brandon J. Rickman wrote:
> 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.

Hrm...yes, one could certainly do something like this.  I don't see it
adding much at first glance; probably the best effect would be:

% skill woodcarving
Your skill at woodcarving is poor.
% carve shaft to fit axehead
You begin trying to make the end of the shaft fit into the axehead's
socket.
[...]
You finish your work.
% fit shaft into axehead
You shove the shaft into the axhead's socket.
Hmmm, it seems pretty loose.

A person with a good woodcarving ability would get a "The fit is perfect!"
message and would have much less of a chance of the axehead flying off in
the middle of combat.

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

Ah, but we've had some good discussion of this...

I would postulate that if I can see enough of the object, I can classify
it regardless of scale.  I table does *not* look the same as a shelter to
me, regardless of size.  Tables have certain traits - beveling on the
legs, smoothly finished tops, perhaps fold-out sections or other table
features.  A shelter may have similar components, but they will most
likely not be made the same way, unless it was made out of material that
originaly came from a table.  Now, for the purpose of the system, we are
ignoring these differences.  But the high-level result is that templates
simulate this data.  From the code standpoint, my character recognizes the
table because it is a table template.  From the player's point of view,
they recognize it as a table and not something else because of all those
little features which we associate with tables but not with rain shelters
or beds or anything else.  This is why I think it makes perfect sense to
have poorly built objects less recognizable.

At some point you cease to be able to make out enough detail on the object
for you to be able to tell it's a table.  Either it gets so big that
you're only looking at a small part of it at any one time, or it's so
small that you can't discern the details.  Either way it should be
replaced with an ambiguous description, with the option to examine it
closer in order to attempt to recognize it.
Ie:

There is a small brown speck on the floor.
% exam spec
On closer inspection, you realize it is a miniature table.

or:

A black shape looms in the sky.
% exam shape
You step back to try to get a bettter look at the shape.
You realize that it is a Q'lonian mothership.

> important that the server gets the _name_ of an object correct, more
> important for it to get the _implied function_ of the object correct.

Yeah...I suppose this is where the ambiguity comes in.  I'm kind of
pushing both of these things together into a single lump.  For something
like a table or a bed this seems to work, although I wonder if there would
not be problems with other objects that I haven't thought of yet, due to
this lumping.

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

You're right.  In a nutshell:

- There is a list of materials (oak, iron, flesh, water, diamond..) which
the basic shapes in the world can be made of.  The shapes consist of
simple geometrical objects such as planes, cylinders, spheres, domes,
wedges, and so on.  The more basic shapes you define the easier it will be
to form simple and obvious templates, but the less flexible and extensible
the system will become.  This is the choice between having an axe template
use an axehead and a shaft, or using a wedge and a cylinder.  In the
second case some subclassing would be necessary (depending somewhat on the
game world and method of display), to indicate the difference beweteen a
doorstop and an axehead.
- Templates are a list of shapes containing data about how they are
connected to one another, and how they are oriented in relationship to
each other.  They also define the obvious function (and therefore, name)
of the object.

Personally, I would prefer to go for the more open-ended system.  An axe
template only gives the object its name and possibly stores some
wieldability values based on the skill of whoever constructed it (ie,
balance and grip).  How it actually damages things is based on the physics
of the wedge impacting other surfaces.  By the same token, objects can
rest on any plane given the proper friction-to-angle of incline ratio.
The fact that said flat plane is raised off the ground on four legs is
only a convenience for characters; if the plane was resting on the ground
it would still function identically, it would just be less useful as you'd
have to bend down to interact with the objects upon it.

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

Nod - which is why I like to sidestep this issue altogether.  Bubba has a
loaf of bread in his right hand, and that's all players see when they look
at him.
However, I suppose it would be perfectly reasonable to assume that there
is a difference between a fighting grip (holding it near the base for
better swing leverage) and a normal grip (holding in the center for ease
of balance/support).  Thus:

% i
You are holding a loaf of bread.
Boffo attacks you!
You shift your loaf of bread into a fighting grip.
% i
You are wielding a loaf of bread.

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

Once again, this is part of the point of templates.
Builders do not make objects and assign them a string of "a large oaken
door".  Instead, they load up a door template, set the plane component to
be made of oak, and modify the size of the door until it appears "large"
to the average-sized player.  They add "unhinged" by simply remoing the
hinge components.  They cause it to display "is on the ground here"
instead of "is here" by simply placing it on the ground instead of placing
it in a doorway.
I imagine it would be nearly impossible to make templates work the way
I've outlined if you allowed builders to just name objects anything they
wanted.  This is, of course, extremely unsuitable for a mud which promotes
user-building, or a mud which wishes to contain silly locations and
objects.  It IS suitable for a "realistic" mud - ie, one where the
implemtentors wish the game to be more like a consistent and believable
world and less like a beefed up Zork.

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

Hrm, I suppose it depends on how much you want to automate.  It seems
reasonable if not completely user-friendly to just have them plop down on
whatever surface they happen to be standing on (ie, the ground) if they
type "sleep", or more reasonably "lie down".  If they specify a location
they will sleep there instead.

However, if you *did* want to insert this sort of semi-smart command
handler, I'd want to keep things atomic.  When responding to "sleep", the
command handler would search for the nearest flat surface of the
appropriate height, with a pliancy value as close as possible to that
character's ideal pliancy for sleeping surfaces, that was large enough
to hold their prone form, and which looked sturdy enough to support their
weight.  By the same token, droping an object would cause the command
handler to search for a flat surface large enough to hold the object, near
as possible (in x, y, AND z) to the character's hand, and which looked
sturdy enough to hold the object.  As it just so happens, most tables are
built to fit this list of criteria very closely, so normally if there was
one around you'd end up dropping the object onto it.

> back to templates and object function, is there not a greater benefit from
> sleeping in a bed-template?

This goes back to what I mentioned early about how much functionality
should be defined by the template, and how much should be extracted from
its components.  Ideally, you'd want as much as possible to come from the
compoents - a bed is consider 'good' if it has a flat surface of the
proper pliancy and is the proper size a strength to support the person who
wished to sleep upon it.  For more complex objects, I could easily see
adding extra parameters to the template (like wieldability values for the
axe that I mentioned above).

>  Do people only sleep in actual beds, in
> actual houses, to avoid being attacked by random monsters?

People sleep in beds because they are comfortable.  People sleep in houses
because it protects them from disturbance by noise, weather, and other
humans (regardless of their intent).  So I guess the answer is, sort of.

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

Seeking protection from adversity is not something that I find very
related to any particular hormone.  Of course, I also don't consider
testosterone to be the horrible, vile substance that many nowadays seem
to.

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

Absolutely!

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

Heh, well I should say that once you have all the OTHER stuff in place
(which is no small feat), that part is the "easy" part.  Very little that
is discussed on this list is truly easy to implement.

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

There's much more to it than simply getting enough CPU time.  Designing
that interface and then implementing the hardware to make it work is
something many have aspired to but few (none?) have succeeded at.  People
still prefer mouse+keyboard to play Quake, which has *extremely* simple
interaction with a 3D world.  And the mouse+keyboard interface is still
inadequate!  Now consider a world where you can actually interact with the
environment in ways other than shooting...

But yes, I agree.  Good graphics are not the problem: graphics getting
ahead of the interface is a SERIOUS problem.

Adam