Come my friends, hear a tale of beetles and blasphemy.

Last year at GDC I had the privilege to play the game Johann Sebastian Joust made by Doug Wilson and Die Gute Fabrik. If you haven’t seen or heard of the game, it is a “no-graphics, digitally-enabled folk game for 2 to 7 players, designed for motion controllers.” The goal is to make your opponent(s) shake their controller hard enough to set off the internal motion sensors, eliminating your opponent from the game, while making sure not to shake your controller hard enough to get eliminated before everyone else. During the game, selected musical pieces by Johann Sebastian Bach play at two different tempos, slow and fast. When the music is slow, the motion controllers are very sensitive and easy to set off. Thus, players move slower and cautiously. When the music is fast the controllers are less sensitive and players become more animated, taking more risks. In respect to other games, it is sort of a combination of ‘tag,’ ‘keep away’ and ‘king of the hill.’ No graphics also means the game can be played anywhere you can setup a laptop to work as a bluetooth hub.

When Doug showed me the game at GDC 2011 he was using Wii controllers but now the game uses Playstation Move controllers. I can see one reason why the switch occurred. On the top of a Move controller is an orb with an LED inside which allows the orb to emit colored light. It looks like a glowing lollipop. In JS Joust the colored orb is used to identify players (with unique colors), to alert players when the game begins (everyone’s controller flashes white) and to show when a player has been eliminated (the controller light turns red before shutting off). Compared to the Wii controller, which relied on short sounds/rumbles emitted from the controller to convey when the game began or when a player was eliminated, a Move controller’s colored orb makes it immediately apparent who is in the game and who has been eliminated, allowing spectators to watch more easily too.

It’s the aspect of spectating JS Joust which got me thinking about ways of combining the game with methods of game analytics, visualization and stat tracking – which I lump together here. A lot of game analytic and stat tracking systems are useful for spectating/analyzing gameplay during or after play has ceased. But combining the two, analytics and folk games, at first seems contradictory if you understand the philosophies behind both game analytics and the design of folk games such as JS Joust.

Blasphemous Analytics

For the past three to four years my work has centered on game analytics and visualization. Mainly, this consists of capturing and analyzing data from games. A very simplistic example is a leaderboard. Player scores are captured and ordered based on some criteria of importance. Higher scores are better, for instance. Leaderboard ‘score data’ is not really analyzed per se but the cycle of capturing and organizing data based on a set of criteria is vital to game analytics. Developers can capture all sorts of data related to gameplay and player behavior in order to find interesting patterns. The Data Cracker game analytic system I help build for the game ‘Dead Space 2’ captures player data such as weapon damage, kill/death ratios and win/loss records. DS2 designers use the system to determine if the changes they make in the game (let’s say they alter a weapon’s damage amount) are having the desired effects on gameplay (the weapon is used more often). So game analytics has the mystic of using methods to objectify game events and player behavior in hopes of being able to learn more about what is happening in a game. It is this objectifying mystic which flies in the face of some game design philosophes like the ones promoted by the creator of JS Joust.

There is a specific design philosophy behind Doug’s games like JS Joust. He argues:

“Games that are intentionally designed to be ambiguous, abusive, broken, or otherwise ‘incomplete’ can help shift the focus from winning to a decidedly festive, collaborative, and intrinsically motivated kind of play.”

Doug has a problem with rules. By designing games with ambiguous, abusive, broken and incomplete rule sets it forces players to create their own. It forces them to play more than game, where play isn’t about winning but about experiencing the social comradery one has when playing with others. The “absence of technological systemization can be understood as an attempt to foreground social context,” Doug says, as we can see in JS Joust. The game declares a winner but how players get from turning on their controller to being the last player standing changes from context to context. Discussion around ‘house rules’ is a common occurrence because the game “deputizes” the player allowing them to dictate how the game proceeds. The game is given little power to monitor and enforce a rule set, leaving the job instead to players.

The contradiction between game analytics and folk games is one of systemization. Game analytics systematically objectifies a game, creates categories and chops a game into pieces for analysis. Folk games refrain from systematically objectify a game in order to provide players with as much power to alter the rules of the game as possible. Players can “create, change and argue” about rules and procedures just fine without the “authority of the machine” supervising them, as Doug mentions. Coincidentally, I make the exact same argument in regards to game analytics, however blasphemous that may seem. I see game analytics as a tool players can wield. Not as a system of authority but one which affords creation, change and argument.

Unfortunately, I often feel trapped when discussing game analytics with industry developers because the objectifying aspects of the domain are so strong. I hate that I’m inundated with questions about A/B tests and how game analytics can produce ‘actionable insights’ from data. It’s bullshit. Data is like paint. You can use it to create an incredibly realistic mundane landscape or something utterly surreal. Solely focusing on the objective systemization of game analytics – your ‘useful, effective, actionable’ aspects – locks us into an un-critical path where systems are built as means to an end instead of questioning why we seek such ends in the first place.

If Beetles Could Joust

