Curated by: Luigi Canali De Rossi

Friday, January 12, 2007

Alternate Reality Games: Design, Development And Implementation (Part III)

Sponsored Links

In the first part of this paper we provided an introduction to Alternate Reality Games, whereas in the second part we covered a large variety of games within ARG. This section addresses the specific details and design choices faced when developing an ARG. There are a number of routine challenges faced by every ARG team, and a number of common mechanisms have come into play to solve them. There is no need to reinvent the wheel with each game.


Each development team should use caution, however, before relying on the methods described here as their sole resource. The games widely credited as the most successful usually blaze trails by inventing new methods and mechanics and implementing them to provide a player experience unique to the game.

The basic recipe for an ARG could be boiled down to Exposition + Interaction + Challenges. Each of these components must be present for any given game to be widely accepted as an ARG, but the amounts in which they must be represented and the weight on each leg of the tripod vary widely from game to game.

One could also use a model of challenge-reward to understand ARG game flow, though this is very similar to the model used in many kinds of traditional video gaming already. (In an average first-person-shooter game, for example, the typical flow is: clear a level, fight a boss creature, and then get a cut scene of exposition as your reward.)

However, because of the multithreaded nature of ARGs and the fact that very many players participate concurrently, it is difficult to break up ARG elements into simply "challenges and rewards", and we have instead used "exposition-interaction-challenge".

Please also note that each specific mechanic described here has been given one of three categories (exposition, interaction, challenges) in order to simplify this document. This is, however, only a semantic distinction, at best. In the real world, the lines between these categories are indistinct, and any given element of an ARG could serve two or even all three of these purposes.

No simple list will cover every single possible mechanic to be found in every game, because the mechanics are constrained only by real-world limitations and resources, and by the designers' imaginations. Providing an exhaustive list of methods and mechanics that could be used in an ARG would be no less difficult than providing such a list of all of the ways that human beings use to interact with one another.


Photo credit: AC Vault

The primary problem of storytelling in an ARG is how to convey expository information. In order to run an ARG, you need to present a cast of characters and their motivations, flesh out the world they live in, and deliver information about backstory and real-time story action simultaneously. In traditional video game development, exposition has been increasingly relegated to cut scenes and informational box inserts, but in an ARG, a much richer array of narrative mechanisms is available.

As in more traditional narrative-form games, expository content is often used as a reward for reaching a significant achievement. However, the balance of gameplay vs. narrative content is usually much heavier on the side of narrative content in an ARG, as the interactive elements of a game are typically more cost-intensive to create, in terms of both development time and money, and because of the relative level of difficulty involved in naturally integrating those narrative elements.

ARGs can be significantly more text-heavy than modern PC and console games, in some cases far outstripping the number of words written for a typical text adventure. Integrating narrative elements into a comprehensive whole is also, arguably, a part of the game mechanism itself, in an ARG. Many ARGs rely on players to scour content carefully multiple times for clues in order to solve some underlying mystery. Contract this with the average cut scene, which is only viewed once and rarely if ever heavily scrutinized thereafter.

Exposition regarding the action is, moreover, significantly more necessary in an ARG than in traditional video gaming. This is because the individual player is typically not "present" to witness the action directly, and so another means must be found to convey that information. (If the player is not the one directly striking down the evil overlord, then some means of describing the hard-won battle with the evil overlord is necessary simply to keep the player engaged.)


Character blogs are the bread and butter most ARGs use for exposition, as the cut scene is in traditional video gaming. This is the simplest and easiest method to convey direct verbatim information, initiate challenges, provide color, and explain the progress of a story. The blog can be considered the dev team's 'voice' in the game, and is sometimes the only way to present information furthering character-development goals.

Blogs also present a fairly simple way for players to catch up to current events and understand past game events quickly, as the blog acts as something of a self-encapsulated summary of events-to-date. The chronological nature of a blog means that content is retained in a hierarchical and easily grasped fashion, and a new player drawn into the game well after it has begun will be able to read blog archives and begin to participate in the game after a fairly short research period.

Players have a much reduced risk of simply missing out on significant chunks of story, as would be the case if one began to watch a film or play a PC game from someone else's saved game.

Considerations when using a blog include update frequency vs. available writing resources and the level of 'secrecy' of the blog. It is sometimes beneficial for the dev team to present the blog as unavailable to other characters within the story, though this approach should be used cautiously.

Players are not always reliable at keeping secrets.

Most major ARGs to date have eliminated this possibility by not making available paths through which the players could significantly betray the game's protagonists, but if the game is not carefully crafted, this could become a big problem. For example, if your game allows email contact with a man and his wife, and the man is blogging about extramarital affairs he is engaging in, there is a high likelihood that the players will email the wife and give her the blog's URL, as well as any significant details of the adultery.

If your story relies on the wife not knowing about the husband's illicit activities, your team will be left scrambling for how to react. Conversely, if your villains are blogging their plans openly and you rely on the protagonists not being aware of these schemes, your dramatic tension will be shot as soon as even one player emails the details to the protagonists. These problems are typically avoidable with some forethought, but every experienced ARG dev team will tell you that no matter how well you plan, the players will always think of something you did not.

Most ARGs update blog content once a week or more frequently. Some are on a regular and predictable schedule, while others update more sporadically; this is a design choice that does not seem to impact the perceived quality of the game as a whole.


These gems have a much higher production cost than straight text, and are therefore often used sparingly. 4orty2wo Entertainment has a history of creating entire narratives in these formats (a radio play in I Love Bees, and multiple video segments in Last Call Poker) doled out in small segments as players reached significant milestones.

These elements are most often used as rewards in the challenge/reward structure, and can be very exciting discoveries for the players, and can be used to convey information that would be difficult to plausibly propagate by other means within the story framework, such as characterization information that a character would not explicitly state in a first-person blog.

Audio and video have often been used to create large secondary puzzles, in which players must reconstruct a single narrative from fragments of a prerecorded whole. In this process, a single narrative is written and recorded, and then the whole is edited into smaller sections and revealed to players through multiple means, typically (though not always) over a long period of time. This larger meta-puzzle was a primary part of the structure of I Love Bees, and has more recently been used in The LOST Experience, as well.

Non-blog Websites

Many ARGs have also had success using in-game created websites for multiple purposes. Common other websites you might find in an ARG include in-game news organizations and companies. Some proto-ARGs (cross-media content that does not emerge into a full-blown interactive narrative) consist solely of a few web sites for companies or organizations featured in a TV show or film, Alias being one of the most widely-known examples of this.

One danger of using static websites is the possibility that they will confuse players who come across them for the first time late in a game, particularly if information or interaction with that site has ceased. It is a best practice to clean up behind the action of your game such that remaining content is not misleading.

When designing a static site, it is wise to critically examine components such as news sections, calendars, and announcements, to be sure that the absence of updates does not overly damage suspension of disbelief.

Other Media

ARGs have used or could use countless other media for propagating information and for setting challenges. Here is a select list of a few of them:

  • Newspapers or magazines (usually classified or display advertising)

  • Television (commercials or tie-ins with existing programming)

  • Billboards

  • Movies

  • Posters/stickers/flyers



This is quite possibly the defining characteristic of an ARG. By "interaction" we mean both direct conversation with story characters and with the game world. Through interaction, players have the chance to influence the progress of the story even when there is no specific challenge at hand.
Interaction provides a deep level of immersion with the game's story, and it is participation in the kinds of interaction described here that hooks the most dedicated and passionate players into your game, far moreso than solving any challenge or reading any amount of static content. Unfortunately, interaction can be costly in both cash and production energy, and so it is usually significantly limited in scope.


Use of chat has two main approaches: bot-style and true-human interaction. Chat can include IRC or any other form of instant messaging. In non-commercial efforts, a common way to announce the launch of a game has been to target prospective players and engage them in a short but cryptic chat conversation.

Bot-style chat has been used successfully by a number of ARGs, including The Beast and Jamie Kane. In this form, a character is available for online chat, but the entity behind it is a program set up with pre-written responses to keywords in advance. Many readers will be familiar with the pregenitors of such bots, the Alice or psychotherapy bots that have been a diversion of artificial intelligence researchers for many years.

While this approach is more efficient in respect to human energy and significantly more scalable to a larger audience, it can be very easy for a player to tell that he or she is chatting with a bot, and this can lead to a loss of suspension of disbelief and decreased engagement in the story.

