Starbreeze Studios level designer Filip Coulianos shares a method for analyzing the pacing of games, and applies it to two superhero titles -- X-Men Origins: Wolverine and Batman: Arkham Asylum -- to see how differently-paced games can create very different results in players.
[Starbreeze Studios level designer Filip Coulianos shares a method for analyzing the pacing of games, and applies it to two superhero titles -- X-Men Origins: Wolverine and Batman: Arkham Asylum -- to see how differently-paced games can create very different results in players.]
We have always asked ourselves what great stories are made of; as a consequence, many refined methods for analyzing and creating good stories in traditional media have been developed. As the video game medium is only a toddler, no reliable toolsets exist yet. However, the question remains: what makes great games?
I asked myself this very question a few years back, as I wanted to know what really made Half-Life 2 such a great game from a pacing and gameplay perspective. I started trying out different ways to analyze and to measure the gameplay -- but what started out as only a series of simple tests turned out to be something much more interesting.
This article begins by explaining the method. Further on, I compare data from two games, how they are paced differently, and what resulting consequences there are. Finally, I will show you how you can use this method to lay out a framework in the early stages of creating your own games.
The basic idea behind this method is to explore gameplay progression by breaking down the game into its distinctively different gameplay elements. Once this is done, time the player as she is playing through the game, and finally assemble the data into a chart.
Looking at this chart, we can then see what types of gameplay are most present in the game, where the player got stuck, if any section of the game is too repetitive, and so on. So let's dive right into it and have a look at Half-Life 2: Episode 1 as a case study for this method.
Half-Life 2: Episode 1 is a first person shooter; it's the first episode in a series to serve as a sequel for Half-Life 2. The player takes on the role as Gordon Freeman and is accompanied by Alyx Vance to fight the alien race known as the Combine.
Let's start out with thinking about what the player actually does in Half-Life. Except for shooting and killing enemies, the player solves puzzles using her gravity gun, drives some vehicles, and finally listens to character dialogue, both narrative and instructional.
The combat can be divided into two camps; first we have low-key combat, where the player is basically moving through corridors, occasionally stumbling upon enemies. Let's call this "roaming". Then we have the more heavily scripted areas that Valve calls "arenas". An arena is usually an enclosed area where the player has to fight off a large amount of enemies in order to proceed. An arena combat sequence is usually a lot more challenging and faster-paced than a sequence of roaming gameplay. A boss fight is a typical arena battle.
Below is a boiled down version of the five gameplay types I defined previously:
• Puzzles: Non-combat sections where the player has to solve a logical puzzle to proceed.
• Dialogue: Non-combat sections where either pieces of the story is being revealed, or the player gets new weapons.
• Arena: Enclosed and heavily scripted areas in which the player faces multiple enemies and/or a big boss and must kill them all in order to proceed.
• Roaming: Areas in which the player simply travels through with enemies scattered around to keep the player somewhat on the edge.
• Vehicle Ride: Areas in which the player drives a vehicle.
With these definitions in place, it's time to play through the game. For each new game play element, take a note and set a timestamp. Let's go through the first 10 minutes of the chapter "Direct Intervention", where the player's mission is to prevent the reactor core of the citadel from exploding, and describe what happens.
0:00 – 1:00 The player fights off a few guards guarding the Reactor control center. A typical corridor fight with just a few enemies to entertain the player should be considered roaming by our definitions. (Roaming)
1:00 – 2:00 The player and Alyx get to the console, and she talks about the mission ahead as well as activates the lift that allows the player to proceed. As Alyx only talks in this section, this should be considered cinematic. (Cinematic)
3:00 – 5:00 The player has to use the gravity gun to shoot power orbs into sockets, activating bridges to progress. As this section is strictly puzzle solving without any combat, it is defined as a puzzle. (Puzzle)
5:00 – 10:00 The player fights off occasional Combine troops while making her way to one of the stabilizers that is required to prevent the reactor from overheating, and activates it by the press of a button. Further on, the player has to fight off some more Combine troops, progress through a corridor and avoid energy balls flying towards her at great speed, and then fight off some more enemies. This section presents different types of challenges, but all of them are low-key and not puzzle-like. Therefore this section is considered to be roaming. (Roaming)
Let's put these notes into a simple chart and see what we have. Each cell in the chart represents one minute of playtime, the color represents what type of gameplay is present during that period of time. The chart is supposed to be read from left to right:
While the data we just collected doesn't tell us very much, it helps us understand the basic principles of the method. In the next section I will talk about how you can use this method to compare two games' gameplay variation, and how you can spot problematic areas within a game using the data collected.
I once got the chance to present my work to a few people at a major publisher. One of them, being a producer, immediately asked if I could look at the data and distinguish a bad game from a good game.
This is a really tricky question, as it is very difficult to look at such elusive data and draw conclusions without the risk of seeing differences where there are none. One should also keep in mind that different games appeal to completely different target audiences, making it difficult to determine exactly what a good game really is.
With this in mind, let's try this out and assume that reviews of games are a good indication of quality. Let's take a look at, Batman: Arkham Asylum scored 91 at metacritic.com, so let's compare it to X-Men Origins: Wolverine, which scored 75, and see if we can see if we can find any obvious differences in pacing and gameplay variation that might have contributed to the different scores.
X-Men Origins: Wolverine is a video game based on the movie with the same name. It's a third person action adventure game where the player takes the role of Wolverine. The gameplay is mostly centered on melee fighting against lots of enemies where the player can perform different combos to eradicate them more efficiently.
The level design in the game is strictly linear and occasionally grows into larger arenas where the player gets more space and variation in terrain to fight in.
X-Men Origins: Wolverine has the following gameplay elements:
• Combat: Combat sections where the player meets more than four enemies and often must kill them to proceed.
• Cinematic: Ordinary cutscene with no player interaction.
• Roaming: Areas in which the player simply travels through with enemies scattered around to keep her somewhat engaged. I defined this as a section of the game where the player progresses without meeting more than four enemies at once.
• Puzzle: Non-combat sections where the player has to solve a logic puzzle to proceed. These areas are usually about powering different stations using moveable batteries that the player had to find somewhere in the level and then bring to the right location.
• Boss Fight: I define a boss fight in Wolverine as a section where the player is fighting one or a few very tough enemies.
• Special Gameplay: At some places in the game there are special gameplay events that did not fit in any category. Most of these special gameplay sections were interactive cutscenes (quick time events) where the player's ability to interact was restricted to only pushing specific buttons at given times in order to continue the cutscene.
Here's how the chart looks:
Batman: Arkham Asylum is a third person action adventure game where the player assumes control over Batman. It takes place on an island, in and around the buildings of Arkham Asylum. In addition to the standard controls, such as running, climbing, and jumping, Batman can also use his cape to glide from heights and use his grappling hook to get to vantage points or hide.
A more in-depth analysis of Batman: Arkham Asylum is available here.
Batman: Arkham Asylum has the following gameplay elements:
• Puzzles: The puzzle areas are areas in which the player has to use Batman's goggles, to investigate crime scenes, or find trails or clues. Puzzles could also be areas in which the player had to be "clever" in order to progress without using violence.
• Roaming: These are areas in which the player simply moves through indoor or outdoor environments, exploring the asylum or island. They usually include lots of dialogue between Batman and Oracle, or any of the game's antagonists, but still allow the player to move freely and have full camera control. These areas often include sporadic combat with fewer than four enemies involved.
• Combat: These are areas in which the player has to fight more than four thugs at a time.
• Gargoyle Room: The gargoyle rooms, or as developer Rocksteady calls them, "predator areas", are places in which the player has to sneak by, or kill, a large number of thugs without being noticed. This is accomplished by using Batman's grappling hook to swing between gargoyle statues situated close to the ceiling.
• Cinematic: The game plays a cinematic sequence without any player interaction.
• Boss Fight: Boss fights are areas in which the player is fighting enemies inside arenas which the player cannot leave until she has defeated all enemies or the boss. Half of these boss fights also include specially-designed enemies such as Bane or Ivy.
• Gadget: In these instances, the player is given a new gadget to play with that could either be used in combat or to help the player get to new places he hadn't been before.
Here's how the chart looks:
Comparing the data from the two games, we can draw quite a few interesting conclusions. The first and most obvious one is that Wolverine had much more combat with more than four enemies. We can also see that the average combat sequence in Wolverine is a lot longer than Batman. In Wolverine, the fight sequences could be up to 10 minutes long, while in Batman, the longest was five minutes.
Looking at the variation, we can see that in the chapter "Snow Landscape" in Wolverine, the game only switches between combat and roaming back and forth, while Batman always keeps a good variation. Boss fights in Batman are also a lot more evenly spread out through the whole game, giving more interesting variation and more frequent "wow moments" compared to Wolverine, which seems to squeeze almost all the boss fights toward the end of the game.
Even though Batman and Wolverine appeal to slightly different audiences, we can still use this method to compare them. Just by a quick glance, we can draw interesting conclusions and see patterns that suggest that Wolverine is more repetitive -- which we actually can confirm by reading reviews, as they often use the word "repetitive" when describing Wolverine.
Instead of analyzing others' games, you could use this method the other way around -- by creating a chart first and then building your levels using the chart as a framework.
You can then let play testers play through your work while timing them, and then listen to feedback on how they experienced the levels -- and compare that to how they progressed through the game.
In a personal project I called "Project 25", where the goal was to create a single player experience as true to Half-Life 2 gameplay as possible, I used this method to first analyze Half-Life 2 and then create a chart to serve as a framework for my layout of the levels.
It greatly helped me when drawing the first floor plan, as I had a pacing chart to follow; it was also useful during play testing. I could see exactly how the testers progressed through the levels and then use that data to create the average player progression, and compare that with my target completion time.
By timing the players and watching how they behaved when playing, I also made some unexpected discoveries that helped me to further improve the gameplay.
One of them was during the early stages of Project 25, when it became obvious that the final battle was way too long. For some testers it surpassed 12 minutes and many showed signs of fatigue and frustration as they died after such a long stretch of intense arena combat, only to play it through all over again. Luckily I timed this, and solved the problem by having two attack waves to give the players a bit of a breather in between the intense fighting.
If you would like to read more about Project 25, you can read an article about it on Gamasutra sister site GameCareerGuide.
If you decide to undertake this analysis, I strongly advise you to play through the game and cut away the parts where you got stuck or died to create the progression from the view of the "ideal player". This data will of course be somewhat skewed when you use yourself as test subject. However, the rise of "let's play" videos on YouTube solves this problem, as people from all over the world upload video captures of themselves playing through various games, and it is a great source for collecting more accurate data.
As I discuss this method amongst my colleagues, some tend to be very reluctant to embrace it -- while others react very positively to the ideas.
Those positive about the method have quickly found applications for it in their own work. One area where the method got picked up quickly was in the pitching process during dialogue with publishers. With the help of these pacing charts, my colleagues gained an efficient way to communicate and to determine what type of pacing the publishers were looking for.
On the other hand, those being reluctant wrongly see this as an attempt to measure "fun". I don't believe we will ever be able to measure how fun a game is by using only one method, but to be a good storyteller, you really need to know how stories work -- and the same goes for games.
I'm certain that studying games using many methods will greatly expand our knowledge and understanding of what makes games fun. I'm sure that we one day will be able to look back to this time, congratulating ourselves for how well we did -- and living in an era where we, as game, developers have since matured.
Read more about:
FeaturesYou May Also Like
