MITMH 2020: 2019 Sep

Careful: I'm pretty blasé about spoilers for this year-old hunt. If you haven't already solved the puzzles you wanted to solve, maybe don't keep reading.

Every so often, fearless leader Corey sent out a "State of the Hunt" email. Here are some excerpts from September's emails to let you know what the writing team was doing. (And to remind me, as I write this, what we were doing.)

I’m happy to share that we have several tracks with lots of activity. The Hunt server is nearly feature-ready for BTS [Big Test Solve, a planned weekend-long test of our first three rounds of puzzles], including some admin status pages and the early parts of our hint system. You can see some samples of art on #art and these will get more polish after BTS. Most puzzles for BTS will be ready but a few will come in only next week, so there’s a mild scramble going on there. A few handful puzzles have been HTMLified and the rest of the production work is being queued up. We have an intro skit sketched and we’ll try that out at BTS next weekend. Finally, all five of our events have active discussions now and we’re going to test one or two of them in the Bay Area running of BTS.

It’s probably obvious but all the attention presently is focused on BTS—it’s the deadline looming next and it’s big. After next weekend, we’ll review what worked and what didn’t for BTS and make adjustments. Even now, though, please do write yourself notes about what it’s been like for preparing for the test solve. Those notes will be super helpful when we post mortem and figure out what needs to change!


The last week of August, I'd been scrambling to move needed-for-BTS puzzles through the pipeline. I'd scrambled to keep the flow of puzzles smooth, to not leave too many puzzles for the last minute.

But the next week, that stopped. There were puzzles that were still far back in the pipeline. But those puzzles weren't something that I could help out on. Some puzzle authors were struggling. Some puzzles would come in at the last minute.

I kept my mind off of the upcoming last-minute crunch by working on some of my own puzzles.


Around this time, there was a big Slack-discussion about challenge coins. People had opinions. I learned that challenge coin shops will make pressed-penny-shaped coins.


Then it was more scramble, scramble, scramble with last-minute work leading up to the Big Test Solve. In theory, we wanted all of our puzzles to have been testsolved twice before we HTMLified them. In practice, that's not how it went for these last-minute puzzles. We wanted HTML puzzles so Tech Czar Doug could test our early-draft hunt web server. So we went ahead and converted some untested last-minute puzzles, knowing we'd have to re-do that work after testers found issues.

