Simplified Parser
Daniel Phillips
I'm curious to know your thoughts about a simplied parser for an ALAN
game I'm planning. I've modeled this parser after the commands of
certain graphical adventure games such as Shadowgate and Uninvited. I
had to expand on these commands for this text adventure, though. Here
they are:
LOOK
look
look at
look in
look under, above, through, or behind
INVENTORY, TAKE, DROP, USE, THROW, OPEN, CLOSE, ENTER, INSERT, TALK,
SHOW, HIT, FIGHT, compass movements
Examples of use: INSERT sword in hole
USE torch on rug
USE valve
THROW pie at troll
All of these commands and how to use them would be listed in the
readme file. They're simple, right? That's my goal, but at the same
time I hope their uses will be versatile.
What are some other IF games, ALAN or other, that uses a similar
parser?
Thank you for your time.
Daniel Phillips
phi...@ix.netcom.com
Daniel Phillips
<j...@ingold.fsnet.co.uk> wrote:
>> LOOK
>> look
>> look at
>> look in
>> look under, above, through, or behind
>> INVENTORY, TAKE, DROP, USE, THROW, OPEN, CLOSE, ENTER, INSERT, TALK,
>> SHOW, HIT, FIGHT, compass movements
>>
>> Examples of use: INSERT sword in hole
>> USE torch on rug
>> USE valve
>> THROW pie at troll
>>
>> All of these commands and how to use them would be listed in the
>> readme file. They're simple, right? That's my goal, but at the same
>> time I hope their uses will be versatile.
>
>They're simple alright - except for *four* different types of "search the
>object cunningly"?!? Or are above/under/behind/through synonymous?
>
>Jon
>
>
No, they just indicate where the player is searching :-)
LOOK UNDER rug
LOOK BEHIND piano
LOOK THROUGH curtains
And I guess LOOK "above" should be changed to LOOK "on".
Daniel Phillips
phi...@ix.netcom.com
Jon Ingold
Gene Wirchenko
>I'm curious to know your thoughts about a simplied parser for an ALAN
>game I'm planning. I've modeled this parser after the commands of
>certain graphical adventure games such as Shadowgate and Uninvited. I
>had to expand on these commands for this text adventure, though. Here
>they are:
>
>LOOK
> look
> look at
> look in
> look under, above, through, or behind
>INVENTORY, TAKE, DROP, USE, THROW, OPEN, CLOSE, ENTER, INSERT, TALK,
>SHOW, HIT, FIGHT, compass movements
>
>Examples of use: INSERT sword in hole
> USE torch on rug
Do something with the torch that is on the rug?
Do something to the rug with the torch?
> USE valve
Do something with the valve. Open it? Close it?
> THROW pie at troll
>
>All of these commands and how to use them would be listed in the
>readme file. They're simple, right? That's my goal, but at the same
>time I hope their uses will be versatile.
>
>What are some other IF games, ALAN or other, that uses a similar
>parser?
>
>Thank you for your time.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Gene Wirchenko
[snip]
>And I guess LOOK "above" should be changed to LOOK "on".
Not necessarily.
>look above fire.
The mahogany mantelpiece has several knick knacks on it.
The mantelpiece is above the fire, not on it!
Daniel Phillips
>> USE torch on rug
>
> Do something with the torch that is on the rug?
> Do something to the rug with the torch?
>
>> USE valve
>
> Do something with the valve. Open it? Close it?
>
If the valve was closed, "use valve" will open it the first time
around. If "use valve" is entered in again, then the valve will
close.
If a wrench was needed, then what would have to be entered to either
open or close the valve would be "use wrench on valve".
Daniel Phillips
phi...@ix.netcom.com
>> THROW pie at troll
>>
>>All of these commands and how to use them would be listed in the
>>readme file. They're simple, right? That's my goal, but at the same
>>time I hope their uses will be versatile.
>>
>>What are some other IF games, ALAN or other, that uses a similar
>>parser?
>>
>>Thank you for your time.
>
Gene Wirchenko
[snip]
>>> USE valve
>>
>> Do something with the valve. Open it? Close it?
>>
>If the valve was closed, "use valve" will open it the first time
>around. If "use valve" is entered in again, then the valve will
>close.
>
>If a wrench was needed, then what would have to be entered to either
>open or close the valve would be "use wrench on valve".
Why not "turn"?
[snipped previous]
Trevor Powell
2.something, I believe), Michael mentioned that a method of avoiding 'guess
the verb' puzzles was to design the game using only a few verbs: 'take',
'drop', 'examine', 'put in', a few others which are escaping my memory at
the moment, and 'use', which was the 'obvious use' of the object. So, as
Daniel says, 'use button' means to push it, 'use door' means to open it,
etc.
The difference, of course, was that Michael was advocating using the 'use'
verb only while designing the game; as a method of avoiding the creation of
puzzles which relied on the usage of nonstandard adventure game verbs
('wedge' or 'pinch', for example), and substituting the correct verbs when
actually coding the game.
My question is, why use a simplified parser in a text adventure? I'd
always thought that graphical adventures tend to have simple 'use' verbs is
that graphical interfaces become clumsy when too many verbs are available.
Look at the GUI for selecting verbs in Infocom's "Quarterstaff", for an
example.
Simplifying the verbset to 'use' lets graphical adventures require the
player to do initially unintuitive things like wedging doors open with
kitchen utensils without either cluttering the interface or resorting to
'guess the verb'. However, it also leads to gameplay consisting of "for
each pair of objects (a,b) nearby, use a on b and see if anything good
happens," as can be seen in any LucasArts adventure. Isn't this likely to
happen in a text adventure, as well?
Trevor
(e-mail address munged for spam-avoidance)
--
"Whenever I smell asphalt, I think of Maureen."
Gene Wirchenko <ge...@shuswap.net> wrote in message
news:38eec17b...@news.shuswap.net...
Daniel Phillips
<vul...@nos.zikzak.pam.net> wrote:
>
>My question is, why use a simplified parser in a text adventure? I'd
>always thought that graphical adventures tend to have simple 'use' verbs is
>that graphical interfaces become clumsy when too many verbs are available.
>Look at the GUI for selecting verbs in Infocom's "Quarterstaff", for an
>example.
>
>Simplifying the verbset to 'use' lets graphical adventures require the
>player to do initially unintuitive things like wedging doors open with
>kitchen utensils without either cluttering the interface or resorting to
>'guess the verb'. However, it also leads to gameplay consisting of "for
>each pair of objects (a,b) nearby, use a on b and see if anything good
>happens," as can be seen in any LucasArts adventure. Isn't this likely to
>happen in a text adventure, as well?
>
>Trevor
>(e-mail address munged for spam-avoidance)
My goal for the simpler parser was just as you said, to avoid making
the player "guess the verb". I think it could also make the job
easier for me since this would be the first text adventure I ever
designed.
However, I was also concered about one thing that I think you hinted
at. Just like in a graphical adventure, as a last resort the player
might be able to simply "use" an item on everything to see if anything
good comes out of it. I wonder if there would be a way to avoid that
other than making obscure puzzles?
But here's how I rank a few of the game's elements:
1) Storyline and character 2) multiple paths 3) puzzles
I hope that the simple parser will work to the player's enjoyment if I
follow through with the above priorities. I've divided the gameplay
up into phases so there's an opportunity to take one phase at a time
for beta testing. Maybe the test on how well I implement the
nonstandard parser will reveal itself in the beta testing.
Daniel Phillips
phi...@ix.netcom.com