Disabling Undo
ravi...@linux.kirbynet.lafayette.edu
This is an opinion poll of sorts, and I'm fairly certainly it's been
brought up before, but:
I'm designing a puzzle that would be possible to solve via trial and error
using the UNDO command. I don't want this to happen. There is nothing in
the puzzle that will kill the player or (unless there's a bug) put the
game in an unsolveable state.
However, the puzzle could be solved very handily by guessing a part of the
solution, seeing if the desired outcome was achieved, and then, if not,
undoing and trying again.
The puzzle COULD still be solved via trial-and-error without using UNDO,
but it would be much more annoying to do so.
Essentially, I want to do everything in my power to make the player
actually SOLVE the puzzle the right way. There are enough clues and
hints, and the puzzle is logical enough (I hope) that this can be done.
So (after all this), my question to you is:
Would you be annoyed if a game disabled the UNDO command temporarily. If,
during the course of this puzzle, the player typed UNDO, the message would
come back:
[I'm sorry, but the UNDO command is temporarily disabled.]
I already know that one game (the endgame of DELUSIONS) did this. How did
people feel about it?
I also know that certain interpreters (ie FROTZ) allow the player to get
around the "no undo" problem with the ALT-U command. However, if players
are willing to go this far to cheat, then it's their own loss if they feel
the puzzle was too easy.
Thanks,
d
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Matthew Daly
In article <8623203...@dejanews.com> ravi...@linux.kirbynet.lafayette.edu writes:
>
>Would you be annoyed if a game disabled the UNDO command temporarily. If,
>during the course of this puzzle, the player typed UNDO, the message would
>come back:
>
>[I'm sorry, but the UNDO command is temporarily disabled.]
Yup. Is there another way around it? Here is a transcript that
would get around it in some instances.
--------
The troll raises his club over his head and runs toward you, screaming
"Me spare your life if you know me favorite color!!"
> TROLL, YELLOW
The troll pauses in mid-run and looks deep in thought, as if he cannot
remember his favorite color. "That might be it. Me not sure."
> WAIT
The appearance of a 20-watt bulb appears in the troll's mind. "Me
remember now -- you wrong!" The club takes your head clean off
-- relatively painless, actually.
You have died. Would you like to Restart, Restore, Undo, or Quit?
> UNDO
[Move undone]
The troll pauses in mid-run and looks deep in thought, as if he cannot
remember his favorite color. "That might be it. Me not sure."
------------
-Matthew
--
Matthew Daly I feel that if a person has problems communicating
mwd...@kodak.com the very least he can do is to shut up - Tom Lehrer
My opinions are not necessarily those of my employer, of course.
Stephen Granade
On Tue, 29 Apr 1997 ravi...@linux.kirbynet.lafayette.edu wrote:
> Essentially, I want to do everything in my power to make the player
> actually SOLVE the puzzle the right way. There are enough clues and
> hints, and the puzzle is logical enough (I hope) that this can be done.
At some point, though, you have to sit back and hope the player will
catch on. If not, they're going to brute-force it. The only way you can
require that I solve a puzzle in one specific way is to narrow my range
of actions, which I will not like.
> So (after all this), my question to you is:
>
> Would you be annoyed if a game disabled the UNDO command temporarily.
If you disable UNDO, will you also temporarily disable SAVE/RESTORE? It
would be very easy for me to save my game, try an action, and restore,
thus effecting an UNDO.
If you disable UNDO, I would be somewhat annoyed. If you also disable
SAVE and RESTORE (which I think you must in order to get the effect you
want), I will be very annoyed.
Stephen
--
Stephen Granade | "It takes character to withstand the
sgra...@phy.duke.edu | rigors of indolence."
Duke University, Physics Dept | -- from _The Madness of King George_
Andrew Plotkin
Matthew Daly (da...@PPD.Kodak.COM) wrote:
> In article <8623203...@dejanews.com> ravi...@linux.kirbynet.lafayette.edu writes:
> >
> >Would you be annoyed if a game disabled the UNDO command temporarily. If,
> >during the course of this puzzle, the player typed UNDO, the message would
> >come back:
> >
> >[I'm sorry, but the UNDO command is temporarily disabled.]
And, as mentioned elsewhere, you'll have to disable save and restore as
well. (I disagree that this is more annoying than disabling undo, though.
As long as it's for a short scene, it really comes to the same thing.)
> > UNDO
> [Move undone]
> The troll pauses in mid-run and looks deep in thought, as if he cannot
> remember his favorite color. "That might be it. Me not sure."
This is probably a better solution. You could even make the last message
out-of-game-context:
> UNDO
[Move undone.]
[The combination lock is now scrambled, you sneak.]
And the same thing after RESTORE; this would keep people from complaining
about unsavability.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
C.E. Forman
ravi...@linux.kirbynet.lafayette.edu wrote:
>Would you be annoyed if a game disabled the UNDO command temporarily. >If, during the course of this puzzle, the player typed UNDO=
, the message >would come back:
>
>[I'm sorry, but the UNDO command is temporarily disabled.]
Spellbreaker's "real cube" puzzle did this with SAVE and RESTORE, and
I'm glad it did. But Spellbreaker (sort of) gave a reason for
disallowing it (magical protection). It'd really help if you could
come up with something similar. Personally, I wouldn't object to it,
as long as everything else you've said holds true. (Make darn sure
there isn't a bug in your code, though!)
>I already know that one game (the endgame of DELUSIONS) did this. How >did people feel about it?
Don't ask me. I'm just an author. No one ever tells me what they
think. Then again, I haven't received any complaints about it.
(Players, take that as a personal invitation, if you will.)
--
C.E. Forman cefo...@worldnet.att.net
Author of "Delusions", the 3rd place winner in the 1996 I-F Competition!!
Release 3 is now at: ftp://ftp.gmd.de/if-archive/games/infocom/delusns.z5
Read "XYZZYnews" @ http://www.interport.net/~eileen/design/xyzzynews.html
Ye Olde Infocomme Shoppe http://netnow.micron.net/~jgoemmer/infoshop.html
Mary K. Kuhner
I wouldn't mind losing UNDO as I never remember to use it, except
occasionally when I die stupidly. But if you disabled SAVE/RESTORE
(those would be my cheating method, if I decided to cheat) you would
annoy me--now if the doorbell rings I can't save my game.
I'm not sure trying to stop the player from cheating is worthwhile.
Presumably a cheating player has decided that the game will be more fun
if he cheats. Personally I'd be inclined to trust his judgement,
especially if your game has given some solid indication that there
*is* a non-brute-force solution. Maybe he's missed all the clues
leading to the preferred solution, and the choice is between cheating
or quitting. I look back much more fondly on games I solved by use of
hints or cheats than games I abandoned unsolved.
Mary Kuhner mkku...@genetics.washington.edu
Andrew Murie
ravi...@linux.kirbynet.lafayette.edu wrote in article
<8623203...@dejanews.com>...
> So (after all this), my question to you is:
>
> Would you be annoyed if a game disabled the UNDO command temporarily.
If,
> during the course of this puzzle, the player typed UNDO, the message
would
> come back:
> [I'm sorry, but the UNDO command is temporarily disabled.]
Why are you doing this? Are you trying to force people to get the
satisfaction of solving
a puzzle? that seems a futile objective. more realistic is to create a
puzzle which will
be satisfying to solve (and if it's as good as you're saying, it probably
will be.) Then people
who care about that will get what they want out of your game. someone less
concerned
about logically solving the puzzle will get what they want. Eventually,
just to be consistant,
you would have to disable undo, save and restore every time the player
faces a challenge.
And that would annoy everyone.
Besides, there will be walkthroughs, hints and solutions available soon
enough. Look at the
discussion of 'tryst' on rec.games.int-fiction within a few days of it
appearing on ftp.gmd.de
People can choose to solve the game on their own, using logic, or not. The
best you can do is
possibly provide a minor inconvienence.
IMHO, you're better off creating a quality game that people can enjoy
playing, then let people
play it the way they want, not the way you've forced them to do it.
> I already know that one game (the endgame of DELUSIONS) did this. How
did
> people feel about it?
Haven't played it, so can't comment on it specifically.
But by the time you get to that stage, you'll probably have a few saved
games. In which case
you can go back and try again and again, if you want, anyway.
Michael Straight
On 29 Apr 1997, Matthew Daly wrote:
> In article <8623203...@dejanews.com> ravi...@linux.kirbynet.lafayette.edu writes:
> >
> >Would you be annoyed if a game disabled the UNDO command temporarily. If,
> >during the course of this puzzle, the player typed UNDO, the message would
> >come back:
> >
> >[I'm sorry, but the UNDO command is temporarily disabled.]
>
> Yup. Is there another way around it? Here is a transcript that
> would get around it in some instances.
>
> --------
>
> The troll raises his club over his head and runs toward you, screaming
> "Me spare your life if you know me favorite color!!"
>
> > TROLL, YELLOW
>
> The troll pauses in mid-run and looks deep in thought, as if he cannot
> remember his favorite color. "That might be it. Me not sure."
>
> > WAIT
>
> The appearance of a 20-watt bulb appears in the troll's mind. "Me
> remember now -- you wrong!" The club takes your head clean off
> -- relatively painless, actually.
>
> You have died. Would you like to Restart, Restore, Undo, or Quit?
>
> > UNDO
>
> [Move undone]
>
> The troll pauses in mid-run and looks deep in thought, as if he cannot
> remember his favorite color. "That might be it. Me not sure."
I'm not certain, but couldn't you get around that by typing:
>TROLL, YELLOW.W
and then UNDO if you got it wrong? At least in Inform, UNDO seems (at
least some of the time, I'm not sure if it's consistent) to undo the last
line of input rather than the last command.
Michael Straight is saying this from memory and could be wrong.
FLEOEVDETYHOEUPROEONREWMEILECSOFMOERSGTIRVAENRGEEARDSTVHIESBIITBTLHEEPSRIACYK
Ethical Mirth Gas/"I'm chaste alright."/Magic Hitler Hats/"Hath grace limits?"
"Tight Camel Hairs!"/Chili Hamster Tag/The Gilt Charisma/"I gather this calm."
Andrew Plotkin
Michael Straight (stra...@email.unc.edu) wrote:
> On 29 Apr 1997, Matthew Daly wrote:
> > > UNDO
> >
> > [Move undone]
> >
> > The troll pauses in mid-run and looks deep in thought, as if he cannot
> > remember his favorite color. "That might be it. Me not sure."
> I'm not certain, but couldn't you get around that by typing:
> >TROLL, YELLOW.W
> and then UNDO if you got it wrong? At least in Inform, UNDO seems (at
> least some of the time, I'm not sure if it's consistent) to undo the last
> line of input rather than the last command.
Ouch! I bet you're right. This is a serious obstacle for anyone who wants
to block save/restore/undo in an Inform game.
We may have to retreat to a position of just never writing puzzles that
are amenable to brute force. (See years of past discussion on this
topic... of course, a lot of the other dodges also cause player annoyance
or realism flaws. Can't win.)
I suppose an acceptable library hack is to block multiple commands
whenever you block save/restore/undo.
> command . command
Command done.
[You cannot enter multiple commands right now.]
This is unlikely to bother the player, since multiple commands on a line
get used where the player wants a repeat known actions, not explore
unknown actions.
Tom Spindler
>I'm designing a puzzle that would be possible to solve via trial and error
>using the UNDO command. I don't want this to happen. There is nothing in
>the puzzle that will kill the player or (unless there's a bug) put the
>game in an unsolveable state.
>
>However, the puzzle could be solved very handily by guessing a part of the
>solution, seeing if the desired outcome was achieved, and then, if not,
>undoing and trying again.
I believe that in Sorceror, the 'choose the correct unmarked cube' puzzle
doesn't actually determine the 'correct' cube until you've eliminated
the incorrect ones - thus rendering any amount of undos and save/restoring
useless.
(I think this is mentioned in the invisiclues/solution book from LTOI.)
Den of Iniquity
On Tue, 29 Apr 1997, Andrew Plotkin wrote:
>> > UNDO
>> [Move undone]
>> The troll pauses in mid-run and looks deep in thought, as if he cannot
>> remember his favorite color. "That might be it. Me not sure."
>
>This is probably a better solution. You could even make the last message
>out-of-game-context:
>
>> UNDO
>[Move undone.]
>[The combination lock is now scrambled, you sneak.]
>
>And the same thing after RESTORE; this would keep people from complaining
>about unsavability.
Whoa! What if the player has correctly solved the information-deducing
puzzle and is in 'intellectual possession' of, eg, the passcode... Then
just before they come to the door they accidentally do something else awry
(spend the zorkmid on a red herring, for example). They hit restore or
undo to go back a move or ten... Wallop! The answer is changed. Or they
mistype the code on entering it.
-> type '921'
<Whoops>
-> undo. type '912'
Hang on?
Think very, very carefully about the viability of answer scrambling.
--
Den Sending unsolicited mail? Insert '.ignore.this.bit' after my address.
Adam Dawes
Hi Matthew!
MD> Here is a transcript that would get around it in some instances.
[having to wait to see the outcome]
But again, all the interpreters that have out-of-game-context undo functions
(Frotz, for example) can undo (multiple times) without requiring the use of the
UNDO command. AFAICS, you're never going to get around that..
.\dam. [Team AMIGA] //\ Ad...@darkside.demon.co.uk \//
> http://www.rdainfotec.demon.co.uk/adam/
> http://www.geocities.com/TimesSquare/1225/
athol-brose
In article <9705022...@darkside.demon.co.uk>,
ad...@darkside.demon.co.uk says...
> But again, all the interpreters that have out-of-game-context undo functions
> (Frotz, for example) can undo (multiple times) without requiring the use of the
> UNDO command. AFAICS, you're never going to get around that..
This is one good reason why this thread should not be called "Disabling
Undo". Instead, we should be thinking about how we can design compelling
adventure-game puzzles which do not fall into the "screw-it-up-once-and-
you're-dead-or-unable-to-continue" mold.
"Monkey Island", a game often mentioned in fond tones around here, is an
example of this kind of game. Very very very hard to get yourself killed
or painted into a corner, and yet, I still find myself going back to play
it. (Hey, I never did finish it. I play a lot of games, and finish only a
few. Doesn't mean I don't like them, I just drift on to other things.)
There's no need to recall 'past lives' in this game, because you can
always go back and do things again or in a different way without save or
undo.
Matthew Daly
In article <5k62dg$8...@nntp5.u.washington.edu> mkku...@phylo.genetics.washington.edu (Mary K. Kuhner) writes:
>I wouldn't mind losing UNDO as I never remember to use it, except
>occasionally when I die stupidly. But if you disabled SAVE/RESTORE
>(those would be my cheating method, if I decided to cheat) you would
>annoy me--now if the doorbell rings I can't save my game.
I suppose if someone were really interested in doing so, one could
set up RESTORE to delete the saved game, so that you couldn't use
it as a method to try taking multiple paths. This, of course, is
something that would have to be done by the interpreter instead of
the data file.
When all is said and done, though, I like the system as it stands.
I understand that an author might not like the way that I play his
game, and that his brilliantly-executed puzzle (to his mind) might
be sullied if I looked at it and decided to solve it by mindless
mimesis-fouling brute force, but is it not my right as a consumer
to not enjoy the game to its fullest potential if I so wish? :-)
Andrew Plotkin
athol-brose (cinn...@one.net) wrote:
> In article <9705022...@darkside.demon.co.uk>,
> ad...@darkside.demon.co.uk says...
> > But again, all the interpreters that have out-of-game-context undo functions
> > (Frotz, for example) can undo (multiple times) without requiring the use of the
> > UNDO command. AFAICS, you're never going to get around that..
> This is one good reason why this thread should not be called "Disabling
> Undo". Instead, we should be thinking about how we can design compelling
> adventure-game puzzles which do not fall into the "screw-it-up-once-and-
> you're-dead-or-unable-to-continue" mold.
That's actually not quite right. There are lots of puzzles around which
you only get one shot at; I consider this acceptable if (A) I know it's
that kind of a game, and (B) save and undo are available (ie, just about
always.)
The problem comes when this kind of puzzle *also* has the feature that a
moron can solve it by trying every possibility, mechanically. That makes
it a boring puzzle, because I, at least, am going to solve it mechanically
rather than bothing to think. And then I will complain that I was bored.
This is thoroughly annoying of me, but it's what I'm going to do. Heh.
Disabling undo makes this situation less boring, because I can't go
through and solve it by brute force. This is really how I react, as a
player. (Of course, you'd better make it *clear* that brute force won't
work. If I try every possibility, restoring each time, and *none* of them
work, because you silently jiggered the restore function, I'm going to be
thoroughly pissed.)
If disabling save/undo is not to your taste -- or impossible --
we have a large library of other ways around this situation:
* Don't let the player guess. "You spin the dial a few times, but since
you have no idea what the combination is, you give up."
* Jigger the answer so that it's never what the player tries, until the
player gets the correct information.
* Build the puzzle so that there are an nigh-infinite number of
possibilities to try. "You set the orange dial to 34513, the green dial
to 82211, and the mauve dial to 14227..."
* Give the player the benefit of the doubt, and allow a brute-force
solution, but print enough information so that the player at least *sees*
the storyline. "'Aha,' you say, 'if I ask you about the *left* door, then
you'll lie, so whether it's a Thursday or not, the sentence will mean the
opposite of what you said...'"
* Write a different damn puzzle.
All of these are varyingly useful. The worst case is probably logic
puzzles, where there is no other information in the game for the player
to stumble across. The player *can* figure out the answer without any
typing, so there's no way for the game to distinguish logic from a lucky
guess.
And it's all very well to say "Write a different damn puzzle", but
I don't believe in making barriers for the author. If you want to throw a
logic puzzle into your game, you can legitimately ask how to do it; it's
no fair me telling you "don't do that".
Matthew Daly
erky...@netcom.com (Andrew Plotkin), if that is your REAL name, said:
[much snipped]
>And it's all very well to say "Write a different damn puzzle", but
>I don't believe in making barriers for the author.
The alternative is making barriers for the player, and I don't generally
believe in that.
Well, there are different ways of doing that, and some are more
pleasant than others. If I'm trying to open a combination safe,
and the games says "Yeah, like I'm really going to enter every
possible combination," then I'll understand that brute-force isn't
the solution.
To give a concrete example, I didn't make it through the first
hundred moves of Jigsaw without a walkthrough. I searched high
and low for instruction manuals for all of the different "wierd"
items that had been given to me, and I thought that my problem
was that I couldn't find them. The actual problem was that I
didn't realize that I was expected to fiddle with the devices long
enough to figure out how they worked.
I thought that I was playing a Zork II type of game, and I was
actually playing a Savage Island II type of game. No harm, except
that I felt that MAYBE I could have figured it out if I knew that
I had to figure it out.
So now I've gone to play Curses, and I'm stuck inside this book
that I don't know how to get out of. I'll be damned if I have
a walkthough spoil the challenge for me this time, although I
admit that I haven't played the game in some time now because
I can't figure it out and still don't have enough of a feel to
know if I'm lacking information or equipment or if I need to
accomplish some quest or just find the right command to type in.
I don't know where all of this is going (except as just a general
rant), but let me try to sum up. When a game is written well and
I click well with it, I don't get syntax errors (except for spelling).
I'm telling my player character what to do, and she does it. But
when the game is talking to me instead of my player character, I'm
not interacting with a universe any more, I'm sitting in front of
a computer. If I run across a puzzle that is amenable to brute
force, I SHOULD be so deeply engrossed in the universe that it wouldn't
strike me as possible to unwrite my history. But If I make an earnest
search for the solution, and it's not there, I'd damn well better
be able to unwrite my history.
If I typed UNDO and the game said "I'm sorry, Dave, I can't do that",
you're in dire jeapordy of my next command being QUIT and the one
after that starting with DEL. :-) (And yes, Spellbreaker came really
close to that line with the pile of cubes puzzle.)
Andrew Plotkin
Matthew Daly (da...@PPD.Kodak.COM) wrote:
> erky...@netcom.com (Andrew Plotkin), if that is your REAL name, said:
> [much snipped]
> >And it's all very well to say "Write a different damn puzzle", but
> >I don't believe in making barriers for the author.
> The alternative is making barriers for the player, and I don't generally
> believe in that.
If the author makes a puzzle (scene, whatever) then the players can decide
whether they like it or not. If the author is blocked from making the
puzzle -- because of convention, or technology flaws, or whatever -- then
neither the players nor the author have anything at all.
Esa A E Peuha
athol-brose <cinn...@one.net> wrote:
: "Monkey Island", a game often mentioned in fond tones around here, is an
: or painted into a corner
There's at least one way to do each of these. When you are trapped
underwater, just wait long enough and you'll die (after seeing a pretty
funny joke). When you get the banana picker, if you don't return it to
the castaway (what's his name?) before leaving the cannibals' village,
you'll be stuck forever, because the castaway can never be found again.
: There's no need to recall 'past lives' in this game, because you can
: always go back and do things again or in a different way without save or
: undo.
Mostly true. Dying underwater is clearly an intentional design decision,
but the other thing seems very much like a bug (since the player knows
that the banana picker must be given to the castaway, it should be
impossible to leave the village before doing so).
--
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/
Mark Green
> through and solve it by brute force. This is really how I react, as a
> player. (Of course, you'd better make it *clear* that brute force won't
> work. If I try every possibility, restoring each time, and *none* of them
> work, because you silently jiggered the restore function, I'm going to be
> thoroughly pissed.)
I thought that a number of brutable puzzles worked this way: the required
information wasn't computed until it was found within the game. If the
player comes to the puzzle and the information hasn't been computed yet,
all responses are wrong. "Delusions" did this, I think.
Mg
--
James Cole
Esa A E Peuha <pe...@cc.helsinki.fi> wrote:
>athol-brose <cinn...@one.net> wrote:
>: "Monkey Island", a game often mentioned in fond tones around here, is an
>: example of this kind of game. Very very very hard to get yourself killed
>: or painted into a corner
>
>There's at least one way to do each of these. When you are trapped
>underwater, just wait long enough
10 minutes - the time that Guybrush tells the pirate elders he can hold his
breath for.
> and you'll die (after seeing a pretty
>funny joke).
I'm don't recall this, what is it?
> When you get the banana picker, if you don't return it to
>the castaway (what's his name?)
Hermann Toothrot.
> before leaving the cannibals' village,
>you'll be stuck forever, because the castaway can never be found again.
Off the top of my head, I don't think this is correct. You can use the banana
picker to pick bananas to give to the monkey. That means that you wouldn't be
able to give it to Hermann straight away. I've done this and haven't run into
the problem you mentioned.
>: There's no need to recall 'past lives' in this game, because you can
>: always go back and do things again or in a different way without save or
>: undo.
>
>Mostly true. Dying underwater is clearly an intentional design decision,
>but the other thing seems very much like a bug (since the player knows
>that the banana picker must be given to the castaway, it should be
>impossible to leave the village before doing so).
Or you must be able to find him again, which I'm pretty sure you can do.
---------------
James Cole
jrc...@ozemail.com.au
James Cole
Esa A E Peuha <pe...@cc.helsinki.fi> wrote:
>James Cole <jrc...@ozemail.com.au> wrote:
>: Esa A E Peuha <pe...@cc.helsinki.fi> wrote:
>[...]
>: >and you'll die (after seeing a pretty
>: >funny joke).
>
>: I'm don't recall this, what is it?
>
>Two pirates appear. One tells the other he's just killed someone with a
>knife and is going to throw it away (to where Guybrush is) in case they
>find his fingerprints on it.
>
cool. I don't *think* I've seen this. Every time I play this game through
again I discover something new.
[...]
>
>: >before leaving the cannibals' village,
>: >you'll be stuck forever, because the castaway can never be found again.
>
>: Off the top of my head, I don't think this is correct. You can use the banana
>: picker to pick bananas to give to the monkey. That means that you wouldn't be
>: able to give it to Hermann straight away. I've done this and haven't run into
>: the problem you mentioned.
>
>I always got enough bananas already, so I couldn't use the picker to
>actually pick bananas. I don't have the game anymore, so I can't test the
>way you played, but perhaps you could try mine (there are bananas in the
>cannibals' sacrifice altar).
>
I'll try it sometime. But as I'd have to play the game right from the very
start I don't think I'll get around to it for a while.
---------------
James Cole
jrc...@ozemail.com.au
Esa A E Peuha
: >underwater, just wait long enough
: 10 minutes - the time that Guybrush tells the pirate elders he can hold his
: breath for.
: >and you'll die (after seeing a pretty
: >funny joke).
: I'm don't recall this, what is it?
Two pirates appear. One tells the other he's just killed someone with a
knife and is going to throw it away (to where Guybrush is) in case they
find his fingerprints on it.
: >When you get the banana picker, if you don't return it to
: >the castaway (what's his name?)
: Hermann Toothrot.
: >before leaving the cannibals' village,
: >you'll be stuck forever, because the castaway can never be found again.
: Off the top of my head, I don't think this is correct. You can use the banana
: picker to pick bananas to give to the monkey. That means that you wouldn't be
: able to give it to Hermann straight away. I've done this and haven't run into
: the problem you mentioned.
I always got enough bananas already, so I couldn't use the picker to
actually pick bananas. I don't have the game anymore, so I can't test the
way you played, but perhaps you could try mine (there are bananas in the
cannibals' sacrifice altar).
--