Project Overview

In August of 2019, a small group of my friends and I are planning on running a puzzle event in the greater Boston area. This event is based on the writings of H. P. Lovecraft, who wrote a series of horror stories set on the North Shore of Boston.

The structure of the event calls for teams of 4-6 people to spend the weekend driving around the greater Boston area solving puzzles. The event will begin with a dinner on the Friday evening and kick off in earnest on Saturday morning. Over the course of the next 30 hours teams will visit a series of locations. At each location they will be presented with a puzzle, solving the puzzle will lead them to their next location.

As part of this event we are building a web based application that teams can use to check their solutions, receive instructions, and reinforce thematic elements. This document details the design of the interface of that application.

Visual Theme

While Lovecraft's works are stand-alone pieces of fiction, they have shared elements (such as locations, and characters). In particular the Lovecraft stories that take place in the Boston area often reference the fictitious "Miskatonic University" and for the purposes of our event, our participants are attendees at Freshman Orientation Weekend.

As you can imagine from an event that is based on a series of horror stories, while the weekend starts out normally enough, it quickly becomes obvious that something else is going on below the surface. By solving puzzles, participants will learn more about what's going on around them and eventually choose sides in a battle between good and evil.

Our event is broken up into distinct chapters, and our intention is for those chapters to be fairly well delineated. While part of this delineation is taken care of thanks to the structure of the puzzles, we also wanted the appearance of the application to change as the event progresses.

Over the course of the weekend teams will solve 30-60 puzzles and each time they solve a puzzle new plot information will be revealed. In an effort to reinforce the changing nature of the plot and help teams feel like they are progressing through the event, each time they solve a puzzle the background image on the main screen will change. Each individual chapter will have a visual theme made up of a series of images, and those images will transition from one theme to the next as the event progresses.

The animations below depict the changing backgrounds for each chapter of the event. Every time teams solve a puzzle, the background of the app would change to show a new image.

Friday PM

Our event starts on Friday night with an introductory gathering. After a casual dinner and some technical and safety instructions, teams will head to Hammond Castle in Gloucester, MA for the opening event. This event is structured as a college activity fair with each of the puzzles themed around a group or activity you might expect to find on a college campus. In addition to the more mainstream activities, teams will be introduced to a secret society/fraternity and discover their familial ties to the group. The final (meta) puzzle of the evening involves an image from a college yearbook. At the conclusion of the evening teams will head to a local hotel to sleep.

Saturday AM

The game starts in earnest at 9am on Saturday morning at the Masonic Lodge in Newburyport, MA. The morning's activities are structured around the first few days of school. The puzzles in this round each solve to the title of a textbook that might be found on a college reading list, and the final (meta) puzzle of the round involves the covers of those books.

Saturday PM

During the afternoon and evening hours our theme starts to transition away from the college experience and starts to introduce a little bit of mystery. Participants learn more about the secret society/fraternity that they encountered during the Friday night event. As they wind their way south towards the city they start to investigate the fraternity, and discover that the group is hosting a party that evening. This chapter concludes with teams receiving an invitation to the event.

Overnight

Arriving at the party, teams are initially presented with puzzles related to the fraternity and as they solve them they realize that something sinister is going on. This chapter concludes with teams discovering that rather than being at a fraternity party, they have lost their minds and are actually in an insane asylum. In an effort to escape the asylum, teams are given a puzzle that resembles a set of Rorschach tests. This puzzle has two possible solutions and depending on the solution teams select, they are assigned to one of two factions, those trying to save the world, or those trying to end it.

Sunday AM

This section of the event takes place on foot in downtown Boston. At the conclusion of the overnight, teams are secretly assigned to one of two factions, with one group solving puzzles in an attempt to figure out how to release the monsters and end the world, and the other solving puzzles to try to figure out how to keep the monsters from being released and save the world. The background images for this section are presented in two different colors. Teams that are trying to destroy the world will see the blue version, teams that are trying to save the world will see the red version.

Sunday PM

The event concludes in the early afternoon with a final battle. Because all the teams need to arrive at the finale at the same time, this section of the event features a number of bonus puzzles. Depending on how quickly teams have managed to solve puzzles up to this point they will end up seeing a variable number of puzzles. This section concludes on the Boston Common next to a large crate filled with tentacles.

Finale

