MUD Design Digest V1 #55

[Chris Lawrence]

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 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: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...