Playing the game – Managing Computer Game Development

From the Introduction 

Every time a computer games is released it’s accompanied by endless reports and stories about how disorganized and chaotic the production had been. It’s a wonder to me that an industry that a yearly growth of about 15% still is plagued with bad planning. 

Even though the industry make a ton of money each year, it’s a known fact that many project end up with red numbers in the end. This is partly due to the very big economical investments that are normal in the industry. It’s common that large productions have a production budget of around 3-4 million dollars. That’s just for production. 

You don’t have to be a mathematical genius the figure out that you have to sell a lot of copies to make a return on your investment. The profit is a long way down the road when a single copy only brings in a couple of dollars in real profit.

And many games never sell over 500,000 copies worldwide in their entire lifespan.

To examine if the bad production planning really is the very root of the problem, I analyzed 43 different Postmortem articles from The result of the analysis can be read in appendix A.

The analysis both confirmed and changed my view of the way professional game development is being carried out in the development houses around the world. Even though the analysis shows that some productions did indeed have good planning, and a solid pre-production, the majority of the projects did not. They were trouble with either bad or no planning, or bad project managers. Some even have all of the above. The articles all stated this as one of the main problems. 

One other thing that’s quite remarkable is that almost all of these games went on to receive huge critical and/or gamer acclaim. So it’s not so much a question of finding a qualified workforce. The problem lies more in the planning and management parts of the projects.

Another thing that all the productions share is that none seems willing to learn from former mistakes. The articles used in the analysis have all been printed in the period between the September 1999 and August 2002. So even though the information was there, none of the projects show any wish for change in the development form.

The lack of management, or bad management if you will, wears down all the people involved in the development and does not create the desired production level. More time than necessary is used correcting errors and not with what everyone really wants: to invent, develop and refine unique ideas for games.

Many mention the loose structure and the lack of control as a necessity for creative inspiration to thrive. In this report I will try to argument against this and many more opinions.

I will try to show that you as a game developer can save a huge amount of time in the game development process with a proper and thorough planning coupled together with a type of management that gives all the people involved time and space for creative work.

With the saved time comes saved money. Time is, as we all know, money.


Game development projects are generally badly planned and badly managed. This results in delayed productions and exceeded budgets. The process with creating computer games is not effective enough and a huge amount of time and human resources are wasted because of this. It seems that the tendency is to “re-invent the wheel” every time around. 



How can the process of creating computer games be more effective without the loss of any creative force? 

This effective adaptation shall be seen through project management, planning, and organizational reflections. 


Audience for This Report 

The target group for this report is everyone working, or planning to start working, in the computer game development industry. That’s a rather broad statement but it’s my opinion that everyone can draw from the hopefully constructive solutions and suggestions written herein. 


Throughout the report I use the term “computer game”, which here is meant as a technological aided game, be that either a console game, PC game, handheld game or what have you.

Secondly, all the people (gamers, programmers, producers, etc.) mention in this report are referred to by using the pronoun “he”. This is because the writer of this report is a “he” and the majority of the people working in with computer games development are male. Why that is, is a longer and much more elaborate discussion that lies beyond the aims of this report.

Some of the books referred to are only available in Danish. The ones I’ve been able to find in English have been listed in the reference list.



Alfred Hitchcock and The Elements of Suspense

On Why Hitchcock Still Can Make You Sit on the Edge of Your Seat.
Written as part of my education in Medialogy in December 2003


From the introduction:

What is Suspense? 

Suspense is today such an incorporated element of movies that it for many seems second hand, but what elements are needed to create a good suspense scene? It is easy to spot a non-working suspense scene, but what are the key elements that make a good scene become a masterpiece?

It is impossible to talk about suspense without mentioning Alfred Hitchcock (1899-1980). He was the master of the technique. Although Hitchcock was not the first to use suspense in movies he had in the “golden era” of his career (from the mid 50s to the late 60s) developed a template for implementing suspense that worked so well that it is still revered as the best examples of the use of suspense.

In Hitchcock’s own words:

“There is a clear difference between surprise and suspense […]. We are sitting here and having an innocent conversation. Let us assume that there is a bomb under this table between us. […] suddenly there is a loud boom and the bomb goes off. The audience is surprised, but before this surprise they have only seen a very ordinary scene without any significance. Let us instead look at suspense scene. The bomb is under the table and the audience is aware of this because they have seen the anarchist plant it there. They also know that the bomb will go off at one o’clock, and up on the wall is a clock showing that the time is now quarter to one […]. In the first scene we have given the audience 15 seconds of surprise […] but in the last scene we have given them fifteen minutes of suspense.”.

