Looking for the Principles of Unified Level Design
Written as part of my master thesis in Information Science in April 2006 at the IT-University of Copenhagen.
“Few things are harder to put up with than a good example” – Mark Twain
My aim with this paper is to take the idea of formal design tools and show how to apply them to the process of creating levels for multiplayer first-person shooters (FPS). The focus of this paper to be on the architectural properties of the levels and not the storyline or other added elements that differ from game to game. Single player games are often very linearly structured because they need to convey a tightly knitted storyline to the player. The levels themselves are constructed in such a way that they emphasize the storyline and underline the mood and setting that the story is conveying. Multiplayer games must to a much higher degree leave the playing field open, so to speak. To use the words of one of the leading forces behind Epic Games’ Unreal Tournament series, Cliff Bleszinski:
“A Level Designer who is building for a Multiplayer oriented title is much like a playground architect” (2000a).
The storyteller is no longer present to the same extent as in a single player game. Multiplayer games are often fast-paced and center on reaching specific predetermined team-based objectives. So when looking for examples that underline the design patterns presented herein the following games are the only ones taken into consideration:
- Unreal Tournament 2004 (by Epic Games, 2004)
- Day of Defeat: Source (by Valve, 2005)
- Battlefield 1942 (by DICE, 2002)
To use a famous quote from pioneering game developer Sid Meier; the aim is to look for “interesting choices” in level design. I wanted to draw the attention towards design patterns for multiplayer level design, since most of the literature available on multiplayer levels design seems to focus solely on collision points (Bleszinski 2000a) (Saltzman, 2000) (Güttler & Johansson, 2005) and I strongly believe that this is just a (small) part of a very larger picture of designing multiplayer levels. Secondly, of all the other works on design patterns for game design (see section 2.3.1 on page 7) none is focused on level design.
Level design is essentially is a craft and therefore you need proven formal tools. By using design patterns as a design tool when creating levels multiplayer games you ensure that the players can seamlessly navigate through your game world. At the same time, it will greatly reduce the scope of the design process as you apply tried and tested solutions to your current problem domain.
There is no need for reinventing the wheel every time you plan and design a new level. The question that I will try to answer in this paper is; how can formalized design patterns be used for creating interesting choices in level design?
What are design patterns?
Design patterns are formal tools used for solving known problems. Said in another way; it is a design toolbox. In many fields, ranging from architecture, over software development to creative fields such as literature and movies, people are using some form of formal design tools to help create their work. Some call them design patterns others call them “tools-of-the-trade”, but they are essentially the same; formal tools that describe problems (or problematic areas) and proven ways to solve them. If we take movies as example, try to count how many movies you have seen lately that followed a storyline similar to this one: the main character of the story sets out on a quest to undo the wrongdoings that have fallen upon him/her. During this quest, the main character faces many perils and is close to giving up near the ending, but somehow he/she prevails in the end. I would dare say that the large majority of the movies present on IMDb.com’s Top 250 list of the greatest movies ever made follow a storyline very similar to the above. Looking at how movies like Indiana Jones, the Star Wars movies, and The Matrix trilogy is using the Hero’s Journey way of storytelling and then comparing it to the way David Lynch told the story of Lost Highway it is easy to spot the difference. Filmmakers such David Lynch, who is truly artists in their field, makes movies that are not easily understandable. Ask anyone who has seen Lost Highway (1997) or Mulholland Drive (2001) of what the movie is about and you will properly end up with as many answers as people you ask. The popular movies all revolve around the same story outline. They do it because it works. It is easy to understand for the viewers, because of the familiarity of the storyline. You can argue that this type of storyline is a design pattern. Are they works of art? No, by no means! But they are all using a collection of very effective tools for creating entertainment that is easily recognizable for everyone.
The question then is; do these tools hinder the creative workflow and merely created assembly line produced entertainment that all look the same? When doing level design for multiplayer FPS, the aim is not that the player must play against the environment and solve its architectural puzzles embedded within. They must be able to instantly recognize the navigational patterns and move fluidly through the level. The architecture must be created in such a way that the players are working with the environment and it is not becoming an obstacle that the player also has to overcome. More Indiana Jones and less David Lynch, so to speak.
The idea of using formal design tools as an approach to solving issues in different fields is not new, not even in the domain of computer game design. Christopher Alexander et al. described design patterns as a formal design tool for use in the field of architecture in the book A Pattern Language (1977). In it Alexander writes the sentence that should prove to be the foundation for the entire use of design patterns in software development in the decades to come:
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. (Alexander, 1977, p. x)
Software developers Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides based their neo-classical book on software development Design Patterns: Elements of Reusable Object-Oriented Software (1995) on Alexander’s description of a design pattern. They took the notion of having abstract patterns describing solutions that could be used to solve some very concrete problems in software development. It is properly within traditional software development that you can find the biggest influence of design patterns.
Design patterns in games
Design patterns in games have been a topic of discussion for some time now. Doug Church proposed what he saw a way of overcoming some of the very general problems involved with the process of game development and game design in his article: “Formal Abstract Design Tools” (1999). Harvey Smith has also proposed some formal design tools. During two separate presentations at the Game Developers Conference he outlined the thoughts behind his “Systemic Level design” (2002) and “Orthogonal Unit Differentiation (O.U.D.)” (2003). Common for these two presentations is that he is talking about design patterns, but he never get around to actually calling them that.
Someone who did indeed call the formal design tools for design patterns were Staffan Björk and Jussi Holopainen. They presented in their book Patterns in Game Design from 2004 a way of using patterns in the process of designing games. Their book took the call from Bernd Kreimeier’s article “The Case for Game Design Patterns” (2002). Björk and Holopainen have with their book made the definitive documentation of how and when to apply design patterns to the process of game design. Björk and Holopainen have continued to work with the aim of making design patterns for games an intricate part of the game design process. Both with “The Game Design Patterns Project” website4 and with their newer article “Design Patterns and Games” (2006). Noah Falstein and Bob Bates revived their “The 400 Project” project during the Game Developers Conference in March 2006. Their project is a very ambitious take on rules that makes a good game. The project was originally started by Hal Barwood and Noah Falstein in 2001, and even though they rigidly state on the project website No, although there are similarities. Alexander’s work grew out of architecture, and is, in Hal’s words “A welcomed allied analysis”. But it lacks the imperative – the 400 rules are stated in terms of instructions to follow, rather than observations of existing patterns. It also lacks the trumping information that is important to understanding how these rules interact. The similarities between their project and game design patterns cannot be overlooked. As of writing this they have listed 112 rules of the 400 intended.
A very brief history of multiplayer first-person-shooters
In 1992 id Software released Wolfenstein 3D and effectively changed action games forever. The game measured a whopping 700 Kb, a huge amount at the time, but was nonetheless downloaded a quarter million times (Saltzman, 2000, p. 111) in the year it was released6. Since then firstperson-shooters (FPS), as the genre became known as, have become one of the most popular genres.
Wolfenstein 3D was technically not the first action game with a first-person perspective7, but it was without doubt the game that launched the genre. The second generation FPSs were building upon the foundations id Software made with their first games Wolfenstien 3D (1992) and especially the two DOOM games (1993 & 1994).
Quake (1996) and Star Wars: Dark Forces (1995) showed signs of more advance gameplay, but it was not until GoldenEye 007 (1997) and Half-Life (1998) that the genre really showed its full potential. The FPSs was clearly maturing as a genre and the desire to innovate the gameplay elements, spawned memorable games such as Medal of Honor (1999) and Halo (2001). This was also the period when the genre finally moved online with various offerings for multiplayer play with Quake 3 (1999) and Unreal Tournament (1999) leading the masses.
One game really opened the eyes for the potential of multiplayer FPS was Counter-Strike. It did not start out as a stand-alone game, but as a mod for Half-Life. But the influence this mod had (and still very much have) on multiplayer FPSs is not to be overlooked. When it was first released in June 1999, it quickly became the most popular game to play over the internet. You can in fact talk about the eras before and after Counter-Strike. It is still to this day the undisputed king of online FPSs. According to Wikipedia.org Counter-Strike accounted for 70 percent of entire the online FPS audience in 2004. Valve, the developer of Half-Life, also saw the commercial potential of Counter-Strike and bought the rights for the mod and later turned the once free mod in to a commercial product in November 2000. Valve released a much anticipated updated version of the game called Counter-Strike: Source in 2004. This version utilizes the much more powerful game engine Source that also powers Valve’s other products such as Half-Life 2 (2004) and Day of Defeat: Source (2005).
Other multiplayer FPSs worth mentioning are the Tribes series (covering three games from 1998 to 2004), Battlefield series (covering three games 2002 to 2005 and numerous expansion of each game), and lastly the free Wolfenstein: Enemy Territory (2003) is worth mentioning for it’s addition of experience points to the class system.
The sole reason that Counter-Strike is not included as an example is this paper is the mere fact that it is the most analyzed FPS game around. Adding one more analysis to the pile would not accompany much. Instead I have opted to look at the before mentioned games.
Level design patterns (PDF – 2,1 MB)