[MUD-Dev] (fwd) Re: Issues from the digests and Wout's list

clawrenc at cup.hp.com clawrenc at cup.hp.com
Thu May 8 10:20:36 CEST 1997


In <9705071455.7z9i at ami-cg.GraySage.Edmonton.AB.CA>, on 05/07/97 
   at 08:00 PM, cg at ami-cg.graysage.edmonton.ab.ca (Chris Gray) said:

>[Raz:]
>[details of example deleted]
>:The above seems to be a generally smooth handling of that particular
>:situation. Obviously, nicer interaction could be passed to the two
>:participants - the parser could respond to the male human in the last
>:instance "The big bag was just taken by the female human, take the small 
>:one instead?" or, better, offer this prompt the instant the female 
>:takes the bag.

>In order to do that, the system is going to have to know that there
>is a prompt pending on the first player, and that the second player's
>action has an affect on the status involved in that prompt. You are
>deep into semantics here, and far beyond what is just "parser" work.

A lot of this I think can be provided by having the parser generically
detect when it enters a state dependant condition, and when such
occurs, to isntall watchers on all the objects on which that state
depends.  

That way you don't actually have to get into the semantic parsing of
potential the state changes -- it can be handled by direct maintenance
and checking of the state machine itself.

>...I guess
>its your choice as to whether or not the result is worth all that
>effort. For me, its not. I will also point out that as a player, I'm
>not at all sure I would be comfortable with such suspended commands
>hanging around like that - I would hope there would be a way to tell
>the system to never ask me questions like that, and to just fail
>commands that fail.

Yup, thus I currently have the <ENTER> abort any incompleat commands,
with a clear visual signal on the screen that there is an incompleat
command.

>OK, but then you have to somehow decided that some semantic action of
>the player is such that it silently cancels the outstanding state of
>the question. Do you allow any user-level programming of objects,
>etc? If so, how do you make sure that everything that should affect
>such outstanding states does do so?

This is where the watchers come in.  You are no longer reliant on
having the individual objects responsible for determining whether or
not to communicate their state changes to that parser, and you're not
reliant on having the user programmers remembering to do anything at
all.  it happens as a generic side effect of the parser watching its
dependencies directly.

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




More information about the mud-dev-archive mailing list