Procedural Content Generation for Games -Game Maps

Author: Devin Ridgway

Supervisor: Ke Chen

April 2015

Abstract

Video games are complex pieces of software that take a significant amount oftime to create. As the complexity and depth of games continue to increase, alarger percentage of development is focused on content creation. ProceduralContent Generation lends itself nicely to streamlining that process.

This project explores the realm of content generation through the devel-opment of map generation algorithms and a game to allow for interactionwith those maps. The project itself is divided into three sections: an interac-tive game, map generators, and a process of ensuring that only quality mapsare selected.

Based on the verification system’s results, roughly 60% of maps areplayable, and roughly 45% of maps are of acceptable quality.

This report begins with some important background on games and con-tent generation in general. It then describes the design and development ofthe project. Finally, the projects results are detailed and summarized.

1

Acknowledgements

I would like to thank everyone who helped me through this project, especiallytowards the end.

A special thank you goes out to Ke Chen for supervising this project andproviding excellent feedback and guidance through its development.

2

Contents

1 Introduction 71.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Background 92.1 Video Games . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Procedural Content Generation . . . . . . . . . . . . . . . . . 10

2.2.1 Offline vs Online . . . . . . . . . . . . . . . . . . . . . 102.2.2 Constructive vs Generate and Test . . . . . . . . . . . 112.2.3 Optional vs Required . . . . . . . . . . . . . . . . . . . 122.2.4 Uses of PCG . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Content Verification . . . . . . . . . . . . . . . . . . . . . . . 14

3 Algorithmic Methods 153.1 Map Generation Algorithms . . . . . . . . . . . . . . . . . . . 15

3.1.1 Perlin Noise . . . . . . . . . . . . . . . . . . . . . . . . 153.1.2 Binary Space Partitioning . . . . . . . . . . . . . . . . 17

3.2 Verification Algorithms . . . . . . . . . . . . . . . . . . . . . . 203.2.1 Support Vector Machine . . . . . . . . . . . . . . . . . 20

4 Project Design 224.1 Tools Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . 234.3 The Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3.1 Animation System . . . . . . . . . . . . . . . . . . . . 244.4 Map Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4.1 Configuration File . . . . . . . . . . . . . . . . . . . . 264.5 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5.1 Dijkstra’s Algorithm . . . . . . . . . . . . . . . . . . . 274.5.2 Bots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5.3 Map Classification . . . . . . . . . . . . . . . . . . . . 31

3

Contents Contents

5 Evaluation and Testing 325.1 Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Manual Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 Generation Results . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Conclusion 36

Appendix A Map Classification Examples 38

4

List of Code Samples

1 Perlin Noise Map Creation . . . . . . . . . . . . . . . . . . . . 162 Perlin Noise Value Calculation . . . . . . . . . . . . . . . . . . 173 BSP Room Placement . . . . . . . . . . . . . . . . . . . . . . 194 BSP Room Splitting . . . . . . . . . . . . . . . . . . . . . . . 205 Pseudocode for the Map Crawler Bot . . . . . . . . . . . . . . 29

5

List of Figures

2.1 Planet Generation for Plannetary Annihilation [25] . . . . . . 112.2 Generated Weapons in Borderlands: The Pre-Sequel [4] . . . . 122.3 Tiny Keep’s Dungeon Generator [20] . . . . . . . . . . . . . . 13

3.1 256x256 Perlin Noise with Max Octave of 16 . . . . . . . . . . 173.2 128x128 Typical Acceptable Perlin Noise Map . . . . . . . . . 183.3 BSP Room Connection Example . . . . . . . . . . . . . . . . . 193.4 128x128 Typical Acceptable BSP Map . . . . . . . . . . . . . 203.5 Example Support Vector Separators, by ZackWeinberg [30, 31] 21

4.1 System Overview Diagram . . . . . . . . . . . . . . . . . . . . 234.2 Animation Framework Class Diagram . . . . . . . . . . . . . . 25

5.1 Screenshot of a Bot Playing a Map . . . . . . . . . . . . . . . 33

A.1 Map Classified as Not Playable . . . . . . . . . . . . . . . . . 38A.2 Map Classified as Not Playable . . . . . . . . . . . . . . . . . 39A.3 Map Classified as Not Acceptable . . . . . . . . . . . . . . . . 39A.4 Map Classified as Not Acceptable . . . . . . . . . . . . . . . . 40A.5 Map Classified as Acceptable . . . . . . . . . . . . . . . . . . 40A.6 Map Classified as Acceptable . . . . . . . . . . . . . . . . . . 41

6

Chapter 1

Introduction

1.1 Motivation

Video games have been ever increasing in their capabilities, and in turngamers have become used to having an increasing amount of content in theirgames. For example, The Elder Scrolls (TES) series, by Bethesda Softworks,has evolved over the past two decades from the graphically simple and smallscale RPG of TES: Arena to the massive open world of TES V: Skyrim[18]. Evolutions like this lead to developers spending more and more timeon just content creation. Various methods have been developed to ease thisburden, from employing massive teams of artists for developing this contentto utilizing the game’s community who continually produce and upload theirown content like in Valve’s Team Fortress 2 [26]. However, neither solutionsolves the time consuming nature of content creation.

This project explores a method of generating content automatically with-out the use of costly developer time. Through an algorithmic means, gamescan be made to have improbably large amounts of content that wouldn’t bepossible to create with typical team sizes (100-1000) during a typical devel-opment cycle (1-3 years). The content generated here is quality controlledthrough a verification system that flags the most acceptable of the generatedmaps.

1.2 Project Goals

This paper discusses the automatic content creation developed in this projectand the multiple map generation algorithms and verification methods thatresulted. There are a few key deliverables that needed to result for thisproject to be deemed a success:

7

Chapter 1. Introduction 1.2. Project Goals

• A 2D game to play the generated maps

• Perlin Noise based map generator

• Binary Space Partitioning map generator

• Verification process to validate the generated maps

The focus of this project was on the generation of maps for a 2D dungeoncrawler, but also required the development of a game that would allow forthe playing of those generated maps. The game had a few requirements: itmust have a player analogue, a visual representation of the map, and a way ofshowing the player’s traversal over the map. The two map generators utilizedby the game had similarly simple requirements in that the map output needonly to have 4 tile types: walkable, non-walkable, start point, and end point.Finally, the map verification system needed to be able to take the map asinput and come up with either an acceptability classification, or a single valueto sort various maps based on quality.

8

Chapter 2

Background

This project was developed in three distinct sections:

• A game to enable interaction with maps

• Some procedural map generators

• A method of verifying the quality of the generated maps

This chapter presents background information on each of these topicsthat, while not directly relating to the project, is important for understandingits context.

