Tag: Level Design

Categories
Writings

Scaling geometry difficulty in Level Design

The last few days I’ve been playing a lot of God of War II and thoroughly enjoying every last moment of it. That is, up until now. I’ve just gotten to some of the last levels I presume as the story arc is nearing its end (the Phoenix Champers) and the difficulty have just risen so steeply in the last few levels that the game is becoming more frustrating than fun to play.

Let me explain. In the last few years I’ve steadily gone from being a hard-core gamer to a somewhat ex-core gamer due to high level of time consuming elements of my life (such as university studies, wife and son). And that has some clear effects on my timing and aiming skills. These skills only stay good if honed continuously, and I simply don’t have the time for that.

And in the case of God of War II many of the later sequences of the game requires just these skills. As I’ve become an ex-core gamer I tend to play on the easy setting just so that I have time to complete the game without using too much time on it and still see the parts of the game that everyone is talking about. The problem is just that the geometry in the level design don’t scale. The difficulty of making a jump in a 3D environment is just as hard on extreme difficulty as it is on easy.

And that’s no good.

When games moved into 3D, however, the jumping puzzle became a more difficult task. In addition to requiring the player to control their jumps in an extra dimension, the problem of viewpoint reared its ugly head. Games with fixed cameras sometimes made it quite difficult for the players to see where they were landing, while manual control added another control to juggle. #

I would really like to see that if I choose to play on easy setting that the jumping and timing puzzles gets scaled accordingly, else I’ll end up in the position I’m at with God of War II currently; I’ll just stop playing and all the hard work and godly greatness being purred into the levels to come will forever be lost on me.

Categories
Writings

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

Introduction

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

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

Download

Level Design PatternsDownload
Categories
Writings

No Man is an Island

Looking for the dynamics between the game, the group and the player

“No man is an Iland, intire of it selfe; every man is a peece of the Continent, a part of the maine; if a Clod bee washed away by the Sea, Europe is the lesse, as well as if a Promontorie were, as well as if a Mannor of thy friends or of thine own were; any mans death diminishes me, because I am involved in Mankinde; And therefore never send to know for whom the bell tolls; It tolls for thee.” – John Donne (1572 – 1631)

Preface

This report was written in fall of 2005 as part for a project cluster in “Advanced Computer Game Analysis” at the IT-University of Copenhagen. The idea of this cluster was to look at games in an analytical and methodological perspective, and by doing so understand the elements and functions behind the game. During this report we will investigate how and why group structures within multiplayer games emerge.

As this is a new field for all of us we have consulted people who are currently working in this field. We would like to thank Miguel Sicart and Jonas Heide Smith, PhD students at the IT-University, for going beyond the call of duty and sharing thoughts and ideas on the subject.

Introduction

This was not how they planed it. This was going to be a walk-over. The dragons of The Blasted Lands were known throughout the entire realm of Azeroth, as being easy prey for seasoned adventurers like themselves. But something had gone wrong. Terribly wrong. Seven of the ten man strong group that had set out to bring down the dragons, were no longer among the living. Their lifeless corpses lay scattered on the hillside which had proven their final doom. One of them was still on fire, but the proud warrior that once occupied that body, had long since seized his panicking attempts to put it out. He was now walking the lonely road through the eternal fields of the afterlife. Their slogan of “you will never walk alone” suddenly had a very hollow ring to it. Every man for himself was now the order of the day. The chance of survival was close to none. Everyone was running around screaming. “I’m not even supposed to be here for crying out loud! You just be happy I’m helping you fight this dragon.” “Can’t anyone control that freaking rogue? We have rules, and a chain of command for the love of God. If nobody followed our rules it would just be total anarchy. I make the calls of when to fight and when to run!” Never before had they been in these parts of the barren wastelands. Before leaving the secure town of Ironforge behind, they had allied themselves with some highly skilled veterans to help with bringing the dragon down. Because down it had to go! The legend had it that the dragons of The Blasted Lands held guard over some of the most precious metals in the entire known world. Metals that could be used to forge mighty swords and armor. But all that seemed to matter little now…

The story above is an imaginary scene from the game World of Warcraft. Even though none of this really took place, it is included to illustrate some of the mechanics in the game. The game mechanics combined with the human factors, are some of the issues which we will try to cover in this report.

