Issues from the digests and Wout's list

[clawrenc at cup.hp.com]

In <199704170238.CAA492348 at out1.ibm.net>, on 04/16/97 
   at 10:51 AM, "Shawn Halpenny" <rsh at dos.nortel.com> said:

>On Apr 10,  6:57pm, clawrenc at cup.hp.com wrote:

>>>One of the things that were not discussed at length is the
>>>issue of parsing and handling user input.  Could you comment on
>>>that too? 
>>
>> <shake head>
>>
>> The only outstanding one I can remember here is suggesting
>> command compleation ala:
>>
>>   > get bag
>>   Do you want the:
>>     1 -- Mouldy sack
>>     2 -- Paper bag
>>     3 -- Leather satchel
>>     0 -- Cancel command
>>   >> 3
>>   You take the leather satchel,
>>
>> I currently do this, with caveats for nested compleations,
>> multiple character support (multi-playing) and priority
>> interrupts.

>I remember a posting to one of the ng's a while back in this vein,

Yup, probably me with Orion Henry.  I seem to be this feature's only
champion.

>...and I wondered then, as now, what happens if the poor sod who just
>typed "get bag" and was suddenly attacked by UggUgg.  

These are the priority interrupts I mention above.  I'll quote from
the old list and the discussion with Orion:

--<cut>--

I also allow the user to enter commands which bypass the filter and
head straight for the parser without the extra processing.  This
allows:

  > get bag
  You are attacked by the Kobold!
  Do you want the:
    1) Red bag
    2) Tattered paper bag
    3) Mouldy sack
    0) Cancel command
  The kobold hits you with his club.  That hurt!
  >> !! retaliate                // "ret" would have done as well
  You attack the kobold.
  The kobold slams his head into your stomache.  Ouch!
  The kobold blocks your blow with his shield.
  >> !! ret with ls
  You attack the kobold with the longsword.
  Your blow chops the kobold's arm off!
  The kobold drop his shield.
  The kobold's club crunches into your shoulder.  You moan!
  >> 2
  You take the tattered paper bag.
  Your weak lunge misses the kobold.
  ...etc.

Aside: I *REALLY* dislike combat systems where the attacked player
automatically begins retaliating/fighting without an explicit command
to.

--<cut>--

>Will the parser
>still be waiting for a response of 0-3?  

Not exactly.  What has happened is that a filter has been inserted
between the player and the game.  The job of the filter is to resolve
the abiguity, or abort.  Normally all commands go thru and manipulate
the filter.  !Commands just bypass the filter without actually
affecting it.

This gets really messy when the player is controlling multiple bodies
simultaneously as you can get multiple stacked prompts for multiple
bodies.

>Or if a response of anything
>_not_ 0-3 fails the get command without notification, executes the
>just-typed command "c superkill UggUgg", and then returns to the base
>state of waiting for any command?  I'm leaning toward the latter,
>since IMO forcing a reply of 0-3 makes the interface work against the
>user in cases like above.

I also expect to have a null return (blank command) abort the filter.

>> >3) Skills and skill trees.
>>
>> Nathan: I like your recent comment on flat trees without
>> pre-requisites (eg anyone can *try* to fly, it just won't work if you
>> don't have wings/rocket assist etc)  Care to expand?

>Related to this vein, I'm moving towards a model where there are no
>skill sets, really, just commands bound to particular objects which
>can be added or removed from a character's immediate environment
>(inventory, equipment, body).	

This is exactly the approach that MOO (I think Tiny* too) and its
descendants take.  The verb "drink" is bound to the cup, not the
player, and "get" to the sword, rock etc.  LP also used to do this. 
There are a LOT of advantages.  The problem is for verbs which should
be resolvable anywhere:

  > i
  Cup of water
  > drink
  You drink the water.
  > give cup to Bubba
  Okay.
  > drink
  Huh?

or:

  > get rocket
  Okay.
  > fly
  You fly...
  > drop rocket
  Okay.
  > fly
  Huh?

The only solution there is to bind "drink" et all to the player
objects (or something that all players always carry).  Drink then
resolves on the player, and the verb then goies out looking for an
object to satisfy.

It can make for an expensive parser.

>>>4) Rumors.
>>>* Decaying rumors.
>>>* "Alerting authorities".
>>
>> We definitely need to get back into this.
>
>I have thoughts on this, but have to find where I've stashed them...

Form back when:

--<cut>--

Instead of having mobiles or the system spread rumours, make them
objects in their own right.  Every time something rumour worthy
happens, have the system create an invisible rumour object at the
location the event happened.  Now have the rumour object clone itself
every time someone approaches it (same room?) and have that cloned
copy attach itself to whoever (player or mobile) caused the cloning.
Have the cloned rumour objects attached to mobiles and players also
clone themselves and attach their clones to any other mobiles and
player they meet.  (Working on the principle that players move around
a LOT more than most mobiles).  At each point in the process where a
rumour object is created, give it a lifespan, so that the object
deletes itself after it gets too old.  The more distantly cloned a
rumour object is from its original, the shorter its lifespan should
be.

That should probably handle the actual spread of the rumour. Handling
player's hearing the rumour is another matter.

A nice thing about this system is that it also allows rumours to be
fairly easily set.  Thus players (or mobiles) could create false
rumour objects to spread tales and stories that didn't really happen.

--<cut>--

The result is that rumour objects slowly percolate out across the land
from any "worth event", carried by everything from players, to
cityguards, bunny rabbits and mosquitos.  I actually don't care what
the carrying vector is as I depend on the fact that the __FACT__ that
something something moved between two locations as proof that the
invisible MUD popluation (ya know, all those hundreds of city and
village dwellers you never see) can and do also move between those two
points, and thus could have carried the rumour.

Periodically (rarely) a rumour object will check its carrier (host?)
and decide to release.  It then forges an event for its carrier to
spout the rumour:

  > l
  You are in the city square.
  There is a peddler here.
  > z
  Time passes.
  > 
  The peddler looks up and says, "You know Tiamat was killed?  
  Some say Bubba did it."

Note: If you're worried about a mosquito popping up and talking, 
Don't worry.  Mosquitoes don't have a "say" method, so the event will
die there.

This (sorta badly) handles automated rumour progression.  For more
concious rumour control I really like Nathan's system (Which I can't
seem to find right now).  Essentially as I recall he allowed players
to conciously store rumours, and then replay them by command to
others.  (Nathan?)

>>>6) Global mob AI.
>>
>> Ouch.  Like it.  Don't have an elegant solution yet.

><gurgle><spastic-twitching>

I thought we warned you against playing with ducttape?  You really
shouldn't get so wrapped up in your work.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...