In a recent volume of the Parson’s Journal of Information Mapping, artist and educator Brittany Ransom details a visualization project where she experiments with capturing the travel patterns of bess beetles. These little guys have a number of intriguing attributes which drew Ransom’s attention. Bess Beetles are part of the natural decomposition process, breaking down waste and dead vegetation, and are incredibly strong, able to burrow into wood and pull many times their bodyweight. They live in colonies but pair off into male-female partnerships to take care of larva. Sound is also their main mode of communication (for defense, courtship, etc.) as they live mainly in the dark. But the main reason Ransom wished to experiment with bess beetles is to understand how they navigate their environment, something that we take for granted in our world today with such easy access to GPS and Google Maps.

In order to study bess beetle movement Ransom devised a small tracking backpack a beetle could carry. The backpack consisted of a small LED light and battery component, which is lightly adhered to the back of each beetle in order to allow the beetle to remove the backpack after rubbing against a fixed surface such as wood. Once the beetles are placed back into their natural environment, Ransom uses a number of visualization methods including long-exposure photography to produce images like the one below. Long-exposure photography allows each beetle’s travel path to become illuminated as a single streak of light representing the beetle’s movement data over time. It was these images that drew me to wonder can I treat Doug’s Joust players like Random’s beetles?

When I saw Ransom’s image of the beetle with an LED light I made the connection in my head, ‘that beetle looks ready to play Joust.’ It just clicked. Joust players affix LED emitters to themselves, why can’t I capture their movement patterns? In the same way Ransom wished to understand how beetles navigate, I wish to learn how Joust players navigate. It can also be argued that the methods used in Random’s project subscribe to the same philosophies as folk games. Tracking movement can of course become very analytical, focusing on accurate location tracking across time and space. Instead, fixating on the movement of the light takes away the common systemization of capturing accurate measurements, which we find all too often in game analytics, opting instead to systematize light data as a means to produce data visualizations which are ambiguous and interpretable by players and spectators.

Using various video cameras and gathering up a number of ‘in-need-of-a-break’ graduate students, I captured multiple sessions of JS joust. Using methods like photo blending and video echoing I produced long-exposure looking images based on each session played. What I then visualize is very similar to the images of Ransom’s beetles.

Many nuances of Joust gameplay appear in these visualizations. Things like players steadily creeping towards each other before attacking. Players becoming locked in circling motions like a dog chasing its tail. The ill-fated lunges which cause the elimination of both attacker and victim.

Then there are visual records of the funny events which happened during play. The time Bobby ran around the entire play area taking out others as he went. A game that lasted three seconds as three out of the four players all lunged after each other only to each eliminate themselves. Or the sweeping victory dance Andy created after winning a round.

Even though I am going against the Joust mandates to refrain from graphics or systemization, these visualizations can be seen as adding an additional layer to Joust. Not a layer which seeks to cover the game’s design philosophy but rather attach an additional experience for players and spectators to enjoy.

Attaching Experiences

In a recent blog post by Doug Wilson, detailing his “unsimulating” design work on games like Mega-GIRP and Robo-QWOP, he makes a comment that it is “equally fun to design around existing games” as it is to produce brand new games. I wholeheartedly agree with this comment because game analytics in general is about designing around existing games. My visualizations of JS joust player movement can be seen as my attempts to attach another mode of spectating alongside the game. Everything I do regarding game analytics is designed around existing games but, unlike Doug, I don’t produce other games. I do however create additional experiences for players to enjoy and, based on what I have seen from other commercial products made for the Kinect, can see how to combine a game like JS Joust and my visualizations.

One example product is Double Fine’s Happy Action Theater, which is a collection of 18 Kinect-enabled playful “activates,” which is not necessarily a game but has a lot in common with folk games. There are little if any rules to speak of in Happy Action Theater. The activities are deliberately designed to be easy to join and make your movements immediately impact what is happening on the screen. One specific activity is the ‘Clone-o-matic’ which takes a series of five time-lapsed photos giving players the ability to change position between each photo. Since a Kinect can determine depth, players can physically get in front or behind their past selves within each subsequent photo in the series. On a more basic level, other games like Kinect Adventures take photos during play too, displaying them after a level is completed. These photos allow players to reminisce and reflect on their past gameplay, something they may not have had the chance to do otherwise because they were enthralled in the action taking place during play.

In a similar vein compared to capturing images using the Kinect, I can see setting up a camera such as a Kinect or the PS Eye Camera and using it with a game like Joust. The game itself would be played without the use of the screen but after a game concluded players could see visualizations of their gameplay across time. They could then save them, share them and perhaps be given more control over how the visualizations are produced (adding image filters for example).

The only difference between JS Joust and Happy Action Theater is the reliance on the screen. HAT does, Joust doesn’t. But why can’t we have both. Pretty much every major digital gaming platform has both a screen and a camera, why not leverage both but not necessarily at the same time. This is exactly what I’m trying to achieve with the JS Joust visualizations. Sure, Joust can be played without the need for a screen, but why not take advantage of a screen to provide a visual rendition of the game as an additional experience next to the game experience. I can see a scenario where spectators are given control over the visualization allowing them to fast-forward/rewind time, take snapshots or visually warp the image while others play the game. It’s about using the systemization of game data not for analytic purposes but to create a reflective experience which can be just as fun as the game itself.

Really Doug and I are paranoid designers who believe the ‘authority of the machine’ is restrictive and must be dealt with. He seeks to remove it and I seek to alter it. Our ideas are not mutually exclusive though. Game analytics can be “ambiguous, abusive, broken, and incomplete” even though the ‘analytic’ side often dominates the discussion. This brand of reflective or reminiscent game analytics can be attached to folk games and regular games alike. Contemplating a richer domain for how we may present game analytics gives game designers additional means they can use and increases the types of playful experiences they can provide players.