All the members of this project group have been playing games for many years and take great interest in especially multiplayer games and how relations between people emerge in such games. Anyone who has spent a few hours in a multiplayer game has probably experienced how people act and interact in different ways. We have all experienced the good and bad things about such games. How people interact with each other and the game has been our starting point. What we intend to clarify is whether or not the player is influenced by the context of a group and if there is a mutual exchange between players. In the following sections we will clarify the scope of this project and how we will approach the subject.

Problem area

Games in the genre of “Massively Multiplayer Online Games” (MMOGs) have during the last couple of years exploded in terms of player population and popularity. Why, could one ask? What do these games provide that make people, month after month, pay fairly big amounts of money to play? Is it the chance to experience grand adventures, epic battles or the opportunity to rise as a hero in a world of chaos? Or is it something completely non-game related, like chatting, forming new friendships etc.?

In the beginning it is fairly reasonable to expect that the main focus of a player in any MMOG is to explore and learn how to act within the game world, but as time passes and you get more and more familiar with your surroundings other objectives arise; at some point you know everything there is to know about the world and you are faced with a dilemma – what to do now? Either you quit the game completely or you find new objectives within the game – e.g. acquiring the best item, being the best player at a specific game mechanic or building strong social relations. These objectives then serve as a means to keep playing, even though the game itself does not instruct you to. One could say that you stop playing the designers game and instead start to play within the world.

So why is this interesting? Well, people tend to approach games in a very rational fashion; how do I optimize my chance of winning. This is due to how games are structured – a cost-benefit principle where every move should be weighed according to the overall goal of the game. This is certainly the case if we were talking about single player games, where every move only affects you. So, would it be a sensible assumption to make when we are talking multiplayer games, MMOGs in particular? During our initial studies, we saw a tendency that people seemed to deviate from this assumption. Why is that? It seems there is something else affecting the player, when he enters a social context. Why would anyone emphasise a non-game related issues, like social interaction, in a situation where winning is everything? Of course there are anomalies among players – not everyone is playing to win a game, but it is, as we see it, a minority in comparison with most players (Smith, forthcoming).

During this report we will try to clarify the key factors when people participating in certain group structures – e.g. do players always choose, as one could expect, the rational choice in a particular context? In exploring this phenomenon we are using the MMOG World of Warcraft as a case study.

This game is currently the biggest MMOG on the marked, with more than 5 million subscribing users (Blizzard.com). It’s truly a game which has managed to appeal to players in a broader perspective. People of every age, play this game. It has become a leading title within this genre and is probably shaping the next generation of MMOGs.

Problem statement

Based upon the problem area we will try to answer the following question:

  • When playing World of Warcraft, what are the key factors of the relationship between the player and the group?

To understand why players make certain choices regarding group structures, we will initially have to clarify how the game facilitates group structures and what types of players it is dealing with. We will therefore use the following questions as means to answer the before-mentioned statement.

  • How are groups structured within World of Warcraft?
  • Which type of players takes part in these structures?

Problem limitation

As part of our problem limitation we have chosen only to focus on World of Warcraft. This is done due to two factors. First of all because of the extreme focus which World of Warcraft is experiencing at this time, which has, as mentioned in the first section, managed to capture the essence for many types of players and thereby their way of playing. Secondly we wanted a problem area of manageable size.

In our analysis we will be using different theories to verify or explain certain findings. We will not at any time try to verify or substantiate the theories, but merely use them as a foundation from which we will try to explain player behaviour in a social context.

The report

In the following section there will be a brief introduction to the report and how this is structured. In order to answer or problem statement we have decide to divide the report into two sections, where each part respectively will handle “the group” and “the player”. Each chapter will be organised in the following way:

  • Theory – the theory will be used to analyse the mechanics of the game and will be introduced at the beginning of each chapter.
  • The analysis – the theory combined with the empirical material should give us some answers to our initial (sub-) problem statement.
  • Conclusion – there will be a summary of all our findings regarding the analysis.

The consequence of this structure is that we do not have a purely theoretical chapter, where all the theory is introduced at once, but rather it is split up into smaller parts and explained when needed.

Download

No_Man_Is_An_IslandDownload