[MUD-Dev] Text Parsing

Ola Fosheim Grøstad <olag@ifi.uio.no> Ola Fosheim Grøstad <olag@ifi.uio.no>
Mon May 31 21:52:52 CEST 1999


Chris Gray wrote:
> necessarily fully relevant. The goals of a MUD parser are somewhat
> different from the goals of a full AI system. A MUD parser needs to have
> some degree of efficiency (taking seconds to parse a command is just not
> practical), and may well have to deal with words it doesn't know. It just
> needs to find a reasonable interpretation for the commands that the
> designer has decided it ought to be able to interpret.

I am not going to say that discussing command parsing is a waste, discussing
can be valuable in itself as the people involved become more aware of the
problems they face.  BUT, there has been a bit of relevant research on text
based interfaces as well, possibly more relevant than AI. There is so much
reinventing needed in order to get a decent MUD running, so basically Cynbe
has a point, reinventing the command line interface is probably not going to
save your world. The basic approaches have most likely been considered and
evaluated already, so summaries of findings in relevant fields could be
useful.

> So, I think discussion of simple, practical ways to handle a good
> variety of input are quite relevant here.

Yes. However, I think you basically have two choices:

1. A simple well defined well known set of actions.
2. Full fledged natural language parsing with great support for synonyms and
a world of great detail.

Because if you try something in the middle you will most likely end up with
the horrible "guess the verb/item match" puzzle that is so typical of
LP-MUDs. If there are only two places in the world where the "search" verb
has an effect, then it probably should have been replaced with "examine" or
"look" anyway. Special cases of limited utility and importance ought to be
designed away. A better approach might be to interpret commands and
intentions liberally and intelligently provided a nonfatal reversible
outcome, and provide suggestions if they could be fatal. 

	> look
	You see Peter here.
	[adds Peter to future context]

	> get money
	Peter's wallet steals your attention.
	[future context is semi-greedy/collector focus]

	> get money from Peter
	[a steal is more fatal than a get and irreversible]
	You would have to steal to get it.

	> steal money
	[records possible sources at this moment]
	Peter left the room.
	John enters the room.
	Damn, Peter escaped your swift fingers, but John looks tempting.
	[adds John to future context as computer suggested]

	> steal money
	[records possible sources at this moment]
	Eric, Jane and Dick enter the room.
	[John is the only known context]
	Getting John's wallet was easy, he didn't even notice.

	> steal money	
	Both Eric, Jane and Dick look wealthy. Ack, choices...

	> examine Jane	
	Jane has a great b[...]
	[adds Jane to future context as examined]

	> examine Eric	
	Eric's wallet is smaller than Jane's[...]
	[adds Eric to future context as examined]
				
	> steal money
	[Both jane and eric are equal candidates, a priority scheme
	 would fail, because if the most recent context is given
	 priority then one would steal from Eric, if greed is given
	 priority then one would steal from Jane. We should only make
	 obvious assumptions on critical actions.]
	Ack, choices... The memories of Eric's fanciful wallet are
	still lingering in memory, but Jane's wallet is definitively
	bigger.
	[Jane's priority is raised]

	> steal money
	You have stolen Jane's wallet, and she didn't even notice!


Basically, if you won't be able to support subtleties of value throughout
the system, then you will be better off without them. The only
counterexample I can think of is communication commands, or socio-emotional
modifiers:

	> get money greedily
        Ola grabs the gold coin with a greedy smile on his face.
	> get money
	Ola picks up a gold coin.
	
Other counterexamples welcome, of course.

--
Ola Fosheim Groestad,Norway      http://www.stud.ifi.uio.no/~olag/



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev




More information about the mud-dev-archive mailing list