SCI: PEPPER: Franklin's puzzle box doesn't appear to be solvable (bug or feature?)

[eriktorbjorn]

In Act 4 of the game, you will come across Benjamin Franklin's puzzle box, which is just a fancy 15 puzzle. The initial scramble appears to be non-random, because it always looks like this:

It matches this YouTube playthrough, which appears to have been made with DOSBox: ​https://youtu.be/CpASiXJhrcM?list=PLwprFgobvKXbqEr9DSq0TNSnfT5Tu9YZU&t=635

So ScummVM is probably doing it correctly. Turning this into a traditional 15 puzzle, this is what it would look like:

10  7 15  5
 9 12  4  2
13  8  6 14
 1  3 11

This also seems consistent with ​https://github.com/sluicebox/sci-scripts/blob/65c4100d1ba073e89290554f51acbe78777e3c95/pepper-dos-1.000/src/rm116.sc#L225

Unfortunately, this is not a solvable 15 puzzle, unless you use the "Help" button. Is that really the solution, or is there more to this than meets the eye? If it is an original bug, should ScummVM (perhaps optionally) do something about it?

[m-kiewitz]

Why is it not solvable?

[eriktorbjorn]

Why is it not solvable?

You can easily get this far:

But you still need to swap two tiles. And while I don't know how to prove it, according to ​https://kociemba.org/themen/fifteen/fifteensolver.html swapping any two tiles of a solvable position makes it unsolvable. So this would be an unsolvable position.

Now, I thought maybe it was supposed to be impossible to solve, and I had to ask Franklin for help. But he was too worried about his missing wife to give me the time of day, and you need the contents of the puzzle box to get her back. The gambler seemed like another possibility, but he didn't have anything to say about it.

Given the target audience, it seems unlikely that they would make this a convoluted puzzle. The walkthroughs I've seen just said that you have to solve the puzzle box. One did note that he was never able to do so without the Help button, because he always ended up with two pieces swapped. I haven't been able to locate any official hint book.

[m-kiewitz]

Hmm, I tried some code snippet from the internet and used your data on it, and it says indeed not solvable. When I exchange the lower middle 2 tiles 11 and 3 it says solvable.

I'm still not convinced, it would be very weird that a Sierra game, especially one for children has a 100% unsolvable puzzle included.

[m-kiewitz]

Hmmm