2.1 Video Games

Video games have existed for decades as specialized pieces of software, art,and entertainment [28]. They are a complicated series of interconnectedparts, like many software projects, and have various performance require-ments on top of that complexity. However, they are composed of more thanjust a collection of software. The game’s software brings together variouspieces of data content, such as character or environment models, to form thegame as a whole.

Games come in a wide range of different styles, from differences in game-play to variations art style, but despite those differences there’s one signifi-cant commonality between all games: they are meant to be fun in some way.Many factors determine whether a game is fun or not, like gameplay me-chanics, but most are heavily dependant on the player’s personal preferenceand whther or not it meets their expectations or requirements. Since gamemaps represent one of the many pieces of content that can affect the degreeto which a game is considered fun, I chose to focus this project on ways togenerate fun game maps.

9

Chapter 2. Background 2.2. Procedural Content Generation

2.2 Procedural Content Generation

Procedural Content Generation (PCG), as defined by Togelius et al., is “cre-ating game content automatically, through algorithmic means” [13]. Withthis in mind, we need some understanding of what the game content is. Typ-ically, this is limited to any aspect of the game that can “affect gameplayother than non-player character (NPC) behavior and the game engine it-self” [13]. For example, game content could be trees and other foliage or aterrain height map, but it cannot be things like path finding or graphicalworld rendering as those are more process oriented than data oriented andare represented in their own unique fields.

The various PCG algorithms can be divided by 3 distinct classificationmetrics:

• Offline vs Online: is determined by where and when the algorithmis run

• Constructive vs Generate and Test: is differentiated by how thealgorithm runs

• Optional vs Required: is classified by what kind of content thealgorithm produces [13, 24]

The following sections present a more detailed view of each of these clas-sification metrics.

2.2.1 Offline vs Online

Offline PCG techniques are ones that are run outside the main game’s execu-tion. This could be generating content inside a level-editor, or on a server tobe downloaded at a later point [13, 24]. Typically, offline PCG is done in thismanner because of the time and/or resources required to run the algorithm.

Planetary Annihilation, by Uber Entertainment, is one such game thatutilizes Offline PCG. It’s a strategy game played across procedurally gen-erated planets. These planets are each generated inside a world editor, asshown in Figure 2.1, that allows you to modify inputs into the algorithm tochange the look and feel of the world [25]. This is considered an Offline ap-proach because the generation of the planet doesn’t actually happen duringnormal gameplay.

Online PCG, however, tends to have the opposite characteristics: thealgorithm is run during normal gameplay, and the time/resource requirementis predictable and low enough to have little impact upon gameplay. The

10

Chapter 2. Background 2.2.2 Constructive vs Generate and Test

Figure 2.1: Planet Generation for Plannetary Annihilation [25]

differences between these two classes of algorithms are based entirely uponthe time taken during and place of the algorithm’s execution [13, 24].

Borderlands: The Pre-Sequel, by Gearbox Software, utilizes Online PCGfor most of the in-game weapons. Being a First Person Shooter style game,Borderlands contains many weapons of various types with multiple possibleabilities from lasers that freeze their target to rocket launchers that explodelike a grenade when you reload them [4], and example of which is shown inFigure 2.2. To allow for a near infinite number of weapons, the majority areprocedurally generated at the time that they are found, hence the Onlinenature of this algorithm.

2.2.2 Constructive vs Generate and Test

The way in which the algorithm generates content is what distinguishes con-structive algorithms from those that follow the generate and test pattern.Constructive algorithms build up the final piece of content via a set of pro-cedures that have a known quality output and run time [13, 24]. Typically,the quality is high enough that the content doesn’t need to be checked, andthe generation time is fast enough that the algorithm can be run duringgameplay, though this isn’t always the case.

Both the generation of weapons in Borderlands and the creation of planetsin Planetary Annihilation follow the constructive algorithm pattern. Both

11

Chapter 2. Background 2.2.3 Optional vs Required

Figure 2.2: Generated Weapons in Borderlands: The Pre-Sequel [4]

generate their content once in a way that ensures that they are of sufficientquality for use within the game [4, 25].

Generate and Test algorithms, as the name implies, generate the contentand then test it for acceptability (the specific tests are based on the desiredcontent parameters). If the content fails the acceptability check, then thealgorithm is run again and the loop continues until a valid piece of contentis generated [13, 24].

2.2.3 Optional vs Required

The type of content produced by a PCG algorithm can be classified basedon its relationship to the game it’s used in. Optional content can be avoided,in some way, during normal gameplay and is not crucial to the player’s ex-perience [13, 24]. Since the content is relatively unimportant, it’s acceptableto have some errors or flaws due to the generation process. With the gunsin Borderlands, the player doesn’t have to take the one that was just gener-ated if they already have a better weapon, so that’s an example of optionalcontent [4].

Required content, on the other hand, is vital to the experience of thegame and necessitates a higher quality standard [13, 24]. Things that theplayer would be unable to avoid cannot suffer from disruptive errors, whichin turn affects the method of PCG. In Planetary Annihilation, the planets

12

Chapter 2. Background 2.2.4 Uses of PCG

that the players play on is entirely unavoidable, as the game mechanic forcesthem to be on that planet [25]. Those planets are Required content.

Since this classification is based on the content alone, distinguishing be-tween that which is optional that which is required is an indirect measure ofthe PCG algorithm.

2.2.4 Uses of PCG

When making a video game, artists have to spend a significant amount oftime, relative to the rest of development, just creating the content that goesinto the final game [13]. From the placement of trees and rocks in a moun-tainous scene to the layout of buildings in a city, creating content manuallytakes a significant amount of time. Getting a computer to take over the cre-ation of even a small amount of content can save a considerable amount oftime, and saving time could mean anything from the addition of even morecontent to a faster release cycle and cheaper games.

An example of a style of PCG similar to what’s used in this project canbe seen in Phigames’ Tiny Keep. This dungeon crawler utilizes PCG for theirdungeon maps (an example of the layout of one of their maps is in Figure2.3). Content other than just the map’s layout, like enemy location, miscel-laneous obstacles, and certain puzzles, are also included in their generation.Similar to the previous examples, this algorithm is: Required as the mapsare unavoidable, Constructive since it’s all generated once before the playeraccesses it, and Offline because the generation is done before the level begins[20].

Figure 2.3: Tiny Keep’s Dungeon Generator [20]

13

Chapter 2. Background 2.3. Content Verification

In each of the examples in this chapter, the PCG is used to increase thevariety of content available in the game without having to take an artist ordeveloper’s time to do so. As such, the range of content can become nearinfinite so long as care is taken to ensure a consistent quality metric.