When teams arrive at the finale location, they discover that there are two distinct factions. The two factions race again each other to solve a puzzle, with the result either dooming or saving the world. At this point teams will see one of two images depending on the outcome of the battle. If the world is saved, teams will see an image depicting the crate of tentacles wrapped in chains and hidden in an underground location. If the world is destroyed, teams will see an image depicting an opened crate amidst the ruins of civilization. At this point teams will solve one final puzzle which will conclude the event and depict a final image of a book of tentacles wrapped in chains.

Login Page

Because teams will be traveling between locations during this event we expect them to access the app from a variety of different devices over the course of the weekend. Teams typically carry laptops during these sorts of events and we would expect that most teams will access the app with their laptops in locations where wifi is available. When wifi isn't available, such as when they're driving between locations, or solving puzzles in a park, we expect that teams will access the application on their mobile devices. As such not only is it important that the app work well on a variety of devices, it is also necessary for teams to have a shared login that will allow them to access the app from any device.

In an effort to simplify the process of using the app on multiple different devices and platforms, this application is web based. When teams visit the page for the first time on a new device, they will be prompted to login. Each team will have a single username and password which can be used on multiple devices. Once logged in, as a team's status changes, the server will push updates to each device.

Because we want to minimize the application's learning curve, in order to maintain visual consistency between platforms, our application will force a horizontal layout.

Main Page

In an effort to simplify the application, the main page is a hub from which all other pages are accessed. Quick links to the other pages are available from the menu in the top right hand corner. Note that the current puzzle page is only available when a puzzle is open. When teams are in between puzzles, that option is grayed out. Similarly when teams have multiple puzzles open, links to each of the puzzles are available in the menu.

The background of the main page features a full screen image, this image is thematic and changes each time a puzzle is solved.

On the left hand side of the page is a "sanity meter". Because sanity (or lack thereof) is a recurring theme in Lovecraft's work (and one that parallels well to an event of this nature) one of the things we wanted to do was to depict a team's relative sanity and show how it changes over time. Our plan is for this meter to slowly decrease over the course of the event. It will bottom out in the early morning hours when teams discover that they are in an insane asylum, and then gradually increase again as teams choose their faction and start to take control of their destiny. Additionally, things like solving a puzzle or taking a hint would cause a momentary increase. Because we don't want players to think of their sanity level as a score, our intention is not to display this as a numerical value but rather as a meter that gives a general measurement. This meter is blue, to correspond with the convention of depicting sanity markers as blue in Lovecraft themed board games.

When teams arrive at a puzzle location they will be provided with a "start code" which is a word that they will enter into the app to let it know that they've begun work on a puzzle. The app will report this information to game control so that game organizers know what puzzle each team is working on at any given time. This information will also be utilized by the hint system to determine how long a team has been working on a puzzle and when they should receive hints.

At the bottom of the screen are one or more tabs. These tabs will change over time. If teams have an open puzzle the tab will show the name of that puzzle and clicking on it will lead teams to a page specific to that puzzle. If teams don't have any open puzzles, the tab will lead teams to the driving directions necessary to get them to their next location/puzzle. Note that it is possible for teams to have multiple puzzles open at the same time.

Puzzles Pages

When teams enter a start code they are immediately brought to a page specific to that puzzle. That page features basic information about that puzzle such as its title, flavor text, and a description of the puzzle elements.

From a game control point of view, it's really important to keep the event moving as there are a certain number of puzzles and locations that players need to visit, and many of them are time sensitive. In order to help with this process, our intention is for our app to give puzzle hints at various intervals. While these intervals are primarily determined by how much time has passed since players began working on the puzzle, in an effort to even things out, team progress also factors into it, with teams that have seen less overall puzzles being provided hints at a slightly faster rate than teams that have seen more puzzles. As such, over time hints will start to appear on the page. When new hints appear they will have a small drop down arrow next to them so teams can easily determine which hints have and haven't been viewed. Once a hint is viewed the arrow disappears.

A text box for teams to submit answers is at the bottom of the screen. If teams submit a correct answer they will be brought to a new page featuring story elements and driving directions. If a team submits an incorrect or partially correct answer, a popup message will appear informing them that their answer is incorrect or partially correct. Once they click ok, the answer they submitted will appear on the list of attempted solutions.

