Analysis of Halo: Combat Evolved using Game Design Patterns

In this analysis I have picked Halo: Combat Evolved to pieces; picked a few of them that seemed interesting, and tried to make Game Design Patterns (2003) of them using a method developed by Staffan Björk, Sus Lundgren and Jussi Holopainen to see if Game Design Patterns is a useful tool for analyzing games. I also try to hypothetically remove the patterns from the game to see how that affects it. Then I draw the conclusion that Game Design Patterns are good for making very detailed analysis's, and that removing a pattern doesn't necessarily break the game, subpatterns can mostly be removed with ease while removing fundamental patterns can not.

In this report I will analyze the single player part of Bungie's game Halo: Combat Evolved (2001) using the Game Design Patterns (2003) method developed by Staffan Björk, Sus Lundgren and Jussi Holopainen. The game and the Game Design Patterns method will be presented and then I will perform a component breakdown of the game and pick a number of potential patterns from it. The patterns will be described as defined in Game Design Patterns and then hypothetically removed from the game to see what that results in.

Developer: Bungie Studios (www.bungie.com)
Publisher: Microsoft Game Studios (www.microsoft.com/games)
Genre: First person shooter, a game in which you look through the eyes of the character you play and aim with your weapon that way.
System: Xbox, PC, Mac

"Halo is a sci-fi shooter that takes place on a mysterious alien ring-world. Packed with combat, Halo will have you battling on foot, in vehicles, inside and outdoors with Alien and Human weaponry. Your objective: to uncover Halo's horrible secrets and destroy mankind's sworn enemy, the Covenant."

(www.xbox.com)

"Huge weapon variety: Vanquish your enemies with a vast array of Human or Covenant weaponry ranging from the stealthy (semi-automatic pistols, Alien Needler guns) to the fierce (rocket launchers and assault rifles).

Vehicle and foot-based action: Tackle missions anyway you choose-be it storming an enemy base or taking the wheel or gunnery position of a variety of powerful vehicles. Vehicles range from stolen Covenant flyers & hovercraft to Human buggies, tanks and more.

Indoor and outdoor combat: Fight seamlessly in Halo's ultra-realistic indoor and outdoor environments as you hunt the Covenant in dozens of single player missions and multiplayer battles.

Intense multiplayer shoot-outs: Form a team, choose a role, and fight cooperatively with your friends, battle it out Deathmatch style via intense split screen combat or fight co-op with a friend through the single player missions.

Incredible mission variety: Fight the Covenant in dozens of missions as you uncover the dark secrets of Halo. Among your many objectives - attack enemy outposts, raid underground labs for advanced technology, rescue fallen comrades, steal alien vehicles and weaponry and snipe enemy forces.

Reality-bending special effects: Halo features the most advanced graphic system on the most advanced gaming platform in the world. Gunfire rips off the screen, explosions light up a living room, and environments blur the line between your couch and fantasy.

Rich sci-fi experience: Halo transports gamers into a science fiction universe fresh out of a Hollywood movie. With a detailed twisting story-line, complex characters and cunning enemies Halo will fulfill every sci-fi enthusiasts dream."

(www.xbox.com)

In the analysis Halo's primary game mode will be picked apart in components to find potential patterns. These patterns will then be described using the Game Design Pattern method and hypothetically removed from the game.

Game developers and researchers have been lacking a common language for game terms.

"Looking at the work conducted both within academia and industry, one can conclude that there is a need for a language to be able to talk about game both while designing games and while analyzing game play."

(Björk 2003, 2. Game Design Patterns)

Game Design Patterns has been developed in the hope of creating a game language that works across the whole spectrum of game people.
The people behind the project, Staffan Björk, Sus Lundgren and Jussi Holopainen (www.gamedesignpatterns.org), are currently underway with creating a database of identified Game Design Patterns to be used while designing, analyzing and comparing games. One way they used to construct patterns was by analyzing existing games, concepts and design methods in other fields.

You use five iterative steps to harvest a pattern: recognize, analyze, describe, test and evaluate.

"The recognition phase creates a quick pattern candidate collection around a certain idea or interaction area. The next step is that the collection is analyzed by describing how the pattern is used in example games and then trying to remove the pattern from the games and explaining how it would change the game play. The pattern is then described using the developed pattern template. The description is tested by creating a simple prototype game utilizing the pattern and finally the pattern is evaluated using usefulness and sufficiency of the description as criteria."

(Björk 2003, 4. Game Design Patterns)

These are not necessarily executed in this order, but can be used dynamically and recursively.
Also, the research group behind this interviewed a number of game designers to cover all kinds of game media.

The patterns cannot only be used to solve problems as they sometimes add to several other characteristics in the game, preventing different patterns from being applied. Also, solving the problems only removes unwanted effects, it doesn't add new effects. It is the intention that games should be possible to be designed and built using these patterns.

Name: A short, specific and idiomatic name whose main purpose is to be mnemonic, easy to remember, after reading the description.

Description: Contains information of how the pattern affects the game, in which game it was identified and examples of games where it can be found.

Consequences: Using a pattern to solve something might cause other problems or prevent other patterns from being applied. This section explains what drawbacks and benefits using this pattern as a solution might cause, and what alternatives there are.

Using the Pattern: Because a pattern can be applied in all kinds of situations and having a wide range of effects depending on the context, you list the most common design decisions the pattern will result in here. You also often list specific game elements from existing games.

Relations: Here relationships between patterns are defined. There are superior patterns that are on a more abstract level, subpatterns that that can be used to apply this pattern and conflicting patterns that are hard or impossible to implement if the current pattern is applied.

Game Design Patterns should not be used as solutions to single problems, rather like a pen, a tool capable of doing several things in several ways.
You could for example use patterns for idea generation, choosing a number of random patterns and develop an idea out of that. Or if there is a concept already, it can be further developed using patterns to flesh it out, and then go deeper with subpatterns. They can also be used in pre-production, as patterns will almost automatically motivate certain design decisions, and if the people you present the game to are familiar with patterns from previous projects it will be to your advantage. If the game has identified patterns, a good thing is that you can identify competing games with similar patterns, and also references in the patterns might point to patents that affect that pattern. Patterns contain information that can help you solve your problems by changing your design. They can also be used as a game analysis tool, to categorize games and to explore new mediums and platforms for games.

The component breakdown (Appendix 1) was created with knowledge gathered by many hours of playing the game and being active in an online community. Being active in a community inspired me to read more articles, discuss the game and its elements, explore the game world and pick the game apart, trying to get a deeper understanding of the design. A component is a definable part of the game that affects how the interaction is performed, like heads up display, enemy AI and hitpoints.

As the collected Game Design Patterns from the Game Design Pattern Project (www.gamedesignpatterns.org) have not been made public yet (2003-03-07), relations to other patterns are not included in this analysis. The patterns names might not be optimized for all genres, but instead are designed to make the analysis easier to understand.
Most of them are selected because they make up vital or often overlooked parts of the game play experience. They are picked out of the component breakdown (Appendix 1), you can see the chosen one underlined and bold. If one component is in more than one place, it is only the first one that is marked.

This pattern is a form of auto-aim. Auto-aim helps when trying to aim at targets; it moves your crosshair towards potential targets if you aim near enough. Sticky-aim is not as intrusive as that, it makes your crosshair move slower and slightly following the target when you come across it, making it easier to adjust your aiming to pinpoint the target.

Name: Sticky-aim

Description: A form of aiming aid, not as intrusive as auto-aim though. It sticks to targets rather than aiming for you. Ordinary auto-aim can be found in Half-Life (www.half-life.com).

Consequences: The game will be easier to handle, which makes it good for a wider audience. Even so, the feature is so subtle the player might not have noticed how it works until much later in the game. It will most likely prevent over-aiming, that is the player aims for something but goes too far, switches direction and going too far again, and keeping on doing that.

