Simplified Parser

44 views
Skip to first unread message

Daniel Phillips

unread,
Apr 5, 2000, 3:00:00 AM4/5/00
to
Hello all,

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

unread,
Apr 5, 2000, 3:00:00 AM4/5/00
to
On Thu, 6 Apr 2000 00:05:33 +0100, "Jon Ingold"
<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

unread,
Apr 6, 2000, 3:00:00 AM4/6/00
to

Gene Wirchenko

unread,
Apr 8, 2000, 3:00:00 AM4/8/00
to
phi...@ix.netcom.com (Daniel Phillips) wrote:

>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

unread,
Apr 8, 2000, 3:00:00 AM4/8/00
to
phi...@ix.netcom.com (Daniel Phillips) wrote:

[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

unread,
Apr 8, 2000, 3:00:00 AM4/8/00
to
>>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?
>
Doing 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

unread,
Apr 8, 2000, 3:00:00 AM4/8/00
to
phi...@ix.netcom.com (Daniel Phillips) wrote:

[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

unread,
Apr 8, 2000, 3:00:00 AM4/8/00
to
I recall back in the days of olde, in the printed TADS manual (for version
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

unread,
Apr 8, 2000, 3:00:00 AM4/8/00
to
On Sat, 8 Apr 2000 21:57:54 +1000, "Trevor Powell"
<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

Reply all
Reply to author
Forward
0 new messages