So remember the little beetles when playing JS Joust and how we can reflect on their world as we do our own. It’s not always about analyzing the game, it’s sometimes just about the play.

Spoilers, Spoilers, Spoilers. If you have not finished the single player portion of Portal 2 do not read any further. If you have, you may pass. Also check out Giantbomb’s Portal 2 spoiler interview with Valve’s Erik Wolpaw, Jay Pinkerton, and Chet Faliszek. It’s great.

I ran into a problem with Portal 2 around chapter 7 of the game. I didn’t want to solve the puzzles anymore.

The whole game up until that point had been one long training session, and it continued in Chapter 7. I think it was this puzzle, the second propulsion gel puzzle that really stalled the game for me. The puzzle itself is very elaborate, many platforms need to be configured properly with the correct gel in order for you to gracefully reach the exit. But that is the problem, understanding how to properly configure the platforms was easy. There was no moment of “Well how am I going to do this?” I had very few moments where I was completely stumped in the game or felt really good once a puzzle was solved.

What heightened the onset of disappointment with the puzzles was the fact that the dialog and story in Portal 2 are amazing. The entry and exit locations to each puzzle are the best sections of the game. It must have been the hunger to see the rest of the story that eventually led me to despise having to traverse another puzzle.

Then I thought, I’ve felt this way before in a game. I feel as though the monotony of the game’s mechanics got in the way of progressing through the game’s story, a story I am both invested in and determined to see the end. Where have I felt that before? Oh, point-and-click adventure games.

I’ve played numerous point-n-click adventure games where the trial and error puzzle solving aspect of the game put a major damper on my progression and thus halted the storyline. Portal 2 was a little different, the puzzles acted more like a Rube Goldberg machines that I had to setup properly before continuing but all the pieces were there for me to place. Not much trial and error involved but I felt the same as in the adventure games. “Just let me see the rest of the story,” I said.

Though the notion that Portal 2 as a point-and-click adventure game is intriguing. Many people call Portal an anti-FPS or at least an alternative FPS given that a player shoots from a first-person perspective but does not seek to kill anything with the shooting. Portal is given the genres of Action, Puzzle, and Platform on Giant Bomb while Portal 2 is given Action-Adventure and Puzzle. In comparison, The Secret of Monkey Island, a notable point-and-click adventure game, is only marked with the Adventure genre. However, there is a mix up, Portal 2 doesn’t really have a lot of “Action” and The Secret of Monkey Island certainly has a lot of “Puzzle.”

When the connection came to mind that Portal 2 was more similar to say a game like The Secret of Monkey Island than Left 4 Dead, I remembered an article by Clara Fernández-Vara which goes into greater detail about the point-and-click adventure genre (in fact she wrote a whole dissertation about adventure games so I think she is a good source to tap). Taking her analysis of The Secret of Monkey Island it is very easy to swap that game out with Portal 2. Below are some quotes from Clare’s article with added analysis of how they apply to Portal 2.

Defining Features of Point-and-Click Adventures

“Adventure games are story-driven, meaning that the gameplay is practically inextricable from the story. The gameplay is based on puzzle-solving, which means that solving puzzles makes the story unfold.”

This is exactly how Portal 2 to setup, you must solve puzzles to progress through the story. Puzzles which are intricately linked with the overall story of a rogue science corporation and the strange robots and inventions that it produced.

“Another defining feature [of adventure games] is that there is always a player character, who acts as a surrogate of the player in the gameworld.”

Ever since the first Portal players know they are playing as Chell. Players are immediately confronted with the avatar of Chell in the opening room of Portal, orienting them to the fact that portals are connected spatially. Portal 2 is no different, though it takes longer for the player to have the ability to see Chell as their avatar.

“The player commands the player character using commands to navigate the space or affect the gameworld, usually following (explicitly or implicitly) a verb + object interaction pattern (e.g. “open door” of “walk to archway”).”

Portal 1 and 2 are very good at providing verb+object interactions. Button Press+Cube = Open Door. Drench in Repulsion Gel+Turret= Bouncy Turret. Walk+Portals = Breaking of Space-Time Continuum. It should also be noted that this is a different approach to adventure style FPS games when compared to a game like Fallout 3. Games like Fallout 3, Mass Effect or KotOR resemble a lot of point-and-click adventure games because of their dialog trees. Dialog does act like a type of puzzle in these games where players need to negotiate or otherwise unlock proper dialog options in order to find new ways to complete quests or find hidden content. They however do not emphasize the verb+object interaction in the worlds and instead focus on combat as the main world interaction (outside of dialog).

“One of the great things about adventure games is that they can be played by more than one person, with (almost) no struggle about who has the controls, or having to design a multiplayer feature, special user interfaces or including additional controllers. The frequent absence of time-dependent actions and events makes it easier for two, or even three players to sit down and play together in front of the computer.”

A lot of Portal 2’s gameplay is not time dependent at all. You can solve pretty much every puzzle at your leisure. So it is not hard to imagine a few people somewhere sitting around a computer or console and helping the main player solve Portal 2’s puzzles.

