[ALAN] Parser problems, what annoys you?
Mikko P Vuorinen
parser problems they've had when playing the Alan games. I'd like to know
exactly what your problems were and what features and quirks were
annoying so I could try to do something about them in my future
games. One major flaw in Alan is that it doesn't support this:
>PUT MAP
Where do you want to put the map in?
>CHEST
The map is now in the chest.
So, please tell me everything that has annoyed you when playing for
example my games.
--
)))) (((( + Mikko Vuorinen + mvuo...@cc.helsinki.fi
)) OO `oo'((( + Dilbon@IRC&ifMUD + http://www.helsinki.fi/~mvuorine/
6 (_) ( ((( + GSM 050-5859733 +
`____c 8__/((( + + Vuosi 1999 on muuten jo pitkällä.
SteveG
Vuorinen) wrote:
>I've been reading the competition reviews and many reviewers mention the
>parser problems they've had when playing the Alan games. I'd like to know
>exactly what your problems were and what features and quirks were
>annoying so I could try to do something about them in my future
>games. One major flaw in Alan is that it doesn't support this:
>
>>PUT MAP
>Where do you want to put the map in?
>
>>CHEST
>The map is now in the chest.
>
>So, please tell me everything that has annoyed you when playing for
>example my games.
Before moaning about Alan I'd like to note the following positive
comment about both Alan and Mikko's abilities (in the recent thread
"Verbs Wanted" about the difficulty of programming ropes in TADS and
Inform) ...
"Judging by Mikko Vuorinen's comp game "King Arthur's Night Out",
then, we should all be using Alan."
--Iain Merrick
So now that I've, hopefully, made you feel better Mikko lets move on
to the complaints! :-)
I've noticed people moaning about several "Alan parser" problems in
recent r*if posts. I don't think all the problems attributed to the
Alan parser are really parser related at all.
I've noted problems that fall into four categories. The first two are
not directly related to the Alan system at all, the third category are
limitations of the Alan intepreter rather than specifically the parser
and finally there are problems that I *would* call "Alan parser"
limitations...
(1) Mikko's charming idiosyncracy of having different results for
player commands like "search" and "examine" which are more usually
synonomous terms. (I haven't played "KA'sNO" yet but this is my
understanding from the reviews. Yes, I will play it soon -- I'm so
tardy I haven't played any Comp99 games yet!)
I would attribute this to Mikko's preferences. Its certainly not
something forced upon him by a feature of the Alan parser. One would
have to debate with Mikko rather than the Alan system if one didn't
like such things.
(2) Another common complaint is a lack of synonyms or alternative
phrasings available for player actions in Alan games.
This also isn't because of any limitation of Alan itself. There's
no limit to the number of synonyms or alternative phrasings an author
can provide. Perhaps it could be blamed on the sparse standard library
which means Alan authors may run out of steam implementing multiple
alternative verbs etc because they have to spend extra time coding
things which are already coded in systems with more extensive standard
libraries? But it can't be blamed on the Alan parser or the Alan
system itself.
(3) There's a also few problems attributed to "the Alan parser" that
aren't really parser problems but limitations of the Alan runtime
interpreter program
- no "undo" facility
- no again command
- no "oops" facility (to correct typos in previous command)
I don't think there's anything a game author can do about these and
while I think "undo" is nice I don't think the other two are really
necessary when there's command history built into the interpreter.
(And it is built in on all versions except the MSDOS one I think.)
(4) Finally there's a couple of problems that I would attribute to
limitations of the Alan parser.
Mikko mentioned the fact that you can't ask disambiguation
questions. This would be hard to fix in a library routine or whatever
because of a genuine Alan parser limitation. That is that player
commands must start with a verb. So a player couldn't enter a command
consisting solely of an object name in response to a disambiguation
prompt anyway.
As well as the "commands must start with a verb" limitation,
another complaint I've seen is that adjectives can't be used as an
abbreviation for an object name -- an object name must be supplied
(unless the author deliberately programmed the adjective as an
alternative object name as well as an adjective.) For example, a
player couldn't open the "big metal hatchcover" by typing "open
metal".
Well that's about complaints about Alan that I've seen others mention
or I can think of myself.
In my opinion, only a few of the problems mentioned genuinely are
limitations of the Alan interpreter or parser. I don't think those
limitations must necessarily cause serious harm to player enjoyment of
Alan games. I would like to hear more feedback, though, from players
who've been annoyed by an Alan game to see if there are real problems
that can't be solved by conscientious Alan game authors. Then we can
all pester Thomas Nilsson with a wishlist for the next version of
Alan! :-)
--
SteveG
(Please remove erroneous word from address if emailing a reply)
Eric Mayer
(SteveG) wrote:
>
>I've noticed people moaning about several "Alan parser" problems in
>recent r*if posts. I don't think all the problems attributed to the
>Alan parser are really parser related at all.
>
and not as well in a post following the Comp myself. A few players, I
expect, blamed a lot of the shortcomings in my game THE HEBGB HORROR!
on the Alan parser rather than the newbie author. I suppose a language
lets itself in for that when it allows people who are barely computer
literate and prone to all sorts of oversights to nevertheless write a
playable game. (One thing I realize now is that whatever language you
use, no matter how simple, you are still going to face the same
logical problems),
>
>(2) Another common complaint is a lack of synonyms or alternative
>phrasings available for player actions in Alan games.
>
> This also isn't because of any limitation of Alan itself. There's
>no limit to the number of synonyms or alternative phrasings an author
>can provide. Perhaps it could be blamed on the sparse standard library
>which means Alan authors may run out of steam implementing multiple
>alternative verbs etc because they have to spend extra time coding
>things which are already coded in systems with more extensive standard
>libraries? But it can't be blamed on the Alan parser or the Alan
>system itself.
>
I'm still in the process of learning about IF and haven't played all
that many games. I did play almost every game in the Comp, however.
My observation is that only so many verbs are going to be useful in a
given situation and only so many can be implemented. What I seemed to
see, with TADS or INFORM are more default messages, tailored to the
particular game or, as often, not, when the player tries to use a verb
that is not useful in a given situation, as opposed to a verb not
recognized message. Frankly, I don't see how the marginally more
sensible default message adds much by way of realism or anything else.
It is pretty obvious to the player that it just means, nope, the
author didn't bother with this word.
And the big "guess the verb" problem is really down to the author, not
the parser. There are just too many words in the language. TADS and
INFORM might have bigger libraries than ALAN but still can only cover
a pitifully small percentage of the words available. In fact, I find
that multiplying different possible syntaxes can actually exacerbate
"guess the verb." At the most smplistic level, if your only verb to
employ an object is "use" you don't have any guess the verb problems.
The ideal, I think, is something more sophisticated than simply "use"
but simple enough not to leave a player totally at sea. To me IF is a
kind of game and so it doesn't bother me that any given piece of IF
will therefore be subject to certain rules. i.e. to use an object you
can say this and this and this but not this.
>(4) Finally there's a couple of problems that I would attribute to
>limitations of the Alan parser.
>
> Mikko mentioned the fact that you can't ask disambiguation
>questions. This would be hard to fix in a library routine or whatever
>because of a genuine Alan parser limitation. That is that player
>commands must start with a verb. So a player couldn't enter a command
>consisting solely of an object name in response to a disambiguation
>prompt anyway.
>
<snip>
>In my opinion, only a few of the problems mentioned genuinely are
>limitations of the Alan interpreter or parser. I don't think those
>limitations must necessarily cause serious harm to player enjoyment of
>Alan games. I
>
Coming to modern IF with little background I did not expect or miss
things like being able to ask disambiguation questions.In fact, my
only experience was in playing primitive games and when I was in the
middle of programming my own game I suddenly began to realize that,
"hey, Alan can do this, or recognize this construction, oh, gee, I
ought to do something with that" Do the works that the IF community
thinks highly of really rise or fall on such things? How much would
your enjoyment of (name a favorite piece of IF) been harmed by
inability to ask a disambiguation question?
--
Eric Mayer
Web Site: <http://home.epix.net/~maywrite>
=====================================================
co-author of ONE FOR SORROW
A "John the Eunuch" mystery from Poisoned Pen Press
<http://www.poisonedpenpress.com/html/sorrow.html>
=====================================================
"The map is not the territory." -- Alfred Korzybski
Daniel Barkalow
> Frankly, I don't see how the marginally more sensible default message
> adds much by way of realism or anything else. It is pretty obvious to
> the player that it just means, nope, the author didn't bother with this
> word.
The main area in which an extensive libraries is helpful to the player is
when it implements a lot of synonyms for words that the author handles in
such a way that the program treats it as if the player typed what the
author expected. That is, when you type, "pick the book up", it treats it
automatically as if the player had used a more common phrasing. This
example may be a bit extreme, but there are systems which only implement
one of "take" and "get", and these can be really annoying if you are used
to the other.
> And the big "guess the verb" problem is really down to the author, not
> the parser. There are just too many words in the language. TADS and
> INFORM might have bigger libraries than ALAN but still can only cover
> a pitifully small percentage of the words available. In fact, I find
> that multiplying different possible syntaxes can actually exacerbate
> "guess the verb."
There is also the benefit of having a set of conventions for the verb
used for a particular action (and sometimes synanyms, so you don't even
have to guess it). If I want to attack someone with a knife in an Inform
game, I will expect the command to be "hit", because I know that's a verb
that the library knows. I can generally predict the vocabulary that an
Inform game will use, unless it does something that the library doesn't
handle.
> Do the works that the IF community thinks highly of really rise or fall
> on such things? How much would your enjoyment of (name a favorite
> piece of IF) been harmed by inability to ask a disambiguation question?
It gets really important when you're going something complicated with one
of a bunch of similar objects. "unlock door with key" has a great
tendency to ask about one or the other, and figuring out "unlock large
red door with bronze key" by typing it out with more information each
time is a pain.
Jigsaw has plenty of places where I'm glad I just have to type "elegant"
instead of retyping the whole command.
-Iabervon
*This .sig unintentionally changed*
Eric Mayer
<iabe...@iabervon.mit.edu> wrote:
>
>The main area in which an extensive libraries is helpful to the player is
>when it implements a lot of synonyms for words that the author handles in
>such a way that the program treats it as if the player typed what the
>author expected. That is, when you type, "pick the book up", it treats it
>automatically as if the player had used a more common phrasing. This
>example may be a bit extreme, but there are systems which only implement
>one of "take" and "get", and these can be really annoying if you are used
>to the other.
>
That is a good point. I am not entirely clear on exactly everything
that's involved with parsers so if anyone wants to educate me more
that's fine :)
>There is also the benefit of having a set of conventions for the verb
>used for a particular action (and sometimes synanyms, so you don't even
>have to guess it). If I want to attack someone with a knife in an Inform
>game, I will expect the command to be "hit", because I know that's a verb
>that the library knows. I can generally predict the vocabulary that an
>Inform game will use, unless it does something that the library doesn't
>handle.
>
There I agree that it helps to know what the sysem expects, and I
think this is one respect in which Alan suffers, perhaps unfairly, in
that since it isn't used so much as Inform or Tads players don't know
what to expect out of it. That is, some of Alan's "shortcomings"
might not be so bad if players were more familiar with it and with
what to expect out of it.
>It gets really important when you're going something complicated with one
>of a bunch of similar objects. "unlock door with key" has a great
>tendency to ask about one or the other, and figuring out "unlock large
>red door with bronze key" by typing it out with more information each
>time is a pain.
>
That is very true, although I would look on that as a problem that the
author could overcome by avoiding such situations. I know that,
following the discussion on the topic in this group, I immediately
went back to my game, which has a locked door with a key, to use your
example, and made "open door" automtically unlock and open the door if
you had the key. Granted, one might ask if circumventing parser
limitations might be more trouble than learning another language, and
I suppose that depends on the author.
Jurgen Lerch)
SteveG <stev...@erroneous.moc.govt.nz> wrote:
[...]
> (2) Another common complaint is a lack of synonyms or alternative
> phrasings available for player actions in Alan games.
> This also isn't because of any limitation of Alan itself. There's
> no limit to the number of synonyms or alternative phrasings an author
> can provide. Perhaps it could be blamed on the sparse standard library
> which means Alan authors may run out of steam implementing multiple
> alternative verbs etc because they have to spend extra time coding
> things which are already coded in systems with more extensive standard
> libraries? But it can't be blamed on the Alan parser or the Alan
> system itself.
Sic. (Maybe I should finally put my JuLStd.alan on GMD (which is an
extension of the Standard.alan library by Luis E. Torres from there) ...)
> (3) There's a also few problems attributed to "the Alan parser" that
> aren't really parser problems but limitations of the Alan runtime
> interpreter program
> - no "undo" facility
> - no again command
> - no "oops" facility (to correct typos in previous command)
> I don't think there's anything a game author can do about these and
> while I think "undo" is nice I don't think the other two are really
> necessary when there's command history built into the interpreter.
> (And it is built in on all versions except the MSDOS one I think.)
(Ah, I have to admit I never understood that ,,oops'', though without
a history it might make more sense.)
> (4) Finally there's a couple of problems that I would attribute to
> limitations of the Alan parser.
> Mikko mentioned the fact that you can't ask disambiguation
> questions. This would be hard to fix in a library routine or whatever
> because of a genuine Alan parser limitation. That is that player
> commands must start with a verb. So a player couldn't enter a command
> consisting solely of an object name in response to a disambiguation
> prompt anyway.
You can't use non-alphanumeric characters in object names.
I have a zip-fastener in a game of mine (don't ask (or maybe
do! ;-) )). I can call it that in the source but can't refer
to it that way in the interpreter which chokes on the ,,-''.
> Well that's about complaints about Alan that I've seen others mention
> or I can think of myself.
Well, coloured text is missing, of course! :->
Classes of objects.
Better non-english language support. (Customizing standard responses is
nice, but for it to be really useful there should be globally accessible
ACTOR, OBJECT, ... variables. Hm, I mean that I would like to be able to
access the properties of those objects. Example from the German version
of aforementioned library:
MESSAGE NOSUCH: "Du kannst hier"
-- IF OBJECT IS NOT benannt THEN
-- IF OBJECT IS geschlecht THEN
-- IF OBJECT IS maennlich THEN
-- "keinen"
-- ELSE
-- "keine"
-- END IF.
-- ELSE
-- "kein"
-- END IF.
-- END IF.
"kein ,,$1'' sehen."
)
Some kind of REPLACE <object> would be really helpful. I have generic
wall, floor, ... objects in my library which aren't all that useful now
if you have ,,special cases'' of them somewhere, as now you have to
comment them out. (And no, I don't really like the ,,official'' gazillions-
of-libraries-to-be-included-approach.)
And, of course, a full AMIGA version ...
Ad Astra!
JuL
--
ler...@uni-duesseldorf.de / Ärgere nie einen Drachen, denn Du wirst
Jürgen ,,JuL'' Lerch / knusprig sein und gut mit Ketchup schmecken.
http://www-public.rz.uni-duesseldorf.de/~lerchj/
Ron Moore
lot of the versions of BASIC that came free with your computer in the early
80s.
A few additions I'd like to see:
- accepting numerical input
- unlimited dynamic loading and destruction of objects (as opposed to
transferring to and from limbo)
- storage arrays
Ron
Ron Moore
implement it though;)
Objects seem to load in rooms immediately following the location description or
at least print then. I tried to call an event immediately following the
description line to generate random descriptions (seasonal effects, room on
fire, raining, etc.) and the objects show up in between. Is there a way to
hold back objects from listing until you get to either the exit lines or end
location?
I'm having fun with events though reminds me of gosub and return from FORTRAN!
Ron
Eric Mayer
Weirdly enough, just last night I had the brainstorm to use an event
for descriptive purposes, as you mentioned. However, it was very late
and I didn't pursue it. If I understand correctly the event is always
going to execute last however, it would seem that if you just put a
-describe object.
at the end of your event the object description will occur there
instead of after the room description. Well, it worked just now when I
tried it once.
I was practically done with my Alan game when I began to realize that
events might be very useful.
Lelah Conrad
wrote:
>I was practically done with my Alan game when I began to realize that
>events might be very useful.
Events are VERY useful, and fun! I have been writing an on again off
again long game for a couple of years in which events figure
prominently. Events are the most fun thing about ALAN, in my opinion.
Lelah
Thomas Nilsson
Ron Moore wrote:
>
> I'm still learning the language by trial and error but ALAN does remind me a
> lot of the versions of BASIC that came free with your computer in the early
> 80s.
>
> A few additions I'd like to see:
>
> - accepting numerical input
Numeric input is allowed. See OOPS! I thought there was a sample of
this on the site, sorry I have to fix this.
Well anyway you can have Alan accept numeric input by using NUMBER in
the syntax definition:
turn_to = 'turn' (o) 'to' (n)
Where n Isa Number
Else ...
This will allow commands like
> turn dial to 345
sg...@my-deja.com
ler...@uni-duesseldorf.de (J"urgen
Lerch) wrote:
> Saluton!
> [snip](Maybe I should finally put my JuLStd.alan on GMD (which is an
> extension of the Standard.alan library by Luis E. Torres from there)
I'd encourage you to do that - both the German and English versions - I
know I'd like to see your ideas.
> [....] Well, coloured text is missing, of course! :->
[Win95/NT] - DOS Window 'properties' dialog box!
(Just kidding of-course -- I'd like atleast boldface/normal text
attributes to be under the author's control.)
>[...]And no, I don't really like the ,,official'' gazillions-
> of-libraries-to-be-included-approach.)
The advantage of the gazillions approach is that if you only need to
change a few aspects of the default behaviour of the std.i library then
you only need to edit a few of the std.i files - thereby making it
easier to keep track of what you've changed.
With the current 'draft/proposed' state of std.i, I find I need to
expand the contents of all the files anyway, so the advantage of the
multiple-files approach is lost.
Perhaps you could incorporate the features of your JulStd.alan library
into std.i and solve all our problems!
[snip]
Regards,
SteveG.
Sent via Deja.com http://www.deja.com/
Before you buy.
SteveG
>One other thing comes to mind. Maybe I just haven't figured out how to
>implement it though;)
>
>Objects seem to load in rooms immediately following the location description or
>at least print then.
Yes, the descriptions of objects at a location are displayed after the
location description (see Note below.)
>I tried to call an event immediately following the
>description line
You will not be successful trying to schedule an event to occur within
the location description - events scheduled to occur 'this turn' are
*always* the last thing to happen in the turn - after the effects
caused by any actor scripts (which occur after effects caused by the
player's command.) (See Chapter 5 in the Alan manual for a better
explanation.)
The display of the location description (including object
descriptions) is usually triggered by a player command to move into a
new location (eg: 'go north') so the location and object descriptions
will be the first text to be displayed in that turn.
So what you should do is incorporate your random description changes
into the location description itself with IF statements and not use
the Alan EVENT concept at all for this effect.
For example ....
LOCATION moor NAME desolate moor
DESCRIPTION
"There seems to be nothing at this lonely spot except
clumps of long coarse grass."
IF weather IS windy THEN
"The grass is buffetted constantly by the cold wind that is
howling in from the north."
IF RANDOM 1 TO 10 = 1 THEN
"A flash of lightning streaks across the northern sky."
END IF.
END IF.
"A path through the grass runs east to west."
EXIT east TO moremoor.
EXIT west TO moremoortoo.
END LOCATION.
You can use 'events' when you want, for example, text about flashes of
lightning to be displayed during any player turn rather than just when
the location description is displayed. But, as you've noticed, the
text generated by 'events' will always be displayed at the end of the
turn, after the results of player actions, so you need to take that
into account when designing the events. You also might want to look at
using the 'rules' feature.
>to generate random descriptions (seasonal effects, room on
>fire, raining, etc.) and the objects show up in between. Is there a way to
>hold back objects from listing until you get to either the exit lines or end
>location?
The way you order your source code items like 'exit' definitions or
'end location' statements don't affect the way things are processed
each turn.
Note:about object descriptions (not directly relevant to your queries
but it may be useful if you don't know about it already)
- you can give objects blank descriptions. This is useful, for
example, when the object is already described in the location
description - eg: the clumps of grass in the location description
above.
eg:
OBJECT grass AT moor
IS NOT Takeable.
DESCRIPTION
END LOCATION.
>
>I'm having fun with events though reminds me of gosub and return from FORTRAN!
Are you equating fun with FORTRAN ?? :-)
Alos, see the Etudes example at the IF Archive for another way to do
subroutines in ALAN.