Typically, an Alternate Reality Game (ARG) is "an interactive networked narrative that uses the real world as a platform and uses transmedia storytelling to deliver a story that may be altered by participants' ideas or actions", as per the Wikipedia definition.
I'll show in this article how a specific variant of Alternate Reality Games can be designed. This is the method we are currently applying at Zorean to develop the real-world forensic adventure game Mark Lane's Logs: Project H.U.M.A.N.. We could call it a Forensic Alternate Reality Game (FARG).
Comparing to Similar Approaches
By coincidence, another article has just been posted here on Gamasutra by Valve's Adam Foster regarding this subject. In his article, Adam explains how Valve designed the puzzles behind their Portal 2 announcement. To get inspiration on how to design alternate reality puzzles, I strongly advise you to read his blog post.
I'll shamelessly copy his definition of an ARG:
"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."
There are some things in common here, while others are different. Aligned with the ARG concept, in our design we set the player free from platform boundaries, letting him play on any device with Internet access. The story, the resources he'll use, the clues he'll find, and the tools he'll use are all real or based on the real world that surrounds him.
However, unlike traditional ARGs, Mark Lane's Logs' Project H.U.M.A.N. is not really played on the real world. The player doesn't have to leave his room. The game is still played in cyberspace, although the player might use real world objects to pursue his objectives, like pen, paper, scissors, (hammer?)...
This is a post-event game, that is, it's about knowing as much as possible about something that already happened. It's about forensics.
Imagine that something had happened. Something big. Traces of that event have been left on the Internet, by people and organizations that were involved. Text, codes, photos, documents, chat logs, clues, riddles. Anywhere on the Internet.
In our design, the player starts with just a SMS message from Mark Lane. From there, he has to reproduce Mark's steps, find what he found, and live a discovery adventure just like he did. The idea is to make the player feel that he's uncovering a real case. The SMS message is what's called in ARG as the Rabbithole.
Then, there is no software supplied by us. Unlike a traditional game where the player must download and run an application, there is no such thing with our approach. The initial package we must supply will contain information about how to start the game, and some initial clues, everything already disguised as part of the story.
The player is enticed to take the challenge and go out to cyberspace looking for things that will help him discover and solve the case. The truth is somewhere out there, on the Internet. He's out in the wild. The Internet is millions of times bigger than a computer game sandbox. How will the player find and follow a clue? How can we make sure the player doesn't reach a dead-end, or simply gets lost in the clue thread? I'll talk about this specific risk later on.
The player's forensic investigation job should be as close to reality as we can make it. For those gamers that only like to be firing five rounds per second, this will be dead boring. But to mystery addicts, the concept brings the puzzle adventure type to a whole new level.
To play, the player uses one or more devices of his choice (computer, laptop, tablet or phone). Specifically related to the game, the player has nothing installed in his computer, except probably for the initial package.
The game's underlying challenge is to progress as much as possible in the investigation. To progress in the game the player must work as a forensic investigator. As such, he will need to, among many things:
- Find and read Mark Lane's logs (the game's spinal cord)
- Visit websites
- Download files
- Classify and organize collected evidence
- Take notes
- Solve puzzles, riddles and encrypted messages
- Perform deductive and logic thinking
Each piece of evidence found *may* help the player discover a part of the story, solve problems and riddles, and might lead to more evidence, helping you progress further. You may add some "fillers" to confuse the player. After all, forensic investigation progresses on confusing information.
The player sets his own research methods. It's possible to play by just visiting websites, but that will leave the player far from the objective. In order to progress, he will have to use tools. Software tools, that is. The player may choose whatever software tools he has within reach to help on his investigation. He should also organize his findings, take notes, search, connect, solve, think.
The more evidence the player collects, the higher he will score. Any piece of evidence is a game item, a file that the player stores on his device (or in the cloud, if it chooses to). Clues are found on these pieces of evidence, or anywhere on the Internet, like a specially-prepared page or, even better, a legitimate, real world web page.
Unlike traditional games, where most of the game is installed or downloaded, in this game the player starts with an initial package of a few kilobytes, and could end with a few megabytes of evidence on his device.
The player is scored in two ways: a global numerical score and a completeness score. The global score is calculated according to several factors, including the type of collected evidence and the time taken to find it. Harder-to-find evidence is scored higher. The completeness score is a percentage that represents how far you have progressed in the game.
This is the system we are using for our Mark Lane's Logs : Project H.U.M.A.N. game. You are of course free to set other scoring schemes.
The story and its plot is the most important part of the game. Because ARGs are meant to be experienced, not just played, the immersion ability of the story plays a key role in player engagement.
Is your story credible? I mean, you don't expect to create a story about Middle-Earth being right next to Silicon Valley, don't you? After all, we're talking about reality here. Yes, that means no dragons too.
Does the story fit an exploration-type of game? Does the story have unique features or characters? Does it have an engaging story with multiple twists? These are all factors to consider while preparing a scenario for your players.
Building just a puzzle game would not be awesome. You put some awesomeness in the game by adding a strong underlying story, preferably regarding a very important topic. It could be political, military, criminal, or scientific. This would bring additional interest to the game.
Making It Visual
Just because there is no game running in the traditional sense, it doesn't mean there are no visuals. In fact, creating a visual experience in this type of game is imperative. The way we found to make the game much more appealing was to have Mark taking photos on his mission. This gives the player the true sensation of being there. They're like stills from a movie.
Here are some photos we are including in the game:
Some photos you can license, and others you'll have to shoot them yourself, especially those that show unique aspects of the game.
Because our Forensic Alternate Reality Game (FARG) is a post-event game, a precise timeline can be defined. In fact, it has to be. The entire game will be driven by it.
The story timeline will be split into as many steps as we desire. In our design, Mark constantly registers every detail of his mission on his rugged tablet. We call each of these steps, a log (hence the game name Mark Lane's Logs). These logs have a sequence. We call it the mainline.
How will the game events (or the steps) be presented to the player? There are several choices. It could be presented linearly or non-linearly. With the first choice, the player can only progress to a given timeline step if the previous one has been achieved. In our specific design, we have chosen the non-linear method: the player might advance in the timeline before achieving previous steps. This increases the game's difficulty a bit because the player has to be careful about the order of the narrative.
Never heard of the space-time continuum? It exists everywhere, and our game is no exception. Besides setting a precise timeline, you must set precise locations for every timeline step. This is very important as it will help the player "be there, at the right time".
Being a part of the investigation efforts, you may set location as a game item. We, at least, did it. We had to set a location for each of Mark's logs, so we took the opportunity to add this aspect to the game. In our design, the player must associate a precise location for each of Mark's logs.
How precise must be the location? That's up to you. We went as far as finding the precise location of several shops Mark will visit. And when we mean precise, we mean like ten-foot accuracy!
The puzzles to include in the game is a very flexible requirement. I mean, you can put virtually anything you can come up with. But remember, one key design principle is to chain puzzles by their difficulty level. Otherwise gaming experience will suffer and the game may feel weird.
From a simple crossword puzzle to an encryption table, anything can be used as long as you are creative. I won't show any examples here. There are plenty of examples around on the Internet.
Clues will glue the game together and are very, very important. Another critical factor is, how will the player know something he finds is a clue? A clue is something useful. Before the player's eyes, everything might look equal. Everything might look useful.
Clues can be presented directly in another game item, or they can be implied. Make sure implied clues can be "zoomed in", that is, there is some kind of selection factor that will narrow the player's search.
Trial-and-error is the life of a forensic investigator. It's part of the game. Score your game items according to your perception of how hard it is to find such item, or how hard it is to find the clue itself. Lots of flexibility here.
The Clue System
So, how can we make sure the player can follow the leads, find clues and progress in the game? And, more importantly, how to make the game accessible to both the "amateur" and "professional" investigators? And even more importantly, how to make the player's experience enjoyable and challenging to all skill levels?
The answer lies on an inverse fishbone diagram:
Well, it's not really a fishbone diagram. But it's close.
This is the heart of a FARG. The game's mainline must be the easiest part to solve and find. Alternate Reality Games are essentially networked narratives, and these narrative pieces should be the easiest pieces to find, essentially because they drive the player along the story.
All game items are chained together. To be found, one or more clues have to be identified and combined if necessary. It must then be made increasingly difficult to find subsequent game items on the same discovery path.
Note that in our design we don't score clues. Only collected game items are scored, based on our judgment on how hard it might be to reach them. Locations (L/L) are also scored, but here we add a precision factor. The closer the player gets, the higher the score will be. The numbers shown next to the game items are their base score. It's called a base score because there are other factors that you can apply, like "time erosion": the later you are, the less valuable is the clue.
This system allows less skilled players to play and progress, getting challenged by the intermediate difficulty puzzles. Hardcore players will get the chance to beat the really hard challenges prepared for them.
Real World Development
If you want to make the experience believable, sooner or later you'll bump into the need of building real-world stuff. Yes, physical things. Things you can touch. But... what for, if the game is played in "cyberspace"?
You might avoid this part, but as you know, you won't find nothing original in this world unless you create it. And that's what we did! For instance, the secret society Mark will unveil exchanges messages using an ancient cryptographic tool. For this we invented a completely new crypto system, and a new "machine". Unfortunately I can't show it before the game's release. This is something original, and you should also think the same way if you want to make the game unique and interesting.
These are real-world things we have to prepare, sometimes just to take a photo. We can't show you more than this before the game is released.
Painting objects for use in the game
Building an original "ancient" crypto device
Laying Out the Game
Because the underlying concept is forensic investigation, everything in the game's story has already happened. Contrary to most games, the user does not set the story, and has no influence in it.
The player's job is to investigate. Something that is already "there". The traces that have been left on the Internet must be set before the game launches. This has to be planned in advance, of course. You must combine this placement with the clues you have set, in order to make the player reach the desired game item.
To prepare the game you start planning where to leave the clues and the game items (these are files). You can be creative on this, using cloud storage services, registering dedicated domains for fictional organizations, hiding behind social network profiles, etc. The URLs of these items must be found by the player, and therefore a way to determine these must be contained in the game. Usually, clues will lead the player to these places.
Making It Real
The more we weave the game's story and clues with the Internet's true content, the better. The fictional characters must all have their own profiles on the top social networks. However, don't forget to comply with the network's TOS (terms of service). If you create fictional organizations and companies, you should also create fictional websites and, if you see fit, the corresponding social profiles.
In a real-world forensic adventure, you might put some answers on a news story on CNN or on the New York Times. Something about a real company or real person might help the player proceed. Involving public figures will give a lot of credibility to the story. However, be careful about in what terms you include them. My advice is to include public figures if possible, but only superficially and indirectly. You'll be safer from legal problems that way.
The ultimate idea is to intertwine the game with the player's reality so that he'll be left wondering if the story didn't actually happen.
If the player is "released" on the Internet, on his own, how can we monetize this game? The solution is to have some part of the game locked behind some software or some web site. On our design, the player signs up with a fictional governmental organization, on its web site. This site is used to authenticate the user and to update his score based on the evidence he submits. Another thing to ensure is that the player cannot progress with some occasional help from the web site.
You may find your own alternate solution. For instance, you may implement clues that can be bought, or create an "oracle" that can help the player whenever he spends some credits he purchased in advance.
How Easy It Is, After All?
Finally, you want to know if developing an ARG is an easy, quick, and low-risk idea for your next hit, right? The right answer is that developing this type of games is as hard to develop as other, more common types.
For instance, when you are developing your ARG, you need to base it on reality. Reality imposes a lot of constraints. Then, you'll have to perform massive amounts of research to build a credible scenario.
It's not quick either. ARGs are just as complex, or even more complex as a RPG or FPS game. It's just that the details are somewhere else. You don't have to deal with 3D models, textures, physics and so on, but you have to take a lot of attention to tiny details regarding information: Timestamps on photo's EXIF data must match the timeline, connections to the real world must be constantly validated, locations are (and remain) accurate, etc.
Interested in seeing how all this will come out? Follow the game's evolution on IndieDB: