How To Make An Alternate Reality Game: Production

How To Make An Alternate Reality Game: Production
Summary: This is the third part of an article series about developing an ARG. Here, we’ll explore the production phase.

What You Need To Know About How To Make An Alternate Reality Game

Andy Petroski, Emerging Technologies Leader and Author, is allowing our readers to read portions of his work. This article comes from his book Alternate Reality Games: Gamification For Performance. 


In our last two articles, we’ve talked about the initiation as well as the pre-production phase of creating an Alternate Reality Game.

A treat for you! 20% off ‘Alternate Reality Games: Gamification for Performance’
Use the CRC Press code FLR40 and get a special offer by Andy Petroski and eLearning Industry!

After defining the project and determining a strategy for completing the work, the development team now moves into production.

In this phase, the team begins producing the written, visual, and programmatic elements needed to interact with players, computing devices, and the general public. These content elements; animation, graphics, music, narration, photography, sound effects, and video footage are developed using the specifications identified during pre-production and defined in the Design Document.

Use A Treatment To Prototype The Experience: An Example

We often approach the Production phase by producing a treatment. The treatment, or ‘alpha test’, is a representative component of the ARG that might contain a mix of various elements. It lets the team "test" their design assumptions from the previous phase before moving into full production mode.

In "The Pocket" ARG, our players were Pennsylvania educators attending a conference. The goal of The Pocket game was to help educators understand the benefits of "Bring Your Own Technology" (BYOT) programs being piloted across the country.

Attendees were encouraged to think differently about the incredible computing power many students have in their pockets instead of viewing the devices as distractions.

Our treatment was a portion of gameplay that served as the basis of the ARG experience the teachers would have at the conference. During the event, players needed to decipher answers from game clues and submit them to the game system. The game system would then validate the clue code and, if applicable, apply points to the player's account and advance their virtual avatar on a game board.

So, for the treatment we identified the following needs:

  • Two game clues (of the 45 total clues):
    • A physical clue to be included in print material. This would be facilitated by QR codes in the live game.
    • A digital clue to be delivered by the game's Twitter account.
  • Placeholder graphics for the "game board" and player avatar
  • A database to log player activities (timestamp, record id, player id, clue id, points award)
  • Preliminary code to connect the activity database with the public game board accessible via the game's Word Press-based site. 

This treatment uncovered problems with the game board design, the avatar scale, and some incompatibility with previously written code. But it also helped the team validate the "voice" of the Twitter account, the database schema, and a number of additional assumptions made by everyone involved.

We also found that while two game clues were enough to test the game's interaction with the real world, it was not enough to determine if we were meeting our primary learning objective: identification of best practices, opportunities, and potential problems of Bring Your Own Technology (BYOT) programs. This objective would have to be tackled with a larger clue pool later in the production phase.

Building The Components

Once the treatment has been tested and reviewed, the team should document any design changes and update the project schedule. At this point, the team will complete production of various game components. This might include video production, web site development, creation of social media accounts, and the installation of hardware and software tools.

During this portion of Production, it is important to communicate updates weekly and sometimes daily to the entire team. This can be done face-to-face or via digital communication and project management tools. The Google suite of productivity tools (Docs, Sheets, Slides, and Forms) is free and available on a wide array of platforms making it an excellent choice for keeping the development teams up-to-date. Additionally, Asana, Smartsheet, and Trello are the top fee-based solutions.

Preparing To Fail

Another component of the Production phase is testing. "Fail early" is a favorite mantra for many interactive multimedia teams. Failure is a fact of life when tackling creative endeavors. Not every idea will pan out, and not every approach will work as planned.

Throughout this phase, the development team will continually test assumptions made in the Pre-Production phase. Is type readable at the specified size? Can users connect to a web application via WiFi? Are points gained by completing activities accurately tallied by the system? Are users motivated to work together? These are the types of questions that should be discussed and debated during the Production phase. By testing and failing early the development team can identify potential problems with the content or the digital solutions.

Problems identified at this juncture should be addressed either by correcting the issue or identifying a solution that can be tested during Post-Production, a phase which we’ll explore in our next article.

Stay tuned!