Student Postmortem: SCAD's Project Loyola Alternate Reality Game

By Jeff McNab [04.22.08]

 Project Loyola is an alternate reality game (ARG) and senior-level project by students in the Game Design program at Savannah College of Art and Design. The team of SCAD students was formed to work together for Studio II, the culmination of the academic program at the college. In the class, game pitches are given by any of the class members, and projects are green-lit based on a critique by the professor and votes from fellow classmates. The team members worked together over 10 weeks to develop the project under the guidance of Prof. Brenda Brathwaite.

Game Synopsis
Project Loyola is still ongoing, but without giving too much away, the game's basic premise is this: Alex Loyola, the founder of a company called Red Loyola, has gone missing. Alex and his business partner Robert Morgan began Red Loyola, which makes server architecture platforms, from an initial investment from Sophia Rivera, president of Rivera Capital. Alex has disappeared after traveling to the United States on personal business. His wife Stephanie, a sous-chef and co-founder of The Loyola Scholarship, has been trying to locate her husband. With the player's help, Alex's body has been discovered along a strip of highway leading from Atlanta to Savannah, Ga.

Since the discovery of the body, Red Loyola and the Loyola Scholarship have been closed, and contact with Robert and Stephanie has been sparse at best. A mysterious character named Joseph Capablanca, also known as "codemonkey327," has been contacting the players with enigmatic messages. Joseph's messages question the nature of Alex's disappearance and death but also stir up paranoia, as they suggest that some outside entity is always watching him.

Why an ARG?
The Project Loyola team wished to create an ARG for multiple reasons. During the pitch session of the class, the project lead pointed out the freshness of the genre, the minimum technology requirements, and the lack of academic teams working on similar projects. The group members wanted to work in an avant-garde area of game design and be able to finish the project in the allowed time.

The technology requirements of ARGs are fairly simple: web sites, email, and phone calls are the primary source of information distribution and player feedback. The fact that the team wasn't required to develop custom engines or networking architectures in order to work with massive multiplayer game mechanics was a major factor in the decision make an ARG.

The original idea behind Project Loyola was simple enough at the beginning: create an ARG. But the first few days of researching the genre led our team in a new direction: documentation. We found that resources on how to play ARGs are plentiful, but those on creating grass roots ARGs is limited. There is some documentation about ARG design available through various sources, such as the IGDA ARG special interest group, but the focus on grass roots development and process was hard to find.

Also, competition against large-scale ARGs, such as The Dark Knight or Cloverfield, felt like a daunting task. It would be better to keep the project simple and be able to study the design process more than try to create something to go head-to-head with more commercial ARGs.

Our team plan is to document everything that happens during the development and launch of the game in order to create a wealth of knowledge for others to use. This is the focus of our project. We know we won't make the best ARG ever, but we hope that we can help others in their endeavors to do so, too.

 What Went Right
1. Development. Part of the requirements of the Studio II class is for our team to work using the Scrum methodology for development, which involves developing multiple parts of a project at once. This presented a problem for us at first: How do you use Scrum on an ARG's design? A more logical choice for our situation would have been to use a waterfall methodology, in which design progresses in a more linear fashion. But because of the academic requirements, our first step in development was figuring out how to do development.

What we settled on was the concept of narrative phases. Each phase of the ARG is a subset of the overall narrative in which specific events will occur. By developing parts of each phase during the course, we would have elements from each phase completed as we moved forward. We based our phase model after the classic storytelling model, with character introduction (exposition), rise in action, climax, and dénouement (we considered "fall in action" part of the dénouement). Each phase would try to implement each of these four parts.


 Using story block phases allowed our team to follow the Scrum methodology. Each team member was given a specific entity to develop, be it Alex Loyola or Rivera Capital. Team members were responsible for all aspects of that entity, including personality, associated web site, and so forth. Some jobs had to be given to people that had the knowledge on how to complete them, such as server scripting and web design.

For example, the first phase involved the introduction of four characters -- Alex Loyola, Stephanie Loyola, Sophia Rivera, and Robert Morgan -- and it was later that we introduced the enigmatic codemonkey327. Entities, like Red Loyola, Rivera Capital, the Loyola Foundation, were also introduced in this phase. For each of these entities we created web sites, and for most of the characters we created blogs.

In terms of storyline, this first phase is when it first becomes known that Alex has disappeared, and eventually his body is discovered. The players piece together this knowledge by sending messages to characters and using clues found hidden in the various sites.