Another use of PCG, besides simply saving artist’s time, is to develop thegame wholly around the idea of a procedurally generated world. No Man’sSky, by Hello Games, is one example of such a game. Instead of just oneworld, however, they have an entire universe full of countless planets thatcan be explored by the player. The entirety of each planet, from the animalsand fauna to the landscape and oceans, is all procedurally generated [7].

The capabilities and requirements of PCG techniques vary widely de-pending on the context. Fully exploring the topic of PCG is far beyond thedomain of this project, which is why I have limited the requirements to justmap generation.

2.3 Content Verification

Content verification can be done through various means, all of which re-quire some metrics used to form the evaluation. The most obvious processis manual verification, where a person takes the time to examine the gen-erated content. However, this is infeasible in the majority of situations soan algorithm based verification system is preferred. Algorithmic solutions tothis problem vary from simple evaluation functions, which perform a seriesof mathematical operations on the input data to return some value, to morecomplicated machine learning approaches.

More recent work has been done in the area of learning-based PCG, whichtakes machine learning techniques and applies them to the area of contentgeneration [23]. Their technique was to learn from data collected at variouspoints during the game development and run time to modify the generationalgorithms [23]. This project also utilizes machine learning techniques, butinstead of modifying the generation itself, it’s used to label which pieces ofcontent are of higher acceptability.

14

Chapter 3

Algorithmic Methods

This section presents the main algorithms utilized in this project for mapgeneration and verification.

3.1 Map Generation Algorithms

The game maps for this project were made purposefully simple, only contain-ing tile types relevant to the layout rather than content (i.e. passageways androoms rather than items in those rooms). This was done to abstract awayfrom other types of game content that might affect the experience and in-stead focus on the effect of the maps themselves. Because of this, the game’srequirements simplified down to a maze traversal style dungeon crawler, andthe algorithms used to generate the maps were also simplified.

In relation to the PCG algorithm classifications, the generators detailedbelow are all Offline, since they are generated outside of the running of thegame; Generate and Test, as the maps are verified before being allowed to beplayed; and Required, because the maps cannot be avoided during gameplay.

3.1.1 Perlin Noise

The first of the two algorithms was intended to be used for the generation ofcave-like maps. To generate the map, Perlin Noise is first thresholded to geta binary image, which is then smoothed to reduce the edge noise, and finallythe start and end points are randomly placed on walkable tiles. Listing 1illustrates the steps of the algorithm, while the Perlin Noise specifics arecontained in Listing 2.

Perlin Noise is created through the combination of various zoom levels ona region of purely random values [12, 17, 19], (limited to the 0 to 255 range

15

Chapter 3. Algorithmic Methods 3.1.1 Perlin Noise

1 fn generatePerlinMap(width, height) {2 image = generate salt & pepper noise image (values 0-255);3

4 loop over all (x, y) in the image {5 // Set the pixel value either Black or White based

6 // on the threshold of the noise

7 pixelValue = threshold(getPerlinNoiseValue(x, y));8 image.setPixel(x, y, pixelValue);9 }

10

11 image = meanFilter(image); // Smooth the image

12 placeStartPoint(image); // Random Green pixel for the start

13 placeEndPoint(image); // Random Red pixel for the end

14

15 return image;16 }

Listing 1: Perlin Noise Map Creation

for use as an image) or noise map. Each level, or octave, is smaller regionof the noise map (shrinking towards, in this case, the upper left corner)that is scaled up to match the size of the first octave where the x and ycoordinates correspond directly to the values of the noise map [12, 17, 19].The octave itself (i.e. power of two: 1, 2, 4, etc) represents what you dividethe x and y pixel location by to get the value for that octave. For example,a location of (4, 6) in octave 4 will take the noise value at location (1, 1.5).To account for the missing information between integer locations (i.e. whenthe x coordinate is 0.5 and there only exists values for 0 and 1) the algorithmuses bilinear interpolation to return a smoothly transitioning value betweenthe known points (this works in both x and y, hence the bilinear aspect)[12, 17, 19]. The effect of the multiple octaves is a cloudy noise layout, whilethe interpolation gives the noise a smooth transition between the maximumand minimum values, both of which can be seen in Figure 3.1.

The method of generating the Perlin Noise used in this project, however,generates the final image by combining all the octaves for a single pixel inone method call, as shown in Listing 2.

Figure 3.2 is a typical example of a Perlin Noise generated map that isboth Playable and Acceptable, with the green pixel representing the startpoint and the red pixel being the end point. The classification comes fromthe verification system described chapter 4.

16

Chapter 3. Algorithmic Methods 3.1.2 Binary Space Partitioning

1 fn getPerlinNoiseValue(x, y) {2 size = 16; // Determines number of zoom-levels (Octaves)

3 while(size >= 1) { // Loop over the possible octaves

4 // Get the noise value at this location and zoom level

5 // using bilinear interpolation

6 sum += getNoiseValue(x / size, y / size) * size;7 size /= 2.0;8 }9

10 return 8 * sum; // Weight the sum due to getNoiseValue()

11 }

Listing 2: Perlin Noise Value Calculation

Figure 3.1: 256x256 Perlin Noise with Max Octave of 16

3.1.2 Binary Space Partitioning

The second algorithm used in this project was chosen because of its heavilyroom-based appearance. Rather than having large cavernous regions con-nected with variable sized paths, this generator creates maps with variablesized rectangular rooms, each connected to the others via a uniformly sizedseries of corridors.

As the name suggests, Binary Space Partitioning is a process of dividingthe map space into a tree structure based on the split location and direction.There are two basic steps to this algorithm: dividing the map into multi-ple regions that can contain the rooms, and drawing the rooms and their

17

Chapter 3. Algorithmic Methods 3.1.2 Binary Space Partitioning

Figure 3.2: 128x128 Typical Acceptable Perlin Noise Map

connecting paths. Listing 3 outlines the steps for placing a room in a givenregion and the partitioning decision logic, while Listing 4 details the act ofpartitioning, the recursive calls, and the path placement.

Building this tree begins with the entire area. A random split directionis chosen and the area is then divided into two smaller regions such thatit is possible to make a room of at least minimum size in both (i.e. if theminimum room size supplied to the algorithm is 7 pixels high and 10 pixelswide, a split will be made only where both new areas can contain a room ofthat size). The division continues with the new regions until either the splitchance randomly dictates a leaf node, or the new regions become too smallto divide. With the partitioning complete, a room of random size (betweenminimum room size and this region’s size) is placed inside each region.