The whole scene rests on this difference in knowledge and the audience’s fear on behalf of the unknowing characters.

In short: Suspense is a dramaturgy technique that plays of the difference in knowledge between the audience and the characters on the screen. It often revolves around subjects like; will the hero reach the right place and save the heroine before it is too late? Will the bomb expert defuse the bomb before it goes of? Will the detective see the sinister figure waiting in the alley?


Download the PDF here (2,5 MB): Elements of suspense

Den korteste vej til algoritmner og spil


Written as part of my master thesis in Information Science together with Jens Frederiksen in December 2004 at the IT-University of Copenhagen.



Denne rapport og den dertilhørende Java kildekode, er kulminationen på vores 16 uger programmeringsprojekt på IT – Universitetet i efteråret 2004.

Vi har undersøgt hvilke algoritmer og datastrukturer der skal anvendes for at lave en repræsentation af Hex spillet som Piet Hein og John Nash opfandt uafhængigt af hinanden for snart 50 år siden.

Vi har kigget på to forskellige korteste vej algoritmer; brede-først-søgning og Dijktras algoritme. For at finde den korteste vej er graf strukturen et naturligt valg, til at undersøge problematikken. Der er benyttet disjunkte mængder datastrukturen for at nemt at kunne undersøge om en spiller har skabt en forbindelse med spillerens to sider.

Hex spillet er blevet brugt som case for at udforske de algoritmer og datastrukturer, for at få spillet til at fungere. Vi har implementeret to versionen af spillet i Java, hvor den ene version er den som Hein og Nash opfandt og den anden er en version hvor alle felterne på spillebrættet har en vægt som har betydning for den korteste vej i fra den vindende spillerens to sider.



Vores mål med projektet var at kigge nærmere på spillet Hex / Polygon Game som et klassisk graf problem inden for algoritmer og datastrukturer. Vi præsenterer vores implementering af disse ved hjælp af et simpelt userinterface udarbejdet i Java, hvor de underlæggende algoritmer og datastrukturer liggende bagved også programmet i Java.

Vi valgte programmeringssproget Java, da vi tidligere har erfaringer med dette og da et af projektets formål var at udforske objektorienteret programmering virkede dette som et oplagt valg.

Det overordnende mål i vores projekt er at opnå en grundlæggende forståelse af grafer, træer og datastrukturer, samt hvordan de benyttes og udarbejdes på en hensigtsmæssig måde i forbindelse med konstruktion af spil. Implementeringen af disse i Java er sekundært, og udarbejdelsen af et userinterfase tertiært.

Projektet er derfor todelt, i henholdsvis en teoretisk og en praktisk del. Den teoretiske del skal give os en indsigt i algoritmernes og datastrukturers overordnede opbygning. Den praktiske del vil bestå i en implementering af de teoretiske elementer i Java.

For både at få den teoretiske indlæring om datastrukturer og algoritmer og for at sikre en mere praktisk tilgang til emnet har vi anvendt spillet Hex som en case. Derigennem har vi direkte kunne afprøve og af- eller bekræfte noget af den læste teori.


Hvordan sikre man at spillet Hex altid har styr på om der er en vinder og dernæst for at finde den korteste vej fra den vindende spillers to sider?


Hex spillet udspringer af matematikkens verden, vi vil dog ikke dække det matematiske aspekt i spillets udformning eller forskellige strategier. Vi bruger blot Hex spillet til at udforske datastrukturer og algoritmer.

Vi beskriver ikke alle benyttede datastrukturer i detaljer, f.eks. prioritetskøer. Ligeledes har vi ikke brugt de matematiske analysemodeller for datastrukturer og algoritmer, som f.eks. Stor O notation.


Det er vores mål at give en beskrivelse af de teorier og emner, som vi gennemgår i rapporten på et abstraktionsniveau, hvor essensen er bibeholdt, men hvor de matematiske beviser for de forskellige begreber træder i baggrunden. Det er for at holde fast i vores mål om at skrive denne rapporten til vores valgte målgruppe; studerende som os, som ikke har haft undervisning i algoritmer eller datastrukturer og derfor ikke kan forventes at have nogen forkundskaber eller viden omkring emnet.


Download hele rapporten her i PDF (7,7 MB): Den korteste vej til algoritmer og spil