Objects and Abilities

“It was the basic object-hoarding that we had learned in other [adventure games], you take whatever is available for pick up because that means it will be useful later on.”

Portal 2 diverges from stereotypical point-and-click adventures by not having an inventory (unless you count the portal gun). In fact it is impossible to bring anything into the elevators that transport the player to each new puzzle (which offered a funny companion cube moment in the game). However, I would argue that many point-and-click adventure games have stages where the player collects a set of items and then use those items before moving onto the next stage of the story. An obvious example is how the five The Tales of Monkey Island episodes are setup to only allow a few select objects to bridge the different game episodes. In Portal 2 the environment provides the needed items that the player has to use to solve each puzzle. If there is both a repulsion and propulsion gel pipe dripping in the level then they will most likely be used in combination to solve the puzzle. There is no need to carry items.

“One of the most memorable parts of [The Secret of Monkey Island] is sword fighting, or rather, insult-fighting. In order to master the sword, we had to defeat the Sword Master of Mêlée Island. For that to happen, like in all good adventure games, we had to fulfill a set of other conditions, namely, getting a sword and finding someone to train Guybrush.”

In Portal 2 players are on a grand journey learning to use portals, light and gels in order to understand how to use them at key moments in the game, for example the final Wheatley fight.

“In the last part of [The Secret of Monkey Island], we had to venture into the depths of Monkey Island, whose labyrinthine passages we could only navigate with the aid of a magical object, the mummified head of a navigator. We had to hang the head by its hair, and it would turn to the proper path.”

It was delightful to have Wheatley at the beginning of the game, and then Glados, as a sort of sudo guide through the Aperture complex, acting as Portal’s own version of the mummified head. Though not an adventure game concept in general, I think comparing Wheatley and Glados to a mummified head is amusing.

Puzzles

“Both King’s Quest V and the Indiana Jones game were afflicted by some of the recurrent problems of adventure games — they were very well written, had good stories and interesting puzzles. But some of the puzzles consisted of trying to guess what twisted and quasi-sadistic sequence of events the designer had envisioned as their solution.”

The chapter 7 puzzle that I mentioned at the beginning sort of felt as if I was just putting together a sequence of events that the designers laid out for me not solving a puzzle on my own. But there wasn’t too much guess work involved. The puzzle rooms were laid out in such a way that if something was uniquely standing out, then it most likely had to be used in the puzzle solution. There are other puzzles that have multiple solutions though, for example the first Wheatley puzzle in chapter 8.

“Having a single sequence of actions means that if the player cannot solve one puzzle, she is stuck in the [adventure game], because there are no other puzzles for her to solve and come back later to the one troublesome puzzle. This is the “linearity” that is often cited as a handicap of adventure games.“

This is Portal’s handicap as well. If a player cannot solve a puzzle they don’t progess. Clare mentions that in The Secret of Monkey Island the game provides the player with multiple puzzle paths for the player to pursue. Thus a player can leave a difficult puzzle for later and work on solving a different path. It leaves me wondering, what if Portal 2 was a multi-path game?

“Puzzles help us discover things about our own world, and make us see things that we already know in a new way. They also deal with information in a playful way — they point to a missing piece of information, and invite the player to fill it up … There are different types of insight, depending on how information is connected in order to solve a puzzle:

1) Making apparently irrelevant information relevant.

2) Using analogies and metaphors, in order to draw a non-obvious relationship between two pieces of information.

3) Combining two items in order to form a novel one.”

Finally, I felt this list of how to provide players with insights to solve a puzzle was relevant to how Portal 2 is structured. First, seemingly irrelevant information like the fact that Conversion Gel is made out of lunar rocks became very relevant in the last moments of the game. Second, analogies or example of how to use substances like repulsion gel where shown before the player had a chance to use the substances. Third, many puzzles had the player combining cubes, light bridges, and different gels together to solve the puzzle.

I believe the woes I experienced during Portal 2 are connected to the fact that Portal 2 is a point-and-click adventure game that suffers in some places due to linearity and simple puzzle design. Additionally, the tremendous story exaggerated those woes because I found the story so compelling I wanted to race through the gameplay near the end of the game. But I don’t think designing the game differently would have fixed my personal experience.

In terms of linearity, I mentioned that it would have been interesting if Portal 2 was less linear. Perhaps allowing the player to choose which gels they wanted to learn first would be a viable example. Then again, I would have probably experienced the same dread of knowing exactly how many gels I had to learn in order to get on with the story. In terms of simple puzzles, if the puzzles were harder I may have just resorted to using online walkthroughs and videos.

All in all, Portal 2 is a great game. The cheeky dialog and puzzle solving (for most of the game) is a lot of fun and with a completion time of eight hours it provided a lot of entertainment. Thinking about Portal 2 as a point-and-click adventure game also is a great way to understand how that genre’s style of gameplay is still alive in popular games today, even games that are outside the current adventure game reboot lineup coming out of Talltale Games. Perhaps we need a new genre to describe them. Point-and-click FPS seems to simple but hopefully we will see some more soon.

Like many others I jumped on the Magicka bandwagon this week. Something about not having to level up 85 times to get awesome spells appealed to me. But seriously, it’s great to have games that offer “crafting spell casting” in contrast to typical, one-button per spell or gesture-based casting like in Black and White.