At the very bottom of the page is a link to the driving directions that got teams to their current location. These are provided in case a team leaves a location (because they need to use the bathroom or get something to eat) and wishes to return. Note that teams will only ever have access to the pages for their current puzzle(s) and most recent driving directions. This is done in an effort to simplify the application and make sure that teams don't confuse themselves by accidently revisiting an old puzzle or set of driving directions.

In addition to regular puzzles, teams will also encounter "meta puzzles". Meta puzzles are puzzles that require the answers from earlier puzzles in order to solve them. In the case of our event, meta puzzles occur at the end of each chapter. While meta puzzles are a popular mechanic in East Coast games, they are rarer in driving events of this nature and as such we wanted to make sure that when teams encountered a meta puzzle they were aware that they had done so. Additionally, as some of our faster teams will see extra puzzles we needed a way to provide teams with information as to which puzzle answers were necessary to solve a given meta puzzle. Our solution was to add an image to the top of the puzzle page for each meta. Not only will the image show the list of prior solutions necessary to solve each meta, it will also serve as a visual indicator that there is something different about this puzzle.

Driving Directions

When teams successfully enter a puzzle solution they are taken to a congratulatory page. This page confirms their solution and presents them with further information about the evolving plot. In many cases this page will include a short audio clip. This is our opportunity to provide flavor and reinforce the story that we're trying to tell. Note that towards the end of the weekend teams are divided into two competing sides (those trying to save the world, and those trying to destroy the world). While the puzzles that they solve will stay the same, their reasons for solving them will be very different so the content shown to each team will be customized based on which side they've chosen.

At the bottom of the page is a drop down that will allow teams to view the driving directions necessary to get to their next location. When teams click that link, they are given the address of their next location, a Google Map showing that location, and some useful information about that location (such as whether or not the location has food or bathrooms). A special instructions field allows us to give teams additional information about the location such as recommended driving instructions or parking information. One of the reasons that we opted for a web app instead of something more self-contained was that if necessary we wanted the ability to make changes to these instructions on the fly. For example, if on the day of the event we discover that a road is closed for construction, we can edit the instructions to route teams around it.

Story Synopsis

One of the things that really distinguish this type of an event from other types of puzzle hunts is the immersive theme that permeates it. Unfortunately the mental strain of constantly moving from location to location while solving puzzles can make it hard to follow a plot and in the past we've found that teams have to be constantly reminded of what's going on. In an effort to help with this, one of the pages, accessible from the drop down menu on the main page, contains a synopsis of the evolving story. Each time teams solve a puzzle, this page will be updated to reflect the evolving plot. Any audio clips that teams receive when they solve a puzzle will appear on this page so that teams can review the plot at any time.

Codes and Ciphers

In the course of solving puzzles, teams often need access to basic codes and ciphers such as semaphore or morse code. In addition to the usual encoding methods, our event will feature at least one custom code. Rather than print this out and hand it to teams on paper, it and other encoding methods will be available on the codes and cipher page. This page is accessible from the drop down menu on the main page.

Contact Page

Because of the nature of this event, it is important that teams be able to contact event organizers at any time. To ease this process, and ensure that teams don't lose the necessary phone numbers, a contact page is included. It is accessible from the drop down menu on the main page.

Development

While the design of this application is my own, the event for which it is intended is a joint project between myself and a number of my friends. As this event is something that we have been planning for several years, it was important to me that their desires be included in the development of the application. As such, my first step in designing the application was to meet with my team to solicit their input as to what needed to be included in the final design.

Based on that conversation, I quickly realized that the app needed to convey a significant amount of information. From there I sat down and took some time to make sense of it in my own head and to figure a way to organize it.

I divided the information up, determined what pages would be necessary, and started to figure out how the various pages would be linked together. I knew from the conversation with my teammates that they wanted the visual look of the app to change over time. Because our event is divided into such distinct chapters, it seemed obvious that these chapters would each require a distinct appearance. However I was determined that functionally the app would continue to work the same way throughout the event with only the visual skin changing over time.

Photos of my sketchbook detailing my initial thought process, in particular my attempt to determine how many pages and visual skins would be necessary, and what information would appear on each page are available here.

One of the challenges of this app is the fact that teams won't receive access to it until the event begins. As such while it needs to provide teams with a significant amount of information, it needs to do so in a way that is intuitive and doesn't require a steep learning curve. As a result a real effort was made to simplify the app, and the navigation between pages. Most notably, I decided to use the main page as a console from which all other pages were accessed. With the exception of the driving directions and puzzles pages, which have direct links back and forth to each other, all of the pages of this application are accessed from the main screen. This simplifies the mental map of the application, and ensures that users return to the main page again and again.