When the recursive calls to room placement return, a path is drawn ran-domly between the two regions, perpendicular to the split direction, suchthat it only connects the nearest walkable portions of the regions. For exam-ple, if a vertical split was made resulting in rooms A and B, in Figure 3.3, theconnecting path could only be made across the green overlapping portions ofthose two rooms. In this example, blue is the chosen connecting path, red isan invalid place to connect to, and green is the overlapping region where itis acceptable to place a path.

Figure 3.4 is a typical example of a BSP generated map that is bothPlayable and Acceptable, again with the green pixel representing the startpoint and the red pixel being the end point.

18

Chapter 3. Algorithmic Methods 3.1.2 Binary Space Partitioning

1 fn generateBSPMap(Image image, Rect bounds) {2 if bounds area is too small to be split for more rooms {3 size = random(minRoomSize, areaSize - roomGap);4 minLeft = roomGap; // adjusted to guarantee

5 // overlap with other rooms;

6 left = bounds.left + random(from minLeft to

7 bounds.width - width);8 minTop = roomGap; // adjusted to guarantee

9 // overlap with other rooms;

10 top = bounds.left + random(from minTop to

11 bounds.height - height);12 draw room; // randomly placing start/end if needed

13

14 } else {15 if(random() > splitChance)16 choose a random split direction;17 if possible, split();18 }19 return image;20 }

Listing 3: BSP Room Placement

Figure 3.3: BSP Room Connection Example

19

Chapter 3. Algorithmic Methods 3.2. Verification Algorithms

1 fn split(Image image, Rect bounds, Direction dir) {2 rect1 = first rect of the split area;3 generateBSPMap(image, rect1);4

5 rect2 = second rect of the split area;6 generateBSPMap(image, rect2);7

8 draw line-path between the rooms in the newly split areas;9 }

Listing 4: BSP Room Splitting

Figure 3.4: 128x128 Typical Acceptable BSP Map

3.2 Verification Algorithms

The process used in this projected for checking the acceptability of a mapis based on machine learning techniques. By allowing the computer attemptto understand what makes for more acceptable game map it saves havingto create a complex evaluation function and the need to understand whichfeatures provide the best result. To this end, a Support Vector Machine wasutilized in this project, the basic principles of which are outlined below.

3.2.1 Support Vector Machine

Support Vector Machines (SVMs) are a method for classifying data by learn-ing from examples of each class. This is done by iteratively trying to con-

20

Chapter 3. Algorithmic Methods 3.2.1 Support Vector Machine

struct a vector, or line, that separates the data points as best as possible.Consequently, this method only works for linearly separable data (i.e. if thedata overlaps significantly, this method fails to produce acceptable results).The best vector for the data is the vector that has the maximum straightline distance from any data points [9, 10, 11, 30].

Figure 3.5 illustrates various possible support vectors to classify betweentwo classes where each point contains two data fields. Three vectors, H1, H2,and H3, are drawn as potential class separators. H1 simply fails to correctlyseparate the data. H2 does correctly separate the data, but the distancebetween the vector and the nearest data points could be improved. H3 isthe optimal vector as the distance between the vector and the nearest datapoints is maximized, which allows for the largest margin for new data pointsto be classified [11, 30].

Figure 3.5: Example Support Vector Separators, by ZackWeinberg [30, 31]

A SVM is used in this project to learn the difference between acceptableand non acceptable game maps and then classify new examples of such maps,as is explained in more detail in chapter 4.

21

Chapter 4

Project Design

This section outlines the design of the software developed in this project aswell as the reasoning behind those design decisions.

4.1 Tools Used

Many factors affected which tools were used in this project, especially wherethe game was concerned. Using a massive game engine, like Unity3D, wastoo much when all that’s required is a small scale 2D scene renderer, thus theSimple and Fast Multimedia Library (SFML) was the obvious choice. SFMLprovides a cross-platform abstraction of OpenGL, with bindings in multiplelanguages [5].

Now that I had decided on the engine, I needed to choose the language bytaking the rest of the project (map generation and the verification system)into account. The obvious first choice, when considering game development,is C++ because it has the history of being used in games and it has thefastest run time. However, C++ is known to be error prone to develop in,and just generally takes longer to write than similar languages like Java [15],which ruled it out as an option. In the end, D was chosen as the language touse given it has comparable run time speed, is faster to develop in becauseof its significantly cleaner syntax, and SFML also has a binding for it calledDSFML [2, 5, 8].

All of these decisions led to a more streamlined development process aswell as the ability to easily develop this project in a truly cross-platformmanner, supporting all three of Linux, OS X, and Windows by the end ofdevelopment.

22

Chapter 4. Project Design 4.2. System Overview

4.2 System Overview

The diagram in Figure 4.1 displays an overview of the final software solu-tion. The software system as a whole was built in three distinct sectionsand connected together via a central processing method. The map genera-tors are detailed in chapter 3, and the remaining two subsystems, Game andVerification, are detailed in the remainder of this chapter.

Figure 4.1: System Overview Diagram

4.3 The Game

The simplest method for determining whether or not a game map is accept-able is by manually playing it in some game. To enable this, a game had tobe specifically made for this project to support the generated maps.

The requirements for this game are: to have representations of a playerand the map to be played, and to provide a way to traverse the map. Apulsating purple circle in the center of the game window was used to actas the player’s character. The game map is represented by a square grid ofsquare tiles each textured based on their type:

• Walkable - Light Grey

• NonWalkable - Dark Grey

• Start - Green

• End - Red

Map traversal is shown by the player’s onscreen location relative to themap’s location as well as smooth translations of the map’s location.

Map testing was initially done manually, to help determine what makesfor a good map, but later on the game itself was used more as a debuggingtool and demonstration tool than a testing mechanism.

23

Chapter 4. Project Design 4.3.1 Animation System

4.3.1 Animation System

The purpose of this animation system was to enable the smooth translationsof the map as the player moved across it and to provide the player analogue’sstandby animation. It does this by providing a mechanism to smoothlytransition between two values over time.

While the decision to build the game in SFML was beneficial it came withone important downside: a lack of game specific constructs. SFML is builtup from 4 basic components: a system module, a graphics module, an audiomodule, and a networking module, but the relevant aspects, the system andgraphics modules, do nothing more than abstract away from the OS andOpenGL specific window management and 2D rendering [5], allowing thegame developer to ignore those details. However, to improve the quality ofthe game I had to add a system to animate various in-game properties, likethe position of map.

The animation framework I implemented was loosely based upon theframework built into the Android API, as of version 11, which provides aprogress callback that can be used to update the entity that required ani-mating [6]. The class diagram in Figure 4.2 shows the design of the system Ibuilt. I included a progress update mechanism supplied by the Animatable

interface. When an Animatation instance is sent a time difference since thelast update, it follows the following steps to calculate the next value:

