Alternate Reality Game puzzle design

This article is being highlighted as one of Gamasutra's top stories of 2013.

Introduction

A 'game' can be built in any sufficiently complex system. It does not need to limit itself to traditionally game-specific platforms, be they hardware or software. It's quite possible to break outside the usual boundaries and use the real world itself as the setting for your fictional game world - reusing existing physical, logical and societal rules and constraints to implement your game.

This is the Alternate Reality Game.

But, in a world of near-infinite complexity and endless interlocking systems, how do you tell your players what's part of the game and what's an irrelevant part of reality? How can you design puzzles where literally anything could be interpreted as a clue?

In this article, I'll be describing the puzzle design behind Valve's Portal 2 announcement, in which players across the internet collaborated in decoding mysterious audio broadcasts, brute-forced an MD5 hash then redistributed never-before-seen imagery from Portal 2, obtained from an incredibly slow, 1980s-style bulletin board system. A 21st-century treasure hunt, built using real-world systems and knowledge.

A relatively small-scale, incredibly low-budget project. Estimated time to 'solve' the intial puzzles: seven hours.

Actual time to solve: seven hours and sixteen minutes. This wasn't an accident.

Background

I've always been obsessed with the literary concept of the 'false document' - fictional worlds extended through apparently real maps, documents, letters and systems. Various creative writing exercises even from primary school included detailed maps and plans for imaginary locations and buildings, artificial letters and newspapers - carefully crumpled, torn and artificially aged with tea and flame.

Extending this kind of behaviour to the computer world made more than a little sense. My level design career started more as fulfilling a desire to create new worlds than from a want to play more computer games - soon releasing well-received maps for Doom 2 without having ever finished playing through either Doom 1 or 2.

The website for MINERVA, my Half-Life 2 game mod, ended up being effectively in-fiction, with the character Minerva giving motivations, cryptic archive materials and disguised download links in the form of a broken scientific report - relaying her findings in this fictional world.

Along the way, I inadvertently acquired a job at Valve. How should I announce this to the fans?

Quite obviously, it took the simulated form of a post-apocalyptic numbers station, seemingly broadcasting numbers (in Polish!) which encoded a secret message. EBCDIC text, GPS coordinates for the Valve office - those fans figured it out pretty quickly. I definitely learned not to underestimate their sleuthing capabilities.

Portal 2 announcement

Fast-forward a few years to being happily installed at Valve. We were due to announce Portal 2 to the public, and had lined up a mainstream marketing push through Game Informer magazine. Excellent for the wider market, but what about the fans who'd lived and breathed the original Portal?

We'd been thinking about making some completely unexpected changes to Portal - adding, unannounced, some mysterious new content which Portal fans would enthusiastically decipher, thereby revealing the upcoming Portal 2 for themselves before anyone else. Steam made such updates incredibly simple - freely pushing out new content to everyone who owned the original game on Steam. To do something similar on the consoles would have involved a nightmarish level of bureaucracy.

Soon enough, the Portal 2 announcement ARG was born, hereafter known simply as the 'Portal ARG'. It took the form of updating the original game to include radios scattered throughout the game's test chambers - pick a radio up and carry it through the test chamber and a strange new signal would begin to fade in - take it to the right location and a static-free signal would be picked up. Morse code beeping, peculiar squeaky-beeping suggesting other encoded information. Finding the radios was one puzzle, finding the correct locations for the new signals was another puzzle - one which rewarded players with a Steam achievement when they located them all.

 
YouTube: Portal - secret SSTV radio transmissions

(Inevitably, the more technical-minded players immediately reached into the game's data files and extracted the responsible audio files for decoding.)

First the morse code was decoded, then the squeaky-beeping was discovered to be slow-scan television - containing mysterious images containing letters and numbers, seemingly taken from bits of office and scientific equipment. These in turn were pieced together to provide an MD5 hash, which with clues obtained from other SSTV images and the morse code, was brute-forced to reveal a telephone number. Which, when called, provided a 1980s-style BBS, looping through plot fragments, ANSI-art imagery and (most importantly) ANSI-art conversions of screenshots and concept art from Portal 2.

YouTube: Valve BBS Login

Yes, the first the world ever saw of this eagerly anticipated game was filtered through a 2400bps US Robotics modem from 1987, connected to an old PC in my kitchen.

But how did players fight their way through such complexity (for instance, reversing an MD5 hash is supposed to be impossible) - and more importantly, how did we keep everyone, from bystander to elite hacker, engaged?

There's an excellent overview of the Portal ARG at the fan-operated Combine Overwiki if you're interested in the players' experiences of this first Portal ARG, as well as the huge forum threads it spawned - but we have the advantage of being able to delve behind the scenes...

Fictional rationale

In its later stages, the Aperture Laboratories facility became a huge, self-assembling robotic organism, endlessly rearranging itself in pursuit of its twisted idea of 'science'. Perhaps someone (or something) was trying to get a message out without being noticed by GLaDOS, Aperture's central artificial intelligence?

With that in mind, we looked into real-world systems for encoding information - to relay that message over a subverted communications infrastructure. Radios intended for broadcasting the scientifically-proven-to-be-relaxing smooth jazz to test subjects would be co-opted into picking up additional signals leaking from hacked computer hardware. These revealing clues would then lead to a forgotten Aperture data backup apparatus, ready to release its secret data in a (distinctly slow) deluge when another human eventually discovered it. A system set up to transmit a message about Aperture, encoded and concealed from Aperture itself.

The only public announcement of the update was a vague description - "changed radio transmission frequency to comply with federal and state spectrum management regulations". Curious players of Portal soon uncovered the beginnings of this riddle, then found it wrapped in a mystery inside an enigma, each level deepening in complexity. A tiny crack in the world they knew, opening up to reveal something else entirely. In opening the path to that new world, the ending of Portal itself would be altered to better explain the beginning of the forthcoming game.

... and now, the article:

How to build fictionally appropriate ARG puzzles that people have fun solving, and which people can solve.

How to build clues and solutions

Reusing real-world systems for encoding data is good. Firstly, it's educational! Secondly, minds far larger than your own have spent far longer than you have in creating resilient, unambiguous systems for encoding that data - and, if chosen carefully, the system will obviously contain information even when not decoded. Steganography isn't necessarily the aim - at some stages, players must notice information is there to be able to decode it.

When presented with that encoded information, someone will either recognise the system, or through research identify what it is. A real-world system responds to research rather than guesswork - Wikipedia is your best friend. (An example: I knew very little about SSTV beforehand - I got remarkably proficient in knowing of its quirks and features surprisingly quickly.)

It's important to remember that comparatively few people will be directly involved with solving the puzzles themselves. Make sure there's plenty of stuff for people less invested in the arcane details of your world - the Portal ARG had the meta-game involved with locating the radios and the signal locations, rewarding players with additional gameplay and an achievement even when the truly hardcore ARG enthusiasts had long since ripped the underlying audio files from the game and decoded them directly.

I feel the most important aspect of a puzzle in an ARG is that a correct solution must be obviously correct - any leaps of faith must immediately succeed. A very low percentage of people will solve any one puzzle; with a chained puzzle, you need to confirm that each stage is solved so that people can work on the next. Otherwise, a low percentage of a low percentage will have a chance of solving that next stage...

Design particular bottlenecks which gate entrance to the next stages. Smaller puzzles can provide clues for these - an example from the Portal ARG would be the morse code and SSTV as 'quick' puzzles, providing clues and data for the MD5 hash - the ultimate leap of faith that perhaps just one player will take. While not a perfect analogy, think along the lines of rate-determining steps where the time taken for minor steps is insignificant compared with that taken for the most difficult, the latter controlling the entire rate of the reaction.

(I seriously did have the proton-proton chain reaction ocurring at the centre of the Sun in mind when designing the Portal ARG's puzzles - the brute-forcing of the MD5 hash being the deuterium-producing event that everything depends upon. Slow, but ultimately essential.)

You can also add fixed gates to slow things down, preventing the game from exhausting itself too soon and giving players a chance to digest the materials they have uncovered. After the initial burst of puzzling, the Portal ARG had a number of additional stages we manually unlocked, such as the updated ending to Portal, the additional BBS login and so on. Even smaller things would change - I'd frequently add new items to the BBS when I'd verified that previous ones had been successfully received by everyone, providing additional fuel for speculation and giving another continued reason for players to be involved with the game.  

You should expect any and every piece of text you provide to be plugged straight into Google. The morse code containing the mysterious string '9e107d9d372bb6826bd81d3542a419d6'? Stick that in a search engine, find it's the MD5 hash for 'The quick brown fox jumps over the lazy dog'. Therefore, MD5 hashes are important!

Examples of good encodings

Part of the fun in decoding a secret message is in seeing structured information emerge from something incomprehensible. A little like developing a photo, with an image emerging from nowhere - there's a curious satisfaction in extracting data from something that already existed.

For the Portal ARG, it was decided that the very first radio that players would find would be looping through morse code - audio instantly recognisable as containing information. Other morse code radios would be scattered through the game's test chambers to reinforce the concept of them carrying information, but what else?

In trawling Wikipedia for information on the Kansas City standard, used by computers of the 1970s and 80s to save data on to audio cassettes, I came across Slow-Scan Television, or SSTV - used by ham radio enthusiasts for relaying imagery over low-bandwidth radio links. This quasi-analogue standard had the interesting properties of sounding mysterious, and of looking interestingly distorted when decoded. Analogue, noisy, atmospheric - this was perfect for encoding near-broken messages intruding in from the unknown. I ended up going with the Robot-36 standard, capable of relaying a reasonable quality colour image in a mere 36 seconds - and one of the sound engineers had great fun mangling the audio to make it both sound and look particularly distorted. (Great care was taken to avoid the information-rich parts of the images.)

A couple of permutations on audio encoding systems can be summarised as follows:

What if you need to relay some piece of information which must be given to players in a complete, error-free form? To use the telephone number for the Aperture BBS as an example - if players were to get the wrong number, either through an incorrect transcription or through guessing at missing digits, an unrelated bystander might end up severely annoyed by the resulting torrent of unsolicited calls.

Potential error-free encodings follow - but by no means an exhaustive list:

Importantly, be mysterious in your puzzles - but not ambiguous with the answers. Vigorously test-drive all clues and data - if there's any text, put it into search engines to see what comes out, and if necessary adjust the text to give better results. If you've got an image, put it into reverse image searches to see what comes up. Test the most likely lines of investigation that players will take, and design your puzzles around them.

Examples of bad encodings

Anagrams, arbitrary encodings and similar which don't lead to an undeniably correct answer. If there's some doubt or personal opinion involved in decoding, beware. You don't want people trying to solve red herrings provided by incorrect solutions - or worse, being led to real-world systems or locations which aren't part of the game.

Encoded information should be recognisable as such, even if the actual encoding is a mystery - or perhaps be hidden in plain sight, with a clear clue to its existence being brought up later. Imagine one puzzle revealing that the clues for the next puzzle were there all along...

Search results will change, and troll sites immediately crop up with any vaguely successful ARG. You need an incontrovertible chain of in-game evidence to prove new information is also in-game.

You need to authenticate what's in-game and what isn't. Official company pronouncements can be fair game for players attempting to find hidden meanings - whether those meanings are there or not. Be aware that players will attempt to follow every possible trail of information, however tenuous or implausible.

Having said that, there's still plenty of opportunity to add deliberately mysterious content. The Portal ARG's SSTV images included quite a few 'padding' images of electronics, scientific equipment and robotic hardware - amongst the screenshots, plot fragments and concept art, the BBS itself would output various inscrutable scientific diagrams specially drawn by an artist at Valve. Rampant speculation on the forums was the inevitable result - speculation anyone and everyone would participate in.

Think of an ARG as both an in-depth puzzle and a participatory work of fiction. It's not about just the game itself, it's what the community does with it.

(Was the material found on the BBS enough of a reward for players? On its own, perhaps not, but combined with the speculation, enjoyment and exploration everyone got from the game, definitely yes. It's not just the destination but the journey that counts.) 

Real-world considerations

Something that looks like 'specialist knowledge' may not be - but do ensure things are at a level where a determined participant can get to from scratch within half an hour or so. Try getting to a similar position with obvious web search keywords and other clues provided by your puzzles, adjusting them as necessary.

Part of the fun of an ARG's real-world aspects are in what it adds to the fiction - a sense of the unreal colliding with the real. But don't use an expert in any particular domain of knowledge to design complete puzzles - you want things to look super-advanced rather than be super-advanced. (Not everyone is Fabrice Bellard...)

If you're learning about new systems yourself, you'll have a better understanding as to what kind of clues you'll need to provide to help beginners.

If important information is relayed, make sure it can be retrieved by multiple participants. You don't necessarily need it to be retrievable by every participant - we spent a fair amount of time thinking about how to make collaboration between groups a requirement, with the game sharing audio files with some but not all players. Unfortunately the limited timeframe meant we couldn't implement some of the Steam-related ideas we had for discouraging players from keeping data for themselves.

One solution to relaying information could involve 'unlocking' an easily-accessible virtual gate, for example on a website or inside a computer game. The Portal ARG had the game updating itself with an extended ending once players had accessed and retrieved data from the BBS, with the BBS providing vague hints as to what was coming next. (We had planned more direct interaction through the BBS, with players entering Steam usernames for explicit recognition of their actions, but time constraints meant we were left with a more passive BBS simply outputting data to anyone who connected before we manually flipped a switch for the next stage.)

Another method could involve a difficult-to-access system or location that enough different people can get to, for example the BBS itself. Clues in the real-world could work in a similar way - only one player is needed to go there, but there would be nothing stopping more than one from arriving. But beware of stampedes and flash crowds...

Could you obtain some sort of recording of the person unlocking the next stage for everyone? Handy! Serious nerd-cred when the feat is announced to all the players.

Be keenly aware that the game intersects with reality - be absolutely unambiguous where appropriate. Going back to the MD5 hash of a phone number as an example, despite there being a very low likelihood of a false positive turning up, I checked every single US phone number for collisions, just in case. As mentioned earlier, for players to get a bystander's phone number by accident would be a Bad Thing.

Accidental false clues and connections

When players connected to the Aperture BBS, it would loop through 'data files' with numerical identifiers. One person was convinced these numbers contained vital information, so spent a very long time trying to decipher them - turning them into IP addresses then geolocating and portscanning all the possibilities in order to find the 'right' next system. However, the numbers were actually from PHP's rand() function, seeded by each data file's length for consistency purposes.

Effectively no information content, but enough to lead someone down a potentially dangerous path.

Another persistent but more entertaining false clue was present in the radio-dissolving sounds added to Portal - carry a radio into an equipment-destroying 'fizzler' field, and its removal would be accompanied by a harsh, grating, electro-mechanical sound. People were convinced they could hear voices - claiming Alyx and Kleiner from Half-Life 2 were saying Important Things, or that there was a Combine Citadel present in a spectrogram.

Actually, the sounds did contain voices - but not from the cast of Half-Life 2. It was Left 4 Dead's Midnight Riders instead!

Another, accidental false clue was in the BBS-provided GWBasic image-viewing program. The source code included an (authentically ancient) copyright date and room number for a Doug Rattmann in the comments at the top, added for purposes of verisimilitude. Of course, many people assumed the room number was for a phone extension at the real-world Valve office, so tried calling it - resulting in a very confused person in Support!

Be careful with numbers. Someone will certainly attempt to extract meaning from them, whether you intended it or not.

Reality, or game?

You need to define boundaries as to where the game ends and reality begins. In the Portal ARG, information considered 'in-game' was present in the original Portal, obtained from the Aperture BBS or in official Valve press releases and the like - never from arbitrary locations on the internet. Troll sites proliferated, confusing many - people less involved in low-level details won't appreciate existing logical connections, so a plausible-looking troll can get stuck amongst the genuine content.

Speaking of troll content - a false clue can emerge seemingly from nowhere, then persist for far longer than would seem possible, its own longevity somehow being proof of its veracity. With the Portal ARG, the phrase 'look beneath the elephant green' sprang up, allegedly arriving in an email from Valve's Robin Walker, then stuck around forever.

A blurring of the boundary between game and reality occurred due to an implementation quirk of the BBS. Partly due to the short notice and the confusion involved with a Valve office move, it was easiest for me to get an analogue phone line at my then apartment - plumbing in a 1980s-modem-compatible phone line to the new office being considered more than a little awkward. Upon setting up this new phone line, I opted to be ex-directory, hoping for a little extra privacy and not realising the impact the game would have.

Of course, when they obtained the number, people plugged it into various online services - which, refusing to admit defeat when confronted with an unlisted number, gave the address as being the geographic centre of the nearby Kirkland. So obviously, someone went to that location and had a look round, posting back details to the Steam forums.

(I had just left the office to go home, so wasn't immediately able to tell other Valve persons that the address most definitely wasn't mine - they got quite worried for me!)

Luckily, it was a public place and he didn't get in any kind of trouble, but it's worth considering the accidental effects such real-world details can have.

Another person found what he thought was Valve's current office address, and turned up at the front door hoping to track down that elusive phone line. But Valve had, just days earlier, moved to a new location - presenting him with nothing but a huge, empty void. Mind blown, he reported back to the internet that the entire company had disappeared, just like that...

A later attempt at extracting a location from the phone number involved some dodgy paid-for service - that person got an 'ADAM FOSTER' but fortunately no address. He really didn't seem to understand the game / reality boundary, despite warnings from other users on the Steam forums - it got more than a little creepy.

Someone else managed to find a personal phone number for Valve's receptionist. Fortunately for everyone, players decreed that harrassing her for information would be deeply inappropriate - they did the right thing and went no further.

People are fundamentally good, they can just get a little over-enthusiastic at time. 

Treasure hunt versus ongoing interaction

The Portal ARG was intended mainly as a treasure hunt, initially with a fixed chain of clues and puzzles. This worked well with the overall aim - letting fans of Portal know about an impending sequel before anyone else - but another, lomger-lasting approach is for the game to more directly interact with players as the 'story' progresses. Possible examples we could have used might include a live 'chat' with an 'AI' on the Aperture BBS - adjusting the game according to their input. (Players feel super-special when included in the game like this.)

An ongoing ARG suggests a much larger scale. Examples would include The Beast, which promoted the film A.I., or I Love Bees, promoting Halo 2 - the latter ARG involving GPS coordinates of payphones across the USA, with phone calls to players at specific times. Seriously impressive work, but perhaps with budgets slightly higher than the Portal ARG's $100!

More direct interaction with players can mean deliberate emphasis of clues that have been missed, or perhaps dismissal of false clues and trolls.

(I wasn't involved in the Portal 2 launch ARG, being extremely busy finishing the game itself, but I hope this article proves useful to many people thinking about some of the low-level design ideals involved in implementing an ARG!)

Fun coincidences

When you apply perhaps tens of thousands of people to figuring out a problem of your making, they'll come up with solutions you didn't know existed - weird coincidences that must have been better than intentional.

The underlying audio files for the radios added to Portal were named dinosaur[n].wav - the 'dinosaur' an inside joke referring to the antiquated technology involved. By pure coincidence, there were twenty-six of them. Also coincidentally, the voice actor for Doctor Kleiner in Valve's Half-Life series, Harry S. Robins, wrote a book called ... Dinosaur Alphabet.

Twenty-six dinosaurs, surely implying an alphabet? Definitely not an intentional coincidence, but pretty cool!

One 'flavour' SSTV image (with no clues, just padding supporting the fiction) was a noise, abstract picture of circuitry, obtained from a photo I'd recently taken at the MIT Museum in Boston. Players (manually) tracked down a clear version on my Flickr account. Interesting enough, but...

... the robot was 'HERBERT', designed to pick up empty drinks cans from the floor.

At the beginning of Valve's Half-Life 2, there's a sequence in which ... the player is made to pick up an empty drinks can from the floor.

Pure coincidence. Be prepared for it, and design your puzzles to cope with it.