(Later in the year, I noticed that many puzzle authors were confused about the steps in our pipeline. I suspect that's partly because I jumped in and did out-of-order steps without pointing out that I was doing so. Alas.)


I attended the Big Test Solve, hanging out at Rich and Kiki's house. There wasn't much for me to do, though. I was spoiled on all of the puzzles, thanks to having planned their HTMLification. You might think "He could have acted as 'HQ', then, doling out hints and such." But fearless leader Corey and editor-in-chief Yar, similarly spoiled on everything, had that well in hand. I did some strategic eavesdropping to find out what sorts of snags folks hit on some puzzles.

[Our videochat connection to the Boneless Chicken contingent in Virginia] [Nerds testsolving] [I think Kiki took this photo of me] [Nerds testsolving] [Nerds testsolving] [testsolving Whack-a-Mole] [Nerds testsolving]

BTS had been a great success at getting some deadline-driven puzzle authors to buckle down and finish their puzzles. It worked so well that we quickly announced BTS2, another Big Test Solve.

BTS, retroactively called BTS1, had tested the first ⅓ of our hunt. BTS2 would cover the middle ⅓.


The week leading up to BTS1 had been pretty frantic. The week after, I took things pretty easy. I did a little HTMLification, worked a little on my own puzzles. But mostly I did other things.


Over the course of August-September, some people joined Team Left Out so they could help write/run Mystery Hunt. If not for them, the hunt would have been missing some expected features; so I'm pretty glad these folks joined. I'm reluctant to point out who they are, though. I know some Hunt old-timers feel strongly that you must earn the right to run Hunt by winning Hunt. (This attitude explains why I'd participated in Hunt for the previous few years: I wanted to help run hunt but did not want those old-timers to throw rocks at me.) Anyhow, some folks joined the team around this time and, in hindsight, I'm pretty glad they did. And those old-timers might be glad, too, if they knew what these folks ended up doing.


When HTMLifying physical puzzles, we created two versions of the puzzle's web page.

These "static" pages meant that folks reading about the Hunt afterwards could still solve some steps of the puzzle. There's a strange transition: the static web page starts with the text that teams saw, but then "breaks the fourth wall," telling the reader what teams saw during the hunt. I styled the text differently.

Once I'd made a few of these pages, I realized I was making more work for myself. Instead of setting up a shared stylesheet style, I was styling each "fourth wall" paragraph by hand. That was silly. I asked Tech Czar Doug to set up a shared stylesheet style. He didn't go for it: making those after-the-hunt pages wasn't a priority right then.

In hindsight, this was a bad tradeoff. Over the coming months, I'd set up plenty more "fourth wall" text. Other production folks would, too. Instead of pointing them at a shared "fourth wall" style, I had to tell these folks to set up a copy of the style for that individual puzzle. It predictably slowed us down. As a silver lining: I predicted that it would be a bad tradeoff, so at least nowadays I can act smug and put-upon about it.

On the other hand, I failed to predict something more important about these "static" web pages:

Most of the emphasis of the MIT Mystery Hunt is (sensibly) on teams playing at/near MIT campus. But there are plenty of "remote" teams playing in Chicago/Melbourne/London/Wherever. Though the running team concentrates on the experience of the the at-MIT teams, if there's an easy way to improve things for remote teams, that's good.

Those "static" pages aren't just good for the after-the-hunt web site. For many puzzles, static pages are good for remote teams, too. Like after-the-hunt web visitors, remote teams can't visit HQ to pick up that physical jigsaw puzzle or whatever.

Our hunt web server knew which teams were local and which were "remote". In hindsight, I wish the server could have shown the static pages to remote teams (maybe not for all puzzles, maybe just for specially-tagged puzzles?).

We were already doing the work to make remote-friendly versions of our puzzles. But since we didn't realize this early enough, we didn't take advantage of it.


The web was still a mess of almost-compatible-ness. We folks involved with presenting puzzles on a web server learned the hard way: several text-flow styles were widely supported across all modern browsers except in Mozilla Firefox when printing.

Production (converting-puzzles-to-HTML) folks had been pretty good about making sure their puzzles looked OK printed. I (and perhaps others) had been pretty good about testing HTMLified puzzles in Firefox on screen. But we mostly hadn't tested Firefox printing.

The solution was simple for web old-timers like me: pretend that we were still living in the 20-aughts. Apparently that was when Firefox-folks had stopped caring about printed output; HTML features from that time printed OK; newer features didn't.

There was still some anxiety, though. Our web server's puzzle template used a too-modern-for-Firefox layout. Even Tech Czar Doug couldn't figure out a replacement right away. So for the next few months we'd hope we were writing Firefox-compatible HTML; but we wouldn't have a good way to test it (and fix problems we found) until December.


We unsnagged our pipeline.

In the time leading up to BTS, us production (puzzle HTMLification) folks didn't want to wait for Stribs to finish fact-checking puzzles. So we went ahead and HTMLified puzzles; if Stribs found a problem in a puzzle, we redid that part. Since the problems tended to be detail-y, there wasn't much wasted effort on our end. But BUT…

But of course we could make mistakes when HTMLifying puzzles. And Stribs wanted to inspect the post-production puzzles. So he was looking over puzzles multiple times.

So we changed the order of steps in our pipeline: Stribs wouldn't try to fact-check puzzles before they were HTMLified. Instead, he'd just look at them after. (That wasn't 100% true; Stribs still testsolved plenty of puzzles in their pre-HTMLified state. But he didn't necessarily inspect them closely in that state.)

Folks familiar with the Puzzletron puzzle-tracking system might gulp nervously upon hearing this. Puzzletron expects fact-checking to happen before post-production. We skipped Puzzletron's fact-checking step, and instead fact-checked in Puzzletron's "final approval" step. Where by "we", I mostly mean Stribs.


Oct [>]

comment? | | home |