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 AI Interface

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.

The application itself was built on top of Phonegap, a framework that allows developers to build an application that basically consists of some HTML and Javascript, and hook into some phone functions through a Javascript API. The result is an application that is easy to build and runs on most phone platforms. The server side code that received the status from the application and sent any remote messages that I wrote was all written in Perl. The idea for the tablet application came from one of the people who built the stack I went on my junior year, Patrick Xia. First of all, his stack had an android cell phone application which displayed the various ‘achievements’ we had unlocked by scanning QR codes during the day. Second of all, he was the one who showed me the $55 tablet earlier last year, before we had any idea what our stack was even going to look like. He even let me borrow his app’s source code to modify.

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.

A few miscellaneous things: First, the way the space-time coordinates clock worked is that each message had a time value associated with it (or -1 for messages that didn’t travel the group, or -2 for messages that traveled the group to the current lab time). When those messages were unlocked, the app calculated the offset in milliseconds from the current lab time and the time on the message (unless the time was -1) and remembered that. Then, there were two JavaScript date objects, one of which was initialized to the current time (plus 200 years) and the other was initialized to the current time plus the offset (plus 200 years), every time the callback (which was what also sent the current status to the server and got any messages I sent remotely) was initiated. This way, the current space-time coordinates clock ran along with the current lab time clock, as you might expect.

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.

On the morning of Ditch Day, not having slept, I ran into a major issue while I was entering all of the clues into the application. Since I had been working on lots of little things that night and the plot only got completely finished late that night as well, I started inserting the clues pretty late. Anyway, I ran into this bug where the Javascript interpreter was complaining about missing characters what turned out to be 30-40 lines away from where the actual issues were, but all of the code looked valid to me. After spending an hour and a half selectively removing code to see where the problem was, I was still nowhere, so I sent a desperate call for help to the Ditch Day list my class was using (and that our helpful alums were on). Fortunately, Patrick was magical and helped me discover that I had trailing whitespace in some lines where I was breaking strings across multiple lines (which was completely unclear from the errors I was getting, in my defense). I got the app completed and on the tablet with 20 minutes to go (and with my hopes for an hour and a half of sleep having turned into no sleep that night — thus leading to my having pulled my only all-nighter during Caltech). This is yet another reason to set Eclipse to remove all trailing whitespace on lines by default!

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!