10 bits of advice for running a Mystery Hunt art team

[Note: This post will be completely boring and irrelevant if you don’t care about running Mystery Hunts, but Atlas Shrugged asked and Asheesh insisted I post it somewhere publicly. :P]

1.) On our team, hardly any of the art volunteers had web design experience. Many didn’t do digital art; quite a few didn’t even have steady access to a scanner. It’s a bit of a mismatch between skills and tasks given that the biggest, most visible responsibility for the art team is the hunt website. Thus, one of the biggest responsibilities for the art team lead is to divvy up and delegate any artistic elements of the site design that can be done independent of the HTML/CSS/etc, so that your web designers and web devs’ bandwidth can be saved for the stuff only they know how to do. For instance, I started working on the Ocean’s round design months ago with placeholders for Diana’s casino paintings. When the paintings were finished, everything else on the round was basically ready I could just plop them in. Same with the Indiana Jones map.

It’s easy for the art and tech teams to be composed of very different sets of people who don’t talk enough to each other. We were lucky this year that I knew most of the tech team and am a programmer myself for my day job, and thus could bridge that gap. I hope you have at least one person on your team who can take on that role as well! It might even be worth reorganizing so that there is an explicit ‘Web Team’ consisting of both designers and developers (and, later, post-production volunteers helping prepare puzzles for publication).

2.) Also along these lines, making it easy for non-programmers to get your hunt website up and running locally is key if you want people to contribute to your hunt site design–otherwise, they can’t see what they’re doing! For the Agent 99 round, DD designed it in some static HTML files, and I converted it to use Jinja2 blocks and play nice with the rest of the site myself. This worked okay, but meant that I was a bottleneck for any and all design changes; no one else on the art team had a working copy of the hunt web software and thus could work on this stuff. Which is not a great state of affairs.

What may be wise (and kind of what we ended up doing) is to spin off the front-end as a separate app with URLs and views, placeholder templates, and a json or Markdown file full of fake hunt data (a team, puzzles, rounds, whether things are solved or not). Asheesh also packaged all the dependencies he could into this app’s git repository, to minimize the amount of installation hassle people would have to go through. (Though there was still some hassle; yay gevent!) Having a quality README for getting things up and running, and someone to patiently mentor your designers in using source control, are key too.

The goal is to have a piece of software with easy cross-platform install instructions where designers can muck around in the templates and static files folders, modify the fake hunt state to simulate different parts of the hunt, and see the results immediately, without requiring them to know Python or Django or Flask or whatever and making any necessary use of the command line as painless as humanly possible. (For more on this, ask Asheesh. He is the helping-newcomers-be-useful-in-software-projects expert.)

3.) Less (a dialect of CSS) is awesome. You don’t have to install anything to use it, you can just include a JS file to interpret it, it makes your stylesheets so much cleaner, and since it’s a superset of CSS if there’s anybody on the project who insists on using vanilla CSS their code will still work fine.

4.) Google Web Fonts is also pretty sweet. However, regardless of the fonts you use elsewhere on the site, the div where you put puzzle bodies should use one of the standard boring web fonts (Verdana, Helvetica, Times New Roman, etc.) because some puzzles use crazy arcane special characters. Most of the fonts on GWF don’t have those, so they’ll either show blanks or just look weird.

5.) Browser compatibility was not a priority for us. Our rule was that we’d get things working in Chrome, Safari, and Firefox, and if it worked in IE too, so much the better. We also assumed browser widths of at least 950px, which I’d argue is pretty standard these days. Got a fair number of complaints about that, though–both puzzle authors complaining that the design was too narrow for their puzzle, and other team members complaining that the design was too wide for netbooks. Responsive design, and/or having a separate stylesheet for tiny screens, would have been ideal, but we didn’t manage it in all the rounds and there were lots of more important things to spend our time on. YMMV.

I don’t think any hunt to date has built a mobile version of their site. Probably because it’d be a giant pain and you’ve got a million other things to do. Not unthinkable, though, if your site design is already on the minimalist side. And imagine what you could do with it for the runaround!

6.) Something I completely forgot about until a few days before hunt was printability. Pretty sure some of our rounds fared lousy by that metric. For next year, it might be worthwhile to have a “printable version” link on each puzzle page that links to a unstyled HTML page version of whatever is in your {% puzzle_body %} block (or equivalent template architecture). Then you don’t have to sacrifice the round design for this consideration.

7.) Originally, many of the round designs included slots for correct answers on round or puzzle pages. I was convinced by my teammates that this was a bad idea because if the unlock code glitched or HQ accidentally marked a wrong answer as correct, whole puzzles or even rounds could be instantly spoiled for teams. Bad news. What we decided was a best practice (and eventually implemented, though it wasn’t finished until after Hunt started) was to have a call-in page for each puzzle which shows the list of answers that that team has called in. Since this page never asks the database what the real answer is–it only looks at call-ins–even if HQ were to screw up, it can never show spoilers, while still making it possible for teams to look up solved puzzles’ answers.

8.) The company that 3D printed this year’s coin (and last year’s coin). If you want a metallic coin-shaped coin for next year, I recommend them.

9.) Video is hard to pull off. Really, really hard. Unless it’s something you can shoot with a cell phone, nobody owns a video camera. And even if someone does own a video camera, they probably don’t own Final Cut (or equivalent software). And even if you have people who fill these requirements, getting them in the same place as your puzzle writers and actors for a whole day (even for a short video) is hard. And then when your editor or testsolvers demand changes to your video puzzle, instead of just editing a text file like a normal puzzle author, you have to haul all those writers and actors and camerapeople into the same room *again*, and make sure not to have any red herrings due to continuity errors. Rinse and repeat for the next testsolve. Video puzzles are the opposite of agile. And fact-checking or test-solving a script is simply not good enough.

Video is ridiculously resource-intensive. Only do it if you’ve got a really, really good reason and all the people involved are living in the same place. (Opening ceremony is probably a good reason, though–especially since that doesn’t typically need testsolving.)

10.) Watch out for spoilers in your CSS files (and other static files). We missed this this year. Based on some of the id names in the CSS file that appeared on the enigmavalley.com login page (which was findable based on the Hunt invitation), at least one team was able to guess coinheist.com and found its login page–the only thing between them and a view of the Hunt website in a fully-solved state–a few days before Hunt started. Whoops. (They never managed to log in there, thank goodness, but it sent the tech team into a panic as we quickly changed our passwords to be much more secure and swept our CSS files for spoilers.)

Similarly, ideally, you should only be able to access a round’s static files when that round itself has been unlocked–otherwise, the URL should 404. This was something that this year’s hunt site architecture handled quite well. I wouldn’t worry about this until close to Hunt, though–juggling lots of different stylesheets and JS files across multiple folders is a pain when you’re just trying to get started on a design.

Oh, hm. One more bit of advice occurs to me, though who knows if this falls under the purview of the art team or the tech team:

11.) Set a deadline, after which the canonical version for all the puzzles gets moved from Puzzletron to your hunt website git repo and if authors want changes after that date, they have to make them (or request that they be made) in the site code. (Textual edits can be made via Github’s visual editor, so even non-techies can fix typical errata after this date if you show them how.) We failed to do this, which resulted in sleep madness Thursday night due to not knowing which puzzle files we could declare done and move over and which ones people were still tweaking.