Using the Pattern: As the player has aim assistance enabled, the enemies' health might need to be adjusted to balance the difficulty. Also a friend or foe crosshair would help suppressing the aim guidance, as the crosshair would change at the same time as the aim assistance kicks in, stealing the attention.

If this pattern were removed: It would be harder to aim and get successful hits when firing. The game would seem harder to pick up for new players, and be more directed towards hardcore players as it will be harder to master, but still playable. The enemy balance would also need adjustments as the amount of successful hits would be lower.
When Halo was ported to from the Xbox to the PC and the input hardware changed from a gamepad to mouse and keyboard causing a boost in accuracy; this was compensated by removing this pattern, and actually simplifying the balance process.

This pattern makes a huge difference in the players' experience of battle. With a hypothetically infinite source of hitpoints you can simply take more risks when taking on your enemies.

Name: Recharging shields

Description: When hurt this is what gets decreased instead of your health. When you are safe again the shield recharges to full power, and you are ready to go back into action. Though, if your shields get completely depleted the damage will reduce your health instead, which does not regenerate.
A variant of this is regenerating hitpoints, which can be found in Diablo (www.blizzard.com/diablo), though here the whole health regenerates, making it different from the health + shield combo in Halo.

Consequences: The player will not be scared of losing his precious health points, risking more and considering more wild tactics, resulting in a more exciting game play. It also means that less health packs needs to be placed in the game world.

Using the Pattern: The health management will be completely different. The placing of health packs in the game world will change from before using this pattern. They can be placed in or after intense areas and more spread out. If there is a character development system that gives the player more life, you need to consider the shield's usefulness and function.

If this pattern were removed: The whole Halo experience would change. The hunt for health packs would take up more of your attention. You would need to be more careful in every fight because even if you lose just a little health it will automatically make you weaker in the next battle. With a rechargeable shield, you always have a guaranteed amount of health prior to any enemy encounter.

In Halo you can only carry two handheld weapons (without exploiting glitches), so you have to decide what weapons you want to wield. This makes for interesting choices for the player as different weapons are good at different tasks.

Name: Limited arsenal

Description: You cannot carry all weapons available at once but have to decide what weapons you want to use. This can also be found in the Delta Force series (www.novalogic.com).

Consequences: This adds to the strategy and tactical elements of the game, but takes much more balancing and careful weapon design to make it interesting. You can't have one weapon that is superior to the rest as that would always be the player's obvious choice.

Using the Pattern: The range of weapons and their usability have to be planned carefully if using this pattern. If one weapon is weaker, it will never be used if stronger weapons are available. So to not destroy the use of this pattern, you need to limit the range of weapons to interesting choices.

If this pattern were removed: The player would be able to pick up all weapons he finds, removing the tactical choice of what weapons to carry. The need to balance all weapons to make them all interesting is not as important, and can be overlooked. Now the player would most likely look for the most powerful weapon, a static choice, instead of the tactically most useful weapon, a dynamical choice. The game is still playable, but would have pretty different characteristics.

In Halo you don't control the vehicles directly, but you control the camera, and the vehicle aligns to the camera. If the vehicle is facing the wrong direction (towards the camera) it just turns around when throttling. This adds simplicity to the vehicle controls. Just look in the direction you want and you will probably end up there, if you don't hit anything on the way. The steering and slide controlling will be done by the game, so the player can concentrate on the area he travels through instead of keeping the vehicle facing the right way.

Name: Look-steering

Description: You are in control of a vehicle (or any kind of unit) in a 3rd person view. When you steer you move the camera and look in the direction you like, and the vehicle steers so it will go in that direction, adjusting itself to the camera. In Halo this applies to both land based vehicles and airborne crafts.
It can also be found in several iterations of the Quake mod Quake Rally (www.quakerally.com) and the Half-Life mod Half-Life Rally (www.hlrally.net).

