During the first week of October a peculiar situation arose were we first year students suddenly found ourselves with a week of nothing to do – or so we thought. A day later we were quite graciously handed both 100 pages worth of reading materials and a concept challenge with a deadline set for next week.
The special thing about this concept challenge was that we had to build a game around a randomly generated narrative. We were offered two methods for randomly generating our narratives, Rory’s story cubes and They Fight Crime. The difference between these is that the story cubes generate a set of images to interpret while They Fight Crime generates characters according to the template “He is a [insert description]. She is a [insert description]. Together, they fight crime!”
In groups of no more than 5 or alone we had to:
- Randomly generate a narrative.
- Come up with a set of Aesthetic Goals for our game.
- Decide Dynamics and Mechanics that would deliver on these goals.
- Determine a 3-tier target audience and write a profile for these, the three tiers being Early Adopter, Second Tier and Mass Market.
- Design one feature for each audience segment.
- Create a powerpoint-presentation for the game based on the provided template.
- Write a Development Diary.
- Write an explanation of the target audience and a justification for the feature set.
The provided template was an excerpt from an earlier lecture, “3.1. Documentation and the Design Process”.
I chose to work alone on this assignment. Partially because I worked from Stockholm at the time and it felt unfair to join a group if I wasn’t going to be there for the meetings and partially because I wanted to find out what I could do by myself. Could I do it or would I get stuck? Would it be too much work for one person or would it be manageable? Would the end result be good or would my ideas need others to even be worthwhile?
For my narrative I chose the They Fight Crime-method, for the simple reason that Rory’s Story Cubes cost money and I unless those cubes were edible they were not part of my budget. What I got from the They Fight Crime-generator was:
“He’s a world-famous alcoholic cat burglar in a wheelchair. She’s a tortured goth angel with an evil twin sister. They fight crime!”
Figure 1. “…Come again?”
Despite what the list above says, the first item on the list was to re-read all old lectures on MDA. The second item on the list was to brainstorm ideas. From the “They Fight Crime”-part it felt like a given that this would be some kind of an investigation/puzzle-solving game but the examples I immediately came to think of were not appealing to me. Three things that I immediately and intuitively decided upon were that:
1. If you’re playing a detective game you should feel like a detective.
2. The core mechanic should be centered around solving crimes.
3. The characters should be relevant to and inform the player’s actions.
So what does a detective do? It wasn’t actually important what a real detective does, the game had to line up with the player’s expectations of what a detective does. From the few detective shows I’ve watched (recently BBC:s Sherlock) it seemed to mainly be:
1. Find clue.
2. Go to some location indicated by the clue.
2. GO TO 1;
Great! There’s our core loop! But how would this translate into a game? Researching detective and puzzle-based games I stumbled upon the expression “ARG” or Alternate Reality Game. I found examples like the “I love Bees” alternate reality game based on Halo-mythology or “Year Zero” that was made to market a Nine Inch Nails-album. These games were based on internet communities gathering complex clues from obscure real-life places and putting down an insane amount of work to solve them and “unlock” the next piece of story.
What’s important here is what these people enjoyed about it. Most of these games were based on some kind of conspiracy theory and new players could only join the game by finding and solving the first clue. This made them feel specially chosen and thus more likely to invest into the game. They had to do their own thinking with non-trivial and sometimes very complex problems, requiring expertise from a number of different areas. Thus solving a clue made them feel pride and gave them a sense of achievement. These games often required co-operation to solve the problems, giving the players the feeling of being part of a community. Also they provided context that made it seem like the players actions were contributing to something bigger than themselves.
(Much later I read the book “Reality is Broken” by Jane McGonigal and her chapter on intrinsic rewards confirmed these conclusions.)
Alright so that was a great starting point. But how would the actual game mechanic work? Most of these games had a kind of a game master. But that would severely diminish the scope of the game as it would then depend on a person being online and managing the process. Also I was still thinking in the terms of a modern video game and somewhere in the back of my mind I had the idea of casual puzzle games hovering. Then it struck me. Ingress.
Ingress uses smart phone-based geo-positioning technology to let players play an advanced game of “Capture the flag” with real-time feedback.
That was it. It would be a puzzle-solving ARG:s-type of game that would make the player physically check into locations in their home-town and give them feedback via their smart-phone!
Figure 2. “Oppan catnip style!”
Putting up Aesthetic Goals after that was a fairly straightforward process. I registered for Ingress and did some reading on it and what a lot of its players enjoyed were the elements of exploration and co-operation, same as the ARG:s players, as well as being able to play the game in their own time. I wrote down the aesthetic goals, their failure states and the types of fun these would facilitate, according to earlier lectures.
- The player feels like they’re actually participating in solving a crime.
- The player feels like a competent detective and like their making actual deductions.
- The player finds the puzzles reasonably challenging.
- The player finds solving a puzzle rewarding.
- The player feels in control of their own story.
- The player experiences suspense and feels immersed in the story.
- The player feels that there is an immediacy to their actions.
- The player experiences joy from exploring new places.
- The player feels like they are becoming a more resourceful detective.
- The player feels like their contribution does not affect their experience.
- The player feels like they’re going along with – rather than influencing events.
- The player finds the puzzles too hard or too easy.
- The player feels like he/she is insufficiently rewarded for his/her investment.
- The player feels like the mystery is predictable (no suspense).
- The player gets bored and leaves the game unfinished (no investment).
- The player is not seeing new places or finds it boring.
- The player experiences no improvement.
Types of fun:
- Fellowship: Cooperation, Competition
- Challenge: Solving a murder mystery by gathering clues, getting to places in time, deduction, developing skills, competing against others.
- Exploration: Exploration, finding places you did not know about before, physically traveling, getting outside. Discovering a plot twist or a solution to the mystery.
- Narrative: Being part of a crime mystery, watching it unfold and influcencing it with your actions.
The dynamic and mechanic parts of this challenge were trickier. I briefly toyed with the idea of assymetric gameplay a lá Turtle Studio’s new IP “Evolve” where some players play as hunters while one player plays as the monster. I eventually scrapped it because, A. Assymetric gameplay would add a whole new bunch of balancing issues. B. It would derail from the main idea of “solving crime” and move closer to “catch the bad guy”. C. The co-operative element was a big part of the appeal of old-school ARG:s games (Note: Also, in “Reality is Broken”, McGonigal states that based on surveys 3 out of 4 players preferred co-operative play to competitive play).
The story elements were another part. I wanted to give the player control of their story and also give it replay value. Thanks to the provided reading material on scriptwriting I found the idea of “modular storytelling” which I read up on and decided to incorporate into the concept.
For progression I decided that the player would use different skills to solve the crimes. They would earn experience points and then upgrade and choose skills from three skill trees, based on the three main characters, the catburglar, the goth angel and her evil sister.
Listing all the contents would take up too much space so in short what I did with the dynamics was to think about what I needed to facilitate the aesthetic goals (and believe me when I say that there were a lot, which I can’t fit into this blogpost) and sort these dynamics by type of fun.
I did not get finished with the mechanics document but I did write down the core loop and started structuring the internal economy.
In the end I put together a concept presentation and all required documents. Due to part plain bad luck, part sub-par time management on my behalf, my development diary was more bullet points than coherent sentences, the mechanics document was not finished and I had no concept art to show. Despite these flaws the concept was well received. This concept challenge exercise was both challenging and interesting and turned out to be good practice for the Space Shooter-assignment.
My intention is to move forward with this idea. The next step would be to turn my documents into a proper concept document as we learned to do during the Space Shooter-assignment and start putting together a prototype with a smaller scope. The most daunting challenges here are time, the skill-level required to pull this off and finding enthusiastic collaborators (especially programmers) to help turn this thing into reality.
Figure 3. “What he said.”
Well done reader, once again you have lived through a rant of epic proportions. Have a cup of cocoa! (And go to bed, it’s like 2:30 AM in the morning for chrissakes, it’s way past your bedtime).