Issues from the digests and Wout's list

[Nathan Yospe]

On Thu, 17 Apr 1997 clawrenc at cup.hp.com wrote:

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

Interesting.... you seem to do the shell interface in the opposite order
that I do. (My symbol is the colon, which can be used to open secondary
interfaces, toggle interfaces, or execute commands in an external
interface. I would do this in the opposite direction, though, where the
combat commands would not require it... but, say, parsing back to modify a
failed command would require typing something like:
 > :!ge /ba red ba
a system I personally would never use, but when I designed it, and was
ready to scrap it, one of my friends, a unix drooler, told me that, having
programmed something like that, he would never speak to me again if I
removed it.

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

Hmmm.

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

(for the purposes of discussion: I am controlling two characters,
FireBrand and Lissajous. FireBrand is in a secondary interface, Lissajous
is primary. I also have a piece of mmail I am doing in my shell.)
 > :fire >tell lissa Testing, testing...
{FireBrand} You mutter into your comm. {/F} Your comm chirps, and
FireBrand's voice says, "Testing, testing..."
> tell fire Testing.
You mutter into your comm. {FireBrand} Your comm chirps, and Lissajous'
voice says, "Testing." {/F}
 > :messaging fire off
{shell} Messages directed to FireBrand will no longer be broadcasted via
shell. {/s}

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

Ah. Return to kill.

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

Depends... I think both of these should have been global binding, or
player, really.

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

I have to admit, my parser can get pretty expensive, though hardcoding
helps a lot.

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

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

Yeah... well, what it comes down to is that I never hardcoded rumors,
never saw a reason to... and I have yet to translate that softcode over,
and probably never will... it was something I did for fun... but a rumor
is an object, capable of mutation, transmission, and decay. A rumor will
autotransmit when a mob does a rumor dump (runs into a likely other) but a
player could recall rumors he/she had heard, and type something like "tell
StarSeeker about the dragon", and the rumors would be querried for one
that pertained to "the dragon" and was freshest on the mind. This would be
autorelayed. No biggie, really. Just an extension of how an NPC tells a PC
of the rumor.

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

*grin* He wasn't... he accidentaly cut the _red_ wire.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu