Here is a game.
A recap of the SMS scavenger hunt designed for the end-of-2012 Baxter Invitational.
First Evanston succumbed, then Skokie. Zombies. Lake Michigan bubbled with gassy green froth, moreso than usual. Beachgoers, used to minor rashes and mid-coast flotsam, transformed and quickly brought the infection within city limits. And The Drudge Report felt compelled to precede the headline with “CHICAGOLAND:” as if this stuff happened every day.
Were it not for the spirit of mirth and teamwork of the Baxter Invitational, all would have been lost. But the SMS-driven scavenger hunt designed by crafty Baxters @mark and @kat brought out the best in ‘em. Their premise, designed to challenge and amuse their fellows, was as simple as it was topical: some scoundrel known as the @baxterzombie had targeted Chicago, Illinois (location of the Invitational) for zombified, green-gas destruction.
As the Baxters trickled in to the Windy City, so too did the mysterious text messages of nefarious intent. Some players received direct threats, while others received news reports of nearby mayhem. They pieced together the story and, with the help of a backpack o’ clues, set off in response. After all, @baxterzombie threatened to unleash his undead terror if they didn’t comply.
The race-against-the-clock scavenger hunt to follow, punctuated with chin-scratching riddles and wordplay, was a bit of ingenuity and a case study in design-for-context. Players tweeted photos in response to riddles, or as proof of arrival at a designated time-and-place. SMS messages kept teams and the villain in constant contact. Things got a bit grimy on Lower Wacker Drive. But ultimately, @baxterzombie was defeated, and the Baxters walked away with another set of snazzy tricks for location-based game design.
The foresightful designers kept a record of their successes and triumphs. And before we seal it in a rocket and jettison it into space for the benefit of carbon-based life forms everywhere, we’ve collected a few choice bits of their report below, shared in their own words:
Item 00308 – Familiarity
“We had never been to the city before creating the game. This forced us to scour over Google Maps looking for interesting locations within a reasonable distance. Without experience with the logistics travel, queuing at locations, or potential danger of certain routes (e.g. biking down Michigan Ave) we were left to make reasonable assumptions about what was appropriate.” [Editor's note: No casualties.]
Item 001815 – Technology
“An ‘App Free’ game interface: we knew we wouldn’t have time to build a mobile app for the game so we needed to create an interface with commodity features of the phone. Voice, SMS and Twitter came to mind. Kat [located in the UK] pointed out that iMessage would have allowed SMS messages across the Atlantic without extra charge. ”
Item 00754 – Urgency
“While the urgency was designed as part of the game, it really wasn’t necessary. Players were enjoying interacting along the way. Any attempt to push them to hurry would have detracted from that social interaction which is more valuable.”
Item 04471 – Adaptation
“The game would work best on an open schedule that would let you investigate each area for as long as you want. It was difficult to determine how long people would want to look around or chat before heading off. Also, with our physical delivery of destinations it was difficult to change the order after the game has started. If those had been virtual, at the time each location was delivered, you could adjust information based on your current location. (e.g. something isn’t always “West” if you skipped a step.)”
Item 00095 – SMS Comms
“SMS messages allowed us to send text instructions to the player. We had a limited number of characters we could send, so we delivered very brief instructions about which clue envelope to open. We could send a series of predefined game messages via the command line, and leveraged an existing tool called “rake” to run game commands, as follows:
There was also the ability to send ad hoc message:
rake send_all MESSAGE=”Everyone one will see this.”
rake send_random MESSAGE=”Who knows who will see this.”
What was missing was the ability to send message to particular people:
rake send_reply MESSAGE=”Your guess is wrong.”
rake send_to_dipti MESSAGE=”Who should I zombify? Nathan or Matt?”
The addition of both would have let us deliver a more targeted experience, but in a larger, more automated game, might not be necessary.
SMS also allowed for information to be sent back to the game masters. The interface didn’t bridge SMS to another medium. It simply echoed the SMS messages back to the admins’ phones. For example:
Player sends: “orange…your shirt is orange”
Kat’s Phone: “REC: orange…your shirt is orange”
Mark’s Phone: “REC: orange…your shirt is orange”
In addition to echoing player text to admin phones, admin phones could send all the commands available on the command line with an abbreviated syntax; sa=send all, sr = send random, c = command”:
sa: Hi everyone
sr: You’re running out of time.
Although only admin phones could issue these commands, nothing was secured on the API. Had someone stumbled onto the API, they could have easily spoofed an admin phone. This would be solved with more engineering time.
Twitter was a good mechanism for delivering photos and ensuring they would be available for other to see. Almost every phone has an app that can post to Twitter so we were assured people wouldn’t need to download anything.”
Item 19075 – Conclusion
“Civilians saved, lessons learned. And we may be onto something, too. The simplicity of SMS and open APIs allowed us designers to execute decisions with a high degree of confidence. Could other cities be next? We’ll have to pay a visit to Joliet, where the @baxterzombie is locked up and seething …”