Still, this approach can be useful in an ARG because such automated bots are typically excellent provided they are questioned regarding a fairly narrow range of subject matter, and can be skillfully written so that semantic failures become characterization rather than error. The Beast's Eliza very successfully engaged in limited chat through this means.

There have also been cases where story characters are available on chat, typically for a short time, though sometimes for longer periods, as played by actual human responders 'acting' the part. This is a more cost-intensive method of interaction, because the person representing the character in the chat can't do much else during the time of availability. That person of necessity must be someone with intensive familiarity with the story, and is typically one of the team of story writers, as opposed to a hired actor.


Again as with chat, there are two basic levels of telephone interaction: the recorded message and the live human being. Recorded messages scale more easily, but nothing makes for a compelling interaction like talking on the phone to a real human being.

In a human-mediated telephone interaction, the person answering the phone is more likely to be a voice actor than in chat. If this is so, the developing team should take care to very thoroughly brief the actor regarding anything the in-game character would know or think. These interaction can be heavily scripted, but room should always be left for some improvisational reaction, as there is no way to cover all contingencies in any script.

A more dramatic way to use the telephone, however, is by having the game call the players. For reasons of scale and timing, this is almost always a pre-recorded message. This is a very high-impact interaction; the difficulty is in finding a discreet way within the game to obtain telephone numbers. This data collection can be done through a number of 'required registrations' or user-submitted profiles on in-game sites.

Many games, including Jamie Kane and The Beast, have collected contact data as part of an early subplot in the game, and encouraged the players to believe that that part of the interaction was complete. But contact information can be used much later on for shock value; a common device is a mysterious phone call with a pre-recorded message, in which the player may at first not even recall when he or she gave out that phone number.