Near the end of our 10-week development cycle, we decided to move away from paid internet services and toward free ones, such as Gmail and Facebook. The reason was purely financial. After all, we are poor, starving college students.

2. Flexibility of design. The advantage of using phases was flexibility. It put us in a position to alter future phases if things didn't go exactly as planned in the previous phases. We actually were forced to test this out after realizing that we had shown the players an image that wasn't supposed to exist. It was something we had put up for our own reference and had forgotten to take down. When the players found it, we were forced to switch the narrative to keep some level of consistency in the plot.

We actually fixed the errors that could have caused Project Loyola to end prematurely in a 30-minute meeting. We were able to altering the intended path that players will take because future events had not been set in stone. We've actually gone through four different plot line changes since our original idea at the beginning of week one of development. Three of those occurred after launch. The general narrative is still the same, but the specifics have slowly shifted as players move the ARG in new directions. This is one of the things we as designers find so fascinating -- emergent gameplay.

3. Team dynamics. Our team was composed of people interested in various aspects of game design, from narrative design to systems design. This variety of interest allowed most of our team members to focus on the areas that they wanted.

The core of our team was five seniors enrolled in the Studio II class, with a group of interns from various academic levels with different majors at the college. We had graphic designers, web designers, and game designers all working together to create all the content.

The largest role we needed to fill was writers. Fortunately, our professor was also teaching a narrative class during the same quarter. We recruited four people from that class to help us with our project, and most of them have come back to continue helping us with development. These writers were invaluable to us in getting the ARG completed because of the massive amount of content needed to create a believable scenario.

4. Players. We love our players. They are as interested in playing our ARG as we were when we developed it. We've had fellow classmates come to us and tell us that they had to stop playing because it was taking too much of their time. The Unfiction forums group, an independent ARG forum that we utilized for the game, gives us plenty of feedback on what is going right and wrong with Project Loyola so we can not only fix it, but document it. 

Creating a player base for an ARG is a much faster process than for other games. Word of mouth spreads rapidly through the ARG community, and our project already has a strong player base. However, sometimes it's hard to develop content that they all can use due to geographic and financial reasons. Yet, most players will take our mistakes with a grain of salt and understand that we are running our first ARG. We can't thank them enough for their patience.

5. Design documentation. Over the past couple of months while our team was working on this project, I've had a chance to meet some of the important figures in the ARG community. When I approached them to find out about their experiences with the genre and what goes right and wrong, I found that our team is seeing some of the same problems that all ARG developers face when making their first ARG. It's nice to know that the logic behind the project (that of documentation) is something that does seem to be needed by the community as a whole.

During these conversations, I mentioned some of the more interesting things we've noticed, such as the efficiency of design. Recently, our team put together a small clue to give out to our players as a notice of an upcoming event. This clue was converted from text to binary, and then implanted inside a picture using a text editor. The image became corrupted as a result. Basically, the players got a distorted image with little information about it. It took our team about 50 minutes to develop the message, the importance of the message to the overall plot and timeline, implant it, and email it out to the players. Thirty-two minutes after sending the email, it was already decoded and distributed to the players who hadn't originally received it. This is how fast ARGs run. (A fellow designer here at SCAD told me "The internet is smarter than you," something I think all ARG developers learn quickly.)

This clue had a 64 percent efficiency. For 50 minutes of development, players got 32 minutes of play. ARGs, I theorize, have a very high efficiency of development to play time in comparison to standard AAA titles. This is the sort of information that we feel ARG developers are interested in, along with the pitfalls and problems that can arise.


 What Went Wrong
1. Needle in a haystack. Making an ARG is like hiding a needle in a haystack. Players are faced with all this information that they have to sort through in order to find one nugget of information that can be used to progress the story along or solve the puzzles. Designing the needle was the easy part. Making hay takes longer. Our team got stuck making hay during the beginning of development: making web sites, figuring out server tech, developing characters' personalities, and so on.

We decided that we could release the game because of the flexibility of our design. We thought that while players were sorting through the content, we could continue to develop the next phase. The problem is that the players worked much faster than we had originally expected. We had hoped that the players would take about a month to find our clues; they discovered them in three days. We made hay, and they had torches.