Before I purchased the game I was roaming around online in search of Magicka information and found Magickapedia, a standard game wiki. However, I found this page entitled “Possible Spell Combinations” and stopped, reviewing the long list of possible element combinations available in the game.

At first I thought, what a great visualization. The length of the page is long, which helps express the large number of element combinations. It’s also setup in a hierarchy format – Arcane element first, Water element last – and follows that format to present each of the 1123 possible combinations (each element cancels another element out, hence the possible spells is not [10 - the number of elements] to the power of [5 - the number of element slots]).

Since the spells are setup in a hierarchy they can also be represented using an Icicle graph, which is a space saving visualization for presented hierarchically categorized data. And with that it lead me to create an entire infographic around the element combinations in Magicka.

Big thanks to the contributors at Magickapedia, I used the site as my reference source. Also, thumbs up to Arrowhead Games for putting up high res concept art, and for producing a great game. Finally, protovis was used to produce the icicle graph, which is the visualization package I used to develop the Dead Space 2 analytic tool, Data Cracker.

“Play with Data” is a series of articles looking at game analytics and how game data plays a major role in games. A role that is less about the gamepocalypse and more about play, with data.

I’m sick of my family saying “you’re not working, you’re playing” every time I mention I’m studying a game. Mainly because it is true. Well, it is a little of both. When I play I analyze. There should be nothing wrong with that.

Why do we believe that analyzing something, approaching it scientifically and methodically, has to be serious work. In fact, that is exactly the opposite of what most serious data analysts and scientists believe.

Take a few of Stephen Few’s … *intentional … personality traits a good data analyst should exhibit: Interested, Curious, Self-motivated, Open-minded, Flexible and Imaginative. Those sound very playful to me. These traits are lumped in right next to the Analytical, Skeptical and Methodical traits as if there were no differences between them.

If play is a part of analysis then why shouldn’t we study how play can combine with, oh let’s say, information visualization (infovis), a heavy hitter in the realm of data analysis.

In a new article written for the Parsons Journal for Information Mapping I tackle that very issue. Using games as my medium of choice, as if I would use another, I examine how play and infovis fuse together to form playful visualizations to support and promote play.

While it would be easy to argue that gameplay itself is a form of infovis, I take a literal route providing game-related examples which mimic typical infovis systems and exist just outside of normal gameplay. Examples like Darkfall’s political map, players using cartology to represent the political turmoil of Darkfall’s continents, or Need For Speed’s Autolog recommendation system, which proceduralizes the phrase “neener neener” as a driver of competition.

The article ends with a post-mortem of sorts: given the examples explored, how do data analysis interactions promote different types of play and/or players. It will be interesting to see how these interactions continue to crop up in my other articles about game analytics, even when discussing analytics meant for serious analysis of games.

Over the summer I had the pleasure to work at EA Redwood Shores as an intern. Usually being an EA intern means joining a development team for a few months, working on one of EA’s games. However, for my internship I was placed in the CCO, the Chief Creative Office, a research oriented group at EA. The CCO basically houses some of the heavy hitters at EA, like Rich Hilleman (EA’s CCO) and Scott Cronce (EA’s CTO), along with a number of team members working on various projects. A much smaller operation compared to the size of a typical EA development team but none the less a very powerful one.

During the summer my fellow intern, Jeff, and I were charged with the task to research, design and build a game analytic system for an EA team. Game analytics basically refers to the practice of capturing data related to gameplay, for example recording a player’s behavior while they play, and analyzing the data for insightful information that can help improve the game’s design. Seeing as my dissertation work surrounds the topic of game analytics I could not have pitched a better project to EA than the one we were given. Plus, since we worked at the CCO, we had a lot of freedom to meet with many development teams and discuss their game analytic needs.

The team we ended up working with was the Dead Space 2 Multiplayer team. As of this writing, and throughout the entire summer, the Dead Space 2 multiplayer gameplay is still shrouded in mystery. This made the project even more relevant because (a) the multiplayer feature is new to the Dead Space 2 franchise and (b) it was early enough in the dev cycle that any game analytic tool that was built could have a huge impact on the design. The experience was flat out one of the best projects I have ever been a part of, to say the least.

The tool we ended up building is called Data Cracker, which is a play on the concept of ‘Planet Cracking’ that exists within the lore of Dead Space. Data Cracker taps into data depicting player events that occur multiplayer matches. Without giving anything away, an obvious example of a player event is which player(s) won the match. Those events are sent to EA’s servers and the tool grabs the data, aggregates it into different values for analysis and visualizes those values within a web interface.

My main task on the project was working on the visualizations. We ended up choosing Protovis for our visualization library (built in javascript), mostly due to the fact that the group wanted to focus on HTML5 (however I’m still a diehard Flash developer and think Flare is an awesome visualization package). It turned out to be a fairly good library to work with and my only complaint is that it is much harder to create complex interactions compared with Flash. I was able to combine Protovis with other javascript libraries like jQuery however, which fixed some of the interaction/animation limitations of Protovis.

I can’t say much more than that at this time but I am working on papers that dive into the design and development of the tool. Those will appear on my site soon as will a number of off-shoot game analytic projects that I am working on for the rest of the year.

