General: IF Ruminations Uploaded
Jim Aikin
been bugging me lately. It's at
http://www.musicwords.net/if/if_clever_author.htm. Included is a wacky and
possibly impractical idea for expanding the horizons of the humble 'examine'
command.
--Jim Aikin
George Oliver
IF may be a novel at war with a crossword, but I like to think of it as
a novel in the shape of a crossword. I'm not satisfied when you write,
>Not everyone cares for obscure novels by Thomas Pynchon,
>and not everyone likes giant Mickey Mouse and Donald Duck
>figures on ice skates. If you choose to write ICTYA IF, I can't tell
>you it's a bad idea, but I will assert that your audience is likely to
>remain very small.
I think encouraging people to write easy, accessible works is
fundamentally a bad idea. Also I don't understand why you seem so
concerned with fair puzzles, unfair puzzles, and difficult puzzles.
Rating the success of a puzzle on how well a player succeeds against it
is to me too narrow-minded. A puzzle should be designed to delight, to
play, to amuse, to entertain, but never to be simply a mindless
obstacle. A puzzle is a toy, not a lock on the door.
Good idea about in-game hints. Perhaps players could also choose the
level of difficulty by selecting a number, say 1-3, (or easy,
challenging, and diffcult) that allows access to shallower to deeper
levels of examined hints.
Jim Aikin
> fundamentally a bad idea.
Uhh ... why?
I support the idea of people writing a wide variety of works -- easy and
accessible, thorny and esoteric, or anywhere on that spectrum that you may
feel comfortable. All I was saying ... well, I was saying a couple of
things. First, I get annoyed with games that stop me cold and make me feel
stupid. Second, the way to reach a wider audience is to concentrate more on
the story and less on the puzzles, or at the very least to find ways to keep
players immersed in the story rather than having them get frustrated and/or
annoyed with the author.
> Also I don't understand why you seem so
> concerned with fair puzzles, unfair puzzles, and difficult puzzles.
Because I'm lousy at solving puzzles.
> Rating the success of a puzzle on how well a player succeeds against it
> is to me too narrow-minded. A puzzle should be designed to delight, to
> play, to amuse, to entertain, but never to be simply a mindless
> obstacle.
If it's interesting enough to qualify as a toy, fine. There was a game in
this year's comp that involved rotating a cube in three dimensions (while
inside the cube). That was complex enough to qualify as a toy. And maybe ...
I don't know, I suppose some of the stuff in "Finding Martin" is toys, at
least if you think setting the dining room table is a cute way to open the
door to the kitchen. But the majority of puzzles in the majority of games
don't seem to me to rise to that level.
Granted, the question of whether the player can solve the puzzle is kind of
digital (yes/no). There are lots of other factors: Is it innovative? Does it
fit into the context of the game and/or the story?
> A puzzle is a toy, not a lock on the door.
No, that's not correct. A puzzle in IF is precisely a lock on a door. It may
also be lots of other things, up to and including a metaphor for the nature
of life. But if it's not a lock on a door, what's it doing in the game? I
mean, if you implement a 15 puzzle (I have to apologize here -- there's a 15
puzzle in Ballerina) and it's not necessary for finishing the game, then
it's just a toy. But most puzzles in IF are integral to the process of
finishing the game, right?
> Good idea about in-game hints. Perhaps players could also choose the
> level of difficulty by selecting a number, say 1-3, (or easy,
> challenging, and diffcult) that allows access to shallower to deeper
> levels of examined hints.
That sounds like more work than I'm willing to do.
--JA
George Oliver
> > I think encouraging people to write easy, accessible works is
> > fundamentally a bad idea.
>
> Uhh ... why?
I'm not saying the greatest works are the most complex, dense, and
inscrutable, only that encouraging people to write easy as A-B-C IF
probably won't raise the bar for quality IF.
> > A puzzle is a toy, not a lock on the door.
>
> No, that's not correct. A puzzle in IF is precisely a lock on a door. It may
> also be lots of other things, up to and including a metaphor for the nature
> of life. But if it's not a lock on a door, what's it doing in the game? I
> mean, if you implement a 15 puzzle (I have to apologize here -- there's a 15
> puzzle in Ballerina) and it's not necessary for finishing the game, then
> it's just a toy. But most puzzles in IF are integral to the process of
> finishing the game, right?
Well, yes. I phrased that within a shallow context, to mean people
shouldn't focus on your typical puzzle of lock and key. Touche.
Dannii
I also definately like the idea of item (and room) desciptions that
change as you deal with them.
However there's a problem that I don't think was addressed in your
essay: how to you encourage players who are used to static descriptions
to examine items more than once? And then once they've learnt to do
that, how do you stop them from examining everything 20 times
immediately to get all the clues?
Jim Aikin
> essay: how to you encourage players who are used to static descriptions
> to examine items more than once? And then once they've learnt to do
> that, how do you stop them from examining everything 20 times
> immediately to get all the clues?
Yes, I think these are real problems, or at least issues that need to be
considered.
First, I suspect that most players examine things more than once. If you
can't figure out how to get the big glob of chewing gum off of the ceiling,
and you're standing there in the grand ballroom thinking about it, you're
likely to type 'x gum' several times in order to consider the description
carefully. If you can't solve the problem and later come back to it with a
different idea, you're likely to type 'x gum' again simply to refresh your
memory.
Second, I would tend to want to make any changes in the description
context-sensitive. If you type 'x gum' 20 times without doing anything, you
would still get the same description 20 times. But if you try 'throw putty
knife at gum' or 'squirt gum with squirt gun', even though that didn't work,
the gum object might reasonably be alerted that you had tried something and
failed. It might change its description immediately, or it might simply keep
track of the number of things you try so as to change its description a
little later on.
This is why coding this type of thing would be such a big job. If there are
a dozen ways the player might reasonably try to get the chewing gum down off
the ceiling (none of which work), the author needs to think of what they
are, so as to be able to recognize the commands when they're entered and
keep track of the number that have been tried. If the player tries something
imaginative that the author didn't think of, then the gum is probably not
going to know about it, so there would be no advantage in making the
description change context-sensitive.
It was just an idea I had the other day. I may try it in my current project,
or I may not have the energy after I get done with all of the other neat
stuff I want to add.
--JA
David Fisher
news:eoef70$q7i$1...@aioe.org...
Thanks for the thoughts in your essay ...
You gave an example:
> Let's suppose there's an old trunk in the basement.
...
> The first time you examine the trunk's lock, you might
> learn only that it's somewhat rusted. But the action
> of trying to unlock the trunk (using something that
> doesn't work) might kick the lock's description into
> a new state. Now, the same command ('x lock') might
> -- and arguably should -- provide additional detail:
>
> "The keyhole is rather large, as if it was meant for
> an old-fashioned key."
I think the best time to give this kind of feedback might be when the player
tries the action - in this case, when they fail to unlock the trunk:
> unlock trunk with coathanger
It doesn't seem to fit the lock. The keyhole is rather large,
as if it was meant for an old-fashioned key.
That way the player doesn't have to re-examine the trunk to get the clue.
This would work fine in tandem with your system though, which would ensure
that they get the clue after re-examining everything if they missed it the
first time or forgot about it.
David Fisher
Jim Aikin
> player tries the action - in this case, when they fail to unlock the
> trunk:
>
> > unlock trunk with coathanger
>
> It doesn't seem to fit the lock. The keyhole is rather large,
> as if it was meant for an old-fashioned key.
>
> That way the player doesn't have to re-examine the trunk to get the clue.
>
> This would work fine in tandem with your system though, which would ensure
> that they get the clue after re-examining everything if they missed it the
> first time or forgot about it.
Good suggestion. More work, of course.
--JA
Mike Rozak
a crossword to enhance immersion"?
Interactive novel = CYOA, but perhaps more subtly done.
Use crossword to enhance immersion = Have the player experience what the
character would experience; don't use a puzzle (or CRPG combat) just to
stymie the player, use it to affect the player's emotional state. Also, the
act of providing choices is itself immersive.
"Jim Aikin" <edi...@musicwords.net> wrote in message
news:eoef70$q7i$1...@aioe.org...
George Oliver
Jim Aikin wrote:
> This is why coding this type of thing would be such a big job. If there are
> a dozen ways the player might reasonably try to get the chewing gum down off
> the ceiling (none of which work), the author needs to think of what they
> are, so as to be able to recognize the commands when they're entered and
> keep track of the number that have been tried. If the player tries something
> imaginative that the author didn't think of, then the gum is probably not
> going to know about it, so there would be no advantage in making the
> description change context-sensitive.
Do you need to know the commands exactly? Or would just a couple of
general patterns (for each object, of course) suffice? And if your
system counts something twice or misses something by mistake, it's not
such a big deal, is it?
George Oliver
Mike Rozak wrote:
> Is IF "A novel at war with a crossword," or "An interactive novel that uses
> a crossword to enhance immersion"?
>
> Interactive novel = CYOA, but perhaps more subtly done.
Do you really think an interactive novel is a CYOA? I suppose you could
say a CYOA is an interactive novel (or novella or short story), but to
define interactive as CYOA seems backward.
> Use crossword to enhance immersion = Have the player experience what the
> character would experience; don't use a puzzle (or CRPG combat) just to
> stymie the player, use it to affect the player's emotional state.
What do you think a puzzle is affecting, if not a player's emotional
state? How do you design a puzzle that doesn't affect the emotions?
Mike Rozak
> Do you really think an interactive novel is a CYOA? I suppose you could
> say a CYOA is an interactive novel (or novella or short story), but to
> define interactive as CYOA seems backward.
A CYOA is a very simple interactive novel. Something like Facade is
interactive short story. It's a narrative where the player can not only
affect final cut-scene by making a choice immediately before the final
cutscene, but can decide what branch to take at numerous points in the
experience.
> What do you think a puzzle is affecting, if not a player's emotional
> state? How do you design a puzzle that doesn't affect the emotions?
Besides frustration? :-)
Here's an example: In a muder-myster IF, it's perfectly natural to ask NPCs
where they were, etc. This puzzle immerses the player because it's in the
genre. It might even be OK to have the player to break into a safe, also
because it's immersive. It makes the player feel like they're the detective.
In a Tolkien fantasy, it's immersive to have monsters chasing you, it's
immersive to try and decipher old ruins, and it's immersive to be lost in
Moria.
In a romance IF, it's immersive to wonder what kind of gift would be liked
by your sweetheart. Figuring out the gift might be a puzzle, but more
importantly it enhances the story.
Basically, the puzzle, game, or whatever activity, is used to further the
story. It's not an artificial construct whose pupose is to stymie the story.
Something like Myst is a crossword puzzle (so to speak) with a linear story
added. The linear story is gated by the solution to the puzzles. I'm talking
about an interactive story (choices in the story's path throughout) with a
crossword puzzle (or other appropriate activities) added where they enhance
the story.
Reiko
> I support the idea of people writing a wide variety of works -- easy and
> accessible, thorny and esoteric, or anywhere on that spectrum that you may
> feel comfortable. All I was saying ... well, I was saying a couple of
> things. First, I get annoyed with games that stop me cold and make me feel
> stupid. Second, the way to reach a wider audience is to concentrate more on
> the story and less on the puzzles, or at the very least to find ways to keep
> players immersed in the story rather than having them get frustrated and/or
> annoyed with the author.
>
> > Also I don't understand why you seem so
> > concerned with fair puzzles, unfair puzzles, and difficult puzzles.
>
> Because I'm lousy at solving puzzles.
I totally agree. I started a game recently which doesn't have any hints
available except for in-game comments by NPCs, and after I wandered
around for a bit, fiddled with a couple of gadgets, and went everywhere
I could find, I had a handful of items, a few splinters of a story, and
no inspiration to keep going. I got a few hints from someone on
r.g.i-f, but I wasn't able to get much farther. This is the sort of
game that makes me feel like I'm beating my head against a brick wall
to continue. It does make me feel stupid sometimes, because I go
looking for an object someone tells me I'm supposed to have, and then
I'm told it's in a particular room, and after searching around for a
bit, realize there's a piece of scenery that's been sitting there
looking particularly uninteresting. When I search it or look under it
or examine it or something, I find the object, where there was
absolutely no reason I could see to search there before I got the hint.
And, what's more, later on I find out that the object doesn't even work
for the purpose it seems obvious that it should work for.
I haven't been trying terribly wacky things, but I've certainly been
coming up with wacky possibilities for why things are the way they are
or what to do with the items I've got (and usually being wrong, because
I'm missing clues or items in the setting that aren't pointed out at
all in the base descriptions). The only reason I keep coming back to it
is because I like the theme (if we could ever get an actual story
going, it'd be nice...) and because I've heard it's a good game (later
on?). But it's really hard to get into it.
~Reiko
d...@pobox.com
On Jan 15, 1:12 am, "Jim Aikin" <edi...@musicwords.net> wrote:
> > A puzzle is a toy, not a lock on the door.
> No, that's not correct. A puzzle in IF is precisely a lock on a door. It may
> also be lots of other things, up to and including a metaphor for the nature
> of life. But if it's not a lock on a door, what's it doing in the game? I
> mean, if you implement a 15 puzzle (I have to apologize here -- there's a 15
> puzzle in Ballerina) and it's not necessary for finishing the game, then
> it's just a toy. But most puzzles in IF are integral to the process of
> finishing the game, right?
You seem to think that a player must be forced through each and every
puzzle in a game in order to get to the end, but I suspect you don't
think the same thing about paragraphs of text. In almost any work
there will be plenty of text that it isn't necessary to see in order to
reach the end. It seems very reasonable to me to have "optional
puzzles" in a game, just as there are "optional texts". The complement
of your question "If it's not a lock on a door, what's it doing in the
game?" is "If you don't need to read it, what's it doing in the game?"
The answer to both questions is providing entertainment, often through
an increased sensation of depth or immersion. Just as additional
descriptions provide extra depth, so can additional puzzles (or other
interactive devices).
To take an example from Last Resort, why are Diane's clothes or the
space under the bed described? Neither description is necessary for
the player to complete the game, but they both add depth. Why can't
you remove all the fuses in the fuse box or tear pages out of the
bible? Both of those would add depth to the game through better
simulation. The usual answer, it's unnecessary in order to motivate
the PC's arc, masks what I suspect is the true answer: the simulation
involves too much programming and is too hard.
drj
Emily Short
d...@pobox.com wrote:
> Why can't
> you remove all the fuses in the fuse box or tear pages out of the
> bible? Both of those would add depth to the game through better
> simulation. The usual answer, it's unnecessary in order to motivate
> the PC's arc, masks what I suspect is the true answer: the simulation
> involves too much programming and is too hard.
That's probably part of it. On the other hand, in many games -- and
especially in a game like Last Resort, which is heavy on thoroughness
puzzles (that is, puzzles that test the player's diligence in looking
at everything, trying objects in combination, and using keywords on
every NPC) -- if you put a lot of work into simulating something, the
player will expect that that simulation will play into one or more of
the puzzles. And if he wastes time exploring the boundaries of the
simulation and finds that that doesn't ever help him at all, he may be
annoyed rather than pleased. (I know that would have been *my*
reaction. I spent enough of my time meta-gaming as it was.)
Extra flavor text on examining things (such as PC or NPC clothes) tends
to be a bit less misleading. Though I recall spending a lot of time in
Zork trying to interact with a crack described in a cavern wall, which
was there only as scenery...
d...@pobox.com
I basically agree. I wonder though if extra "flavor text" is a bit
less misleading simply because it's easier to add. I think all players
meta-game (whether they call it that or not); to some extent they'll
spend time investigating the bits of the game where they think the time
has been spent by the author. You see that the PC's epaulets have been
described, you spend a few moves trying to interact with them and
conclude that it's just "flavor text". There's no real equivalent on
the programming side, though I suppose a series of rather specific
"instead of" rules might be close.
drj
Blank
Really what we're interested in is not whether the moves the player is
making are progressing toward the (or possibly just one of several)
solution(s), but is s/he having fun?
Would it be useful to have something like a TELLME command, so that when
it stops being fun the player could ask for extra information? Darn,
that's a muddled, vague description. Perhaps an example would be clearer:-
Okay - the player has been poking around in the grounds of an empty mansion.
Imagine the player has been interacting with a bush. Its leaves crackle
when you rustle them, they flicker in the wind - you know, cute
programming stuff. But now the player has got bored with the bush, and
really wants to know if it's somehow going to help with opening the
Warped Cellar Door - perhaps provide a lever for prising it open or
something. So:
> X BUSH
"It's a short scrubby bush, rather strangely shaped. It may be natural
growth, or perhaps in the distant past it was clipped into the shape of
some winged creature.
> TELLME
(Okay, more information is now available for the next command.)
> X BUSH
"It's a short scrubby bush, rather strangely shaped. It may be natural
growth, or perhaps in the distant past it was clipped into the shape of
some winged creature."
(It's just here for entertainment. [or: "It's part of a puzzle. But
there are many puzzles here."]
TELLME mode off.)
>
So now the information is available to the player who can better choose
how to spend time: serious puzzle bashing, or just poking about? Making
the TELLME command (or whatever better name we can come up with) have to
be specifically enabled for each request would provide just enough extra
work that I think players would only ask for it when they really wanted it.
I'm only thinking of this as a means of allowing the player to filter
out scenery objects, a kind of *negative* hint, IYSWIM. So it wouldn't
be much extra work for the author - possibly even reduce to a
plug-in-and-forget extension.
Thoughts?
jz
-
IF is sometimes like writing software documentation: one doesn't say
/why/ to interact w/ a widget, only /how/ or /when/. One must assume the
user's expertise in the problem domain. For example, it's not the
writer's job to teach the user the basics of double entry accounting,
only to describe the widget combination that creates a payroll journal
entry.
IF is sometimes not like writing software documentation: one gets a
chance to tell a story that challenges the reader; such provocations are
not tolerated in technical writing. Isn't that supposed to be the art of
this software genre?
One could view the OP's suggestion as a kind of tooltip, with
presentation mechanics To Be Determined. OTOH, perhaps a general
annotation technique is really what's required? Are there other IF tools
that provide an annotation framework?
Jim Aikin
> making are progressing toward the (or possibly just one of several)
> solution(s), but is s/he having fun?
>
> Would it be useful to have something like a TELLME command, so that when
> it stops being fun the player could ask for extra information?
I sort of like this. A 'tell me more' command (or it could be implemented as
'examine closely') would simply bypass the mechanism for adding
context-sensitive bits to the description, and take you straight to the end
state of the description.
OTOH, at this point many players will simply go around examining everything
closely, and will get annoyed that you've implemented a special command that
requires them to type more characters. So maybe this isn't such a hot idea.
Maybe it's better to let the game output a few extra bits of text when and
if it feels like it.
It's less meta-gaming, to use Emily's term. The player who knows there's a
software shortcut is kind of being pulled out of the world of the story.
--JA
Eric Eve
>
>> Would it be useful to have something like a TELLME command, so
>> that when it stops being fun the player could ask for extra
>> information?
>
> OTOH, at this point many players will simply go around examining
> everything closely, and will get annoyed that you've implemented a
> special command that requires them to type more characters. So
> maybe this isn't such a hot idea. Maybe it's better to let the
> game output a few extra bits of text when and if it feels like it.
>
> It's less meta-gaming, to use Emily's term. The player who knows
> there's a software shortcut is kind of being pulled out of the
> world of the story.
That would also be my concern with this suggestion. It might be
better to handle this in the hints system, if it needs handling at
all, e.g. with a hint topic that says "What do I need to do with the
bush?" with an answer that can say "Nothing -- it's just
decoration".
-- Eric
JDC
Jim Aikin wrote:
> > Would it be useful to have something like a TELLME command, so that when
> > it stops being fun the player could ask for extra information?
>
> I sort of like this. A 'tell me more' command (or it could be implemented as
> 'examine closely') would simply bypass the mechanism for adding
> context-sensitive bits to the description, and take you straight to the end
> state of the description.
>
> OTOH, at this point many players will simply go around examining everything
> closely, and will get annoyed that you've implemented a special command that
> requires them to type more characters. So maybe this isn't such a hot idea.
> Maybe it's better to let the game output a few extra bits of text when and
> if it feels like it.
>
> It's less meta-gaming, to use Emily's term. The player who knows there's a
> software shortcut is kind of being pulled out of the world of the story.
Additionally, an important question is whether something like a TELLME
command would be any less meta than simply typing HINT, and I'm not
sure that it would be. But one distinction I see is that it's
presenting hints from a different perspective. Rather than looking at a
hint for a particular puzzle (which seems to be the most common way of
presenting hints), it presents things from the standpoint of whether a
particular object is good for anything.
This can be somewhat less spoilery, in the sense that you might have an
idea for solving a puzzle and just want to see if you're on the the
right track. But I think this could be presented about as well by
having hints along the lines of "What do I do with the shrubbery?"
("Nothing."), and a number of games do present hints of this form.
If the idea is to try to make hints more naturally a part of the game,
I prefer the idea of having descriptions change in response to
unsuccessful attempts to solve puzzles or interact with objects,
although this seems like it would require a lot of work to implement.
To do it really well you would probably want to know what puzzle a
player was trying to use a particular object for, so you'd need to keep
track of unsuccessful attempts at solving puzzles as well as
unsuccessful attempts to use various objects and correlate them
somehow.
-JDC
Adam Thornton
>IF is sometimes not like writing software documentation: one gets a
>chance to tell a story that challenges the reader; such provocations are
>not tolerated in technical writing.
Maybe you could have a word with the documentation departments of
several software vendors with whom I interact.
Adam
-
/me observes contrails...
Meaning they want you to tell stories & you wish they'd revisit that
requirement? Or you want to tell stories & they won't accept that type
of work product?
Adam Thornton
>Adam Thornton wrote:
>> In article <eoj015$v25$1...@aioe.org>, - <x...@x.com> wrote:
>>> IF is sometimes not like writing software documentation: one gets a
>>> chance to tell a story that challenges the reader; such provocations are
>>> not tolerated in technical writing.
>> Maybe you could have a word with the documentation departments of
>> several software vendors with whom I interact.
>Meaning they want you to tell stories & you wish they'd revisit that
>requirement? Or you want to tell stories & they won't accept that type
>of work product?
Meaning I find the stories they tell challenging to read, and they
consider that perfectly appropriate, apparently, as their documentation
has gotten more, not less, challenging to understand, as time has
progressed. I am approaching this particular issue as an end-user, not
an author.
Adam
Emily Short
Blank wrote:
> Really what we're interested in is not whether the moves the player is
> making are progressing toward the (or possibly just one of several)
> solution(s), but is s/he having fun?
>
> Would it be useful to have something like a TELLME command, so that when
> it stops being fun the player could ask for extra information?
I have played a game that had a red-herring detector: use it on
something, and it tells you whether the item in question is important
to puzzles or not.
I did use it. I found it useful from the game perspective. I also found
it somewhat anti-immersion. But since I was using it voluntarily, I
kind of felt as though those disconnects from the game reality were
*my* fault rather than the game's.
Still, the most effective, least game-destroying way I know to deal
with this is to have a friend who's already played the game and to be
able to ask that person, "hey, does the bush matter to any puzzles?"
Unfortunately, as author I'm not in a position to package a
knowledgeable buddy along with the game.
-
Yeah, worked w/ a group that wanted to "tell stories" as their
documentation (a sophisticated FORTRAN API). They were quite distracted
from the actual task at hand: producing an accurate description of their
rather complex API. The storyline became increasingly outre' until
project management finally put brakes to the idea.
One the Inform's lures is that its implementation of a class of
programming tools (natural language parser) /might/ hold a way of
transforming the end-user experience when learning/exploring
sophisticated software environments.
Notwithstanding my comment above, I do believe that documentation qua
story has its place in the documentation writer's toolkit. It's just
that the story /cannot/ become the sole technical reference. Stories
have the ability to teach by analogy, a technique unavailable to
technical documentation. The story should be presented as an adjunct to,
not in lieu of, the technical reference.
Emily Short
d...@pobox.com wrote:
> I basically agree. I wonder though if extra "flavor text" is a bit
> less misleading simply because it's easier to add. I think all players
> meta-game (whether they call it that or not); to some extent they'll
> spend time investigating the bits of the game where they think the time
> has been spent by the author. You see that the PC's epaulets have been
> described, you spend a few moves trying to interact with them and
> conclude that it's just "flavor text". There's no real equivalent on
> the programming side, though I suppose a series of rather specific
> "instead of" rules might be close.
If I encounter a lot of extra descriptions of things, I tend to
conclude that the item descriptions are important to the story aspect
of the work -- world-building, characterization, etc. -- but that I
don't actually have to do anything about them other than examine lots
of things.
So partly it's a question of detecting where the author spent his time,
as you say, and partly it's that extra descriptions create a precise
and limited kind of extra work for me (examine everything) and mostly
that's something I already need to do anyway. To put it another way:
it's just the same amount of work for the player to type >EXAMINE FOO
and get the result "That's not important in this game." or "That's just
scenery." as it is to type >EXAMINE FOO and get the reply "The foo is
exquisitely carved in black wood, an excellent example of 33rd-century
Ursinian workmanship..." or whatever. Admittedly then I have to
half-way remember this detail in case a puzzle arises later which has
to do with the Ursinians, but this is generally not a huge tax on my
attention span unless there's just an obscene amount of stuff in the
game. If, on the other hand, the foo has a working set of levers and
buttons that do nothing, then there's a lot of stuff I have to do
before I can determine that the foo is useless.
I also think there is a legitimate alternative (for the author) to
simulating only the systems that matter: namely, simulate lots of
things, BUT provide a lot of internal guidance for the player to let
him know where the plot goes and what his next tasks are. This seems to
work tolerably in IF where story is dominant but world-building is very
important; I think it works less well in even moderately puzzly stuff,
and very badly in puzzly games where the puzzles are underclued.
David Fisher
> ... an important question is whether something like a TELLME
> command would be any less meta than simply typing HINT, and I'm not
> sure that it would be. But one distinction I see is that it's
> presenting hints from a different perspective. Rather than looking at a
> hint for a particular puzzle (which seems to be the most common way of
> presenting hints), it presents things from the standpoint of whether a
> particular object is good for anything.
I really like the idea of being able to get hints about particular objects;
how about the following syntax:
>HINT ABOUT SHRUBBERY
It really is just an ordinary shrubbery.
By the way, has anyone done much work on different kinds of hints in IF ?
Here are some examples:
"HINT ABOUT x"
- Is object X important ?
- How do I get past obstacle X (a door, creature, etc) ?
- Have I finished with NPC x (for now) ?
"HINT ABOUT HERE"
- Have I missed anything important in this room / area ?
"HINT ABOUT PLACES"
- Is there an area I can reach which I haven't discovered yet ?
"HINT"
- What am I supposed to be doing ?
There are times when I would have liked to be able to ask a game these
questions ...
David Fisher
Emily Short
David Fisher wrote:
> "JDC" <jd...@psu.edu> wrote:
>
> > ... an important question is whether something like a TELLME
> > command would be any less meta than simply typing HINT, and I'm not
> > sure that it would be. But one distinction I see is that it's
> > presenting hints from a different perspective. Rather than looking at a
> > hint for a particular puzzle (which seems to be the most common way of
> > presenting hints), it presents things from the standpoint of whether a
> > particular object is good for anything.
>
> I really like the idea of being able to get hints about particular objects;
> how about the following syntax:
>
> >HINT ABOUT SHRUBBERY
> It really is just an ordinary shrubbery.
>
> By the way, has anyone done much work on different kinds of hints in IF ?
> Here are some examples:
>
> "HINT ABOUT x"
>
> - Is object X important ?
> - How do I get past obstacle X (a door, creature, etc) ?
> - Have I finished with NPC x (for now) ?
Bronze implements object-specific hints like this; I've had a few
complaints that people found them not useful enough in a couple of
specialized circumstances, but in general (as far as I can tell) they
worked tolerably well, and the underlying algorithm that determines
whether a puzzle has been solved yet (or what needs to happen next) was
not hard to write. But Bronze also deliberately sticks to a narrow
range of puzzle types, so I can imagine that other kinds of games might
need more handwritten hints, in which case it could be quite
challenging coming up with all the content.
Or you could just make the object-hints context-insensitive, but I
think that's a really bad idea with this kind of hint structure. Tthe
player may or may not have discovered the puzzle to which the object
belongs (whereas when you're reading hints from a menu, usually the
menu offers questions that you might want answered); and if the game
doesn't have any model of player knowledge-about-puzzles, it's likely
to give quite startling responses to such hint requests.
steve....@gmail.com
> By the way, has anyone done much work on different kinds of hints in IF?
I've been thinking that one might use a planner for some types of
hints. E.g.:
>HOW DO I CLIMB THE TREE?
You'll need to get the ladder from the hook in the garage.
>W
The Garage
[...]
On a hook hangs a ladder.
>GET LADDER
Taken.
>HOW DO I CLIMB THE TREE?
You'll need to put the ladder on the tree.
You might be surprised how easy it would be to produce the hint output,
once the planner is in place. All you need to do is resolve an action
path for a given command, and report the next-step in the form of
"You'll need to <action verb> <dobj list?> <action prep?> <iobj list?>
<dobj's room's objectInName>." TADS 3 produces this sort of output in
other contexts all the time, as I'm sure do other systems.
Blank
pulled away from the game a little bit - I said s/he'd "got bored". So
providing meta information about the game world "It's [not] just
scenery" might help the player back in again.
jz
d...@pobox.com
On Jan 16, 9:01 pm, "Emily Short" <emsh...@mindspring.com> wrote:
> Still, the most effective, least game-destroying way I know to deal
> with this is to have a friend who's already played the game and to be
> able to ask that person, "hey, does the bush matter to any puzzles?"
> Unfortunately, as author I'm not in a position to package a
> knowledgeable buddy along with the game.
But it's a nice ideal that hint systems can strive towards so is worth
bearing in mind when designing practical hint systems. RGIF is almost
as good.
drj
Conrad
Hey guys... A great discussion all around...
On Jan 14, 8:12 pm, "Jim Aikin" <edi...@musicwords.net> wrote:
> > Also I don't understand why you seem so
> > concerned with fair puzzles, unfair puzzles, and difficult puzzles.
>
> Because I'm lousy at solving puzzles.
So'm I! And I'm deeply bitter at the implicit discrimination against
stupid folk like me.
Seriously, I'm dumb with these games, and it basically prevents
me from playing them: I get stuck, and that is more or less
that.
I like the interaction and exploration; but getting stonewalled by
not flashing on some goofy lateral thinking gets my goat.
I designed and largely built an IF game (called _Cop In Paradise_),
but the engine was unstable. Anyway, I had a couple of ways of
dealing with this:
+ LOOK descriptions imply useful ways to use EXAMINE.
+ EXAMINE descriptions imply useful actions.
+ Wrong solutions fail in ways that suggest correct solutions.
+ Characters can be asked for advice.
+ Puzzles are organized in parallel rather than in series.
+ Some puzzles have more than one solution.
Conrad.
d...@pobox.com
On Jan 30, 4:02 am, "Conrad" <conradc...@gmail.com> wrote:
> Hey guys... A great discussion all around...
>
> On Jan 14, 8:12 pm, "Jim Aikin" <edi...@musicwords.net> wrote:
>
> > > Also I don't understand why you seem so
> > > concerned with fair puzzles, unfair puzzles, and difficult puzzles.
>
> > Because I'm lousy at solving puzzles.
> So'm I! And I'm deeply bitter at the implicit discrimination against
> stupid folk like me.
What implicit discrimination?
> Seriously, I'm dumb with these games, and it basically prevents
> me from playing them: I get stuck, and that is more or less
> that.
I think the modern trend is to avoid making the player stuck. Even in
a very puzzley game. The modern solution to this is to provide a
variety of devices (in, I suppose, the literary sense) to aid the
player, some in-game, some not. You list some below that are in-game;
ones that are not in-game include walkthroughs, hint menus,
knowledgable buddies. The distinction isn't quite so clear cut
either, Emily Short mentioned a game with a red-herring detector,
Curses has a demon (or at least, I think it does). The red-herring
detector and the demon are clearly in-game, but obviously not for
verisimilitude; any player using them knows they have stepped outside
the bounds of the strict simulation and into a little world where the
author is trying more explicitly to help them. There has been
discussion in this thread about hint systems that are more integrated
with the usual parser / response style of interaction.
So we see a range of devices to aid the player. If well done it
allows the player to select their own challenge. Some players might
think that using a walkthrough is cheating, but others are quite happy
to leap to the walkthrough in order to finish the game in a reasonable
amount of time. Clearly there's no sense in which the community
frowns upon the latter as we can see from the practice of providing
walkthroughs with games.
>
> I like the interaction and exploration; but getting stonewalled by
> not flashing on some goofy lateral thinking gets my goat.
>
> I designed and largely built an IF game (called _Cop In Paradise_),
> but the engine was unstable. Anyway, I had a couple of ways of
> dealing with this:
>
> + LOOK descriptions imply useful ways to use EXAMINE.
> + EXAMINE descriptions imply useful actions.
> + Wrong solutions fail in ways that suggest correct solutions.
> + Characters can be asked for advice.
> + Puzzles are organized in parallel rather than in series.
> + Some puzzles have more than one solution.
This is really just SOP for good game design. Isn't it?
drj
Conrad
On Jan 30, 4:24 am, d...@pobox.com wrote:
> On Jan 30, 4:02 am, "Conrad" <conradc...@gmail.com> wrote:
>
> > Hey guys... A great discussion all around...
>
> > On Jan 14, 8:12 pm, "Jim Aikin" <edi...@musicwords.net> wrote:
>
> > > > Also I don't understand why you seem so
> > > > concerned with fair puzzles, unfair puzzles, and difficult puzzles.
>
> > > Because I'm lousy at solving puzzles.
> > So'm I! And I'm deeply bitter at the implicit discrimination against
> > stupid folk like me.What implicit discrimination?
>
> > Seriously, I'm dumb with these games, and it basically prevents
> > me from playing them: I get stuck, and that is more or less
> > that.
> I think the modern trend is to avoid making the player stuck. Even in
> a very puzzley game. The modern solution to this is to provide a
> variety of devices (in, I suppose, the literary sense) to aid the
> player, some in-game, some not. You list some below that are in-game;
> ones that are not in-game include walkthroughs, hint menus,
> knowledgable buddies. The distinction isn't quite so clear cut
> either, Emily Short mentioned a game with a red-herring detector,
> Curses has a demon (or at least, I think it does). The red-herring
> detector and the demon are clearly in-game, but obviously not for
> verisimilitude; any player using them knows they have stepped outside
> the bounds of the strict simulation and into a little world where the
> author is trying more explicitly to help them. There has been
> discussion in this thread about hint systems that are more integrated
> with the usual parser / response style of interaction.
>
> So we see a range of devices to aid the player. If well done it
> allows the player to select their own challenge. Some players might
> think that using a walkthrough is cheating, but others are quite happy
> to leap to the walkthrough in order to finish the game in a reasonable
> amount of time. Clearly there's no sense in which the community
> frowns upon the latter as we can see from the practice of providing
> walkthroughs with games.
Yeah, see, I also largely refuse to do walkthroughs: no point.
Kinda
like reading ahead to the last page in an Agatha Christie novel so
you
can then go back & read the pages that lead up to it. My opinion.
Plus I've encountered a walkthrough or two that didn't work anyway.
> > + LOOK descriptions imply useful ways to use EXAMINE.
> > + EXAMINE descriptions imply useful actions.
> > + Wrong solutions fail in ways that suggest correct solutions.
> > + Characters can be asked for advice.
> > + Puzzles are organized in parallel rather than in series.
> > + Some puzzles have more than one solution.
>
> This is really just SOP for good game design. Isn't it?
I dunno... Have I been downloading all bad games?
To go further into it:
What I'm thinking is that if you set a number of puzzles out
simultaneously, of different natures, but leading to the same
goal -- say there are three doors; one is physically locked; one
is locked with a riddle; and one is blocked by a disgruntled
guard who hasn't been paid in a while -- then to some extent
it's the player's choice which kind of puzzle he wants to solve.
And the choice that the player makes tells you something
about the player that you can program the game to respond to:
namely that this player is more interested in solving social
puzzles, or language or mechanical ones.
Similarly, you can use the structure of the game to try to
figure out to what extent the player likes challenges (does he
or she take the easy way out?), responds to risks, punishes
or forgives betrayal, loves chaos or order, appeases or
challenges authority, makes or does not make sacrifices
to protect dependents from harm, and so forth.
And this is interesting, I think: it makes for a more emotionally
intriguing experience than a sequence of puzzles typically does.
What gets me is that the puzzles get in the way of the narrative:
and what I myself am interested in is not primarily solving puzzles
(unless they're especially cool) but in interacting with the
narrative
to see how it responds to me when, for example, I decide I'm going
to play this one as a bastard, or a coward, or a noble hero.
Is anyone making games that aim to psych the player, to figure
out where they're coming from and respond on that basis?
Conrad.
d...@pobox.com
On Jan 30, 5:31 pm, "Conrad" <conradc...@gmail.com> wrote:
>
> Is anyone making games that aim to psych the player, to figure
> out where they're coming from and respond on that basis?
Well, there was Black and White (which I never played). And er, some
IF game that explicitly tried to evaluate your style of play and
comment on it after. Someone more knowledgeable will have to fill in
the title.
drj
Emily Short
You may be thinking of The Erudition Chamber, by Daniel Freas:
http://www.wurb.com/if/game/2163
That explicitly evaluated the player's puzzle-solving style and then
responded accordingly.