Consequences: As the user controls the camera there will not be any problems with bad angles. It does though reduce the realism and the immersion of the game, as you are not really controlling the vehicle, just the camera.

Using the Pattern: The camera should have been programmed to not clip through walls and keep your view unobstructed, this will still be used after applying this pattern. The only thing that doesn't need to be done is calculating the angle of the camera as that is what the player controls. Code to control the vehicle has to be implemented instead.

If this pattern were removed: Another way of controlling the vehicles would need to be used, either in 1st person or 3rd person view. Presumably the player controls the vehicle directly, like he would control a vehicle in real life, making it harder but more realistic. The vehicle controlling code will not be necessary, but if you still drive in 3rd person code to control the camera would be needed instead. Without this pattern the game would be easier to grasp when first playing, as it then would work as it does in the majority of existing racing games and remind of steering in the real world. But when the player is used to the look-steering, it will work in his favor, it is easier to keep a direction, to spread your attention to the area you're traveling through instead of just driving. The player can look in any direction he wants without stepping out of the vehicle. This can be enabled without this pattern if driving in first person or adding an additional control to the 3rd person driving.

This is a very fundamental pattern. It's basically the world you play in. In Halo, a level is all world elements you see and interact with while playing the primary game mode. This includes the world geometry itself, structures, enemies, game triggers etc.

Name: Levels

Description: A level is the world you interact with as a player, the location in which your in game representation exists. It can be anything from a chess board to a labyrinth, a small island to outer space. A level could even be the invisible world in a text base adventure game; you can walk around in the world that does not physically exist, even in the game world. The level is not only the geometry or the buildings but everything in it, like monsters, triggers, skies, sounds etc. All things that makes the world, makes the level. This pattern is so fundamental no references to games are necessary, as it exists in most games ever made, if not all.

Consequences: The game will have a place to execute its primary game mode interaction in, some kind of virtual game universe where it all can take place.
A game can still be interacted with if you count possible menus and dialogs before the primary game mode is initiated, though even that could be considered a level.

Using the Pattern: Depending on the game design, it can be very different to implement levels. Basically you gather all parts of the game and make them work together, building a virtual world, a level. A level still has to be loaded and interpreted by a game engine for the world to be possible to interact with.

If this pattern were removed: If levels are removed from a game, the player would not have a place to interact in while playing the primary game mode. It would literally be nothing. Even a black void could be seen as a level (outer space) so without a level the interaction would just cease to exist. It's like removing the universe from the real world, nothing left, not even void. Removing this pattern will most definitely break the game.

In parts of Halo, there are slopes and cliffs which you fall down and cannot climb up. This prevents the player from going back and waste time in previous areas and decreases the chance of getting lost.

Name: Drop-cliffs

Description: A physical drop in the game world that when you fall down cannot get back up from, making it impossible for the player to go backwards in the level, limiting the exploration to the unvisited parts. This concept can be found in the Half-Life mod Day of Defeat (www.dayofdefeatmod.com). It's different from doors in the way of triggering. For a door to work as a limit it has to get locked, a drop is just static geometry.

Consequences: You limit the area the player can explore, narrowing the risk he would get lost. Make sure the player can't cross the point of no return before he has done everything that has to be done in the current area, or the level might be impossible to finish in that try.

Using the Pattern: It's a simple matter of utilizing the geometry in your level. Create a cliff that cannot be climbed, but jumped/fallen down or a slope that you only can slide down, but not walk up; something with that function.

If this pattern were removed: The player could, if uncertain, wander back into areas he already explored, wasting time and building frustration. Though, if the level is designed so the player has to run back and forth to gather items or quests, this pattern will be useless. It is favorably applied to linear or partially linear levels.

After beating hard enemies or passing an invisible trigger the game saves a checkpoint. If the player further ahead loses all his life and virtually dies, he is respawned at the last checkpoint almost instantaneously.