Some games have also used telephone interaction as an opportunity for a challenge, by creating voice mail boxes to be 'broken into'' or complicated call routing trees to navigate. The Beast relied on players listening to voice mail messages left in Jeanine and Laia Salla's voice mail boxes as rewards after reasoning out the access codes for those boxes (which in both cases were essentially T9 representations of parts of the women's names).

And Perplex City used an elaborate call routing tree as a part of its Receda Trail, wherein a wrong step caused the system to hang up on the player; but each when a caller successfully navigated the call tree, the reward was a GPS location for the next clue in the trail.


There are three basic uses for email in an ARG, with varying levels of interaction; the autoresponse, the mass email, and conversational email.

At its most basic, the development team uses email in a primarily expository fashion, by providing an email address and then setting up an autoresponder that includes information not otherwise available in the story. In a typical game, nearly every email address mentioned or even hinted at in an ARG will have such an autoresponder set up.

A slightly more advanced approach involves use of code to examine the incoming email for keywords, and selecting a response email from a number of pre-written choices based on keyword presence or absence.

This keyword approach has not stepped up into common usage, probably in part because of some difficulty (as with chat) in maintaining the illusion that the response was not auto-generated, and possibly because of the difficulty of implementing such a system. (This difficulty lies not so much in the technical implementation, however, but in executing the writing in a believable fashion, so that story elements are not sent to individual players in nonsensical or anti-causative order.)

If it becomes obvious to the players that a keyword mechanism is being used, there is also a risk that players may try gaming the system for hidden information by sending random strings of keywords to the address.

The mass email approach is one in which a character or other in-game entity periodically sends out email to all players, or to a subset of players known to that character/entity. This approach was favored in The Beast, in which the character of Laia Salla sent out a weekly update email detailing her thoughts and plans. This type of email has largely been superseded by use of blogs, instead.

Blogs do suffer the disadavantage of being a passive form of communication, relatively speaking, and the perceived level of excitement when players receive email is generally much higher. This passive vs. active communication level has been used to advantage, though, by combining multiple forms of communication.

For example, Perplex City pushed out urgent SMS messages to players to push them toward breaking newspaper site updates during a real-time live event in which a major character was potentially killed in an explosion.

Some characters and game entities can be tagged to respond to email individually, though this is a process that is very difficult to scale as the size of the audience increases. This is also a very rewarding type of interaction for players. There is, however, some difficulty in managing expectation for this type of reply.

The level of individual correspondence any one player can expect when a game has fifty players will be quite different from that in a fifty thousand player game, and early players may be disappointed if a highly interactive character becomes much quieter over the course of a game. Anticipated future player numbers should be taken into account when determining whether and how to respond to individual emails.


To date, few games have made truly extensive use of SMS or text messaging, probably in some part due to poor penetration of this technology into the United States. Perplex City has used SMS during real-time action in the story in order to drive players to a specific URL in order to take part in a live event that was not pre-announced, and also to send out simultaneous time-limited SMS challenges to all participants during such live events. As SMS and MMS become more common in the United States, its adoption as a regular tool of the ARG dev team will probably grow in pace.

Live Events

While not every ARG conducts live events, they are one of the elements that get a playerbase very excited. Live events have two main breeds: online and physical. Every live event requires a player to take part in a specific activity within a specific time frame. Most have aspects of both interaction and challenge.

Online live events call together groups of players to simultaneously engage in, typically, a coordinated activity: 'overloading' an in-game security system, for example, or participating in a group chat, or taking part in a high-stakes poker tournament. These can be tremendously scalable, provided they are planned and implemented well.

Physical live events are probably the single most expensive type of game element to use, in terms of time and money. Physical live events are very intense for participants, but necessarily scale poorly based on venue size and available pool of players. After all, in a potentially global game, only a fraction of players can even theoretically make it to a specific location on a specific day - your game may have ten thousand players, but only fifty of them may live near or be willing to travel to, say, Chicago.

Similarly, the venue you would choose for those fifty players would not be the same one you would require if all ten thousand players were unaccountably able to participate, physical building capacity being subject to static laws of physics. One must be able to determine anticipated participation numbers in advance, for planning purposes.

However, the possibilities for narrative and challenges available in a physical live event are limited only by the resources and imagination of the team. ARGs have successfully used a number of guises for this variety of event, including protest rallies, puzzle tournaments, and planned auto thefts.

Dramatic elements occurring at these events have included choreographed fist fights on the part of actors, as occurred at E3 during Art of the Heist; mysterious messages found in the venues, a technique used during the Anti-Robot Militia Rallies held by The Beast and during Perplex City Academy Games events held by Perplex City; and in one notable case, the 'death' of a player, also in Art of the Heist.

Dev teams wishing to produce a live event would do well to study the best practices of other kinds of live event planners, such as wedding or party organizers, and the principles and practices of live improvisational theater.



In a traditional video game, this would be the part labeled as 'game play,' in which the player shoots zombies, jumps over ravines, stacks blocks, etc. Challenges in an ARG take on varied forms, and are rarely very similar from challenge to challenge even within the samegame.


ARGs have deep roots in cryptography and puzzles that require deciphering encoded text. This is one of the challenge categories in which difficulty should be very carefully measured against player ability level. Traditional methods used include Morse code, simple Caesar or other ROT ciphers, Braille, and even more complicated schemes such as Enigma. Double encryption is not rare, with a Morse message consisting entirely of numbers that correspond to ASCII character codes, for example.

The ARG community tends to expect a lot of this variety of challenge, for better or for worse, so expect all graphical design elements to be scrutinized as potential codes, and expect all digital images to be examined for signs of steganography, at least to begin with, until the community has determined to what degree your game in particular is played on this level.


Some ARGs have successfully used familiar pre-existing games as challenges within their game structure. Last Call Poker participants played, of course, a considerable amount of poker. The Beast featured an online game of Go and live jigsaw puzzles. The advantage to this is a familiar rule set, though integrating such a game in a plausible fashion can be more challenging than the alternatives.


Some challenges issued to the players are not games or puzzles as such; notable examples include in Perplex City, when the players collaboratively wrote a book of (mainly) short fiction to further the story. In I Love Bees, players answered ringing payphones and gave keywords to the caller to unlock story elements. This sort of challenge is generally aimed at getting a large number of players over a wide area to work together for a common cause, sometimes for an extended period of time.

Social Engineering

This variety of challenge could just as easily fall under the 'interaction' category. Social engineering tasks are interactions in which the player must achieve a goal by convincing an in-game character to behave in a certain way, or to provide specific information.

The first and most famous social engineering puzzle was the Mike Royal telephone interaction in The Beast, in which players convinced a security guard to intervene and rescue a teen boy from his captors by using information gleaned about the guard from other sources.

Other uses for social engineering puzzles are convincing a character that a player is a legitimate contact for a password or other privileged information, or simply establishing a rapport with the character such that he or she 'feels comfortable' passing on information that may be crucial to the story.


The word 'puzzles' is a catch-all term that, in this context, includes any challenge in which the players are presented with information, an interface, or a situation lacking context or explanatory information and must figure out what to do in order to surmount the challenge. These can take any number of forms, some of the most common being:

  • Obscurity puzzles (searching through masses of information for patterns or specific data)

  • Guessing passwords/subdirectories/URLs

  • Understanding and using unfamiliar and undocumented interfaces

Other Challenges

Challenges can be both real-world and online. The only limit is the imagination, and challenges that players have surmounted have included or could include the following, plus more:

  • Locating a geocache or other hidden real-world object

  • Playing through a text adventure

  • Performing a special service for an in-game character (proven with photographs)

  • Identifying or completing literary references

  • Translating from obscure languages

  • Interpreting highly specific information or notation from a specialized field

Integrating the Pieces


The art and artifice in developing an ARG, of course, is in pulling all of these specific mechanics together to create a cohesive, compelling, and internally consistent player experience. Following are a number of guiding principles regarded as a best-practice by most ARG teams.

Attention to Detail

A large part of creating a successful ARG hinges on the same kind of suspension-of-disbelief required for cinema or video games. In an ARG, much of this can be accomplished through subtle world-building or color. Some of this depth is simple and not even time-consuming to create. Any organization for which there is a website can have contact information, such as an email address (and probably an autoresponder).

Any character can have an email address. Restaurants can have menus, banks can have login forms (even if they don't work), consulting agencies can have news announcements about their latest big deals. A fairly small investment in time and resources will result in a much more colorful and believable gamespace.

Another level of detail to pay attention to, though, is the inner workings of your own plot. Managing information flow can be a tricky battle, particularly with interaction, and particularly if you are simultaneously presenting the viewpoints of multiple factions or opposing interests in your story. Keeping careful track of who-knows-what for the sake of internal consistency is a vital task, and one you cannot always rely on your players to keep straight.

Playing in Real Time

An early lesson learned by every ARG team is this: there will never be such a thing as enough content for a dedicated audience. That said, it is wise to meter the amount of content you plan to provide to your players, so that you reach a volume that keeps interest high, but doesn't result in early burnout for the dev team.

There are several approaches to this, including updating web sites and providing new content at set times; or updating periodically, depending on player progress (or internal development progress.) Some easy mechanism to increase tension in the story are to do multiple updates very rapidly, or to miss regularly schedules updates, or to introduce finite time limits on challenges presented to the players.

A problem with the real-time nature of an ARG, though, is the fact that for any given global audience, a large number will be asleep or unavailable any time of day you choose to schedule updates or live events, and will be accordingly unhappy.

Hinting Strategies

It is absolutely crucial to have a fallback plan if you are providing a challenge to the players and the reward is pivotal to further your story. It is very decidedly a best-practice to never rely on your players to solve any specific puzzle, regardless of how simple it may seem to be, if the reward lying on the other side of it is absolutely necessary and not feasibly available through any other means.

The specifics of a hinting strategy are something every development team should give time and discussion to as early in the project as possible. If possible, it is wise to cultivate potential channels for providing hints to a stuck playerbase in advance.

Suspension of Disbelief

A few commonly-accepted conventions have grown up regarding the varieties of story that can be told in an ARG and how they unfold. Common tropes involve sci-fi or horror elements (time travel, ghosts, advanced A.I., etc.), conspiracy themes (secret government agencies, fanatical religious groups) or both.

While not all games use these elements, the simple fact is that it is very simple to tie these types of story into the other elements of an ARG. For example, an organization whose existence depends on secrecy might plausibly have developed elaborate systems of codes and pass phrases, thus presenting the audience with puzzles to solve.


There are two major approaches to an ARG audience: catering to a standalone player, or catering to a hive-mind community. The second approach is by far the most common, and some would argue that the community element is part of the definition of an ARG. That said, there has been one notable case of an ARG targeted at the standalone player, the BBC's Jamie Kane project.

This style of game is typically given to less branching, as the flow and outcome of the game are not as affected by individual players. On the other hand, this style of game is typically more accessible to late-comers, and may be designed to be replayable from the beginning by an individual at any time.

Because it is the more common approach, most of this "methods and mechanics" section is written assuming the audience is an information-sharing and collaborative community. Language aside, most of this information applies equally to both situations.

Assessing Player Skill Level

In the early days of a game, analyzing and meeting player expectations and abilities is probably the most difficult task. This is, however, a crucial task to complete.

Missteps in difficulty on the side of too-simple can lead to the players burning through content at a much faster rate than expected. This in turn leads to a breakneck development pace for the development team to stay far enough ahead of the audience that they can devote adequate time to quality assurance and testing, while ensuring that the game does not stagger to a halt in the interim.

Too-difficult games will also throw off the pacing of the game, especially if the players are unable to progress and grow frustrated. (See the Hinting Strategies section for more discussion of coping with frustrated players.)

In some cases, the audience you attract may not be the audience you had expected during your pregame development phase. This can lead to an early mismatch between the actual skill level of the players and the skill level at which the game is conducted, in which case it is even more important to adjust expectations quickly.

In order to assess the skill level of the players, it can be helpful to set a number of challenges of widely varying difficulty early on in the game to discover which ones seem the most popular and how quickly they are solved.

Expectation Management

Expectation management is a tricky business, as many an ARG development team will attest. For the sake of your relationship with your players and for the health and sanity of your team, one of the most important planning tasks of an ARG is determining the weight of work your team can shoulder over the anticipated duration of the game.

Once a development team has set a precedent, players will expect that level of pace or difficulty to be maintained. For example, as with The Beast, if your game starts out pushing multiple content updates including blog posts, email, and at least one or two brand-new web sites every Tuesday, your playerbase will be extremely unforgiving if a Tuesday goes by with no updates at all.

This can set up a grueling workload for all of your developers, writers and designers; and while this may be acceptable for a game planned to run only 6 to 8 weeks, it may be completely unsustainable for a game planned to last several months.

Similarly, if you avoid giving players a certain type of update or puzzle for very long, one should not be surprised when they cease to pursue that avenue, even to the point of missing it when you finally use it. For example, if a static in-game 'corporate' web site persists unchanged for three months, it would be unsurprising if the players do not notice when it is finally updated.

Expectations can be altered after they have been set - and one could argue that every game has to struggle against the preconceived expectations players hold based on prior games they have played or heard about - but it is not a simple task. Some care up front can avoid loss of audience goodwill later on.

Love Your Audience

Always love your players. It's easy to get drawn into a combative relationship with the players, as the players often tend toward an adversarial relationship with the development team. It is seductive to set challenges and tangle plot with the sole intent of stumping the players, but this is not conducive to an enjoyable game experience for them.

Also keep in mind that the audience your game attracts may not be the one you had initially wanted or envisioned. Foster affection and especially respect for them regardless; they are the audience you have, and this means they are the people who really enjoy the creative effort you are putting into your game. Your players will probably be able to tell if you think of them unfavorably, and you won't have them for very long.




Physical geography, not typically a constraint for other varieties of gaming, becomes a problem for the ARG on three separate levels. First, there is the inherent tension between the global nature of the internet, over which much of an ARG typically unfolds, vs. player availability by time zone. Then there is the universal problem of globalizing any sort of game - breaching language barriers and still providing a great game experience.

An even greater geographic problem comes from providing interaction, particularly for physical live events and some forms of interaction. For example, a phone number is a local construct, and choosing to whom it should be local may exclude players who lack the capacity, money, or willingness to call long-distance, especially internationally.

Moreover, physical live events such as Perplex City's PCAG tournaments limit those portions of the game to players either local to the area, or those who have the funds and time to travel to the area for the event.

Some teams have tried to downplay this angle of the problem by making these kinds of events of relatively small consequence to game play, or, as in the case of Art of the Heist and I Love Bees, by running a larger number of very similar small events across a large geographic area. It is strongly advised, however, to specify the target geographic area of your audience in your initial project specification.


In many ARGs, development of the game continues concurrently with game play after the game launches. Every team presumably does as much work as possible before launch. Still, for most teams, a significant share of work is done post-launch in reaction to player activity and progress. This is especially true in games with longer run times.

Because development and play are concurrent, there is a very high risk of team burnout. Very carefully weigh the planned story schedule and pace against the projected ongoing burden on the development team.


Every game has a budgetary consideration, and ARGs are no different. Several non-commercial games have run successfully on shoestring budgets by using volunteered time and resources of the dev team, donated time from voice or live actors, free online hosting and blogging services, and so forth.

Greater resources permit a team to introduce more dramatic elements to a game (phone calls, significant programming projects, helicopters). A bigger budget also allows a team to invest in professionals for video and audio production, web design, coding, and writing, and can lead to faster development times and a more intense pace of gameplay.

It is very likely that the budget is one of the first known factors about the game development. When planning the budget spend, important factors will include burn rate vs. projected run time, ongoing maintenance costs, and estimates of available funds for heavy development and live events.

Physical live events, in particular, pose a hairy budgetary problem, because they are by nature only accessible to a subset of players. Total player participation and impact of the experience on both them and on non-participating players should be considered when establishing the budget for such a live event. In some cases, it may simply not be beneficial from a cost point of view to conduct a physical event.

Project Goals

Many ARGs are produced as an ancillary effort rather than standalone projects. When an ARG is produced as a public relations or marketing effort, additional challenges will be present in complying with the canon of existing intellectual property, or working with a separate group who may exercise significant creative control. On the other hand, a commercial standalone ARG faces the problem of constructing a profitable business model.

Risk Management

An ARG brings legal considerations into the field of game development to perhaps an unprecedented degree, because of the very real-world nature of the playing field. No lawsuits have been filed as of this writing, and it is entirely possible that none will be for years to come. Still, in the interest of providing both the players and developers with as safe an experience as possible, a dev team should always use caution in designing game parameters, particularly for live events.

Games should always be designed with due consideration toward non-participants who could be affected by the course of play. (A game of tag might be a terrific in-game device, but not through the streets of midtown Manhattan at 5pm on a Tuesday. An example of great risk-management to protect bystanders was found in Art of the Heist, who provided the VIN of each vehicle to be 'robbed' - imagine if this information were absent or ambiguous and the players tried to steal SD cards from an out-of-game car!)

The first and most obvious step: don't require your players to do anything dangerous, illegal, or otherwise unconscionable in order to further the game. Moreover, because an ARG does not come with a rule book (at least, not to date) the challenge is even more compelling.

It is possible, as with the Art of the Heist example above, to create the illusion that the players must do something legally shady in order to further the game, but in these cases, the boundaries between the in-game elements and out-of-game law should be clear to the players. Throughout the development process, the team must look, not only at the intended flow of the game, but also at how the game parameters might be misconstrued.

The last thing a dev team needs is for a group of players to be arrested while fulfilling what they believed to be a necessary role in the game, be it hacking into a server that wasn't in game after all or removing a 'clue' from private property that was unrelated to the game.

No player has thus far been injured in the process of fulfilling a necessary game function, although there have been some close calls. Players have put themselves into potentially risky situations due to inclement weather (I Love Bees). Players have also entered areas where they reported feeling threatened by non-players present on the scene (Art of the Heist). It is not clear whether a development company could be held liable in the event of such an injury, but some caution should be exercised to avoid the question at all, if possible.

End of Part III

Read part I: Alternate Reality Games: Daily Narratives Turn Into Interactive Cross-Media Games

Read part II: Alternate Reality Games: Genres And Categories

Originally published on 2006 by the IGDA Alternate Reality Games SIG as "2006 Alternate Reality Games White Paper" on the IGDA website.

About the authors


This paper by the IGDA was created and written by volunteers on behalf of the community at large. The editor of this third part is Andrea Phillips.

The IGDA Alternate Reality Games SIG -
Reference: IGDA [ Read more ]
Readers' Comments    
blog comments powered by Disqus
posted by on Friday, January 12 2007, updated on Tuesday, May 5 2015

Search this site for more with 








    Curated by

    New media explorer
    Communication designer


    POP Newsletter

    Robin Good's Newsletter for Professional Online Publishers  



    Real Time Web Analytics