Like many others I have been gallivanting around the Milky Way Galaxy this past week in the highly anticipated game sequel, Mass Effect 2. I will not go into great detail describing the game but in the simplest of terms it is an interactive ‘choose your own adventure’ game where the player travels around the galaxy in your star ship, finding planets to land on and shoot enemies. In the most complicated terms it is an RPG/FPS hybrid space opera with branching storylines and consequences that stretch across multiple games. However you want to slice it, I’m actually interested in some of the smaller experiences you have in the game, the ones that don’t mean as much in terms of scope. Specifically, what is with all of the visualizations in Mass Effect 2?

(There are no story spoilers below but game mechanics are discussed)

Visualization of information, particularly game information, is a key component in my dissertation work and I was blown back by how blatantly BioWare, the makers of the Mass Effect series, has taken a number of visualization principles and turned them into games … which I found fun. It can be argued that all games with a user interface must “visualize” information for the player but what Mass Effect 2 has done is highly relatable to the practices within two visualization domains, Scientific and Information Visualization. The major difference between these two domains being Scientific Visualization attempts to render information in a realistic fashion (for example, a 3D visual of a human heart), while Information Visualization, or InfoVis, tends to visualize abstract information that may not have a “realistic” form (such as stock market price fluctuations).

Mass Effect 2 uses both types of visualization domains during gameplay and there are four main areas where visualizations are used: Loading Screens, Bypassing Locks, Hacking Terminals, and Mining Resources. The last three are mini-games, I’ll describe them but will provide videos for each area to help understand the interactions that take place.

Loading screens

First, loading screens are displayed when game content is loading. If the player moves to a new area in the game a loading screen is shown while the area is being loaded into memory. Most games have some form of a loading screen and most are non-interactive, they are eye candy or in some cases a boring loading bar.

The loading screens for Mass Effect 2, while still not interactive, are fake scientific visualizations that relate to what is going on in the game. For example, if the player is being picked up from a planet the loading screen will show a visualization depicting the main star ship, the Normandy, swooping in to collect the player’s shuttle. While none of the information that is shown is “real” the fact that BioWare took the time to make visualizations for each situation that the player would be in, whether on their ship, on a planet or traveling in-between, tells how important these non-interactive portion of the game are to them. Plus they are aesthetically pleasing too. Here is a video of most of them.

Bypass Locks

The first type of mini-game in Mass Effect 2. While the player is ducking and diving trying to kill enemies they may run across some safes that they can unlock, or bypass as it is called, to receive extra money. In order to bypass a lock a player must connect a number of connections points (called Vias) on a circuit board schematic. The connection points are hidden to the player but rollover a point reveals that point’s symbol and it is up to the player to find the other matching symbol on the circuit board (video below).

This is a memory game, the same type of game you played as a kid, find two of the same hidden object. The interesting part about this mini-game, though, is that the matching points are not laid out arbitrarily on the screen. Notice the image of the circuit board behind the connection points; it’s a scientific visualization of the possible circuit connections. Two matching points will be connected along the circuit’s schematic lines and after playing over 50 variations of this matching game I can tell you once you understand the layout of the circuit schematic finding the matching points is trivial (well more trivial because the mini-game is already easy).

One can wonder, if BioWare can create a mini-game that is played on a visualization of a circuit board how might it be possible to build a game that dives deeper and is used to teach computer engineers about circuit board construction and layout?

Hacking Terminals

If the player is not bypassing locks then they are hacking computers. Matching is still a mechanic used in this mini-game but in a different way. The game operates as follows: Three columns of source code segments are shown to the player. Each code segment has its own unique color pattern and text layout, which makes them visually distinguishable. The player’s job is to match the code segment shown at the top of the screen with a copy of that code segment found in one of the three columns below by moving their selection box with the arrow keys (or a D-pad on the Xbox). Three code segments must be matched before time runs out. Each column is constantly moving from the bottom to the top, adding to the difficulty, where the code segments at the top are removed and new ones appear at the bottom. There are also error boxes that if the player runs into one while using the arrow keys to move around they will have to find an additional code segment.

This mini-game epitomizes the reasons for using InfoVis. What the player is doing is analyzing the code segments looking for patterns in the visualization, exactly what InfoVis is used for. In this case players are looking for a specific pattern, a visual piece of code that looks like the one at the top of the screen. It’s no different than say visualizing financial information and allowing a user to find interesting outliers or patterns within sales figures.

What BioWare is doing different, however, is saying “here is a ton of information, find this specific phenomena in a set amount of time” which gives the player a goal, something that turns the process of analysis into a game. Information visualization is often said to provide users the ability to explore information but giving someone a specific item to look for, and under a time pressure, is an interesting twist to using InfoVis.

Mine resources

Saved the best for last. This mini-game is perhaps the most tedious of the three but in terms of using InfoVis it is the best one.

In Mass Effect 2 the player needs to collect resources from planets in order to upgrade equipment. Resources are gathered by traveling to a planet and sending down probes to collect the resources that exist on the planet’s surface. But probes cannot be sent down willy-nilly to collect resources; a player must find a location where resources exist first.

Players do this by scanning the surface of a planet and when their scanner rolls over a section on the surface that has resources the line chart to the right of the planet spikes showing which resources are present. The line chart works similar to a seismometer, meters that track waves through the Earth, where areas with higher amounts of resources will make the meter jump higher and the lines are continuously fluctuating has players rollover different surface areas. This is better shown with a video.