Name: Progress checkpoint

Description: When triggered the game saves the players progress, not to be confused with the time checkpoints in racing games which adds to the time left before the game ends. A variant can be found in Crash Bandicoot (www.wrathofcortex.com), but in that game you need to hit a box to trigger the checkpoint.

Consequences: When the player triggers the losing condition (often when the in game character dies) he gets respawned where he got the last checkpoint, and not at the beginning of the level, if the player has triggered a checkpoint in the first place. If loading a checkpoint takes a long time, the player's motivation to survive in the game might be to escape the long loading times instead of keeping the player's representation in the game alive.

Using the Pattern: Use checkpoints after and/or before a hard part of the level, after a long distance has been traveled, after a cutscene and maybe in the beginning of the level.

If this pattern were removed: The game would restart the level each time the player lost/died, making it a very though job to finish that level, directing the game towards the hardcore players. The player will be nervous to lose as that would force him to replay everything that he has managed to do so far in that level. Another way of saving the progress would most likely need to be implemented, like save locations where you manually can save your progress or a number of saves you can use at all times. Using manual saving and allowing the player to save at all times would probably degrade the immersion immensely as some players might save after each successful step, just because they can, interrupting the game play.

How is Game Design Patterns useful when analyzing games?
The concept of Game Design Patterns has worked well for analyzing specific parts of the game. An analysis of a whole (full size) game would consume a large amount of time, but the purpose and mechanics of the game components gets thoroughly explored, resulting in a very detailed result. The component gets well dissected because of how you describe a pattern. When working on the different parts of the pattern description, you have to figure out how it works, causing you to get a deeper understanding of the pattern itself.

What happens when Game Design Patterns are removed from the game?
Game Design Patterns define subpatterns and superior patterns only. It seems that more classes might be useful, like fundamental patterns, the top level patterns that can't be removed without breaking the game; like the use of a main character or levels.
Removing one of the subpatterns doesn't necessarily break the game; instead it just changes the game's overall game play. Almost all of the patterns chosen in this analysis were subpatterns, pretty deep into the game's structure, and they could be removed without destroying the game, but it would cause major changes to the game play characteristics. The one superior pattern that was fundamental, Levels, would definitely destroy the game if removed, as it removes the whole game world. So what happens if a pattern is removed is unique for each pattern, but subpatterns are the ones that preferably can be removed or swapped.

In this analysis seven potential patterns from Halo: Combat Evolved are analyzed:

After defining the patterns and trying to hypothetically remove them from the game, I draw the conclusion that Game Design Patterns works very well to analyze games with, if you want a really detailed analysis; and that patterns can be left out if they are subpatterns that won't destroy the game when missing.

Halo: Combat Evolved
Xbox: Developed by Bungie Studios, published by Microsoft, released 14 Nov 2001 (US)
PC: Ported by Gearbox Software, published by Microsoft, released 30 Sep 2003
Download a trial version here:
http://www.microsoft.com/games/halo/downloads.asp (2004-03-14)
Mac: Ported by Westlake Interactive, published by MacSoft, released 12 Dec 2003

Analysis of Halo: Combat Evolved
using Game Design Patterns

Index

1. Abstract

2. Introduction

3. Presentation of the game

4. Method

4.1. The concept of Game Design Patterns

4.2. Layout of a Game Design Pattern

4.3. Using Game Design Patterns

5. Analysis of Halo: Combat Evolved

5.1. Component Breakdown

5.2. Harvested Game Design Patterns

5.2.1. Pattern: Sticky-aim

5.2.2. Pattern: Recharging shields

5.2.3. Pattern: Limited arsenal

5.2.4. Pattern: Look-steering

5.2.5. Pattern: Levels

5.2.6. Pattern: Drop-cliffs

5.2.7. Pattern: Progress checkpoint

5.3. Conclusion and discussion

6. Summary

7. List of references

Appendix 1