This is part 3 of a 10-part series.
Now that I’ve described the plot of my stack, I’ll start explaining the details of the physical components that the people on the stack experienced on the day of. The first component I’ll describe is the Android application that the stackees used to receive clues and information during the day.
While eating a nice breakfast at the Athenaeum, the frosh received a tablet computer from the ’employees’ representing the Vector Corporation. Upon booting the device, the frosh were greeted with a screen that looked more or less like this:
The best part about the tablet computer we used? It cost $55. It’s certainly no impressive piece of hardware, but I love that we live in a world where I can buy a portable computing device that I can program for so cheap. Furthermore, as prices drop, I expect to see more of these on stacks, which can open the way to some pretty exciting demonstrations.
On the screen, the frosh could see a list of messages (which there was only one of at first) from the Vector Corporation and the AI itself, their current space-time coordinate, the current lab time (which was the same as their space-time coordinate at that time, since they hadn’t time traveled yet), the current “encryption key”, and a button that allowed them to send a “coded transmission” to Vector Corporation.
The messages served as clues and hints, telling the frosh where to go during the day. The clocks told them both the current time and what times they had jumped to. The coded transmissions were where the frosh put in passwords and other such things that they got from their puzzles so that they could receive the next clue and move on. Finally, the encryption key was mostly flavor text, although I did set up the app to send them a message mocking them should they try to send it as a coded transmission. I wasn’t sure they would try it, but it was actually one of the first things they did. I was so pleased when I saw that they had done that.
What the frosh couldn’t see is that the app was also keeping track of all of the passwords they entered and all of the messages they had ‘unlocked’ and storing it in a text file that I could check on the Caltech undergraduate-run computer cluster (the UGCS servers, for those of you who know what that is). Furthermore, the line in the screenshot above that reads “Information about the current mission will be displayed here when necessary” was a line that I could arbitrarily change remotely. It was very useful to have these features so that we could know how far our stackees had gotten on the day of. It also proved useful early on, when they entered the very first password incorrectly (having used the wrong case for the letters). On the other hand, it became all too tempting to helicopter stacker the frosh. While it was fine (in my opinion) to watch their progress, we had to restrain ourselves from sending too many impromptu messages through the app (except the snarky ones that made fun of them — those were fine), lest we ruin the puzzles or the immersion.
Thus, our app was built on top of his source code, which was reportedly written in a day before his stack ran (quite impressive). His application was built for a phone and displayed achievements, but not the actual clues for the day. Thus, my contribution was restyling it so that it looked more like a tablet application, updating the code so that it would work on the two year newer Android OS, removing some features we couldn’t use because of our hardware (his application used the phone to GPS track our group, as well as the microphone to listen in on our group — it was quite devious but hilarious when we found out), making the aesthetics and flavor text fit into our theme, and inserting all of our clues and hints. Since the tablet was such an integral component of our stack, it really, really could not fail (we had a backup plan but it wasn’t nearly as good). I basically didn’t touch the server side code at all, since I didn’t need to. This was fortunate, since I’m not familiar with Perl at all.
Second, the one advantage we foresaw with having the app was that we didn’t have to spend the entire night before laying out our paper clues, since we didn’t really have paper clues. This was incredibly nice, since we could get our clues done much sooner. However, all of those hopes of saving night-before stress were fruitless, despite having started our stack quite early. It’s always that last 10% that gives you trouble, as anyone who has built a large scale project knows.
In the next post, I will describe my favorite physical puzzle on our stack, and one of our two centerpieces: the mirror maze. Unfortunately, the stackees didn’t really capture any video of themselves doing the puzzle, but the puzzle was so good that we ran it with five or six more groups over the next two or three days, so I have a video of one of those runs to show you. Until next time!