One of our main concerns was that over the course of the event, users would be presented with so much information that they would get bogged down in it. It was easy for us to imagine sleep deprived people accidently opening up the wrong puzzle, or using the wrong set of driving directions to accidently return to an old location. To address this concern, it was decided that teams should only ever have access to their current puzzle(s) and driving directions. All old data would be removed from the app as soon as a new puzzle or set of driving directions was revealed.

One of the elements that sets this kind of an event apart from other puzzle events, is the importance of the plot and pervasiveness of thematic elements. Unfortunately we know from experience just how easy it is to get distracted by puzzles and sleep deprivation and lose track of the plot. As such while we wanted to eliminate old pages with outdated information, we didn't want our teams to lose access to the developing story elements that they encountered after successfully solving each puzzle. The solution was to create a story page that would be updated overtime. This page would archive any plot related audio clips or media that teams were given, and provide a easy way for teams to refresh themselves on the evolving plot.

Once I had an idea of the number of pages and skins that would be necessary, and how I wanted to organize the information, I created a set of wireframes. When the wireframes were ready, I reviewed them with my puzzle writing team, and did some user testing. Based on my observations, and the feedback I received, I refined the wireframes.

A detailed description of the final wireframes is available here.

Once the wireframes were complete, I turned my attention to the visual appearance of this application. It had already been decided that the different chapters should have different visual looks, and since the wireframes had determined that we weren't going to be displaying a lot of data on the main page, I realized that I wanted to use that space for some large imagery.

I've taken part in a lot of puzzle events over the years, and while not all puzzle hunts use digital answer submission systems, many of them do. At this point in the process, I took a bit of time to do some research and look back at the visual appearance of some of the events I've participated in over the years. One of the things that struck me was that for a lot of events, solving a puzzle results in a visual change to the page. In most cases this change is very small. For example, during the 2018 MIT Mystery Hunt, puzzles could be accessed by clicking on small spheres on the side of the main page. As the theme of the 2018 MIT Mystery Hunt was Pixar's movie "Inside Out", these spheres were intended to represent memory orbs and when a puzzle was solved, the corresponding sphere would turn from gray to a color.

While it had already been decided that we didn't want teams able to access old puzzles, my teammates did like the idea of a state change after each successful solve. The thought was that not only would this be a fun thematic element, it would also serve as a reward for teams.

I spent some time trying to figure out what kind of imagery to use for each chapter. We'd determined when we first started planning the event that we didn't want any aspect of it to be scary or gruesome and it was also important to me that the background images reflect the theme of each chapter. For example the Saturday morning portion of the event features a set of puzzles that solve to the titles of books that one might find on a college reading list, as such it seemed logical that the background imagery for Saturday morning might feature textbooks gradually accumulating on a desk.

I brainstormed ideas for the imagery of the various sections and then realized that I could use the imagery to transition seamlessly from one chapter to another with the last image of one chapter, serving as the starting point for the next.

While there were a number of approaches that I could have taken to create the imagery, I liked the idea of using photography, especially as it was clear that the later chapters would require photographs of things that one wouldn't normally encounter. Not only did a photograph of a crate of tentacles seem far more interesting than a drawing of the same thing would have been, it also made it seem a little bit more real than an illustration would have.

As a proof of concept I put together a storyboard in the form of an animated gif. This proved useful as I was able to use it to not only communicate my idea to my teammates, but also to plan the eventual photoshoot.

After several iterations, my team approved the storyboard and I turned my attention to preparing for the photoshoot. This process involved assembling the materials I would need for each of the scenes and making a series of props.

I turned a dictionary into a old creepy looking tome, created (and aged) custom pages for inside the book, 3D printed and painted some derelict buildings from Thingiverse, designed and laser-cut a miniature crate, created a set of plush tentacles, made a fake polaroid photo, and painted a wall in my attic so that I could use it for the background of my set.

With the assistance of a friend, I took the necessary photos and then strung them together into an animated gif to illustrate my concept.

While I liked the initial photographs, after some discussion it was determined that based on the theme of the event, the artwork needed a darker feel to it. After some experimentation, I decided to remove the color from the images except for whatever element had most recently been added and was currently the focus.

Once the photography was taken care of, I set to work finalizing the visual design. I created a variety of visual mockups and played with font pairings.