This has caused all sorts of problems. We released the game a week before final exams and had planned on being able to focus on other classes while the players were searching. Instead, we had to have two meetings during the last week to try and figure out tactics for delaying our players. This lead to future issues, since most of our team went home for the break after finals and game development all but stopped. Hay wasn't being made, but players were still burning through things.

2. Level of response. Most designers would be happy if they had more people playing their game than they had anticipated. But when the number of players you have determines how quickly they progress through the game, it can cause problems. It's not that we don't want a lot of players involved in our ARG -- we just weren't expecting them. Project Loyola players moved so quickly through the ARG that they caught up to us in terms of content. We weren't ready to release content when they were ready for it.

Another issue is geography. Originally, we had planned on the majority of our players being located in one geographic area, basically around Savannah. Since we have players from all over the world now, many of our real-world puzzles have had to be abandoned and replaced with ones that exist purely in virtual space. We are working to build new puzzles that will be non-geographically centered so as to break players away from their computers to play the game

3. Play testing. For most game development projects, the developers have a chance to play test their game. They let various people play through the game or prototype, looking for problems or ways to make it more fun.

In our situation, we wanted to keep the content of the game as secret as possible from our fellow classmates since ARGs are linear. Once information has been leaked, there is no way to hide it again. For example, as mentioned earlier, we accidentally left an image on a web site that wasn't supposed to be seen by the players, which caused us to call an emergency meeting. The image said, "Alex is Dead: Deal with that shit." It was meant to be a placeholder for a possible puzzle clue that we would figure out later. What's more, not everyone on the development team even knew that it was there. If we had been able to play test the game in a more traditional sense, this image would have been found and removed. As such, our team was forced to scramble to try and protect the ARG's story, rewriting some of our plot line to now incorporate that found image.

4. Our first puzzle. One of the roles that ARGs players must take is that of puzzle solvers. Certain clues are left for players to find and decode in order to find the next clues and so on.

One of our earliest puzzles involved a color bar and a complex code that applied to that bar. Unfortunately, the players weren't finding it and began focusing on the wrong things, such as the mysterious and accidental "Alex is Dead" image. To cope with the mixed up clues, we decided to introduce one of the characters who wasn't actually supposed to appear yet, "codemonkey327".

Codemonkey327 is a mysterious character and not much is known about him. He drops clues and converses with players every once in a while in order to help move the plot along. He introduced himself with a cryptic message that referenced chess.

Unfortunately, the players began to think that the code for the bar was related to chess moves. Eventually, we sent them a similar color bar found by Sophia on Alex's computer as a push in the right direction.

The code for the color bars used specific RGB values from the image as numbers inside the code. However, we never tested the color bar's color values after it was saved as a PNG file. The Mac version of Photoshop did something to the color values, making the players' resulting code completely different from our own. We ultimately were forced to change what the code was used for (originally, it allowed the player to gain access to a users-only area of the Red Loyola web site).

5. Progress after launch. Two weeks into launch, our team was feeling good about the game's progress. Players were taking the clues we had left and using them in a manner that was conducive to progression. Then, problems started to arise. Certain team members were no longer able to work on the project because of other responsibilities. Development slowed, but players were still moving through our content at the same rate.

This has led to a bored player base. A bored player base equals no player base. It's one of the biggest flops of the project so far, in all honesty, but something that we feel we can fix due to our design method. Future phases will come into effect to allow our old players and new players to get back into the ARG.

Alternate Game Design Education
Project Loyola as a whole was definitely a learning experience for everyone on the development team. We definitely recommend developing an ARG to any academic group looking for a project to work on. The low-tech requirements merged with the massive multiplayer game mechanics and emergent gameplay make it an excellent genre for academic purposes.

Project Loyola is still underway, not only in terms of gameplay, but also documentation. Upon completion of the project, the documentation will be given to the ARG community for future developers.

Jeff McNab is the team lead on Project Loyola and was responsible for server technologies and systems design, along with various narrative elements.

He and the team welcome questions from the student game development community via email ([email protected]); or visit the project blog.

Project Loyola Team
Jeff McNab, project lead
Ashley Waldbaum, writer/graphic designer
Fran Rodriguez, writer
Stephen Lawrence, writer/graphic designer
Greg Morgan, graphic designer
Blake Harris, content developer
Ryan Place, graphic designer
Shannon Hegarty, graphic designer
Susanna Harrison, writer
Charles Elum, writer
Brian Shurtleff, writer/content developer
Gwen Murray, content developer

Return to the web version of this article
Copyright © UBM TechWeb