When a "puzzle" isn't a puzzle, or a red herring
Brendan
to the player character. Sure, you'd probably prefer the PC to be in
control of his/her own destiny as much as possible, if not always.
After all, that's the interactive part of the fiction. But sometimes,
just as in real life, sh*t happens - to me, to you, and possibly, to a
wide-eyed, unsuspecting PC, if the type of game you're writing calls
for it. When events are beyond the PC's control, the story, at that
point, can be said to be "on rails". This is neither a good thing or
a bad thing, seems to me. All depends on what the author decides is
the best way to achieve his/her own personal creative orgasm and make
the game "work".
The dilemma in putting the story on rails, (even if only here and
there, and now and then), is the possibility of losing the player to
frustration. The player could potentially misinterpret an
uncontrollable "plot advancing event" as a puzzle that requires
solving. Experienced players will immediately begin "thinking outside
the game", attempting to determine what the author is up to - is this
a plot device or a puzzle? Saved games and UNDO become strategies for
the player, although obviously not for the PC. Again, there's nothing
wrong with this, seems to me, as long as fun is being had by one and
all.
In my newbie game, I gave the player an interesting item, and later
took it away - permanently. It was to advance the story. It was the
_PC's_ loss, and not the player's loss, (if I can try to make a
distinction in this context). I intended the PC to feel regret, as
part of advancing a storyline. I didn't intend the player to get
stuck on trying to _prevent_ the loss. Unfortunately, I think I
designed the event to smell too much like a puzzle. On the other
hand, I couldn't very well flag a spoiler to the player, as in: "Don't
worry about it. The impact will become clear if you keep playing."
Technically, the loss was neither a red herring or a puzzle. Just a
device.
In the end, I decided to allay any potential fears on the point by
making mention of it in the hint system. An odd approach perhaps, as
technically speaking, a "hint" wasn't called for. The "hint" was more
of a push forward, if requested by the player. Unfortunately again,
this approach has an obvious tendency to backfire. By making mention
of the event as part of a hint system menu option, the player
(thinking outside the game) might well conclude: "A HA! It _is_ a
puzzle," and go back to head-banging "puzzle solving" without actually
reading the hint text. Sigh.
I guess many would say that there is no dilemma - that it is all fair
game. Sometimes, it just so happens that a "puzzling event" isn't a
puzzle, and it's the player's job to figure that out. Or give up in
frustration, if that's what s/he decides to do.
What say you?
Cheers,
Brendan
Mark W
news:3c1i7vck0h2654ok8...@4ax.com:
> The dilemma in putting the story on rails, (even if only here and
> there, and now and then), is the possibility of losing the player to
> frustration. The player could potentially misinterpret an
> uncontrollable "plot advancing event" as a puzzle that requires
> solving.
The big question in my mind is "does the player have any immediate goals?"
If the player has goals in the now, they may forgive taking away of the
item.
Also, are there other ways to express your message without making it seem
like a puzzle?
Regards,
Mark
--
http://www.marktaw.com/
Jessica Knoch
"Brendan" wrote...
> It was the
> _PC's_ loss, and not the player's loss, (if I can try to make a
> distinction in this context). I intended the PC to feel regret, as
> part of advancing a storyline. I didn't intend the player to get
> stuck on trying to _prevent_ the loss. Unfortunately, I think I
> designed the event to smell too much like a puzzle. On the other
> hand, I couldn't very well flag a spoiler to the player, as in: "Don't
> worry about it. The impact will become clear if you keep playing."
> Technically, the loss was neither a red herring or a puzzle. Just a
> device.
I've got a very similar problem in a WIP, and the emotional attachment
to the thing is quite high (or is supposed to be). But I don't know how
to keep the player from what you describe: trying again and again to
keep the event from taking place, because they think they're supposed
to prevent it somehow. I'm quite interested in everyone's comments,
especially since the player's goal at that point in the game will
naturally be to prevent the "necessary" event from happening.
--
Jess K.
Michael Coyne
> [snip]
> In the end, I decided to allay any potential fears on the point by
> making mention of it in the hint system. An odd approach perhaps, as
> technically speaking, a "hint" wasn't called for. The "hint" was more
> of a push forward, if requested by the player. Unfortunately again,
> this approach has an obvious tendency to backfire. By making mention
> of the event as part of a hint system menu option, the player
> (thinking outside the game) might well conclude: "A HA! It _is_ a
> puzzle," and go back to head-banging "puzzle solving" without actually
> reading the hint text. Sigh.
>
I would probably have handled this within the narrative of the plot
device in any case, e.g.
"As Ankula takes the bejewelled dagger away from you and stows it in his
pack, all you can hope is that somehow, somewhere, you'll see it again."
This way, the player may get the idea that "There's nothing you can do
about this right now, and if you need it again later, you'll be able to
find it at that time." And the fact that it never appears again won't
bother most people--it makes the game more like real life. You lose
stuff and never see it again, esp. if you're a person that lends stuff
to people. Just ask me about my incredible shrinking CD collection. : )
Michael
Daryl McCullough
>I guess many would say that there is no dilemma - that it is all fair
>game. Sometimes, it just so happens that a "puzzling event" isn't a
>puzzle, and it's the player's job to figure that out. Or give up in
>frustration, if that's what s/he decides to do.
The puzzle that the player must solve is to figure out that there
*is* no puzzle to solve. It's a meta-puzzle.
--
Daryl McCullough
Ithaca, NY
Lucian P. Smith
: "Brendan" wrote...
:> It was the
:> _PC's_ loss, and not the player's loss, (if I can try to make a
:> distinction in this context). I intended the PC to feel regret, as
:> part of advancing a storyline. I didn't intend the player to get
:> stuck on trying to _prevent_ the loss. Unfortunately, I think I
:> designed the event to smell too much like a puzzle.
: I've got a very similar problem in a WIP, and the emotional attachment
: to the thing is quite high (or is supposed to be). But I don't know how
: to keep the player from what you describe: trying again and again to
: keep the event from taking place, because they think they're supposed
: to prevent it somehow.
I'm not sure this is a real problem. As others have said, as long as
there's something else to do, the fact that some avenues never produce
anything is probably a *good* thing, from a game design standpoint. If
you haven't, play 'So Far' for some examples of avenues that never pan out
that serve to both keep you involved and experimenting in the world, as
well as making the world seem bigger than it is.
The other option is to play like 'Metamorphoses', and have multiple
options available to the player, in some of which the player loses a
precious item, and in others of which the item can be saved.
Both are valid options, but the former has the advantage of taking less
time and effort to code ;-)
-Lucian
Andrew Plotkin
> In my newbie game, I gave the player an interesting item, and later
> took it away - permanently. It was to advance the story. It was the
> _PC's_ loss, and not the player's loss, (if I can try to make a
> distinction in this context). I intended the PC to feel regret, as
> part of advancing a storyline. I didn't intend the player to get
> stuck on trying to _prevent_ the loss. Unfortunately, I think I
> designed the event to smell too much like a puzzle. On the other
> hand, I couldn't very well flag a spoiler to the player, as in: "Don't
> worry about it. The impact will become clear if you keep playing."
> Technically, the loss was neither a red herring or a puzzle. Just a
> device.
This is an interesting observation. I've certainly run into the same
situation when playing games (both text and graphical adventures).
The best approach I can think of, from the designer's point of view,
is to write the scene well enough that it's clearly part of a *good
story*. If the player has a sense that what's happening is part of the
story you intended to write, he'll be more inclined to roll with it.
Of course, it's easy to *say* "write a good story". :)
Plus, the player might think you genuinely intended two different
branches of storyline. (Maybe you *do* have a branching storyline,
only this isn't one of the possible branches.) I don't have much idea
how to deal with this.
Low-level design patterns which apply:
- Have a broad shape to your game, so that there are always two or
three different areas the player could be working on. When the player
hits your "unsolvable puzzle", he may pound on it for a while, but
then (hopefully) he'll give up and go work on another part of the
game. If he makes ongoing progress overall, he won't come back and
start pounding on the problem event again.
- When you take away the item (your example), write the event to
strongly motivate a new goal. In other words, have an obvious
direction to chase off in to get it back. The player never *will* get
it back, but he'll be pulled into the next part of the story. (You
would then have to work the "loss" storyline reaction into later parts
of the game, as opposed to have a big immediate mourning scene.)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Andrew Plotkin
This is a good description from the designer's (or critic's) point of
view, but it doesn't help the player at all.
When the player hits a puzzle and fails to solve it, he tries harder.
When the player hits this metapuzzle and fails to "solve it", he tries
harder *to do the wrong thing*. What sort of clues do you provide to
lead him out of this blind alley?
Harry
<voyagingR...@hotmail.com> wrote:
>Sometimes, to advance a story/adventure, things just _have_ to happen
>to the player character. Sure, you'd probably prefer the PC to be in
>control of his/her own destiny as much as possible, if not always.
>After all, that's the interactive part of the fiction. But sometimes,
>just as in real life, sh*t happens - to me, to you, and possibly, to a
>wide-eyed, unsuspecting PC, if the type of game you're writing calls
>for it. When events are beyond the PC's control, the story, at that
>point, can be said to be "on rails". This is neither a good thing or
>a bad thing, seems to me. All depends on what the author decides is
>the best way to achieve his/her own personal creative orgasm and make
>the game "work".
>
>What say you?
I say this: I think it has to do with building trust between the
designer and the player. If you make it clear to the player that the
game cannot be put in an unwinnable situation, then he is more likely
to accept such a loss and conclude it is part of the story.
Also, I think that if it is clear that the loss of the item always
happens under a certain condition which cannot be avoided, the player
will accept it as well. I don't think you can ever rule out a
undo-save-restore loop completely, as players are usually curious what
different paths are possible within a game.
If, however the loss of the object is something that seems to be a
random event (like the pirate stealing something in Advent) then the
player is logically concluding that he was just having bad luck, or
that there was a puzzle to be solved.
-------------------------
"Hey, aren't you Gadget?"
"I was."
(To send e-mail, remove SPAMBLOCK from address)
Andrew Plotkin
> I say this: I think it has to do with building trust between the
> designer and the player. If you make it clear to the player that the
> game cannot be put in an unwinnable situation, then he is more likely
> to accept such a loss and conclude it is part of the story.
What if the game *can* be put into an unwinnable situation? It's still
a pretty common game format, in this community.
Harry
<erky...@eblong.com> wrote:
>Here, Harry <gad...@spamblockhaha.demon.nl> wrote:
>
>> I say this: I think it has to do with building trust between the
>> designer and the player. If you make it clear to the player that the
>> game cannot be put in an unwinnable situation, then he is more likely
>> to accept such a loss and conclude it is part of the story.
>
>What if the game *can* be put into an unwinnable situation? It's still
>a pretty common game format, in this community.
>
Well, if the game can become unwinnable at several points during play,
and the player is not told this (allowing him to keep on playing while
he has no chance of reaching the end anymore) *and* the designer
throws non-puzzles at him which seems to imply that he has put the
game in an unwinnable state, then I say: you created this mess, you
sort it out. Then it is just bad game design. Or at the very least
questionable game design. Nope. It's just bad. Sorry.
Quintin Stone
> I'm not sure this is a real problem. As others have said, as long as
> there's something else to do, the fact that some avenues never produce
> anything is probably a *good* thing, from a game design standpoint. If
> you haven't, play 'So Far' for some examples of avenues that never pan
> out that serve to both keep you involved and experimenting in the world,
> as well as making the world seem bigger than it is.
When I played 'Jigsaw', there's a point at which something is stolen by a
bird. As the original poster wrote, I believed that the puzzle was to
prevent its theft. It wasn't until I read a walkthrough that I realized
that the puzzle was to get it back. I agree, this is an issue that needs
to be addressed. The best solution I can think of is to do what Michael
suggests, make it clear that the game continues and that they may see it
again. I don't think you can really have your cake and eat it too.
Either the player believes they can prevent it, or you tip your hat and
reveal that the plot is railroading the player just a tad.
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/
Daryl McCullough
>> The puzzle that the player must solve is to figure out that there
>> *is* no puzzle to solve. It's a meta-puzzle.
>
>This is a good description from the designer's (or critic's) point of
>view, but it doesn't help the player at all.
>
>When the player hits a puzzle and fails to solve it, he tries harder.
>When the player hits this metapuzzle and fails to "solve it", he tries
>harder *to do the wrong thing*. What sort of clues do you provide to
>lead him out of this blind alley?
Well, the clue that there is no solution is that every attempt at a
solution fails.
Yes, I know that if the player never "gets" it, then he will be
extremely frustrated. But isn't that true of any puzzle that is
too difficult for the player to solve? The playing experience of
the player isn't changed by the *existence* of a solution if he
never discovers that solution.
Actually, I think I'll take this opportunity to change the subject
slightly to make a general point about hard puzzles.
If the solution to the puzzle is something that makes sense in
hindsight (as opposed to a solution that requires the player to
perform a precise sequence of completely unmotivated actions),
then finally discovering the solution can be a real "rush";
like a moment of satari, or instant enlightenment in Zen. So
there is a point in having difficult puzzles, because if they
are well-done, it feels so good when they are solved. (I don't
know whether that's like hitting yourself in the head so that
it will feel good when you stop.)
However, for the people who never solve the puzzle, it is
extremely frustrating. It makes them feel stupid. It makes
them angry.
I guess it might make a sense for a game designer to say: I don't
care about those people, I'm only interested in entertaining that
self-selecting group that will actually stick to my game until
they solve it. What would be wonderful (if you can pull it off)
is to manage to write a game that is enjoyable and satisfying
to those unable to solve all of the puzzles, and still provides
that sudden enlightenment satisfaction for the few, the proud,
the true adventurer.
Brendan
> The best approach I can think of, from the designer's point of view,
> is to write the scene well enough that it's clearly part of a *good
> story*. If the player has a sense that what's happening is part of the
> story you intended to write, he'll be more inclined to roll with it.
<snip>
> Low-level design patterns which apply:
>
> - Have a broad shape to your game, so that there are always two or
> three different areas the player could be working on. When the player
> hits your "unsolvable puzzle", he may pound on it for a while, but
> then (hopefully) he'll give up and go work on another part of the
> game. If he makes ongoing progress overall, he won't come back and
> start pounding on the problem event again.
>
> - When you take away the item (your example), write the event to
> strongly motivate a new goal. In other words, have an obvious
> direction to chase off in to get it back. The player never *will* get
> it back, but he'll be pulled into the next part of the story. (You
> would then have to work the "loss" storyline reaction into later parts
> of the game, as opposed to have a big immediate mourning scene.)
Yes, these are all valuable considerations. These, and other comments
in this thread, highlight the "chicken and egg" of story development and
puzzle design. It seems to me that neither should "come first".
Rather, the trick is to identify at the outset an IF project that exploits the
peculiar nature of IF, rather than trying to _force_ a pre-conceived story into
interactivity, or forcing pre-conceived puzzles into a story. That's
where the real art of IF now lies these days, seems to me. And it's
probably the toughest part of creating IF: developing an idea tailor made
to exploit the genre.
As for some comments made by others in this thread, I can only say that the
topic, the "dilemma", arises _because_ of a concern for fairness to the
player. There's nothing wrong with creating an interesting, dynamically
changing world. It's just a matter of being sensitive to the potential
impact of it upon the player. Hordes of beta testers probably creates the
most reliable "sensitivity" for a writer.
Cheers,
Brendan
David Brain
wrote:
> Actually, I think I'll take this opportunity to change the subject
> slightly to make a general point about hard puzzles.
>
> If the solution to the puzzle is something that makes sense in
> hindsight (as opposed to a solution that requires the player to
> perform a precise sequence of completely unmotivated actions),
> then finally discovering the solution can be a real "rush";
> like a moment of satari, or instant enlightenment in Zen. So
> there is a point in having difficult puzzles, because if they
> are well-done, it feels so good when they are solved. (I don't
> know whether that's like hitting yourself in the head so that
> it will feel good when you stop.)
>
> However, for the people who never solve the puzzle, it is
> extremely frustrating. It makes them feel stupid. It makes
> them angry.
>
> I guess it might make a sense for a game designer to say: I don't
> care about those people, I'm only interested in entertaining that
> self-selecting group that will actually stick to my game until
> they solve it. What would be wonderful (if you can pull it off)
> is to manage to write a game that is enjoyable and satisfying
> to those unable to solve all of the puzzles, and still provides
> that sudden enlightenment satisfaction for the few, the proud,
> the true adventurer.
Maybe, and maybe not. I designed "Sun and Moon" as a set of puzzles with a
linking story. Owing to a design mess-up, there is a sort of hour-glass shape
to the puzzles, so that to progress to the final part of the story the player
has to solve a ludicrously obscure password puzzle, to which there is
apparently one - and only one - clue! Once they have passed that point,
however, there are several solutions to the final puzzle, depending upon which
of the earlier puzzles they have solved (indeed, I think that one of the key
puzzles has yet to be solved by anyone other than one very persistent
beta-tester!)
But I specifically arranged things so that someone ought to have been able to
get to the final part of the story having only partly solved only one of the
intervening puzzles. I have no evidence as to whether this strategy worked - as
noted, I got an earlier bit wrong which probably stopped the majority of players
anyway :-( - but I suppose that inherently I agree with the principle that the
game really should be "solveable" without perhaps all the intricacies
necessarily being essential to completion.
--
David Brain
London, UK