I enjoy this mini-game because unlike the others it is not limited by time and is very ambiguous. A single planet may have 30+ resource points on the surface but some points will give more resources than others. The player must decide if they want to only find high-yield resource points or strip the planet bare. Plus there are no distinguishing features on the surface of a planet to tell the player where the resources exist. Therefore, the player must rely on the visualization to help them. They can rely on sound too, anytime the player scans an area with resources a clicking noise can be heard, getting faster and loader when close to a resource point (each resource type has their own sound as well).

Just like the other two mini-games I wonder how real-world information could be used with the mechanics of this mini-game. Would it be possible to set up a game similar to this one but use real geographic data from Earth or perhaps the Moon, or Mars? Certainly it wouldn’t have to be resource information, I bet the oil companies would love a system that finds oil deposits automatically, but other information mapped onto a surface of a planet for players to explore and find might be fun.

Here is my main point: the fact that visualizations are used for serious and important purposes makes them even more interesting in the context of a game. Academics are always talking about how games can engage students, getting them more involved with their school work. Well, why not take that principle even farther and combine it with concepts such as InfoVis which is already used to engage users with information that is important to them. These Mass Effect 2 mini-games teach players how to find patterns within information and offers a different spin on InfoVis by adding constraints which force a player to focus quickly on what information is present. That’s why I like them and that’s why I hope to see more games follow suit in the future.

Seems that the developers of Gran Turismo 5 (GT5) thought it would be cool to link together the real world of racing with their virtual world of racing. They built a system called the Data Logger Visualization (DLV) which allows players to go out to real race tracks that are used in the game, capture video of their laps around the track, and upload the footage into GT5 which recreates their laps on a virtual track.

The whole system sounds pretty cool but I have some nagging doubts. One, how many GT5 players are going to find themselves on a real race track from the game? Granted, some people who play GT5 are car/racing nuts (my father included) so perhaps for those players the DLV system makes sense. Two, using video to recreate a cars position around a track seems inefficient; would not recording position with geo-location devices, even if on a cell phone, be a faster method (no video analysis required)? Then again, if a player is racing on a real track most likely they want a video of their experience, not a bunch of geo-coordinates. So, the system will most likely be used by some GT players.

Kudos, to the GT team though for making a system that can analyze video footage and use it to translate a car’s real world position onto a virtual world’s track. I think I have my Dad’s next birthday present, if GT5 ever comes out.

DLV video below.

I am in the middle of preparing for my qualifying exam to become a Ph.D. candidate. Which means I can then, officially, begin my thesis. So I am not promising that I will be writing anytime soon but I’m thinking that I will be writing something soon.

In the mean time I updated my publications list for 2009 and my recently accepted paper The Implications of Improvisational Acting and Role-Playing on Design Methodologies that will be presented at CHI 2010. Not my typical M.O. considering I’m not a HCI person, nor an acting person but that paper spawned from working with Dr. Brian Magerko for two years on a research project studying improv actors. It will be an interesting talk to give to say the least.

We are on top of the Human Ecology Building on Michigan State’s Campus. The roof sits six stores above the ground, is only flat in the one section, where we are at, but that section has battlements around the edges. Which, needless to say, makes for an excellent roof to take in the view.

I have always enjoyed being on roofs. Any time my dad had the ladder out around the house I wanted to shimmy up to our roof. It must be the height, but perhaps it is having the sky above me. That’s a key differences in what makes a roof a roof. Taking in the view from inside a skyscraper verses atop its roof is very different, like standing on a mountain instead of gazing at a picture. Roofs are terrain in this respect, land open to the sky. Windows are just glorified holes in the side of a hill.

However, roofs are not open terrain. Jason, Marie and I had to sneak onto the roof of the Human Ecology building. There were two locked doors barring access and the shear fact that those doors could be opened easily if one was on the roof (which is why Jason had to climb out the window) says that the building’s architect did not wish anyone to be trapped on the roof. Human occupancy on a roof should be limited and fleeting. Large machinery, communication equipment, ugly cements, rocks, tars and shingles are placed on flat top roofs, only a repairman should see such things. Vaulted roofs on personal dwellings are dangerous to walk on and typically used to accent the property. All these features point to the fact that roof terrain should be controlled, hidden or serve merely as aesthetic. But not so in games.

Perhaps you have noticed, open world games are thriving on rooftops. Assassin’s Creed, Infamous, Mirror’s Edge and Prototype have each utilized rooftops as terrain. That is unrestricted terrain, roofs are appropriated as playgrounds. Players move freely and experience the game’s action atop the skyline. Certainly there is a street level down below the cityscape, most of the games have indoor areas as well, but the roofs are where players are drawn.

One would have to assume that the reason for this love affair with roofs is due to the taboo nature the roof has within our culture. General access roofs are rare. In de Certeau terms, those with strategic authority wish to keep us everyday citizens from tactically using roof space. No wonder our media are filled with rooftop chase, fight or love scenes. Those are so rare in real life that we must imagine what they would be like in our entertainment escapes.