1. Calculates the current progress of the animation (a floating point value0 to 1)

2. Sends the progress through the current Interpolator

3. Calls updateProgress() with the interpolated value, which then up-dates the entity’s value1

Each part of this framework plays a specific role in the game itself. Forexample, the Animation subclasses of RotationAnimation, TranslationAn-imation, and ScaleAnimation utilize the progress update to set the entity’srotation, translation, and scale, respectively, based upon the input start andend values, like the translation movements of the map and the pulsating scaleanimation of the player analogue. AnimationSet instances are used to runmultiple animations simultaneously, or in sequence, based upon the specifiedmode, which allowed for a transparency animation to play after the scaleanimation on the player analogue. To prevent errors during the input of

1The updateProgress() method is implemented by subclasses of Animation whichuse the interpolated progress value to update their specific value types (i.e. Translatio-nAnimation updates a Sprite’s position of type Vector2f).

24

Chapter 4. Project Design 4.4. Map Generation

Figure 4.2: Animation Framework Class Diagram

movement commands, the UpdateListener is used to send a callback sayingthat the map’s translation animation has finished, which in turn re-enablesthe controls to make another move.

As a post-project task, this animation framework was improved upon,made more generic (i.e. less reliant on SFML and any other dependenciesoutside the D standard library), and then published to GitHub under thename AnimateD [16].

4.4 Map Generation

This section outlines a handful of details regarding map generation that aren’trelevant to the algorithms themselves, but are relevant to the project.

25

Chapter 4. Project Design 4.4.1 Configuration File

Before the maps were loaded into the game for playing, they were pre-viewed in the GUI to help determine if the algorithm was producing the ex-pected output. Rather than have miscellaneous numbers in raw text that’scumbersome to interpret, the generated maps were instead saved as PNGimages. The visualization of the map layout allowed for a significantly moreefficient manual verification of algorithm performance, but was used more asa debugging tool rather than a method for classifying the generated maps,as the classification method is described later in this chapter.

4.4.1 Configuration File

Parts of these algorithms have been made configurable so that the softwarecan be rerun with different inputs to achieve different results. These optionscan be changed by users of the software by editing a configuration file, thecontents of which are formatted in JSON. The options available are as follows:

• Map Size: The pixel length of one side of the square map (any integer,default: 128)

• Perlin Noise:

– Use 3D Noise: Whether or not to generate 3D noise versus thedefault 2D noise (true/false, default: false)

– Threshold Value: The value to use to threshold the noise downto binary (integers 0-255, default: 120)

– Smooth Edges: Whether or not to run the smoothing functionto remove noise from the edges (true/false, default: true)

• BSP:

– Minimum Room Height: The shortest the room’s height isallowed to be (any integer smaller than the map size, default: 7)

– Minimum Room Width: The shortest the room’s width isallowed to be (any integer smaller than the map size, default: 7)

– Minimum Area Ratio: How small the split area is allowed tobe, relative to the minimum room size, before it’s too small tohold a room (floating point 0.0-10.0, default: 1.0)

– Room Gap: The spacing between the room and the edge of thesplit area (any integer smaller than the map size, default: 2)

Defaults were set for each of these items based on trial and error andwhat I personally thought gave an acceptable range of output.

26

Chapter 4. Project Design 4.5. Verification

4.5 Verification

More important than the generation of the maps is the system built to ensurethey are of sufficient quality. There are three classes of map quality used torank the maps generated here:

• Not Playable: it is not possible to get from the map’s start point tothe end point.

• Playable but Not Acceptable: it is possible to get from the startto the end, but the map probably isn’t fun.

• Acceptable: it is possible to get from the start to the end, and themap is probably fun.

The first class is the easiest to distinguish: run through the map to findout if there exists any path between the start point and the end point, and ifnot it falls under Not Playable. Classifying between the next two classes,determining the map’s acceptability, is a far more challenging and subtletask.

Making this distinction by hand would typically involve playing throughthe map. A personal decision as to the map’s acceptability would then bemade based off of the length of the map, its complexity, and other less obviousmeasures like the player’s gaming experience, etc. This personal preferenceissue complicates the act of map classification.

To provide a defined value for this classification, a machine learning tech-nique, Support Vector Machine (SVM), was used to interpret the map’s fea-tures, as detailed in chapter 3 [10]. The specific features used, and how theyare gathered, are detailed below.

4.5.1 Dijkstra’s Algorithm

The first feature extraction technique used is a slight modification of Dijk-stra’s path finding algorithm. Like the original, this algorithm is run fromthe start point to find a path, or rather the length of the shortest path, to allreachable nodes in the map. After that, however, the path lengths are usedto collect the required map features:

• Distance to the End Point

• Distance to the Furthest Point

• Number of Walkable Tiles

• Number of Non-Walkable Tiles

• Percentage of Reachable Walkable Tiles

27

Chapter 4. Project Design 4.5.2 Bots

4.5.2 Bots

The second technique is significantly more involved and calculates a moreindirect representation of the game map. The intention is to find out, withoutmanually playing the map, what a human would be likely to do when playingthe game. To solve this problem, several iterations of bots were built toattempt to simulate this human behavior.

Research

Since the game used in this project is basically a maze system, the firsttechnique I explored was maze solving algorithms. However, one thing thatbecame quickly apparent with these maze solvers is that they were optimizedfor standard mazes and would be problematic to modify for the general casemaps generated in this project [29]. For example, the algorithms had as-sumptions about the path width being uniform and, in the case of the simpleWall Follower algorithm, knowledge that the exit was along a wall [29]. Bothof those assumptions, however, are not valid for these maps, as they aren’tstandard mazes.

The next idea I tried was to use pre-existing game bots to play throughthe maps. This was also problematic, because the community’s emphasis forgame bots was to use them to play First Person Shooter (FPS) games, ratherthan the dungeon crawler style used in this project [22]. Modifying one ofthese bots was also out of the question given that the goals defined in thesebots were out of line with those designed for this game (i.e. to eliminateall other players vs exploring and finding the exit), so utilizing them wouldeffectively involve writing the bot from scratch anyway.

Development

The first bot test I developed was an omniscient bot, because it was a quickmethod to allow for the integration of a bot into the game. Every time thisfirst bot is polled, it runs the A* search algorithm and returns the move alongthe found path to the exit [27]. The bot maintains an internal state of itslocation relative to the map as well as all the information about the map’slayout, hence the omniscience. As such, the bot already knows where to goand gathers no extra feature information.

This initial bot led to the development of the Demo Mode which runs thegame, without keyboard player controls, and polls the bot for a new moveevery time a new move is required (i.e. once the map’s onAnimationEnd()

callback allows for a new move to be made). When the bot reaches themap’s exit, a new map is generated and the process continues. The process

