Analysis of 72 Newbie Transcripts
Aaron A. Reed
days at the Slamdance Film Festival. When the dust cleared, I gathered
the transcripts from everyone who played during this time and wrote-up
an analysis which may be of interest in light of the recent (and
ongoing) discussion on new players and interactive fiction. The full
report is at the link below:
http://aaronareed.net/wttc/transcripts.html
As I explain, the circumstances of the game and venue are different
enough that these stats may be completely different than reactions to,
say, "Zork." But briefly, only half of players read the instructions,
about 20% of commands longer than one word are not understood by the
game, and the average time till a "not understood" message is received
is about 8 moves. The average player who didn't finish the game stuck
with it for 28 moves.
I'd love for anyone with reactions to post them here!
David Whyld
Aaron A. Reed wrote:
> Recently my IF piece "Whom the Telling Changed" was displayed for 4
> days at the Slamdance Film Festival. When the dust cleared, I gathered
> the transcripts from everyone who played during this time and wrote-up
> an analysis which may be of interest in light of the recent (and
> ongoing) discussion on new players and interactive fiction. The full
> report is at the link below:
>
> http://aaronareed.net/wttc/transcripts.html
>
It's interesting seeing the commands that some of the people who have
never played IF before tried. At first glance, some of them seem just
plain silly and you wonder if they're playing the games for a laugh or
something. But read a little further and a lot of the commands do
actually seem like commands that people who don't know much about IF
would try. Going on how many of them ran into problems, and how quickly
they ran into problems, might explain just why IF isn't more widely
popular: it's just too difficult to get to grips with.
And, you'll probably hate me for saying this, but I don't think "Whom
The Telling Changed" was the right game for this kind of thing.
Ideally, a nice and simple straightforward game was needed, a game with
clear goals that are obvious from the start. I've been playing IF for
years yet this game confused me at first. If I'd never played an IF
game before, and had no real idea what I was doing, I'd have probably
lasted about as long as some of the people whose transcripts you
selected lasted.
ems...@mindspring.com
Aaron A. Reed wrote:
> Recently my IF piece "Whom the Telling Changed" was displayed for 4
> days at the Slamdance Film Festival. When the dust cleared, I gathered
> the transcripts from everyone who played during this time and wrote-up
> an analysis which may be of interest in light of the recent (and
> ongoing) discussion on new players and interactive fiction. The full
> report is at the link below:
>
> http://aaronareed.net/wttc/transcripts.html
First of all, thank you very much for doing this. Much appreciated.
I'm not sure what I think about the idea of snipping out extraneous
material from a command and interpreting only the sensible bits; it
seems that this would produce absolute nonsense quite a lot of the
time, especially if the player tried to use negations, adverbs, and
that sort of thing. But we won't know for sure until someone tries it,
I imagine.
ems...@mindspring.com
ems...@mindspring.com wrote:
> Aaron A. Reed wrote:
> > Recently my IF piece "Whom the Telling Changed" was displayed for 4
> > days at the Slamdance Film Festival. When the dust cleared, I gathered
> > the transcripts from everyone who played during this time and wrote-up
> > an analysis which may be of interest in light of the recent (and
> > ongoing) discussion on new players and interactive fiction. The full
> > report is at the link below:
> >
> > http://aaronareed.net/wttc/transcripts.html
A couple of other observations after looking over this more: if over a
quarter of type three errors are typos, that seems like a good reason
to consider some kind of automated typo-correction, either built into
the interpreter (I believe Nitfol offers this) or built into the game.
Cedric Knight's mistype.h does this for Inform, and when I've included
it in a project I have found that it makes life noticeably easier even
for me replaying my own work.
The next place to improve the standard libraries is obviously (a) to
provide more synonyms for standard actions and (b) to design more
error-catching mechanisms for the very common types of mistake. GO
actions were a major trouble-spot in the phpZork logs I looked at, a
couple of years ago: players typed a lot of GO TO [thing in room], GO
BACK, LEAVE TENT, etc., and your transcripts seem to confirm that. So a
wide range of error-catching in that field may be particularly useful.
Catching sentences that start with a question word also seems a good
way to sift for errors.
Another nice trick might be to identify and excise common problem
phrases from commands, wherever they may appear -- PLEASE, very common
adverbs, and phrases like WITH MY HEAD or WITH MY FIST. This is a
watered down version of the thing you suggest (ignoring all input that
isn't understood), but with the advantage that the author can be sure
what he's ignoring and offer instructive feedback at the same time;
e.g., "(Adverbs are not recognized by [game], so I am ignoring that
part of your input.)"
I also had the impression that many people got confused at the point
where you require the player to choose a professional symbol. I though
that was a cool feature of the game, but the refusal to disambiguate
when players typed X SYMBOL looks like it threw at least a few people
off track.
This is not meant as a criticism of the game at all, but it does
suggest that one needs to be extra-careful about any ambiguous
situation when dealing with novice players.
Another thing that struck me (compared with the phpZork logs) was how
much of the input was civil/cooperative: there wasn't a huge amount of
swearing, snarking at the game, or deliberately trying to break the
parser. Presumably this has a bit to do with the context in which this
was presented, but it does suggest that these transcripts generally
represent a good-faith effort on the part of players. So Slamdance may
have been a good venue for experimentation in that respect, even if it
also presented distractions that kept many people from playing to
completion.
-- Emily
Aaron A. Reed
>A couple of other observations after looking over this more: if over a
>quarter of type three errors are typos, that seems like a good reason
>to consider some kind of automated typo-correction, either built into
>the interpreter (I believe Nitfol offers this) or built into the game.
>Cedric Knight's mistype.h does this for Inform, and when I've included
>it in a project I have found that it makes life noticeably easier even
>for me replaying my own work.
mistype.h is great and works well, but I've always found when I've
played around with it that it has a tendency to disambiguate to objects
I don't want the player to know about yet. I haven't looked at the
source code but this would probably be a fairly trivial fix.
>I also had the impression that many people got confused at the point
>where you require the player to choose a professional symbol. I though
>that was a cool feature of the game, but the refusal to disambiguate
>when players typed X SYMBOL looks like it threw at least a few people
>off track.
In some ways, this was a trick that requires knowledge of IF to
completely make sense. If you're familiar with the concept of a
disambiguation question, you sort of realize what the game is asking
you here. If you aren't, however, it definitely can be a source of
frustration, and wasn't the ideal thing for newbies to be seeing a few
moves into the game.
>I'm not sure what I think about the idea of snipping out extraneous
>material from a command and interpreting only the sensible bits; it
>seems that this would produce absolute nonsense quite a lot of the
>time, especially if the player tried to use negations, adverbs, and
>that sort of thing. But we won't know for sure until someone tries it,
>I imagine.
I'm working on it... :grIn:
Aaron A. Reed
>And, you'll probably hate me for saying this, but I don't think "Whom
>The Telling Changed" was the right game for this kind of thing.
>Ideally, a nice and simple straightforward game was needed, a game with
>clear goals that are obvious from the start. I've been playing IF for
>years yet this game confused me at first. If I'd never played an IF
>game before, and had no real idea what I was doing, I'd have probably
>lasted about as long as some of the people whose transcripts you
>selected lasted.
I actually agree---but I thought less than ideal data would at least be
of some interest, since the community has very little data at all to
work with!
Jim Aikin
> part of your input.)"
...and you're assuming that the average high-school graduate in the U.S.
will remember what an adverb is?
The questions raised in this thread are all excellent -- I'm not quibbling.
I'm just suggesting that when instructing the player, it might be helpful to
think about what the player's knowledge set is likely to be:
"You don't need to say how you'd do something (quickly, gently, hard, soft,
etc.). Just say what action you want to take (for instance, 'knock on
door')."
--JA
Jim Aikin
> ASK ABOUT ENEMIES (the parser expects ASK CHARACTER ABOUT TOPIC).
This is probably a change that could be made in the verb grammar (or perhaps
the library) without too much pain. If the player is in a location where
there is exactly one NPC, the grammar for 'ask', 'tell', 'show', and 'give'
ought to be understood as having an implicit direct object.
I wouldn't know how to implement it in Inform, but I'll bet Andrew would.
--JA
ems...@mindspring.com
Jim Aikin wrote:
> > e.g., "(Adverbs are not recognized by [game], so I am ignoring that
> > part of your input.)"
>
> ...and you're assuming that the average high-school graduate in the U.S.
> will remember what an adverb is?
Not quite. I was assuming the average member of the target audience of
IF would know what an adverb is.
On consulting a few people, I discover that I am wrong. Well, supply
your own error message.
Samwyse
> I'd love for anyone with reactions to post them here!
Most excellent. Your analysis seems to agree with Emily Short's
analysis of on-line games. She produced two extensions (IIRC,
NewbieGrammar and ExpertGrammar) which might have helped at Slamdance.
Still, I see several avenues for futher improvements based on your analysis.
One point that I feel is important is the number of people who typed
full commands where abbreviations would do ("yes" instead of "y", etc).
The original FORTRAN version of Adventure kept track of how many times
the word "west" was used; on the fifth usage or so, it printed out help
text about common abbreviations. Someone (i.e. myself, most likely)
needs to see how hard it would be to fit something like that into the
Inform parser. The compass directions should be fairly easy since they
are special cases already, the real trick would be catching where the
player could use I, X, Y, N, Z, etc.
Samwyse
TADS goes even futher by remembering the last person spoken to and
assuming that all conversation is directed there. I'm half trying to do
something similar in Inform.
ems...@mindspring.com
Jim Aikin wrote:
> From the posted essay:
>
> > ASK ABOUT ENEMIES (the parser expects ASK CHARACTER ABOUT TOPIC).
>
> This is probably a change that could be made in the verb grammar (or perhaps
> the library) without too much pain. If the player is in a location where
> there is exactly one NPC, the grammar for 'ask', 'tell', 'show', and 'give'
> ought to be understood as having an implicit direct object.
This is not hard, no. Several of my games follow this logic:
if no person is specified in an ask/tell/give/show command, then
address the last person spoken to;
if that person isn't around or there is no previous interlocutor, look
for a logical replacement;
-- if there's only one person visible, that person becomes the new
interlocutor;
-- if there's no one visible, say that the person last spoken to is no
longer available;
-- if there are multiple people visible, request a more specific
command.
Then, because ASK ABOUT and TELL ABOUT are a bit long to type out as IF
commands go, abbreviate those as A and T.
This requires some additions to both the grammar and the verb set, but
it's not too bad.
Samwyse
> One point that I feel is important is the number of people who typed
> full commands where abbreviations would do ("yes" instead of "y", etc).
> The original FORTRAN version of Adventure kept track of how many times
> the word "west" was used; on the fifth usage or so, it printed out help
> text about common abbreviations. Someone (i.e. myself, most likely)
> needs to see how hard it would be to fit something like that into the
> Inform parser. The compass directions should be fairly easy since they
> are special cases already, the real trick would be catching where the
> player could use I, X, Y, N, Z, etc.
OK, compass directions are fairly easy. Add a global variable called
'long_direction' and change parserm from this:
if (l ~= 0) {
results-->0 = ##Go;
to this:
if (l ~= 0) {
! We don't want to trap 'out' or 'exit', so look for words
! that are more than 4 characters in length.
if (WordLength(verb_wordnum) > 4) {
if (long_direction++ > 3)
print "(If you prefer, you can type one or two
letter abbreviations for directions.)^";
}
results-->0 = ##Go;
Aaron A. Reed
>One point that I feel is important is the number of people who typed
>full commands where abbreviations would do ("yes" instead of "y", etc).
> The original FORTRAN version of Adventure kept track of how many times
>the word "west" was used; on the fifth usage or so, it printed out help
>text about common abbreviations. Someone (i.e. myself, most likely)
>needs to see how hard it would be to fit something like that into the
>Inform parser. The compass directions should be fairly easy since they
>are special cases already, the real trick would be catching where the
>player could use I, X, Y, N, Z, etc.
This is a great idea, and on a broader scope, there are a number of
things like this that could be helpful to new players. Most new
players, for example, don't realize that when they're asked a question
like "Which do you mean, the red one or the blue one?" they can just
type "red" or "blue" rather than having to retype the whole command.
The first time a disambiguation question is asked, a helpful text like
"You may simply type red or blue" might be ammended to teach the player
this mechanic.
I had seen Emily Short's two Grammar extensions previously, and thought
they were great. In some ways it's a better solution to the
problem---if you try to get players to enter their input in the correct
format, it's a skill that will carry over to other works of IF they try
as well. It's more backwards compatible, if you will. But I also think
it's a shame to reject player input when the capability to understand
it exists and is easily implemented.
I've always thought this was a bit of an inconsistancy in Inform's
design philosophy. To quote the DM4 as regards to parsing nouns:
>...the parser normally recognises any
>arrangement of some or all of the name words of an object as a noun which
>refers to it: and the more words, the better the match is considered to be.
>Thus ''fried green tomato'' is a better match than ''fried tomato'' or ''green
>tomato'' but all three are considered to match. On the other hand, so is ''fried
>green'', and ''green green tomato green fried green'' is considered a very good
>match indeed. The method is quick and good at understanding a wide variety
>of sensible texts, though poor at throwing out foolish ones. (An example of
>the parser's strategy of being generous rather than strict.)
This makes perfect sense, but the philosophy does not get applied to
the rest of the player's input. There's no good reason LOOK BAG should
fail, just as there's no good reason PLEASE STUDY THE BAG MORE CLOSELY
should fail---it's trivial to extract the underlying meaning X BAG out
of both of these commands. The only danger in allowing a wider range of
commands is that the player will get sloppier with his command
structure and pass the point of easy recognition--but the above passage
does not worry about this being a problem for the recognition of nouns.
Steve Evans
<ems...@mindspring.com> wrote:
>
>> http://aaronareed.net/wttc/transcripts.html
>
>First of all, thank you very much for doing this. Much appreciated.
>
>I'm not sure what I think about the idea of snipping out extraneous
>material from a command and interpreting only the sensible bits; it
>seems that this would produce absolute nonsense quite a lot of the
>time, especially if the player tried to use negations, adverbs, and
>that sort of thing. But we won't know for sure until someone tries it,
>I imagine.
As I recall it, Synapse adopted such an approach with the BTZ (Better
Than Zork) parser used in their mid-1980's Electronic Novels series
(Mindwheel, Breakers, etc.)
I remember (all those years ago) being very impressed by the BTZ
parser's attempts at disambiguating my input. Although, when the
parser got my commands wrong it would occasionally get them *very*
wrong, making it apparent that it was not nearly as clever as it
pretended to be.
Still, I've often wondered why modern parsers haven't moved, to some
degree, along that path towards a more flexible approach to user
input.
--Steve
Daryl McCullough
>I'm not sure what I think about the idea of snipping out extraneous
>material from a command and interpreting only the sensible bits; it
>seems that this would produce absolute nonsense quite a lot of the
>time, especially if the player tried to use negations, adverbs, and
>that sort of thing.
I wonder whether it would be useful in such cases to paraphrase
the command back to the player to ask if that's what he/she meant.
For instance:
>Kick the guard hard in the shin
[Understood as: "Attack the guard". Is that what you meant (yes/no)?]
--
Daryl McCullough
Ithaca, NY
Andrew Plotkin
>
> This makes perfect sense, but the philosophy does not get applied to
> the rest of the player's input. There's no good reason LOOK BAG should
> fail, just as there's no good reason PLEASE STUDY THE BAG MORE CLOSELY
> should fail---it's trivial to extract the underlying meaning X BAG out
> of both of these commands. The only danger in allowing a wider range of
> commands is that the player will get sloppier with his command
> structure and pass the point of easy recognition--but the above passage
> does not worry about this being a problem for the recognition of nouns.
punting the problem of rejecting "green green fried green tomatoes".
(Rejecting that would be a fair amount of extra code.)
More seriously: the two input spaces are fairly different. There is
rarely anything else that the player could have meant by a string of
nouns and adjectives that describe a single object.[*] The wordy verb
examples are not so tractable -- I think they have more ways for the
parser to genuinely misconstrue the player's intent.
[* Except in a case like "door" and "door bell" -- and in that case we
*do* go to great effort to prevent "push door" from matching
<push door_bell>.]
"Look bag" remains a bit of a blivet. I don't deny that it carries a
lingering historical arrogance: "Our parser is smart enough to know
what prepositions are! And you're going to like it!"
However, there is a little more to it than that. "Look bag" may be
the first mistake that the player hits, *particularly* if he has not
gotten the idea of prepositional phrases. If it is accepted, it may be
bad training for more than just the "look" command.
In other words, I'm not so worried about someone learning "look bag"
and then failing to realize that "look in bag" or "look behind bag"
are possible. I'm worried about someone learning "look bag" and then
having no idea how to put a stone into the bag.
(I would be all for a game that took "look bag" and responded "Try
'look at bag'." In fact, I should have thought of that for Dreamhold.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because of the Eighth Amendment.
Mike Roberts
> Still, I've often wondered why modern parsers haven't moved, to
> some degree, along that path towards a more flexible approach to
> user input.
I can't speak for any modern parsers but the ones I've written, but for my
part, it's a deliberate design decision. Basically, I think it's better for
newbies if the parser is comprehensible than if it's flexible.
The metric I see as important in the learning curve is the amount of time it
takes for a new user to internalize the parser's model. The simpler the
parser's model, and the more straightforwardly the parser exposes the model
to the user, the more quickly a new user will learn exactly what that model
is. (Taken by itself, and taken to its logical extreme, this principle that
simpler is better would lead directly to CYOA-type interfaces. But if you
combine it with the opposing goal of expressiveness, so that the goal is the
simplest parser that lets you express everything you can do in the world
model, I think you arrive at something close to the current state of the
art.)
The BTZ parsers were predicated on an entirely different philosophy. That
philosophy is that the user shouldn't have to learn how to use the parser at
all, ever - that it's the parser's job to understand what the user already
knows about communicating in English (or other natural language). With that
philosophy, the learning curve metric that's important is to maximize the
comprehension percentage of commands typed by uninstructed new users.
The "flexible" philosophy is much better than the "comprehensible"
philosophy in an ideal world where computers behave like they do on Star
Trek. If the computer *can* be programmed to understand what uninstructed
new users type, then it should be. The practical problem, at least for the
moment, is that it can't. People who write BTZ-style parsers compensate for
this by allowing themselves to become confused about the learning curve
metric - in particular, they tend to substitute "acceptance" for
"comprehension" in the percentage figure they're trying to maximize.
(They're not the same; if the parser accepts a command but interprets it to
mean something other than what the user intended, the parser has failed even
worse than it would have by rejecting the command.) This confusion leads to
"cheap AI" tricks like discarding unknown words, and, in my experience,
leads to confused users. New users are occasionally delighted that random
things they try actually work, but just as often they're confused by the
parser's strange misinterpretation of something simple they tried, and over
time they find it difficult to assemble a coherent picture of how the parser
will interpret any particular input; so even experienced users stay fuzzy on
exactly how to express a given intention.
Looking at Aaron's figures, the conclusion I come to is that it would pay
the biggest dividends to improve the parser's diagnostics rather than to try
to make the parser more flexible per se. It's pretty clear that users won't
read instructions (I suspect that most of the 53% of Aaron's users who said
"yes" to receiving the instructions skimmed them at best), but I think
that's largely just because people these days are accustomed to learning new
software by trial and error. The standard modern parser is really pretty
simple from the user's perspective, so if we make the trials and errors
maximally instructive, a newbie should be able to work out the big picture
in not too many turns. For example, I'd suggest that rather than dropping
noise words like "please," the parser might simply scan for common noise
words and offer some customized advice if it finds them ("You don't need to
use words like 'please' with this game").
--Mike
mjr underscore at hotmail dot com
Urbatain
autocorrect tool could issue errors in the parsing routine from the
real input the player gives. Think that maybe a sentence could not be
wrong, really the parser or game dictionary doesn't understand the
sentence, but it is gramatically correct.
So I think the good idea is to give advice, something like google:
"search for "candyes" You meant to say: candies." Something like this
is quite better.
In our games something like: Maybe you type wrong that word or I didn't
understand "candyes". Do you wanna correct that?" Or something like
that.
See you.
Urbatain.
Urbatain
of commands, and must have a detailed instructions set. So I think the
way to go is to tell the player what is legal and what is illegal to
type. To tell what words the parser don't understand, what things are
irrelevant, and what kind of phrases the parses expect to receive,
exaclty the same when a player press F1 to see the keys to play Quake.
Urbatain.
Brian Wh.
Full disclosure! [1]
A simple, enumerated command set, completey disclosed to the player, no
synonyms!
Way to go, spanish IF community!
[1] ...and a map, too.
Stephen Bond
> You must think that a game is a game, and a game have a limited amount
> of commands,
So a live RPG is not a game?
Some games have a limited set of commands. Not everyone thinks
IF should be that sort of game.
Stephen.
Brian Wh.
IF should be that sort of game. "
Regardless of what "not everyone" thinks IF should be, IF _has_ a
limited set of commands.
A limited set of verbs. Some authours think it improves the game to
conceal some of the commands
from the player.
Stephen Bond
> "Some games have a limited set of commands. Not everyone thinks
> IF should be that sort of game. "
>
> Regardless of what "not everyone" thinks IF should be, IF _has_ a
> limited set of commands.
In practice, yes. But the player is not usually aware of the
limits of this set. So it appears essentially unlimited.
> A limited set of verbs. Some authours think it improves the game to
> conceal some of the commands
> from the player.
And often for good reason.
Stephen.
Brian Wh.
> limited set of commands.
In practice, yes. But the player is not usually aware of the
limits of this set. So it appears essentially unlimited. "
Rubbish. To me it appears essentially broken-- the vast majority of
possible inputs elicit error messages.
Judging from the transcripts, most newbies share this opinion with me."
"Some authours think it improves the game to
> conceal some of the commands
> from the player.
And often for good reason."
Rubbish. If an IF only works if the author conceals the commands, it is
rubbish.
I don't want to play it. And neither would most newbies.
Greg Boettcher
> > > Some authours think it improves the game to
> > > conceal some of the commands
> > > from the player.
> >
> > And often for good reason.
>
> Rubbish. If an IF only works if the author conceals the commands, it is
> rubbish.
> I don't want to play it. And neither would most newbies.
I agree that it's a good idea to try to empathize more with newbies and
try to help them.
However, could it be that you're throwing the baby out with the bath
water here? As mentioned in that other thread, "Why Newbies Don't Like
IF," there certain moments, including one scene in Photopia, that a lot
of people think would be less interesting if its verb/action were
revealed up front. It would be more interesting to hear your position
on this after playing that game and commenting on that scene.
I think it would be quite helpful for newbies to get a list of actions.
But you're saying a *complete* list would *always* be good, and I can't
agree there.
Or, hold on, there is one other alternative. Giving a complete list of
verbs wouldn't necessarily hurt Photopia that much, if the list was,
say, 200 verbs long, and included a lot of red herrings; i.e.
completely unnecessary verbs. Legend Entertainment games did that, and
it never bothered me.
Greg
Stephen Bond
> "> Regardless of what "not everyone" thinks IF should be, IF _has_ a
> > limited set of commands.
>
> In practice, yes. But the player is not usually aware of the
> limits of this set. So it appears essentially unlimited. "
>
> Rubbish. To me it appears essentially broken-- the vast majority of
> possible inputs elicit error messages.
That arbitrary possible inputs, such as >SDFGKFJD, elicit error
messages is of no concern. What matters are the inputs one
would expect to work, such as sensible natural language commands
in a given context. In the transcripts, "something like 20%" of
the inputs produced error messages. A lot, but not the majority,
and certainly not the "vast majority".
> Judging from the transcripts, most newbies share this opinion with me."
I think IF authors would be wise not to put too much stock in
newbie opinion. While it's desirable up to a point to cater to new
players, it's never good to pander to them. And "full disclosure" of
the command set compromises the medium to an extent that
amounts to pandering.
Newbies are by definition fairly ignorant of the nuances of an art
form. As a newbie, I had much the same opinion of the IF command
set -- but the games I played soon changed my mind.
> "Some authours think it improves the game to
> > conceal some of the commands
> > from the player.
>
> And often for good reason."
>
> Rubbish. If an IF only works if the author conceals the commands, it is
> rubbish.
Did you read the other thread? Do you think _Spider and Web_ or
_Photopia_ would have worked if the authors had presented all
available commands?
Many IF games -- in my opinion, the best IF games -- exploit the
open-endedness of the command set in ingenious ways. To
dismiss all such games as "rubbish" is rather blinkered, to
say the least.
Stephen.
Andrew Plotkin
>
> I think IF authors would be wise not to put too much stock in
> newbie opinion. While it's desirable up to a point to cater to new
> players, it's never good to pander to them.
While I generally share your position about the principles of IF, I
wouldn't put it *that* strongly. It is entirely desirable to cater to
new players -- in order to turn them into *experienced* players. It is
undesirable to give them less interesting, less enjoyable games on the
pretext of being newbie-friendly. "Pandering" doesn't come into it,
either way.
Rubes
> While I generally share your position about the principles of IF, I
> wouldn't put it *that* strongly. It is entirely desirable to cater to
> new players -- in order to turn them into *experienced* players. It is
> undesirable to give them less interesting, less enjoyable games on the
> pretext of being newbie-friendly. "Pandering" doesn't come into it,
> either way.
I agree with that. I think the goal, overall, is to try and get players
hooked. That requires some measure of hand-holding, but there are
certainly limits.
What about a system that recognizes that a user has received an error
on, say, 3 consecutive command entries, upon which it produces a
message like "Would you like some assistance?"
Then it could just give a few basic examples of typical IF commands. It
doesn't have to show every available verb, but some of the most common
ones. And it could then encourage creativity by the player as well.
Stephen Bond
> Here, Stephen Bond <steph...@ireland.com> wrote:
> >
> > I think IF authors would be wise not to put too much stock in
> > newbie opinion. While it's desirable up to a point to cater to new
> > players, it's never good to pander to them.
>
> While I generally share your position about the principles of IF, I
> wouldn't put it *that* strongly. It is entirely desirable to cater to
> new players -- in order to turn them into *experienced* players. It is
> undesirable to give them less interesting, less enjoyable games on the
> pretext of being newbie-friendly. "Pandering" doesn't come into it,
> either way.
Hmm. I'd count the latter as pandering, in the sense of catering to
some perceived lowest common denominator. I don't mean that to
criticise the motives of the authors, which are almost certainly not
those of the various media companies that pander, but to
criticise its effects on the games.
Stephen.
Kevin Forchione
news:droi04$pfb$1...@reader2.panix.com...
> Here, Stephen Bond <steph...@ireland.com> wrote:
>>
>> I think IF authors would be wise not to put too much stock in
>> newbie opinion. While it's desirable up to a point to cater to new
>> players, it's never good to pander to them.
>
> While I generally share your position about the principles of IF, I
> wouldn't put it *that* strongly. It is entirely desirable to cater to
> new players -- in order to turn them into *experienced* players. It is
> undesirable to give them less interesting, less enjoyable games on the
> pretext of being newbie-friendly. "Pandering" doesn't come into it,
> either way.
One shouldn't undervalue the importance of motivation here. Games have
rules, and certainly one doesn't "dumb-down" something like bridge or chess
in order to make the games more palatable for the newcomer. Instead one
lures them in with peer excitement. Give IF a celeb, and the unwashed masses
will come knocking down the doors in droves.
--Kevin
Brian Wh.
open-endedness of the command set in ingenious ways."
Guys, give me specific examples. Don't worry about spoilers,
I can handle it. Don't just mention a game, give at least one
_specific_ example.
Specific examples of where letting the player know what
commands are available is deleterious to the player's
gameplay experience.
Brian Wh.
verbs wouldn't necessarily hurt Photopia that much, if the list was,
say, 200 verbs long, and included a lot of red herrings; i.e.
completely unnecessary verbs. "
Why stop at only 200 <g>?
I'm not against "red herrings" in a verb list. But I want a _complete_
, inclusive list.
By the way, it was amazing at how many verbs Legend implemented and
_used_! So much effort!
Stephen Bond
I gave two spoiler-laden specific examples (for _A Change in
the Weather_ and _Rameses_) in the "Why Newbies
Don't Like IF" thread on rgif a few weeks ago. Still available
on Google Groups.
Here's another for _Photopia_, which has been alluded to in this
thread.
[SPOILERS]
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
In the colour sections of _Photopia_, you play a young girl who
is having a story told to her by her babysitter. One such section
is a blue crystal maze. For a while, you wander around the maze
using compass directions as usual, and there appears to be no
way out. But gradually, the storyteller clues you into the fact
that you have wings. You can soar above the maze!
You can >FLY! This is a moment of realisation that captures
something of the childlike wonder of the protagonist, a peak
of intimacy between her and her babysitter -- and also
a realisation that the game world has been imagined in three
dimensions, that it has *depth* -- figuratively and literally -- as
well as breadth. A realisation that would have been considerably
damped if >FLY was listed as one of twenty or thirty or even
a hundred available commands.
If anyone is interested, I've written a short essay about the
brilliance of a another concealed action (in the CYOA gamebook
_Creature of Havoc_, of all places) here:
http://www.plover.net/~bonds/creatureofhavoc.html
Stephen.
Daryl McCullough
In a work of interactive fiction, potentially <i>every</i>
verb phrase could be a possible command. Telling the player
which ones, out of the hundreds of thousands of possible
verb phrase, actually do something may be giving away information
that the player would enjoy discovering by playing the game.
For instance, there could be a strange device of unknown purpose
in a game with a science-fiction setting. Through piecing together
various clues, the player may discover that it is a teleportation
machine, or a mind-swapping machine. Now, if the author includes
a list of commands
teleport to X
swap minds with Y
that would give away the secret purpose of the machine. It would
spoil part of the fun (at least, some people think that figuring
things out can be fun).
Adam Thornton
Brian Wh. <bri...@sympatico.ca> wrote:
>Rubbish. To me it appears essentially broken-- the vast majority of
>possible inputs elicit error messages.
>Judging from the transcripts, most newbies share this opinion with me."
The vast majority of possible inputs, when used in actual conversation
with actual human beings, elicit error messages.
Adam
Adam Thornton
Kevin Forchione <ke...@lysseus.com> wrote:
>One shouldn't undervalue the importance of motivation here. Games have
>rules, and certainly one doesn't "dumb-down" something like bridge
Spades?
>or chess
Checkers? OK, that one's a stretch.
>in order to make the games more palatable for the newcomer. Instead one
>lures them in with peer excitement. Give IF a celeb, and the unwashed masses
>will come knocking down the doors in droves.
Maybe we could get Tom Cruise, as long as we didn't say anything nasty
about Scientology.
Adam
Mike Roberts
> Brian Wh. wrote:
>> If an IF only works if the author conceals the commands, it is
>> rubbish.
>
> Did you read the other thread? Do you think _Spider and Web_
> or _Photopia_ would have worked if the authors had presented
> all available commands?
I can't speak for "Brian Wh.", of course, but I can give my own answer. I
know which magic command you're talking about in Photopia, and you'll be sad
to hear that my reaction to that was: oh, guess-the-verb. And yet I still
liked Photopia; the gtv puzzle was just a ding in an otherwise well-designed
game.
As I've pointed out before, the extent to which concealed-verb puzzles are
pleasing is a matter of taste. It's not something everyone likes, and it's
not even something that everyone who likes IF likes. The former point is
obvious, given the number of people still interested in IF; but it's the
latter point that makes me chime in whenever this comes up, because a lot of
people around here don't seem to believe it. And that disbelief makes me
wonder: isn't there anything else about IF to like, apart from the concealed
verbs? Isn't there anything equally essential?
Mike Roberts
> Some games have a limited set of commands. Not everyone
> thinks IF should be that sort of game.
Not everyone doesn't, either, though - hopefully there's room for the
occasional variation.
Samwyse
> I can't speak for "Brian Wh.", of course, but I can give my own answer. I
> know which magic command you're talking about in Photopia, and you'll be sad
> to hear that my reaction to that was: oh, guess-the-verb. And yet I still
> liked Photopia; the gtv puzzle was just a ding in an otherwise well-designed
> game.
I'm rather stunned by that statement. I thought that it was a masterful
bit of linguistic sleight-of-hand, rather like those magic tricks where
the magician reveals that the dollar bill that you've been gripping
tightly is really a playing card.
> As I've pointed out before, the extent to which concealed-verb puzzles are
> pleasing is a matter of taste. It's not something everyone likes, and it's
> not even something that everyone who likes IF likes. The former point is
> obvious, given the number of people still interested in IF; but it's the
> latter point that makes me chime in whenever this comes up, because a lot of
> people around here don't seem to believe it. And that disbelief makes me
> wonder: isn't there anything else about IF to like, apart from the concealed
> verbs? Isn't there anything equally essential?
First, I think that everyone will readily concede that 90%, maybe even
99%, of all guess-the-verb situations are due to authorial errors, and
many of the rest shouldn't have been attempted. Nevertheless, there are
cases where it is successfully done, and those occasions invoke a
feeling of awe when I encounter them. I'd hate to eliminate any chance
of puzzles like those ever being written again.
Puzzles, I think, are essential. Some games feature puzzles that are
fiendishly subtle and/or complicated, and some people decide that
puzzle-less games are the way to go. But even those games feature
simple, almost invisible puzzles that are used to pace the game.
Maps are almost essential, but I say that as someone who wrote a very
traditional underground adventure set in a single room. That game also
broke a few of the other rules of "good" I-F, since I wrote it with the
goal of maximizing the number of times the player had to start over
after getting killed.
I'd guess that there are a handful of ingredients for a good game, but
any one or two of them can be completely omitted if the rest are used well.
Mike Roberts
> Mike Roberts wrote:
>> I know which magic command you're talking about in Photopia, and you'll
>> be sad to hear that my reaction to that was: oh, guess-
>> the-verb.
>
As I said:
>> [...] it's not even something that everyone who likes IF likes [and] a
>> lot of people around here don't seem to believe it.
Believe it. :)
> Nevertheless, there are cases where it is successfully done, and those
> occasions invoke a feeling of awe when I encounter them.
So you like that sort of thing. The thing is, for me they all feel
basically derivative of the primordial meta-UI puzzle in Adventure. (Know
the one I'm talking about? Now *that* was a proper guess-the-verb puzzle.)
It was highly surprising and amusing the first time I encountered that sort
of thing; somewhat less so the second time; and at this point, sorry to say,
I can't work up much awe when I encounter it.
> I'd hate to eliminate any chance of puzzles like those ever being written
> again.
Who said anything about eliminating chances? Not me. My point isn't that
*you* shouldn't like this sort of thing; it's that some people do and some
people don't, and those who number themselves in one camp shouldn't be
baffled and amazed at the existence of the other group, and shouldn't think
the other group must just be missing something. I mean, surely everyone by
now understands how futile it is to try to persuade someone who doesn't like
brussels sprouts that they just haven't had really good brussels sprouts,
right?
>> And that disbelief makes me wonder: isn't there anything else about IF to
>> like, apart from the concealed verbs?
>
> I'd guess that there are a handful of ingredients for a good game, but any
> one or two of them can be completely omitted if the rest are used well.
So my follow-up question is this: if you take the concealed verbs out, and
keep those other good ingredients, is it still possible for it to be IF?
And is it still possible for a concealed-verb-enjoyer to enjoy the result?
Or are concealed verbs a necessary condition of enjoyable IF for
concealed-verb-enjoyers?
The Photopia example that keeps coming up as an example of why concealed
verbs are so wonderful is interesting to me in that, from my perspective,
the game overall would actually have been slightly improved without the
concealed verb in that particular scene. But that's my perspective as a
non-concealed-verb-enjoyer. Concealed-verb supporters keep saying what a
great scene they think it is, but that doesn't seem to me to prove that
concealed verbs are necessary, just that maybe they're sufficient in some
sense for some people. So what about the necessity question? That is,
would Photopia have been ruined for concealed-verb-enjoyers without that
scene? Is that aspect of that scene what makes the whole game work for
CVEs?
steve....@gmail.com
> I'm rather stunned by [Mike's statement that the "magic command"
> in Photopia was a mere gtv puzzle]. I thought that it was a masterful
> bit of linguistic sleight-of-hand, rather like those magic tricks where
> the magician reveals that the dollar bill that you've been gripping
> tightly is really a playing card.
Don't be stunned. I'm a huge fan of Adam's writing, but I thought that
one was a cheap parlour trick at best (to develop your analogy). "Think
outside the box" was as terrible a cliche in 1998 as it is today, and
therefore an uninteresting contradiction. You can consider this part of
the game a stroke of genius, but don't be surprised if someone else can
think of it as trite pap. In any case, this example is not the best one
for our discussion, because it is in fact controversial (as stunning as
that may be).
But what sort of example are we looking for, and why? Authors will
continue to take advantage of the incomplete disclosure of the command
interface. Nobody can intelligently argue against that in principle.
Aaron A. Reed
>And that disbelief makes me
>wonder: isn't there anything else about IF to like, apart from the concealed
>verbs? Isn't there anything equally essential?
I think there's an important distinction here. A properly-clued use of
a verb that might not otherwise have been tried (like the wings in
Photopia) is not really a guess-the-verb puzzle, unless the author has
picked an unusual verb, because the game is practically telling you to
try it. This is fine. The problem arises when the author expects the
player to use a verb hitherto unimplemented, without clueing the player
in that this is possible. If I'm supposed to ACCUSE SUSPECT and the
game hasn't told me ACCUSE is a valid verb, I might be trying things
like TELL INSPECTOR ABOUT SUSPECT, ASK SUSPECT ABOUT DUBIOUS ALIBI,
etc., etc.... which in a good game should also be implemented. The joy
of the undefined vocabulary comes when words work that you didn't
expect to; if the ones you expected to work fail you, the author has
created a problem.
As to what's essential about IF: to me, it's the fact that you're
combining all the imagination-sparking allure of good fiction with the
powerful device of actually getting to BE the main character. The
undefined command set is sometimes a plus, but isn't essential to the
experience. There is certainly IF with basic commands that's still
engrossing or interesting. It's really all about the writing,
storytelling, and implementation; the parser is just the front end to
the experience.
Samwyse
> So you like that sort of thing. The thing is, for me they all feel
> basically derivative of the primordial meta-UI puzzle in Adventure. (Know
> the one I'm talking about? Now *that* was a proper guess-the-verb puzzle.)
> It was highly surprising and amusing the first time I encountered that sort
> of thing; somewhat less so the second time; and at this point, sorry to say,
> I can't work up much awe when I encounter it.
I'll assume you mean "THERE IS SOMETHING STRANGE ABOUT THIS PLACE, SUCH
THAT ONE OF THE WORDS I'VE ALWAYS KNOWN NOW HAS A NEW EFFECT."
> So my follow-up question is this: if you take the concealed verbs out, and
> keep those other good ingredients, is it still possible for it to be IF?
> And is it still possible for a concealed-verb-enjoyer to enjoy the result?
> Or are concealed verbs a necessary condition of enjoyable IF for
> concealed-verb-enjoyers?
That's my point. Many games have problems with unintentional "guess the
verb" situations (I hesitate to call them puzzles, they're usually a
sort of bug). They would all be improved by eliminating the problem.
The people who like those puzzles I suspect like them because they are
so rarely done.
> The Photopia example that keeps coming up as an example of why concealed
> verbs are so wonderful is interesting to me in that, from my perspective,
> the game overall would actually have been slightly improved without the
> concealed verb in that particular scene. But that's my perspective as a
> non-concealed-verb-enjoyer. Concealed-verb supporters keep saying what a
> great scene they think it is, but that doesn't seem to me to prove that
> concealed verbs are necessary, just that maybe they're sufficient in some
> sense for some people. So what about the necessity question? That is,
> would Photopia have been ruined for concealed-verb-enjoyers without that
> scene? Is that aspect of that scene what makes the whole game work for
> CVEs?
What can I say? I can't see how the scene could have been written to
achieve the desired effect without concealed verb. The events leading
up to the surprise set up a level of frustration, the game effectively
forced you into taking an action that revealed that another action was
possible that you hadn't previously considered, and the dramatic tension
was suddenly resolved. It's been a few years, but I think my reaction
was, "What the heck? Oh. Wow!"
fiziwig
>> and then failing to realize that "look in bag" or "look behind bag"
>> are possible. I'm worried about someone learning "look bag" and then
>> having no idea how to put a stone into the bag.
>> (I would be all for a game that took "look bag" and responded "Try
>> 'look at bag'." In fact, I should have thought of that for Dreamhold.)
As a pretty newbie player myself I'd rather have the response be
something like:
Do you want to look AT the bag or look IN the bag? That trains the
player in the proper usage of the verb.
--gary
Kevin Forchione
news:1nVDf.21380$Jd....@newssvr25.news.prodigy.net...
> The Photopia example that keeps coming up as an example of why concealed
> verbs are so wonderful is interesting to me in that, from my perspective,
> the game overall would actually have been slightly improved without the
> concealed verb in that particular scene. But that's my perspective as a
> non-concealed-verb-enjoyer. Concealed-verb supporters keep saying what a
> great scene they think it is, but that doesn't seem to me to prove that
> concealed verbs are necessary, just that maybe they're sufficient in some
> sense for some people. So what about the necessity question? That is,
> would Photopia have been ruined for concealed-verb-enjoyers without that
> scene? Is that aspect of that scene what makes the whole game work for
> CVEs?
And one has to ask, would it be possible for a game to determine, to some
small degree, the psychology of the player, and to then provide, based on
that determination, a subtle shift in style so that perhaps the CVE would
receive the scene played out one way, while the non-CVE would receive it
another? That is to say, could one determine the psychology of the player
from their command choices? Is there a statistical pattern to the CVE?
--Kevin
Samwyse
> As a pretty newbie player myself I'd rather have the response be
> something like:
>
> Do you want to look AT the bag or look IN the bag? That trains the
> player in the proper usage of the verb.
Verb 'look'
* noun -> VagueLook;
[ VagueLookSub ;
print "Do you want to LOOK AT ", (the)noun;
if (noun has supporter) print " or LOOK ON ", (the)noun;
if (noun has container) print " or LOOK IN ", (the)noun;
"?";
];
The only problem is that the player might reply with just the
preposition. I can't speak for TADS, but the Inform library lacks tools
to let the author constructively interfere with the parser in this sort
of situation.
Brian Wh.
thread.
[SPOILERS] "
Stephen,
Thanks very much for the example. I will check it out and get back to
this thread.
It may take me a week or so.
Thanks again,
Brian
Brian Wh.
"In a work of interactive fiction, potentially <i>every</i>
verb phrase could be a possible command. "
Actually, when I say command list, I mean a complete list of verbs,
(not verb phrases) and the syntax for using them.
I agree that a list of all _verb phrases_ would not be helpful or
productive.
I wonder if other posters got the same wrong impression...? ooops.
Kevin Forchione
news:1138772530....@g44g2000cwa.googlegroups.com...
Nope. A list of all possible commands would be impractical. But it would be
trivial to create a <<verbs>> player command that produced a list of all
verbs within a given game. I doubt very much that such a list would give
very much away. It would seem more likely for objects to be unknown to
players than for verbs to be, and more prone to "spoiling" a puzzle.
I believe that more pleasure is to be derived out of the sophisticated use
of drama, mystery, and suspense than by simply withholding information from
the player without due motivation. And more pleasure seems to be derived
from resolving a problem through the juxtaposition of common objects and
common actions where such objects and actions are not normally paired
together, rather than the introduction of an exotic action into the game.
One must regard the psychology of the player in this respect: there is far
more likelihood of a satisfying experience of immersion if the actions are
an organic part of the world, and their patterns deduced rather than
guessed. Stories must obey the laws of narrative causality, and when such is
not the case then what one experiences at best is a shifting of player
consciousness from story-immersion to meta-story fascination, and at worst
the psychological breach results in non-participation.
--Kevin
Urbatain
genre in the games world (or fiction world). You see, a graphical
game... you have an very reduced asset of commands, so when you hit a
good action and solve a puzzle, you get some satisfaction, but some of
the puzzle "way" is spoiled by the limited set of actions (you can
take, or use, or take, or use, it's easy enough). But here in IF the
player may think that the interface is infinite, and maybe, sometimes,
almost for every puzzle the solutions comes without spoilers from your
pretty chovinist mind (this for laugh about spanish), so IF has the
perfect interactivity.
But, natural language being undestood by parsers is an utopia, and drop
a game in free fall with that ideas is a bad one when a newbie is
playing... the frutration allways will be more powerfull than the full
interactive experience that IF can gives. So the way to go is add
instructions, or hints to the newbie to know where to go with her
parser typings.
Understandme, no at all a very reduced amount of actions with an
instruction set, but not at all the illusion of a infinite perfect
parser.
And, every luminarie here use full instructions set within their games,
Emily, Adam (along with a reduced set of actions compared with the
standard inform libnrary, Plotkin, Paul O'B, etc) in their recent
works. This means something.
See you.
Urbatain.
Urbatain
posible action that the human parser can generate, in a RPG module it
will be a default kind response like: "that's not important" :)
But you see... livbe RPG with human master is the perfect IF. We must
abandon inform, tads, hugo and every non human tool, and return to our
origins :)
I have a new game to play, the parser is Urbatain, you can play one by
one in the IF MUD from 9:00 to 13:00 spanish hour!
See you.
Urbatain.
Urbatain
highly superior to every other kind of interface. That "Eureka!" only
exists here in IF.
Of course, to reveal that actions in a instruction set will be a stupid
spoiler, but I really mean about the "standards" of the model world.
The newbie player must be issued about something like "win the game,
search for the gold cup and share it with my friends to celebrate my
victory" it's no a legal action in the game. Or that containers must me
aproach with put in, take from, etc.
Ummmmmm... old tecniques about guessing the parser with PAW games or
level9 ones is a very good practice for learning a new genre for a
newbie. To tell the player that THAT phrase is not understood because
the parser doens't know that verb, or that kind of word is in the
vocabulary, but that object "is not important for winning the game", is
another good idea to teach a new player about our standards. This is
what I name "negative feedback". Feedback of the parser about wrong
phrases or wrong actions, or illegal ones.
See you.
Urbatain.
Urbatain
a guess the verb problem. I can think in the "register" action for a
game that never used it at all in all its lenght less the end. Or for
example "A bear's night out", the sucessive look into that gives
successives objects, is a guess the feature problem. It's allways a
good idea, if your game requires a rarerly used verb at one point, to
allow the player to experiment that verb earlier.
But in Photopía that's not the case, because Photopía gives very well
clever clues about that magic word. So Photopía is perfect in that, is
very clever hinted.
See you.
Urbatain.
Samwyse
> Verb 'look'
> * noun -> VagueLook;
>
> [ VagueLookSub ;
> print "Do you want to LOOK AT ", (the)noun;
> if (noun has supporter) print " or LOOK ON ", (the)noun;
> if (noun has container) print " or LOOK IN ", (the)noun;
> "?";
> ];
>
> The only problem is that the player might reply with just the
> preposition. I can't speak for TADS, but the Inform library lacks tools
> to let the author constructively interfere with the parser in this sort
> of situation.
After sleeping on the preceding, I have a couple more ideas. They boil
down to the fact that action routines need a way to communicate problems
back to the parser.
Right now, most if not all such routines return true; a different value
could be used to tell the parser that an error occurred. If the grammar
lines denote possible errors could be marked somehow, then only the
small number of action routines so noted would have to be changed. This
marking could be done via the 'meta' flag, or the compiler could be
patched to allow a new flag such as 'vague'.
On the other hand, more than a single value may need to be communicated
back to the parser. VagueLookSub apparently needs to tell the parser
two things, both that a preposition is missing, and where in the line it
was expected. The parser already keeps a couple of extra copies of the
player's input around for the 'oops' command and disambiguation replies,
these could be used to insert a bare preposition into a command.
The fact that it's a preposition that is missing can be inferred in the
above example, so just returning an insertion point may handle
everything that's needed. On the other hand, I can see other instances
where something similar could be useful, just not in English.
The Russian language has no word for 'go'; speakers have to always say
either 'walk' or 'ride'. Logically, using these verbs in a game could
lead to implied ##Board and ##Disembark actions. Using a bare compass
direction as an action in English implies ##Go, but in a Russian game
one might logically see a disambiguation question if you're in a
location with a vehicle. For example:
> LOOK
You are in the town square. A tavern sits to the north, and beyond
it are the steppes. Your horse grazes nearby.
> NORTH
Do you mean to walk or to ride?
> RIDE
(First getting onto the horse.)
You ride north for several miles across the steppes...
Pulling off the above would require a reworking of the way the library
handles room objects (replacing the x_dir properties with walk_x and
ride_x ones), but for some languages such an effort might make sense.
The point of the above digression is to note that the compass object has
an implied action associated with it. Currently, that action is built
into the parser, but it could easily be separated out as a property of
the compass itself. In a non-Engish game that property might point to a
fake WalkOrRide action that in turn might need to trigger a
disambiguation question.
Stephen Bond
> I can't speak for "Brian Wh.", of course, but I can give my own answer. I
> know which magic command you're talking about in Photopia, and you'll be sad
> to hear that my reaction to that was: oh, guess-the-verb. And yet I still
> liked Photopia; the gtv puzzle was just a ding in an otherwise well-designed
> game.
Guess-the-verb is more usefully applied to puzzles where you know
the solution, and know how to phrase it in natural language, but
don't know the phrasing the parser expects. This is usually
considered a design flaw. At that moment in Photopia, once you
know what to do, there's never any doubt about what verb the
parser expects.
> As I've pointed out before, the extent to which concealed-verb puzzles are
> pleasing is a matter of taste.
And as I've replied before, that's a fairly obvious and uninteresting
observation. We can't measure the quality of the concealed-verb
experience in SI units. We're arguing personal taste here. (And
concealing the full verb set isn't just about puzzles.)
> And that disbelief makes me
> wonder: isn't there anything else about IF to like, apart from the concealed
> verbs? Isn't there anything equally essential?
What I like about IF varies from game to game (and I don't like most
IF games), but if I was to abstract it all to one common element, it
would be the enjoyment of interacting with a richly realised world.
The open-endedness of the verb set contributes to the illusion of
richness -- I'd even say it was essential for establishing it. As I've
said before, giving the player a limited set of verbs makes the
world seem more like a contrivance.
Of course, other things like good writing and good game design are
essential too, and much harder to come by.
> So my follow-up question is this: if you take the concealed verbs out, and
> keep those other good ingredients, is it still possible for it to be IF?
> And is it still possible for a concealed-verb-enjoyer to enjoy the result?
I suspect I'd answer no to both of those questions, but this is very
hypothetical. I'd have to see the game. Certainly, I don't think the
games I've played with up-front verb sets (such as the LA adventures
or most CYOA books, much as I liked them) truly succeed as IF.
> So what about the necessity question? That is,
> would Photopia have been ruined for concealed-verb-enjoyers without that
> scene? Is that aspect of that scene what makes the whole game work for
> CVEs?
No one is arguing that that part of the scene makes the whole game
work. But again, I suspect that if _Photopia_ had been accompanied by
an LA-style menu with N possible verbs, my enjoyment of the game
would have been considerably diminished. Alley says "Let's tell a
story together" and not "Let's tell a story together, except you're
only allowed to say >PULL and >PUSH and >PICK UP".
Stephen.
David Thornley
Stephen Bond <steph...@ireland.com> wrote:
>Mike Roberts wrote:
>
>> I can't speak for "Brian Wh.", of course, but I can give my own answer. I
>> know which magic command you're talking about in Photopia, and you'll be sad
>> to hear that my reaction to that was: oh, guess-the-verb. And yet I still
>> liked Photopia; the gtv puzzle was just a ding in an otherwise well-designed
>> game.
>
>Guess-the-verb is more usefully applied to puzzles where you know
>the solution, and know how to phrase it in natural language, but
>don't know the phrasing the parser expects. This is usually
>considered a design flaw. At that moment in Photopia, once you
>know what to do, there's never any doubt about what verb the
>parser expects.
>
in question, but a very standard IF verb instead.) As long as the
parser recognizes all reasonable verbs, it isn't guess-the-verb.
This means, BTW, that a list of verbs could be supplied that would
be enough to get through that puzzle without giving it away.
Would people be happier about it if there was a VERBS response
that excluded that particular three-letter word?
IF is, I believe, enriched by the fact that some puzzles require
non-obvious actions, and some non-obvious actions require special
verbs. As long as the parser recognizes enough ways to specify
the action, I don't think that's a problem.
The real world is surprising; that's one of its characteristic features.
If the IF world is predictably limited, that takes away much of the charm.
>> And that disbelief makes me
>> wonder: isn't there anything else about IF to like, apart from the concealed
>> verbs? Isn't there anything equally essential?
>
>What I like about IF varies from game to game (and I don't like most
>IF games), but if I was to abstract it all to one common element, it
>would be the enjoyment of interacting with a richly realised world.
>The open-endedness of the verb set contributes to the illusion of
>richness -- I'd even say it was essential for establishing it. As I've
>said before, giving the player a limited set of verbs makes the
>world seem more like a contrivance.
>
It looks to me like some people find "I don't know what you're talking
about" messages a turn-off, and other people love the illusion that
a large and indefinite set of verbs gives.
>> So my follow-up question is this: if you take the concealed verbs out, and
>> keep those other good ingredients, is it still possible for it to be IF?
>> And is it still possible for a concealed-verb-enjoyer to enjoy the result?
>
>I suspect I'd answer no to both of those questions, but this is very
>hypothetical. I'd have to see the game. Certainly, I don't think the
>games I've played with up-front verb sets (such as the LA adventures
>or most CYOA books, much as I liked them) truly succeed as IF.
>
I would say that it depends on the game. Rameses, for example, would
probably not be hurt at all by a VERBS command. Photopia, if my
memory is correct, would not be hurt by a VERBS command that gave
all necessary verbs but not all the ones the game actually accepts.
It may be possible to find a middle ground. Have a list of standard
IF verbs, along with all others that are introduced by the opening
help that most people don't read. As the game goes along, add
verbs that the player uses successfully, as well as others that
are introduced:
Congratulations! You have just finished the Gulliver Foyle class.
You can now <b>jaunt</b> or <b>teleport</b> to locations you are
familiar with.
Let that list be produced with a VERBS command, and make a reference
to that in the very basic opening help.
If you are new to IF, you can get help at any time by typing HELP,
or a list of verbs that may be useful by typing VERBS.
And, ideally, set up all actions so they can be done with the listed
verbs, if possible.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Stephen Bond
> In article <1138797934.2...@g14g2000cwa.googlegroups.com>,
> Stephen Bond <steph...@ireland.com> wrote:
> >
> >Guess-the-verb is more usefully applied to puzzles where you know
> >the solution, and know how to phrase it in natural language, but
> >don't know the phrasing the parser expects. This is usually
> >considered a design flaw. At that moment in Photopia, once you
> >know what to do, there's never any doubt about what verb the
> >parser expects.
> >
> There can be doubt, but who cares? (IIRC, I never used the verb
> in question, but a very standard IF verb instead.) As long as the
> parser recognizes all reasonable verbs, it isn't guess-the-verb.
I'm arguing that it isn't guess-the-verb, not attempting to
give a precise definition of guess-the-verb.
> This means, BTW, that a list of verbs could be supplied that would
> be enough to get through that puzzle without giving it away.
> Would people be happier about it if there was a VERBS response
> that excluded that particular three-letter word?
I've no problem with a verb list, as long as it's obviously a partial
list and not 'full disclosure'. (Though I think any obvious synonym
of that three-letter-word would be a spoiler in this case.)
> The real world is surprising; that's one of its characteristic features.
> If the IF world is predictably limited, that takes away much of the charm.
Yup, agreed.
> >I suspect I'd answer no to both of those questions, but this is very
> >hypothetical. I'd have to see the game. Certainly, I don't think the
> >games I've played with up-front verb sets (such as the LA adventures
> >or most CYOA books, much as I liked them) truly succeed as IF.
> >
> I would say that it depends on the game. Rameses, for example, would
> probably not be hurt at all by a VERBS command.
It wouldn't be hurt by a partial verb list, but definitely would by a
complete verb list, as I've argued in the other thread. It's the
difference between not doing actions A,B or C and not doing
*anything*.
Stephen.
Andrew Plotkin
> [...] A list of all possible commands would be impractical. But it would be
> trivial to create a <<verbs>> player command that produced a list of all
> verbs within a given game. I doubt very much that such a list would give
> very much away. It would seem more likely for objects to be unknown to
> players than for verbs to be, and more prone to "spoiling" a puzzle.
*In principle*, a list of objects in the game is exactly the same kind
of spoiler as a list of actions.
And in practice, every game presents some explicit documentation and
some implicit clues. Nobody is saying that _Enchanter_ was degraded as
a game because the docs explained the "learn spell" action.
> I believe that more pleasure is to be derived out of the
> sophisticated use of drama, mystery, and suspense than by simply
> withholding information from the player without due motivation.
That's begging the question. Of course a simplistic, unmotivated use
of a technique will work out badly.
When I withhold information -- about the story, the characters, the
world, or the protagonist's choices -- I am doing it in support of
drama, mystery, and suspense.
And note the focus there. The point is not, and never has been, to
"conceal a verb". That phrase is a fallacy. The goal is for an
*action* to be *discoverable*: you realize *what you want to do*.
("In the game world", to reuse the phrase I frequently reuse.)
Figuring out the *command to type* should, after that revelation, be
a simple and obvious step to take.
Yes, people sometimes trip on that step. Authors sometimes fail to
make it an obvious one. But don't confuse that failure with the goal
of the exercise, and don't try to solve it by eliminating the goal.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because you're innocent.
ems...@mindspring.com
> probably not be hurt at all by a VERBS command.
I'm pretty sure it would -- at least, I remember that one or two of the
game's best moments (for me) came when I tried a command completely
outside the usual IF command set, but in keeping with my PC's
characterization, and had it *work*. These commands weren't necessary
to finish the game, and I would have been far less entertained by them
if I'd read them on the list of possible verbs at the beginning.
Something similar is true of several other games that turn on the
player getting into the role of the PC and learning to think and act
like him: "Kissing Bandit" and "Act of Misdirection" come immediately
to mind.
But I agree with your assessment that this depends on the game. If
giving instructions at all (which I didn't in my first few games
because I didn't anticipate an audience outside the IF community), I
list all the commands that the player will need to complete a
playthrough; if any are left out it is because, as Zarf says, they
represent *actions* that the player won't discover until partway
through the game. In that case, I try to make sure that the right
commands to use are strongly hinted at the moment that the new ability
is introduced.
Kevin Forchione
news:1138826907.6...@z14g2000cwz.googlegroups.com...
Sounds like the right solution. One would hope that the language of the
player would grow out of the playing experience organically, and where this
needs supplementing, then perhaps it should be.
--Kevin
Daryl McCullough
>When I withhold information -- about the story, the characters, the
>world, or the protagonist's choices -- I am doing it in support of
>drama, mystery, and suspense.
Right. I don't see how, in *principle* there is much difference
between a game author withholding the information that it is
possible to teleport in a game, and a novelist withholding that
the gardner committed the murder, or that the main character is
the heir to the throne of Zinapaz.
>And note the focus there. The point is not, and never has been, to
>"conceal a verb". That phrase is a fallacy. The goal is for an
>*action* to be *discoverable*: you realize *what you want to do*.
>("In the game world", to reuse the phrase I frequently reuse.)
>Figuring out the *command to type* should, after that revelation, be
>a simple and obvious step to take.
Exactly right. It's *usually* considered a "bug" if the player
knows what he wants to do, but can't figure out how to make the
damn parser understand it. (Maybe there are some counterexamples
that I'm not aware of?) But that brings up the question of why not
just have some generic command such as "use X with Y" that always
works? I think the answer to that is that often the game author
wants the player to experience a moment of insight into his
character's situation, and the precise command (including the
choice of verb) is evidence that this insight has indeed occurred.
It's *supposed* to be infeasible to solve the puzzle without
this insight (for example, by exhaustively trying all possibilities).
--
Daryl McCullough
Ithaca, NY
Michel Nizette
> Did you read the other thread? Do you think _Spider and Web_ or
> _Photopia_ would have worked if the authors had presented all
> available commands?
Why exactly wouldn't _Spider and Web_ have worked if the author had included
a list of all available commands? I ask the question sincerely, since it
seems to me that the puzzle you must have in mind was about using in some
proper context a command the player had plenty of time to experiment with
before, and which was therefore not concealed at all.
--Michel.
Neil Cerutti
Inform has heavy, blunt-headed tools that will work in this case.
The introduction of a new global array to store the deferred
command and a BeforeParsing entry point to check for the reponse
could accomplish it.
--
Neil Cerutti
Mark J. Tilford
>
>
> Andrew Plotkin says...
>
>>When I withhold information -- about the story, the characters, the
>>world, or the protagonist's choices -- I am doing it in support of
>>drama, mystery, and suspense.
>
> Right. I don't see how, in *principle* there is much difference
> between a game author withholding the information that it is
> possible to teleport in a game, and a novelist withholding that
> the gardner committed the murder, or that the main character is
> the heir to the throne of Zinapaz.
>
>>And note the focus there. The point is not, and never has been, to
>>"conceal a verb". That phrase is a fallacy. The goal is for an
>>*action* to be *discoverable*: you realize *what you want to do*.
>>("In the game world", to reuse the phrase I frequently reuse.)
>>Figuring out the *command to type* should, after that revelation, be
>>a simple and obvious step to take.
>
> Exactly right. It's *usually* considered a "bug" if the player
> knows what he wants to do, but can't figure out how to make the
> damn parser understand it. (Maybe there are some counterexamples
> that I'm not aware of?) But that brings up the question of why not
Ad Verbum
> just have some generic command such as "use X with Y" that always
> works? I think the answer to that is that often the game author
> wants the player to experience a moment of insight into his
> character's situation, and the precise command (including the
> choice of verb) is evidence that this insight has indeed occurred.
> It's *supposed* to be infeasible to solve the puzzle without
> this insight (for example, by exhaustively trying all possibilities).
>
> --
> Daryl McCullough
> Ithaca, NY
>
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
Eric Eve
news:MDXDf.40714$dW3....@newssvr21.news.prodigy.com...
> fiziwig wrote:
>
>> As a pretty newbie player myself I'd rather have the response be
>> something like:
>>
>> Do you want to look AT the bag or look IN the bag? That trains
>> the
>> player in the proper usage of the verb.
This is a good suggestion; in common with some of the others I've
seen flying around in this and related threads I'm pinching it for
my current WIP.
> The only problem is that the player might reply with just the
> preposition. I can't speak for TADS, but the Inform library lacks
> tools to let the author constructively interfere with the parser
> in this sort of situation.
I've had a look at in in TADS 3, and it seems perfectly feasible to
cover the case where the player replies with a preposition (provided
it's one of the prepositions you're expecting); e.g.:
>LOOK BOOK
Do you want to look at the book or under it or through it or behind
it or in it?
>AT
{look at the book)
It's a big blue book entitled "The Perfect Parser (and other
fictional tales)".
Outside this context, the parser will still reject a lone
preposition as an illegal command, but hopefully the "(look at the
book)" announcement will help steer players towards the correct
phrasing. In my experimental implementation I've also hyperlinked
the prepositions in the "Do you want to look at the book or..."
response so that, for example, if the player clicks on AT the
command LOOK AT THE BOOK is sent to the command line and executed
(HTML-TADS makes this easy to do).
The difficult balance to get right here (not just in this case but
throughout all the interesting proposals that have been aired
recently) is between (a) helping newbies without (b) leading them
into bad habits or (c) getting in the way of more experienced
players. I think the above implementation of LOOK X does that, but
others may disagree. Again, I think it may be more helpful than not
to implement a GO TO verb (to handle, e.g., GO TO TABLE when the
table is already in the same location as the PC), since when the
command is redundant the response can simply say so ("You're already
as near to the table as you need to be. "), while sometimes there
may be a useful action to carry out (e.g. interpret GO TO BED as LIE
ON BED). I'm inclined to think this may help newbies learn that GO
TO X is generally not needed in a less annoying way than a parser
error that refuses to recognize the input at all, but again, others
may feel this simply leads newbies into bad habits.
Much has been said about a VERBS command; I'm of the view, expressed
by several others, that this can be helpful but does not need to be
exhaustive. For example, we often implement extra verbs not because
they're actually needed to complete the game, but because it's
apparent (or becomes apparent through beta-testing and other
feedback) that they correspond to a phrasing some players might use.
There seems to be no *need* to list such verbs explicity. Again,
there's surely no need to list every library synoynm (PUT IN = PLACE
IN etc.). It probably is a good idea to give an example of a verb
phrase with each, otherwise the correct usage (i.e. the usage
implemented) may not be apparent to the player reading the list. For
example, in a list of verbs alone, it would not be clear if FLY had
been implemented transitively (e.g. FLY THE KITE), intransitively
(FLY only) or both, and it's surely a bit counter-productive to
replace a guess-the-verb puzzle with a guess-the-verb-usage puzzle.
Finally, it does seem to me to be legitimate to hold back from
listing commands the listing of which would constitute a spoiler,
provided they are adequately clued before they are needed.
There's been some discussion about simply ignoring spurious words
from player input and using the rest. (E.g. taking PLACE THE FRAGILE
VASE EVER SO DELICATELY ON THE TABLE THAT's STANDING IN THE MIDDLE
OF THE ROOM, JUST UNDER THE CHANDELIER to mean simply PUT VASE ON
TABLE). I suspect this would prove counter-productive in the long
run, at least with the current state of parser technology, since it
would simply mislead newbies (and other players besides) into
supposing your parser is much smarter than it is, while not leading
them into communicating with the parser more effectively. A second
danger is that words that might be extraneous noise in the context
of one game may in fact be significant in another, so a library
parser that worked that way in an authoring system could end up
frustrating authors.
Some mention has also been made of using automatic typo-correction.
I'm currently experimenting with Steve Breslin's TADS 3
SpellingCorrector module, and it's certainly effective up to a
point. The problem is that there's a limit to what it can do without
being too aggressive to be helpful (I'm not saying Steve's is, I'm
discussing a more hypothetical problem here).
For example, suppose a newbie friendly game implements both
typo-correction and the LOOK X grammar discussed above. Our fearless
newbie then types:
>LOK DOOR
Does this mean LOOK DOOR or LOCK DOOR? If the automatic typo
corrector hazards a guess and gets it wrong, the newbie will only be
the more irritated about it ("stupid game, I *obviously* meant LOOK
AT DOOR, now it's gone and locked the damn thing!"). If, more
sensibly, the automatic typo corrector realizes that the player's
meaning is indeteminate and attempts no correction, our newbie who
has seen it work before but does not realize why the present case is
ambiguous will regard the typo feature as erratic.
I suppose in this case the game could respond with "Did you mean
LOCK DOOR or LOOK DOOR?", but if the player then types LOOK, is this
a LOOK AROUND command or a LOOK DOOR command? If the latter, the
player will then see "Did you want to look at the door or in the
door or...", and the newbie-friendly features suddenly won't seem so
friendly any more:
>LOK DOOR
Did you mean LOCK DOOR or LOOK DOOR?
>LOOK DOOR
Did you want to look at the door, in the door, under the door,
behind the door, or through the door?
>QUIT
Cheerio; thanks ever so much for playing; do try again some time!
On balance, my experience with Steve Breslin's T3 spelling corrector
is that it's very helpful in correcting some typos, but that it's
not a mechanism that be used to handle all or even most of them. It
*may* be a mixed blessing in terms of newbie-friendliness in that
*could* lead newbies into relying on it too much; though I'm not
personally persuaded that it would, it would be interesting to hear
if anyone thinks otherwise.
-- Eric
Paul E Collins
> > LOOK DOOR
> Did you want to look at the door, in the door, under the door,
> behind the door, or through the door?
> YES
P.
Michel Nizette
> If, more sensibly, the automatic typo corrector realizes that the player's
> meaning is indeteminate and attempts no correction, our newbie who has
> seen it work before but does not realize why the present case is ambiguous
> will regard the typo feature as erratic.
I'm in favor of this cautious approach, nevertheless. I can't truly speak
for a newbie, but I don't think I'd blame the game for not understanding
something I can myself recognize as incorrect, even if I had seen the typo
correction feature in action before. I'd probably think, rather, that I was
particularly lucky the first times. In contrast, imagining myself as a
newbie, I think I might shy away if the game, in an attempt to make sense of
my input at all costs, brought me into all sorts of disambiguation queries
and modal dialogs which I'd then have to learn to negotiate on the spot.
Basically, I agree with Mike Roberts's view that comprehensibility of the
parser's mechanics might be a better goal than flexibility, and simply
attempting no correction of a typo that can't be unambiguously corrected
seems to be a pretty comprehensible bevahior.
--Michel.
Daryl McCullough
>"Samwyse" <sam...@gmail.com> wrote in message
>news:MDXDf.40714$dW3....@newssvr21.news.prodigy.com...
>> fiziwig wrote:
>>
>>> As a pretty newbie player myself I'd rather have the response be
>>> something like:
>>>
>>> Do you want to look AT the bag or look IN the bag? That trains
>>> the player in the proper usage of the verb.
>
>This is a good suggestion; in common with some of the others I've
>seen flying around in this and related threads I'm pinching it for
>my current WIP.
Here's an approach that I've never seen done before
(maybe because it would be too hard, and maybe because
it would be a stupid thing to do). How would it
work if every time there is an ambiguity with a small number of
possible interpretations (say 5 or fewer), the interpreter presents
a menu of choices. For example
>look bag
Do you want to
1. Look at the bag
2. Look in the bag
3. Forget it
(Type the number of your choice)
>2
In the bag, you see...
Eric Eve
"Michel Nizette" <Mic...@Nizette.name> wrote in message
news:drtb32$48l$1...@snic.vub.ac.be...
>
> I'm in favor of this cautious approach, nevertheless. I can't
> truly speak for a newbie, but I don't think I'd blame the game for
> not understanding something I can myself recognize as incorrect,
> even if I had seen the typo correction feature in action before.
> I'd probably think, rather, that I was particularly lucky the
> first times. In contrast, imagining myself as a newbie, I think I
> might shy away if the game, in an attempt to make sense of my
> input at all costs, brought me into all sorts of disambiguation
> queries and modal dialogs which I'd then have to learn to
> negotiate on the spot.
I'm inclined to agree. Indeed, that was partly what my final
mock-transcript was designed to illustrate.
> Basically, I agree with Mike Roberts's view that comprehensibility
> of the parser's mechanics might be a better goal than flexibility,
> and simply attempting no correction of a typo that can't be
> unambiguously corrected seems to be a pretty comprehensible
> bevahior.
Then once again we're basically in agreement; at least the behaviour
you advocate is the one I'd be inclined to incorporate in practice.
In part what I was trying to do in my previous post was to explore
the possible effects of unintended consequences here: feature X (in
this case a conservative typo-corrector) seems like a useful
newbie-friendly (and general-player-friendly) feature, but let's
just check there isn't a possible down-side that would make it not
such a great idea after all.
-- Eric
steve....@gmail.com
> Eric Eve wrote:
>
> > If, more sensibly, the automatic typo corrector realizes that the player's
> > meaning is indeteminate and attempts no correction, our newbie who has
> > seen it work before but does not realize why the present case is ambiguous
> > will regard the typo feature as erratic.
>
> I'm in favor of this cautious approach, nevertheless.
Early in the development of the Tads-3 corrector, it became very
obvious that a spelling corrector needs to abstain where there is more
than one "equally-legitimate" transformation of a given typo.
Otherwise, the corrector is just horribly obnoxious, and it's far
better having no correction whatsoever.
So, if we're to do any spelling correction at all, this inevitably
means that our corrector will assert itself in one case, yet abstain in
a case which will seem to the player closely equivalent.
Efforts to improve our tiebreaking of "arguably-equivalent" cases *can*
lead to a smarter corrector, but they can also lead to a corrector that
unfortunately asserts itself in those cases where abstinance is much
less offensive.
Abstinance is relatively unoffensive because the player will take
responisibility for the error in the first place. Also, we speculated
that the service is one the player will notice at first, but quickly
forget about.
That being the case, we designed a corrector which errs, for the most
part, on the side of caution.
Eric Eve
news:1138906212.4...@g43g2000cwa.googlegroups.com...
> Michel Nizette wrote:
>> Eric Eve wrote:
>>
>> > If, more sensibly, the automatic typo corrector realizes that
>> > the player's
>> > meaning is indeteminate and attempts no correction, our newbie
>> > who has
>> > seen it work before but does not realize why the present case
>> > is ambiguous
>> > will regard the typo feature as erratic.
>>
>> I'm in favor of this cautious approach, nevertheless.
>
> Early in the development of the Tads-3 corrector, it became very
> obvious that a spelling corrector needs to abstain where there is
> more
> than one "equally-legitimate" transformation of a given typo.
> Otherwise, the corrector is just horribly obnoxious, and it's far
> better having no correction whatsoever.
>
> So, if we're to do any spelling correction at all, this inevitably
> means that our corrector will assert itself in one case, yet
> abstain in
> a case which will seem to the player closely equivalent.
> Abstinance is relatively unoffensive because the player will take
> responisibility for the error in the first place. Also, we
> speculated
> that the service is one the player will notice at first, but
> quickly
> forget about.
>
> That being the case, we designed a corrector which errs, for the
> most
> part, on the side of caution.
Sure, and that was absolutely the right approach. I hope it was
apparent that my remarks were *not* intended to be critical of it.
The context of my musings was not "how should the ideal
typo-corrector work?" but "what might be the practical implication
for newbie-friendliness of some of the suggestions made in this
thread?".
-- Eric
Mike Roberts
>> The thing is, for me they [concealed-verb puzzles] all feel basically
>> derivative of the primordial meta-UI puzzle in Adventure.
> I'll assume you mean "THERE IS SOMETHING STRANGE ABOUT THIS PLACE, SUCH
> THAT ONE OF THE WORDS I'VE ALWAYS KNOWN NOW HAS A NEW EFFECT."
That's not the one I had in mind, actually; I was talking about something
even more meta-UI, involving a dragon and a seemingly rhetorical question.
--Mike
mjr underscore at hotmail dot com
steve....@gmail.com
parser would go exactly where the spelling-corrector plugs into the
parsing sequence, and I think the output (the parenthesis around the
transformed command phrase) and consequent behavior (replacing the
command with a modified token list) should be the same. Really,
newbie-friendly command-line fault tolerance is a natural development
from spelling correction.
Adam Thornton
Mike Roberts <mj...@hotmail.com> wrote:
>That's not the one I had in mind, actually; I was talking about something
>even more meta-UI, involving a dragon and a seemingly rhetorical question.
Yes.
Adam
Greg Boettcher
> fiziwig wrote:
>
> > As a pretty newbie player myself I'd rather have the response be
> > something like:
> >
> > Do you want to look AT the bag or look IN the bag? That trains the
> > player in the proper usage of the verb.
>
> * noun -> VagueLook;
>
> [ VagueLookSub ;
> print "Do you want to LOOK AT ", (the)noun;
> if (noun has supporter) print " or LOOK ON ", (the)noun;
> if (noun has container) print " or LOOK IN ", (the)noun;
> "?";
> ];
>
> preposition. I can't speak for TADS, but the Inform library lacks tools
> to let the author constructively interfere with the parser in this sort
> of situation.
You're talking about bending over backwards to disambiguate something
that is not ambiguous.
In my opinion, this would anger newbies like nothing else. "This
pedantic game would rather correct my grammar than let me do what it
KNOWS I want to do?"
Certain posters around here correct people's grammar instead of
addressing the substance of their messages. This behavior would not be
appreciated in parsers either. This is not really a fair comparison,
but I'm saying it so people will get a sense of the full magnitude of
how annoying this suggested change might be to some people.
For newbies who don't know "X THING," I'm sure "LOOK THING" seems an
obvious and welcome abbreviation, especially if they're examining
things a lot. And why shouldn't it be accepted? "LOOK THING" is
certainly no further from natural language than "X THING," which is an
artificial syntax if ever there was one. If a syntax is common and
unambiguous and easy to accept, it should always be accepted.
"LOOK THING" may seem primitive, but it is foolish to reject it on that
account. In fact, "primitive" input is to be expected. Our parsers are
a lot less intelligent than any human being, and we should expect
people to treat them that way.
As far as the objection that requiring "LOOK AT THING" might be
necessary to get players to understand the "PUT THING IN BAG" syntax...
I don't know, I think Inform and TADS do a fair amount of asking for
indirect objects, enough to clue people in to things like that. I could
be wrong.
Greg
Mike Roberts
> What matters are the inputs one would expect to work, such
> as sensible natural language commands in a given context.
and "Aaron A. Reed" <aar...@gmail.com> wrote:
> I think there's an important distinction here. A properly-clued use
> of a verb that might not otherwise have been tried [...] is not really
> a guess-the-verb puzzle, unless the author has picked an unusual
> verb, because the game is practically telling you to try it. This is fine.
It's the combination of these two factors that presents the problem for the
newbie (and, more generally, for people who just don't like the IF model).
IF by its very nature constantly provides clues about sensible things you
ought to be able to do. A small number of those clues are intentional - the
author wants you to try some unusual command and drops hints to lead you
there. The rest are false clues that weren't intended as clues by the
author but are inferred - invented, really - by the player, based on any
number of factors: apparent weight given to something in the text,
real-world knowledge of analogous objects or situations, connections or
similarities among objects in the game, etc. Those false clues lead the
player to try something that *ought* to work but doesn't - and it's not just
a matter of the parser understanding the command, it's a matter of a logical
or realistic action having some kind of logical or realistic result, not
just a pat refusal.
And this is where the combination I'm talking about comes in: if you as the
player expect the game to have concealed-verb puzzles *at all* - even if you
expect them to be well-clued and well-designed when they occur - then you
can't help but think that concealed verb puzzles are *everywhere*. Every
time you encounter something that seems like a clue, or something that seems
like it ought to be doable in the real world, you're going to have to try
it, because your expectation is that sooner or later one of those things
will work.
It's this matter of expectations that's led me to think concealed verbs are
basically problematic across the board, no matter how perfect they may seem
for a particular situation.
The problem is particularly acute for newbies. We've developed enough of a
set of conventions over the years that experienced IF players know the basic
model and the basic set of model-level commands, so they don't waste their
time on things like STAND NEXT TO BOB or LEAVE KITCHEN; and experienced
players have a sense for what constitutes a true clue in the conventions
that have evolved. The newbie doesn't have the benefit of knowing the
peculiar conventions. The newbie also experiences a rather perverse
learning curve: the typical game basically trains you *not* to try
exceptional commands, because they hardly ever work - if you can stand to
keep playing past the first twenty moves, you eventually internalize the
idea that your options are limited to GO NORTH S E W LOOK EXAMINE INVENTORY
GET DROP PUT IN ON WAIT SIT LIE STAND. But just as soon as you do, you find
that you've been stuck for fifty turns because you didn't think you could
REPAIR RADIO just by saying so.
"Stephen Bond" again:
> But again, I suspect that if _Photopia_ had been accompanied by
> an LA-style menu with N possible verbs, my enjoyment of the
> game would have been considerably diminished. Alley says "Let's
> tell a story together" and not "Let's tell a story together, except
> you're only allowed to say >PULL and >PUSH and >PICK UP".
Maybe I'm creating some confusion by talking about the badness of concealed
verbs; I keep seeing these injured expressions like I'm trying to take
people's parsers away from them. So let me be clear: I don't want to take
anyone's parse away. I don't propose that the alternative is a menu
interface, or that we all ought to abandon command lines, or that Inform and
TADS and Hugo ought to be deleted from the Archive until they can be
reformulated around my principles of UI transparency, or that Federal
Aviation Regulations ought to require a VERBS command in every game, or that
people who write Scott Adams two-word parsers ought to snap out of it
already, or that we all ought to do any one thing in any case. I'm more in
idea-questing mode than anything; if I had the solution to these problems I
speak of I'd just go implement it; I'm just pointing out the problems in the
hope that someone cleverer than myself can tell me the solution.
Daryl McCullough
>And this is where the combination I'm talking about comes in: if you as the
>player expect the game to have concealed-verb puzzles *at all* - even if you
>expect them to be well-clued and well-designed when they occur - then you
>can't help but think that concealed verb puzzles are *everywhere*. Every
>time you encounter something that seems like a clue, or something that seems
>like it ought to be doable in the real world, you're going to have to try
>it, because your expectation is that sooner or later one of those things
>will work.
Excellent point, and something I hadn't thought about. I've been thinking
along the lines of *successful* actions: if there is some action that is
appropriate at some point, the author can take measures to make sure that
the player is clued in about how to perform the action (what verb to use,
etc.) But if an action is *not* appropriate, how can the author clue the
player about that? In the predictable cases (trying to burn something,
trying to climb something, trying to break something) the author can
anticipate what the player might attempt and give an appropriately
negative response message ("Starting a fire in here would be too
dangerous.") But if the player tries an unusual verb (for example,
if he tries "incinerate" instead of "burn") then he doesn't know
whether it fails to work because it is inappropriate, or because
the author just left out that particular synonym. So the player
might (incorrectly) be led to *think* that he is in a "guess-the-verb"
puzzle when he actually *isn't*.
I'm not sure how to remedy this situation. Limiting the verbs
to some standard set (take, drop, etc.) seems too drastic, but
it's hard to see what, short of that, will do the trick. Of course,
it can be alleviated by lots of beta testing---keep track of everything
that players try, and make sure you have a good response to each of
them. But it doesn't resolve the problem with expectations: if in
vast majority of cases, nonstandard verbs do nothing, then the player
will quit trying them. How do you clue in the user that something
nonstandard is appropriate in one situation but not in another?
(A hints system helps a little...)
Andrew Plotkin
>
> For newbies who don't know "X THING," I'm sure "LOOK THING" seems an
> obvious and welcome abbreviation, especially if they're examining
> things a lot.
Why do you believe this?
It occurs a few times in the 72 transcripts that we started with. But
not many.
I would imagine that it would only be obvious to people who have
already be inculcated with the assumption that the game understands a
string "VERB NOUN" language.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a
warrant, it's for one reason: they don't feel like it. Not because of
the Fourth Amendment.
Jackdaw
"Daryl McCullough" <stevend...@yahoo.com> wrote in message
news:drtta...@drn.newsguy.com...
> Mike Roberts says...
> I'm not sure how to remedy this situation. Limiting the verbs
> to some standard set (take, drop, etc.) seems too drastic, but
> it's hard to see what, short of that, will do the trick. Of course,
> it can be alleviated by lots of beta testing---keep track of everything
> that players try, and make sure you have a good response to each of
> them. But it doesn't resolve the problem with expectations: if in
> vast majority of cases, nonstandard verbs do nothing, then the player
> will quit trying them. How do you clue in the user that something
> nonstandard is appropriate in one situation but not in another?
> (A hints system helps a little...)
Musings on structure / verbs an' stuff...............
If a strange verb/noun combination was mentioned in the beginning of the
game i,e, "The Wizards casts a spell" ( simple I know ) it might clue in the
player later in the game to "cast spell whatever" or "you see a foger
smotking a whibble", then that structure could be assimilated by the player
to be of use further on.
Apropos bugger all............... I am including in the "Verbs to Go" /
help system in my game a, "terse" and "verbose" for room location
descriptions. The idea being that on the first visit to the location, you
get the full description, should you return, you get the shorter ( terse )
description, unless the player enters "V" for the full fruity original
description.
Yes.. No?
Jackdaw collector of junk, trivia and bright twinkly things.
ems...@mindspring.com
Mike Roberts wrote:
> IF by its very nature constantly provides clues about sensible things you
> ought to be able to do. A small number of those clues are intentional - the
> author wants you to try some unusual command and drops hints to lead you
> there. The rest are false clues that weren't intended as clues by the
> author but are inferred - invented, really - by the player, based on any
> number of factors: apparent weight given to something in the text,
> real-world knowledge of analogous objects or situations, connections or
> similarities among objects in the game, etc. Those false clues lead the
> player to try something that *ought* to work but doesn't - and it's not just
> a matter of the parser understanding the command, it's a matter of a logical
> or realistic action having some kind of logical or realistic result, not
> just a pat refusal.
I've come to think that one of the jobs of a work of IF is to teach its
player -- constantly, in every kind of feedback -- what sorts of
interactions are appropriate to the game. The listed/unlisted command
issue is only part of this larger problem, as you suggest (though I'm
coming at it from a different angle). A few months ago I wrote up a
sort of manifesto about how the parser, world model, and output should
work together to achieve this. This was mainly intended to clarify my
own thinking for various projects.
But it's become relevant, so I'm posting it here; with the warning that
it is (a) long and (b) emphatically phrased, with lots of shoulds and
should-nots, thanks to the fact that it originated as a sort of
in-house mission statement. Feel free to sprinkle it liberally with "in
my opinion" if that makes it a more palatable read.
A few people on ifMUD were kind enough to look at it at the time and
offer some feedback, but the opinions shouldn't be blamed on anyone but
me.
In case it is of use, then:
=====
World model
1. The purpose of the world model is to allow the player with a range
of action greater than the author of the IF could have anticipated
specifically. This distinguishes IF from a Choose Your Own Adventure.
2. There is no point to elements of the world model that do not
contribute to the range of interaction important in the game. A game
about treason and loyalty, where the interaction mostly involves
personal relationships, probably does not need a detailed
implementation of realistic water.
2A. The type of interaction should be as much as possible appropriate
to the type of story. It is difficult to have a story about people
where the interaction is principally about moving things from one place
to another. Sometimes it can be done, but it's challenging.
2B. The "world model" is a broad term as applied here. A world model
may model things besides space and physical objects, such as character
moods and topics of conversation; time; sequence of events (what has or
has not happened so far); or anything else the author wants the player
to be able to affect.
2C. It is understood that a world model based on a library will have
some few base features that will likely not be excised even when they
are not being used. For this reason a basic library should remain
compact, and extra aspects of the world model be added by extension
through the deliberate choice of the author. Having extraneous features
in a model world that do not lead to any productive interaction for the
player may be counterproductive, because it distracts from the
interaction type intended in this particular game.
3. There is no point to a model that cannot usefully be described in
text. A model that incorporates exact physical location to the inch is
appropriate to a graphical representation, not to a text
representation.
3A. Aspects of the world that cannot be *mechanically* translated from
the model representation into text need not be modeled in any
complexity. They will need handwritten text anyway.
3B. Effects of action can be quantitative (changing the value of
something along a gradual scale) or qualitative (switching between
several discrete states). Qualitative effects are as a rule easier to
describe in text. Describing a quantitative effect often, though not
always, involves throwing away some information when describing an
outcome to a player. (After buying something, the player might know
exactly how much money he has left: this is a quantitative effect
described exactly. On the other hand, after hitting someone, the player
might know only that he has caused his opponent to "look weaker". The
problem here is that divulging the opponent's exact number of hit
points goes counter to the realism of the description -- since in real
life people do not have hit points -- but concealing this information
leaves the player at a disadvantage in terms of gameplay. We are more
or less arbitrarily concealing from him information that he might want
to use to interact intelligently with our model world. It's possible
that the point of the game is to require the player to gamble and make
educated guesses about outcomes, but this is challenging to make work
well; the player will likely UNDO after a failure, but depriving
players of the UNDO command may irritate them so much that they won't
play.)
3C. Modeled states of objects should always in some way affect the
output at some point in the game (though it may be indirectly). If a
state of an object in no way affects what the player sees at any time,
that state information is irrelevant and might as well be excised from
the world model.
4. There is no point to a model that cannot usefully be manipulated via
text commands. Models involving speed of action, or type of motion, are
usually more appropriate to arcade-style games. Models involving high
degrees of abstraction are challenging as well.
4A. It is valid for the model to track effects that the player does
not directly control (e.g., moods of characters, even though the player
cannot directly act on those moods, only do things that cause changes
to them). On the other hand, the less direct the player's control over
the important aspects of the model, the less his sense of agency and
the greater the risk of confusion.
4B. If the player is indirectly causing a quantitative effect -- e.g.,
slowly changing the attitude of another character along multiple axes
-- representation becomes particularly challenging and it is easy for
the player to become confused about the effects of his action.
4C. It should in general be obvious to the player *that* he has
manipulated the model when he succeeds in causing a change. If his
actions have indirect effects, there should usually be some hint that
an indirect effect has occurred: e.g., the changing expression on an
NPC's face, a sound from a distant room, etc.
Parser
1. The purpose of the parser is to allow the player to manipulate the
model world. It is not the author's job to provide the player with a
parsing that will accept anything the player wants to type. It would
not in fact be helpful to do so unless the author has also constructed
a model world capable of sustaining any type of action the player
chooses to describe in natural language. It *is* the author's job to
try to lead the player towards phrasings that are useful -- that is,
that indicate meaningful manipulation of the model world.
1A. Teaching the player what sorts of commands are appropriate is
effectively one and the same with teaching the player what the world
model can do.
1B. Where the standard command set, or the world model, diverge from
IF convention, the author should be extra careful to provide hints and
suggestions. New commands should be implemented with an extensive
supply of synonyms and alternate phrasings. The thesaurus and good
beta-testers may help.
1C. Unless the new commands represent actions which are to be hidden
from the player until partway through the game, explicit instructions
should be included in the game, and the player encouraged to read these
instructions on starting play.
2. The structure of a command should require that the player provide
all the information necessary to specify an action fully given the
terms of the model world.
2A. The same action might be implemented with different degrees of
complexity in different world models. One game might allow cutting with
only one implement, while another might have different cutting
implements offering different effects, for instance. The command set of
a standard library will often need adjustment for a given
implementation.
2B. It should never be the case that, e.g., CUT FOO is accepted by the
parser (but fails to do anything interesting), while CUT FOO WITH BAR
does something useful. If the player can be seen to be attempting a
valid command, but is inadequately specific about it in the present
context, he should receive guidance about the correct form.
2C. The basic implementation of a command should always be one that
incorporates all the information needed. Thus if it matters what weapon
the player is using to ATTACK someone, the basic form of the command
should be ATTACK FOO WITH BAR. It is valid to attempt to understand
ATTACK FOO rationally, but the command should always resolve back to
the complex form.
3. The structure of a command should not require that the player
provide any information that can reasonably be determined by default
from the world model. If the player is only carrying one key, e.g., it
should be understood that this is the key he wishes to try using.
3A. This does not invalidate the points in 2 above. The correct thing
is to implement the most complex form of command, then provide
intelligent defaulting.
3B. When a default is selected, the player should always be told
what the default selection was. This will help train him in the correct
command structure, and prevent confusion based on incorrect
assumptions.
4. The parser should always prompt for information missing from a
command, if the player offers incomplete information and a reasonable
default cannot be deduced.
4A. If a small list of reasonable default possibilities can be
assembled, and the knowledge of these items is not itself a puzzle, the
list may be presented to the player as a selection of options. (FIX FOO
WITH THE HAMMER OR THE WRENCH?) This is not something that most systems
currently do, to the best of my knowledge. Maybe T3 lets you set a
disambiguation list, but I wouldn't be too sure.
4B. If the list of reasonable default possibilities is large, it is
reasonable merely to ask the player for more information.
4C. If the requested information is a value rather than a thing, the
usable values should also be listed when disambiguation is requested.
("You may open your snuffbox insouciantly, or in a sneaky manner.");
or, if it is not reasonable to list the values (e.g., we are expecting
the numeric code for a safe), one should at least indicate what sort of
value is expected.
5. If the parser needs to distinguish between multiple items when the
player has named one but named it ambiguously, the disambiguation
("Which do you mean, ...") should be designed to make the difference
between the items on the list obvious.
5A. Ideally, it should indicate to the player which
properties/aspects/adjectives/etc. would distinguish between the two
(or more) objects proposed. Thus "Which tea do you mean, the tea in the
pot or the tea in the cup?"; or "Which baseball do you mean, the dirty
baseball or the clean baseball?" -- even if the baseballs are not
ordinarily listed in those terms.
Output
1. The purpose of what gets printed to the screen is to reveal to the
player everything he needs to know to interact with the world in the
way intended. The output should draw the player's attention to the
important parts of the world model.
1A. This does not mean that there can be no aesthetic purpose to what
is printed. Nonetheless, the text will be ineffective as prose for
interactive fiction if it does not fulfill this requirement.
2. Different aspects of the model world may be important at different
times in the work.
3. At output time, therefore, information about the world model may be
emphasized (presented on its own paragraph, made the first or last item
in a list, bold-faced, etc.); of ordinary significance (listing as part
of "you can see here", properties of openness/containment/light/etc.
which happen to be critical to the world model); or secret, ignored, or
unlisted (scenery, concealed items; properties of secondary importance;
or those properties which the player might reasonably deduce from the
object's name [e.g., it is likely unnecessary to indicate in inventory
listings et al. that an object called "fork" has the property of being
metal]).
3A. The information displayed should not overwhelm the player. If
there is a great deal of information presented in emphatic form, the
emphasis becomes useless.
3B. In general, hand-crafted prose suggests greater focus or emphasis
than mechanically-generated prose.
4. It should be possible for the player to recover any world model
information which he has been told once, even if it is not currently
considered important enough to be listed under ordinary circumstances.
Thus, if he has discovered some property of an item (e.g., that the
teapot is enchanted), he should be able to tell this thereafter in some
way (by examining it, inspecting it through the enchantment-detecting
lens, etc.), even if we do not from then on call it "the enchanted
teapot" on every occasion.
4A. Barring special tools/circumstances (e.g., the game features a
microscope/geiger counter/etc.), examining an object should give the
player all the useful information it is currently possible for him to
detect. There should not be important world-model information about an
object which gets mentioned in the general room description but not
when one looks at the object directly. Or, to put the rule in a more
general form: if the player attempts to recover information about an
aspect of the world model using a command devised for that purpose, he
should be given a complete view of everything he is currently allowed
to know.
4B. IF modeling conversation, plot events, time, etc., should provide
some command by which the player can review what has been said or what
has occurred. Said summary need not be exhaustive but should convey
everything critically affecting the current world state.
5. The status bar is useful for presenting information that is simple
(e.g., the room we are in, but not the list of things we are carrying);
important (likely to have an effect on most or all actions the player
performs); rapidly-changing (unlikely to remain the same throughout the
game, or even from turn to turn); and/or from an isolated part of the
world model.
5A. By isolated, we mean things such as systems of conversation, time,
emotion, etc., which are modeled but only weakly coupled with the rest
of the world model. Because these systems may be important but have
few, sporadic, or subtle effects on the way the model world works, the
text output may otherwise not remind the player very often of the
time/conversation state/etc. Having this information in the status bar
tells him that it is nonetheless important information and allows him
to review it.
steve....@gmail.com
In its present location, it seems buried, and really it shouldn't be.
Samwyse
> Samwyse wrote:
>>[ VagueLookSub ;
>> print "Do you want to LOOK AT ", (the)noun;
>> if (noun has supporter) print " or LOOK ON ", (the)noun;
>> if (noun has container) print " or LOOK IN ", (the)noun;
>> "?";
>>];
>>
>>The only problem is that the player might reply with just the
>>preposition. I can't speak for TADS, but the Inform library lacks tools
>>to let the author constructively interfere with the parser in this sort
>>of situation.
>
> You're talking about bending over backwards to disambiguate something
> that is not ambiguous.
How is it not ambiguous? If I say LOOK BAG or LOOK TABLE, how do you
know what I mean? You likely have an excellent idea of what you'd mean
in that situation, but you're not me. Here's an example of someone
who's glanced over the instructions without reading them carefully:
> X BAG
It's a silk purse sewn from a pig's ear.
> LOOK BAG
At this point, what do they mean, and how certain are you?
Kevin Forchione
news:drtv5s$de0$1...@reader2.panix.com...
> Here, Greg Boettcher <WRITET...@gregboettcher.com> wrote:
>>
>> For newbies who don't know "X THING," I'm sure "LOOK THING" seems an
>> obvious and welcome abbreviation, especially if they're examining
>> things a lot.
>
> Why do you believe this?
>
> It occurs a few times in the 72 transcripts that we started with. But
> not many.
>
> I would imagine that it would only be obvious to people who have
> already be inculcated with the assumption that the game understands a
> string "VERB NOUN" language.
Then it seems the straightforward thing is not to change the behavior of the
parser ... trying to have it determine an ambiguity which exists only as an
encoding of the grammar and which only exists within the mind of the player
(<<Look Door>> must translate into some action within the grammar currently
or the parser would complain)... but rather to inculcate the newbie into the
standards and conventions of interactive fiction.
Now perhaps one way of doing this would be to present certain text at the
first occurrence of this sort of ambiguity, something similar to the text
displayed when a footnote is first encountered. Simply instruct the player
that the use of this kind of construct (i.e. a missing preposition) is
understood by the game by such and such a default construction (<<Look
Object>> --> <<Look at Object>> or whatnot). The message is displayed once,
the player is alerted to the convention, and from that point on the
convention is assumed to be understood.
Perhaps another approach would be the implementation of a "help" command,
which would indicate what the fuller translation of the command would be.
Something like the following:
>HELP "LOOK DOOR"
The player character understands this command as "LOOK AT BEDROOM-DOOR".
What this would require would be first to inculcate the player in the use of
the facility. It's no good if they don't know it's there, and second, to
have the HELP command (or whatever) throw out its argument to the game
parser, capture the command associated with it (and perhaps even down to the
object involved), and return meta-game information to the player much as a
debugging verb would.
This would be the equivalent of having a chess program supply a hint or show
all the legal moves for a piece. We're not asking the parser to engage in a
dialogue with the player over a case where the parser would clearly make *a*
decision, we're supplying the player with a means for feedback on what that
decision would be, without having the command executed.
--Kevin
Kevin Forchione
In this case the player may or may not be certain of what the *parser* means
by LOOK BAG. No one but the player can know for sure, based on the above
transcript. There's no ambiguity on the part of the parser though. It knows
what that command means, and how to translate it into a game action.
It would be presumptuous, perhaps pretentious, for the game to assume that
simply because a command is repeated or repeated in a different syntax, even
a possibly ambiguous one, that the player is attempting to achieve an
alternate response from the game. An argument can be made for that case, of
course, but it is not so clear if we reverse the order of those commands
<<LOOK BAG>> followed by <<X BAG>> and most of us would say that the player
is merely abbreviating his command. Perhaps the repetition is caused by the
player wishing to see text that has scrolled off the display.
However... here the <<HELP>> facility I mention in another post would be
helpful. A newbie typing <<HELP>> or somesuch command would be informed that
they could "analyze" the results of a command by simply typing <<HELP LOOK
BAG>>. The game would provide a description of the action and objects that
would be involved. From that point forward the newbie would understand the
convention that the game uses when <<LOOK OBJECT>> is entered on the command
line, and if this is not the desired interpretation, then the newbie can
enter another command <<LOOK IN BAG>>.
I don't believe this mechanism would spoil any puzzles - it's not going to
give the player any further information beyond that specific command (as
opposed to the UNDER, AT, IN, ON, BEHIND options approach which could clue
the player in to things not noticed.)
This form of HELP command could be phrased as <<HELP VERB LOOK BAG>> which
would provide only information about the verb in the command; <<HELP OBJ
LOOK BAG>> which would disclose the objects involved (and which an author
could possibly restrict if it would spoil puzzles); and <<HELP CMD LOOK
BAG>> which would give disclosure of the interpretation of both verb and
object.
It's one possible approach to the newbie inculcation problem. Experienced
players would not be impacted by it, as they would in a "choices" approach.
--Kevin
Michel Nizette
> 2C. It is understood that a world model based on a library will have
> some few base features that will likely not be excised even when they
> are not being used. For this reason a basic library should remain
> compact, and extra aspects of the world model be added by extension
> through the deliberate choice of the author.
Out of curiosity, do you regard the basic libraries of the major systems as
satisfactory in this respect, or not? They usually implement all sorts of
legacy verbs such as "kiss," "jump," or "sing," which are actually only
pertinent to a limited number of games. In your opinion, should those verbs
ideally be trimmed off of the basic libraries? Or would it be worthwile for
those libraries to reduce their handling to explicit messages about the
limits of the world model, such as "jumping is not necessary in this game"?
> 1A. Teaching the player what sorts of commands are appropriate is
> effectively one and the same with teaching the player what the world
> model can do.
That's an interesting point of view, and one that suggests that if we could
somehow make it perfectly clear to players what can be done in the world
model and what cannot, they might much less often be tempted to type
unrecognized commands. So, the parser problems this thread has been mostly
revolving around might actually be secondary to the problem of instructing
newbies about the limits of the simulation, independently of the interface
used to communicate with the game world.
> 1. [...] It would not in fact be helpful to [provide the player with a
> parsing that will accept anything the player wants to type]
> unless the author has also constructed
> a model world capable of sustaining any type of action the player
> chooses to describe in natural language.
This makes sense in the light of your point 1A; however, quoting Mike
Roberts
from
http://groups.google.be/group/rec.arts.int-fiction/browse_frm/thread/61da68b00ac94919/5d4583a57cbad438:
>The range of action can be more limited than the parser's comprehension,
>though - just because the parser understands a command doesn't mean that
>the
>game has to carry it out. Given a command-line interface, I'd much rather
>have the parser understand what I mean, and tell me that my intended action
>isn't allowed, than to have the parser get confused about syntax or
>vocabulary. When the parser doesn't understand your input, you're left
>wondering whether the problem is the idea or the phrasing. Eliminating
>that
>would be entirely positive, I think.
--Michel.
Eric Eve
news:1138923448.2...@g47g2000cwa.googlegroups.com...
> 2C. The basic implementation of a command should always be one
> that
> incorporates all the information needed. Thus if it matters what
> weapon
> the player is using to ATTACK someone, the basic form of the
> command
> should be ATTACK FOO WITH BAR. It is valid to attempt to
> understand
> ATTACK FOO rationally, but the command should always resolve back
> to
> the complex form.
I don't know about other people, but I generally take ATTACK FOO to
mean ATTACK FOO WITH MY BARE HANDS (since it's usually a synonym for
HIT FOO, and that's the most obvious meaning of HIT FOO without a
WITH WHATSIT modifier) reserving ATTACK FOO WITH BAR for the case of
explicitly wielding a weapon. Since most games don't explicitly
implement a BARE HANDS object, this seems to be a reasonab;y
convenient convention. If what you had in mind was:
>ATTACK FOO
(with your bare hands)
You deliver a knock-out blow to Foo's chin.
That might be positively misleading, since the "(with your bare
hands)" might lead players into supposing that a hands object was
implemented (when to implement the PC's hands could otherwise prove
more trouble than it's worth).
> 4A. If a small list of reasonable default possibilities can be
> assembled, and the knowledge of these items is not itself a
> puzzle, the
> list may be presented to the player as a selection of options.
> (FIX FOO
> WITH THE HAMMER OR THE WRENCH?) This is not something that most
> systems
> currently do, to the best of my knowledge. Maybe T3 lets you set a
> disambiguation list, but I wouldn't be too sure.
I think this should be possible in principle in TADS 3, though I
couldn't say off the top of my head exactly how you'd implement it,
so I can't be sure how practicable or straightforward it would be.
There's already an existing TADS 3 library class (AskConnector) that
uses this technique to disambiguate travel commands in directions
where there's more than one possible exit (e.g. two doors in the
north wall), e.g.:
>NORTH
Which door do you want to use, the red door or the blue door?
>BLUE
Blue Bedroom
...
And it looks to me as if the mechanism it uses should be adaptable
to other cases. My guess is that it's doable where there's a static
disambiguation list that's knowable in advance (as with
AskConnector), but might become much trickier for the average game
author if s/he has to construct the list dynamically from the game
state (although I suspect the T3 library probably helps out here by
discarding from a static disambiguation list any objects that aren't
currently in scope).
-- Eric
Michel Nizette
> I don't know about other people, but I generally take ATTACK FOO to mean
> ATTACK FOO WITH MY BARE HANDS [...],
> reserving ATTACK FOO WITH BAR for the case of explicitly wielding a
> weapon.
I agree this might be a rather well established convention, but isn't it
precisely the kind of thing that newbies could find particularly confusing,
though? Especially if they come from a different gaming background, such
for example as a RTS game like Warcraft III: there it isn't uncommon that
the simple acquisition of a new artefact by a player character automatically
increases his ability in combat, without necessity for the player to tell
the game explicitly to use the artefact. Newbies coming from such a
background could be at loss to understand why your IF game didn't
automatically choose the most powerful weapon in their possession for the
attack.
My impression is that implementing a "fists" object in this case might
actually be the most newbie-friendly solution, whatever difficulties it
creates in other respects.
--Michel.
Eric Eve
"Michel Nizette" <Mic...@Nizette.name> wrote in message
> Eric Eve wrote:
> I agree this might be a rather well established convention, but
> isn't it precisely the kind of thing that newbies could find
> particularly confusing, though? Especially if they come from a
> different gaming background, such for example as a RTS game like
> Warcraft III: there it isn't uncommon that the simple acquisition
> of a new artefact by a player character automatically increases
> his ability in combat, without necessity for the player to tell
> the game explicitly to use the artefact. Newbies coming from such
> a background could be at loss to understand why your IF game
> didn't automatically choose the most powerful weapon in their
> possession for the attack.
>
> My impression is that implementing a "fists" object in this case
> might actually be the most newbie-friendly solution, whatever
> difficulties it creates in other respects.
But do you actually need to create a "fists" object to let the
newbie know what's happening here?
Consider the following two cases:
1)
>ATTACK FOO
(with your bare hands)
You punch the foo in the face; it bursts into tears and runs away.
2)
>ATTACK FOO
You punch the foo in the face; it bursts into tears and runs away.
So far as I can see, both transcripts convey the same information
(that ATTACK FOO has been taken to mean ATTACK FOO (with your bare
hands)), but Case 1 implies that it might in future be desirable
explicitly to command ATTACK FOO WITH BARE HANDS (requiring the
implementation of a BARE HANDS object), while Case 2 does not.
Whether this is better than automatically selecting the best weapon
in scope surely depends on the context and the nature of the game.
In some games, helping the player out this way might make it *too*
easy (effectively solving a puzzle the player was meant to figure
out for him/herself). In some others, where combat doesn't feature
much (if at all) in the game, you haven't really created the
impression that it should behave in an RTS-like manner.
I think the potential downside of explicitly implementing ATTACK FOO
WITH HANDS is too large for it to be worth it, since this phrasing
will then encourage newbies to try:
>TAKE BAR WITH HANDS
>PUT FOO ON BAR WITH RIGHT HAND
>WIPE NOSE WITH LEFT HAND
And all sorts of other pointless things you don't want to lead
newbies into, and don't want to have to provide responses for in the
interests of newbie-friendliness. Unless a game really needs to
start implementing the PC's body parts, it's much better not to,
IMHO, so that newbies can be trained not to expect them to be
implemented.
-- Eric
Michel Nizette
> I think the potential downside of explicitly implementing ATTACK FOO WITH
> HANDS is too large for it to be worth it, since this phrasing will then
> encourage newbies to try:
>
>>TAKE BAR WITH HANDS
>>PUT FOO ON BAR WITH RIGHT HAND
>>WIPE NOSE WITH LEFT HAND
>
> And all sorts of other pointless things you don't want to lead newbies
> into, and don't want to have to provide responses for in the interests of
> newbie-friendliness. Unless a game really needs to start implementing the
> PC's body parts, it's much better not to, IMHO, so that newbies can be
> trained not to expect them to be implemented.
Fair enough. I'm still worried, though, that something like this:
>ATTACK TROLL
You punch the troll in the stomach with all your might. Mildly annoyed, he
flicks your forehead, sending you inconscious on the floor.
might leave newbies utterly confused as to how to get the game to understand
that they want to use the all-powerful vorpal blade they have just acquired,
especially if they haven't been properly introduced to the use of indirect
objects yet. The response to the direct-object-only form of "ATTACK" just
looks like the right place to inform newbies about this, although I'm not
sure how in the light of your comments.
--Michel.
Stephen Bond
> And this is where the combination I'm talking about comes in: if you as the
> player expect the game to have concealed-verb puzzles *at all* - even if you
> expect them to be well-clued and well-designed when they occur - then you
> can't help but think that concealed verb puzzles are *everywhere*. Every
> time you encounter something that seems like a clue, or something that seems
> like it ought to be doable in the real world, you're going to have to try
> it, because your expectation is that sooner or later one of those things
> will work.
In the perfect game, everything you think of trying will work. Until
we have the perfect parser and perfect world simulation, this
means that a great deal rests on the game design. This is the
part where game authors get to show off their skills. The
best-designed games lead me to think in such a way that almost
everything I try works. They also lead me not to think of trying
things that won't work.
(By the way, I agree with Zarf that "concealed-verb" isn't the right
wording. Also, leaving the verb set open-ended isn't just about
puzzles, or even primarily about them.)
> It's this matter of expectations that's led me to think concealed verbs are
> basically problematic across the board, no matter how perfect they may seem
> for a particular situation.
Just because it's difficult to handle, and most authors design poor
games, doesn't mean the model is flawed "across the board".
> The newbie also experiences a rather perverse
> learning curve: the typical game basically trains you *not* to try
> exceptional commands, because they hardly ever work - if you can stand to
> keep playing past the first twenty moves, you eventually internalize the
> idea that your options are limited to GO NORTH S E W LOOK EXAMINE INVENTORY
> GET DROP PUT IN ON WAIT SIT LIE STAND. But just as soon as you do, you find
> that you've been stuck for fifty turns because you didn't think you could
> REPAIR RADIO just by saying so.
Then this "typical game" is a hypothetical example of typically poor
game design. (At least, if the games is aimed at newbies.)
> "Stephen Bond" again:
> > But again, I suspect that if _Photopia_ had been accompanied by
> > an LA-style menu with N possible verbs, my enjoyment of the
> > game would have been considerably diminished. Alley says "Let's
> > tell a story together" and not "Let's tell a story together, except
> > you're only allowed to say >PULL and >PUSH and >PICK UP".
>
> Maybe I'm creating some confusion by talking about the badness of concealed
> verbs; I keep seeing these injured expressions like I'm trying to take
> people's parsers away from them.
No injured expression here -- I was just directly responding to your
question about whether "concealed verbs" were necessary for the
enjoyment of _Photopia_.
I suppose I could throw out a similar question -- can something
with a limited, fully disclosed command set still work as IF? In other
words, can you show me a game that has a fully-disclosed set of
available actions and also a rich and convincing game world?
Stephen.
Eric Eve
"Michel Nizette" <Mic...@Nizette.name> wrote in message
> Fair enough. I'm still worried, though, that something like this:
>
>>ATTACK TROLL
> You punch the troll in the stomach with all your might. Mildly
> annoyed, he flicks your forehead, sending you inconscious on the
> floor.
>
> might leave newbies utterly confused as to how to get the game to
> understand that they want to use the all-powerful vorpal blade
> they have just acquired, especially if they haven't been properly
> introduced to the use of indirect objects yet. The response to
> the direct-object-only form of "ATTACK" just looks like the right
> place to inform newbies about this, although I'm not sure how in
> the light of your comments.
Well, probably the game shouldn't confront the newbie with the troll
until it's taught the newbie how to cope with indirect objects in
less threatening situations, but if this structure was really
necessary, then (in TADS 3 terms), your actionDobjAttack() method
could first check whether the PC was carrying any weapons, and if so
use askForIobj(), which might then pick the vorpal blade if you give
it the highest logicalRank in its verifyIobjAttackWith() routine,
but default to attacking the troll with bare hands (without a "(with
bare hands)" announcement) if no weapons are being carried.
-- Eric
Michel Nizette
> I suppose I could throw out a similar question -- can something
> with a limited, fully disclosed command set still work as IF? In other
> words, can you show me a game that has a fully-disclosed set of
> available actions and also a rich and convincing game world?
I would count nearly every graphical adventure game I've played as such.
Limiting myself to text games, though, I can't think of any example off
hand, but I regard _All Things Devours_ as a close approximation, in that it
is my belief that this game wouldn't have been harmed at all by disclosing
the full set of actions at any point in the game. The challenge, there, is
not to figure out the available range of actions, but to combine a set of
actions that are perfectly obvious to the player from the start into a
successful sequence. In other words, this game doesn't require the player
to think outside the box; instead, it manages to make the box interesting
and complex enough to offer a satisfactory experience all by itself.
That's the way I perceived it, anyway.
--Michel.
Daryl McCullough
>In the perfect game, everything you think of trying will work.
I'm not sure about that. The plot of the game may depend on something
being solved in a particular way, and so solving it in a novel way
might derail the plot. If the game is *pure* simulation (no plot
other than what the player chooses to do) then that's probably okay
(for instance, the Sims). But if the author has a specific story to tell,
then it might be important to that story that certain things happen
in a certain way. To defeat the dragon, you need the magical sword
known as "The Blue Fang". To get the sword, you need to enter the
Vendozian palace. Etc.
Stephen Bond
"Thinking outside the box" has nothing to do with it. With an
open-ended verb set, there is no box.
I notice that those who want to see the full set of actions keep
talking of "challenges" and the effect of concealing verbs on
puzzles and puzzle-solving. But surely even the most
puzzle-heavy IF game is more than just a challenge or a set of
puzzles. Otherwise, why not implement the puzzles as pure
abstractions? Why bother putting them all in some fictional
world?
The more I think about it, the more I see the common element
of all IF as being the *game world* and not the 'game'.
Alternatively, the game *is* the game world, and not the puzzles,
the challenge, or whatever. And the quality of an IF interface is
related to how well it allows this world to be realised. An interface
which gives a limited, exhaustive set of actions makes the world
seem more like a puzzle and less like a world.
(Hmmm. It appears that I think some kind of IF definition will help.
Felixp7, I take it all back.)
Stephen.
Stephen Bond
Daryl McCullough wrote:
> Stephen Bond says...
>
> >In the perfect game, everything you think of trying will work.
>
> I'm not sure about that. The plot of the game may depend on something
> being solved in a particular way, and so solving it in a novel way
> might derail the plot.
True. By "work" I meant (and should have said) "produce an
intelligent response" or something similar.
Stephen.
solar penguin
>
> I don't know about other people, but I generally take ATTACK FOO to
> mean ATTACK FOO WITH MY BARE HANDS (since it's usually a synonym for
> HIT FOO, and that's the most obvious meaning of HIT FOO without a
> WITH WHATSIT modifier) reserving ATTACK FOO WITH BAR for the case of
> explicitly wielding a weapon.
Speaking as a MUD player, I'd take ATTACK FOO as shorthand for ATTACK
FOO WITH THE CURRENTLY WIELDED WEAPON, the last explicitly named weapon
in either a full ATTACK FOO WITH BAR command or a WIELD BAR command.
--
___ _ ___ _
/ __| ___ | | __ _ _ _ | _ \ ___ _ _ __ _ _ _ (_) _ _
\__ \/ _ \| |/ _` || '_| | _// -_)| ' \ / _` || || || || ' \
|___/\___/|_|\__,_||_| |_| \___||_||_|\__, | \_,_||_||_||_|
|___/
http://www.freewebs.com/solar_penguin/
** Now, lean against the robot culture.
** The dominion is a member of the lupin family.
Kevin Forchione
We seem to be addressing 3 different cases:
a) Where the player is attempting to use a synonym that the author has not
implemented, either in the game or in a specific context of the game.
b) Where the author has implemented a verb that is non-standard, and for
which the player has not been clued into using, either as a synonym for
another verb already present in the game model, or uniquely idiomatic to the
author's understanding and style of telling of the story, an understanding
that the player lacks.
c) Where the player's interpretation of the implementation is different from
that of the author/parser (<<LOOK BAG>> means something to the player that
doesn't correspond to the action the parser produces.)
I think that delineates the issues...
--Kevin
Greg Boettcher
> Here, Greg Boettcher <WRITET...@gregboettcher.com> wrote:
> >
> > For newbies who don't know "X THING," I'm sure "LOOK THING" seems an
> > obvious and welcome abbreviation, especially if they're examining
> > things a lot.
>
> Why do you believe this?
>
> It occurs a few times in the 72 transcripts that we started with. But
> not many.
>
> I would imagine that it would only be obvious to people who have
> already be inculcated with the assumption that the game understands a
> string "VERB NOUN" language.
*Most* of the parser-based games I played during the 1980s did accept
"look noun," to the point where I actually got into the habit of using
that syntax whenever possible. That was the case with Sierra games,
which I played a ton of during that period. Opening up Space Quest 1
now, I see that it accepts "look noun" but not "x noun" or "l at noun".
No wonder I got into the habit of typing "look noun"; it's the shortest
syntax.
As far as newbies who have never played any parser-based games, I could
see them typing "look noun" regardless of whether they already know
that the parser can accept prepositions. They may be on the lookout for
a shorter syntax to type, and they may not know about "x noun."
Greg
Mike Snyder
news:1138991663....@g43g2000cwa.googlegroups.com...
> *Most* of the parser-based games I played during the 1980s did accept
> "look noun," to the point where I actually got into the habit of using
> that syntax whenever possible. That was the case with Sierra games,
> which I played a ton of during that period. Opening up Space Quest 1
> now, I see that it accepts "look noun" but not "x noun" or "l at noun".
> No wonder I got into the habit of typing "look noun"; it's the shortest
> syntax.
>
> As far as newbies who have never played any parser-based games, I could
> see them typing "look noun" regardless of whether they already know
> that the parser can accept prepositions. They may be on the lookout for
> a shorter syntax to type, and they may not know about "x noun."
It took me quite a while to get out of the habit of using "look noun". I'm
pretty used to "x noun" now, so it hasn't bothered me as much. At first, I
was reporting it as a bug in the games I played, but usually the authors
would reply back saying "look noun" wasn't valid syntax, so it shouldn't
work anyway. Still, it was a hard habit to break.
The default libraries in some IF languages must support it, though. I
noticed that it works in my Hugo games, and I didn't add grammar for it. I
think it doesn't work by default in TADS-2 games. Not sure about Inform, and
I'm not at a point right now to go check. :)
--- Mike.