With regard to fonts, I selected Raleway for page headings, tabs, and buttons due to its light strokes and elegant open design. I decided to use Open Sans for the majority of the body text because it was specifically designed to be easy to read on digital displays and small screens. Both fonts are licensed openly and easily integrated into CSS and mobile apps.

Typography
Raleway Page Headings - Black 50pt Text Fields - Grey (#999999) 18pt Submit Button - Black 18pt Menu Items - Black 18pt Tabs - Black 18pt Unavailable Menu Options - Grey (#999999) 18pt
Raleway Medium View Driving Directions - Black 16pt Capitals
Open Sans SemiBold Section Headings - Black 14pt Link Between Pages - Blue (#00468C) 13pt Story Page Chapter Headings - Black 14pt Capitals
Open Sans Regular Page Text - black 14pt Incorrect Answers - Black 14pt Capitals Local Page Links - Grey (#999999) 16pt Login - White 18pt

A document showing early experimentations with the visual design is available here.

Once I was happy with the design of the various pages, I created a clickable mockup of the site. This allowed users to view the various pages and get a feel for the navigation between them.

User testing went well, though as expected it identified a few minor issues. For example, unbeknownst to me the convention in most Lovecraft themed board games is to use blue tokens to represent sanity, as such the color of the sanity bar meter was changed to blue to ease identification. Other problems led to the addition of an interstitial popup message when teams input an incorrect, or partially correct solution.

The final clickable mockup is available here.

Credits

This project would not have been possible without the help of the following people:.

App Developer: Mark Asdoorian
Photographic Assistance: Jason Sproul
App Testers: J. Heléne Andersson, Mark Asdoorian, Carol Carveth, Ross Corliss, Jess Foley, Lauren Haffner, Jess LeBlanc, Mike Morse, Jason Sproul
Content Development: Carol Carveth, Nathan Fung
Tech Support: Mike Morse
Sewing Assistance: Lauren Haffner
Additional ArtWork for Ancient Tome: Ross Corliss
Puzzle/Event Development: J. Heléne Andersson, Mark Asdoorian, Carol Carveth, Ross Corliss, Nathan Curtis, Joel Fried, Nathan Fung

Works Cited

2018 MIT Mystery Hunt. [Screenshot of Interface]. Retrieved 25 January 2018 from https://head-hunters.org.

4997826. [Untitled image of orchestra]. Pixabay. Retrieved 15 April 2018 from https://pixabay.com/en/classical-music-orchestra-choir-2199085/.

Barni1. [Untitled image of hurdles]. Pixabay. Retrieved 15 April 2018 from https://pixabay.com/en/sport-athletics-659224/.

Caigan, Khem. "Book Cover." 1977. The Necronomicon. Simon, Schlangekraft Inc / Barnes Graphics Inc., New York.

DariuszSankowski. [Untitled image of an open book on a desk]. Pixabay. Retrieved 30 March 2018 from https://pixabay.com/en/knowledge-book-library-glasses-1052014/.

Ethan3D. "Destroyed Building with Rubble". 2017. Thingiverse. Retrieved 17 March 2018 from https://www.thingiverse.com/thing:2049484.

FallenXBlade. “Warhammer 40K Broken Building Corner.” 2015. Thingiverse. Retrieved 17 March 2018 from https://www.thingiverse.com/thing:1092770.

Matteson, Steve. "Open Sans." Google Fonts. Retrieved 18 April 2018 from https://fonts.google.com/specimen/Open+Sans.

McInerney, Matt et al. "Raleway." Google Fonts. Retrieved 18 April 2018 from https://fonts.google.com/specimen/Raleway.

StartupStockPhotos. [Untitled image of man writing on whiteboard]. Pixabay. Retrieved 15 April 2018 from https://pixabay.com/en/whiteboard-man-presentation-write-849812/.

StockSnap. [Untitled image of graduation]. Pixabay. Retrieved 15 April 2018 from https://pixabay.com/en/people-men-women-graduation-school-2562626/.

StockSnap. [Untitled image of library]. Pixabay. Retrieved 15 April 2018 from https://pixabay.com/en/library-books-shelves-student-922998/.

StockSnap. [Untitled image of woman reading]. Pixabay. Retrieved 15 April 2018 fromhttps://pixabay.com/en/table-chairs-sofa-people-alone-2593395/.