28

Chapter 4. Project Design 4.5.2 Bots

of making moves with the bot was later used without the GUI to simplycollect the feature data about the map.

Visualizing the bot’s progress like this was an important debugging anddevelopment tool. Not only did it provide an initial mechanism to retrieveinformation from the bot, but it allowed any errors in bot logic to be moreeasily found. Tile coloring based on the bot’s knowledge was also added asa debugging feature with a similar purpose.

After the interaction framework was built, a more functional bot wasrequired. The idea for this was based off of the fact that a person playingthe game would have no knowledge of where the exit is, and thus would haveto search the map to both learn the layout and find the exit. This becamethe driving principle of the bot’s design: to learn the layout of the map asthe bot moves through on its way to the exit. This bot’s logic is describedin the pseduo-code in Listing 5.

1 fn makeMove() {2 if we have seen the last goal {3 // find a new goal

4 dijkstras over all nodes to get distances;5

6 if endNode has been seen {7 foundNode = endNode

8 } else {9 foundNode = closest walkable unseen node;

10 }11 calculate path to foundNode;12 }13 make move along current path;14

15 ray trace to nearby nodes, update their seen status;16 }

Listing 5: Pseudocode for the Map Crawler Bot

For use with bot’s learning process it’s given all of the map’s information,like the A* bot, but instead it flags the tiles as it sees them. From the bot’sperspective, there are three tile types: unseen, seen, and edge. The first twoare self explanatory, while the edge tiles are tiles that have been seen thatare also next to (vertically or horizontally, but not diagonally) tiles that havenot been seen.

Edge tiles represent the boundary of the bot’s knowledge space, so tokeep with the exploration the bot needs to expand that knowledge space.

29

Chapter 4. Project Design 4.5.2 Bots

This is done by having the bot move towards the nearest unseen tile that’snext to an edge tile and updating tile visibility after every move. When thatselected tile has been seen, the bot selects a knew one until it has seen theexit.

Tile visibility is determined by tracing a ray cast between every tile withinthe bot’s visibility area and its current location. If there’s a wall in the wayof the ray, then that tile is not visible. For the purposes of this project, thebot’s visibility radius was set to be a 5 by 5 square grid around the player,for simplicity’s sake, rather than a circle.

The process of tile selection and moving towards that tile are similar.Dijkstra’s is run over the map to first make the decision on what that closesttile is (ties between closest tiles are settled randomly), and then that sameinformation is used to calculate a path to that node. The path is saved andthen followed for each consecutive move request until a new path to a newtile needs to be calculated.

Features Gathered by the Bot

The information gathered from the bot is as follows:

• Number of tiles seen

• Number of moves made

• Number of goals chosen

The number of seen tiles represents roughly what percentage of the mapcan be expected to be observed by a player moving through it. If the countis too low, the map is mostly wasted and therefore not particularly good.

The next two values go hand in hand. Moves made is the actual numberof calls to the bot for making a new move, while goals chosen are the numberof times a new path had to be calculated. The closer the two values are, themore straightforward the map is, while the greater the difference means thereare more instances of backtracking. A balance needs to be made betweenthese two extremes to form an acceptable map. For example, if the botmade 1000 moves and chose 900 goals, we can assume that the map wasmostly straight and boring, but if the bot made 10,000 moves and chose2,000 goals, it’s safe to say that the map has a lot of back tracking and deadends, neither of which are desirable features for this project. The task ofdeciding the importance of each feature is left to the classification system.

30

Chapter 4. Project Design 4.5.3 Map Classification

4.5.3 Map Classification

To ease the process of classifying generated maps, and generating severalmaps at one time, I developed a command line interface that would generatea number of maps, extract their features via the methods detailed above, andthen run them through a classification system. It’s that classification systemthat is explained here.

The main processing is done through the use of an SVM software builtby T. Joachims [9, 10]. This software supports learning from training datato generate a model file that is then used to classify the testing data [9, 10].Output from testing a single map’s feature data is a floating point numberthat can be used to either rank the maps or, in the case of this project,be rounded to the nearest integer representation of the class (i.e. -1 is notplayable, 0 is not acceptable, 1 is acceptable).

The output from the feature extraction is, at first, a JSON formatted filecontaining the feature data. Lines for the file name and order are also partof this data (the order is the class that it was classified as), but are onlyrelevant after the classification steps. The feature data is then formatted tomatch the following:

<target class> qid:1 <feature number>:<feature value> ...

The target class is unimportant when classifying, as it’s used only duringtraining, so it’s set to 0 for usage here (similarly, qid:1 is an unimportantrequirement of the software). Feature numbers to feature values are setby matching a number to each feature extracted from the map and usingthe corresponding value (i.e. if tiles seen by the bot is feature 1 and thecorresponding value was 4012 then the entry would be: 1:4021). This is donefor all features ensuring consistency between the numbering in the trainingdata and the numbering in the testing data.

The SVM-formatted feature data is then sent through the software whichoutputs the classification values. These values are rounded to the nearestclass which is then saved back in the JSON output.

The software requires data to learn from before it can be used to classifynew maps. This training was done by gathering the feature data for 20 maps,in the format expected by the software, and then I manually went througheach of the generated maps and gave them a class. These classified mapswere used to train the system and then classify another 100 generated maps.I manually checked the system’s classification against how I would classifythe maps, changing the class when necessary, and then added these mapsto the training data and retrained the SVM with the 120 examples. Thisbecame the data set used for the remainder of the classification tasks.

31

Chapter 5

Evaluation and Testing

This chapter describes the methods used for testing the software as well asvarious project statistics.

5.1 Unit Tests

The first testing method used in this project was Unit Testing. Unit testswere used early in development because there was only a small section ofthe project that could be tested in such a manner, namely the AnimationSystem. Other parts of the project, like the game and the map generation,could only be efficiently tested by hand since their output isn’t necessarilypredictable in a repeatable manner, as is expected when unit testing.

The Animation System has very predictable output: the time spent dur-ing the animation should be directly represented in the progress of the ani-mation. This made unit testing the obvious choice for verifying that it works.Also, this system turned into a full open source project at the end of the de-velopment [16], which provided an added incentive for decent unit tests1. Inthe end, the tests provided 100% code coverage for this part of the project.

5.2 Manual Testing

The majority of the project was not testable through automated means,though. The game itself requires human interpretation to be certain thatwhat’s being displayed is correct, and the map generators are similarly visual.

1This system was made available publicly because I felt there wasn’t a suitable ani-mation framework for the D programming language and that what I had built could beuseful to the community.

32

Chapter 5. Evaluation and Testing 5.2. Manual Testing

