Use of USE
Freddy
I plan on entering the IF ART Show and since this will be my first
game for this show I was wondering what you thought on the verb USE.
I tried to do a google search but couldn't narrow down the posts since
USE is a common word so I don't know what discussions have taken place
on this.
If I have a shovel should
>use shovel
work just as well as
>dig ground with shovel
The deadline isn't for a few days so I have some time to make changes.
My gratitude for your time.
Fred Demul
Ricardo SIGNES
> I plan on entering the IF ART Show and since this will be my first
> game for this show I was wondering what you thought on the verb USE.
Similar questions:
Should I be using Inform or TADS?
Is vi or emacs better?
Are graphics in games better than no graphics?
(Inform, vi, no, and "use is so general that it's annoying to use in plan and
in design.")
--
rjbs
Joe Mason
>
>>use shovel
>
> work just as well as
>
>>dig ground with shovel
Nobody really expects this.
> The deadline isn't for a few days so I have some time to make changes.
> My gratitude for your time.
I don't think you have time to make such major changes as introducing
USE. USE has to be context sensitive, so you have to implement it for
every object and possibly have it detect multiple things to do with each
object (>USE SHOVEL ON GHOUL instead of >HIT GHOUL WITH SHOVEL).
Testing it will take a lot of time. (If you add USE for just one noun
and circumstance, players will expect it to be consistent and it will
feel like a bug if the game doesn't respond just right.)
Of course, if your art show entry is just modelling the shovel, it might
be easy to just stick a USE verb on it, but if it's even a little more
complicated than that I don't think it's worth it right now.
Joe
Daphne Brinkerhoff
> Hi gamers.
>
> I plan on entering the IF ART Show and since this will be my first
> game for this show I was wondering what you thought on the verb USE.
> If I have a shovel should
>
> >use shovel
>
> work just as well as
>
> >dig ground with shovel
Personally, I wouldn't be looking for it to work. I wouldn't even try
it, unless the game told me to. If you're only going to pick one
form, I'd rather see the other way ("dig ground with shovel")
implemented. (Or maybe just "dig", since it should be clear I don't
want to dig the ceiling. "Dig with shovel" is natural-sounding, but I
bet it isn't so easy to code.)
I guess the answer is: did your betatesters try to "USE" things? If
so, you could put it in as an alternative syntax wherever it came
naturally to them.
(Not specific to your question) In general, if you have "USE" assume
what I want to do with something, that's going to be wrong some of the
time, and that would make me (as a player) not happy. With a shovel,
maybe it's obvious how to "use" it, but how does one "use" a glass of
water? An unsigned contract? Etc.
--
Daphne
Harry
I don't really like 'USE' as a verb. As stated by others in this
thread, it take a lot more coding then you'd expect, since what you
basically do is provide a general synonym for lots of very different
actions. And people have different expectations for a single 'USE"
command:
Kitchen
You are in a kitchen.
You see Chester the cat here.
Some food lies on the counter.
>Take food
Taken.
>Use food
You eat the tasty food. Yummy!
At which point the player is annoyed, since he wanted to feed the cat.
I do, however, usually write a short 'USE' verb, which only prints out
a message to satisfy any logical input. Something like:
>USE FLASHLIGHT
Ah yes! But how?
Which teaches the player he has to be specific.
There is nothing wrong in expecting specific commands to solve a
puzzle, as long as they are logical, clued properly and consistently
coded.
-------------------------
"Hey, aren't you Gadget?"
"I was."
(To send e-mail, remove SPAMBLOCK from address)
Ben Caplan
> On 23 Apr 2003 10:42:31 -0700, dem...@hotmail.com (Freddy) wrote:
>>> use shovel
>>> dig ground with shovel
I agree with all of this, with one exception: Sometimes USE is the most
natural verb to use in a situation. Imagine if...
> I
You have a set of keys.
> UNLOCK GRATE
You'll have to be more specific about how you want to do that.
> USE KEYS
I don't know the word 'use'.
[after much guess-the-verb...]
> UNLOCK GRATE WITH KEYS
Unlocked.
> IN
The grate is closed.
> QUIT
And then there's 'use toilet' near the beginning of _Leather Goddesses of
Phobos_. It's a judgment to be made for each situation. I personally
advocate against it whenever reasonable, but the H in IMHO means 'I have no
clue.' When I say it, at least.
(Actually, I don't even say it. It's implicit.)
----------------------------------------------------------------
Ben Caplan -- philosopher, linguist, and thaumaturge
Mike Roberts
> I don't really like 'USE' as a verb. As stated by others in this
> thread, it take a lot more coding then you'd expect, since what
> you basically do is provide a general synonym for lots of very
> different actions. And people have different expectations for a
> single 'USE" command:
When you say you don't like USE, are you speaking as a player, or as an
author? The reasons you just stated (and the objections others have raised)
sound an awful lot like you're thinking about this from the author's
perspective.
Not picking on you or anyone else in particular, I've observed a certain
tendency among raif'ers to do that - to think in terms of the purity of the
world model and the implementation details rather than in terms of the
player's experience. (Think of the recent "prior knowledge" threads, or
authors who turn off TAKE ALL because it would make things "too easy" for
the player.) It's fine to put the author's viewpoint ahead of the player's
if that's what you want, and given the high overlap in the community between
authors and players, perhaps there isn't really such a thing as a player's
viewpoint any more. But I'm not sure what the point is; players won't see
or appreciate the inner beauty of the mechanical construction of a game.
They just want something that's fun, easy to use, and doesn't require a lot
of tedious typing. It's pretty clear to me that the most successful games
have been the ones where the author put the player's priorities ahead of
everything else.
Personally, I've found myself really, really wanting a USE command on a fair
number of occasions while playing IF games. Not all the time, but enough
times that it wasn't just a fluke. There are some objects whose function is
simply obvious, and there are times when a verb phrasing is anything but,
and it's happened to me at least a few times that those two conditions
coincided perfectly. You can talk about edge cases where USE SHOVEL might
mean "hit troll with shovel" or whatever, but even in cases like that, is a
player ever truly going to be confused if USE SHOVEL always means DIG?
--Mike
mjr underscore at hotmail dot com
Paul Drallos
>
> I guess the answer is: did your betatesters try to "USE" things? If
> so, you could put it in as an alternative syntax wherever it came
> naturally to them.
>
I recently ran into this very situation. When my betatesters
tried to fight the beast, the game would respond with
'Bare-handed, you are no match for the beast.' So they would
then try 'use sword', and were perplexed as to why they couldn't
use the sword. So I implemented 'use sword' for that particular
case only and didn't get any further complaints from them.
Paul
R. N. Dominick
news:BACC8A1A.1AF5%b...@hayscaplan.org:
>> USE KEYS
> I don't know the word 'use'.
>
> [after much guess-the-verb...]
>
>> UNLOCK GRATE WITH KEYS
> Unlocked.
I can pretty confidently predict that almost nobody has to guess that the
verb to use when presented with a locked lock and a key is 'unlock'. What
other possibilities could there be? 'Lock' and 'unlock' are what
naturally go with keys and locks -- well, along with the possibility of
'open lock with key'.
> And then there's 'use toilet' near the beginning of _Leather Goddesses
> of Phobos_.
But that's what we do; we use the toilet. There's no specific verb for
interacting with a toilet; that's the natural phrasing. (FWIW, in LGOP
you can 'pee' and 'pee in toilet' as well, or even 'wee-wee', which makes
the 11-year-old me giggle.)
But the natural phrasing for striking an enemy with a sword is most
definitely not 'use sword'.
--
R. N. Dominick -- ur...@bookmice.net
Harry
<mjrUND...@hotmail.com> wrote:
>"Harry" <gad...@SPAMBLOCKhaha.demon.nl> wrote:
>> I don't really like 'USE' as a verb. As stated by others in this
>> thread, it take a lot more coding then you'd expect, since what
>> you basically do is provide a general synonym for lots of very
>> different actions. And people have different expectations for a
>> single 'USE" command:
>
>When you say you don't like USE, are you speaking as a player, or as an
>author? The reasons you just stated (and the objections others have raised)
>sound an awful lot like you're thinking about this from the author's
>perspective.
>
Erm... yeah. *blush* I was thinking mostly as an author here.
>Not picking on you or anyone else in particular, I've observed a certain
>tendency among raif'ers to do that - to think in terms of the purity of the
>world model and the implementation details rather than in terms of the
>player's experience. (Think of the recent "prior knowledge" threads, or
>authors who turn off TAKE ALL because it would make things "too easy" for
>the player.) It's fine to put the author's viewpoint ahead of the player's
>if that's what you want, and given the high overlap in the community between
>authors and players, perhaps there isn't really such a thing as a player's
>viewpoint any more. But I'm not sure what the point is; players won't see
>or appreciate the inner beauty of the mechanical construction of a game.
>They just want something that's fun, easy to use, and doesn't require a lot
>of tedious typing.
I was one of the people hammering on the point you just made: fun over
design-purity. And now I try to scare that little Inform coder out of
my head for a moment, I remember the joy in a simple verb-noun affair
where all the verbs are known to the player, including the use of USE.
So, hey. USE can be fun.
> It's pretty clear to me that the most successful games
>have been the ones where the author put the player's priorities ahead of
>everything else.
Agreed. Sometimes designers forget they are in the 'fun-business', not
the 'art-business' or the 'elegant-algolrythm-business'.
>
>Personally, I've found myself really, really wanting a USE command on a fair
>number of occasions while playing IF games. Not all the time, but enough
>times that it wasn't just a fluke. There are some objects whose function is
>simply obvious, and there are times when a verb phrasing is anything but,
>and it's happened to me at least a few times that those two conditions
>coincided perfectly. You can talk about edge cases where USE SHOVEL might
>mean "hit troll with shovel" or whatever, but even in cases like that, is a
>player ever truly going to be confused if USE SHOVEL always means DIG?
>
>--Mike
>mjr underscore at hotmail dot com
>
>
Okay, I'm all over the place now. Both points are valid. But with the
complex parsers of today, as a player I don't expect the game to
understand general commands, only specific. So I usually don't even
try 'USE' anymore but try to think of a natural way to interact with
objects.
I guess it is because of limitations in old parsers that they were
often elegantly coded in such a way that USE was a naturally way to
play the game. The question is: do we want to simplify the parser or
force the player to pick his words with care?
Quintin Stone
> Personally, I've found myself really, really wanting a USE command on a
> fair number of occasions while playing IF games. Not all the time, but
> enough times that it wasn't just a fluke. There are some objects whose
> function is simply obvious, and there are times when a verb phrasing is
> anything but, and it's happened to me at least a few times that those
> two conditions coincided perfectly. You can talk about edge cases where
> USE SHOVEL might mean "hit troll with shovel" or whatever, but even in
> cases like that, is a player ever truly going to be confused if USE
> SHOVEL always means DIG?
Although I dislike the idea of the generic "USE", I think Mike has a
point. There are those situations where an obvious-use object needs to be
employed, but the player is forced into the torture of guessing the one
obscure verb that the author implemented. Maybe there should be a default
verb attached to a few select objects that can be accessed with merely
"USE" ("use toilet", "use computer", etc.). Most other things, however,
could return the message: "You'll have to be more specific as to how you
want to use it."
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/
Freddy
player. I was really hoping for player opinions but do appreciate all
the feedback.
To answer one of the questions, no it wasn't found by the person
looking at my game. There is a use verb in some tads code that I
found in the archive and it just got me thinking about my current
situation.
I know it's a lot of work to implement verbs but as Mike Roberts
pointed out, I'm just going to make use a synonym for certain actions
on certain items. If an item has multiple uses then the game will
respond that you need to be more specific. If an item has one major
use, then use will work.
For instance, a rake has one primary function. Rake leaves is the
proper command but I don't see why use rake shouldn't work either. On
the other hand, if you have a chain saw, use saw is too vague since
the game needs to know what you're trying to cut.
Fred Demul
Rikard Peterson
> When you say you don't like USE, are you speaking as a player, or
> as an author? The reasons you just stated (and the objections
> others have raised) sound an awful lot like you're thinking about
> this from the author's perspective.
As a player, I come from a background of graphical adventures and one
of the things I like most about text IF is the parser. That you don't
just Use or Use With, but are required to be more specific. I think it
would have been harder for me to get in the right mindset if the first
text game I played had supported Use.
I don't really have anything useful to say about the special cases
mentioned, but in the case of the shovel I see no advantage of
supporting Use Shovel. (And I would expect to shovel with the shovel.
For any digging I'd prefer a spade. Yes - I have grown up on a farm.)
Rikard
Alan DeNiro
> Agreed. Sometimes designers forget they are in the 'fun-business', not
> the 'art-business' or the 'elegant-algolrythm-business'.
>
Except that it perhaps should be reiterated that the author who posted
his question in the first place was making a game for the IF Art Show,
which is in fact, according to its guidelines, in the art "business."
Best,
Alan
______
Alan DeNiro
Correspondent, Ptarmigan
http://ptarmigan.blogspot.com
Ricardo SIGNES
> player. I was really hoping for player opinions but do appreciate all
> the feedback.
I certainly meant to respond as both. I think that the problem with USE is its
genericity. It's useful only in cases where it is the most likely verb I'd use
in normal speech. "use toilet" and "use computer" and "use back massager" are
indeed good examples.
Even those, though, have replacements which should be supported -- I generally
never, ever use the 'use' verb in a game, largely because I assume it will be
unimplemented.
--
rjbs
Paul Drallos
> On Wed, 23 Apr 2003, Mike Roberts wrote:
>
>
> Although I dislike the idea of the generic "USE", I think Mike has a
> point. There are those situations where an obvious-use object needs to be
> employed, but the player is forced into the torture of guessing the one
> obscure verb that the author implemented. Maybe there should be a default
> verb attached to a few select objects that can be accessed with merely
> "USE" ("use toilet", "use computer", etc.). Most other things, however,
> could return the message: "You'll have to be more specific as to how you
> want to use it."
>
The player isn't necessarily forced forced into the torture of
guessing the verb. USE can implemented simply as an alternative
option for performing an action which can also be performed by
more more traditional verbage. The player doesn't have to use
'USE', but if (s)he does, it should work, at least in some
compelling situations.
Mike Roberts
> As a player, I come from a background of graphical adventures
> and one of the things I like most about text IF is the parser. That
> you don't just Use or Use With, but are required to be more
> specific.
I think it's good to be *allowed* to be more specific. *Required* is less
clearly a benefit. For example, the parser could require you to always use
the full name of an object in a command, rather than eliding adjectives that
aren't needed because the meaning is clear from context; I don't think that
would be a benefit. To me, USE is very much the same thing in certain
cases: the meaning is so clear from context that I really want to use USE
instead of figuring out what other phrasing the author had in mind. Note
that I'm not saying that the other phrasing shouldn't also be accepted.
Mike Roberts
> Maybe there should be a default verb attached to a few
> select objects that can be accessed with merely "USE"
> ("use toilet", "use computer", etc.). Most other things,
> however, could return the message: "You'll have to be
> more specific as to how you want to use it."
I think that would be just about perfect. I don't think USE is the most
natural verb most of the time, but once in a while it just is.
In cases where an object can be used in a couple of different ways, and
especially in cases where a guess-the-verb situation is likely because of
special phrasing, the standard USE reply could elaborate on the other uses:
"You'll have to be more specific - you can type something on the keyboard,
you can run an application by clicking on its icon, or you can press the
Print Screen button to print out what's on the screen."
Rikard Peterson
But to a new player (esp. someone that has played graphical adventure
games), I think it is a good thing to be required to think beyond
"use object". Being given an error message when typing Use forces the
player to start to think differently, which is a good thing.
I like being required to "turn TV on" instead of "use TV" or "shovel
manure" instead of "use shovel with manure". I probably don't like
"guess the verb" any more than you do, but I don't think Use is the
answer.
If I encounter an object that I don't know how to use, I'd prefer the
game to hint at its useage rather than being allowed to type "USE
OBJECT". The examine-text for the shovel could mention that it can be
used to shovel things around. Examining the toilet may say something
about sitting down on it... And of course different phrasings is
good, but I still think Use is too generic.
Rikard
Mike Roberts
> I like being required to "turn TV on" instead of "use TV" or
> "shovel manure" instead of "use shovel with manure". I
> probably don't like "guess the verb" any more than you do,
> but I don't think Use is the answer.
I think we're basically in agreement on this much - I'm certainly not
suggesting that text games should go the graphical adventure route and
replace every verb with USE. I'm also not suggesting that USE ought to be
accepted as a synonym for every other verb. My point is rather than there
are times when USE is a perfectly natural way of stating something, and I
think it's good for games to accept that phrasing when that's the case. I
think it's especially called for when it's *the most* natural phrasing,
which doesn't happen frequently but does happen.
> If I encounter an object that I don't know how to use, I'd
> prefer the game to hint at its useage rather than being allowed
> to type "USE OBJECT".
Again, I'm not suggesting USE OBJECT as the generic catch-all verb. I'm
just suggesting it should be allowed where it's a natural phrasing. Even
so, I have a hard time seeing how it's a problem for you as a player to be
*allowed* to type USE SHOVEL. If you don't like typing USE SHOVEL, can't
you just not type USE SHOVEL? Assuming, of course, that the game equally
well accepts DIG. (Not that I think a shovel is a case that particularly
calls for USE; this is one where I think DIG is a more natural verb. I've
just been using it as a generic example because it was the one raised
earlier in the thread.)
> But to a new player (esp. someone that has played graphical
> adventure games), I think it is a good thing to be required to
> think beyond "use object".
I don't know; I just find it an odd mindset to think in terms of forcing
players to enjoy a game "the right way." I don't think text IF will attract
all that many new players, especially from the graphical adventure world, if
authors think they're on a mission to train players on the proper mode of
game appreciation. It's a little reminiscient of people who insist that I'm
missing something because I don't like peas; peas taste so yummy, they say,
I'm really missing out on this great yumminess experience by incorrectly not
liking them. I'm especially skeptical of the idea that the parser ought to
be part of the challenge of playing a game; maybe it's just my tastes, but I
see the parser as a user interface, and I think user interfaces should be as
transparent as possible.
Magnus Olsson
Rikard Peterson <trumg...@bigfoot.com> wrote:
>If I encounter an object that I don't know how to use, I'd prefer the
>game to hint at its useage rather than being allowed to type "USE
>OBJECT". The examine-text for the shovel could mention that it can be
>used to shovel things around.
Yes, I've seen this done; things like "To use the magic wand, type
'AIM WAND AT OBJECT'". It's a minor mimesis-breaker, of course, since
the "narrator" steps out of the story and starts discussing game
mechanics, but IMHO it's not much worse than having parser responses
like "I don't understand the word 'FROBNICATE'". And (again IMHO) it's
infinitely preferable to guess-the-verb problems.
The problem with "use", as I see it, is that it can cause gameplay to
degenerate into "take everything, examine everything, use everything",
similarly to the way some graphic games degenerate into "click on
everything and see if something happens".
--
Magnus Olsson (m...@df.lth.se)
PGP Public Key available at http://www.df.lth.se/~mol
Paul Drallos
> I probably don't like
> "guess the verb" any more than you do, but I don't think Use is the
> answer.
>
> If I encounter an object that I don't know how to use, I'd prefer the
> game to hint at its useage rather than being allowed to type "USE
> OBJECT".
Actually, you have stumbled on a great use for 'USE' here.
"Guess the verb" often comes up and it can be very frustrating.
'USE' could be a nice way to present a hint about the verb or
syntax that is needed. So the player types 'use widget' and the
game could reply, 'In order to use the widget you will need to
SWING the widget at the <object>. The programmer might want to
put something like this in for cases where he knows player may
have difficulty guessing the verb.
Quintin Stone
> The problem with "use", as I see it, is that it can cause gameplay to
> degenerate into "take everything, examine everything, use everything",
> similarly to the way some graphic games degenerate into "click on
> everything and see if something happens".
Agreed. But then this is why I would only support the verb being helpful
in a few very particular and isolated cases where its usage is the MOST
perfectly natural response. Everything else would basically return a
"You'll have to be more specific" message. At the very least, that
message would be a little more comforting and helpful to the new player
than just "I don't know the word 'use'."
Mike Roberts
> The problem with "use", as I see it, is that it can cause
> gameplay to degenerate into "take everything, examine
> everything, use everything", similarly to the way some
> graphic games degenerate into "click on everything and
> see if something happens".
A valid concern, to be sure. But is the user interface really the right
place to be fixing the problem that a game isn't interactive enough? Isn't
it better to keep the player from *wanting* to approach the game that way,
rather than using the UI to force them not to?
It seems to me that the essence of the adventure game is in creating the
illusion that the game isn't a mechanical process; I think it's the only
kind of game where this is true, so maybe it's even the defining feature.
But I don't think the illusion can be created or maintained by forcing the
player to behave a certain way. I think the game has to get the player to
be an active participant in maintaining the illusion, and when you can do
that, the player won't want to ruin the illusion by reducing the game to a
mechanical exercise. Getting that active collaboration with the player
going isn't trivial, but I think it's like suspension of disbelief in static
fiction - you get it by default, because the whole reason they're watching
your movie or playing your game is that they *want* that experience of being
caught up in another reality. So you don't necessarily have to win it, you
just have to avoid losing it. I personally think using the UI to force the
player to behave a certain way is counterproductive, because it will only
frustrate the player, and call attention to the UI, both of which reduce the
player's will to maintain the illusion.
Rikard Peterson
> I'm especially skeptical of the idea that the parser ought to be part
> of the challenge of playing a game; maybe it's just my tastes, but I
> see the parser as a user interface, and I think user interfaces
> should be as transparent as possible.
I agree. But for a user interface to be transparent, you have to
understand how it works. Think of all the courses given to help people
get started with the very basics of Windows that are second nature to
most of us computer users. My main point is simply that the lack of a
Use verb helped me understand how to play text games. I realise that
it's just a single datapoint (me) but it may apply to others as well so
authors should think twice before implementing Use.
Then again, maybe I'm just weird. :)
Rikard
Andrew Plotkin
> "Magnus Olsson" <m...@df.lth.se> wrote:
>> The problem with "use", as I see it, is that it can cause
>> gameplay to degenerate into "take everything, examine
>> everything, use everything", similarly to the way some
>> graphic games degenerate into "click on everything and
>> see if something happens".
> A valid concern, to be sure. But is the user interface really the right
> place to be fixing the problem that a game isn't interactive enough? Isn't
> it better to keep the player from *wanting* to approach the game that way,
> rather than using the UI to force them not to?
Yes.
Unfortunately, players always play games the way they don't want to.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
L. Ross Raszewski
>
>"Guess the verb" often comes up and it can be very frustrating.
>'USE' could be a nice way to present a hint about the verb or
>syntax that is needed. So the player types 'use widget' and the
>game could reply, 'In order to use the widget you will need to
>SWING the widget at the <object>. The programmer might want to
>put something like this in for cases where he knows player may
>have difficulty guessing the verb.
>
See, I'm not sure about this.
If the game can tell me absolutely that the verb I'm looking for is
'swing', then it should just *do* it.
It really bugs me when I try an invalid syntax, and the game tells me
the <exact> right syntax; if the parser knows what I meant, then it's
just being a bitch.
Now, if >USE WIDGET responded "You'll have to be more specific."
that's fine; the parser doesn't know what I want to do. But ">USE
WIDGET" "You have to say FROBNICATE WIDGET for this to work." smacks
of "I know what you want to do, but you're going to have to play by my
rules or not at all."
Mike Roberts
> My main point is simply that the lack of a Use verb helped
> with playing graphical adventures].
Okay, that makes sense - sort of a built-in training system that reminds you
from the outset not to approach it the same way you would a graphical
adventure. But I really think you'd still get that effect if the game
responded to USE with "You'll have to be more specific" *most* of the time,
but accepted it for those few cases where it truly is a/the natural verb.
Or maybe text games just need some "mindset detection system" - something
like the subtle trick LGOP uses to get you to identify your sex at the
beginning of the game. Such as: If you click on the picture of the linking
book in the first scene, the game turns off USE entirely; if you type in
ENTER LINKING BOOK, you get the occasional USE where it's natural. (But if
you type USE LINKING BOOK, who knows. :)
Joe Mason
> See, I'm not sure about this.
>
> If the game can tell me absolutely that the verb I'm looking for is
> 'swing', then it should just *do* it.
>
> It really bugs me when I try an invalid syntax, and the game tells me
> the <exact> right syntax; if the parser knows what I meant, then it's
> just being a bitch.
>
> Now, if >USE WIDGET responded "You'll have to be more specific."
> that's fine; the parser doesn't know what I want to do. But ">USE
> WIDGET" "You have to say FROBNICATE WIDGET for this to work." smacks
> of "I know what you want to do, but you're going to have to play by my
> rules or not at all."
Hmm, that gives me an idea. What if USE WIDGET said, "Some common ways
of interacting with widgets are the FROBNICATE, FIDDLIZE, and FOOZLE."
The game has no way of knowing which you actually mean at this time, but
it still gives you some syntax help. (And this would be especially
helpful, as another poster noted, for people just coming from graphic
adventures.)
Joe
gm...@rzu-mailhost.unizh.ch
<mjrUND...@hotmail.com> wrote:
>
> In cases where an object can be used in a couple of different ways, and
> especially in cases where a guess-the-verb situation is likely because of
> special phrasing, the standard USE reply could elaborate on the other uses
just want to offer my opinion as a player here...as a non-native english
speaker I really, really hate to get stuck in a guess-the-verb trap! It
did not happen often, luckily, but sometimes yes, particularly when the
author implements just one particular verb for a certain action. Just an
example, when you have to cut down a tree with an axe, it is certainly
more polished to say "chop tree", but what about allowing also to "use
axe" or "hit tree with axe"? My point here is that sometimes allowing the
use of simple verbs (it was USE in this thread, but the argument can be
made more general), even just replying to it with a hint to the right verb
to be used, will greatly facilitate people whose english vocabulary is
somehow limited (like me). Just want to add one thing here...I do not know
whether people ever considered it, but in my experience IF-playing was a
very amusing way to improve my english, which was very "technical" and
limited, by learning very simple and common words of everyday use (which
you generally do not find on textbooks or grammars). So, I think that
every IF-author who is spreading his work on the net, should be aware that
his piece of IF could also have an "instructive" or "educational" role.
Since I am not an author, I really do not know what this could change in a
IF writer's mind, but I wanted just to let you know my opinion.
Thanx to all the IF-writes who gave me hours of real good time! Happy
adventuring. Giovanni
Paul Drallos
Oooooo. I like that!
Kathleen
> In article <8da7a47a.03042...@posting.google.com>, Freddy wrote:
> > Interesting that most people responded as a game designer and not as a
> > player. I was really hoping for player opinions but do appreciate all
> > the feedback.
>
> I certainly meant to respond as both. I think that the problem with USE is
> its genericity. It's useful only in cases where it is the most likely verb
> I'd use in normal speech. "use toilet" and "use computer" and "use back
> massager" are indeed good examples.
Although - just to be difficult, here - what exactly should USE
COMPUTER do? Should it print something? Break into the ulti-secret
goverment agency? Display a receipe for Cheez Whiz...
Perhaps USE would be nice for sci-fi scenery things, where the correct
verb for an object isn't readily apparent and discovering it is
irrelevant.
> USE FLUMBOBBLE
You zapple the flumbobble, instantly reducing yourself to a pile
of ash.
> Even those, though, have replacements which should be supported -- I generally
> never, ever use the 'use' verb in a game, largely because I assume it will be
> unimplemented.
Agreed - though a simple message in the ABOUT would take care of that.
Kathleen
Edmund Kirwan
> On 23 Apr 2003 10:42:31 -0700, dem...@hotmail.com (Freddy) wrote:
>
> I don't really like 'USE' as a verb. As stated by others in this
> thread, it take a lot more coding then you'd expect, since what you
> basically do is provide a general synonym for lots of very different
> actions. And people have different expectations for a single 'USE"
> command:
>
> You are in a kitchen.
>
> You see Chester the cat here.
>
> Some food lies on the counter.
> >Take food
> Taken.
>
> >Use food
> You eat the tasty food. Yummy!
>
> At which point the player is annoyed, since he wanted to feed the cat.
>
> I do, however, usually write a short 'USE' verb, which only prints out
> a message to satisfy any logical input. Something like:
>
> >USE FLASHLIGHT
> Ah yes! But how?
>
> Which teaches the player he has to be specific.
Amazing. As I read each line of this reply, I thought, "No, that's
crap!" And then at the end, I thought, "Oh, yeah, that actually good."
I think this thread has been answered by:
a) Programmers saying that they don't like, "Use," because it's
difficult to implement.
b) Players saying that they like, "Use," because it helps them to
understand what objects are for.
If you want, "Customers," for your game, go with (b) and give (at
least) cursory alternatives to, "Use," whenever anyone tries it ...
.ed
/==================\
www.edmundkirwan.com
"It's not very good."
Andrew Plotkin
> I think this thread has been answered by:
> a) Programmers saying that they don't like, "Use," because it's
> difficult to implement.
> b) Players saying that they like, "Use," because it helps them to
> understand what objects are for.
Well, no. See the long string of posts, the recent ones, in which
*designers* dislike it because it can enable a non-fun path through
the game.
Ahab
shortcut to finding the function(s) of the item in question.
Personally I try 'use' in desperation when I reckon I'm on the right track
but have exhausted (or think I have) all other options.
Getting no recognition at all of a fairly logical input while already at
screaming point just produces the 'fuck it' response and the resulting
exodus of players to the pub to drown their frustration.
In the end if it works in your game, use it, if not don't - what's to
debate?
Just my humble opinion.
William Burke
ade...@eircom.net (Edmund Kirwan) wrote:
> I think this thread has been answered by:
> a) Programmers saying that they don't like, "Use," because it's
> difficult to implement.
> b) Players saying that they like, "Use," because it helps them to
> understand what objects are for.
this isn't what I'm getting from the thread at all. mostly what I heard
was:
a) designers saying that "use" is contrary to the way they want their
game played.
b) players saying, mostly, that "use" avoids guess-the-verb problems.
note especially Mike Roberts:
> There are some objects whose function is
> simply obvious, and there are times when a verb phrasing is anything but,
> and it's happened to me at least a few times that those two conditions
> coincided perfectly.
and
> To me, USE is very much the same thing in certain
> cases: the meaning is so clear from context that I really want to use USE
> instead of figuring out what other phrasing the author had in mind.
of course, if you can't figure out what verb you're supposed to be using
when your objective is obvious from context, then there's a more
fundamental design problem. so if I were to draw a conclusion from this
thread, it would be to implement use as a verb that always does the
"sensible" thing with an object, so that it will dig with a shovel, open
a door with keys, or poke a fireplace with a fireplace poker, but won't
use the shovel as a club or the keys as a counterweight or the poker as
a lever handle.
this makes extra sense to me for two reasons: first, the average
non-degenerate player will only be typing USE when he thinks the way he
wants to use the object should be obvious, so making it do the obvious
thing should handle almost all the appropriate situations, and beta
testing will hopefully catch the rest. secondly, this encourages you to
create puzzles that are a little more complicated and lateral than just
picking up an object and applying it in the standard way, since if you
do that the player may well USE his way through the entire game.
--p
Ben Caplan
experience with IF at all, or even graphical adventures. There are probably
people here who remember playing ADVENT for the first time way back when it
was first released. How much guess-the-verb did you play? Did you try USE?
It's a fairly common verb. How long did it take you to discover that you had
to press [enter] after each command?
If a game can be won easily by putting all visible objects to their most
naturally obvious uses (dig with shovel, flip light switch, read book), then
the game needs some fundamental redesigning.
The real problem is that everything that's been said on this thread so far
is correct.
----------------------------------------------------------------
Ben Caplan -- philosopher, linguist, and thaumaturge
Mike Arnautov
> Okay, I'm all over the place now. Both points are valid. But with the
> complex parsers of today, as a player I don't expect the game to
> understand general commands, only specific. So I usually don't even
> try 'USE' anymore but try to think of a natural way to interact with
> objects.
I got to see many player logs of adv660 nearly 20 years ago. Comparing my
memory of those logs with the ones I've seen recently in beta-testing
adv770, I was startled to observe differences, which confirm exactly what
you are saying. These days, players expect parsers to be much more finicky,
and as the result insist on being unnecessarily specific. It confirmed my
strong suspicion that the art of intelligent defaulting is dead or dying in
IF.
> I guess it is because of limitations in old parsers that they were
> often elegantly coded in such a way that USE was a naturally way to
> play the game. The question is: do we want to simplify the parser or
> force the player to pick his words with care?
Depends on your priorities. From my PoVS it's a no-brainer: simplify the
parser. And yes, I knnow that many would disagree. And, alas, players got
"educated" into picking their words with care. It's a loss. One of these
days I will write that paper entitled "Complex Parsers Considered Harmful".
AFAICS they've caused a lot of damage to IF.
YMMV, but I don't care! :-)
--
Mike Arnautov
Andrew Plotkin
> I got to see many player logs of adv660 nearly 20 years ago. Comparing my
> memory of those logs with the ones I've seen recently in beta-testing
> adv770, I was startled to observe differences, which confirm exactly what
> you are saying. These days, players expect parsers to be much more finicky,
> and as the result insist on being unnecessarily specific.
Adventure is a strange case. It has puzzle requirements which, even a
few years later, would be considered design solecisms.
(I'm thinking of the "KILL DRAGON" sequence. And the puzzle where,
without any hints at all, you have to realize that typing "XYZZY" or
"FEE" is meaningful.)
> It confirmed my strong suspicion that the art of intelligent
> defaulting is dead or dying in IF.
I really don't think the language has changed much since 1983-ish --
at least among people who came in through Infocom games. So if it's
dying, then the entire history of modern IF has appeared it was
morbid.
>> I guess it is because of limitations in old parsers that they were
>> often elegantly coded in such a way that USE was a naturally way to
>> play the game. The question is: do we want to simplify the parser or
>> force the player to pick his words with care?
> Depends on your priorities. From my PoVS it's a no-brainer: simplify the
> parser. And yes, I knnow that many would disagree. And, alas, players got
> "educated" into picking their words with care. It's a loss.
I keep reading these paragraphs and thinking, "A *simple* parser
requires you to pick your words carefully. A *complex* parser allows
options and intelligent defaults."
Obviously, a game can use a complex parser poorly. A big part of my
design time is spent on the question: "The player knows what he wants
to do. What might he type?"
Mike Arnautov
>> I got to see many player logs of adv660 nearly 20 years ago. Comparing my
>> memory of those logs with the ones I've seen recently in beta-testing
>> adv770, I was startled to observe differences, which confirm exactly what
>> you are saying. These days, players expect parsers to be much more
>> finicky, and as the result insist on being unnecessarily specific.
>
> Adventure is a strange case. It has puzzle requirements which, even a
> few years later, would be considered design solecisms.
That's as maybe, but I am talking about ordinary actions. E.g. players
insisting on typing "OPEN DOOR" rather than just "OPEN", even though the
door is the only openable object present. It goes deeper than that too. The
beta testers uniformly typed "EXAMINE" in full, even though vocabulary
command clearly gives "X" as a synonym, and the instructions state that
everything is abbreviable to the shortest unambiguous length (so as it
happens, "EX" would do too). That certainly wasn't the case back in the
80s. And it's not that people are more used to keyboards these days -- the
players whose logs I saw all those years ago were seasoned computer users.
> (I'm thinking of the "KILL DRAGON" sequence.
Case in point. It used to be just "KILL" most of the time, 'cause there
wasn't anybody else there to attack. Now everybody types "KILL DRAGON".
Similarly, nobody now uses naked "GET" (let alone abbreviating it to "G",
as vocabulary suggests) to pick up a single present portable object.
>> It confirmed my strong suspicion that the art of intelligent
>> defaulting is dead or dying in IF.
>
> I really don't think the language has changed much since 1983-ish
The language hasn't (did I suggest it did?). What appears to have changed is
that players are no longer willing to trust the game to do the appropriate
defaulting. Probably quite rightly too. How many modern games would do as
the old Adventure did, and do the right thing in response to "OPEN" by the
locked grate, provided you were carrying the keys? Or how many code for
"FOLLOW PATH"?
>> Depends on your priorities. From my PoVS it's a no-brainer: simplify the
>> parser. And yes, I know that many would disagree. And, alas, players got
>> "educated" into picking their words with care. It's a loss.
>
> I keep reading these paragraphs and thinking, "A *simple* parser
> requires you to pick your words carefully. A *complex* parser allows
> options and intelligent defaults."
Allows, yes, but that doesn't mean that's how it is typically used. It's a
question of the respective sizes of the command space. A typical author
will put only so much effort (often not much effort :-) into covering all
possible ways in which a player might specify a particular action. With a
simple parser this will result in a proportionally greater coverage than
with a complex one. Given the reasonable assumption of roughly the same
amount of effort being put into it in both cases, the outcome is not hard
to foresee -- games using complex parsers will be typically more picky. The
occasional brilliant exception does not disprove this. Player habits are
not formed by exceptions but by the standard fare.
No, I am not claiming that things were better in some imaginary Golden Age
of IF. About a year ago I made a list of all possible commands a player may
give in trying to do something as simple as exiting from the brick
well-house in Adventure. It was surprisingly long. And when I tried the
list on the good old adv660 (which I fondly think was better than most in
this respect :-), I was unpleasantly surprised to see just how few of them
actually worked. Depressing, really.
> Obviously, a game can use a complex parser poorly. A big part of my
> design time is spent on the question: "The player knows what he wants
> to do. What might he type?"
Yup. A huge chunk of adv770 development was spent on that -- despite my
decision to go for tradition and stick with a simple parser; I shudder to
think at the effort that would have to go into it with a complex one! And
then players went ahead and typed something else altogether, causing me no
end of extra work. :-)
But the point of my diatribe against complex parsers is not that they are
bad per se. Merely that they came in far too early, before IF had the time
to establish cultural norms, which would have mitigated the ease with which
complex parsers can be (and are) abused.
--
Mike Arnautov
Mike Roberts
> From my PoVS it's a no-brainer: simplify the parser. And yes, I
> knnow that many would disagree. And, alas, players got "educated"
> into picking their words with care. It's a loss. One of these days I
> will write that paper entitled "Complex Parsers Considered Harmful".
> AFAICS they've caused a lot of damage to IF.
I can understand why you've formed this impression, but I think you've
confused cause and effect. The differences you have observed have nothing
to do with parsers having become more finicky; the differences come from the
world model become richer. The title I'd suggest for your paper is
"Simulationist World Models Considered Harmful," because it's the richness
in the world model that's creating the need for more precise input. The
parsers in today's major systems do a fine job of inferring meaning from
context; Advent only created the illusion that it was doing that by having
an extremely limited context. If you were to put an Advent-style parser on
top of a modern game's world model, you'd have the strange situation that
the world model would be capable of representing things that the input
language couldn't express. As a trivial example, in a room containing a
desk and a shelf, there would be no way to specify that you wanted to put
something on one or the other of them. If you don't like that level of
complexity, your beef is with the world model, not the parser.
Today's graphical adventures are roughly on par with Advent in terms of
richness of world model, which I think serves as an existence proof that
Advent-class world models can still be used to create satisfying games.
(That's an argument you can use in your paper, to counter the claim some
people would make that Advent was only successful with its limited world
model because of its novelty.)
I personally wouldn't be too enthusiastic about a renaissance of
Advent-level text games, though. As a player, I don't mind the limitations
of graphical adventures; if anything, the simpler the better when it comes
to point-and-click interfaces. But I find such a limited world model to
feel almost claustrophobic when rendered in text format. There's something
about the verbal input format that makes me really want my indirect objects.
Whenever I play a two-word-parser game, I have this unpleasant feeling of
being unable to express my intentions.
Rikard Peterson
news:3eac18d2$0$962$cc9e...@news.dial.pipex.com:
> That's as maybe, but I am talking about ordinary actions. E.g.
> players insisting on typing "OPEN DOOR" rather than just "OPEN",
> even though the door is the only openable object present. It goes
> deeper than that too. The beta testers uniformly typed "EXAMINE"
> in full, even though vocabulary command clearly gives "X" as a
> synonym, and the instructions state that everything is abbreviable
> to the shortest unambiguous length (so as it happens, "EX" would
> do too). That certainly wasn't the case back in the 80s. And it's
> not that people are more used to keyboards these days -- the
> players whose logs I saw all those years ago were seasoned
> computer users.
Exactly. I'd say that it's the opposite. Those people in the eighties
were probably more used to typed commands. To me, "Open Door" seems
more natural to type than "Open" which seems much more like a computer
command. You might as well type "grep" or "rm". Abbreviations are
handy, but they have to be learned. The most natural thing to type is
the full command. At least, that's how I think my mind works.
Rikard
L. Ross Raszewski
>Exactly. I'd say that it's the opposite. Those people in the eighties
>were probably more used to typed commands. To me, "Open Door" seems
>more natural to type than "Open" which seems much more like a computer
>command. You might as well type "grep" or "rm". Abbreviations are
>handy, but they have to be learned. The most natural thing to type is
>the full command. At least, that's how I think my mind works.
Um. Maybe I'm missing something, but what you're saying makes no sense
to me.
I mean, yes 'open door' sounds more natural than 'open', but 'open'
sounds more like a computer command? The examples you cite, 'grep'
and 'rm' don't follow through with this analogy; you type 'grep' or
'rm' into a shell with no further arguments, and you'll get an error;
there are very few commands in a command-line driven computer system
which don't take further arguments. I don't see any parallel between
the 1-word parser and using a command-based computer interface; on the
contrary, I'd think that the later parsers (Though not so advanced as
the modern adjective and preposition-supporting variety) would be more
similar to the sorts of commands one would give to a computer.
Joe Mason
I think he's just saying that the mindset that complains about "OPEN"
vs. "OPEN DOOR" is the same mindset that complains about "CP" vs.
"COPY".
Joe
Mike Roberts
> mjr:
> > Isn't it better to keep the player from *wanting*
> > EXAMINE/TAKE/USE space] rather than using
> > the UI to force them not to?
>
> Yes.
>
> Unfortunately, players always play games the way they don't
> want to.
True enough. Even so, I guess I'd rather not approach designing a game as
an exercise in thwarting the player; I mean, if it's to be a contest between
author and player, then it's no contest at all, as the author holds all the
cards.
One thing I've noticed as a player in games that are "too easy" is that I'm
sometimes more willing in these games to intentionally slow things down, by
looking at scenery or randomly playing with interactive elements. That
doesn't last long unless the scenery is interesting and the random fussing
is rewarded somehow, but when these conditions do hold, I've found myself on
occasion intentionally holding back from letting the story advance, because
I as the player wasn't quite ready for it yet. My point being that there
might be times when letting players brute-force their way through portions
won't necessarily hurt the experience as much as many authors seem to fear.
Quintin Stone
> Case in point. It used to be just "KILL" most of the time, 'cause there
> wasn't anybody else there to attack. Now everybody types "KILL DRAGON".
> Similarly, nobody now uses naked "GET" (let alone abbreviating it to
> "G", as vocabulary suggests) to pick up a single present portable
> object.
Actually, I do quite often. :) Though, that's about the only verb that I
let the game try to default the direct object.
Rikard Peterson
news:D02ra.10719$B61....@nwrddc01.gnilink.net:
> On 27 Apr 2003 22:04:52 GMT, Rikard Peterson
> <trumg...@bigfoot.com> wrote:
>>Exactly. I'd say that it's the opposite. Those people in the
>>eighties were probably more used to typed commands. To me, "Open
>>Door" seems more natural to type than "Open" which seems much more
>>like a computer command. You might as well type "grep" or "rm".
>>Abbreviations are handy, but they have to be learned. The most
>>natural thing to type is the full command. At least, that's how I
>>think my mind works.
>
> Um. Maybe I'm missing something, but what you're saying makes no
> sense to me.
That's not unusual. That I make no sense, I mean. I'll try again.
> I mean, yes 'open door' sounds more natural than 'open', but
> 'open' sounds more like a computer command? The examples you
> cite, 'grep' and 'rm' don't follow through with this analogy; you
> type 'grep' or 'rm' into a shell with no further arguments, and
> you'll get an error; there are very few commands in a command-line
> driven computer system which don't take further arguments. I don't
> see any parallel between the 1-word parser and using a
> command-based computer interface; on the contrary, I'd think that
> the later parsers (Though not so advanced as the modern adjective
> and preposition-supporting variety) would be more similar to the
> sorts of commands one would give to a computer.
Ok, "grep" and "rm" were bad examples. My theory is that typing "Open"
isn't something that comes natural. If you get a description with a
closed door, only someone who thinks of the parser as a command line
(or someone with IF experience, trained to use shortcuts) will type
"Open" instead of "Open Door". Today, much less computer users have
seen a command prompt than in the eighties. That could (at least
partly) explain the differences that Mike Arnatuov saw.
Maybe I'm way off, though.
Rikard
Mike Arnautov
> Exactly. I'd say that it's the opposite. Those people in the eighties
> were probably more used to typed commands. To me, "Open Door" seems
> more natural to type than "Open" which seems much more like a computer
> command.
You have the strangest notions of the command line interfaces. The exact
reverse is true. If a computer command takes an argument, that argument is
not optional. if I type "rm" (or "delete" or "erase", depending on the O/S)
I don't expect the command to delete a file I haven't specified. I *have*
to type "rm filename". Inferring the meaning of incomplete instructions is
what humans do. Not computers.
> You might as well type "grep" or "rm". Abbreviations are
> handy, but they have to be learned.
Except that those commands aren't abbreviations. They may be derived as
abbreviations of words, but as commands they *are* the full commands. And
they cannot be abbreviated. That's my gripe about CLIs -- I cannot see why
they have to be so rigid. They should allow proper words as commands *and*
abbreviations.
> The most natural thing to type is
> the full command. At least, that's how I think my mind works.
Really. Well, if you always type "go west" instead of "w", I'd say you are
merely strange. OTOH if you do type "w", I'll call you inconsistent. In
either case you have been educated by poor use of complex parsing into
believing that use to be natural. If somebody texts you with "thnx", do you
reply "There is no such verb"? Or do you interpret what they mean? The
latter, I guess. Which is what IF games should do.
--
Mike Arnautov
http://www.mipmip.dsl.pipex.com
Mike Arnautov
> I can understand why you've formed this impression, but I think you've
> confused cause and effect. The differences you have observed have nothing
> to do with parsers having become more finicky; the differences come from
> the
> world model become richer. The title I'd suggest for your paper is
> "Simulationist World Models Considered Harmful,"
No, no... That's my *other* proposed paper! :-) That is also true, but for
rather different reasons. Don't you start me on *that* one. Or you'll get
me pontificating on all over again on the need to re-discover the roots of
IF in verbal expression by the author, instead of tying to do a Doom in
words.
Er, where were we?.... Oh yes...
> because it's the richness
> in the world model that's creating the need for more precise input.
No, I don't think I got it the wrong way round. I think I am just looking
further back in time. Complex parsers allowed more complex worlds, which in
turn almost inevitably led to a rampant misuse of complex parsers.
> The
> parsers in today's major systems do a fine job of inferring meaning from
> context; Advent only created the illusion that it was doing that by having
> an extremely limited context. If you were to put an Advent-style parser
> on top of a modern game's world model, you'd have the strange situation
> that the world model would be capable of representing things that the
> input
> language couldn't express. As a trivial example, in a room containing a
> desk and a shelf, there would be no way to specify that you wanted to put
> something on one or the other of them.
I am not suggesting any such "back to mono" equivalent. I am just pointing
out that the use of parser complexity should be restricted to situations
where it is actually necessary. Which is *far* from as often as it gets
inflicted on players.
Let me give you a few examples from a game that's been irritating me a few
days ago. It happens to be Andrew Plotkin's "So Far" (sorry Andrew, nothing
personal -- you just happened to pull the short straw :-). I quote from
memory, so probably imprecisely in detail, but near enough:
You are told that you are standing by the west wall of the auditorium:
EXAMINE WALL
Which wall do you want to examine? The north, east, west, south, northeast,
southeast, southwest or northwest one?
EXAMINE WEST WALL
There is nothing special about the wall.
That's *horrible*! But it gets worse. You get exactly the same respons
standing outside the theatre, with the busy street to the south of you.
Which wall do you wish to exanmine, the north, east, west...? And if you
say south, you are told there is nothin special about it. South wall???
Where????
Or take the start of the game. You are in the theatre and a dramatic action
onfolds in front of you. Then you get the command prompt:
WATCH
What do you want to watch?
Helloooo!! Is anybody home? Obviously not...
Or take the fact that I cannot "LOOK WALL", it has to be "LOOK AT WALL". Now
before you say anything about good grammaticla English, let me point out
that "GO THROUGH DOORWAY" results in "You can't see any such object.", yet
"GO DOORWAY" does the trick. Or observe that "GET" results in "What do you
want to get?" while "DROP" does drop the single object you are carrying.
It's hardly surprising that players don't trust games to do the right thing,
and insist in typing out maximally specific commands. I am sorry to say
that after a while of that sort of thing, I just give up. (The game commits
sins of ohter kinds too, but those do not fall into the parsing category,
so I'll stop being nasty to it. :-)And to be fair to Andrew, he *is* aware
of the problem and does seem to put some effort into avoiding such
atrocities. But it's not easy.
> If you don't like that level of
> complexity, your beef is with the world model, not the parser.
As I hope is obvious from the above, my beef is with the parser and with
authors' inability to tame it. I have some sympathy -- it *is* hard. But
why should the player care whether it is hard? And why no attention is
being paid to possible ways of making the taming easier?
As a player, what I value in an "IF experience" is the feel that I am not
merely runnnig a program, just like in reading a book I don't just read the
words -- in both cases I value the feeling that however indirectly, I am
communicating with the author, or to be more precise, the author is
communicating with me. As you would expect, the kind of thing quoted above,
destroys any such illusion pretty pronto.
In fact, as a player, I would go even further. If I am instructing somebody
else who tells me that he is standing in a corridoor by a closed door, and
I want him to enter the room behind, I'd just tell him to go in --
expecting either a success or a statement that the door is locked. Why
playing a game, should I say "open door" before saying "go in" (assuming
the author remembered to allow for it)? And if I should, why not also give
instructions to grasp the handle (or is it a knob?) and turn it (up? down?
clockwise? anticlockwise?) and push the door (or should it be pull?).
Ridiculous? Sure... My point exactly. I cannot see why the game should not
Do The Right Thing. It would be too easy to play? Well, sorry, as a player,
I have no interest in playing a game which becomes too simpe as the result.
Russell Wallace
wrote:
>Exactly. I'd say that it's the opposite. Those people in the eighties
>were probably more used to typed commands. To me, "Open Door" seems
>more natural to type than "Open" which seems much more like a computer
>command.
They're both computer commands. Neither is a grammatically correct
English sentence (they're both derived from English words, yes, but so
are "grep" and "rm"), and neither even vaguely resembles what you'd
actually say.
Think about it: in a roleplaying game with a human GM (the closest
non-computer situation to a text adventure), you'd probably say
something along the lines of "Okay, I try the key - does it work?
Great, I head inside then." That doesn't remotely resemble anything
any adventure game parser can understand.
Now, if you think making your parser understand "open" as well as
"open door" would be a poor use of resources, that's fine - but it's a
question of resource allocation, not of anything being more or less
natural. And if enough authors do this, players will end up expecting
they can't abbreviate "open door" to open, but that's no different
than DOS users expecting they can't abbreviate "copy" to "cp".
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Russell Wallace
>Although - just to be difficult, here - what exactly should USE
>COMPUTER do? Should it print something? Break into the ulti-secret
>goverment agency? Display a receipe for Cheez Whiz...
Depends on the context. To take one that's actually likely to come up
in a game, suppose I'm sneaking around the offices of the government
agency looking for the top secret data file, then telling a text
adventure program:
> USE COMPUTER
should communicate the same thing as telling a human GM:
"Okay, I turn on the computer and sit down at it and see if I can find
the data file or anything that might lead me to it."
Even a dumb program can reasonably be expected to know that printing a
recipe for Cheez Whiz is unlikely to be the player's objective here :)
Rikard Peterson
news:3eada719$0$11382$cc9e...@news.dial.pipex.com:
<snip>
Yes, it was a mistake of me to mention rm and grep. It just confused
what I was trying to say.
>> The most natural thing to type is
>> the full command. At least, that's how I think my mind works.
>
> Really. Well, if you always type "go west" instead of "w", I'd say
> you are merely strange. OTOH if you do type "w", I'll call you
> inconsistent.
Yes, I type w, but I don't think that make me inconsistent. I'm not
arguing that parsers shouldn't let a simple "Open" command work. All I
really was trying to say was that I think there probably are other
explanations for the differences you had observed in players that are
at least as valid as yours, which I don't buy. I don't think it's so
much about lack of trust as a belief that the computer actually
understand what you type.
(Besides, nobody would type w without being told that w is valid
input.)
> In either case you have been educated by poor use of
> complex parsing into believing that use to be natural.
Have I? Russell Wallace said in another post in this thread:
"Think about it: in a roleplaying game with a human GM (the closest
non-computer situation to a text adventure), you'd probably say
something along the lines of "Okay, I try the key - does it work?
Great, I head inside then." That doesn't remotely resemble anything any
adventure game parser can understand."
I am a less verbose person, so I would probably just say "Open the
door" which is more or less what I would type in a computer game. But
even I would not say "Open". Once again, I'm not against "Open" or any
other shourtcuts - they're great - but if you want it to be easy to
play the game you shouldn't remove the longer, more natural form
either.
> If somebody texts you with "thnx", do you reply "There is no such
> verb"? Or do you interpret what they mean? The latter, I guess. Which
> is what IF games should do.
Actually, I probably would reply something close to the "There is no
such verb" option, but I freely admit that's (at least partly) beacuse
I'm weird. :)
Rikard
Mike Roberts
mjr:
> > [...] it's the richness in the world model that's creating
> > the need for more precise input [not that parsers are
> > becoming more stupid or finicky].
>
> No, I don't think I got it the wrong way round. I think I am
> just looking further back in time. Complex parsers allowed
> more complex worlds, which in turn almost inevitably led to
> a rampant misuse of complex parsers.
Okay, chicken and egg, but I still maintain it's the complexity in the world
model that requires more precision in the input language.
> [Example from actual game:] You are told that you are
> standing by the west wall of the auditorium:
>
> EXAMINE WALL
> Which wall do you want to examine? The north, east, west,
> south, northeast, southeast, southwest or northwest one?
> EXAMINE WEST WALL
> There is nothing special about the wall.
>
> That's *horrible*!
But this just proves my point. The reason you're being asked which wall you
mean is that the world model includes all those walls. In the older games
you hold up as exemplars of intelligent defaulting, there are simply no
walls in the model at all, so you most like would have seen
>look wall
You don't see any wall!!!
which isn't any better. Or maybe the game would have maintained the
illusion more thoroughly by not admitting the problem:
>look wall
What a crazy idea?!
Or maybe there's something special about the wall in this one location, so
it's actually implemented, in which case you'd get the illusion of
"intelligent default" from the parser - but it's not *really* an intelligent
default, it's just that there's nothing else modeled. The illusion that the
parser is being smart breaks as soon as you try
>look north wall
You don't see any north wall!
or perhaps more honestly
>look north wall
You don't see any two-word noun phrases!
> But it gets worse. You get exactly the same respons standing
> outside the theatre, with the busy street to the south of you.
> Which wall do you wish to exanmine, the north, east, west...?
> And if you say south, you are told there is nothin special about
> it. South wall??? Where????
Well, yes, but this would be an example of the world model being
*insufficiently* complex, not overly complex. The model in this case
attempts to create the illusion that it implements all of the necessary
walls by implementing one stock set of walls that's present everywhere.
This illusion is as paper-thin as the no-walls-at-all illusion, but has
different failure modes. Perhaps you're happier with the type of illusion
created by a sparse world model to the one created by a richer one; or
perhaps your memory of Advent is somewhat selective.
> Or take the start of the game. You are in the theatre and
> a dramatic action onfolds in front of you. Then you get the
> command prompt:
>
> WATCH
> What do you want to watch?
>
> Helloooo!! Is anybody home? Obviously not...
The thing is, most raif and rgif people would just consider this a bug. If
your claim were true that "intelligent defaulting is dead," as you put it
earlier, then would most people consider this a bug? No, they'd say: we
don't like intelligent defaults, intelligent defaults are so 1982, we're
*glad* that the game doesn't provide any. But they don't; they say: this is
a bug. I suspect I could find equally egregious cases in Advent or any
other game you'd like to hold up as an exemplar of intelligent defaulting
done right.
> Or take the fact that I cannot "LOOK WALL", it has to be
> "LOOK AT WALL".
What does that have to do with intelligent defaulting?
Okay, so your thesis goes beyond intelligent defaulting; this seems to tie
into something you were saying earlier about Celf0n T><T M5G 5PK as having
something to do with this, and how you seem to want games to accept anything
at all you want to throw at them. I guess it's all tied up in the same
thing - do what I mean, no matter how I say it.
But once again, the way you're holding up the glorious two-word parsers of
old as somehow smarter in this respect just makes no sense to me. Okay, so
Advent accepted LOOK WALL. But did it accept LOOK AT WALL? No. Did it
accept L00K W@11? Nope. How about just LOOK THE WALL? Highly doubtful.
You consider this flexible? It's like saying Unix is more flexible than DOS
because Unix accepts "cp", while DOS only accept "copy". Okay, so Unix
*only* accepts "cp", but that's okay, because it's the one you like.
Honestly, Advent's parser was as rigid as parsers come. Virtually every
game today accepts LOOK AT WALL, EXAMINE WALL, X WALL, LOOK AT THE WALL, X
THE WALL, EXAMINE THE WALL. That strikes me as way more flexible than
Advent, with its single formulation LOOK WALL. Making a modern parser
accept LOOK WALL *in addition to all of the others* would be trivial;
authors would add it in an instant if they thought enough people wanted it.
> It's hardly surprising that players don't trust games to do
> the right thing, and insist in typing out maximally specific
> commands.
Now wait a second - "it's hardly surprising"? I'd say it's hardly true. At
least, hardly proven. You looked at one other person's game transcript,
noted that that person didn't rely on defaulting much, and generalized that
into "players don't trust games to do the right thing." Did you even ask
the person who wrote that transcript about their trust issues with modern
games? And did follow up by surveying "players" to determine if there is in
fact this overwhelming consensus you claim?
> > If you don't like that level of complexity, your beef is
> > with the world model, not the parser.
>
> As I hope is obvious from the above, my beef is with the
> parser and with authors' inability to tame it.
And I hope it's obvious from the above that I still consider your beef to be
with the complexity of the world model. I'm not sure where else you think
the extra complexity in the parser would be coming from. Do you think it's
just coming more words? From accepting AT in LOOK AT? That's not
complexity; that's just different syntax for the same exact complexity.
> And why no attention is being paid to possible ways of making
> the taming easier?
I really have no idea what you have in mind here. Who ought to be paying
this attention? What possible ways?
Magnus Olsson
Mike Arnautov <m...@mipmip.demon.co.uk> wrote:
>Let me give you a few examples from a game that's been irritating me a few
>days ago. It happens to be Andrew Plotkin's "So Far" (sorry Andrew, nothing
>personal -- you just happened to pull the short straw :-). I quote from
>memory, so probably imprecisely in detail, but near enough:
>
>You are told that you are standing by the west wall of the auditorium:
>
>EXAMINE WALL
>Which wall do you want to examine? The north, east, west, south, northeast,
>southeast, southwest or northwest one?
>EXAMINE WEST WALL
>There is nothing special about the wall.
>
>That's *horrible*!
This is the default behaviour of the Inform Library - which, IIRC,
got this behaviour from Zork I. So (again IIRC) games actually
behaved this way already in the early 80's.
>But it gets worse. You get exactly the same respons
>standing outside the theatre, with the busy street to the south of you.
>Which wall do you wish to exanmine, the north, east, west...? And if you
>say south, you are told there is nothin special about it. South wall???
I agree that this particular wall silliness is horrible; an ugly wart on
the Inform Library.
>Or take the start of the game. You are in the theatre and a dramatic action
>onfolds in front of you. Then you get the command prompt:
>
>WATCH
>What do you want to watch?
>
>Helloooo!! Is anybody home? Obviously not...
This is also irritating. Just for your information, I tend to play
games like you describe your 1980's playtesters: if there's only
one obvious object for a command, I tend to leave it out, and expect
the parser to be able to default intelligently. If the game fails to
do this however, I don't blame it on an overly-complex parser, but
on an insufficiently sophisticated world model.
--
Magnus Olsson (m...@df.lth.se)
PGP Public Key available at http://www.df.lth.se/~mol
Mike Arnautov
>> No, I don't think I got it the wrong way round. I think I am
>> just looking further back in time. Complex parsers allowed
>> more complex worlds, which in turn almost inevitably led to
>> a rampant misuse of complex parsers.
>
> Okay, chicken and egg, but I still maintain it's the complexity in the
> world model that requires more precision in the input language.
Only if you take the bottom-up view -- or let the parser impose the bottom
up view on you. See below.
>> [Example from actual game:] You are told that you are
>> standing by the west wall of the auditorium:
>>
>> EXAMINE WALL
>> Which wall do you want to examine? The north, east, west,
>> south, northeast, southeast, southwest or northwest one?
>> EXAMINE WEST WALL
>> There is nothing special about the wall.
>>
>> That's *horrible*!
>
> But this just proves my point. The reason you're being asked which wall
> you mean is that the world model includes all those walls.
Which proves mine. Because the parser can parse all those purely
hypothetical walls, the model needs to include them. And if the author
doesn't handle the resulting complexity, the result is nonsense.
> Or maybe there's something special about the wall in this one location, so
> it's actually implemented, in which case you'd get the illusion of
> "intelligent default" from the parser - but it's not *really* an
> intelligent
> default, it's just that there's nothing else modeled.
So what? Your difficulty is in assuming that a model is the proper or even
the only solution. I disagree with that assumption.
> The illusion that
> the parser is being smart breaks as soon as you try
>
>>look north wall
> You don't see any north wall!
>
> or perhaps more honestly
>
>>look north wall
> You don't see any two-word noun phrases!
Sorry, but you are getting carried away. First of all, it is very rare for a
player to have to handle/examine a particular wall -- otherwise you'd have
a very boring game. The specific code to do so, can be handled by code
associated with the relevant locations. Beyond that you need just a
generalised closure which, yes, just pretends that there is a wall if
appropriate and generates the appropriate response. Is the result an
illusion? That depends on your definition of an illusion. Does the player
care whether the wall is actually there, or it is "merely an illusion" not
underpinned by a model? Absolutely no!
And doo you honestly believe that (I quote "So Far" again)
> "GO THROUGH DOORWAY"
You can't see any such object here
is any sort of improvement anyway?
> Well, yes, but this would be an example of the world model being
> *insufficiently* complex, not overly complex. The model in this case
> attempts to create the illusion that it implements all of the necessary
> walls by implementing one stock set of walls that's present everywhere.
> This illusion is as paper-thin as the no-walls-at-all illusion, but has
> different failure modes. Perhaps you're happier with the type of illusion
> created by a sparse world model to the one created by a richer one; or
> perhaps your memory of Advent is somewhat selective.
Now, now... No need to get personal! :-) But perhaps there is something
wrong with my keyboard. I *thought* I'd made clear that I was not promoting
any rose-tinted view of a lost Golden Age, and that I am happy to accept
the use of complex command parsing WHERE IT IS ACTUALLY NECESSARY. But it
would seem this is not what appeared on your screen.
As it happens, my point is exactly in the mismatch between the capabilities
of a complex parser and the capabilities of games abilities to handle that
complexity. You seem to put trust into elaborating the world model, which
to my mind amounts to rendering Doom in text -- currently a hopeless task,
and ultimately pointless too. Whether one says that the world model is
insufficiently complex for the parser, or that the parser is too complex
for the word model, it amounts to the same.
>> WATCH
>> What do you want to watch?
>>
>> Helloooo!! Is anybody home? Obviously not...
>
> The thing is, most raif and rgif people would just consider this a bug.
> If your claim were true that "intelligent defaulting is dead," as you put
> it
> earlier, then would most people consider this a bug? No, they'd say: we
> don't like intelligent defaults, intelligent defaults are so 1982, we're
> *glad* that the game doesn't provide any. But they don't; they say: this
> is
> a bug.
Curiously enough, I don't recall a single review pointing out that this game
is full of bugs. Which brings us back to my original post. I expect the
truth is that players know to type full commands and not to expect any
defaulting, so they don't see the problem and nobody complains. In fact, I
seem to recall a SPAG review, which claimed "So Far" to be "nearly
flawless" in its coding.
>> Or take the fact that I cannot "LOOK WALL", it has to be
>> "LOOK AT WALL".
>
> What does that have to do with intelligent defaulting?
Everything. The preposition defaults to AT, because no other preposition
makes sense.
> But once again, the way you're holding up the glorious two-word parsers of
> old as somehow smarter in this respect just makes no sense to me.
There we go again. Something very strange with my keyboard. I am *sure* I
never typed anything about two-word parsers being in any way glorious.
> Okay,
> so
> Advent accepted LOOK WALL. But did it accept LOOK AT WALL? No. Did it
> accept L00K W@11? Nope. How about just LOOK THE WALL? Highly doubtful.
Indeed. But ask yourself: why not? Why shouldn't an IF parser accept *both*
LOOK AT WALL and LOOK WALL. I think it should. And why shouldn't an IF
parser attempt error correction? I think it should. One of the reasons why
I started re-working old adv660 into adv770, was to experiment with typo
correction.
I cannot see that building intelligence into parsers is any more ludicrous
than trying to build an AI capable of underpinning a believable
world-model. In fact, I would say the former is easier, and is much closer
to the core of IF than world modelling is.
> You consider this flexible? It's like saying Unix is more flexible than
> DOS
> because Unix accepts "cp", while DOS only accept "copy". Okay, so Unix
> *only* accepts "cp", but that's okay, because it's the one you like.
You know, it's inadvisible to jump to assumptions about your opponents
beliefs. Would it surprise you to know that I've been complaining for many
years about *both* Unix and DIOS being silly in not accepting command
synonyms and unambiguous abbreviations? I am afraid your sarcasm falls
rather flat.
> Honestly, Advent's parser was as rigid as parsers come.
>
> Virtually every
> game today accepts LOOK AT WALL, EXAMINE WALL, X WALL, LOOK AT THE WALL, X
> THE WALL, EXAMINE THE WALL. That strikes me as way more flexible than
> Advent, with its single formulation LOOK WALL.
Perhaps you should play some old games. Adv660 (and I believe adv550)
accepts all of these. Sure it cheats! It declares AT and HTE to be noise
words which are ignored by the parser. :-)
> Making a modern parser
> accept LOOK WALL *in addition to all of the others* would be trivial;
> authors would add it in an instant if they thought enough people wanted
> it.
Wrong philosophy. If something is trivial, I do it because somebody *might*
want it.
>> It's hardly surprising that players don't trust games to do
>> the right thing, and insist in typing out maximally specific
>> commands.
>
> Now wait a second - "it's hardly surprising"? I'd say it's hardly true.
> At
> least, hardly proven. You looked at one other person's game transcript,
> noted that that person didn't rely on defaulting much, and generalized
> that
> into "players don't trust games to do the right thing."
Actually, I read through several hundred logs generated by 26 players. Then
I responded to a post which pointed in the same direction, stating that my
observations confirmed it
> Did you even ask
> the person who wrote that transcript about their trust issues with modern
> games? And did follow up by surveying "players" to determine if there is
> in fact this overwhelming consensus you claim?
Nobody "wrote" the logs in question. They were generated automatically. I
think 26 players behaving in the same manner is evidence not to be
dismissed out of hand.
> And I hope it's obvious from the above that I still consider your beef to
> be
> with the complexity of the world model.
Suit yourself. But frankly, so many of your assumptions about me are wrong,
that I hope you will pardon me for not tking this one too seriously either.
:-)
> I'm not sure where else you think
> the extra complexity in the parser would be coming from. Do you think
> it's
> just coming more words? From accepting AT in LOOK AT? That's not
> complexity; that's just different syntax for the same exact complexity.
Ever heard the words "exponential explosion"?
>> And why no attention is being paid to possible ways of making
>> the taming easier?
>
> I really have no idea what you have in mind here. Who ought to be paying
> this attention? What possible ways?
Why those who write parsers of course! :-) As to how, I'll leave it to you
to figure out. IOt'll give you a chance to come up with some more ingenious
beliefs about my beliefs. ;-)
Seriously though, it is a question worth pondering. I do have one idea, but
it's too unformed as yet. I'll pipe out if it amounts to anything. In the
meantime any suggestions would be welcome.
Mike Arnautov
>>That's *horrible*!
>
> This is the default behaviour of the Inform Library - which, IIRC,
> got this behaviour from Zork I. So (again IIRC) games actually
> behaved this way already in the early 80's.
Sure. The rot set in with Zork. But at the time I didn't believe it would
spread. The parser was obviously too powerful for the game, and in fact
exposed its inadequacies. I naively believed that people would learn to use
complex parsers properly, and that kind of response would be deemed quite
unacceptable. But I underestimated the difficulty of taming the exponential
command riches offered by the parsers, and the determination of IF writers
to press on regardless. Zork approach to parsing essentially won, and I
coult it a loss.
Once again, I am not advicating a return to a mythical Golden Age of
verb/noun commands. I am bemoaning the fact that approaches and lessons
forced on adventure programmers by verb/noun parsers got discarded and
disregarded by authors using complex parsers.
>>WATCH
>>What do you want to watch?
>>
>>Helloooo!! Is anybody home? Obviously not...
>
> This is also irritating. Just for your information, I tend to play
> games like you describe your 1980's playtesters: if there's only
> one obvious object for a command, I tend to leave it out, and expect
> the parser to be able to default intelligently. If the game fails to
> do this however, I don't blame it on an overly-complex parser, but
> on an insufficiently sophisticated world model.
Same difference. If you prefer, there is a mismatch between the power of IF
parsers and the power of IF world models. Since a world model to match the
power of a complex parser would require a full-blown AI, I don't expect to
see it any time soon. Hence I would suggest seeking other ways of
ameliorating the mismatch. But for that to happen, the reality of the gap
has to be accepted, as well as the need to do something about it.
That's where simple parser experience comes in. The gap was much smaller
there, and hence some work-arounds were possible. Mike R seems to decry
such workarounds as a worthless illusionism, but I think that's
short-sighted.
Mike Roberts
> >> That's *horrible*!
> >
> > But this just proves my point. The reason you're being asked
> > which wall you mean is that the world model includes all those
> > walls.
>
> Which proves mine. Because the parser can parse all those
> purely hypothetical walls, the model needs to include them. And
> if the author doesn't handle the resulting complexity, the result is
> nonsense.
Okay, so let me see if I understand your point. You are saying that (1) the
world model includes the several walls because the parser is capable of
parsing multiple walls; (2) this is bad; (3) the parser should be changed to
correct this problem. The logical conclusion I see is that adjectives
should be removed. Correct?
> First of all, it is very rare for a player to have to handle/examine
> a particular wall -- otherwise you'd have a very boring game.
> The specific code to do so, can be handled by code associated
> with the relevant locations. Beyond that you need just a generalised
> closure which, yes, just pretends that there is a wall if appropriate
> and generates the appropriate response.
You're losing me. What is "a generalised closure which ... pretends that
there is a wall if appropriate"?
To me, that part about "if appropriate" is exactly what the world model
provides. In your view, how do you decide whether the wall is appropriate
or not? Perhaps you could offer some pseudo-code for your generalized
closure. I really don't understand what you have in mind.
> I cannot see that building intelligence into parsers is any more
> ludicrous than trying to build an AI capable of underpinning a
> believable world-model. In fact, I would say the former is easier,
> and is much closer to the core of IF than world modelling is.
Ah, I think I'm finally seeing where you're going. As I've read your past
posts, I've thought several times you were bordering on AI territory.
Let me try to clear up one matter of terminology. When you say "simple
parsers," do you mean "a very limited parser with very minimal capabilities,
like Advent's", or do you mean "a parser that's very intuitive for any
computer-illiterate human to operate, and correctly understands anything you
throw at it"? You said several times that you're not interested in going
back to Advent-style parsers, so I'm now thinking the latter.
If you're talking about building intelligence into parsers at that level,
all I can say is good luck. A lot of what you've been saying seems to
suggest you're thinking along the lines of AI-on-the-cheap, using smoke and
mirrors and simple heuristics to make it appear that the computer is
intelligent. I won't try to discourage you from pursuing that direction,
but I'm personally not too interested in it myself, since it's pretty much a
dead end in my experience.
Mike Roberts
> Since a world model to match the power of a complex
I don't understand how this follows. Perhaps it would help if you could
define "complex parser" and "simple parser"; I guess I'm not sure of your
meaning after you disclaimed Advent as a model "simple parser." Presumably
you define "complex parser" as the typical Inform/TADS parser; why does that
level of parser require full-blown AI in the world model?
Joe Mason
>> But this just proves my point. The reason you're being asked which wall
>> you mean is that the world model includes all those walls.
>
> Which proves mine. Because the parser can parse all those purely
> hypothetical walls, the model needs to include them. And if the author
> doesn't handle the resulting complexity, the result is nonsense.
It seems to me that you're picking on two particular weaknesses of the
Inform default world model, rather than a systemic flaw.
The first is it's arbitrary decision to make the directions double as
walls, so that "LOOK NORTH" prints a useless and occasionally
counterproductive message about a north wall. The second is the
decision to not include the phrase "LOOK object".
Both of these are bad decisions. I agree with you - this is stupid, and
the parser should be changed. Unfortunately, due to the way Inform is
distributed, this can't happen. (Basically because Graham Nelson is not
working on any new versions, and nobody else has permission to make
any.) However, I urge everyone else writing authoring system to make
sure theirs don't do the same thing.
Of course, authors could work around this. But they don't, not because
they're lazy, but because of two factors which affect a lot of software
development: the ones who are just starting don't know how, and often
don't think of it because they're in too much of a hurry to just get
something out, and the ones who have enough experience to know that they
should replace certain behaviours have, in the process of gaining that
experience, gotten used to these quirks.
I think you're right that these are a big problem. Inform's brain-dead
creation of walls is especially bad. I also agree that making the
parser fill in some default objects automatically would be a good idea,
though not strictly neccessary.
I completely disagree that this is a problem with a fundamental
approach. These are quirks that you're blowing up out of proportion,
nothing more.
Joe
Quintin Stone
> >> WATCH
> >> What do you want to watch?
> >>
> >> Helloooo!! Is anybody home? Obviously not...
> >
> > The thing is, most raif and rgif people would just consider this a
> > bug. If your claim were true that "intelligent defaulting is dead," as
> > you put it earlier, then would most people consider this a bug? No,
> > they'd say: we don't like intelligent defaults, intelligent defaults
> > are so 1982, we're *glad* that the game doesn't provide any. But they
> > don't; they say: this is a bug.
>
> Curiously enough, I don't recall a single review pointing out that this
> game is full of bugs. Which brings us back to my original post. I expect
> the truth is that players know to type full commands and not to expect
> any defaulting, so they don't see the problem and nobody complains. In
> fact, I seem to recall a SPAG review, which claimed "So Far" to be
> "nearly flawless" in its coding.
Uh, not to be snippy, but... who cares what those reviews said? You're
setting up quite a straw man here. There's a minor bug here that you feel
is somehow a systematic problem, and when someone points out that it's a
just a simple oversight in the game, your only defense is that other
people thought the game was coded flawlessly? That since it's not "full
of bugs", there can't be *any*?
If I post about how I found a bug in game So-and-So, can I expect to be
flamed by people who insist that previous reviews found the game to be
error free? That's just silly. Not every player will encounter every
possible scenario... and of course "nearly flawless" does not mean
"completely flawless".
William Burke
Joe Mason <j...@notcharles.ca> wrote:
> It seems to me that you're picking on two particular weaknesses of the
> Inform default world model, rather than a systemic flaw.
>
> The first is it's arbitrary decision to make the directions double as
> walls, so that "LOOK NORTH" prints a useless and occasionally
> counterproductive message about a north wall. The second is the
> decision to not include the phrase "LOOK object".
I don't think that the decision to include walls was arbitrary. It
seems most likely that it was done specifically so that, should the
player want to look at the north wall in a room which logically has one,
he won't get told that he can't see that there. As a gamble, it should
usually pay off, because the player isn't likely to look at walls which
aren't there unless he's trying to cause trouble, and if he gets told
that there isn't a wall when he knows there is one, he'll be annoyed.
It mainly falls down in a big way whenever the player tries to look at a
generic wall and gets told he has eight options to choose from.
Thinking about it, it might be best to have a single wall object which
can take any of the directions as nouns, because that avoids any
unfortunate scary disambiguation. If you wanted to go all out, you
could even create a parse_name routine that sets a flag based on whether
you referred to it using the keyword "wall" and respond differently to
actions based on the setting of that flag. You still run into the
problem that a player who looks at a wall that's not present will be
told there's nothing special about it, but there's no easy way to create
just the walls that should be present.
The "look object" thing is a little surprising, but solvable with one
line of code. (Incidentally, LOOK NORTH doesn't actually work, for
exactly this reason.)
> Both of these are bad decisions. I agree with you - this is stupid, and
> the parser should be changed. Unfortunately, due to the way Inform is
> distributed, this can't happen. (Basically because Graham Nelson is not
> working on any new versions, and nobody else has permission to make
> any.) However, I urge everyone else writing authoring system to make
> sure theirs don't do the same thing.
Anybody can write a patch to solve these problems, though.
Mike Arnautov
> Uh, not to be snippy, but... who cares what those reviews said? You're
> setting up quite a straw man here. There's a minor bug here that you feel
> is somehow a systematic problem, and when someone points out that it's a
> just a simple oversight in the game, your only defense is that other
> people thought the game was coded flawlessly? That since it's not "full
> of bugs", there can't be *any*?
Not at all. But this happens to be an obvious bug/defect/feature/oversight,
acll it what you will, on the very first move in the game. Did I say it was
the only one? I certainly did not, because it is not. Just the opening
section contains quite a few of them and I've already mentioned some of
those. The wall business (which according to one view somehow demonstrates
the supriority of modern IF :-), the inconsistencie in default behaviour of
GET and DROP (DROP defaults, GET doesn't). The rejection of a grammatically
correct commend (with a preposition) in one place, while dropping the
preposition works, and the complete reverse (preposition must be supplied
or the command isn't understood) in another. Non-existence of some major
"things" which are clearly described. And that's just in the first few
locations of the game! If you insist on a specific list with verbatim
quotes from the game, I can supply.
> If I post about how I found a bug in game So-and-So, can I expect to be
> flamed by people who insist that previous reviews found the game to be
> error free? That's just silly. Not every player will encounter every
> possible scenario... and of course "nearly flawless" does not mean
> "completely flawless".
Indeed. But I am puzzled that this one player promptly encountered so many
of them as to game frustrating almost to the point of being unplayeable.
The only explanation I can find is that my style of playing differs from
that of majority of other players. Which means that there is a "right
style" in which the game behaves just fine, and the "wrong style" in which
it does not.
Mike Arnautov
from tomorrow. This is in no way an attempt to have the last word -- I'll
do my best to respond to any rejoinders when I am back.
Mike Roberts wrote:
>> Which proves mine. Because the parser can parse all those
>> purely hypothetical walls, the model needs to include them. And
>> if the author doesn't handle the resulting complexity, the result is
>> nonsense.
>
> Okay, so let me see if I understand your point. You are saying that (1)
> the world model includes the several walls because the parser is capable
> of parsing multiple walls; (2) this is bad; (3) the parser should be
> changed to correct this problem. The logical conclusion I see is that
> adjectives should be removed. Correct?
Sorry, no. (1) is correct. (2) is not. (3) is a non-sequitur.
I have no objection to all those spurious walls actually existing in the
game. What is bad is that the parser pushes the fact at the player, unless
the author actively prevents it. (Just how many rooms do you know which
have eight walls - 4 in the cardinal directions and four in the split ones?
:-) It is also bad because according to the description you are at the west
wall, which makes LOOK AT WALL pretty unambiguous. So the author has three
choices: (a) ignore (or forget) the need to handle the wall, even though it
is explicitly described (and even though else examining much less obviously
described features is crucial); (b) make the world model more complex by
making only the west wall present in that location (I have no idea whether
the engine allows this, but that really is not important to this
discussion) -- but that is tricky, because the player may refer to the
north wall, or heavens forbid! to the non-existent NW wall -- so a
hierarchy of walls appers to be necessary, or (c) say stuff the world
model: the player is at the west wall and *I* know that here any reference
to a wall means *that* wall (again, I do not know how feasible that is, and
again this doesn't matter).
Your preferred solution clearly is (b), which in the extreme, forces the
elaboration of the model far beyond need, simply in order to handle
non-essential commands. My preferred solution is (c), which in its extreme
version leads to the complete abandonment of any world model. I think we
both agree that (a) is undesirable. :-) Would you agree so far?
My beef with parsers is two-fold. One is technical and could be solved (but
isn't being solved). One is historical. The technical one is that unless
the authors remembers to intercept in some manner, the parser is liable to
pipe up, offering inanities like the choice of walls. The parser is not,
and in your version should not be context-aware, so it should keep stumm,
lest it makes a fool of itself and of the game author. It should signal the
mis-parsing to the rest of the game, and let the author decide how to
handle mis-parsings. This is what Dave Platt's parser did, for example.
The historical problem is that complex parsers (from Zork on) gave the
illusion that the problem is easily solved by pairing the command parser
with a "world parser" (i.e. a world model). After all language reflected
reality, and language turned out to be much easier to parse than
anticipated. Ergo... (You may or may not remember what a revelation it was
at the time that a pseudo-natural language interface was possible At ALL!)
Hence option (b) above prevailed by default and option (c), which to my mind
is much closer to what IF is all about, languished. Of course, world
parsing turned out to be a headache, Shrdlu notwithstanding. Thinking about
it, it is really ironic that the prevailing IF culture should be one of the
last refuges of the traditional AI. But I digress...
> You're losing me. What is "a generalised closure which ... pretends that
> there is a wall if appropriate"?
>
> To me, that part about "if appropriate" is exactly what the world model
> provides.
If you accept that the model only need to exist in the author's head, I
agree entirely. But I think you don't accept that. (My apologies if I am
wrong.)
> In your view, how do you decide whether the wall is appropriate
> or not? Perhaps you could offer some pseudo-code for your generalized
> closure. I really don't understand what you have in mind.
After the experiences list time I had a major argument around here, I am
reluctant to use code, because I'd have to use A-code, which seems to
liable to lead to the "finger and the moon" kind of trouble.
I am talking about the author being in control, instead of the parser. Think
about it in terms of serch tree pruning in board (or card) game
programming. In the case under discussion, walls are present but
irrelevant. Hence there is no point in searching the space of possible more
specific command versions. That search branch should be pruned then and
there. But the parser doesn't know that, and the author and descends all
the way down the parse tree to maximal specifics.
This obviously can be done and in some instances in some games is done. But
it's very hit-and-miss, suggesting that there is no top-down mechanism,
which starts with generalities, and overrides these with specifics as
necessary. But I forget -- you count that as cheating, because the "world
model" is clearly entirely specific everywhere. :-)
> Ah, I think I'm finally seeing where you're going. As I've read your past
> posts, I've thought several times you were bordering on AI territory.
Well, since I got my PhD in AI, that's hardly surprising. Nor is it entirely
surprising that I have a very jaundiced view of AI as the result. :-)
> Let me try to clear up one matter of terminology. When you say "simple
> parsers," do you mean "a very limited parser with very minimal
> capabilities, like Advent's", or do you mean "a parser that's very
> intuitive for any computer-illiterate human to operate, and correctly
> understands anything you
> throw at it"? You said several times that you're not interested in going
> back to Advent-style parsers, so I'm now thinking the latter.
Well, yes and no. You are making a false dichotomy. A "simple parser" is
indeed the original verb/noun parser of the very early games. Complex
parsers launched from Zork onwards into "verb [adjective] object
[preposition [adjective] instrument]" territory, triggering an exponential
explosion in the size of the command space -- particularly when a later
game (The Hobbit, I think) proudly added adverbs into the mix. The result
was that the potential of simpler parsers to be elaborated in a completely
different direction, got entirely missed, or at least forgotten. And yet
there is no great problem with making a simple parser to understand
commands like
GET LAMP AND KEYS, EXAMINE THE LAMP AND THEN STEP OUT
which with a minimum of pre-processing, reduces to
GET LAMP
GET KEYS
X LAMP
OUT
Mere illusionism? Well, I say it is the result that counts, not the cogs and
wheels behind the scenes. :-)
Working with such simple structures led me to concerns quite different from
those which seem to preoccupy the IF mainstream. Most are of a kind world
modelling doesn address:
How to interpret and implement the verb FOLLOW (tricky!)
How to interpret IT in a more natural manner
How to deal with words the author used in descriptions but didn't handle in
command processing.
How to allow for bad typing
How to allow for bad syntax
How to respond to misparsing in a meaningful manner
how to respond to command errors in a meaningful manner (a highly
non-trivial problem)
None of this is exclusive with complex parsers, but it is easier to pursue
such experimentation on a smaller command space. And that's what I've been
doing in writing adv770. :-)
> If you're talking about building intelligence into parsers at that level,
> all I can say is good luck.
Thank you. But I am not, actually. Where this sems to be leading me, is to
abandon the notion of The Parser as a completely separate entity. The
parser needs to be context-aware, but does not need to be "intelligent". It
should provide me as the author with the framework for *me* to be
intelligent. But here I am getting to near to my other hobby-horse
"modelling versus literary IF", and it is getting late, and this post is
already *far* too long anyway.
> A lot of what you've been saying seems to
> suggest you're thinking along the lines of AI-on-the-cheap, using smoke
> and mirrors and simple heuristics to make it appear that the computer is
> intelligent.
Good grief! What makes you think your mind is not built on such "smoke and
mirrors" cheapo heuristic tricks? Evolution is not proud -- it uses every
sliver of advantage that can be found.
> I won't try to discourage you from pursuing that direction,
> but I'm personally not too interested in it myself, since it's pretty much
> a dead end in my experience.
That intrigues me. Do you think your pursuit of world modelling is taking
you anywhere else? The logic of the real world is non-monotonic, and hence
a full-blown AI is inevitably required to provide a convincing world model.
We are still nowhere near being even to approach such a model. In the
mean-time, my approach gives a decent chance of faking it. And in IF it is
the result that matters -- what the players sees. Not what's under the
bonnet.
Mike Arnautov
> "Mike Arnautov" <m...@mipmip.demon.co.uk> wrote:
>> Since a world model to match the power of a complex
>> parser would require a full-blown AI [...]
>
> I don't understand how this follows.
Because the world is governed by a non-monotonic logic, to which our common
sense is supremely adapted, but our programs are incapable of handling.
(Well Lenat tried with the Cyc project, which amply demonstrates the
problem.)
> Perhaps it would help if you could
> define "complex parser" and "simple parser"; I guess I'm not sure of your
> meaning after you disclaimed Advent as a model "simple parser."
See my other long post.
> Presumably you define "complex parser" as the typical Inform/TADS parser;
> why does that level of parser require full-blown AI in the world model?
The parser doesn't -- it merely generates a huge command space. The world
model, by which you are trying to address the size of the parsable command
space, does. And I've deliberately avoided talking about any *specific*
parser, restricting myself to observations of actual parsing and
mis-parsing in games I have been sampling of late.
Mike Arnautov
> I completely disagree that this is a problem with a fundamental
> approach. These are quirks that you're blowing up out of proportion,
> nothing more.
I beg to differ. But I've typed enough tonight and I badly need some sleep.
Maybe after I am back in 10 days time...
Mike Roberts
> [on dealing with LOOK AT WALL where there's only one
> wall, and the Inform library's default of 8 walls everywhere]
> [possible solutions:] (b) make the world model more complex by
> making only the west wall present in that location; or (c) say stuff
> the world model: the player is at the west wall and *I* know that
> here any reference to a wall means *that* wall (again, I do not
> know how feasible that is, and again this doesn't matter).
>
> Your preferred solution clearly is (b), which in the extreme,
> forces the elaboration of the model far beyond need, simply in
> order to handle non-essential commands. My preferred solution
> is (c), which in its extreme version leads to the complete
> abandonment of any world model.
Actually, I fail to see how (b) and (c) differ. To my mind, whatever
information you're using in (c) to know that "any reference to a wall means
*that* wall" is a world model by another name.
I think you might be misconstruing what I mean by "world model." You
mentioned the Cyc project and "world parsers," so I think you might have a
completely different thing in mind than I do. Let me be clear: I'm not
talking about anything even remotely like Cyc. There's nothing relating to
AI in what I'm talking about.
The world model I have in mind is the data model that represents the
setting. So, for example, there's some data structure that says there's a
location, and the location has this name, and it has this description, and
to the north lies this other location, and to the east lies this third
location. There's also a data structure that represents a wall, and it says
the wall is in this location, it has this displayed name, it has this
descriptive text, and it's referred to in command input with these words.
There's another data item somewhere giving the player's current location.
All of these bits of data - *they're* the "world model." It's *not* an
attempt to model "common sense," or physical reality, or all of Western
literature, or the human mind, or the great cosmic unconscious; it's just an
entirely mundane set of data structures encoding the specific things that
the author wants to put in the game.
So, let me ask this: if there is no world model, as you propose, how do you
represent the current location of the player character? How do you
represent where "north" goes? How do you represent the description of the
current location? How do you represent the list of items the player is
carrying? You must have *some* way of representing these things, because
otherwise, how do you know there's a "west wall" here, or indeed a wall of
any kind? Whatever means you're using to represent these things, it's a
world model.
> The parser is not, and in your version should not be context-aware
What do you mean? IF parsers are *very* context-aware. They're aware of
context via the world model. If you type in LOOK AT WALL, the parser asks
the world model: what does WALL mean right now, based on the current state
of the network of data structures representing the locations and objects and
actors? The world model looks at what the player can see, and returns this
information to the parser. Refer to the Inform Designer's Manual section on
scope, or the TADS manual's section on resolving noun phrases, if you want
to see just how context-sensitive these parsers are.
> > Perhaps you could offer some pseudo-code for your
> > generalized closure. I really don't understand what you
> > have in mind.
>
> After the experiences list time I had a major argument around
> here, I am reluctant to use code, because I'd have to use A-code,
> which seems to liable to lead to the "finger and the moon" kind of
> trouble.
Well, suit yourself, but I continue to fail to have any idea what you're
talking about. These ideas cannot be expressed concretely in any other form
than "A-code"? (I don't get the "finger and the moon" metaphor, either,
truth be told.)
> Complex parsers launched from Zork onwards into "verb
> [adjective] object [preposition [adjective] instrument]" territory,
> triggering an exponential explosion in the size of the command
> space -- particularly when a later game (The Hobbit, I think)
> proudly added adverbs into the mix.
This is perhaps a bit of a tangent, but don't you find it interesting that
adverbs never caught on, despite the idea have occurred independently to
numerous people over the years, starting quite a long time ago? It suggests
to me that the IF community is not driven by some techno-lust to ever more
complex parsers, but has found a comfortable balance between expressive
power and simplicity in the present standard parser style.
> > I won't try to discourage you from pursuing that direction,
> > but I'm personally not too interested in it myself, since it's
> > pretty much a dead end in my experience.
>
> That intrigues me. Do you think your pursuit of world modelling
> is taking you anywhere else? The logic of the real world is non-
> monotonic, and hence a full-blown AI is inevitably required to
> provide a convincing world model.
This suggests again that you're thinking Cyc or something when I say "world
model," so let me once again be clear: that's the opposite of my meaning.
The people using TADS and Inform and the rest are specifically *not* trying
to attack AI-related problems.
This is perhaps the major source of your disconnect with many of us around
here. You seem to want IF games to provide a convincing Turing-test
experience to players; that's something most of us are explicitly *not*
after. That's right - we're not even *trying* to make anyone think our
games have human-level intelligence.
My impression is that the early adventure-game people were thinking in terms
of convincing Turing-test programs, as you seem to be. The command-line
format creates that expectation by default, I think. In my mind, one of the
major advances that has occurred over the years has been a shift in that
thinking, so that now most authors think in terms of providing a good
computer user interface experience. A good UI experience does not require
that the game appear to have human-level intelligence; rather, it requires
consistency, simplicity, and transparency. You might say: goodness, that's
not an advance, that's a horrible step backwards! But I see it as an
advance because it's allowed authors to focus on aspects of game design
other than trying to make the parser pass a Turing test, and that focus has
been productive. Passing a Turing test would be a bonus, but we've set that
aside in favor of other things for now.
This is why your righteous outrage at the stupidity of responses to EXAMINE
WALL and so on have been met with such indifference. People around here
have converged over the years on a certain style of user interface. It's
not that people have been beaten into submission by bad UI's, or "trained"
to accept less than they should; it's that most of us have come to think of
the command-line UI as something other than a Turing-test terminal, and
players and authors have worked out a tacit agreement about how that UI
should work. Your complaints strike some of us as equivalent to going up to
a Mac user and complaining that nothing happens when you speak commands into
the mouse: of *course* it doesn't work that way - it's not supposed to.
As I said earlier, if you want to pursue making an IF game pass a Turing
test, best of luck. When you've done that, we'd be interested in hearing
how; for that matter, we'd be happy to continue hearing your ideas about it
now. I for one need something more concrete to understand what you have in
mind, though.
Mike Arnautov
is the furtherst thing from my mind. I can't think how that suggestion
could be matched with my listed concerns in parser developments. But it'll
have to wait -- I am off.
Quintin Stone
> Indeed. But I am puzzled that this one player promptly encountered so
> many of them as to game frustrating almost to the point of being
> unplayeable. The only explanation I can find is that my style of playing
> differs from that of majority of other players. Which means that there
> is a "right style" in which the game behaves just fine, and the "wrong
> style" in which it does not.
I can definitely see that being the case. I wouldn't say one is "wrong",
but I think that over the 20+ years of IF, certain conventions and
traditions have been established that people have a hard time breaking out
of. Some people play a specific way and any other style may seem rather
alien to them. And so if they were to try a different command and not get
an appropriate response, they might just say, "Oh well, who would expect
someone to try that anyway?"
For example, as someone who was very used to Infocom games, I'm still
trying to make the transition to more modern IF games which implement more
verbs and scenery. And so I sometimes find myself stuck in the rut of
simpler times.
Ben Caplan
like trying to learn a foreign language. Of course, I was repeatedly trying
to 'enter biulding' [sic], but the point is, parsers could and should be
much more natural.
I think AI is the right way to go. You speak of quirks, but they keep
recurring after so many years. It is a fundamental design flaw that usually
- but not always - expresses itself as trivial annoyances.
Well done, the parser could even recognize when a noun should be implemented
(I don't know that word, but it's used as a noun in the room's long
description), and dynamically create an object that makes sense in the
context.
I know this sounds unrealistic, but I have a basic idea of how it could be
implemented. If anyone wants, I'll post an explanation.
Doesn't this belong on raif?
----------------------------------------------------------------
Ben Caplan -- philosopher, linguist, and thaumaturge
Jaap van der Velde
wrote:
>I know this sounds unrealistic, but I have a basic idea of how it could be
>implemented. If anyone wants, I'll post an explanation.
>
>Doesn't this belong on raif?
I think it kind of does, but I'm a bit of a skeptic about it coming
to good use. According to me, the expected trajectory of such
a discussion would be:
1. You explain your idea (which is pretty good, some agree)
2. Someone explains why this is impossible to implement in
TADS/Inform/Glulx/my own system which is a WIP.
3. People start suggesting setting up a new system which does
allow what you need.
4. Discussions about the hardships of writing a parser start
up. (or why a new language+terp is a bad idea)
5. You try to make clear that wasn't what your idea was all
about.
6. etc.
Too cynical? Perhaps, but what I want to make clear is that the
risc of the discussion you'll start veering off into a discussion
about limitations of writing parsers or limitations of existing
systems is large.
Thinking about it, I think you're idea is very much on the topic
of AI and NLP and those realms have yet to touch IF in any way.
But, yes, I am interested in your idea :-)
Greetings,
JAAP.
---------------------------------------------------------------------------
"Did you ever walk into a room and forget why you walked in? I think
that's how dogs spend their lives."
-- Sue Murphy
Magnus Olsson
Mike Roberts <mjrUND...@hotmail.com> wrote:
>My impression is that the early adventure-game people were thinking in terms
>of convincing Turing-test programs, as you seem to be. The command-line
>format creates that expectation by default, I think.
An interesting thought, and I think the idea has some merit.
Perhaps programmers in the late 70's/early 80's were a bit naive
in the sense of having a fresh outlook on interactivity, and not being
jaded by decades of bad UIs. The idea of "conversational" interfaces
that, to some level, understand what the user means rather than what
he says, was, and still is, an attractive one - at least until one
runs into the wall and starts analyzing the reasons why such interfaces
fail and how the user/program dialogue really works.
Of course, the few command-line interfaces still in existance tend to
target programmers or at least power-users, but the idea of natural-
language UIs pops up every now and then, for example in search engines.
Adrien Beau
>
>Rikard Peterson wrote:
>> You might as well type "grep" or "rm". Abbreviations are
>> handy, but they have to be learned.
>
> Except that those commands aren't abbreviations. They may be
> derived as abbreviations of words, but as commands they *are*
> the full commands. And they cannot be abbreviated. That's my
> gripe about CLIs -- I cannot see why they have to be so rigid.
> They should allow proper words as commands *and* abbreviations.
That's exactly what OpenVMS CLI does: you can type commands and
parameters as short as you want, as long as the abbreviation is
unique. I've almost never typed DIRECTORY/FULL there, most often
it was DIR/FU.
Of course, this system is still pretty mechanical. It also implies
that you have to register a program and its parameters with the
CLI system: just having the binary is not enough (well, you can
RUN it, of course).
--
spam....@free.fr
You have my name and my hostname: you can mail me.
(Put a period between my first and last names).
(boa13? A nickname I didn't intend to use here).