​https://gamefaqs.gamespot.com/pc/564732-peppers-adventures-in-time/faqs/37937
[JLR note: I never could solve the puzzle completely. I was always stuck with
2 pieces I couldn't swap, so I always click the "Help" button to finish it.
Doesn't seem to hurt the point score.

[m-kiewitz]

The puzzle is room + script 116

[m-kiewitz]

local variables 1-16 contain references to the corresponding tiles

[m-kiewitz]

Tile order seems to get set by rm116::init

lofsa t10
send $6
pushi $6e ; 110, 'n', init
push1
lofsa blankSpot
push
lofsa t7
send $6
pushi $6e ; 110, 'n', init
push1
lofsa blankSpot
push
lofsa t15
send $6
pushi $6e ; 110, 'n', init
push1
lofsa blankSpot
push
lofsa t5
send $6
pushi $6e ; 110, 'n', init
push1
lofsa blankSpot
push
lofsa t9
send $6

etc.
So one would have to replace the last 2 calls and in theory the puzzle should then be solvable.

[m-kiewitz]

patched puzzle script

[m-kiewitz]

I may have patched the script properly.
Please check.

[m-kiewitz]

Originally
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
00001008 72 7E 07 36 72 C0 01 4A 06 39 6E 78 72 7E 07 36 r~.6rÀ.J.9nxr~.6
00001024 72 84 02 4A 06 39 6E 78 72 7E 07 36 72 94 05 4A r”.J.9nxr~.6r„.J

Patched
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
00001008 72 7E 07 36 72 C0 01 4A 06 39 6E 78 72 7E 07 36 r~.6rÀ.J.9nxr~.6
00001024 72 94 05 4A 06 39 6E 78 72 7E 07 36 72 84 02 4A r”.J.9nxr~.6r„.J

0038:040a: 72 84 02 lofsa t3[09fb]
0038:0401: 4a 06 send 06

t3::init[FUNCT](0038:0ef5)

0038:0403: 39 6e pushi 6e
0038:0405: 78 push1
0038:0406: 72 7e 07 lofsa blankSpot[0ef5]
0038:0409: 36 push
0038:03fe: 72 94 05 lofsa t11[0d0b]
0038:0401: 4a 06 send 06

t11::init[FUNCT](0038:0ef5)

[eriktorbjorn]

I wonder what effect the "Help" button has on the solvability of the puzzle. It seems to just swap two tiles, so that might mean it flips between solvable and unsolvable.

[m-kiewitz]

It actually seems to solve the puzzle.
Probably puts 2 tiles into the right position every time you press it.

[m-kiewitz]

You can use the button right from the start, you just have to press it multiple times.

[eriktorbjorn]

I know. I meant that pressing it once might make the puzzle solvable, then pressing it again might make it unsolvable, and so on. But I haven't checked, and I don't have the time to do so right now. (Maybe tomorrow.)

[m-kiewitz]

I see, right. Still really really weird that no one tested it at all, especially when it's made for children.

Of course if it's now solvable, but the Help buttons ruins it, then it wouldn't really matter that much, because if someone pressed Help once, he may press Help multiple times.

[eriktorbjorn]

Yeah, even if the Help button behaves that way it's probably still not worth worrying about.

[eriktorbjorn]

I tried the puzzle a couple of times, and it does seem like pressing the Help button an odd number of times makes the puzzle solvable, while pressing it an even number of times makes it unsolvable.

This seems like a pretty sloppy implementation to me, but there isn't much we can do about that I guess. Unless there's more to this puzzle than meets the eye, I'm surprised it made it through testing. I've long suspected that Sierra's testing process wasn't as thorough as that of some other companies, but come on.

[m-kiewitz]

Actually their game testing for older SCI games was spot on.
Quest for Glory 1 had basically no bugs, and that's a 3 class RPG game with so many different ways to get through.

It got sloppy and really bad during SCI32, but also slightly before that. Quest for Glory 4 floppy probably being the worst offender.

But here we are talking about a puzzle being 100% broken and that's actually really weird. Even weirder that it's not even mentioned as a bug elsewhere. Glad that we can fix it through, still really weird.

[eriktorbjorn]

Even weirder that it's not even mentioned as a bug elsewhere. Glad that we can fix it through, still really weird.

Yeah, I've tried finding any mention of it but I guess Pepper's Adventures in Time isn't a very well known game to begin with.

I did find a mention of an official hint book, but I haven't been able to find it.

[m-kiewitz]

Sierra hint books are extremely rare.
But yes, I would like to know what kind of hints that one had for this puzzle.
Maybe "press Help" lol

[eriktorbjorn]

I did ask in a Sierra Facebook group, and while not conclusive I did get one answer from someone who had at least encountered the problem. (I was also warned that in a "budget "value priced merchandise" release" they included a piece of paper warning players about a bug where you can't feed the goat, but I think that's the one that ScummVM already fixes.)

[eriktorbjorn]

Something like this might work, then:

diff --git a/engines/sci/engine/script_patches.cpp b/engines/sci/engine/script_patches.cpp
index afc213d4607..bc1ece24592 100644
--- a/engines/sci/engine/script_patches.cpp
+++ b/engines/sci/engine/script_patches.cpp
@@ -13279,10 +13279,35 @@ static const uint16 pepperPatchGlassJar[] = {
 	PATCH_END
 };
 
+static const uint16 pepperSignaturePuzzleBox[] = {
+	SIG_MAGICDWORD,
+	0x72, 0x7e, 0x07,                    // lofsa	blankSpot[0ef5]
+	0x36,                                // push
+	0x72, 0x84, 0x02,                    // lofsa	t3[09fb]
+	0x4a, 0x06,                          // send 	06
+	0x39, 0x6e,                          // pushi	6e		; 110, 'n', init
+	0x78,                                // push1			; x
+	0x72, 0x7e, 0x07,                    // lofsa	blankSpot[0ef5]
+	0x36,                                // push
+	0x72, 0x94, 0x05,                    // lofsa	t11[0d0b]
+	0x4a, 0x06,                          // send 	06
+	0x39, 0x6e,                          // pushi	6e		; 110, 'n', init
+	SIG_END
+};
+
+static const uint16 pepperPatchPuzzleBox[] = {
+	PATCH_ADDTOOFFSET(+5),
+	0x94, 0x05,                         // lofsa   t11[0d0b]
+	PATCH_ADDTOOFFSET(+10),
+	0x84, 0x02,                         // lofsa   t3[09fb]
+	PATCH_END
+};
+
 //          script, description,                                         signature                            patch
 static const SciScriptPatcherEntry pepperSignatures[] = {
 	{  true,   894, "glass jar fix",                                  1, pepperSignatureGlassJar,             pepperPatchGlassJar },
 	{  true,   928, "Narrator lockup fix",                            1, sciNarratorLockupSignature,          sciNarratorLockupPatch },
+	{  true,   116, "Puzzle Box solvability fix",                     1, pepperSignaturePuzzleBox,            pepperPatchPuzzleBox },
 	SCI_SIGNATUREENTRY_TERMINATOR
 };

But I'm no @sluicebox, so I'm sure that patch can be refined. And of course, it'll need a comment to go with it.

[sluicebox]

Hilarious bug; great find!

Sounds like we have consensus. Swapping the last two tiles was my first thought for the most unobtrusive change, and the sample patch is how I imagined implementing it.

I used a different online solver and it agrees too. More consensus!

I'll write this up soon and give it some robustness.

This bug is simultaneously *unbelievable* and totally believable. How could you make a puzzle impossible to complete in a way that not only survived testing, but also survived players for so long that we don't see references to it online?

Because this puzzle sucks. You can hear the groans on the youtube playthough when it appears. I remember groaning the same way. You start with something that no one really wants to do and everyone can skip. But then, and here's why this puzzle really sucks: clicking anywhere outside the box kicks you out of the puzzle with no warning and you have to start over. It is so easy to do accidentally. I happened to me four times just trying to reproduce these findings, even when trying not to, and that's exactly what happened when I tried playing/auditing this game years ago. Even if you try to engage with the puzzle, it betrays you, and after the Nth time you say Oh The Hell With This and click HELP. That's exactly how I missed this! Any careful clickers who truly get stuck, especially kids, will assume the puzzle is just too hard instead of broken. But since it's not fun, they just click HELP and quickly move on and never give this unpleasantness a second thought.

And then along comes eriktorbjorn...

[eriktorbjorn]

Replying to sluicebox:

But then, and here's why this puzzle really sucks: clicking anywhere outside the box kicks you out of the puzzle with no warning and you have to start over. It is so easy to do accidentally. I happened to me four times just trying to reproduce these findings, even when trying not to,

Heh, that happened to me too! It didn't help that I was playing the game on a phone when I first got to the puzzle. If I had known what the Help button did I might not have noticed, but I assumed it would print instructions for how the puzzle works.

The good news is that I've now played through the game. There's one thing I might report as a bug later (in at least one chapter, the gambler's music would restart every time I clicked on him, even if it was already playing), but I'm going away for a few days so I won't have the time until later.

Other than that, I guess the savegame crash - https://bugs.scummvm.org/ticket/15212 - is the most serious issue I found.

[sluicebox <22204938+sluicebox@…>]

In 00adc464:

SCI: Fix PEPPER unsolvable puzzle box

Congratulations to @eriktorbjorn for discovering what has to be one of
the funniest Sierra bugs yet: a truly unsolvable puzzle.

Thanks to @m-kiewitz for the initial patch and @eriktorbjorn for the
impressively thorough research.

Fixes bug #15225

[sluicebox]

What a fun ticket!