Testing of the game was done with a temporary hard-coded map in thesame format the generated maps would be loaded into. This map enabledthe creation of the game and the integration of the animations, map object,and player object.

The map generators, as mentioned earlier, saved their output as imagesrather than a custom data format. This visualization of the generator’s resulthelped find and solve several bugs, like one with the BSP maps where thepaths were drawn incorrectly. Further on in the project, saving the mapsas images provided more context for the verification details where it waspossible to see how those details related to the generated map.

The most useful addition to the project, in terms of debugging, was thedecision to visualize the bot’s internal state onto the map, as shown in Figure5.1. The red tiles indicate the path that the bot is trying to follow to getto the next unseen tile. Yellow tinted tiles are ones that are on the edge ofthe bot’s knowledge about the map (i.e. tiles that have been seen but thatare next to tiles that have not been seen). The lighter grey tiles are walkabletiles that have been seen (lightest grey) or not seen (slightly darker grey).The darkest grey tiles are non-walkable tiles.

Figure 5.1: Screenshot of a Bot Playing a Map

While this coloring presented an excellent insight into the bot’s innerworkings, it also proved to be a successful demonstration mode. Having

33

Chapter 5. Evaluation and Testing 5.3. Generation Results

the bot continuously run through newly generated maps, while presentinginformation about its internal state, created an informative visual demo.

5.3 Generation Results

The map classification system, as described in chapter 4, required trainingdata that was manually classified. The initial classification accuracy overthe first 100 maps was 90%, with only 20 maps used in the training data.When these 100 data samples were added to the training set, the accuracyjumped to over 95%2. Table 5.1 displays the data gathered from generatingand classifying 1000 maps, and manually classifying them to detect errors inthe classification system.

The worst kind of misclassification is where a map is not playable but getsclassified as playable, or vice versa, because that could lead to a situationwhere a player is given a map that has no solution. Minimizing this erroris a significant priority, and this system demonstrated none of that stylemisclassification during the test runs of the project.

However, almost 40% of generated the maps were unplayable. The goodside of this is that the verification system correctly identified every singleone of these maps, but having that many unplayable maps does mean there’sroom for improvement in the algorithms. One possible change to improvethis, at least for Perlin Noise maps, is to use blob detection to find thelargest area in which to place the start and end points, ensuring there’s apath between them.

Perlin Noise Binary Space Partitioning TotalNot Playable 216 174 390

Not Acceptable 75 74 149Acceptable 213 248 461

Misclassified 39 9 48

Table 5.1: Spread of Generated Maps Across 1000 Runs

Table 5.2 is a confusion matrix showing the type of misclassificationsthat occurred in the generation. The least acceptable misclassificaiton thatoccurred for these maps is a false positive (i.e. the map was labeled as Ac-ceptable, when in reality it was not), and as the data shows this representedonly a third of the misclassifications.

2Variation on this figure is due to the inherent randomness in the map generatorswhereby they may create more maps that have qualities leading to a miss classification

34

Chapter 5. Evaluation and Testing 5.3. Generation Results

Perlin NotAcceptable

PerlinAcceptable

BSP NotAcceptable

BSPAcceptable

True 50 199 67 246False 25 14 7 2

Table 5.2: Confusion Matrix for 1000 Generated Maps

Appendix A contains examples of generated maps, the features extractedfrom the maps by the methods explained above, and then their classificationsas reported by the SVM. In each example, A is the image file for the map,and B is the JSON-formatted feature data.

The time spent during map generation is significantly less than that spenton verification. Typically each map takes roughly a second to generate,regardless of which method is used, but the verification can extend that toanywhere between 5 and 10 seconds without the bots. Add in the bots to theverification process and each map can potentially take upwards of 2 minutes.To generate the 1000 maps discussed earlier, the process took over 9 hourson a fairly powerful 3rd generation Intel i5 CPU running at 4.0 GHz andgenerating 4 maps at once (via 4 threads). This gave an average generationtime of about 33 seconds.

35

Chapter 6

Conclusion

The aim of this project was to develop a game, two map generators, andverification system that would separate out the fun maps from those thatweren’t likely to be fun or simply weren’t playable. This project did justthat. However, due to time constraints some stretch goals could not beadded. These included things like items, chests, and other obstacles placedin the maps, and map-feature extraction through human players.

Those extra tasks were planned for the end of the project, since theyweren’t crucial to the project’s success. A lack of time towards the end ofthe project led to these extra features getting dropped in favor of spendingtime polishing the existing system. Since much of that extra content is alsoheavily game-specific, focusing just on the layout of the map allowed for awider application for this project’s output.

If I were to start this project again from the beginning, I would be sureto create an improved method for manually verifying the verification system.Right now, the only way to check the verification system’s output is by usingan image viewer to view the map and a text editor to view the verificationoutput. This process is cumbersome and it could have been avoided with theaddition of an extra part of the GUI.

Another improvement would be to use more types of maps, generatedwith a wider variety of algorithms. For example, adding in an algorithmsimilar to the one used in Tiny Keep [20] would have added some usefulvariation. Having more variation in the maps would increase confidence inthe verification system’s ability to be map-agnostic.

The map generators currently in place, while limited to just the map’slayout, proved to be successful in generating quality maps. While many ofthe maps weren’t of acceptable quality, this wasn’t an issue as the verificationsystem was capable of distinguishing the majority of the good maps from thebad ones. The error rate in the generators also beneficial in that it allowed

36

Chapter 6. Conclusion

the verification system to be tested thoroughly enough to be certain that itwould not wrongly classify playable and non-playable maps.

Overall, the target goals for this project were completed on time and tothe desired quality, which, together, qualify this project as a success.

37

Appendix A

Map Classification Examples

(a) Perlin Noise

{"bots": {

"tilesSeen": 0,"goalsChosen": 0,"movesMade": 0

},"dijkstras": {

"percentReachable": 51,"nonwalkable": 8828,"furthestDistance": 1604,"walkable": 7556,"exitDistance": -1

},"order": -1,"name": "1 - Perlin"}

(b) Feature Data and Classification

Figure A.1: Map Classified as Not Playable

38

Appendix A. Map Classification Examples

(a) Binary Space Partitioning

{"bots": {

"tilesSeen": 0,"goalsChosen": 0,"movesMade": 0

},"dijkstras": {

"percentReachable": 0,"nonwalkable": -1,"furthestDistance": -1,"walkable": -1,"exitDistance": -1

},"order": -1,"name": "7 - BSP"}

(b) Feature Data and Classification

Figure A.2: Map Classified as Not Playable

(a) Perlin Noise

