Building up my excitement for Return to Monkey Island, I read the interview with the development and designer crew the other day: Ron Gilbert and Dave Grossman reveal their one Monkey Island regret | Eurogamer.net. I knew about the puzzle they are talking about in the article, and that it was a huge challenge to overcome for many players. While creating a puzzle that is almost too complex to solve is an honest mistake in adventure game design, it’s still annoying for a first-time player. In retrospect, it’s a funny puzzle that you get, when you get it, but is hard to complete – creating frustration for the player.
I kept asking myself how one could have avoided that – also in a more general way of preventing bugs and design defects of that nature.
The description of the puzzle in question below – beware of the spoilers.
***Spoilers start***
Description:
In “Monkey Island 2: Le Chuck’s revenge”, when you are on Phatt Island, trying to get all the map pieces together, there’s a waterfall in the left area of the island. Up hill, there’s a pump that controls the water flow of the waterfall, but there is no apparent way of how to turn off the pump. To solve this puzzle, to progress into a hole behind the waterfall, Guybrush needs to stop the waterflow, turning off the pump.
The puzzle is solved by getting arrested and being thrown in jail, freeing yourself and picking up a Gorilla envelop that contains a banana. That banana, in turn, can be used on Woodtick, where in the bar, there’s a piano playing monkey. The same bar you were hired as a cook – and left without notice. You use the banana with the metronome on the piano, hypnotizing the monkey, making it get stiff and frozen – so you can pick it up.
The monkey, then, on Phatt Island, can be used on the pump. It acts as a monkey wrench, a synonym in a few regions in the US for a spanner – a tool to tighten or loosen something. The pump would then close the water stream, revealing a tunnel behind the waterfall that Guybrush can then use.
***Spoilers end***
In a way, it’s a fairly funny puzzle, if it wasn’t unbelievably difficult – especially as a non-native speaker – to figure it out. You freeze a monkey, to become a monkey wrench, a (regional) synonym for the right tool for the job you need to complete. I think this puzzle threw a fair amount of players off for quite a while, causing some frustration. Remember, this was the early 90s. Access to the internet was rare, so really you could only call the helpline to get hints, or discuss the challenge with your friends at school or relatives that also played – and mostly they were as lost as you were (in my case).
There’s a number of things wrong with the puzzle – and I am trying to decompose that a little bit. Mind you, I wasn’t there when they built it, nor have I interviewed the creators – this is all assumptions and hypotheses.
Ultimately, there’s a few mental leaps you have to make, in order to solve the puzzle: I hear that even for native speakers and US citizens, a monkey wrench isn’t necessarily an everyday word, or a word that’s actively used and may even be regional lingo that isn’t applied everywhere. Ron Gilbert mentioned in an interview that while they knew the game was played outside of the US and got translated, there wasn’t much transparency as to how much of a success they were outside of the US – possibly a reason as to how the money wrench could end up in the game – translations and the local idioms were never cross checked to meet a global, localized bar.
What also missing are the in-game references that lead up to the puzzle. There could have been a poster somewhere, warning from paralyzing effects of local bananas on monkeys if waved in a regular, steady rhythm. Or someone calming down a monkey by presenting them with a banana on a rope, dangling rhythmically in front of them. I think two kinds of hints would have been required: one that lead to the rhythmical waving of the banana, another that hints to the monkey being used as a tool. Maybe the owner of the bar, could have told Guybrush that Jojo (the monkey turned wrench) playing the piano was, indeed, a trained handyman before, before <comical incident> happened.
The puzzle is so absurd, that there’s even a considerable amount of dedication you need to put into brute force trying combinations of things, to end up with the right steps by accident. So ending up with the right steps by accident is hard. I would argue that the wrench puzzle, to a degree is also different than many other puzzles in the game – in the sense that it is the only puzzle where you (a) steal a living thing and (b) while there’s the bar keeper standing next to you who is NOT interrupting you in doing so. I am not counting the navigator from Secret of Monkey Island – not really a living thing.
The pump isn’t help you either, hint-wise. The only thing that helped, but only after you’ve made the mental leap to hypnotize Jojo, is the little inventory graphic that Jojo gets. It may resemble a tool already.
From a software development and Product Management (PM) perspective, there’s a lot to think about: how do I create an environment, ask the right questions, have the right checks and balances in place, such that this doesn’t happen to my project, product, code? Again, listing a few possible reasons and countermeasures – I wasn’t there and therefore don’t know what really happened 🙂
One way of how this could have happened – is that PM, Engineering and test are very close with one another – which usually is a very good signal – but in this case, too close, and invented the puzzle, possibly as a joke or inside joke, together. This invalidated some of the cross-team checks and balances that the different roles would be supposed to uphold. If an idea is born and approved by all of the team, make sure you re-visit the idea a few days later, socialize it with a fellow PM, or Engineering leader and hear them out to cross-check for bias through in-team dynamics from a good lunch time.
Back then, getting your code tested wasn’t very easy. You had in-house testers, but if they were part of your team and you had socialized the puzzle with them over lunch, the mental leap can’t be caught there. Your only other chance was external testers that can validate your code and give you feedback on some of the puzzles. That’s easier today than it was back then. If you didn’t invite testers in then, you’d have to have them on the phone or send them questionnaires that may or may not surface the point. The turnaround time from supplying the code on disks or CDs to getting actual feedback most likely wasn’t great either – and for late-developed things, there may simply not have been enough time before release, to have it tested “in the wild”. That’s easier today, where you can distribute your code through various channels, give specific testers access to specific portions of your software, such as specific features, conduct A/B testing, and have them focus on specific problem areas. It’s as easy as collecting crash reports from the software and sending them back home – or measuring “time spent” in different places in the pre-release software, and let the testers manually send in the data collected back in.
Collecting feedback is easier and faster these days. With the power of the internet, you could ask a few specific questions, and gather the right data points to drill deeper into curious findings, interview testers individually (if they’re up to it) and find blocking puzzles or disconnects in UI or workflow. Leveraging today’s capabilities to keep testers or early adopter user groups close to you, may have solved this issue. As there are no boundaries in how you could form your test and validation community, you could invite people from all over the globe – with the monkey wrench raising eyebrows hopefully. It’s really more about defining the right balance and mixture of test and validation users, than anything else.
Nourishing such a testing and validation community allows for a more agile exchange on whether the product “works” and meets the technical bar – but also to determine if it supports end users in what they’re doing, if the user experience comes natural and supports existing workflows, if things are confusing. And you get to double down on responses that you get, to learn more. A few questions that I start my interaction with testers, but also customers in live products are: “Can you use the product, as-is, in production?”, “What’s the most annoying or frustrating thing about [product]?”, “What costs you the most time to complete in [product]?” – that usually leads to follow-on conversations, about where in a user’s process the product comes in, and how it supports or doesn’t support that process – and why it’s perceived as annoying. Or you find inconsistencies, bugs or ways the product is used that you didn’t know it could be used. Or simply – that you didn’t have all scenarios on your radar. Tied back to the monkey wrench – one could avoid similar defects by simply pulling a diverse group of testers and validators closer, and ask them open questions about progress, annoying things – and double down and deeper on what they report. If you had given me Monkey Island 2 to beta-test, and, say, you wanted me to complete 2 of the 4 maps puzzle in my focus group, I would sure as hell tell you that the most annoying thing was figuring out I had to mistreat Jojo. If I were able to complete it at all.
Today’s cloud software has another advantage for delivering feedback on how well specific parts of a game or software are doing: usage telemetry. Telemetry could tell you which of your service or game are the most favorite parts, where users hang out most, where drop-off-rates skyrocket and how your software is used in general. You may be able to draw a few good conclusions from telemetry, if some (anonymized) data is collected, beyond the usually more engineering-driven metrics such as performance, processing speed, peeks in connections, worker throughput, etc. knowing what telemetry to plan for is a craft in itself. But measuring the playtime it takes a user to complete specific parts, for example, when they discover the pump until they solve the puzzle, and for how long they have the ingredients, such as the banana or Jojo, would give you interesting insights into where users are blocked. Also – if you see a spike in number of tried combinations of things with the pump, you see users are desperate and brute-force their way over the puzzle. If only you could connect your computer to the internet back then!
Taking a step back, as soon as you have a pre-release of your code, and you do a bug bash or internal demo, this is the PM’s (last) chance to look over the story again – what did we set out to do, what’s the target audience, what pre-conditions have to be met so the user – or player – can use the feature, what post-conditions need to be met – or does the user have to consult documentation or training first? Is there a disconnect anywhere, from previous knowledge or steps in the process, to complete the scenario [or puzzle]? Would a user in the target audience be successful, if they used the in-product clues in the UI along the way, the in-product help, and references from other places [in the product]?
FRICKELSOFT 