Level design patterns

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:

  1. Unreal Tournament 2004 (by Epic Games, 2004)
  2. Day of Defeat: Source (by Valve, 2005)
  3. 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.

Problem statement

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’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.

Prior work

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 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)

Please do not walk on the grass

On how role-playing in “Grand Theft Auto: San Andreas” can be difficult

Before you starting spamming the comment function with enlightening comments such as “GTA is not a RPG you idiot!”, let me explain what I mean with role-playing in a game like Grand Theft Auto (GTA);

It is correct that GTA is not marketed as a RPG, but in it you play the role of Carl Johnson ((or just plain CJ among friends)) in his quest for correcting all the wrongdoings that has come upon him and his family. This, in itself, does not really constitute GTA as a RPG, since then all games would more or less be RPGs, but the sheer size of the game world and the freedom to roam around in this, creates a narrative vacuum that the player has to fill out by him/herself, very similar to “normal” RPGs. Furthermore you, as a player, are free to dress up Carl in more or less any way you find suitable and “pimp his ride” in various ways. On top of that you have the element of the fitness and sex appeal of CJ. These elements are clearly added into the game in order for the players to identify more with CJ, e.g. that they share the same goals and behave in a way you would prefer etc.

The overall story arc of the game is very well constructed but in some cases the narrative that the player is creating (though his/her (inter)actions) clashes very hard with the narrative that Rockstar Games has put into the game.

When I first loaded the game on my PS2, I was expecting the grandeur of the two previous games in the series, GTA III and GTA: Vice City, and Rockstar delivered. The game is bigger, prettier, sounds better and driving around in the game is just a fun as it was in the others. It has a great and better written story than the previous game. But this is also where GTA: SA goes down an unfamiliar path for the series.

In GTA III the protagonist was an unnamed guy with a gritty past, the plot was familiar in sense of “Goodfellas” kind of way. And again with GTA: VC the setting was instantly recognizable, everything from the Miami Vice inspired intro, the Don Johnson and “that other Guy“, the pink flamingos and everything in between.

These two games worked perfectly, because the story was loose and the setting geared towards only one kind of storyline, so there was little difference in the story that Rockstar had put into the game and the story that the player developed while playing.

I would argue that the focus on a better and stronger story proved to be San Andreas’ Achilles’ heel. As I said, the story is better, no need to argue about that, but it is also tighter and more confined, therefore limiting in the way the players act out their “inner criminal”.

An example of this is in the first part of the game. Here you take on the “Doberman” mission, a mission that involves taking over some gang territory from competing gangs in Los Santos (the first of three cities in the state of San Andreas). The game explain very clearly how the game mechanics works in connection with this and before long you and your recruited gang members are out cruising in pimped-up lowriders looking for drive-by action ((note the deliberate use of “you” and “your”)). Within minutes full-blown gang war is happening in downtown Los Santos.

The gang war gameplay element of SA is a nice little (mini) game in itself, but wear out after some time. And this is where the real trouble kicks in.

After I’d have taken over more or less the entire city of Los Santos and in the process developed my own story of CJ as being this “don’t-you-look-at-me-or-I?ll-shoot-you” kind of guy, that doesn’t take any crap from anyone (yes, really living out my inner criminal here) I decided to take on a mission I was more or less certain that would progress the story line of the game. And the mission did indeed progress the story, but in a whole other direction than the one I wanted.

The mission starts with a cutscene where a crocket cop named Tenpenny (brilliantly voice-acted by Samuel L. Jackson) back-stabs CJ. Since it was a cut-scene there was nothing I could do, even though my view of CJ had now become this before mentioned hard-boiled gangster that would blow the head of anyone trying to cheat him, even cops.

So there I was, thrown out of town, with no guns, no homies to protect me, no nothing. Just seconds ago I was the king of town, I was the guy with homies on every street corner looking out for me, I was the one everyone feared and few had live to tell the tale of. CJ and I were one, but no more. The bond between me, as the player of the game, and Carl Johnson was lost the minute he sat foot in the hillbilly town of Angle Pine… never to be found again.

I kept on playing the game, but CJ was no longer an important part of the game for me, now I was just looking for quick ways to complete the missions, earn money to buy property and scouting for nice cars to drive around.

After this “incident” I played the game in the way Rockstar properly wanted me to play it. The problem was that they had open up this huge game world for me and told me that I could do anything I wanted in. But in really they wanted me to act in a very specific way in it, and not walk on the pretty grass even though I could.