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

[Brandon J. Rickman]

On Sun, 10 May 1998, Marian Griffith wrote:
> In <URL:/archives/meow?group+local.muddev> on Sun 10 May, Brandon J. Rickman wrote:
> > 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.
> 
> In a way this is a problem of how detailed you want your game world to
> be. I am all for having more realism in this but we have to be practi-
> cal as well.
> In this case  you might want to say  for the simplest objects  just what
> physical properties would make a good example of it. Things like weight,
> dimensions  and perhaps if you want to be that detailed, strengths.  The
> last probably is too detailed for practical purposes  already.  Within a
> game you rarely would be interested in knowing just how much weight will
> cause a table to collapse. At least not often enough to go to the length
> of taking care of it.
> After you have those basic objects  you simply collect them  and combine
> them into a finished object. There is no need to be detailed just how it
> is done as the players will not care in the least to be that detailed a-
> bout doing it themselves.  They just want to learn a certain skill (e.g.
> wood joining)  and a type of object (e.g. a table)  and then be able  to
> build tables if they so desire.
> 
> The more serious question is of course what use the players are going to
> have for tables so they are going to want to build them (and go chopping
> up trees for the table blade and legs).

I have two answers for this.  The first is a a real-world answer: building
things (tables, houses, bridges, canals) is a pretty fundamental human
activity, an activity that is much less removed from the daily lives of
those dealing with physical challenges to their survival (i.e., during the
Middle Ages; the American Old West and other frontier struggles;
futuristic space colonization).  The idea of "building a community" can be
a fairly literal concept, and without a sense of community investment (the
time spent to build things) there may not be much commitment.

The second answer is specific to the implementation.  If a game allows 
wood joining but provides no occasion to use the skill then it is a waste
of effort.  Presumably the skill is in the game for players to use in creative
ways.  How sophisticated the implementation is depends on how you want
your players/game to perform, which certainly doesn't _have_ to focus on
player built tables.  "[T]aking care of" the more complex details isn't
important if you are really strict about what players are allowed to
do/create.

(My interests on this list deal with ways of implementing muds that are
tightly focused on the experience of the player/participant.  The issue is
not for the player to understand what is going on in the mud world, but
for the mud world to understand what the player is trying to do.  The
weakest kind of interactivity is where the player is explicitly told all
the commands up front.  Revealing nothing to the player is bad as
well.)

> > compression, &c.  A stack of
> > peanut butter and jelly sandwiches doesn't 
> > make a very good table leg. 
> 
> I guess you are right, but how often is that relevant to a game?  To the
> players the only thing that matters is that the axe handle burns and the
> axe blade does not,  and that if you trow the thing in the fire  you end
> up with a singed blade.  If they head falls off first is of no real con-
> cern, the axe is useless in any case.

It isn't always relevant to the game, and that is a problem with the game
- it doesn't understand the activity.  If there is a fire, and a command
to burn things, then you'd expect 'burn axe' to behave as above.  This can
be coded for a specific case, but it usually isn't. ;)

> Indeed. How the object is represented is less important than how the game
> thinks it can be used.

That is a perfect summary of what I was trying to say.

> > 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.
> 
> I do not really understand what you are aiming at. Building a stair from
> the crates is pretty much the same as building any other type of object?

Crates stacked one way may be a wall, and crates stacked another way may
form a stairway.  In the case of UO, the behavior of crates is very rigid.
They do not behave like building blocks.  (Or maybe they do, I have no
first-hand knowledge.)
 
- Brandon Rickman
I think I lost my .sig



--
MUD-Dev: Advancing an unrealised future.