This past spring semester (my last as an MIT undergrad), I made a puzzle hunt for a friend. Among the reasons, I wanted to go through the motions of planning, writing, and implementing a small scale version of a hunt one might encounter during the annual MIT Mystery Hunt, where puzzles may be constructed by a +100-man strong team over a year.
This post is to report on my experience and associated findings related to making this puzzle hunt. It's intended to be spoiler-free, so I'll only go over general themes that I came across, rather than the fine details. If you just want to do it, I've put it up here.
Start big picture
As with most creations, whether it be a puzzle hunt, computer program, or blog post, you can't just make it. Unless the point in part is to intentionally improvise, stuff needs planning. What does it do/communicate? Who's the audience? Is it standalone? Is there a theme? So many questions! And they all need to be answered before any doing happens.
And that is what I mean by big picture. I started with writing down general things my friend likes, and combined a couple into one hybrid theme for each puzzle. Each puzzle was designed to be standalone, with a simple overarching narrative tying them together.
Making architectural decisions
I found it helpful decomposing each individual puzzle into some number of modules (perhaps only one), each of which has its own mini-solution that is needed to solve the ensemble puzzle. How these modules connect and interact is a separate issue the puzzle master needs to figure out.
As an analogy, each module is like a function that takes input from zero or more other modules and returns its solution as an output. The modules may be arranged in series, in parallel, or in a more complex way. You can imagine drawing a wiring diagram that shows how the modules are connected. It's possible some modules are completely disconnected from the rest of the wiring. Such modules would be red herrings.
The modules (and their connections) are intentionally obfuscated, so the puzzle solver needs to do some clever trial and error to understand what the internals of each module looks like and what makes the most sense as to how they're wired. Then they can "run" the module to get its mini-solution. In this way, puzzle design is like systems engineering, and solving one is like systems analysis.
Polar opposites
Making a puzzle very much felt like solving one in reverse. When solving a puzzle, you might simply accumulate as many seemingly relevant details or hints. From there, it's a merging process, taking two or more smaller pieces, putting them together, and getting a new piece that (hopefully) is a step closer to ultimately solving the puzzle at hand.
As a puzzle master, I would start by asking what form should the final answer to a puzzle look like. What should the answer even be? Once I decided what the answer and its representation are, I thought about what deterministic process could create it, and from what smaller solutions. And so on until leaf-level elements of the puzzle were acceptably atomic.
In short, puzzle solving is bottom-up while puzzle making is top-down, which conforms to this dichotomy between puzzle solving and puzzle making.
Editing is tough
Plans aren't perfect. Midway through making a puzzle, I found myself swapping elements in and out, changing the solution, or simply tweaking the theme. Since puzzle solutions are deterministically derived, any change tends to threaten the structure of the whole puzzle, and often times making another edit (or edits) to maintain consistency was required.
This observation just emphasizes how important it is to get that initial plan as close to what you envision the final creation to be. That said, it's okay to make edits. They make the puzzle more polished and interesting, after all. Just take care not to make too many. At that point it can become frustrating.
Blunders were made
Alas, at the end, my creation was not perfect. I asked my friend for feedback afterwards. There were mistakes with the presentation (e.g. too specific flavor text) as well as with one of the puzzles (didn't account for misleading interpretations). The feedback didn't necessarily mean changes were needed (though I did tweak things a bit). Rather, it highlighted the need to "proofread" sufficiently. Thankfully, the puzzles were still polished enough for a first-time effort.
Final words
Making my own puzzle was an exercise of both a creative and technical nature. For that reason it was fun, and I would do it again.
As mentioned at the top, the puzzle is up for anyone to attempt. I hope you enjoy it!