{"bots": {

"tilesSeen": 4021,"goalsChosen": 399,"movesMade": 525

},"dijkstras": {

"percentReachable": 52,"nonwalkable": 7760,"furthestDistance": 1685,"walkable": 8624,"exitDistance": 1291

},"order": 0,"name": "4 - Perlin"}

(b) Feature Data and Classification

Figure A.3: Map Classified as Not Acceptable

39

Appendix A. Map Classification Examples

(a) Binary Space Partitioning

{"bots": {

"tilesSeen": 4273,"goalsChosen": 466,"movesMade": 724

},"dijkstras": {

"percentReachable": 100,"nonwalkable": 11125,"furthestDistance": 1071,"walkable": 5259,"exitDistance": 1004

},"order": 0,"name": "3 - BSP"}

(b) Feature Data and Classification

Figure A.4: Map Classified as Not Acceptable

(a) Perlin Noise

{"bots": {

"tilesSeen": 8035,"goalsChosen": 858,"movesMade": 1210

},"dijkstras": {

"percentReachable": 92,"nonwalkable": 6288,"furthestDistance": 2185,"walkable": 10096,"exitDistance": 1146

},"order": 1,"name": "2 - Perlin"}

(b) Feature Data and Classification

Figure A.5: Map Classified as Acceptable

40

Appendix A. Map Classification Examples

(a) Binary Space Partitioning

{"bots": {

"tilesSeen": 7418,"goalsChosen": 840,"movesMade": 1562

},"dijkstras": {

"percentReachable": 100,"nonwalkable": 9930,"furthestDistance": 799,"walkable": 6454,"exitDistance": 604

},"order": 1,"name": "5 - BSP"}

(b) Feature Data and Classification

Figure A.6: Map Classified as Acceptable

41

Bibliography

[1] Basic BSP Dungeon Generation. (2012, October 26) http://www.

roguebasin.com/index.php?title=Basic BSP Dungeon generation

(Accessed April 27, 2015)

[2] Digital Mars. The D Programming Language http://dlang.org (Ac-cessed April 27, 2015)

[3] Eskerda. (2013) Dungeon generation using BSP trees http://eskerda.

com/bsp-dungeon-generation/ (Accessed April 27, 2015)

[4] Gearbox Software. (2015) Borderlands: The Pre-Sequel http://borderlandsthegame.com/index.php/game/

borderlands-the-presequel#videos (Accessed April 27, 2015)

[5] Gomila, Laurent. Simple and Fast Multimedia Library http://www.

sfml-dev.org (Accessed April 27, 2015)

[6] Google, Inc. Property Animation http://developer.android.com/

guide/topics/graphics/prop-animation.html (Accessed April 27,2015)

[7] Hello Games. (2015) No Man’s Sky http://www.no-mans-sky.com/

about/ (Accessed April 27, 2015)

[8] Jebbs. DSFML http://dsfml.com (Accessed April 27, 2015)

[9] Joachims, T. (2008) Support Vector Machine http://svmlight.

joachims.org (Accessed April 27, 2015)

[10] Joachims, T. (2009) Support Vector Machine for Rankinghttp://www.cs.cornell.edu/People/tj/svm light/svm rank.html

(Accessed April 27, 2015)

[11] Joachims, T. Cornell University. Optimizing Search Engines using Click-through Data

42

Bibliography Bibliography

[12] Joshua Tippetts. (2011) 3D Cube World Level Generation http:

//accidentalnoise.sourceforge.net/minecraftworlds.html (Ac-cessed April 27, 2015)

[13] J. Togelius, G. N. Yannakakis, K. O. Stanley, & C. Browne (2011)Search-Based Procedural Content Generation: A Taxonomy and Survey.IEEE Transactions on Computational Intelligence and AI in Games, Vol.3, No. 3.

[14] Lode Vandevenne. (2007) Texture Generation using Random Noisehttp://lodev.org/cgtutor/randomnoise.html (Accessed April 27,2015)

[15] lrdev. (2010) Differences between Java and C++ http://www.lrdev.

com/lr/java/javacppdiffs.html (Accessed April 27, 2015)

[16] Luke5542. AnimateD https://github.com/luke5542/AnimateD (Ac-cessed April 27, 2015)

[17] Matt Zucker. (2001) The Perlin noise math FAQ http:

//webstaff.itn.liu.se/∼stegu/TNM022-2005/perlinnoiselinks/

perlin-noise-math-faq.html (Accessed April 27, 2015)

[18] Mick Fraser. (2011) FROM ARENA TO SKYRIM... The Evolution ofThe Elder Scrolls http://jedibeatstank.blogspot.co.uk/2011/07/

from-arena-to-skyrim-evolution-of-elder.html (Accessed April27, 2015)

[19] Perlin Noise http://freespace.virgin.net/hugo.elias/models/m

perlin.htm (Accessed April 27, 2015)

[20] Phigames. Tiny Keep Dungeon Generation Demo http://tinykeep.

com/dungen/ (Accessed April 27, 2015)

[21] Planetside Software. Terragen http://planetside.co.uk (AccessedApril 27, 2015)

[22] Randar. (2013) The Bot FAQ http://www.randars.com/bots/

botfaq.html (Accessed April 27, 2015)

[23] Roberts J. and Chen K. (2015): Learning-based procedural content gener-ation, IEEE Transactions on Computational Intelligence and AI Games7(1): 88-101.

43

Bibliography Bibliography

[24] Shaker, Noor and Togelius, Julian and Nelson, Mark J. (2015) ProceduralContent Generation in Games: A Textbook and an Overview of CurrentResearch Springer. http://pcgbook.com/ (Accessed April 27, 2015)

[25] Uber Entertainment. (2014) Planetary Annihilation http://www.

uberent.com/pa/ (Accessed April 27, 2015)

[26] Valve Corporation. Item-making Instructions for Team Fortress 2 http:

//www.teamfortress.com/workshop/ (Accessed April 27, 2015)

[27] Wikipedia. A* Search Algorithm http://en.wikipedia.org/wiki/A*

search algorithm (Accessed April 27, 2015)

[28] Wikipedia. History of Video Games http://en.wikipedia.org/wiki/

History of video games (Accessed April 27, 2015)

[29] Wikipedia. Maze Solving Algorithm http://en.wikipedia.org/wiki/

Maze solving algorithm (Accessed April 27, 2015)

[30] Wikipedia. Support Vector Machine http://en.wikipedia.org/wiki/

Support vector machine (Accessed April 27, 2015)

[31] Wikipedia User:ZackWeinberg, based on PNG versionby User:Cyc. http://commons.wikimedia.org/wiki/File:

Svm separating hyperplanes (SVG).svg (Accessed April 27, 2015)

44