Why Newbies don't like IF
fiziwig
IF. His experience illustrates some of the problems that have to be
addresses of IF is ever to appeal to a wider audience. I'll use a
hypothetical situation here for a hypothetical game to demonstrate the
first problem he ran into as a new IF player:
You are standing on the sidewalk on Elm street in front of the massive
doors or the Sprocket And Fudge Commerce Bank. It is dark and the bank
is closed and locked. Other than that you see only a few darkened shop
windows, and the grey marble walls of the bank.
>x door
I don't see any door here.
>x sidewalk
I don't see any sidewalk here.
>x windows
I don't see any windows here.
>x bank
I don't see any bank here.
>x walls
I don't see any walls here.
So his first impression of IF was very negative. It "shows" you a bunch
of stuff and then tells you that none of that stuff is really there. At
the VERY least, any items mentioned in the description should be
examinable. We tend to be forgiving, if not completely blind to
shortcomings like that, because we're so used to it. But should we
tolerate it, really? I don't think so. Maybe the game engine itself
needs to identify nouns in the description text and be prepared to
supply some kind of minimal "that's not important" reply instead of "I
dont' see any...". If a word processor can have a spell checker then an
IF engine can sure by golly have a noun checker. And what if a word is
dual usage, noun or verb, like "brush" "Brush your hair with a brush"?
Why can't the COMPILER issue a warning message to the AUTHOR letting
him know there is a possible unreferenced noun in his description that
needs to be properly addressed.
Another thing that would be very helpful to IF-newbies is some kind of
situation-sensitive help engine. Again, the author shouldn't
necessarily be burdned with inventing this from scratch for each new
game, but the IF engine should be built to notice when a player is
having trouble making any progress and automatically slip in a hint
from a collection of progressively more hlepful hints supplied by the
author. These days, in order to make games more interesting and
challenging to experienced IFers they are often completely out of reach
for IF-newbies who wouldn't stand a chance of solving them. My grandson
has spent days pacing back and forth on Main Street in "The Sugared
Pill", climbing in and back out of the car, opening the trunk, walking
down to the end of the street, driving to nowhere and generally making
not one single bit of progress. He only goes back to it because I ask
him to so I can watch to see what a newbie tries and why he is not
successful. Without someone standing over his shoulder, giving him
hints when it becomes apparent he needs them, he will go away from his
first IF experience not only unimpressed, but very discouraged and
unlikely to ever come back again.
In a situation like that, if the player paces back and forth between
the two locations in his tiny dungeon cell for 15 turns in a row and
doesn't take or examine anything, he obviously needs help. The IF
engine itself should act as that helper looking over his shoulder. It
could invoke hints provided by the game author so that, for example, a
voice from a nearby dungeon cell might strike up a conversation and
hint that he should examine his cot. The idea is that the engine
monitors the players progress, and by some facility built into the
authoring language, players who are not making reasonable progress are
helped along. Thus the new player gets a positive experience and can
actually finish the game, AND learn a little more about how IF works
along the way.
Sure, an author could spend a lot of time incorporating features like
this into a game, but for IF to really become a mature medium then the
IF engines themselves need to provide this functionality.
My own first introduction to IF was Deadline on the Apple II back inte
80's. After spending a totally frustrating couple of hours making
absolutely no progress whatsoever I tossed it out and didn't come back
to IF for 15 years or more. Seasoned IFers just don't seem to have any
conception of how difficult, frustrating, and UN-fun IF can be for
newbies. In order to attract and keep new IF fans that initial
learning-curve frustration factor has to be addressed.
--gary
Stephen Bond
> I'll use a
> hypothetical situation here for a hypothetical game to demonstrate the
> first problem he ran into as a new IF player:
>
> You are standing on the sidewalk on Elm street in front of the massive
>
> >x door
>
> I don't see any door here.
I'd prefer if you used a real example and not a hypothetical one.
Certainly, most of the quality games from recent years have an
implementation for almost all objects mentioned in the text.
Which games are you talking about? It's not impolite to mention
specific games -- RGIF is all about discussing games.
> So his first impression of IF was very negative. It "shows" you a bunch
> of stuff and then tells you that none of that stuff is really there. At
> the VERY least, any items mentioned in the description should be
> examinable. We tend to be forgiving, if not completely blind to
> shortcomings like that, because we're so used to it.
Hmmm... I don't think many people are so forgiving of unimplemented
objects these days. It's something that's likely to get a disapproving
mention in reviews.
But should we
> tolerate it, really? I don't think so. Maybe the game engine itself
> needs to identify nouns in the description text and be prepared to
> supply some kind of minimal "that's not important" reply instead of "I
> dont' see any...". If a word processor can have a spell checker then an
> IF engine can sure by golly have a noun checker.
That's actually a nontrivial natural language parsing problem, which
would require a much more sophisticated parser than the one which
handles user input. (It's also not sufficient for this parser to
recognise nouns -- it has to recognise when these nouns refer to
things that can be examined.) In practice, it's much easier for the
author to handle all examinable objects in the game text. It's a bit
more work, but not that much more work.
And what if a word is
> dual usage, noun or verb, like "brush" "Brush your hair with a brush"?
> Why can't the COMPILER issue a warning message to the AUTHOR letting
> him know there is a possible unreferenced noun in his description that
> needs to be properly addressed.
That would require the compiler to have a natural language parser
as well as its Inform/TADS/whatever parser. Would slow down
compilation significantly, and probably produce a lot of spurious
warnings the user would turn off anyway. Also, it's not really what a
compiler is for.
> Without someone standing over his shoulder, giving him
> hints when it becomes apparent he needs them, he will go away from his
> first IF experience not only unimpressed, but very discouraged and
> unlikely to ever come back again.
I agree this is a problem, and is something that turned me off IF
the first few times I tried it. I think it's more a game design
problem than an IF engine problem, though. One can encounter
the same things in poorly-designed graphical adventure games.
> In a situation like that, if the player paces back and forth between
> the two locations in his tiny dungeon cell for 15 turns in a row and
> doesn't take or examine anything, he obviously needs help. The IF
> engine itself should act as that helper looking over his shoulder.
I think _The Dreamhold_ implemented a dynamic hint system
like this, though since I turned it off, I'm not sure how well it
worked
for newbies in practice.
> Sure, an author could spend a lot of time incorporating features like
> this into a game, but for IF to really become a mature medium then the
> IF engines themselves need to provide this functionality.
Why? Hints aren't required in every game, and non-user-invoked
hints would be undesirable in many games. This, not to mention
the NLP parser, would just add a lot of unnecessary bloat to the
game file.
> My own first introduction to IF was Deadline on the Apple II back inte
> 80's. After spending a totally frustrating couple of hours making
> absolutely no progress whatsoever I tossed it out and didn't come back
> to IF for 15 years or more. Seasoned IFers just don't seem to have any
> conception of how difficult, frustrating, and UN-fun IF can be for
> newbies.
I'm aware of this problem, which is why I've tried not to write any
difficult, frustrating games ("un-fun" is a matter of opinion). I
would say that I still find most IF difficult, frustrating and un-fun,
but then the "90% of everything is crap" rule holds as well in IF
as it does in any other medium.
> In order to attract and keep new IF fans that initial
> learning-curve frustration factor has to be addressed.
There have been attempts to address the learning-curve issue.
It's quite common to see on-line hints in games now
(_Beyond_ from last year's comp is a particularly good
example), and there are apparently easy-to-use hint libraries
available for those who want to include them.
Stephen.
Andrew Plotkin
> At the VERY least, any items mentioned in the description should be
> examinable. We tend to be forgiving, if not completely blind to
> shortcomings like that, because we're so used to it.
Are we? I imagine we're *more* forgiving of lapses than a newcomer,
but the idea that "unimplemented scenery is bad" has been accepted
wisdom for as long as I've been on this newsgroup. When a game is
particularly bad at implementing objects, everyone says so in reviews
and comments. So it's not like we're unaware of the issue.
--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.
Risujin
> But should we
>>tolerate it, really? I don't think so. Maybe the game engine itself
>>needs to identify nouns in the description text and be prepared to
>>supply some kind of minimal "that's not important" reply instead of "I
>>dont' see any...". If a word processor can have a spell checker then an
>>IF engine can sure by golly have a noun checker.
>
> That's actually a nontrivial natural language parsing problem, which
> would require a much more sophisticated parser than the one which
> handles user input. (It's also not sufficient for this parser to
> recognise nouns -- it has to recognise when these nouns refer to
> things that can be examined.) In practice, it's much easier for the
> author to handle all examinable objects in the game text. It's a bit
> more work, but not that much more work.
We could keep a running dictionary of all words used in output, we don't
need to know what they mean. If any unidentified words appear in the
users input that *are* in our output dictionary, we can say something
nice like "you don't need to refer to that".
A more important point actually, is why don't IF interpreters have spell
checkers? All the words that an IF uses are known, how hard can it be to
do a quick spell check and list some suggestions?
-- Risujin
Mike Snyder
news:1136742780....@g14g2000cwa.googlegroups.com...
>I recently introduced my grandson, aged 17 and very computer savy, to
> IF. His experience illustrates some of the problems that have to be
> addresses of IF is ever to appeal to a wider audience. I'll use a
> hypothetical situation here for a hypothetical game to demonstrate the
> first problem he ran into as a new IF player:
(details snipped)
My opinion is that to introduce somebody new to IF, game choice is key. I
can't recommend a good work IF for a beginner, but such lists exist. These
games should avoid the kinds of complaints new players might have --
unimplimented sceneary, high difficulty, etc. It sounds to me like you just
picked the wrong game to start him on.
---- Mike.
fel...@yahoo.com
> I'd prefer if you used a real example and not a hypothetical one.
I have a real example, though not a transcript. Some time ago,
I showed my WIP to a friend who had no prior experience with
text adventures. He never got past the first room. Here's what
happened.
You see, there was this table with a computer terminal on it.
First, he tried to walk up to the table. I explained the basic
IF conventions. Then he tried to *use* the terminal. Guess
what happened. Then he looked at it, and learned he could
talk to the computer (Star Trek style). So he tried to TALK
TO the machine. Another unimplemented verb. I suggested
him to use ASK ABOUT, and he started to ask a lot of
things that were irrelevant enough that I hadn't thought to
cover them. When I pointed this to him, my friend gave up.
By the way, he refused to type HELP, despite the
conspicuous prompt in the standard header, claiming "it
shouldn't be necessary". I only half-agreed, considering it
was his first contact with IF, but he did have a point.
Anyway, this story shows the truth about the "illusionary
freedom" IF suposedly gives the player. It's not even
illusionary. *It doesn't exist*. In this regard, graphical
adventures are more fair: they make it clear what one can
and cannot do whithin the game world. It may not seem
free, but it's at least honest, and people appreciate honesty.
Now, catching unimplemented nouns, or auto-detecting
when the player is stuck, *might* alleviate the problem.
Somewhat. But it doesn't go nowhere near the source.
And the source of the problem is... well... I can't define it
in a few words, but playing IF is not like reading a book,
as much as we like to compare the two. A computer
program is a computer program, and it's not truly intuitive.
Pretending it's something else does not help...
Ah, crap. I don't know how to put it. But the problem is real.
Felix
fiziwig
spell
checkers?>>
I spend about an hour taking a random sample from a good comprehensive
dictionary and computing what should be a pretty reliable stimate of
the number of nouns naming objects that might posisble appear in an IF
adventure. It appears that there are between 8,000 and 10,000 possible
"things" that could be named. In a modern computer the overhead
necessary for the interpretor to look up an unknown word in the input
in a list of 10,000 or less possible nouns wouldn't be much overhead at
all. Better yet, the compiler should catch the fact that nouns
mentioned in the description are not examinable and warn the author.
Yes, authors might turn off the warning messages, but as a C++ software
developer I NEVER turned off warnings. My C++ code compiles without
warnings because I take the care to make sure its right, and a good
author would do the same.
I just hink there's more that compilers and interpretors could be doing
to ease the burden on the author.
--gary
Nathan
> I have a real example, though not a transcript. Some time ago,
> I showed my WIP to a friend who had no prior experience with
> text adventures. He never got past the first room. Here's what
> happened.
Do you have a real example that isn't a game you wrote?
This just sounds like you complaining about your own mistakes.
> You see, there was this table with a computer terminal on it.
> First, he tried to walk up to the table. I explained the basic
> IF conventions. Then he tried to *use* the terminal. Guess
> what happened. Then he looked at it, and learned he could
> talk to the computer (Star Trek style). So he tried to TALK
> TO the machine. Another unimplemented verb.
So you learned from him some things you could change to
improve the way your game would work for a newbie. This is
why you should have people test your game. You said it was
a WIP. I don' t see the problem.
> I suggested him to use ASK ABOUT, and he started to ask
> a lot of things that were irrelevant enough that I hadn't thought to
> cover them.
Again, more useful information for you.
There is also lots of stuff available about writing for newbies.
If you want your game to be a good introduction to IF, you need
to put more effort into achieving that goal.
> By the way, he refused to type HELP, despite the
> conspicuous prompt in the standard header, claiming "it
> shouldn't be necessary". I only half-agreed, considering it
> was his first contact with IF, but he did have a point.
No he did not! I'm fed up with people trying to use new things,
but refusing to learn how and complaining that they don't
understand. That goes for everything from my mom's new food
processor to my neighbor's new word processor. When you do
something new, a learning process is required. There is no
royal road. Appliances and adventures cannot read your
mind, and we should not make them try. RTFM!
This particular problem is not your fault. At all.
> Anyway, this story shows the truth about the "illusionary
> freedom" IF suposedly gives the player. It's not even
> illusionary. *It doesn't exist*.
This is nonsense. No author can *force* the illusion of freedom
on an uncooperative player. Your friend chose to mess around
with the game in his own way, heedless of your efforts to
initiate him. No matter how well written, a novel won't give you
a powerful immersive experience if you try to use it by asking
it questions, tearing out pages, or throwing it against the wall.
> In this regard, graphical adventures are more fair: they make
> it clear what one can and cannot do whithin the game world.
This has not been my experience. "Find the hidden hotspot"
and "guess the action/object combination" are just as
notorious as "guess the verb".
> Now, catching unimplemented nouns, or auto-detecting
> when the player is stuck, *might* alleviate the problem.
> Somewhat. But it doesn't go nowhere near the source.
> And the source of the problem is... well... I can't define it
> in a few words, but playing IF is not like reading a book,
> as much as we like to compare the two. A computer
> program is a computer program, and it's not truly intuitive.
Neither is a book. How much time and effort did you spend
learning the standard user interface of books?
Andrew Plotkin
> Stephen Bond wrote:
> > I'd prefer if you used a real example and not a hypothetical one.
>
> I have a real example, though not a transcript. Some time ago,
> I showed my WIP to a friend who had no prior experience with
> text adventures. He never got past the first room. Here's what
> happened.
>
> You see, there was this table with a computer terminal on it.
> First, he tried to walk up to the table. I explained the basic
> IF conventions. Then he tried to *use* the terminal. Guess
> what happened. Then he looked at it, and learned he could
> talk to the computer (Star Trek style). So he tried to TALK
> TO the machine. Another unimplemented verb.
Given the variability of TALK handling across games, I'd want "TALK TO
COMPUTER" to produce a useful message (explaining what sort of command
to use instead). And I'm speaking as an experienced player.
> Anyway, this story shows the truth about the "illusionary
> freedom" IF suposedly gives the player. It's not even
> illusionary. *It doesn't exist*.
Sure it does. It's not like we're playing CYOA games and hallucinating
verbs.
> In this regard, graphical adventures are more fair: they make it
> clear what one can and cannot do whithin the game world.
No they don't. They present a complicated visual scene, and it's only
your playing experience and the design skill of the creators that lets
you know what you can click on and what you can't. That's the whole
point of graphical adventures. They are, as I've argued, analogous to
text adventures on a deep level.
--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 you're an American.
Aaron A. Reed
> I have a real example, though not a transcript. Some time ago,
> I showed my WIP to a friend who had no prior experience with
> text adventures. He never got past the first room. Here's what
> happened.
>
> You see, there was this table with a computer terminal on it.
> First, he tried to walk up to the table. I explained the basic
> IF conventions. Then he tried to *use* the terminal. Guess
> what happened. Then he looked at it, and learned he could
> talk to the computer (Star Trek style). So he tried to TALK
> TO the machine. Another unimplemented verb. I suggested
> him to use ASK ABOUT, and he started to ask a lot of
> things that were irrelevant enough that I hadn't thought to
> cover them. When I pointed this to him, my friend gave up.
> By the way, he refused to type HELP, despite the
> conspicuous prompt in the standard header, claiming "it
> shouldn't be necessary". I only half-agreed, considering it
> was his first contact with IF, but he did have a point.
USE and TALK TO are, in my experience, very often used by new players
who are then nonplussed when the game doesn't understand what they
mean. I try to always implement USE as it would be used with various
objects in my game. "USE GUN" should work just as well as "FIRE GUN,"
and is arguably better, since I don't have to guess what variation on
FIRE, SHOOT, PULL TRIGGER, etc. the author might have coded in. I have
also implemented TALK TO in my games, since I feel it's a lot more
intuitive than ASK ABOUT -- though the latter is still implemented for
experienced players or players who read the instructions.
This problem is compounded since many of the Inform library messages
are written in the somewhat snarky, impatient tone of the classic
Infocom games ("Is that the best you can think of?" "You would
achieve nothing by this.") but I think for modern players the idea of
being scolded by a program that doesn't even understand the word USE is
a turn-off.
> Anyway, this story shows the truth about the "illusionary
> freedom" IF suposedly gives the player. It's not even
> illusionary. *It doesn't exist*. In this regard, graphical
> adventures are more fair: they make it clear what one can
> and cannot do whithin the game world. It may not seem
> free, but it's at least honest, and people appreciate honesty.
There's some truth to this. I think the frustration many new players
experience when first trying IF is related to the fact that they feel
the game is being dishonest with them. Explaining that you see
something and then responding with "You can't see any such thing" feels
dishonest to someone who doesn't know how the parser and compiler work.
Futher, being presented with a fire and told "I'm not sure what you're
trying to do" when you type PUT OUT FIRE is a non-starter.
Whether this is the fault of the library, parser, author, or player can
be debated, but the end result is a definite stumbling block for
newbies. At least in graphical games, the situation is couched in more
limited terms---if I click the right object on the right part of the
screen, something will happen. Arguably this is the same with text,
except that there's thousands of "objects" (words) that might be
involved, instead of a few dozen or less.
I tried to write "Whom the Telling Changed" in a style accessible to
players unfamiliar with IF. At Slamdance in a few weeks it will be
played by a few hundred people, most of whom I expect will fall into
this category. I'm keeping transcripts and will keep an eye open for
interesting patterns.
Stephen Bond
> We could keep a running dictionary of all words used in output, we don't
> need to know what they mean. If any unidentified words appear in the
> users input that *are* in our output dictionary, we can say something
> nice like "you don't need to refer to that".
Except that "You don't need to refer to that" would not be an
ideal response to examining output words like, say, "you", "don't",
"need", "to", "refer", or "that". It would look like the parser is
pretending to understand more than it does. It's in fact a less
sensible response than "you can't see any such thing", the Inform
library default, which at least acknowledges the >EXAMINE verb.
No obvious gain for more processing and memory overhead, but
by all means implement such a parser extension if you want to.
Stephen.
Stephen Bond
> I spend about an hour taking a random sample from a good comprehensive
> dictionary and computing what should be a pretty reliable stimate of
> the number of nouns naming objects that might posisble appear in an IF
> adventure. It appears that there are between 8,000 and 10,000 possible
> "things" that could be named. In a modern computer the overhead
> necessary for the interpretor to look up an unknown word in the input
> in a list of 10,000 or less possible nouns wouldn't be much overhead at
> all. Better yet, the compiler should catch the fact that nouns
> mentioned in the description are not examinable and warn the author.
Dictionary lookup for common nouns isn't enough. Nouns can be
modified by adjectives, determiners, prepositional phrases, all of
which could be used by the player to refer to the object. A game
could use proper nouns or specialised, invented vocabulary which
wouldn't be covered by the dictionary. Abstract nouns like
"abstraction" could be reified and become examinable objects in
surreal games. In addition, you have the problem of deciding
whether even a common noun in the text is actually present and
examinable. It could be in a line of dialogue, or being read by the
player in a journal entry, in which case "You can't see any such
thing" is again a better response.
> I just hink there's more that compilers and interpretors could be doing
> to ease the burden on the author.
Is this really such a burden? In Inform it can be as easy as
listing the noun as an alternative room name. In any case, I
suspect that the authors who can't be bothered describing the
objects in a room are probably not willing to put in the effort
elsewhere in their games.
Stephen.
Risujin
> Here, fel...@yahoo.com <fel...@yahoo.com> wrote:
>>In this regard, graphical adventures are more fair: they make it
>>clear what one can and cannot do whithin the game world.
>
> No they don't. They present a complicated visual scene, and it's only
> your playing experience and the design skill of the creators that lets
> you know what you can click on and what you can't. That's the whole
> point of graphical adventures. They are, as I've argued, analogous to
> text adventures on a deep level.
Dor every game there is a finite set of actions a player can perform.
The problem we're talking about here is learning that set.
If we bring back from the dead the LucasArts graphical adventure games
for a moment, recall that all verbs used were listed on the screen (all
6 of them in the Monkey Island games), and the inventory and game world
had only one mode of interaction--clicking. The set of interactions the
player can initiate is easy to learn, nothing is hidden. This is what we
mean by an "honest game".
Speaking of which, IF was actually supposed to be as honest as a game
could be. All interactions should be natural to the player. We all know
a great variety of English words and how to use them. So, in theory, we
are already familiar with our set of actions and can jump right in, right?
Wrong! Whatever the ideal IF may be, the golden standard today is far
from it. IF uses a very limited set of verbs which we have to learn
through playing. When we were young and naive, playing our first IF, we
all tried goofy things natural to us, who would't try to "use the
computer"? It makes perfect sense to us, but there are real issues with
implementing a "use" verb within a game. Does it give too much away (use
everything and win)? What exactly does the player expect to do? Problems
like these and others restrict the verb list pretty severely.
IF, in a way, is a half-success. The big idea of a player already
familiar with his set of actions never materialized. We know our set of
actions within the real world and with other games, yes, but each new
type of game we encounter has to give thorough instructions as to what
we can and cannot do. IF is no exception.
-- Risujin
Mark Thern
interface does more to hold it back from a wider audience than any
other factor. Felix's friend was not wrong to insist that he shouldn't
have to resort to using Help to understand how to play. Good
professional software takes the time to guide new users through its
functions. A player is ponying up irreplaceable moments in a finite
lifetime to play your game. He deserves more appreciation for that than
this:
Catchy introductory paragraph
Type Help for instructions.
>(Flashing cursor)
If the user isn't turned off by this kind of cavalier treatment, the
hassles of using the parser will soon provide new reasons to turn off
the program and go do something else. If the player can't type with ten
fingers or type particularly well, then they are not going to have
much fun. And even assuming the player is an expert typist, much of
what he types is going to get a variation of "You can't do that" as a
response. I love games that revolve around social interaction with
npcs, but it's a right pain to have to type >Ask about (keyword) over
and over again when there are lots of npcs to use them on and lots of
potential keywords. I think I logged somewhere around 500 turns when I
did that playing Sting of the Wasp. I enjoyed that game tremendously,
mainly because its clever "You can't do that responses" made it less
tedious to play, but it sure was a lot of work.
Overall, I don't think the benefits of hiding the player's choices are
worth the cost. I'm designing a game in Tads 3 that uses a point and
click interface that only allows productive commands to be entered. The
theme is one of political intrigue and the gameplay revolves around
deciding what to ask and what to tell, which is done by clicking a verb
and the appropriate keyword. By using this system, I hope to create a
game where the primary problem is not figuring out "What can I do?" but
rather "What should I do?"
Poster
mouse. Six or half-dozen. I watched my grandfather learn to use the
mouse, and it too requires learning.
I'm not so certain as to what's cavelier about a catchy paragraph. Did
you mean the being told how to get help part? (You could argue that a
word is more primal than an icon that stands for help; and in fact,
this is often the case. Many times GUI designers simply put a word on a
button rather than bother with icon design, because the word is more
quickly comprehended.) Or is it the flashing cursor that is cavalier?
Yes, I'm being facetious here, but only to illustrate that one
interface is hardly any more cavalier than another. Both visual
paradigms and textual paradigms can be equally obtuse.
I can't say that purposefully hiding the choices is always the best
choice. For more complex games, it would be. For most IF games
(especially the simpler treasure collecting ones), it isn't worth it.
~Poster
www.intaligo.com Building, INFORM, Doom metal
Jimmy Maher
> But you assume here that all users are skilled with, or enjoy using the
> mouse. Six or half-dozen. I watched my grandfather learn to use the
> mouse, and it too requires learning.
I also don't think that the typing interface is the main thing holding
IF back from greater acceptance. I base this on the popularity of
another application that is build around typing, and lots of it: instant
messaging. IM and email has replaced the telephone as the primary means
of interpersonal communication for a big chunk of people, especially
young people.
I am hardly a command line purist, yet I personally find it easier,
faster, and more natural to just type what I am trying to do than to
click a verb, followed by a noun, possibly followed by a preposition,
etc. I say this even though I wrote an interpreter partly as an
experiment in just this kind of interactivity. When I use my terp, I
shut all those bells and whistles off.
I think this kind of interface is potentially useful for easing people
into IF, however, which is the main reason I chose to include it in
Filfre. That, and because I find the Inventory and Objects in Area
windows to be occasionally useful just to have up for reference. I just
don't think eliminating the typing is the magic bullet to bring newbies
into the fold, and it's actually a bit of a dangerous road to go down.
Pretty soon we will be reduced to the simplistic "one-click does all"
interaction of most commercial graphic adventures, without the pretty
pictures they use as partial compensation.
--
Jimmy Maher
Editor, SPAG Magazine -- http://www.sparkynet.com/spag
Thank you for helping to keep text adventures alive!
Samwyse
> Andrew Plotkin wrote:
>> Here, fel...@yahoo.com <fel...@yahoo.com> wrote:
>>
>>> In this regard, graphical adventures are more fair: they make it
>>> clear what one can and cannot do whithin the game world.
>>
>> No they don't. They present a complicated visual scene, and it's only
>> your playing experience and the design skill of the creators that lets
>> you know what you can click on and what you can't. That's the whole
>> point of graphical adventures. They are, as I've argued, analogous to
>> text adventures on a deep level.
>
> Dor every game there is a finite set of actions a player can perform.
> The problem we're talking about here is learning that set.
Which is exactly what good games do: they teach you the set of commands
that you need to play the game. Almost every game extends the
"standard" grammar in some way or another. This makes it easy to fall
into a "guess the verb" puzzle. The trick to to remember Chekov's gun
and apply it in reverse. If you are going to use the verb
"transmorgrify" in the third act, you need to introduce it in the first.
Look at some "simple" but popular graphics games: Tetris, Lemmings,
etc. In each of these, the early rounds are simple, teaching the player
the vocabulary of the game. In Lemmings, for those who don't recall,
there are a half-dozen or so types of lemmings that you can control.
The first few rounds introduce them one at a time, then the next few few
let you play with various combinations of one or two. It isn't until
well into the game that the player has to juggle all of the different
classes to solve the puzzles.
You have to do the same thing in IF. Look at the Enchanter series:
There you had to learn a large number of spells, but they weren't all
thrown at you at once. If you create a story that starts the player in
a room with a computer, that room can't just be a puzzle, it has to
teach the player how to use computers in the game. And that requires
customization -- a lot of it, in fact. USE COMPUTER shouldn't neither
say "Huh?" nor should it magically do what is needed at that point.
Instead, perhaps it should list the things that can be done. In other
words, USE (and other general verbs) might be implemented as a type of
on-line help system:
> USE COMPUTER
Do you want to turn the computer on or off, list the available programs,
run one of them, or insert or remove a floppy?
> LIST PROGRAMS
(First turning on the computer)
This computer has three programs: email, notepad, and crypto.
> RUN EMAIL PROGRAM
Do you want to compose a message to someone or read your messages?
> COMPOSE A MESSAGE TO GRAHAM
You send a message to Dr. Xavier, telling him of your discoveries in the
Mayan ruins.
Et cetera.
Nathan
> Felix's friend was not wrong to insist that he shouldn't
> have to resort to using Help to understand how to play. Good
> professional software takes the time to guide new users through its
> functions.
Yes, he really was wrong to insist that he shouldn't have
to read any instructions before using something new.
There is certainly a place for introductory IF, which could
assume every user is new until told otherwise. But I
don't think every game should have to work this way.
Every time I start up my good professional software, it doesn't
automatically treat me like a newbie--and that's a good thing.
Having learned how to use it, I don't want to be interrupted by
introductory things each time. Good professional software
includes the means for a new user to ask for help. If the new
user refuses to ask for help, he shouldn't complain that he can't
understand how to use the software.
> A player is ponying up irreplaceable moments in a finite
> lifetime to play your game. He deserves more appreciation for that than
> this:
>
> Catchy introductory paragraph
>
> Type Help for instructions.
>
> >(Flashing cursor)
>
> If the user isn't turned off by this kind of cavalier treatment, the
> hassles of using the parser will soon provide new reasons to turn off
> the program and go do something else.
How is this different from any other piece of software in the universe?
You get a title screen, and then the actual program interface. No one
automatically knows what to do the first time, but nowadays
well-designed software gives new users a simple way to ask for help.
You can choose to click on "Help" or not. Does anybody really think
of this as "cavalier treatment"?
> If the player can't type with ten fingers or type particularly well, then
> they are not going to have much fun.
Of course. IF really isn't for everyone. But this is RGIF. There are
newsgroups for other kinds of games, too.
> Overall, I don't think the benefits of hiding the player's choices are
> worth the cost.
Well, this is a matter of taste. I always preferred IF over CYOA books.
Different people like different things. I don't see the IF community
replacing IF with something else just to attract more people.
We like text adventures. Not everybody does.
> I'm designing a game in Tads 3 that uses a point and
> click interface that only allows productive commands to be entered. The
> theme is one of political intrigue and the gameplay revolves around
> deciding what to ask and what to tell, which is done by clicking a verb
> and the appropriate keyword. By using this system, I hope to create a
> game where the primary problem is not figuring out "What can I do?" but
> rather "What should I do?"
As a kid I liked a Mideast political simulation game called Conflict,
whose interface was all checkboxes. I would probably be interested
in playing your game, too. There are good games with point-and-click
interfaces in which every command does something. They just aren't IF.
It really doesn't make sense to me to use a specialized IF language to
write such a game, either.
fel...@yahoo.com
>
> I also don't think that the typing interface is the main thing holding
> IF back from greater acceptance. I base this on the popularity of
> another application that is build around typing, and lots of it: instant
> messaging. IM and email has replaced the telephone as the primary means
> of interpersonal communication for a big chunk of people, especially
> young people.
>
an IM client goes to a human, not to a computer who fails to
understand 90% of it. The program itself is controlled through a GUI
of some sort, otherwise it would be a chore.
> I am hardly a command line purist, yet I personally find it easier,
> faster, and more natural to just type what I am trying to do than to
> click a verb, followed by a noun, possibly followed by a preposition,
> etc. I say this even though I wrote an interpreter partly as an
> experiment in just this kind of interactivity. When I use my terp, I
> shut all those bells and whistles off.
>
I like the command line a lot myself, just not for every task. It's too
involved. For someone unfamiliar with it, it's the very opposite of
fun.
> I just
> don't think eliminating the typing is the magic bullet to bring newbies
> into the fold, and it's actually a bit of a dangerous road to go down.
> Pretty soon we will be reduced to the simplistic "one-click does all"
> interaction of most commercial graphic adventures, without the pretty
> pictures they use as partial compensation.
>
I agree. By my reckoning, the ideal interface would have buttons/links
for the basic commands *and* a command prompt to let the player
experiment himself once he learns it's not all that complicated. See
the way HTML TADS works.
Now, as someone else noted, the mouse interface must be learned
as well. It's not easy, either. But once you've learned it (as most
computer users do nowadays), it's much easier to apply it in new
circumstances, and that's what makes it so successful. In a graphical
adventure, even if you've never played one before, you can simply
start clicking around at random: at least something useful will happen.
In a hurry,
Felix
Urbatain
overall positive experience.
>From I remember I allways tried to show IF to non player people. But
allways to non hardcore 3D players or arcade ones. Here is a brief
report of my quest:
-Two friends of mine... Universitary ones, around twenty. Full ... how
I must say it... full exit, no full score? full goal? let's say full
gooool. They pass the game without my help (a pretty good spanish one,
without walkthrough and without internet). But I lost contact so I
think that it was the first and the last IF game they play. But they
enjoy it a lot.
-My very best friends... Average goool. They must carry my friendship
and that includes to play my games wity myself looking over their
shoulders and my gun against their heads. They enjoy my works but they
never play them by themselves.
-My cousins... I've tested the children friendly of the spanish IF
games, and the experience was a banana of discord. For the spanish IF
world part it was a miss, because there's no a lot of IF works
orientated to children, either to young ones between 12 and 17. But the
response of my cousins was very possitive. I've learned that an IF work
is only situable for children from 7 age old and upper, beacause typing
and reading skills (well, if the boy is an illiterate, nobody could
help him here). You can put a girl of 7 or 6 but you must stay with her
and help she to type, or almost type for her.
They enjoy a lot the experience, but again, they for themselves will
not play them alone. Maybe with multiples days of IF games in family
could help to gain them to us.
-My little girl of 3 years old, allways tell me: Daddy, let's play
Alice in Wonderland, or the Cat in Boots. I read in loud voice and type
my way to the end, but my baby undestand the game spirit of the genre
and allways tell me: go to the castle!, take the rabbit with the sack,
etc etc.
All this gives me the thinking... we have little works suitable for
childrens or young ones. So the resources soon went to cero, than a
children could get really excited with the genre. We need more works
like fairy tales, and very polished ones. Something like The Stronghold
but oriented for children will be a good idea.
With childrens we must see the theme like a father playing with his
offspring, allways be there in front of the computer and enjoy the
time.
With more youngs and mature people we need more Strongholds... maybe we
need a help newbie system that could be inserted in a variety of games.
But remember... when a child grows to 14 and up, they forget at all the
goodness of the static fiction, books, etc and go towards TV, net,
discos, pubs, and 3D games, so maybe is a waste of time to try to
expand the genre in that direction.
I notice with newbies, that they express allways in a really true
natural way with the parser. while us, we are slaves of our
"professional deformation" and speak allways in a rare speaching form:
"mommy, give me milk", "take milk" "drink milk" Oh god, my son is
mad!!!, that our games rarely support a 100% proof natural language and
logical tries of the newbies. Maybe we must constate that the natural
language is an utopia, and we must know that we have games, and games
had a list of commands and instructions... you see. I'm really on the
side of the interface of late Adam Cadre game's parser where he cut
some of the actions of inform giving a cute, small and polished raw of
commands to interact with the world. So, what direction must we walk?
We have a lot of works for mature minds, so that is the way to follow.
Is a very discussed thread around here so I don't want to say something
allready spoken. But I think to advertish us in visual impaired people
forums and webs is a good idea. I get a reasonable goool in that
"market niche" here in the spanish community. But I or we must put more
efforts in this direction.
See you.
Urbatain.
Mark Thern
every user is new until told otherwise. But I don't think every game
should have to work this way."
That's where I differ with you. I think every piece of I-F should
assume that their users are new. If they aren't new, then they should
be given the choice of turning off the tutorial hints and\or given the
option of using a traditional interface.
If we accept this assumption as a given, then the traditional "Type
Help for instructions" is cavalier for two reasons:
1.) You're forcing the user to pay the whole cost up front before he
can enjoy your work.
Every new activity has a learning curve. That's unavoidable. However,
there's no reason to make that curve any harder than it needs to be.
People are willing to spend a lot of time learning how to read or how
to drive because reading and driving are life enriching skills that
will be used every day of their lives. Playing I-F is pretty trivial by
comparison, and if I make my user read 2 to 3 pages of instructions
before he can enjoy my game, I'm forcing him to decide right then and
there whether or not he should quit. Remember, he's new to I-F, and he
has no idea if the effort is going to be worth the trouble. Plenty of
reasons for him to quit already exist. I don't want to give him extra
ones.
If I were making a board game, I would have no choice but to accept the
situation, because there's simply no way to play a board game without
prior knowledge of the rules. But I-F is interactive, which means that
if I'm willing to take the time to consider my player's needs, I can
teach him step by step, allowing him to pay as he goes instead of
making him invest a chunk of time with an uncertain return.
2) You're forcing the user to memorize your instructions in order to
play the game.
My mother is a bright lady who actually does read the manuals for the
electronic gizmos that she buys. However, she's over 60 and her memory
doesn't work as well as it used to. This is why she has to drag out the
manual to her VCR every time she wants to program it to record
something. If this were an activity she did every day, she wouldn't
have this problem, but she does this infrequently and so the
instructions don't stay with her. If the VCR's interface was designed
in way that allowed its users to quickly reacquaint themselves with
how it works, then she wouldn't have to do this. It's fair to expect
users to be able to follow instructions; it's not fair to expect them
to memorize them. Computer programmers are so adept at keeping
complicated sets of instructions in their heads that I think they
forget that most people don't have that ability.
A work of I-F is going to see even less use than my mom's VCR. And you
have to remember that most people have limited amounts of leisure time
to spend. I think it's best to assume that the average person is going
to play your game in short bursts of an hour or two spread across a
period of a month or more. If you force them to relearn the rules each
time they play, you're giving them an incentive to quit. Products with
easy to use interfaces are going to enjoy more success than ones that
don't have them. It's why cars with automatic transmissions sell better
than cars with manual ones.
"I don't see the IF community replacing IF with something else just
to attract more people."
I don't think I'm advocating replacing I-F with something else so much
as I am in making it more user-friendly and broadening the styles of
games that are produced. Proponents of complex war games will tell you
that the game play is well worth the investment needed to learn the
rules. Sure, okay. Different strokes for different folks. But I
wouldn't play board games at all if complex war games were the only
kinds available to play.
"It really doesn't make sense to me to use a specialized IF language
to write such a game, either."
As a newbie programmer struggling with the arcana of Tads 3, I often
feel that way myself. However, it's still easier to use Tads 3 and its
predefined libraries than it would be to learn a more general language
and write all those routines from scratch.
Samwyse
>
> -My little girl of 3 years old, allways tell me: Daddy, let's play
> Alice in Wonderland, or the Cat in Boots. I read in loud voice and type
> my way to the end, but my baby undestand the game spirit of the genre
> and allways tell me: go to the castle!, take the rabbit with the sack,
> etc etc.
>
> All this gives me the thinking... we have little works suitable for
> childrens or young ones. So the resources soon went to cero, than a
> children could get really excited with the genre. We need more works
> like fairy tales, and very polished ones. Something like The Stronghold
> but oriented for children will be a good idea.
>
> With childrens we must see the theme like a father playing with his
> offspring, allways be there in front of the computer and enjoy the
> time.
I've done much the same with my daughter, who is just learning to read.
Unfortunately, we were playing Adventure, and the first appearance of
a dwarf frightened her. ;-)
> With more youngs and mature people we need more Strongholds... maybe we
> need a help newbie system that could be inserted in a variety of games.
[...]
> I notice with newbies, that they express allways in a really true
> natural way with the parser. while us, we are slaves of our
> "professional deformation" and speak allways in a rare speaching form:
> "mommy, give me milk", "take milk" "drink milk" Oh god, my son is
> mad!!!, that our games rarely support a 100% proof natural language and
> logical tries of the newbies.
In English, there's Emily Short's NewbieGrammar.h and ExpertGrammar.h,
which arguably should be made part of the standard library. These
aren't help systems (for that, see her HelpRoutines.h), but they assist
new players who aren't used to the conventions of "standard" IF.
Stephen Bond
> Dor every game there is a finite set of actions a player can perform.
> The problem we're talking about here is learning that set.
I don't believe that's the problem. (By the way, it's worth
distinguishing between actions, such as >PUT THE CAT ON THE
TABLE, and verbs, such as "put on". The latter can be considered
as ways to act.)
> If we bring back from the dead the LucasArts graphical adventure games
> for a moment, recall that all verbs used were listed on the screen (all
> 6 of them in the Monkey Island games), and the inventory and game world
> had only one mode of interaction--clicking. The set of interactions the
> player can initiate is easy to learn, nothing is hidden. This is what we
> mean by an "honest game".
It's not what I mean.
I wouldn't hold up the LucasArts adventures as an ideal of game or
interface design. Looked at unsentimentally, how many of them were
great *games*? I've played all the classic SCUMM games, and have fond
memories of them -- but the things I remember are the jokes in Monkey
Island, the banter between Indy and Sophia, the artwork, the wonderful
iMuse soundtracks. In truth, the games themselves were fairly
uninspired, a series of contrived and repetitive
locked-door/give-stuff-to-the-NPC puzzles. (Much of the humour in
Monkey Island was actually at the expense of the game itself.) The
shortcomings of the games have a lot to do with the interface, which
tells you what objects can be used, tells you what the objects are,
and tells you all the possible ways in which you can use them. This
places pretty drastic limits on the number of possible actions, and at
any one time the player can be aware of them all, making the game
world seem artificial. The SCUMM games would mostly make poor text
adventures.
(It's worth noting that such limitations aren't present in, say, FPS
games, where the number of ways to act is limited, but the number of
possible actions is enormous. IF games have a much smaller number of
possible actions than FPS games, but most of these are hidden from
the player, and the player is aware of this. So there seem to be many
more possibilities than there really are.)
> IF, in a way, is a half-success. The big idea of a player already
> familiar with his set of actions never materialized.
It's not an ideal of IF that the player knows the entire
set of possible actions, or even the entire set of verbs, although
that may well be the ideal of several things which are not IF.
Rather, the ideal is that when the player thinks an action should
work, then the action should work. (To paraphrase a quote by
Andrew Plotkin, whom I'm already plagiarising extensively in this
post :) Ideally, the player should have an intuitive feel for what is
possible and what is not, a feel which develops as he explores and
interacts with the game. This offers a much deeper and more
engaged participation in the game world than what is possible in
the SCUMM system. The player develops insights about the game,
discovers how to interact with it. The best such experiences I've
had in IF (in _Photopia_, _Spider and Web_, _All Things Devours_)
would not work if all the possible actions were given up-front.
Stephen.
Stephen Bond
>I think every piece of I-F should
> assume that their users are new. If they aren't new, then they should
> be given the choice of turning off the tutorial hints and\or given the
> option of using a traditional interface.
>
> If we accept this assumption as a given,
And why should we do that? It's a rather sweeping assumption, and not
one I agree with.
then the traditional "Type
> Help for instructions" is cavalier for two reasons:
Well your original post referred to the "cavalierness" of a
presenting the player with some introductory text, "Type Help
for instructions", and a command prompt, which is a different
thing.
> 1.) You're forcing the user to pay the whole cost up front before he
> can enjoy your work.
> Every new activity has a learning curve. That's unavoidable. However,
> there's no reason to make that curve any harder than it needs to be.
I think people familiar with command-line environments
(a dwindling number, I know) would probably gather from such
an introduction that some kind of command was required, and
would probably try a few commands of their own before resorting
to >HELP. Even for those who have never seen a command line
might gather the same from the opening text, the "type help"
suggestion, and the flashing cursor. So even in the most
cavalier game one doesn't necessarily have to invest a chunk of
time before getting started.
Such an interface might discourage anyone who doesn't like typing,
but then IF also discourages anyone who doesn't like reading.
No big deal. The medium can't cater to everybody.
I'm more concerned that the interface might discourage people
who do like reading and don't mind typing, and I agree it
often does. (Other turn-offs include contrived puzzles, dodgy
implementation, poor writing and so on, though these can be
avoided by pointing newbies to good games.) I have ideas about
why this is so and how to get around the problem, but I'd rather
test them out in a game first.
> 2) You're forcing the user to memorize your instructions in order to
> play the game.
> Computer programmers are so adept at keeping
> complicated sets of instructions in their heads that I think they
> forget that most people don't have that ability.
IF commands (meta-commands like "save" and "restore", and special
commands like "inventory", excepted) are not really "instructions" in
the sense that the ones in your VCR manual are. One doesn't need to
learn off a large set of specialised terms or abstract concepts.
Really, the only concept to learn is that the game accepts commands
in natural language, which it can be assumed the player has memorised
since infancy. I don't know what "complicated sets of instructions" one
has to keep in mind when using a work of IF.
> Products with
> easy to use interfaces are going to enjoy more success than ones that
> don't have them. It's why cars with automatic transmissions sell better
> than cars with manual ones.
Not where I come from.
Sometimes it's worth learning a more difficult interface to get a
more rewarding experience (as you acknowledged with the wargames
example). One shouldn't have to cater towards the slacker mentality.
Stephen.
David Thornley
Risujin <ris...@fastmail.fm> wrote:
>
>Dor every game there is a finite set of actions a player can perform.
>The problem we're talking about here is learning that set.
>
There is no need for the player to know everything he or she can
do. Indeed, many puzzles depend on the player not knowing exactly
what's possible, and trying ingenious things that may or may not
work.
>If we bring back from the dead the LucasArts graphical adventure games
>for a moment, recall that all verbs used were listed on the screen (all
>6 of them in the Monkey Island games), and the inventory and game world
>had only one mode of interaction--clicking. The set of interactions the
>player can initiate is easy to learn, nothing is hidden. This is what we
>mean by an "honest game".
>
Wrong.
There was one puzzle in Monkey Island that I needed help on. There
was (IIRC) a statue with a nose that had to be held down, and I didn't
pick up on that particular hot spot. If there were a command to highlight
the hot spots, that would make it fair by your definition.
Now, if it were possible to highlight all the hot spots, and all the
verbs were shown, would it be easy to write a good game?
What I really liked from Monkey Island was not the actual gameplay,
although that was occasionally entertaining, but the other things
that were going on.
>Speaking of which, IF was actually supposed to be as honest as a game
>could be. All interactions should be natural to the player. We all know
>a great variety of English words and how to use them. So, in theory, we
>are already familiar with our set of actions and can jump right in, right?
>
Who supposed IF to be as honest as possible? There are a lot of
Infocom puzzles that would be considered thoroughly unfair today.
The baseball puzzle in Zork II is probably the most egregious example.
>Wrong! Whatever the ideal IF may be, the golden standard today is far
>from it. IF uses a very limited set of verbs which we have to learn
>through playing.
Well, there is no type of computer game that offers real natural
language processing, as far as I can tell, so IF is certainly not
alone in that.
When we were young and naive, playing our first IF, we
>all tried goofy things natural to us, who would't try to "use the
>computer"? It makes perfect sense to us, but there are real issues with
>implementing a "use" verb within a game. Does it give too much away (use
>everything and win)? What exactly does the player expect to do? Problems
>like these and others restrict the verb list pretty severely.
>
For that reason, an author could implement the "use" verb to print
out a hint as to what verbs to use and how to use them. This is
a matter of game design. All computer games have limitations.
Some of these are due to computer and computer science limitations,
such as the lack of good natural language processing. Some are
necessary to limit the game world to something that can be envisioned
in detail by one author.
>IF, in a way, is a half-success. The big idea of a player already
>familiar with his set of actions never materialized. We know our set of
>actions within the real world and with other games, yes, but each new
>type of game we encounter has to give thorough instructions as to what
>we can and cannot do. IF is no exception.
>
Look, I'm not thoroughly familiar with my set of actions in real life.
There's lots of things I could do that I just don't think of. Why
should IF be different?
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
samwyse
> If I were making a board game, I would have no choice but to accept the
> situation, because there's simply no way to play a board game without
> prior knowledge of the rules. But I-F is interactive, which means that
> if I'm willing to take the time to consider my player's needs, I can
> teach him step by step, allowing him to pay as he goes instead of
> making him invest a chunk of time with an uncertain return.
You're on a slippery slope, there. How do you explain RESTART, SAVE,
and RESTORE in this context? When, during the game, do you decide to
tell the player about UNDO? How do you explain LOOK and EXAMINE
without resorting to an expository chunk?
What about the interpreter that I'm using? Why can't I have the game
repeat what it just said? You see, I'm using the version of WinFrotz
that supports speech-synthesis, and there are special keystrokes that
re-read the screen to me.
Magic: The Gathering already prints most of the rules on the playing
cards themselves. Why not get rid of the instruction sheet altogether
and print *everything* on the cards.
There comes a point where you have to assume both a base level of
knowlege and a desire to acquire basic instructions. Otherwise, you'll
just frustrate the people who are willing to read an instruction manual.
Mike Roberts
> IF games have a much smaller number of possible actions than
> FPS games, but most of these are hidden from the player, and
> the player is aware of this. So there seem to be many more
> possibilities than there really are.
I believe that last sentence is, in a nutshell, the real answer to the
question posed in the subject of this thread. People who like IF think this
is a virtue. People who don't like IF think it's a bug. The bug isn't that
the possible actions aren't visibly enumerated the way they are in a
graphical adventure; it's that the interface implicitly promises that, by
*not* enumerating the possible actions, all reasonable actions are possible.
Newbies gradually and gruellingly discover the gulf between promise and
reality as 98% of their commands fail due to missing vocabulary, missing
grammar, missing world model, or missing plot flexibility. Some people
enjoy this discovery process; others find it unfun.
I don't personally think any amount of added nouns or verbs or grammar lines
will change this; I think the over-promising is intrinsic in the
command-line UI. (At least, in the "ordinary English" command-line UI.
Clearly it changes matters if we admit to players that it's a computer
command shell, like DOS: no one would expect a DOS shell to respond
favorably to WOULD YOU PLEASE STEALTHILY SHOW ME THE CONTENTS OF THE ROOT
FOLDER OF MY 80 GIGABYTE HARD DISK GOOD SIR.) I think, rather, it comes
down to taste. Some people like the illusion of freedom you get from the
command line more than they dislike its negative aspects; most people don't.
I don't think there's much we can do to change that latter group's minds.
--Mike
mjr underscore at hotmail dot com
Mike Roberts
> I wouldn't hold up the LucasArts adventures as an ideal of game
> lot to do with the interface, which tells you what objects can be
> used, tells you what the objects are, and tells you all the possible
> ways in which you can use them. This places pretty drastic limits
> on the number of possible actions, and at any one time the player
> can be aware of them all, making the game world seem artificial.
I rather disagree with this analysis. In the first place, the one really
inspired bit of game-play that I recall from the several LA adventures I've
played is the Sword Master puzzle in Monkey Island, and that was an even
more constrained UI than normal for LA games - every choice was enumerated,
but even so, the puzzle wasn't readily solvable with trial and error because
its combinatorics created a search space large enough to be inconvenient to
search exhaustively. In the second place, a recurring element of LA puzzle
design was "USE X WITH Y", where X and Y were inventory items. This created
an N^2 search space if you wanted to brute-force it, and most of those games
chose N such that the space was inconveniently large - MI2 had about 40 or
50 inventory items by the end of the game, as I recall.
It's a pernicious fallacy around here that an enumerated range of inputs
creates a brute-force-able search space. If the inputs are limited to a
linear list with no combinability, then, yes, the search space is small.
But as soon as there's a way to combine inputs (as in USE X WITH Y), the
search space expands greatly, and it's easy to get it up to an effectively
infinite size even with a small number of basic input elements.
I could even use a CYOA interface to create a puzzle that you couldn't solve
by brute force - not by using combinable inputs in the UI per se, but by
using state. Example:
[transcript]
You are standing before a steel door. A small keypad is next to the
door, with buttons numbered from 1 to 3. A display above the
keypad is blank.
Would you like to...
1. Push the '1' button
2. Push the '2' button
3. Push the '3' button
>1
You push the '1' button. The display now reads '1'.
Would you like to...
[end transcript]
If the combination is 10 digits long or so, solving by brute-force
exhaustive search is not viable.
My point is that unboundedness is not a unique feature of the command-line
UI. The command-line UI has certain virtues, but being uniquely unbounded
is not one of them.
Stephen Bond
> I rather disagree with this analysis. In the first place, the one really
> inspired bit of game-play that I recall from the several LA adventures I've
> played is the Sword Master puzzle in Monkey Island, and that was an even
> more constrained UI than normal for LA games - every choice was enumerated,
> but even so, the puzzle wasn't readily solvable with trial and error because
> its combinatorics created a search space large enough to be inconvenient to
> search exhaustively. In the second place, a recurring element of LA puzzle
> design was "USE X WITH Y", where X and Y were inventory items. This created
> an N^2 search space if you wanted to brute-force it, and most of those games
> chose N such that the space was inconveniently large - MI2 had about 40 or
> 50 inventory items by the end of the game, as I recall.
My complaint is not that SCUMM games are solvable by brute
force (though I suspect some of them are), but that at any point in
the game all possible actions are available to the player (and that
their number is small enough to be conceivable -- something in the
order of 10^4 in the worst cases, and usually a lot lower). One could
say the same about chess, but chess isn't IF. I don't come to a
chessboard with the same expectations with which I come
to an interactive fictional world -- where I would hope the range and
freedom of actions to be much the same as in the real world, or
greater. The LA interface makes the game world seem like a
chessboard, like a toy, like something obviously limited and
artificial. Of course all interfaces will place some limits on the
possible interaction, but I'd rather that the limits were not made so
obvious. Many of the most interesting IF games specifically exploit
the command line's sense of "anything is possible."
Stephen.
Mark Thern
knowlege and a desire to acquire basic instructions. Otherwise, you'll
just frustrate the people who are willing to read an instruction
manual."
True enough. That said, have you played any recently produced
commercial games that didn't have some sort of tutorial level? The
makers of commercial games know that the majority of their sales will
come from die-hard players who know the genre inside and out. However,
a small percentage of purchasers are going to be new or casual players,
so a tutorial level is included in the hopes that the learning curve
will be reduced enough to transform the new players into regular
customers.
Also, I'd like to point out that my idea of guiding the player through
the process is less obtrusive than you might think. I explain it
gradually during the beginning stages of the game, and then I
implicitly reinforce my explanation through the way the command process
works. As the player enters his command, only commands that are legal
for that particular stage of the loop have active hyperlinks. For
example, once the player has entered a verb, all the verbs in the verb
menu are grayed out and will remain so until the user either finishes
inputing his command or uses the Back button to go back to that stage.
Likewise, I gray out nonsensical choices in the keyword menu when
appropriate, so the user can't enter something like "Ask Mary about Joe
and Joe".
I don't think this is likely to annoy experienced players, and they do
have the option of turning off the tutorial messages if they want.
Mark Thern
>And why should we do that? It's a rather sweeping assumption, and not one I agree with.
I make this assumption not because it's factually true, but because I
want the audience for I-F to grow. To do that, I have to design my game
to meet the needs of new players.
"I don't know what "complicated sets of instructions" one has to keep
in mind when using a work of IF."
Well, there's more than you think. First, the user has to learn the
grammatical syntax used by the parser. If the player passes by a bum
who's munching on a rat like it was a slice of watermelon on a hot day,
he can't type in "That's disgusting!" or "Why are you doing that?" and
be understood. He has to type "Talk to bum" or "Ask bum about rat".
There's a certain way to phrase things that takes a bit of practice to
get accustomed to. A player who reads the instructions, plays the game
for an hour and then revisits the game 4 days later will probably
remember that he has to type in stuff like "Take" and "Ask" if he did a
lot of that on his first playing experience. But if he never used the
"npc, command" syntax during that first hour, he might not remember it
and he's not going to be figure out that the way to get the bum to the
homeless shelter is to say "Bum, follow me," unless he reads the manual
again.
He'll have to memorize any special verbs the designer chooses to
implement. He'll have to memorize the layout of the map because very
few non-Adrift works of I-F provide any sort of map or even a "Go to
Landmark" or "Go to Room" command that saves the player the trouble of
having to type the same lengthy direction sequence over and over again
to get from point A to point B. I loved Anchorhead --devoured it like
it was candy, as a matter of fact-- but I hated how hard it was to get
from the house into town. Oh, and he'll have to memorize any special
keywords the game uses, like the names of the npcs or unique vocabulary
items because very few games have commands that remind players about
these things.
None of this is really a problem if the user plays the game without any
long intervals between pplaying but I don't want to penalize a player
simply because he doesn't have a lot of free time to spend playing my
game.
">Products with easy to use interfaces are going to enjoy more success
than ones that don't have them. It's why cars with automatic
transmissions sell better than cars with manual ones.
>Not where I come from."
Yeah, I read that it's like that in Europe. Here in States, where
people do a lot more driving, an automatic is the way to go.
"Sometimes it's worth learning a more difficult interface to get a more
rewarding experience (as you acknowledged with the wargames example).
One shouldn't have to cater towards the slacker mentality."
I don't see my efforts to improve the interface of I-F as catering to
slackers. I like to imagine my players as unexpected guests who took
time out of their busy schedules just so they could visit me and listen
to what I have to say. I see myself welcoming them into my home,
offering them something to eat or drink, showing them a comfortable
chair to sit in. I see myself looking them in the eye and saying, "I'm
going to tell you a story and you're going to help me and we're going
to have a really good time doing it." And when it's time for them to
leave, they're going to shake my hand and say, "I had a lot of fun.
I'll stop by again sometime."
Rikard Peterson
"Jimmy Maher" wrote in news:11s6aft...@corp.supernews.com:
> I also don't think that the typing interface is the main thing
> holding IF back from greater acceptance.
In addition, I think the typing interface is one of the best things
about IF (when using IF to mean text adventures). Says a person (me)
working on a point-and-click graphical adventure game. I like those
too, but I really like the parser. Remove that, and we might just as
well be playing graphical games.
Rikard
prof...@yahoo.com
programming problem.
With a little experience, an IF author learns to cut references to
objects that aren't important to the game, since every object in the
game world requires a nontrivial amount of work. So instead of
referring to "gray marble walls of the bank" you learn to say "the
imposing bank".
I agree that IF newbies need more help than the experienced player, and
I applaud any designer who goes the extra distance and finds an elegant
way to offer help. (I loved the hint that fluttered down from the
ceiling in Jacqueline Lott's Waterhouse Women
http://www.wurb.com/if/game/1805. )
At the same time, plenty of novels are not written with beginning
readers in mind. It's okay for some works of IF to assume the player
knows has learned how to play the game.
Gary, real IF games that have huge design errors won't get good
reviews, and won't be likely to be found by causal newbies.
Dennis G. Jerz
fel...@yahoo.com
> Such an interface might discourage anyone who doesn't like typing,
> but then IF also discourages anyone who doesn't like reading.
> No big deal. The medium can't cater to everybody.
>
discouraged. As I said, playing IF is not like reading a book,
even when both are done on a computer screen.
But it's time I mention another friend of mine, also an avid reader
and CRPG fan, like my other friend. I introduced him to Glowgrass.
He did have a few gripes with the interaction model, but he found
his way around with reasonable effort. Interesting to note, a game
or two later, he was able to learn the basics of Inform in a few
hours, though he had no prior programming experience.
Now, you could argue that my WIP was deeply flawed, and that's
why it didn't work. I don't think I'm *that* incompetent, besides, it
was my "masterpiece", so my first friend was compelled to be
forgiving; he even liked the introduction.
Apparently, there is *something* to IF that some people love,
some learn to cope with because they like the stories, and yet
others just can't manage, no matter how much they want to play.
These others, I believe, mean the difference between niche genre
and mainstream. If we could just pinpoint that something and fix
it... well... we'd furfill our dream.
Let's experiment,
Felix
Mike Roberts
> Mike Roberts wrote:
>> Stephen Bond wrote:
>>> The shortcomings of the games have a lot to do with the
>>> interface, which tells you what objects can be used, tells
>>> you what the objects are, and tells you all the possible ways
>>> in which you can use them. This places pretty drastic limits
>>> on the number of possible actions, and at any one time the
>>> player can be aware of them all, making the game world seem
>>> artificial.
>>
>> LA puzzle design was "USE X WITH Y" [...] This created an
>> N^2 search space if you wanted to brute-force it.
>
> My complaint is not that SCUMM games are solvable by brute
> force (though I suspect some of them are), but that at any point in
My point was that the possible *actions* aren't enumerated to the player
just because the verbs and nouns are. The set of possible actions is
plainly finite, but it's not enumerated; the list would have a couple
thousand entries in the typical case in an LA game. It's too big even to
enumerate in your head, even though you know the construction rule and can
see available inputs. You said enumerating the verbs places "drastic
limits" on the available actions; I'm saying that while there are obviously
limits, I'd hardly call them drastic.
> The LA interface makes the game world seem like a
> chessboard, like a toy, like something obviously limited and
> artificial.
And text IF seems obviously limited and artificial to a newbie because of
the intractable UI. It's a matter of perspective and taste.
For what it's worth, I rather like text IF, but I've generally found the
graphical UIs in the LA games I've played to be more transparent than the
typical command-line UI - in other words, it was easier to forget about the
mechanics at that level and get into the story than it typically is with a
command line. The command-line parser is too often in the way to become
transparent, in my experience, and it calls attention to the clockwork
artifice of the game. That's my subjective experience; obviously everyone's
mileage varies.
Urbatain
an that objects becomes irrelevant for the game. For example, level9
allways make a superb work about it. If you try
>examine walls of the bank
That's not important for winning the game
or
It's just scenery, don't waste time in it.
This a ton of better than I can't see that, that breaks all the mimesis
created by the description.
See you.
Urbatain.
Stephen Bond
> "Stephen Bond" <steph...@ireland.com> wrote:
> > My complaint is not that SCUMM games are solvable by brute
> > force (though I suspect some of them are), but that at any point in
> > the game all possible actions are available to the player [...].
>
> My point was that the possible *actions* aren't enumerated to the player
> just because the verbs and nouns are. The set of possible actions is
> plainly finite, but it's not enumerated; the list would have a couple
> thousand entries in the typical case in an LA game. It's too big even to
> enumerate in your head, even though you know the construction rule and can
> see available inputs. You said enumerating the verbs places "drastic
> limits" on the available actions; I'm saying that while there are obviously
> limits, I'd hardly call them drastic.
Then we have a different idea of what constitutes an acceptable
limit in this case. The actions in an LA game are not enumerated,
but they are finitely enumerable; and a few thousand actions is
not very many, far fewer than in a typical 3D game, and far fewer
again than in real life. While a few thousand actions might be too
many to contain in the average head, the finite space of actions
is rather easy to conceptualise (usually objects * objects *
verbs), the enumerated verbs and objects providing a
convenient index into this space. I don't think it's a stretch to
say that in telling the player all the available verbs and
objects, the game makes the player aware of all the available
actions.
To speak in more concrete terms, none of my favourite
moments in IF would have worked if all available actions were
presented to the player -- the famous puzzle in _Spider and
Web_, the maze in _Photopia_. Or if I may plug my own stuff
by way of example (possible spoilers here), for _Rameses_
to work, it's crucial that the player is not aware of the set of
available actions. If at every turn the player was presented
with 1,000 or even 10,000 actions to choose from, only
for the PC not to do them -- well maybe they're just the
wrong 10,000 actions. If instead the player is presented with
the possibility of doing *anything* and then the PC does
nothing -- that creates the kind of effect I wanted. (And yes,
I know there's a conversation menu. I put that there for
different, but not entirely unrelated, reasons.)
> And text IF seems obviously limited and artificial to a newbie because of
> the intractable UI. It's a matter of perspective and taste.
Of course it's a matter of perspective and taste. I hope that
should go without saying.
> The command-line parser is too often in the way to become
> transparent, in my experience, and it calls attention to the clockwork
> artifice of the game.
I agree it usually does, especially when it's a bad parser or the
game is poorly-designed. But in the best games, I find it far
more transparent than the LA interface.
Stephen.
Stephen Bond
> > > I think every piece of I-F should assume that their users are new. If we accept this assumption as a given...
>
> >And why should we do that? It's a rather sweeping assumption, and not one I agree with.
>
> I make this assumption not because it's factually true, but because I
> want the audience for I-F to grow. To do that, I have to design my game
> to meet the needs of new players.
So then not every piece of IF should assume that its users are new.
Only the ones designed to meet the needs of new players.
> > > You're forcing the user to memorize your instructions in order to
play the game.
> > I don't know what "complicated sets of instructions" one has to keep
> in mind when using a work of IF."
>
> Well, there's more than you think. First, the user has to learn the
> grammatical syntax used by the parser.
Like I said, one just has to learn that it's the syntax of
commands in natural language. In practice, the parser is usually
not good enough to handle all such commands sensibly, I admit,
but in theory the syntax is very simple. (>NPC, BLAH being an
exception I don't like. Thankfully, it's rarely necessary.)
> He'll have to memorize any special verbs the designer chooses to
> implement.
Which usually have the same syntax. But now we're talking about
specific details of specific games, rather than the instructions
you need to memorise in order to play an IF game.
> He'll have to memorize the layout of the map
You don't need to memorise the layout of the map in order to
play a game. You might have to do so in order to play the game
*successfully*, but that's a different issue.
Oh, and he'll have to memorize any special
> keywords the game uses, like the names of the npcs or unique vocabulary
> items
The same goes for almost any work of fiction.
> > >Products with easy to use interfaces are going to enjoy more success
> than ones that don't have them. It's why cars with automatic
> transmissions sell better than cars with manual ones.
>
> >Not where I come from."
>
> Yeah, I read that it's like that in Europe. Here in States, where
> people do a lot more driving, an automatic is the way to go.
It's probably more to do with urbanisation, tradition and fuel prices.
Anyway, my point was not some US vs Europe comparison, but that
different communities will have different expectations about what
interface is more convenient. In the 70s and 80s, command lines were
the standard interface for most computer systems, so it wasn't
off-putting to see a command line interface in a game. Many people
who started computing in this time still prefer them. Many others
see definite advantages in command lines.
> I don't see my efforts to improve the interface of I-F as catering to
> slackers. I like to imagine my players as unexpected guests who took
> time out of their busy schedules just so they could visit me and listen
> to what I have to say. I see myself welcoming them into my home,
> offering them something to eat or drink, showing them a comfortable
> chair to sit in. I see myself looking them in the eye and saying, "I'm
> going to tell you a story and you're going to help me and we're going
> to have a really good time doing it." And when it's time for them to
> leave, they're going to shake my hand and say, "I had a lot of fun.
> I'll stop by again sometime."
How nice for them. I'd rather make my players physically sick, lose
a night's sleep, and burn all their possessions in the morning.
Stephen.
fiziwig
it... well... we'd furfill our dream. >>
I think it has to do with success, rewards, and payoffs. When my son
was a Cub Scout and I volunteered to be a den leader, one of the key
things I discovered about keeping a bunch of boys interested and
motivated was to set task for them that they were capable of
completing, and then be sure that the rewards for completion followed
promptly. If the task frustrated them they would lose interest. If they
completed the task but there was no reward, no merit badge, to little
gold star presented with much pomp and ceremony, they also lost
interest.
Take a combat-style FPS, for example. The first itme I played the
original Unreal I walked into the first cave and got blown up by a
giant monster shooting rockets at me. I didn't need any instructions to
inform me that I had to learn how to dodge those rockets, and I didn't
need to struggle with verbs and adjectives to figure out HOW to dodge
those rockets. The next time into the cave I danced around those
rockets and blasted away with my puny little pistol until that monster
came crashing down. That was a big reward for accomplishing a task that
was not frustrating because, first, it was obvious what needed to be
done, and second, it was obvious how to accomplish it. Granted, that's
a motor skill, not a thoughtful application of deductive logic, but
even working a crossword or a Sudoku gives me the same immediate sense
of satisfaction upon completing a task.
My experience with IF, and I have to admit, my IF experience is very
limited, (having played probably no more than two dozen games in my
life) is that the rewards are very small, and follow very long,
protracted guessing games which, by themselves, are not much fun at
all. Yet I keep coming back to IF. Every few years I pick it up again
and try it. NOT because I enjoy it, but because I WANT TO enjoy it;
because I think I OUGHT TO enjoy it. The concept is intriguing and it
just sounds like it should be a lot of fun. But then I play for a few
weeks or a month and then set it aside for another couple of years
until I've forgotten that it's not as much fun as it seems like it
ought to be.
On the other hand, For anyone familiar with Flying Buffalo Publications
"Solo Dungeon Adventure games", these are books based around a
paper-and-pencil-and-dice combat system called "Tunnels and Trolls".
These books have pretty thin story lines, but are not simple CYOAs.
Instead, you take your player character into one of these adventure
books and encounter puzzles, mazes and treasure just like IF, but also
monsters to fight. And if your PC survives the encounter with a
particular book then your PC is often rewarded with nifty special
weapons or magic spells. But these are not merely symbolic because,
(and THIS makes a huge difference), your PC can take those nifty new
weapons and spells along when you pick up the next new adventure book.
The uniform combat system makes their use possible in any adventure
book written under that system.
Maybe my own personal problem with IF is that I would rather it worked
like that. I would rather it were "CRIF" (Combat-Ready Interactive
Fiction) or maybe "SPICE" (Single Player Interactive Combat
Environment.) I think that being a D&D player since that game was just
a few pamphlets back in the 70's, I've come to expect more sustained
excitement than IF can reasonably offer. Perhaps I simply don't belong
here. Perhaps I belong writing a good combat-enabled IF
interpretor/compiler and puting out my own brand of fast-action
text-based fantasy shooters.
--gary
Rubes
>but they are finitely enumerable; and a few thousand actions is
>not very many, far fewer than in a typical 3D game, and far fewer
>again than in real life.
I'm curious about this. One of the things I've felt about 3D games is
that the actions allowed are so incredibly limited, much more so that
text games. Perhaps I'm just misunderstanding you, but what are all of
these actions allowed in 3D games?
Stephen Bond
> My experience with IF, and I have to admit, my IF experience is very
> limited, (having played probably no more than two dozen games in my
> life) is that the rewards are very small, and follow very long,
> protracted guessing games which, by themselves, are not much fun at
> all.
Which games have you tried?
> Yet I keep coming back to IF. Every few years I pick it up again
> and try it. NOT because I enjoy it, but because I WANT TO enjoy it;
> because I think I OUGHT TO enjoy it. The concept is intriguing and it
> just sounds like it should be a lot of fun. But then I play for a few
> weeks or a month and then set it aside for another couple of years
> until I've forgotten that it's not as much fun as it seems like it
> ought to be.
I had a similar on-off relationship with IF for a few years (and came
from a similar CYOA 'background'). I kept wanting to enjoy the medium,
but kept running into games with poor parsers, poor design, poor
writing, hackneyed settings, etc. All the time I believed the medium
was capable of something, but it wasn't until I happened across
_Photopia_ and some other games in mid-2000 that I realised exactly
what.
It doesn't sound like what attracts you to CYOA is what attracted me,
so I'm not sure this particular testimonial is going to be of much use.
But it's possible that what you dislike about the IF you've tried --
which seems to be mostly the parser difficulties -- can be
accounted for by a poor choice of game (or, if you like, a choice of
poor games). If you tell us what you've played, maybe we can help
point you in more promising directions.
Stephen.
J. Robinson Wheeler
> fiziwig wrote:
> > At the VERY least, any items mentioned in the description should
> > be examinable. We tend to be forgiving, if not completely blind
> > to shortcomings like that, because we're so used to it.
>
> Are we? I imagine we're *more* forgiving of lapses than a newcomer,
> but the idea that "unimplemented scenery is bad" has been accepted
> wisdom for as long as I've been on this newsgroup. When a game is
> particularly bad at implementing objects, everyone says so in
> reviews and comments. So it's not like we're unaware of the issue.
I agree, but this also reminds me of something that's a slight
tangent. The raised standards of scenery implementation is one of
the things that makes writing a large-scale game quite a chore,
and take forever to do. When writing a Comp-sized game, it's not
all that bad to write scenery objects for everything you describe,
even to several levels of grain (I seem to recall Metamorphoses
going to three levels of examination depth, or something scary
like that).
Having to do that same level of detail in a game that has dozens
and dozens of locations gets to be kind of punishing on a single
author. I recently played Jigsaw, and was astonished at how little
scenery was implemented, much as I am with Infocom games. But
then I thought about how much work it would have been to fill all
of that up with scenery, and I understood a little better.
Yet this is basically what I'm trying to do with the various
large-scale projects I'm working on. It's just that it's making
it take four or five years to do these things at a minimum,
instead of six months to a year.
--
J. Robinson Wheeler Games: http://raddial.com/if/
JRW Digital Media Movie: http://thekroneexperiment.com/dvd/
Stephen Bond
Firing weapon w at time t at position {x,y,z} while facing in direction
{a,b,c} and moving at velocity {d,e,f} is not the same action as firing
weapon w at time t at position {x,y,z} while facing in direction
{a,b,c} and moving at velocity {d,e,f+1}. (And that's not even
considering the state of NPCs and other objects in the world).
There is a vast, multi-dimensional space of possible actions in
most 3D games. Granted, many of these are very similar, but they're
not identical, and this is essential for creating a feeling of realism.
(Otherwise the game would be like hopping between a few thousand
static waypoints.) It's extremely unlikely that any two plays of a
3D game will be exactly the same.
I think this vast space of actions, which no player can be fully aware
of, offers much more potential for surprising insights and discoveries
about the game world. I also agree that few game designers take
advantage of this, and that most 3D games are pretty dull and
formulaic affairs. One of the many reasons I've given up on new
games.
Stephen.
Dan Shiovitz
It might be useful here to distinguish between "kinds of actions" and
"actual actions" or something. Like, imagine a game where the board is
a 100x100 grid, and the every turn you decide on a grid square to
teleport to. There are thousands of actual actions you can take
(teleport to 0,0; teleport to 0,1; teleport to 0,2; ...) but only one
kind of action (teleport to a square).
Now, having said that, what tends to happen in practice is kinds of
actions get built out of smaller actual actions. In go, for instance,
the only atomic kind of action you can do is "place a stone" (or pass,
I guess), but most players think of the game in terms of multi-turn
conceptual actions, of which there are many kinds: "capture a
particular piece of territory", "protect a group of stones", "prevent
the opponent from advancing past a line", etc.
My experience is that games that have good support for building
higher-level kinds of actions tend to be more satisfying; they're
easy to start playing but continue to provide strategic depth for a
long time.
--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW
Dan Shiovitz
J. Robinson Wheeler <j...@jrwdigitalmedia.com> wrote:
[..]
>I agree, but this also reminds me of something that's a slight
>tangent. The raised standards of scenery implementation is one of
>the things that makes writing a large-scale game quite a chore,
>and take forever to do. When writing a Comp-sized game, it's not
>Having to do that same level of detail in a game that has dozens
>and dozens of locations gets to be kind of punishing on a single
>author. I recently played Jigsaw, and was astonished at how little
>scenery was implemented, much as I am with Infocom games. But
>then I thought about how much work it would have been to fill all
>of that up with scenery, and I understood a little better.
It's my impression that Narcolepsy was specifically designed as a
response to this trend in IF. I think on the whole it wasn't that
well-received, but it does show some techniques for designing a game
that doesn't implement a lot of scenery, and might be worth looking at
more if this is something one is interested in.
>J. Robinson Wheeler Games: http://raddial.com/if/
Rubes
Stephen Bond wrote:
> I think this vast space of actions, which no player can be fully aware
> of, offers much more potential for surprising insights and discoveries
> about the game world. I also agree that few game designers take
> advantage of this, and that most 3D games are pretty dull and
> formulaic affairs. One of the many reasons I've given up on new
> games.
Ah, I gotcha, and that does make sense. One question then, do you think
it would be interesting to see a 3D game that also incorporates a text
parser?
fiziwig
point you in more promising directions. >>
I played "Advent" (Colossal Cave) on the time sharing system at the
university back in the 70's, then tried Deadline back when it was first
released on the Apple II. I was not able to complete either one. In
fact I recall getting no further than the first few rooms in Deadline
before stalling completely, yet my wife breezed through it in a few
days.
More recently, I tried again in 2002 with a lot of the IFComp games,
and tried games that were getting good reviews. Mostly I was not very
succeessful with any of them. Photopia stumped me completely, and I did
nothing but wander fruitlessly from building to building in Perdition's
Flames.
Then I wrote a game in TADS (http://fiziwig.com/intfic/index.html) for
the "2002 IF Library Annual Interactive Fiction Competition." which
took second place. Writing a game was a lot more fun that playing one,
but I got a lot of the same complaints from other players that I had
myself about the games that I had played, so I began to think the
problem of frstration and lack of direction were just something
inherent in the genre, and perhaps couldn't be solved.
This time around, I drifted back in a few weeks ago to see what was
happening and the first game I saw mentioned here was "The Sugared
Pill" so I downloaded it and gave it a try. After several days I got as
far as burning the gunman and pacing up and down the street,
occasionally getting into the car and trying, without success, to drive
anywhere. (Why doesn't "Drive home" do something sensible?") I've
examined every object mentioned in the descriptions, looked under,
behind, on top of, inside, every object mentioned. Found only an iron
bar that can't be used to smash anything or pry anything, and just
genrally decided that nothing else is possible from this point. And yet
other players seem to have made forward progress on the game. It must
be ME that is deficient. Perhaps, and I've reached this unfortunate
conclusion on many other occasions over the years, I simply don't have
whatever mental skill set is necessary to play IF successfully. And if
that's the case, then I should stop punishing myself and just not play
IF.
Either that, or start authoring my own style of action-based first
person shooter text adventure games. I know I'd like that. I LOVE
writing compilers. :-)
--gary
fiziwig
me again.
In "The Sugared Pill" I get in the car and try to drive but I am not
allowed to drive anywhere. The question I want to ask of the game is
"Why am I not allowed to drive anywhere?" If the game, any game,
forbids me from doing a particular thing then there MUST BE A REASON
for that prohibition, and the player MUST BE TOLD that reason.
In a first person 3D shooter If I try to jump to the top of three-story
building the reason I can't do that is obvious; gravity. If I try to
shoot a monster when I'm out of ammo the reason I can't shoot it
obvious. But in IF I am too often forbidden to do things and not given
any reason whatsoever for why I can't do what seems like a perfectly
reeasonable thing to do.
In real life I get into a car that has the engine running and I can
drive wherever I want to drive, including driving home. If the game
forbids me from driving ANYWHERE then it better tell me that the tires
are flat or I just ran out of gas, or give me some reason WHY. Then, at
least, I have some sub-goal to work towards like fixing the flat or
finding gas. But when no reason whatsoever is given for why an action
is forbidden then it's just very frustrating.
--gary
Stephen Bond
> Ah, I gotcha, and that does make sense. One question then, do you think
> it would be interesting to see a 3D game that also incorporates a text
> parser?
Hmmm... what would the text parser be for? I don't think it would
be very interesting to type >GO NORTH and then watch an
animation of a 3D character going north; in that case I would
rather do without the graphics. Perhaps a text parser could
be used to handle some complex commands... but I can't
think of any case in which that wouldn't be better handled by
some other interface. In an immersive 3D world, I'd rather *do*
things than type about doing them, if you see what I mean.
The only useful place I can imagine for a text parser in a 3D
game is in natural language NPC communication. But that
would have to be a very good text parser!
Stephen.
Mark Thern
> want the audience for I-F to grow. To do that, I have to design my game
> to meet the needs of new players.
>So then not every piece of IF should assume that its users are new.
>Only the ones designed to meet the needs of new players.
That's close, but not quite it. Let's put it like this instead: Any I-F
author who wants his work to be enjoyed by as large an audience as
possible should design their game to meet the needs of new players. If
the author's artistic goals are best served by a command line
interface or if he's simply not interested in taking the time to make
his game user-friendly, then he should go ahead with using a
traditional parser. He'll just have to accept a smaller audience for
his work as a consequence.
>In practice, the parser is usually not good enough to handle all such commands sensibly, I admit, but in theory the syntax is very simple. (>NPC, BLAH being an exception I don't like. Thankfully, it's rarely necessary.)
The "not good enough" part is one of the things that bothers me
about parsers. I don't like having to rephrase commands until I arrive
at a phrasing that the parser understands. I might only have to do it
once or twice for a given command, but it's an irritant that diminishes
my enjoyment of the game, however slightly, and it adds up over time.
> He'll have to memorize any special verbs the designer chooses to
> implement.
>Which usually have the same syntax. But now we're talking about specific details of specific games, rather than the instructions you need to memorize in order to play an IF game.
I don't see your point. If I'm a first time player and I'm playing
Sting of the Wasp, I can't beat the game unless I read the
instructions and find out that I'll need to use the Blackmail verb,
which is a command I probably wouldn't have thought to use without the
manual telling me. It's only applicable for this particular game, but
this is the only game I've ever played. Doesn't that make it an extra
instruction to memorize?
>You don't need to memorize the layout of the map in order to play a game. You might have to do so in order to play the game *successfully*, but that's a different issue.
I guess so. It's an annoyance all the same, and I almost always have to
draw a map when I'm playing I-F. A Tads 3 game can display all the
exits to a room in the Status line. That's a nice feature, but I'd take
it further. Instead of displaying the exits like this:
Kitchen Exits: North South
I'd show it like this:
Kitchen Exits: North:??? South:???
And after the player goes North and then returns back to the Kitchen:
Kitchen Exits: North: Dining Room South:???
It's not a perfect solution-- an automap would be better-- but it would
certainly help and it shouldn't be all that hard to implement.
>Oh, and he'll have to memorize any special keywords the game uses, like the names of the npcs or unique vocabulary items
>The same goes for almost any work of fiction.
The difference is that if the reader of a mystery novel forgets that
the murder victim had a mistress named Gloria, the novel will remind
him about it later when the detective asks a suspect about her. In an
I-F version of the same situation, the player is the detective and if
he can't remember Gloria's name, he's probably stuck. A trip to Hints
will probably remedy the situation, but that will make him feel a
little stupid and possibly tell him more about the puzzle than he
wanted to know. "Aww man, I could have figured it out if I had only
remembered her name!" I'll say it again: Players are busy people, and
I'm not going to penalize them if they can't play my game every day.
I always keep notes when I play I-F, and I wish I didn't have to. City
of Secrets has a Who command that tells the player who they've met and
what their relationship is with them so far. I really appreciated that
feature, and I wish she had implemented a similiar one that kept track
of keywords like "the Illuminated".
>In the 70s and 80s, command lines were the standard interface for most computer systems, so it wasn't off-putting to see a command line interface in a game. Many people
who started computing in this time still prefer them. Many others see
definite advantages in command lines.
I think a command line can sometimes be the best choice of interface
for a game. I don't think the Mulldoon Legacy, which has 92 different
verbs, would work well in a GUI, even if you could somehow categorize
the verbs. In contrast, I think a low verb game like Sting of the Wasp
could use a point and click system without really losing anything
except a lot of inconvenience.
I think it's pretty clear to anyone reading my posts that I don't like
the command line. I tolerate it because "smart" interactivity
(versus "dumb" interactivity like hyperfiction, which isn't
stateful as far as I know) offers me experiences that I can't get from
any other type of storytelling medium. I think a GUI I-F could offer
equally enjoyable experiences, but without the tedium, and it would be
much more accessible to newcomers because they could leverage all the
experience they have with using GUI interfaces when it comes to
learning how to play and remembering how to do it later. The design
challenges in making such a game would be different from traditional
I-F, but that's a subject for a later post.
>And when it's time for them to leave, they're going to shake my hand
and say, "I had a lot of fun. I'll stop by again sometime."
>How nice for them. I'd rather make my players physically sick, lose a night's sleep, and burn all their possessions in the morning.
Umm, each to his own. Note to self: Perhaps it would be unwise to drop
by Stephen's house for a visit :)
samwyse
NetHack!
(And yes, I intentionally didn't quote any of the preceeding thread.)
Stephen Bond
> >So then not every piece of IF should assume that its users are new.
> >Only the ones designed to meet the needs of new players.
>
> That's close, but not quite it. Let's put it like this instead: Any I-F
> author who wants his work to be enjoyed by as large an audience as
> possible should design their game to meet the needs of new players.
That's the thing -- I'm not usually interested in reaching as large
an audience as possible (otherwise I wouldn't be writing IF), but
the 'right' audience. Whatever the right audience may be.
> I don't see your point. If I'm a first time player and I'm playing
> Sting of the Wasp, I can't beat the game unless I read the
> instructions and find out that I'll need to use the Blackmail verb,
> which is a command I probably wouldn't have thought to use without the
> manual telling me. It's only applicable for this particular game, but
> this is the only game I've ever played. Doesn't that make it an extra
> instruction to memorize?
I thought we were talking about the things you need to learn to play
IF in general, not specific IF games. But fair enough.
> The difference is that if the reader of a mystery novel forgets that
> the murder victim had a mistress named Gloria, the novel will remind
> him about it later when the detective asks a suspect about her. In an
> I-F version of the same situation, the player is the detective and if
> he can't remember Gloria's name, he's probably stuck.
Well, there is the scrollback feature on some interpreters, which
could help if the name was mentioned since the game was
started (though I suppose that's another instruction to learn).
In any case, this strikes me as another "playing" vs. "playing well"
distinction.
> >How nice for them. I'd rather make my players physically sick, lose a night's sleep, and burn all their possessions in the morning.
>
> Umm, each to his own. Note to self: Perhaps it would be unwise to drop
> by Stephen's house for a visit :)
:) Oh, I can assure you I'm quite charming in person.
Stephen.
Stephen Bond
I don't like NetHack. Your point is?
Stephen.
samwyse
> I don't see your point. If I'm a first time player and I'm playing
> Sting of the Wasp, I can't beat the game unless I read the
> instructions and find out that I'll need to use the Blackmail verb,
> which is a command I probably wouldn't have thought to use without the
> manual telling me. It's only applicable for this particular game, but
> this is the only game I've ever played. Doesn't that make it an extra
> instruction to memorize?
I haven't played this game, but I'd hope that at some point, the player
was instructed in the BLACKMAIL command. How to do that within the
game is challenging, but certainly possible. Have lots of NPCs drop
hints, like "Are you trying to blackmail me?" or "I bet if you
blackmailed that guy, he'd help us out." Eventually, the player will
try BLACKMAIL BOB, and get a response other than "Huh?", which should
be all the clue that you need that eventually you'll need the command
elsewhere.
(I'm reminded of Adventure, where the very first time I played, I tried
to use the black rod in a particular way, which didn't work. The
message made it clear that the verb I was using would never work with
the rod, and over the next few days I put it out of my mind. Many
weeks later, I was stuck in the endgame. Eventually, I cracked open
the FORTRAN source code and discovered that the key to winning was the
verb that I'd forgotten about. I was angry, but at myself, not the
game.)
Rubes
Stephen Bond wrote:
> Hmmm... what would the text parser be for? I don't think it would
> be very interesting to type >GO NORTH and then watch an
> animation of a 3D character going north; in that case I would
> rather do without the graphics. Perhaps a text parser could
> be used to handle some complex commands... but I can't
> think of any case in which that wouldn't be better handled by
> some other interface. In an immersive 3D world, I'd rather *do*
> things than type about doing them, if you see what I mean.
>
> The only useful place I can imagine for a text parser in a 3D
> game is in natural language NPC communication. But that
> would have to be a very good text parser!
Well, naturally you wouldn't need the parser to perform actions like
movement that are already handled by the 3D engine. The problem that I
see with most 3D games is that there isn't a great deal of variety in
the actions a player can perform. Most are handled by a single "action"
key, mostly because it would be hard to implement the actual "doing" of
more complicated actions. How would you actually *do* those more
complex actions?
As for interactions with NPCs, the best I've seen in a 3D game involves
menu-driven conversation, which I personally don't like; otherwise,
it's usually just using the "action" key to trigger conversation, which
is generally unidirectional. Perhaps with a parser, the ASK/TELL system
could be implemented, offering at least some variety.
Emily Short
Dan Shiovitz wrote:
> In article <1137004902.1...@g47g2000cwa.googlegroups.com>,
> J. Robinson Wheeler <j...@jrwdigitalmedia.com> wrote:
> [..]
> >I agree, but this also reminds me of something that's a slight
> >tangent. The raised standards of scenery implementation is one of
> >the things that makes writing a large-scale game quite a chore,
> >and take forever to do. When writing a Comp-sized game, it's not
> [..]
> >Having to do that same level of detail in a game that has dozens
> >and dozens of locations gets to be kind of punishing on a single
> >author. I recently played Jigsaw, and was astonished at how little
> >scenery was implemented, much as I am with Infocom games. But
> >then I thought about how much work it would have been to fill all
> >of that up with scenery, and I understood a little better.
>
> It's my impression that Narcolepsy was specifically designed as a
Another place to look is Nick Montfort's "Book and Volume", which
responds to quite a lot of scenery with a comment like "That's an
ordinary [whatever]." While I found this irritating on a few occasions,
it nonetheless felt like better implementation than having "You don't
see any such thing", and because the response was customized it also
didn't seem as lazy as "You see nothing special about the [whatever]."
I think the key to making the player accept a shallower depth of
implementation, though, is to provide a lot of guidance about what he
*is* supposed to be looking at, either by providing strong plot
motivation or offering some sort of redirection clue. "The [whatever]
doesn't hold your attention, considering that there's an untamed lion
in the room." When I have something specific to do (as when carrying
out one of the tasks in Book and Volume, or following the plot of Being
Andrew Plotkin, or whatever), I'm less likely to spend time examining
every piece of random scenery. I got more exasperated with the
minimalism of Narcolepsy because I was so often stuck, unable to make
the game progress, and the scantness of the descriptions gave me little
to go on.
Nathan
> Any I-F author who wants his work to be enjoyed by as large an
> audience as possible should design their game to meet the
> needs of new players.
I don't think IF authors want their work to be enjoyed by
"as large an audience as possible", if that means producing
something that isn't IF.
> If the author's artistic goals are best served by a command line
> interface or if he's simply not interested in taking the time to make
> his game user-friendly, then he should go ahead with using a
> traditional parser. He'll just have to accept a smaller audience for
> his work as a consequence.
If an author is simply not interested in taking the time to make
his game user-friendly, he deserves the consequences.
However, IF == "traditional parser" ~= "non-user-friendly".
I interpret what you're saying as, "Most people don't like
IF, so people should only make other kinds of games."
> If I'm a first time player and I'm playing Sting of the Wasp,
> I can't beat the game unless I read the instructions and find out
> that I'll need to use the Blackmail verb, which is a command I
> probably wouldn't have thought to use without the manual telling
> me.
If you're a first time player, why in the world wouldn't you read
the instructions and find this out?
> I always keep notes when I play I-F, and I wish I didn't have to.
I wish I were better at remembering things in real life.
> I think a command line can sometimes be the best choice of interface
> for a game.
I think you're contradicting yourself.
> I don't think the Mulldoon Legacy, which has 92 different
> verbs, would work well in a GUI, even if you could somehow categorize
> the verbs.
So you find the Mulldoon Legacy "non-user-friendly", but don't
think it would work well if it were "user-friendly"?
> In contrast, I think a low verb game like Sting of the Wasp
> could use a point and click system without really losing anything
> except a lot of inconvenience.
I disagree; it would lose very much.
> I think it's pretty clear to anyone reading my posts that I don't like
> the command line. I tolerate it because "smart" interactivity
> (versus "dumb" interactivity like hyperfiction, which isn't
> stateful as far as I know) offers me experiences that I can't get from
> any other type of storytelling medium. I think a GUI I-F could offer
> equally enjoyable experiences, but without the tedium, and it would be
> much more accessible to newcomers because they could leverage all the
> experience they have with using GUI interfaces when it comes to
> learning how to play and remembering how to do it later.
GUl adventure games really do exist, you know.
They're not "much more accessible to newcomers", and
they certainly aren't "without the tedium" in general.
The best graphical adventures aren't nearly as well-written
as the best IF.
IF is already very accessible to newcomers because you can leverage
all the experience they have with using command-line interfaces
and written language when it comes to learning how to play and
Mark J. Tilford
>
>
> "Stephen Bond" <steph...@ireland.com> wrote:
>> or interface design. [...] The shortcomings of the games have a
>> lot to do with the interface, which tells you what objects can be
>> used, tells you what the objects are, and tells you all the possible
>> ways in which you can use them. This places pretty drastic limits
>> on the number of possible actions, and at any one time the player
>> can be aware of them all, making the game world seem artificial.
>
> inspired bit of game-play that I recall from the several LA adventures I've
> played is the Sword Master puzzle in Monkey Island, and that was an even
> more constrained UI than normal for LA games - every choice was enumerated,
> but even so, the puzzle wasn't readily solvable with trial and error because
> its combinatorics created a search space large enough to be inconvenient to
> search exhaustively. In the second place, a recurring element of LA puzzle
> design was "USE X WITH Y", where X and Y were inventory items. This created
> an N^2 search space if you wanted to brute-force it, and most of those games
> chose N such that the space was inconveniently large - MI2 had about 40 or
> 50 inventory items by the end of the game, as I recall.
>
> It's a pernicious fallacy around here that an enumerated range of inputs
> creates a brute-force-able search space. If the inputs are limited to a
> linear list with no combinability, then, yes, the search space is small.
> But as soon as there's a way to combine inputs (as in USE X WITH Y), the
> search space expands greatly, and it's easy to get it up to an effectively
> infinite size even with a small number of basic input elements.
>
> I could even use a CYOA interface to create a puzzle that you couldn't solve
> by brute force - not by using combinable inputs in the UI per se, but by
> using state. Example:
>
> [transcript]
> You are standing before a steel door. A small keypad is next to the
> door, with buttons numbered from 1 to 3. A display above the
> keypad is blank.
>
> Would you like to...
> 1. Push the '1' button
> 2. Push the '2' button
> 3. Push the '3' button
>>1
>
> You push the '1' button. The display now reads '1'.
> Would you like to...
> [end transcript]
>
> If the combination is 10 digits long or so, solving by brute-force
> exhaustive search is not viable.
>
> My point is that unboundedness is not a unique feature of the command-line
> UI. The command-line UI has certain virtues, but being uniquely unbounded
> is not one of them.
>
I ended up working the combination lock in John's Fire Witch by brute
force; 3^10 isn't that many more cases.
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
Andrew Plotkin
able to comment on all of it. However...
Here, Mike Roberts <mj...@hotmail.com> wrote:
> It's a pernicious fallacy around here that an enumerated range of inputs
> creates a brute-force-able search space. If the inputs are limited to a
> linear list with no combinability, then, yes, the search space is small.
> But as soon as there's a way to combine inputs (as in USE X WITH Y), the
> search space expands greatly, and it's easy to get it up to an effectively
> infinite size even with a small number of basic input elements.
...this is *my* pernicious fallacy, or at least I purvey it
frequently, so I should reply to this at least. (I haven't read ahead
in the thread, so I'm probably repeating people. Sorry.)
I haven't played the Monkey Island games, but I've played a reasonable
selection of the games that grew out of that interface, including Grim
Fandango and The Longest Journey. They are my standard examples of the
"enumerated range of inputs".
So, first, I don't think of them as *equivalent* to a typical CYOA
game. They have state, they have more than three or four inputs per
scene. They have combinable commands.
What they *don't* do is actually *combine* the axes of control in an
interesting way. Yes, you can use any of N inventory items on any of M
scenery objects. But nearly always, I find that there's *either*
exactly one inventory item in play, or exactly one scenery object. So
despite *theoretical* M-times-N commands available to me, I actually
only have to try N, or M.
"But that's the same as IF!" Certainly it *can* be. I've played
text-parser games where I wound up going through and shooting every
noun with the transmoggifier gun, because I had nothing else to do.
But even then, the text-parser environment provides me with a *fuzzy*
list of N things to do. It's got a lot of front-and-center game
objects, a bunch of things that are clearly scenery... and maybe a few
that are on the borderline, plus a few more that I haven't realized
are important and therefore haven't interacted with at all. (But I
*would* realize they were important, if I put myself in the
protagonist's shoes!)
And the "known" axis (the command that I think I know -- the "1" in
the 1-times-N enumeration) is fuzzy too. Maybe I'm using the gun
wrong, and examining it in detail will reveal that. The text parser is
an excellent tool for making this be *realizable by the player*. The
menu is not. Menus are flat.
> I could even use a CYOA interface to create a puzzle that you
> couldn't solve by brute force - not by using combinable inputs in
> the UI per se, but by using state.
Sure. And then you'd have a puzzle that could only be bruted-forced by
a machine -- which is *even less* interactive than a puzzle which can
be bruted-forced by a human.
> My point is that unboundedness is not a unique feature of the command-line
> UI. The command-line UI has certain virtues, but being uniquely unbounded
> is not one of them.
I am not touting unboundedness as the definition of interactive
fiction. (If I were, the archetypical IF puzzle would be guessing
a twelve-digit combination lock.) An undifferentiated, non-enumerable
axis of control is just as antithetical to IF as a three-choice menu.
The definition of IF is -- if you'll forgive the use of a different
80's geek fad -- a fractal dimensionality, neither finite nor the real
number line.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
"Bush has kept America safe from terrorism since 9/11." Too bad his
job was to keep America safe *on* 9/11.
Mike Roberts
> Here, Mike Roberts <mj...@hotmail.com> wrote:
>> It's a pernicious fallacy around here that an enumerated range
>> of inputs creates a brute-force-able search space.
>
> frequently, so I should reply to this at least.
Well, a lot of people here make this argument, or more typically argue from
this assumption.
> I haven't played the Monkey Island games, but I've played a
> reasonable selection of the games that grew out of that interface,
> including Grim Fandango and The Longest Journey. They are
> my standard examples of the "enumerated range of inputs".
In that case you might want to try, say, MI2 some time. Because...
> Yes, you can use any of N inventory items on any of M scenery
> objects. But nearly always, I find that there's *either* exactly
> one inventory item in play, or exactly one scenery object.
...this actually isn't typical of the earlier games, so perhaps your
impressions about the subjective player experience are impressions of one
particular subset of this kind of interface rather than general impressions
of the full range of this kind of interface. The earlier LA games (Monkey
Island 1 and 2, the first couple of Indiana Jones games, possibly Sam & Max
but I don't recall for sure) were rather old-school inventory-based
adventures. MI2 in particular had an almost comically large inventory; in
fact, it might have been intentionally comic in its largeness. These games
had a moderate number of verbs (nine) and a large number of objects. One of
the verbs, USE, effectively turned many inventory items into additional
verbs (USE HAMMER ON x, USE CROWBAR ON x, etc). USE X WITH Y was used at
times to combine inventory items into a new inventory item.
The bottom line is that there were enough active combinations at any given
time that exhaustive search would not be at all attractive as a strategy,
even when really stuck. That's my subjective experience with these sorts of
games, anyway.
I think commercial adventure game designers at some point got together at a
CGDC or something and decided among themselves that the reason people
weren't buying adventure games (the graphical kind, I mean) had something to
do with the games being too hard, and that the chief virtue in adventure
game design is making it really easy. Or maybe they were just all awed by
Myst's numbers, and decided that what made Myst so great was the minimal UI.
In any case, the interfaces gradually lost expressive power and the later
games took on the character you're talking about.
>> I could even use a CYOA interface to create a puzzle that you
>> couldn't solve by brute force - not by using combinable inputs in
>> the UI per se, but by using state.
>
> Sure. And then you'd have a puzzle that could only be bruted-forced
> by a machine -- which is *even less* interactive than a puzzle which
> can be bruted-forced by a human.
I don't follow your argument here - if difficulty of brute-forcing is bad,
then text IF is surely the worst of all because it has such a huge input
space. My point about the CYOA wasn't that the puzzle *ought* to be solved
by brute force - just the opposite. My point was that it's possible even
with as limited an input space as a CYOA to construct a puzzle that *can't*
be solved by brute force and thus must be solved by reasoning from clues.
Which is the virtue underlying all the goodness you see in the command-line
UI - the requirement and possibility for the player to come up with the
answer on his own rather than select it from a list.
Mark Thern
I think one of the biggest differences in our points of view is that we
want very different things from the I-F games that we play. I play I-F
because I like interacting with npcs, solving knowledge puzzles,
experiencing branching storylines, and the feeling of identification
that I only get from good I-F, the sense that of really becoming a
different person for awhile. Everything else to me is a mild amusement
at best to an outright irritant at worst. I'm not especially interested
in puzzles that revolve around items; I might refer to the Muldoon
Legacy, but I've never played it beyond reading the manual. I don't
enjoy memorizing map layouts. And I dislike the parser because it hides
choices from me, which forces me to indulge in some very repetitive
gameplay if I want to play the game effectively. In a graphical
adventure, you can sweep over the items in a room and figure out which
ones are important and which ones are just decoration. In traditional
I-F, I have no idea what might be important, so I have to examine and
manipulate each item. Likewise, I have to test every possible keyword
on an npc to see which ones will be effective. I enjoy the lateral
thinking aspects of I-F puzzles, but this part of the process doesn't
take any real skill other than being able to identify nouns in the
output text and maybe figuring out the appropriate verb. I think it's
the equivalent of pixel-hunting in graphical adventures.
Some folks love this discovery process. I imagine for these folks, the
negative responses only enhance the feeling of victory when they
finally get a productive response. For me, the reward is diminished by
all the work I had to do to achieve it. I'm not saying that I-F works
should be devoid of challenge --that would be like replacing those
complex wargames I mentioned earlier with copies of children's games
like CandyLand. However, I would like to see these challenges take a
wider variety of forms, and I want the challenge to serve the story.
The benefits of adding challenge to a story is that you're imbuing it
with the addictive qualities of a good game, which can turn merely
adequate prose into I-couldn't-put-it-down literature. I experience
this playing I-F all the time. And when you wed addicting gameplay to
really good prose... only the masters of static fiction can rival the
experience.
I don't enjoy games like the Muldoon Legacy, but that doesn't mean that
I think it shouldn't exist, or that people shouldn't continue to write
games like it. I just want games that provide me with more of the
things that I want and less of what I don't, and I think this happy
turn of events is most likely to happen if I-F authors start
experimenting with a GUI interface.
Now let's go to the other big difference in our points of view: the
responsibilities of the user in learning to use a program. We'll start
with two axioms that I don't think you'll disagree with:
1. Most users don't read manuals.
2. Most users don't find any intrinsic enjoyment in figuring out how a
program works; they're interested in the end rather than the means.
We each react to these facts in a different way. For you, if a user
isn't willing to take the time to read the manual and learn how a
program works, then it's not your problem if he can't use the software.
I choose to simply accept this fact and I'm trying to design my game to
accommodate these attitudes.
Why am I so willing to bend over backward for these folks? Three
reasons:
1. I want them as customers for my work. I'm actually foolish enough
to try my hand at producing commercial I-F. I probably won't succeed,
but if I do, I think the financial and artistic rewards could be higher
than if I devoted my efforts to producing static fiction.
All I'm willing to demand from my potential customers is that they must
like reading text on a computer screen and that they possess the
technical savvy to click on a hyperlink. They don't have to have any
tolerance for being stuck because the puzzles aren't designed that way,
much as they are in Shadows on the Mirror and Emily Short's Best of
Three.
2. I want to advance the state of the art in interactive stories. It
will progress much faster if I had the help of others in doing this, so
I want the audience of I-F to grow.
3. I like helping people, and I get a great deal of emotional
satisfaction by expressing this quality in my work.
I don't expect all authors of I-F to share my goals, but I'd like to
ask those who do to consider the merits of my proposals.
I'll address your other points in another post. We'll talk more
tomorrow.
Samwyse
Just that NetHack has a vast space of actions, which no player can be
fully aware of, and offers much potential for surprising insights and
Samwyse
> Just a postscript to my previous post. Something that just occured to
> me again.
>
> In "The Sugared Pill" I get in the car and try to drive but I am not
> allowed to drive anywhere. The question I want to ask of the game is
> "Why am I not allowed to drive anywhere?" If the game, any game,
> forbids me from doing a particular thing then there MUST BE A REASON
> for that prohibition, and the player MUST BE TOLD that reason.
Congratulations, you just discovered one of the more common complaints
about ordinary fiction, that the plot just doesn't make sense. If you
were reading a book about someone being chased and he kept passing cars
that were parked with their engines running, you'd pretty quickly give
up on that story, too. The Turkey City Lexicon (Google for it) would
label this as either Fuzz or Idiot Plot, and it's quite possibly both at
once.
I haven't played "The Sugared Pill" yet, so I don't know if this ia a
small failing or something typical of the work as a whole. I do know
that Sturgeon's Law states that 90% of *everything* is crap. That means
that 90% of IF is crap. Unfortunately, there's so little IF in
existance that you as a consumer can't avoid it. Only a few IF authors
have ever sold an ink-on-paper story, so I'm not surprised that most of
them commit mistakes that professional writers have learned to avoid.
It's taking me years to complete my first story; everytime I return to
it, I'm horrified by its clumsiness and have to rewrite major portions.
I think that many of the people here are trying to fight this. That's
why critical review is important. I try to post a link to the Lexicon
every so often, in the hopes that serious writers will read it and
recognize attributes of their own work. So far, I'm usually disappointed.
Unfortunately, there are damn few writer's workshops for IF. In their
absence, r.a.i-f tries to fill the void, but the signal-to-noise ratio
is fairly high; the biggest shortcoming is inability to enforce the rule
that "No one can attend or comment who does not bring a story." But I'm
not giving up; not yet anyway.
Stephen Bond
That's true. NetHack is a game I admire in theory, and indeed I keep
coming back to it every so often and wanting to enjoy it, but for some
reason I don't like playing it at all.
Stephen.
Stephen Bond
> Writing a game was a lot more fun that playing one,
> but I got a lot of the same complaints from other players that I had
> myself about the games that I had played, so I began to think the
> problem of frstration and lack of direction were just something
> inherent in the genre, and perhaps couldn't be solved.
A lot of games suffer from a lack of direction. You might want
to try _Babel_, _Spider and Web_, _Hunter, in Darkness_, or
_All Things Devours_, all of which I recall being more focused and
tightly-paced.
> Either that, or start authoring my own style of action-based first
> person shooter text adventure games. I know I'd like that. I LOVE
> writing compilers. :-)
Yes, if you don't see the kind of game you'd like, it's a good idea
to write it yourself.
Stephen.
David Goldfarb
Aaron A. Reed <aar...@gmail.com> wrote:
>I try to always implement USE as it would be used with various
>objects in my game. "USE GUN" should work just as well as "FIRE GUN,"
>and is arguably better, since I don't have to guess what variation on
>FIRE, SHOOT, PULL TRIGGER, etc. the author might have coded in.
I remember playing a very very early graphical adventure (well, really
a text adventure with illustrations) called _The Wizard and the Princess_.
It had only a two-word parser, so a lot of puzzle solutions were broken
up into two parts. E.g. (and this example is made-up)
>PLUG HOLE
What do you want to plug the hole with?
>WITH CORK
You put the cork into the hole. The flow of water stops.
...only, due to some quirk in the parser, the first half was actually
unnecessary. You could go straight to "WITH CORK". I spent a lot of
time at various puzzle locations typing "WITH [everything in my inventory]".
--
David Goldfarb |"English cuisine is the cuisine of fear."
gold...@ocf.berkeley.edu |
gold...@csua.berkeley.edu | -- Andrew Conway
Stephen Bond
> My point was that it's possible even
> with as limited an input space as a CYOA to construct a puzzle that *can't*
> be solved by brute force and thus must be solved by reasoning from clues.
> Which is the virtue underlying all the goodness you see in the command-line
> UI - the requirement and possibility for the player to come up with the
> answer on his own rather than select it from a list.
The virtue I see the command-line interface is not as simple as that.
It's all about engaging with the game world on a deeper level. I've
been rather vague and abstract about this earlier in the thread, so
now I'll give a specific example, which also happens to be a terrible
spoiler for _A Change in the Weather_.
(SPOILERS)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
In ACITW, there's a boulder on top of a hill that you have to push
to solve some part of the puzzle -- I can't remember why exactly,
but that's not important now. The thing is, >PUSH BOULDER
doesn't solve the puzzle -- in fact, I think it resulted in an instant
death. The real solution is >PUSH BOULDER SOUTH. When I first
saw this in the walkthrough, coming from an LA adventure
background, I thought it was terribly unfair. Surely if I know I have
to push the boulder somewhere, and >PUSH is the verb, and
BOULDER the object, then >PUSH BOULDER should do it all for
me. But now I believe I was wrong. >PUSH BOULDER is the solution
when you think about the game world as a puzzle, as a toy, with
the hilltop being room X, the boulder a piece that goes in the
right slot in room Y, and >PUSH the menu option that does that
for you. To make the >PUSH BOULDER SOUTH insight -- an
insight afforded by the command line -- you have to realise that
>PUSH is not just a verb but a force that you can apply in a
certain direction, the boulder is a great big rock with mass and
inertia, and that the hilltop is not a 'room' but a bare lonely
place on top of a hill with a surrounding topography. In other
words, you have to imagine the game world less as a
contrivance and more as a real place.
Note that this would not be the case if
PUSH <OBJECT> <DIRECTION> were a menu option.
Stephen.
Samwyse
> USE and TALK TO are, in my experience, very often used by new players
> who are then nonplussed when the game doesn't understand what they
> mean. I try to always implement USE as it would be used with various
> objects in my game. "USE GUN" should work just as well as "FIRE GUN,"
> and is arguably better, since I don't have to guess what variation on
> FIRE, SHOOT, PULL TRIGGER, etc. the author might have coded in.
I used to try to implement USE in this way, but have lately come to the
view that USE ITEM should instead provide an item-specific help. DM4
sketches out a simple implementation of USE:
Verb 'use' 'employ' 'utilise'
* edible -> Eat
* clothing -> Wear
...
* enterable -> Enter;
I've implemented that a few times, but now I'm leaning more toward this:
Verb 'use' 'employ' 'utilise'
* noun -> Use;
[ UseSub ;
if (noun provides usage) { PrintOrRun(noun.usage); rtrue; }
print "Perhaps you mean to say ";
if (noun has edible) "'eat'.";
if (noun has clothing) "'wear'.";
...
if (noun has enterable) "'enter'.";
"something more specific.";
];
> I have
> also implemented TALK TO in my games, since I feel it's a lot more
> intuitive than ASK ABOUT -- though the latter is still implemented for
> experienced players or players who read the instructions.
I'd be interested in how you do this. Are you using the TADS3
conversational system and having TALK TO activate the highest scoring
conversational topic, or what?
J. Robinson Wheeler
Dan Shiovitz wrote:
> J. Robinson Wheeler wrote:
> >The raised standards of scenery implementation is one of
> >the things that makes writing a large-scale game quite a chore,
> >and take forever to do.
> >Having to do that same level of detail in a game that has dozens
> >and dozens of locations gets to be kind of punishing on a single
> >author.
>
> response to this trend in IF. I think on the whole it wasn't that
> well-received, but it does show some techniques for designing a
> game that doesn't implement a lot of scenery, and might be worth
> looking at more if this is something one is interested in.
Well, yeah. I was originally going to mention Narcolepsy in
this post you responded to. The problem with that is that I
didn't like Narcolepsy's lack of scenery objects.
One of the reasons I hold myself to this standard as an
author is that I think like a player when I'm writing, and I
don't like missing scenery.
It still doesn't make it any easier to do.
--
J. Robinson Wheeler Games: http://raddial.com/if/
JRW Digital Media Movie: http://thekroneexperiment.com/dvd/
fiziwig
* noun -> Use;
[ UseSub ;
if (noun provides usage) { PrintOrRun(noun.usage); rtrue; }
print "Perhaps you mean to say ";
if (noun has edible) "'eat'.";
I think a better solution would look something like this:
> USE CARROT
You put the carrot in your ear. Nothing happens.
That gives the player the hint that he should perhaps be more specific
about how to use the carrot.
--gary
Greg Boettcher
> I am not touting unboundedness as the definition of interactive
> fiction. (If I were, the archetypical IF puzzle would be guessing
> a twelve-digit combination lock.) An undifferentiated, non-enumerable
> axis of control is just as antithetical to IF as a three-choice menu.
> The definition of IF is -- if you'll forgive the use of a different
> 80's geek fad -- a fractal dimensionality, neither finite nor the real
> number line.
Could you translate this for those of us who don't know much about
fractal mathematics? I'm asking because to me this sounds sort of like,
"Oh yeah, well, 'slithy toves.'"
> I haven't played the Monkey Island games, but I've played a reasonable
> selection of the games that grew out of that interface, including Grim
> Fandango and The Longest Journey. They are my standard examples of the
> "enumerated range of inputs".
>From what little I've played of GF and TLJ, I don't see that they have
much in common with Monkey Island except for their conversation
interface. That, and the fact that they all have a rather small,
enumerated list of actions you can perform, but this is true of most
any non-parser-based game. With Myst, the list of enumerated actions is
just "click," if I remember right.
I think Mike is talking about Monkey Island's list of 12 verbs, and the
way you clicked on them, and on the objects around you, to build
sentences. See also:
http://www.mobygames.com/game/dos/secret-of-monkey-island/screenshots/gameShotId,62808/
On the other hand, I don't see that you came to any wrong conclusions,
extrapolating from GF and TLJ.
Greg
Quintin Stone
> I think a better solution would look something like this:
>
> > USE CARROT
>
> You put the carrot in your ear. Nothing happens.
>
> That gives the player the hint that he should perhaps be more specific
> about how to use the carrot.
I implemented a USE verb in Scavenger at the request of a tester. Quite a
few objects have an obvious default verb associated with them (buttons are
pressed, doors are opened/closed). For everything else, it simply
responds "You'll have to be more specific how you want to use <<the
item>>."
It's not really something that an experienced IF player will try,
considering its absence in historical IF works. But you know, for players
coming from other types of games, it's very helpful and not that hard to
put into a game. At the very least, the "more specific" message indicates
that IF works a little differently from what they may be used to.
==--- --=--=-- ---==
Quintin Stone "You speak of necessary evil? One of those necessities
st...@rps.net is that if innocents must suffer, the guilty must suffer
www.rps.net more." - Mackenzie Calhoun, "Once Burned" by Peter David
Stephen Bond
> >From what little I've played of GF and TLJ, I don't see that they have
> much in common with Monkey Island except for their conversation
> interface. That, and the fact that they all have a rather small,
> enumerated list of actions you can perform, but this is true of most
> any non-parser-based game. With Myst, the list of enumerated actions is
> just "click," if I remember right.
"Click" is not an action in Myst, nor is it a verb, in much the
same way that "type a command" is not an action or verb in a
command-line interface.
Clicking on things in Myst will produce different actions for
different objects, or different parts of objects: opening,
closing, pushing, pulling, entering, reading.... In fact, the
list of actions is not enumerated.
Stephen.
Aaron A. Reed
> In other
> words, you have to imagine the game world less as a
> contrivance and more as a real place.
Some of the best puzzles in the "Myst" games require you to see beyond
what's technically presented and imagine the world as a real place in
order to solve a puzzle. An early puzzle in Riven involves a device
with a pipe running off in a certain direction, and a pipe-directing
complex many screens away in the game world. Of course, Riven is just a
series of still slides, so the concept of a "direction" is fairly
meaningless, and there is no visual representation of the path the pipe
takes. To solve the puzzle you must have been observant, constructed a
mental representation of the relationship these two locations have with
each other, and realized that what happens at the one place affects the
other, even though they are not directly connected. If you are thinking
of the world as a real place, it's an easy puzzle; if you are looking
for hot spots to click on, it will elude you.
Unfortunately, the wider scope of a text parser makes this a lot more
difficult to pull off in IF. If the player is encouraged to think of
the world as real, and they can EXAMINE and possibly TAKE an object,
they might trying using its shadow to measure the time of day, or
standing on top of it, or writing on the side of it, or taking shelter
under it, or a million other things which, in the vast majority of
cases, will produce a flat error message. Many games actually encourage
you to think of items as abstract OBJECTS in abstract ROOM spaces.
A robust implementation can go along way to solving these problems, and
I think the extra work on the designer's side is worth the effort here.
Thinking in this vein is great for authors, as it simultaneously makes
for more interesting, believable, and solveable puzzles, while making
your game world seem more real to the player.
Timofei Shatrov
tried to confuse everyone with this message:
You may try other roguelikes. Nethack is kind of average as far as
roguelikes go: it's only advantage is that it's well-known. In
particular I recommend:
*ADOM
*DoomRL
*Dungeon Crawl
*IVAN
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
Aaron A. Reed
> >USE CARROT
>
> You put the carrot in your ear. Nothing happens.
>
>That gives the player the hint that he should perhaps be more specific
>about how to use the carrot.
I've done things like this, too, and it's useful if there's more than
one type of thing that can be done with the carrot. But I've always
found the old maxim true that if the player knows what he wants to do,
and the game knows what he wants to do, there's absolutely no reason
why the action should not proceed. If I type "USE KEY" and the game
asks me "What do you want to use it on?" when there's only one lock
present, I become extremely annoyed. Particularly if the game then says
"Perhaps you meant to say 'unlock.'"
Aaron A. Reed
it's always nice to get a description for something you're interested
in instead of a stock message, I feel a little weary every time I enter
a new room in most modern IF, knowing that I'm going to have to X
everything in sight in order to discover the puzzles and their
solutions.
I also think EXAMINE is frighteningly unintuitive for new players. In
my experience, new IF players almost never try to look at things in
more detail, unless you explicitly prompt them to.
Mark Thern
> If I'm a first time player and I'm playing Sting of the Wasp,
I can't beat the game unless I read the instructions and find out
that I'll need to use the Blackmail verb, which is a command I
probably wouldn't have thought to use without the manual telling
me.
>If you're a first time player, why in the world wouldn't you read
the instructions and find this out?
I don't assume that the user will always remember all the instructions
that I give him. Read my VCR explanation from my earlier post to
understand my reasoning. Or better yet, try reading Joel Spolksy's
essay on interface design at:
http://www.joelonsoftware.com/printerFriendly/uibook/fog0000000249.html.
I don't think you'll agree with Mr. Spolsky's views, but you'll gain a
more thorough understanding of mine, as I base much of my interface
design philosophy on his writings.
> I think a command line can sometimes be the best choice of interface
for a game.
> I think you're contradicting yourself.
> I don't think the Mulldoon Legacy, which has 92 different
verbs, would work well in a GUI, even if you could somehow categorize
the verbs.
> So you find the Mulldoon Legacy "non-user-friendly", but don't think it would work well if it were "user-friendly"?
I think that for a GUI to work well in a work of I-F, the game must
have a set of verbs that can be divided into easily recognized
categories. For example, if the player is talking to an npc, a talk
menu should appear with verbs relevant to talking, such as Ask, Tell,
Think About, Examine, and Wait. If the player is exploring an area,
then the verbs in the menu should be related to movement, examination,
and taking things that don't belong to you. If the Use verb is too
generic for the author's tastes, then he could create a menu with a
set of item interaction verbs. In the case of the Muldoon Legacy, the
verb set for item manipulation is too lengthy to stuff in a single
easily recognized category. For that game, it probably really is more
efficient to simply type in the commands than it would be to search
through a menu tree looking for the right verb.
Now that I think about it, I suppose the game could use a GUI to allow
players to acquaint themselves with the verbs. Once the player felt
secure in his knowledge, he could then choose to turn off the GUI and
play through the command line.
>GUl adventure games really do exist, you know. They're not "much more accessible to newcomers", and they certainly aren't "without the tedium" in general. The best graphical adventures aren't nearly as well-written as the best IF.
I think the average user would disagree with you about the
accessibility part.
>IF is already very accessible to newcomers because you can leverage
all the experience they have with using command-line interfaces
and written language when it comes to learning how to play and
remembering how to do it later.
As far as I know, programs whose functions are controlled solely
through a command line aren't very common outside techie circles. I
don't think typing queries in Google will help you much when it comes
to learning I-F. Some users might have some experience with DOS, but I
don't think they have many happy memories of using it.
You seem to be happy with the status quo when it comes to I-F. That's
fine. I'm just curious about one thing. If you could improve the
aspects of I-F that you didn't like, what would you choose to improve?
I won't dispute your choices or anything. I'm just honestly curious.
Greg Boettcher
> Greg Boettcher wrote:
> > With Myst, the list of enumerated actions is
> > just "click," if I remember right.
>
> "Click" is not an action in Myst, nor is it a verb, in much the
> same way that "type a command" is not an action or verb in a
> command-line interface.
Whatever it is, it is directly relevant to how many options you have at
a time. I think that's what we were talking about.
For what it's worth, I remembered wrong. "Click-and-drag" is also an
option sometimes.
Greg
Nathan
> Nathan wrote:
>> Mark Thern wrote:
>>> If I'm a first time player and I'm playing Sting of the Wasp,
>>> I can't beat the game unless I read the instructions and find out
>>> that I'll need to use the Blackmail verb, which is a command I
>>> probably wouldn't have thought to use without the manual telling
>>> me.
>> If you're a first time player, why in the world wouldn't you read
>> the instructions and find this out?
> I don't assume that the user will always remember all the instructions
> that I give him. Read my VCR explanation from my earlier post to
> understand my reasoning. Or better yet, try reading Joel Spolksy's
> essay on interface design at:
>
> http://www.joelonsoftware.com/printerFriendly/uibook/fog0000000249.html.
>
> I don't think you'll agree with Mr. Spolsky's views, but you'll gain a
> more thorough understanding of mine, as I base much of my interface
> design philosophy on his writings.
Thank you for pointing me to this. It was a fun read. You're right; I
disagree, but I understand much better now. I found this paragraph
very illuminating:
"Every time you provide an option, you're asking the user to make a
decision. That means they will have to think about something and
decide about it. It's not necessarily a bad thing, but, in general,
you should always try to minimize the number of decisions that
people have to make."
Idealistic, isn't he? This is all very well and good when designing a
word processor, but IF is all about options. IF is for people who like
thinking and deciding about things. Application software is a means
to an end. IF is an end in itself. Static fiction is also great, but
it's not IF.
Here's another telling quotation:
"Yes, I know, people who use computers are by and large
able to read, but I guarantee you that a good percentage of
them will find reading to be a chore."
Not only is this frightfully sad if true, but it's talking about
people who will never be part of the IF audience. IF can't
possibly ever appeal to people who don't like to read.
By the way, I certainly believe the claim that most users don't
read instructions. It's the claim that they shouldn't have to
that constantly galls me. This is an arrogant and dangerous
attitude for sentient beings in a world of constant change.
IF will never be an appropriate medium for such people,
unwilling to learn new things unless you trick them into
doing it unconsciously.
Here's a claim I can't let pass:
"Even smart, experienced, advanced users will appreciate
things that you do to make it easy for the distracted,
inexperienced, beginner users."
This only works when your newbie helps don't get in the way.
Getting rid of the command line in IF doesn't meet that standard.
My wife--nobody's power user--is constantly complaining to
me about the "helpful" features built into her word processor,
the decisions it makes without her say-so.
Here's one thing I agree strongly with:
"Even in the best of situations, using the mouse a lot feels
slow to people. If you force people to perform a multi-step
operation using the mouse, they may feel like they are
being stalled which in turn makes the UI feel unresponsive,
which, as you should know by now, makes them unhappy."
Compared to typing in commands, clicking on pictures or
words is just so slow and inefficient. It certainly doesn't
help me get into a story.
And here's one that's just a fallacy:
"Using a command line interface is like having to learn Korean
to order food in a Seoul branch of McDonalds. Using a menu
based interface is like being able to point to the food you want
and nod your head vigorously: it conveys the same information
with no learning curve."
This fallacy has been with us a long time. "No learning curve",
indeed! So why is it that my mom still can't use a computer,
even though all the user interfaces have been beautifully intuitive
GUIs for 10 years or more? Even Apple and Microsoft know
better than that. It's not the user interface; it's the user attitude.
> Now that I think about it, I suppose the game could use a GUI to allow
> players to acquaint themselves with the verbs. Once the player felt
> secure in his knowledge, he could then choose to turn off the GUI and
> play through the command line.
Maybe there's room for compromise with this sort of interface.
I frankly doubt it would significantly expand the user base.
I recently played a few of Legend Entertainment's old games for the
first time: Eric the Unready and the Spellcasting series. These were
still parser-based (with illustrations and sound), but they had
a mouse-clickable compass rose and verb-noun menus off to the
side. I wonder if newbies used these the way you suggest. I
just typed. Unfortunately, although the writing in these games is
excellent, I found the gameplay too linear.
> You seem to be happy with the status quo when it comes to I-F. That's
> fine. I'm just curious about one thing. If you could improve the
> aspects of I-F that you didn't like, what would you choose to improve?
> I won't dispute your choices or anything. I'm just honestly curious.
Obviously I don't want to change the definition of IF.
If the reason we are a small group is simply that users
don't like the command line, then we're going to stay small.
I think what needs improvement is the community itself.
We need a few more authors (I'll get around to it someday),
and we need a lot more testers (I'll get around to that sooner).
Rather than catering to newbies, I think authors need to
get better at meeting the standards that already exist.
A lot of the complaints made earlier in the thread aren't
really about the command line, but about what are already
recognized as common design flaws. I see lots more
beta testing as the solution.
Mark Thern
agree with your evaluation of my design philosophy, but you knew that
would be the case:) I don't have any new arguments to add, other than I
think that the average user's preference for learning through doing
rather than learning through written instructions is rooted in our
evolutionary psychology and not likely to change anytime soon. I see
this attitude as an evolutionary failing rather than a moral one, and
that's why my conclusions are so different from your own.
And now I'd like to make a few comments on some of the points that you
used, but in the spirit of clarification rather than contention:
>Compared to typing in commands, clicking on pictures or
>words is just so slow and inefficient. It certainly doesn't
>help me get into a story.
I agree that this is true for some people, and that this preference is
probably quite common among regular players of I-F. I think the ideal
circumstance is for the player to have the choice of either the mouse,
the numberpad, or the keyboard as an interface option.
>I recently played a few of Legend Entertainment's old games for the
>first time: Eric the Unready and the Spellcasting series. These were
>still parser-based (with illustrations and sound), but they had
>a mouse-clickable compass rose and verb-noun menus off to the
>side. I wonder if newbies used these the way you suggest.
I haven't played those games, but I did take a look at Legend's Gateway
2: Homeworld when I was doing research on interfaces for I-F. I
seriously doubt that many newbies used the verb menu because it was
horribly designed. The designers just dumped all the verbs in one menu
without making any effort to categorize them other than to put the 10
most commonly used verbs at the top. Studying that game provided a very
good lesson in how not to do things.
>Unfortunately, although the writing in these games is excellent, I found the gameplay too linear.
That's probably due to the puzzle design and the expense of producing
artwork for branching paths. I think an I-F game with a gui interface
won't work very well if the author relies on the "combination lock"
style of puzzle, i.e. to open the door, you must get the poison apple
and feed it to the troll guarding the key sort of thing. I think
strategic puzzles, like in Adam Cadre's Lock and Key, are the way to go
if an author decides to enumerate all the choices in his game.
I'll give you an example. Suppose you're writing a game of stalker
horror and have a situation where the young heroine is trapped in a
large house with a machete-wielding maniac. This could be pretty scary
with a command line interface, because the user will be under stress to
figure out the right choice before the pc undergoes a radical
weight-loss plan. But I think it could be equally scary if you gave her
a menu that limited her choices to the following options: Attack,
Scream, Hide, Run, Push, and Take. Now if you make this a combination
lock puzzle where the only thing that works is Attack and only if she
has the axe, then your puzzle is boring. But if you allow each choice
to be a good one under the correct circumstance, then you've made an
interesting puzzle. Scream might fail miserably in the Basement, but
will alert the neighbors if she does it on the Balcony. Or it might buy
her some time if she uses it when she first runs into the stalker.
("I love listening to you scream, baby. It whets my appetite," the
killer says as he licks the machete in his hand. He cuts his tongue
doing so, but doesn't seem to notice as he disappears into some
mysterious inner world.) Pushing something over could delay her
pursuer, but she'll waste time if it's too heavy to move. Running might
make her tired, and if she runs into the wrong part of the house,
she'll encounter the stalker's partner. (Her boyfriend!)
You could implement the same puzzle with a command line, but would the
user think to Scream? He might if he read about it in the manual, but
is he likely to try using it as a viable tactical option unless you
tell him somehow? You'll probably tell me that good hinting will
overcome this problem. Maybe. But what if you have lots of
hard-to-think of actions, like a huge list of fighting maneuvers in
your martial arts I-F?
>I think what needs improvement is the community itself.
>We need a few more authors (I'll get around to it someday),
>and we need a lot more testers (I'll get around to that sooner).
I agree, and this is why I'd like to see more authors try to
commercialize their efforts. An author who wants a momentary reward for
his work is going to put more time and effort into it than a hobbyist
author could justify doing, and the beta tester problem would go away
because they would be paid for their efforts. I don't see this
happening soon, but I hope the dam will begin to break a bit sometime
during the next five years.
Samwyse
> Some of the best puzzles in the "Myst" games require you to see beyond
> what's technically presented and imagine the world as a real place in
> order to solve a puzzle. An early puzzle in Riven involves a device
> with a pipe running off in a certain direction, and a pipe-directing
> complex many screens away in the game world. Of course, Riven is just a
> series of still slides, so the concept of a "direction" is fairly
> meaningless, and there is no visual representation of the path the pipe
> takes. To solve the puzzle you must have been observant, constructed a
> mental representation of the relationship these two locations have with
> each other, and realized that what happens at the one place affects the
> other, even though they are not directly connected. If you are thinking
> of the world as a real place, it's an easy puzzle; if you are looking
> for hot spots to click on, it will elude you.
>
> Unfortunately, the wider scope of a text parser makes this a lot more
> difficult to pull off in IF.
While not a puzzle, Adventure has excellent spacial relationships. (Of
course, it was based on a real cave, which helps.) For example, all of
the rooms that contain falling water are vertically aligned with each
other. This fact can help tremendously when constructing a map.
Samwyse
> I recently played a few of Legend Entertainment's old games for the
> first time: Eric the Unready and the Spellcasting series. These were
> still parser-based (with illustrations and sound), but they had
> a mouse-clickable compass rose and verb-noun menus off to the
> side. I wonder if newbies used these the way you suggest. I
> just typed.
I guess I need to figure out when those were written, and compare it to
when I wrote MudWin... Hmmm, I wrote MudWin in 1994/1995, and Eric
dates back to 1993, so I guess we were independent implementors of the idea.
MudWin is a GUI MUD client, writen back when MUDs were strictly text.
It featured a toolbar with a compass rose and icons for the more common
verbs. If you highlighted some text (by either double-clicking or
click-and-drag) and then clicked on an icon, it would issue the command
followed by that text; useful if you selected the word "sword" and then
clicked the "take" icon. I keep meaning to create an updated version,
but never have the time.
James Taylor
> I am not touting unboundedness as the definition of interactive
> fiction. (If I were, the archetypical IF puzzle would be guessing
> a twelve-digit combination lock.) An undifferentiated, non-enumerable
> axis of control is just as antithetical to IF as a three-choice menu.
> The definition of IF is -- if you'll forgive the use of a different
> 80's geek fad -- a fractal dimensionality, neither finite nor the real
> number line.
Having studied maths at university and attended a lecture on fractal
dimensionality given by none other than Mandelbrot himself, I feel a bit
sheepish for asking, but would you please explain what you mean by this?
My recollection of the meaning of fractal dimension is rusty at best and
I can't even imagine how to apply it to IF. Thanks.
--
James Taylor
Autymn D. C.
> I recently introduced my grandson, aged 17 and very computer savy, to
savvy
> IF. His experience illustrates some of the problems that have to be
> addresses of IF is ever to appeal to a wider audience. I'll use a
> hypothetical situation here for a hypothetical game to demonstrate the
> first problem he ran into as a new IF player:
> So his first impression of IF was very negative. It "shows" you a bunch
> of stuff and then tells you that none of that stuff is really there. At
> the VERY least, any items mentioned in the description should be
> examinable. We tend to be forgiving, if not completely blind to
> shortcomings like that, because we're so used to it. But should we
> tolerate it, really? I don't think so. Maybe the game engine itself
U, I know a game that will make one homicidal or suicidal: A Simple
Home Adventure.
Autymn D. C.
Be more specific.
>turn it on
ChrisM...@hotmail.com
I just think IF is such a unique thing, where the player/reader is
partaking in something part literature and part game, that some people
just can't deal with it. They can't deal with learning a whole new set
of gaming skills to become good at IF, and they also can't deal with
engaging the work on the same level they do when they open a book and
read from paper, because they arent really sure what IF IS.
fiziwig
participate in our elite pastime" argument. I hear that a lot from
Linux users too, whenever anyone complains about some user-unfriendly
feature of Linux.
--gary
David Thornley
IF, like chess, or military miniatures games, or science fiction,
appeals to some people and not others. We put up with the inherent
limitations of IF because we like IF. It's not like somebody putting
up with some stupid thing in any given OS and giving themselves airs
about it.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Autymn D. C.
> You may try other roguelikes. Nethack is kind of average as far as
> roguelikes go: it's only advantage is that it's well-known. In
"it's only advantage"? dumbass.
> particular I recommend:
>
> *ADOM
> *DoomRL
> *Dungeon Crawl
> *IVAN
NetHack is good for misanthropes, who don't care to bog themselves down
in races and classes or other RPG fare, and who want to get to the
hacking and grabbing. So it's like Zork, with extra dimensions.
-Aut
Timofei Shatrov
tried to confuse everyone with this message:
>Timofei Shatrov wrote:
>> You may try other roguelikes. Nethack is kind of average as far as
>> roguelikes go: it's only advantage is that it's well-known. In
>
>"it's only advantage"? dumbass.
Oh, shut up. Bet you can't spell a single word in Russian.
>> particular I recommend:
>>
>> *ADOM
>> *DoomRL
>> *Dungeon Crawl
>> *IVAN
>
>NetHack is good for misanthropes, who don't care to bog themselves down
>in races and classes or other RPG fare, and who want to get to the
>hacking and grabbing. So it's like Zork, with extra dimensions.
At least Zork has a storyline.
Autymn D. C.
As the "braintree" of neura that a few scientists describe by its
fractal dimension, this is a measure of the fraction of whole (integal)
space a region takes up. It can be any fraction. Discrete or finite
spaces would have integral dimension, but some recursive algorithm
models it as a fractal. For regular parsings, the forktree is between
1D and 3D. So I guess.
-Aut
lumi...@hotmail.com
fiziwig wrote:
> <<If we could just pinpoint that something and fix
> it... well... we'd furfill our dream. >>
>
> I think it has to do with success, rewards, and payoffs. When my son
> was a Cub Scout and I volunteered to be a den leader, one of the key
> things I discovered about keeping a bunch of boys interested and
> motivated was to set task for them that they were capable of
> completing, and then be sure that the rewards for completion followed
> promptly. If the task frustrated them they would lose interest. If they
> completed the task but there was no reward, no merit badge, to little
> gold star presented with much pomp and ceremony, they also lost
> interest.
>
> Take a combat-style FPS, for example. The first itme I played the
> original Unreal I walked into the first cave and got blown up by a
> giant monster shooting rockets at me. I didn't need any instructions to
> inform me that I had to learn how to dodge those rockets, and I didn't
> need to struggle with verbs and adjectives to figure out HOW to dodge
> those rockets. The next time into the cave I danced around those
> rockets and blasted away with my puny little pistol until that monster
> came crashing down. That was a big reward for accomplishing a task that
> was not frustrating because, first, it was obvious what needed to be
> done, and second, it was obvious how to accomplish it. Granted, that's
> a motor skill, not a thoughtful application of deductive logic, but
> even working a crossword or a Sudoku gives me the same immediate sense
> of satisfaction upon completing a task.
>
> My experience with IF, and I have to admit, my IF experience is very
> limited, (having played probably no more than two dozen games in my
> life) is that the rewards are very small, and follow very long,
> protracted guessing games which, by themselves, are not much fun at
> all. Yet I keep coming back to IF. Every few years I pick it up again
> and try it. NOT because I enjoy it, but because I WANT TO enjoy it;
> because I think I OUGHT TO enjoy it. The concept is intriguing and it
> just sounds like it should be a lot of fun. But then I play for a few
> weeks or a month and then set it aside for another couple of years
> until I've forgotten that it's not as much fun as it seems like it
> ought to be.
>
> On the other hand, For anyone familiar with Flying Buffalo Publications
> "Solo Dungeon Adventure games", these are books based around a
> paper-and-pencil-and-dice combat system called "Tunnels and Trolls".
> These books have pretty thin story lines, but are not simple CYOAs.
> Instead, you take your player character into one of these adventure
> books and encounter puzzles, mazes and treasure just like IF, but also
> monsters to fight. And if your PC survives the encounter with a
> particular book then your PC is often rewarded with nifty special
> weapons or magic spells. But these are not merely symbolic because,
> (and THIS makes a huge difference), your PC can take those nifty new
> weapons and spells along when you pick up the next new adventure book.
> The uniform combat system makes their use possible in any adventure
> book written under that system.
>
> Maybe my own personal problem with IF is that I would rather it worked
> like that. I would rather it were "CRIF" (Combat-Ready Interactive
> Fiction) or maybe "SPICE" (Single Player Interactive Combat
> Environment.) I think that being a D&D player since that game was just
> a few pamphlets back in the 70's, I've come to expect more sustained
> excitement than IF can reasonably offer. Perhaps I simply don't belong
> here. Perhaps I belong writing a good combat-enabled IF
> interpretor/compiler and puting out my own brand of fast-action
> text-based fantasy shooters.
>
> --gary
This thread has gotten way too long for me to read the entire thing,
but Gary, after reading this I wonder if a MUD is actually more along
the lines of what you're looking for. (I know they tend to be looked
down on in the community, but I came across my first IF game (HGttG)
when I was sixteen and may not have picked it up so easily if I hadn't
been playing MUDs since junior high.
http://www.mudconnect.com/ Tons of games there, and you may need to
filter through some of the crap to find the good stuff, but the same
goes for any community. Personally I recommend Carrion Fields.
Adam Thornton
Timofei Shatrov <gr...@mail.ru> wrote:
>On 15 Jan 2006 18:30:23 -0800, "Autymn D. C." <lysd...@sbcglobal.net>
>tried to confuse everyone with this message:
>>in races and classes or other RPG fare, and who want to get to the
>>hacking and grabbing. So it's like Zork, with extra dimensions.
>At least Zork has a storyline.
Nethack has more of a storyline than Zork. Behold:
"There's this Amulet of Yendor thingy. It's way down at the bottom of a
dungeon. Go get it, and then travel back through the dungeon and the
Elemental planes, and offer it to your god on his or her altar on the
Astral Plane. If you do this you will be promoted to demigodhood."
"Kill things! Steal their stuff! Steal anything else that's not nailed
down! Put the shiny things in a trophy case! Don't ask why!"
Adam
Autymn D. C.
> >"it's only advantage"? dumbass.
> Oh, shut up. Bet you can't spell a single word in Russian.
That's because I don't have a Curillic keyboard and I don't care to
bring up the Unicode pane. But privet, spasiba, horoxo, ploho, da,
net, moloko, glas, glasni, britva, slovo, mir, ya, laika, fisika, do
svidanya. (I got some of those from /A Clockwork Orange/.) What did
you lose?
The fuddle with Russian is how a'freakin' forever it takes to say some
words, like "in": расположенный внутри.
> >NetHack is good for misanthropes, who don't care to bog themselves down
> >in races and classes or other RPG fare, and who want to get to the
> >hacking and grabbing. So it's like Zork, with extra dimensions.
>
> At least Zork has a storyline.
the first Zork?
-Aut
John W. Kennedy
Yes, the first Zork.
But you're probably confusing the first Zork (which was on a mainframe)
with Zork I, which was the first slice cut out of it in order to be
fitted onto a late-70's personal computer.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
Matthew Russotto
>tried to confuse everyone with this message:
>
>>Timofei Shatrov wrote:
>>> You may try other roguelikes. Nethack is kind of average as far as
>>> roguelikes go: it's only advantage is that it's well-known. In
>>
>>"it's only advantage"? dumbass.
>
>Oh, shut up. Bet you can't spell a single word in Russian.
I can. Well, as close as I can get in ASCII, since I have no idea how
to type in Cyrillic: PECTOPAH. Means "restaurant".
Unfortunately, that's about my limit.
I used to know how to pronounce those ever so useful Russian phrases
suggesting maternal copulation and lack of culture, but alas, I've
forgotten them. And I never could spell them.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.
Samwyse
> I can. Well, as close as I can get in ASCII, since I have no idea how
> to type in Cyrillic: PECTOPAH. Means "restaurant".
>
> Unfortunately, that's about my limit.
>
> I used to know how to pronounce those ever so useful Russian phrases
> suggesting maternal copulation and lack of culture, but alas, I've
> forgotten them. And I never could spell them.
You can probably do a lot better than that, you just need to learn the
Cyrillic alphabet and realize that a lot of words are borrowed from
Europe and America. 'telephone' is (phoenetically) 'telefon', 'cafe' is
'cafe', 'internet salon' is 'internet salon', etc. Heck, 'restaurant'
is 'restoran'. Most of the Cyrillic letters that don't look right are
derived from Greek, so that letter at the begining of 'restaurant' is
really a Greek Rho, etc.
Once you get the hang of it, you can walk down a street in Moscow and
pick out every business and billboard. Once you have to read a
historical marker inside an old church, however, you'll be lost.
Michael Coyne
> I used to know how to pronounce those ever so useful Russian phrases
> suggesting maternal copulation and lack of culture, but alas, I've
> forgotten them. And I never could spell them.
Nekulturny?
(I knew slogging through those 1000+ page Tom Clancys would pay off some
day).
--
Michael Coyne
http://turthalion.blogspot.com
rgrassi
> A more important point actually, is why don't IF interpreters have spell
> checkers? All the words that an IF uses are known, how hard can it be to
> do a quick spell check and list some suggestions?
Adrift has an Autocomplete feature which is very interesting.
Furthermore, an Italian guy is developing a tool which "corrects"
mistyped words (under Inform) in the PreParsing.
Rob