MUD Design Digest V1 #55

[coder at ibm.net]

This is an old post which somehow never made it out to the list:

The "grid-based mudlib?" thread in r.g.m.lp is turning into one of the
more interesting discussions on parsers, space, and memory:

--<cut>--

Subject:      Re: grid-based mudlib?
From:         mmcg at yoyo.cc.monash.edu.au (Mike McGaughey)
Date:         1996/11/30
Newsgroups:   rec.games.mud.lp

borg at visi.com (George Reese) writes:

>Mike McGaughey (mmcg at yoyo.cc.monash.edu.au) wrote:

>: Sorting out how to do [command propogation] sensibly is considerably more
>: difficult than working out how light or sound should propogate.

>Not at all.  MudOS as used in Lima and Nightmare does not use the
>antiquated add_action() system, and it thus does not tie what commands
>you can execute to where you are.

>Instead, an object responds to user input when that user identifies
>the object as a target of the user's action.  Which objects may
>respond is determined in EXACTLY the same manner as light propogation.

This is quite wrong; you can propogate *nouns* in the same way as you
propogate light, which provides an additional collection of objects which
may be mentioned by a player, but command propogation is a different
thing:

> walk to tree
You start walking south east, towards a tree.

> look at tree
There is a nest in the branches.

> climb tree
You are walking south east towards the tree, but
you are not close enough to climb it.

It's certainly not enough to obtain *all* verb/noun combinations:

> tell george hi.
Told him.

This last example shows where an earlier idea - associating an hypersphere
(what, you have a 7-dimensional mud?) with each
object/verb combination runs into trouble.

Now, I'm sure you're thinking: "`Tell' is just a special case". But it's
not.  Verbs don't have a `radius', or a `line of sight' -
they have conditions under which they can be invoked (object known to
subject, known location, visible, in range, flammable, etc), and *that* is
what determines the verbs available to a player at any given time. 
Furthermore, many verbs exist only to change the condition of the player;
these are exactly the conditions which one would use to give sensible
error messages (and that's how one designs them - and/or stumbles across
new ideas for additions to players):

> climb
You are near the base of a mountain (which you could climb now, using
`climb mountain'), and there is a tree to the south east (which you could
climb if you were close enough, using `climb tree'). You could also
`climb' if you were flying or already climbing on something - which you
aren't.  What did you want to climb?

Notice that dealing with this sensibly using the naive scheme you have
suggested would require every wizard to check every condition which might
affect any action.  In an evolving mudlib, this is a recipie for disaster
(or for looking pretty unprofessional every so often, which is essentially
the same thing).  Examples: adding the ability to refer to objects
recently brought to your attention, or adding simple anaphora to your
parser (both of which are solved by the same mechanism, a short term
memory):

George shouts: Hi
> look at george
You heard George recently, but could not determine where he was.  Earlier,
you saw him on a mountain to the north west of here.  Would you like to
walk there?

> run there
You are running north west, towards a mountain.

So, `command propogation' is intimately tied to what the player can refer
to; visibility is just an aspect of this.  Just because a player moves
around, or loses sight of an object, doesn't mean he `loses' verbs he has
aquired earlier on; they persist for all sorts of reasons - especially for
failure messages.

The limitations of the more usual sort of LP command dispatch mechanism
are particularly noticeable in a mud which implements other sorts of
propogation.  But relying on distances or line-of-sight for commands is
definitely *not* the answer.  The word for the day, children, is
con-tin-u-i-ty.
It's hard to create an immersive experience without it.

Cheers,

    Mike.
--<cut>--

To address some of his examples specifically:

  > walk to tree
  You start walking south east, towards a tree.

  > look at tree
  There is a nest in the branches.

  > climb tree
  You are walking south east towards the tree, but
  you are not close enough to climb it.

Presumably the presumption is that the last response should be:

  > climb tree
  You are walking south east towards the tree, but
  you are not close enough to climb it.
  You continue walking towards the tree to the south east.
  As you reach the tree, you start climb it.

I _can_ do this, but it gets into quite a bit of intelligent coding. 
"Walk to tree" would start a chain of events which gradually translate the
character to the tree.  This is fairly standard.  "Look at tree" operates
pretty standardly, doing standard line-of-sight and distance calculations
to determine what you can or cannot see about or in the tree.  It would
get really cute if a little later on:

  > l at tree
  It looks like someone is trying to hide behind the tree.
  There is a nest in the tree with squalling chicks looking out.

This gets messy because non-tree objects are being reported for a verb
invoked on the tree.  Potentially I can support this however if I ever
figure out a way to do position preposistions ("put the book under the rug
on the table", "hide behind the bush") -- but not having prepositions
done, I'm not sure how...<kof>

Now "climb tree" gets nasty.  If you are too far from the tree to start
climing, _should_ the climb action be postponed so that you /do/ start
climbing the tree when you reach it?  Pushing actions like this out into
the future can get nasty.

Consider the more extreme case:

  > let there be light
  You create the universe.
  > create world
  > create birds'n'bees''n'green'n'crawly things
  You begin creating the world.
  Oops.  Humanity happened.  Cancer is malignant.
  > Kill the putz on the corner of 18'th and Sansome.
  Sorry, he hasn't been born yet.  Waiting.
  Okay, the putz has been born, grown up, and now knows too much about
tootsie
    rolls.
  A putz is approaching you from the souch.
  The putz whacks you with a tootsie roll.
  Oops.
  You are dead.

The real nasties happen when pending actions start conflicting:

  You are on a large grassy plain with a single large tree to the north.
  > walk to tree.
  Okay.
  > climb tree.
  You're not there yet, but will climb it when you are.
  ...
  You are attacked by a troll!
  You kill the troll.
  You are bleeding badly.  You must get help or you will die.
  > walk to healer
  You start walking to the healer.
  The healer is sitting under a (different) tree.
  You start climbing the tree.
  You die.

or:

  > walk to tree.
  Okay.
  > climb tree.
  You're not there yet, but will climb it when you are.
  ...
  You are attacked by a troll!
  You kill the troll.
  You are bleeding badly.  You must get help or you will die.
  > walk to healer
  You start walking to the healer.
  You reach the healer.
  The healer heals you.
  ...many moves later....
  You are on a large grassy plain, with a single tree to the north.
  There are some angry trolls to the south.
  > Hide in grass
  You hide.
  > crawl behind tree
  You crawl silently thru the grass.
  You are behind the tree.
  You start climbing the tree.
  The trolls see you and attack!

Whoops.


Additionally, his point on making verbs available per the personal history
and configuration of the character is a good one, especially the example
with "George".  This has a lot of applicability for me with my
user-assigned names as has been raised here before.  I just don't have a
solution.

- 
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...