So how are roofs imagined in open world games? While attempting to find literature that specifically talked about rooftops, or heights in general, I came across a quote in an unlikely, but welcomed, text that may help answer that question. One avenue I took in my search was the notion of having the high ground in combat situations. Descending while fighting is preferred to ascending while fighting, starting at a greater height compared to one’s opponent increases the chances of victory. Additionally, each open world game relies on combat in some respect so a combat relation to terrain is fitting. This led me to my shelf looking for The Art of War and while there are quotes stating the “High Ground” concept it was another quote about terrain that caught my eye:

“By terrain I mean distances, whether the ground is traversed with ease or difficulty, whether it is open or constricted, and the chances of life and death.” (Sun Tzu, The Art of War, trans. Samuel Griffith, 1963)

Traversability, openness, and endangerment, as to describe terrain, are three ways of describing how roofs are used in games.

Traversability

Each of the four open worlds I mentioned rely on speed and freedom of movement. Mirror’s edge is the most obvious example given that it is described as a “First-person Running” game. Racing to the end of the level, jumping over obstacles with ease and taking alternate routes all add to the traversability of the rooftop environment in Mirror’s Edge. Prototype is the other obvious example, Alex (the protagonist) has the ability to run up buildings, jump long distances and glide from skyscraper to skyscraper. In both Prototype and Mirror’s Edge the purpose of the roof is to provide an avenue, a corridor, for players to move.

Infamous and Assassin’s Creed take a different approach to roofs, one that is more strategic. Both games employ a parkour system which players use to climb up structures. While this makes it easy for players to climb up buildings in order to access any roof, getting to the roof quickly is another matter. For example, in both games the player can be knocked off a building by projectile fire if an enemy is in pursuit. Yet, in some cases there are quick access points to the roof, such as ladders in Assassin’s Creed. Once atop a roof the games turn into something similar to Mirror’s Edge or Prototype, though the speed is toned down. True, a player can gain upgrades in Infamous which allow them to glide through the air for short bursts or glide across telephone wires but before that time, as in Assassin’s Creed too, it is less about pure speed and more about maneuverability. Nonetheless, whether the focus is on speed or maneuverability, the rooftops are extremely traversable.

Openness

Three of the games, excluding Assassin’s Creed, have in-door levels. In these spaces I personally felt confined; the spaces are big enough to maneuver but still limiting. At these times the gameplay mimicked the feeling of being in an arena instead of upon an expansive terrain. Prototype players have to enter military bases from time to time where they are restricted to a, roughly, two store room. With the intense combat that can occur in Prototype it wasn’t hard to become surrounded by enemies in these areas, especially in the early parts of the game. Infamous and Mirror’s Edge interior areas instead felt like linear paths; where as on the roofs you felt free, in doors the player is told “you must go this way.”

On the roofs though, freedom reigns supreme. Along with speed and maneuverability, roofs gave a greater sense of having more choice in how to approach gameplay. Determining how to get from A to B, which missions to take, and the means to accomplish those missions all give a sense of agency to the player. Though the roofs are still contained at times. Mirror’s Edge, while I have been lumping it with open world games it normally would not be considered as such, is still a linear game, the finish line is always given to the player. Assassin’s Creed and Infamous restrict access to certain portions of the cityscape and only become truly open about mid-way through the game. But otherwise, the game space atop the city feels open and free, one that can be entered and exited at any time and in any way.

Endangerment

Of course danger exists among the rooftops. Whether it be archer’s in Assassin’s Creed, snipers in Infamous or Mirror’s Edge, or Helicopters in Prototype, the player needs to watch their back on the roof. Combat is supposed to start on the roof and descend to the ground. Infamous and Prototype give players abilities that rely on getting above a target in order to launch surprise attacks. Players in Assassin’s Creed are pushed to take out the archer’s that line the roofs before they move to the street level. Mirror’s Edge does not even have a street level, falling off the roof equals death, so combat starts there and stays there.

In contrast, on the street combat becomes close quarters. Players can be swarmed when fighting at ground level, having to fight their way out. In Assassin’s Creed this is dangerous, being an assassin the player is suppose to hit and run, not stand and fight. Infamous and Prototype turn into a brawler when not fighting on the roofs. Melee and “Area of Effect” attacks are extremely effective, and a little button mashing is required. But combat always returns to the rooftops.

There are defiant distinctions between the rooftop and street level combat but roofs always represent the high ground. As the rule says, fight from the high ground, and when on the street guess what the player does not have, a strategic position. Basically, this means that while fighting in the streets the player has to deal with the enemies around them and the enemies on the roof. This is why combat returns to the roof because eventually the player must always deal with the enemies that have the higher ground. Thus shifting between the roof and street level is of extreme importance but a shift that adds dimension to these games.

–

Roofs are terrain in these respects, or at least they are in games. In an age when it is exciting and risqué to have a party on the roof or install a rooftop eco-friendly garden to combat global warming, games are giving players the experience of traversing roofs in the same way one would explore urban streets or even the wild hinterlands beyond. Certainly the increased popularity of other concepts like the open world game genre and parkour has exacerbated rooftop gameplay too. Combining all of these factors allow us as players to take part in a taboo adventure of running across rooftops while we have probably never even been on the roof of the building we are sitting in at this moment. Perhaps if we were rich men we would build a home with an open roof for us to play or even fiddle upon (I had to reference the play somewhere), but for now we will have to stick with the virtual ones.