Procedural Generation

of Game Content

A Final Year Report by Owen J Chapman

BSc Computer Games Technology

2016 - 2017

Supervisor: Dr. Matthew Crossley

 No part of this project has been submitted in support of an application for any other degree or
qualification at this or any other institute of learning. Apart from those parts of the project containing
citations to the work of others, this project is my own unaided work.

Signed:

Printed: Owen James Chapman

i
Abstract

This project aims to look at procedural generation methods which can be expressed in a computer
game environment. There are many different computational methods which achieve procedural
generation and the industry is using more and more of these methods to help them in the development
of games, some a lot subtler than others. This project looks at a few examples of procedural methods
as well as examining examples currently being used in game titles, from early uses to upcoming
games. The primary objective of this project is to produce a technical demo of a piece of game content
that has been created using various procedural methods.

The product created for this project can be found at: https://stummuac-
my.sharepoint.com/personal/13144386_stu_mmu_ac_uk/_layouts/15/guestaccess.aspx?guestaccessto
ken=L7Ky0%2bXnEEl1z8XtPyCcnaC9YlREKr2ImA%2blgwcwzFw%3d&docid=2_0fdf2bea5b8b44
bbcb2434e4798bdd06f&rev=1

Follow the link to download the project. The file contains two .zip files which need to be extracted.
The file named 13144386_TechDemo.zip contains a README.txt with instructions on how to use the
.exe file, which is found within the same folder, to experience the product. Alternatively, you can
extract the 13144386_ProjectSourceFolder.zip file and open the containing folder using Unity
(preferably version 5.3.1f), this method allows you to run the product in editor for a more detailed
look.

ii
 Procedural Generation of Game Content
Contents

1.0 Introduction 1
1.1 Report Structure 1
1.2 Project Background 2
1.3 Aims and Objectives 3
1.4 Problems 3

2.0 Literature Review

2.1 Introduction 4
2.2 Games that adopt Procedural Generation Methods 4
2.3 Methods of Procedural Generation 4
2.4 Uses Outside of Games 5
2.5 Uses within Games 5

3.0 Design Document

3.1 Original Ideas 7
3.1.1 Idea 1 7
3.1.2 Idea 2 8
3.2 Final Design Idea 8
3.2.1 Overview 8
3.2.2 Grid System 9
3.2.3 Foliage 9
3.2.4 Water 9
3.3 Software 9
3.3.1 Unreal 9
3.3.2 Unity 10
3.3.3 Conclusion 10

4.0 Implementation Documentation 11

4.1 Introduction 11
4.2 Implementation Stages 11
4.2.1 Getting Started 11
4.2.2 Colour 14
4.2.3 Realism 17
4.2.4 Technical Ease 21
4.2.5 Cellular Automaton 22
4.2.6 Decoration 25

5.0 Evaluation Design Document 27

5.1 Methods of Evaluation 27
5.1.1 User Testing 27

iii
 5.1.2 Black Box Testing /w Example 28
5.1.3 Questionnaire 28
5.2 Other Tests 30

6.0 Evaluation Results 31

6.1 Black Box Testing Results 31
6.2 Questionnaire Results and User Testing Analysis 31
6.3 Suggestions and Improvements 32
6.4 Summary 32

7.0 Conclusion
7.1 Personal Evaluation and Reflection 33
7.1.1 Overall 33
7.1.2 Personal Evaluation on Conducting Research 33
7.1.3 Personal Evaluation on Designing the Product 34
7.1.4 Personal Evaluation on Implementation Stages 34
7.1.5 Personal Summary and Future Work 34

References 35

Appendices
Appendix 1 Terms of Reference 37
Appendix 2 Ethics Form 42
Appendix 3 Participant Information Sheet 45
Appendix 4 Risk Assessment 46
Appendix 5 Questionnaire Results 48
Appendix 6 Black Box Testing Results 50

List of Figures and Tables

Figure 1 - Grid with cell types 7
Figure 2 - Grid with path by AI 7
Figure 3 - Hexagonal grid with water flow idea 8
Figure 4 - Construction of a hexagon 11
Figure 5 - Initial square grid 11
Figure 6 - Hexagon grid, using coordinates from the square grid 12
Figure 7 - Axial coordinates, more appropriate for hexagons 13
Figure 8 - Cube coordinates 13
Figure 9 - Construction of a hexagon 13
Figure 10 - Interactive colouring of cells 14
Figure 11 - Colour blending cells 15
Figure 12 - Better blending with triangulated blend regions 15
Figure 13 - Three shapes within grid for blending 16
Figure 14 - Three shapes shown as mesh 16
Figure 15 - Random colour and colour variance 17
Figure 16 - Height change and slopes 18
Figure 17 - RGBA Perlin noise texture 18
Figure 18 - Noise for variation 19
Figure 19 - Subdividing hexagon edges for more distortion/variation 19
Figure 20 - Reconnecting gaps 20

iv
Figure 21 - Larger map with distortion 20
Figure 22 - Map chunks, as seen by selection 21
Figure 23 - Larger map 21
Figure 24 - Console evidencing cases which need to be changed 22
Figure 25 - One-pass smoothing 23
Figure 26 - Multiple-pass smoothing 23
Figure 27 - Constructed smoothing algorithm for cellular automata 24
Figure 28 - Foliage generation method 25
Figure 29 - Example of a finished terrain 26
Figure 30 - Evaluation questionnaire 28-29
Figure 31 - Gantt chart 40

Table 1 - Black Box Test 28

Table 2 - Timetable of Deliverables 41
Table 3 - Chunk Count X 50
Table 4 - Chunk Count Z 50-51
Table 5 - Camera Controls 51-52
Table 6 - Command Buttons on GUI 52
Table 7 - Smoothing Algorithm - Smoothing Cycles 52

v
 Procedural Generation of Game Content
1.0 Introduction

1.1 Report Structure

The following report consists of seven chapters, each with a focus on a specific aspect of the project.
Listed below are the chapters with a brief summary of what that chapter contains.

Chapter 1 - Introduction

This chapter contains project background, aims and objectives of the project and any potential
problems that may be faced when tackling the solution to the project,

Chapter 2 - Literature Review

Chapter containing detailed analyses of current literature, as well as game titles, with relevance to the
project.

Chapter 3 - Design Document

Design chapter contains and reviews initial and final designs for solutions to the project.

Chapter 4 - Implementation

Covers the stages of implementation of the final design idea through to completion of the product.

Chapter 5 - Evaluation Design

Identifies the steps that will be carried out to perform adequate evaluation.

Chapter 6 - Evaluation Results

Contains the results of the evaluation methods used to gather data on the project.

Chapter 7 - Conclusion

Summary of the entire project, including author's views on how the project was handled and how it
could be improved.

1
1.2 Project Background

The video game industry practises a large variety of differing computational techniques to expand and
push technology to its limits. A common method, dating back as far as 1978 (Beneath Apple Manor,
a roguelike game which predates the genre defining Rogue), has been to use procedural generation
to create game content (CRPG Addict, 2013). This is the computational method of using algorithms to
form various aspects of a game for the user. An example of a game that uses procedural generation to
this effect is Minecraft, which, in single player, builds a world for the user to explore which is
different to any other players. Although some games use procedural generation to create the whole
game, others use the method as a way of creating a base-layer or parts to build upon; such an example
would be a terrain or forest can be formed by an array created using cellular automata.

1.2i How are you going to solve the problem?

What is your approach?

This project will explore the possibilities of producing a game in which most aspects are generated
procedurally. For instance, the terrain would be randomly generated via a technique, such as cellular
automata, that would then be used to define the map, e.g. where trees would go, water, grass, etc. This
map would then be the foundations of a simple game.

1.2ii How will you measure success?

What is vital, and what would constitute a bonus?

Vital for success is a final product which uses some form of procedural generation technique to create
a world that can be displayed. Essentially the generated world would be used as a baseline of creating
the game. However simple the game may be doesnt matter, as this project is only to explore the
power of procedural generation within games and not creating a fully functioning game. An extension
to this could be to add some form of control options which affect how the map is generated, such as
having islands, one land mass surrounded by water, etc.

1.2iii Do other pieces of work similar exist?

What relevance do they have to this project?

Other pieces of work which include successful implementation of procedural generation are the space
exploration game No Mans Sky and the upcoming platformer Chasm.

The game No Mans Sky implements procedural generation in most aspects of the game such as
geometry, colour palettes and animations. In terms of procedural generation technology, it is a
massive step up in the field compared to previous entries, as described by gregkwaste (2016) at
3DGameDevBlog. This shows that there are still advances to be made in the area and thus shows
relevance of the project for the industry.

Chasm is an upcoming game that employs procedural generation techniques inspired by the earlier
Metroid platform games created by James Petruzzi, being released in 2017. The game focuses less on
total randomness and more about possible variations (Lena LeRay, 2016). A project such as Chasm
brings to light that successful games from previous generations can be reinvented using modern
techniques.

2
1.3 Aims and Objectives

The primary aim of this project is to;

Investigate the use of procedural generation for the creation of terrain, with an emphasis on
the generation of suitable accents, such as foliage.

Personal aims of the project are;

Gain a greater understanding of procedural generation used within the computer games
industry
Improve/gain new skills in project development and management.

The aims will be met by completing the following objectives;

Identify how existing games use procedural generation

Design algorithms for procedural generation
Compare and contrast designed algorithms
Implement most suitable algorithm for each element
Provide a simple game that explores the game world
Avid testing to ensure integrity of product
Critical evaluation of content created

1.4 Problems

There are limited foreseeable issues that this project may face behind generic computer based system
errors (e.g. loss of data, etc.). Therefore, management of these issues mostly consists of basic file
management and data backups. An issue of primary concern, though still minor, would be the
likelihood of procedural generation techniques becoming unsupported with programming language
updates. This is highly unlikely to happen, as programming languages are usually backwards
compatible, however if this does happen to the primary language (e.g. C#), a secondary language will
be used instead (e.g. Java).

3
 Procedural Generation of Game Content
2.0 Literature Survey

2.1 Introduction

Procedurally generated content present in video games is not at all a new technique and has been used
for many successful games and franchises in years gone by, such as Diablo, and is still being used in
more recent creations, No Mans Sky for example. Procedural generation is a method, specifically in
games to create content, to spawn data using algorithms instead of doing so manually. Games take
advantage of these methods to construct large amounts of content in a shorter period (Cook, 2015),
saving time and money during the development of a game. Other advantages include creating smaller
file sizes and the addition of randomness for a less predictable gameplay experiences.

2.2 Games that adopt Procedural Generation Methods

Minecraft, a sandbox game, allows players free reign in a procedurally generated 3D game world
environment. Current sales of the game exceed 106 million copies (Mojang, 2016) as of June 2016,
making it the second bestselling videogame of all time. The game takes advantage of procedural
generation, a technique that was widely underappreciated, though still commonly used, prior to the
release of Minecraft. The surprising success of Minecraft brought new light to the aspects of using
procedurally generated content within games. Technically, the generation methods/algorithms of
Minecraft are comparatively simple (initially, though they have become more complex as the game
has advanced) to those of more advanced games (Fingas, 2015). This relative simplicity will be a key
factor in helping resolve the problem as a simple, yet effective, solution would be the ideal outcome.

No Mans Sky, released in 2016, uses procedural generation techniques in many aspects and areas of
game content. Such areas include geometry, colour palettes and animations. The game was a
commercial failure, with many players wanting to refund the game hours after purchase (Davenport,
2016), but the technology present in terms of procedural generation of game content was an incredible
step up compared to previous games headlining similar techniques (gregkwaste, 2016). These
generation techniques explored, and used, in No Mans Sky should prove useful in providing a suitable
solution to the defined problem.

Chasm, an upcoming game developed by James Petruzzi, employs methods of procedural generation
in a Metroid-like platform game with intended release in 2017. As a concept the game aims to focus
the generation less on randomness and more about the variety of possibilities. This focus is another
aspect of generation which should be considered during the implementation of the problems solution,
as pure randomness may lead to a less appealing game experience. However, considering that game
experience isn't the primary concern of the project, implementing/altering the system to accommodate
for this approach is to be a secondary objective.

2.3 Methods of Procedural Generation

L-System, short for Lindenmayer System, are popular recursive methods used most often in the
generation of plant-like artificial material (though also for geometry) as they can create very realistic
models of natural patterns (Rozenberg, G., Salomaa, A.). For this reason, they are often employed in

4
creating realistic trees, shrubbery and vegetation in computer game systems as they, assuming they
are kept to a reasonable length, are not very demanding on processing power to compute.

Another method used in the industry for procedural generation is known as Perlin Noise (Flafla2,
2014). In this method, the application of Perlin Noise allows the creation of natural look and feel,
such as adding shakiness to a drawn line to make it appear hand-drawn or emulating the randomness
of smoke, while keeping an ability to be easily and readily controlled making this method highly
desirable. Naturally, this method lends itself to a use with textures generation and texture appearance
in computer created graphics. Minecraft makes use of this method in the generation of the map, using
the noise generated to create the finer details of the terrain.

Cellular automaton (Shiffman, 2012), another common practice, uses a grid system which forms the
base of its procedural generation method. Each cell of the grid has a number of states for which that
particular cell could be. In summary, once the algorithm has finished a pass of the grid, each cell will
have a state selected, often determined (using pre-set rulings) by the ones around itself (the cells
neighbouring cells) for increased smoothness. In games, this method can be used to, for example,
create dungeon layouts and position trees in a forest.

Although not specifically employed in a game context, fractal geometry (Barnsley and Rising, 1993)
is the method of replicating a pattern. The repetitive nature of Fractals allows them to be used in a
procedurally generative way by establishing some rules and setting the amount of times to repeat the
process, resulting in a unique pattern. This method can however be relevant in a game context because
the method can be used to model the surface of mountains, which can then be crafted into terrain,
creating realistic looking mountains and rock faces.

2.4 Uses Outside of Games

An interesting concept, by French researchers A. Peytavie, E. Galin, J. Grosjean and S. Merillou in

2010, explores the possibilities of using procedural generation algorithms to generate roads based on
a weighted anisotropic shortest path. This will be used to create the shortest path between an initial
location and final point, ideally providing a solution with the shortest cost taking into consideration
parameters such as rivers and mountains. The concept can be used in many scenarios such as city
planning and bypass rerouting, providing a cheaper method of calculating the construction costs of the
proposed road. In terms of this project, this helps to show relevance in a non-games related context,
highlighting that the procedural generation techniques and methods explored and practiced in this
project have a transferable identity that can be desired in other, real-world, areas of industry.

2.5 Uses within Games

The maps generated by Minecraft rely upon procedural generation techniques which create the
environments that are guided by specific rules which allow the generation to have consistent logic,
such as rocky mountain regions, lowland trees and grassy plains (Fingas, 2015). Using Perlin noise
calculations, Minecraft starts with creating a simple level then adds noise to create the details, such as
shrubs, hills and lakes, with a just about lenient enough ruling system to allow for unexpected results.
These results allow for a greater user experience as the player doesnt know what they will find in the
world and is, therefore, given the incentive to explore and discover what the world must offer.

5
In No Mans Sky, creatures and other geometric entities are created procedurally. The process of doing
so involves a main part of the body being selected (gregkwaste, 2016). Following this, parts of a
group that fit a describer for the main part of the model (i.e. if a fish head is the main, only parts that
fit the fish describer are available to be used) are selected for the final model. This process is
repeated, adding parts from different groups until all parts of the model have a suitable item selected.
This method often leads to a new and unique model being created. The entire process is a tree
traversal, the root containing every single part, branching down until the leaf at the end is the unique
model that can only be created using the parts along the route.

Sound and music are also important aspects of games. Nearly every game has its own soundtrack
because it is such an essential part of the user experience. The term generative music, popularized
by Brian Eno, refers to music that, given the numbers, could potentially exists indefinitely (Eno,
1996). This is an interesting area for exploration, but is not sufficiently relevant to the specifications
of this project to be examined further here. Thus, there will be little, if any, generated music or sounds
implemented into the final product but the area itself is of high regard and provenance around this
study and so should not have been disregarded in this survey.

6
 Procedural Generation of Game Content
3.0 Design Document

3.1 Original Ideas

3.1.1 Idea 1

Figure 1. Grid with cell types

An idea, based on suggestion from supervisor and personal preferences of games, would be to have
some sort of background generator of an AI. This background would then affect how they go about
making decisions. A method theoretically thought of to test this would be to have a simple 2D array,
as shown in Figure 1, to represent a game map with different terrain, the AI would then navigate the
map from point A to B via the route that would be most suitable for them based on characteristics
given to them from the background generator. For example, the background generator gives a
characteristic that means the AI prefers woodland and cannot swim, this would mean the path from A
to B would mostly prefer wooded areas and avoid all water tiles, as shown in Figure 2.

Figure 2. Grid with path by AI

7
This could be extrapolated and expanded on further to increase variety of decision making within all
types of game genres, be it shooter logic or RPG player interactions, and not just limited to
pathfinding.

3.1.2 Idea 2

The second idea was to have a game in which most aspects are generated procedurally. By this it is
meant the terrain is randomly generated using Cellular Automaton, this will then be used to define the
map, e.g. where trees would go, water, grass, etc.

However there is a benefit to procedurally generate content during production and then use that as
a seed to making data. For example, you can procedurally place trees on a terrain to create a forest,
and then save that as your map, instead of placing all the trees by hand. (Tetrad, 2010)

Essentially the generated code would be used as a baseline of creating the game. Extension to this
could be to add some form of control options which affect how the map is generated, such as having
islands, one land mass surrounded by water, etc.

3.2 Final Design Idea

3.2.1 Overview

Figure 3. Hexagonal Grid with water flow idea

The illustration above, Figure 3, shows a design idea for the generation of a map/terrain. The map
would be created using a grid based system and implementing cellular automaton to give each cell in
the grid a state. Using this method would provide a complete terrain.

8
The numbers and colour of each cell are representations of the states of the cell.
1 - indicates that the terrain would be grass based.
2- indicates that the terrain is also grass but has a border with a water cell.
3 - indicates moving water*.
4 - indicates still water.

The intention would be that each main state has some other form of mini-state giving them a unique
property, examples of such would include 1 main states having a state to include a tree, or moving
water (3) states to include their direction.

*The main idea behind this is that each cell of moving water is that they are given a direction at the
source. This direction has a 1 in 3 chance of sending the moving water out of the cell in the exits
pointed in that direction. So, for example, if the water is moving into the cell from the North-East, the
possible directions of the water to exit the cell are the South-West, South-East and East. It would also
be possible for two of the directions to be chosen, leading to larger river-like structures.

3.2.2 Grid System

Using a grid of regular hexagons has been the desired choice due to their ability to uniformly
tessellate. Among other shapes with this property (Edkins, 2007), hexagons remain simple enough
(only 6 sides) but versatile enough for the river-water direction idea to provide interesting results.

A square-based grid was opted against because aesthetically will produce results which are easily
identifiable as a grid.

3.2.3 Foliage

Trees, plants and grass are intended to be aspects of the game which would be procedurally generated
and set out in the project solution. As explored in the literature review, a popular way of doing this
would be using an L-System (Rozenberg, G., Salomaa, A. 1980 and 1992) as the results of such
methods are reasonably natural looking and can create realistic plant structures.
An alternative to L-Systems generation of foliage is to have multiple prefabs of trees/plants created
which are then instantiated into the game world procedurally.

3.2.4 Water

Water is a reasonably large portion of the project result, so a method for creating a source and
managing the flow/direction of the water procedurally would be worth using. This would be an
extensive task and one which would be looked at more in-depth once the original aims have been
addressed.
As a result, an alternative to this type of water system would be to only have bodies of water
representation created during the grid generation without the flowing system as represented in the
diagram. This would still show as appearing to have large areas of water without completely
excluding some form of water system.

3.3 Software

3.3.1 Unreal

9
Advantages of using Unreal Engine
Often final product looks aesthetically pleasing
Offers blueprint
Familiar with the system
Relevant to the industry, especially so for AAA titles

Disadvantages of Unreal Engine

High requirement of computational power
Asset marketplace has few free resources
Updated very often, can lead to issues with running out of date projects

3.3.2 Unity
Advantages of using Unity
Simple to use
Familiar with the system
Relevant to the industry
Can run well on lower end PC
Free access to marketplace of assets

Disadvantages of Unity
A lot of extra work needed to make the final product as aesthetically pleasing as Unreal
projects.
No blueprints

3.3.3 Conclusion
Unity is most likely to be the software used to create this project, this is because of familiarity with
the software and mostly personal preference. Unreal can be used, however, as a fall-back option if the
project fails to take hold using Unity.

10
 Procedural Generation of Game Content
4.0 Implementation Documentation

4.1 Introduction

Squares have eight neighbours, look simpler and have different distances to the edge neighbour
centres and corner neighbours. These differences can cause complications for certain types of
movements and can be avoided by using hexagonal grid.

Hexagons have only six neighbours, all neighbours are edge neighbours and the distance to the centre
of all the neighbours is equal.

Figure 4. Construction of a Hexagon

Figure 4 shows the construction of a hexagon. The Green line represents Outer radius (from centre to
edge), this is equal to the distance from the centre to any corner. Red Line represents Inner radius; this
is equal to the distance from the centre to any edge. The inner radius can be calculated by multiplying
the outer radius by (3)/2. For example, an outer radius of 10 would have an inner radius of 53.
For edge length e, the inner radius is

((^2) ((/2)^2)) = (3((^2)/4)) = (3/2) 0.886.

The inner radius is an important value for the project as the distance to the centre of neighbouring
cells is double this value.

4.2 Implementation Stages

4.2.1 Getting Started

Initially started by creating a square grid, seen in Figure 5. This grid consists of cells which have been
created procedurally of 6 height and width, the size of each cell is 10x10 and so there is an offset of
10 for the grid creation.

11
 Figure 5. Initial square grid

The next step was to arrange the grid of squares in a way which hexagons would fit together.
Hexagons do not sit directly on top of each other, so an offset of half the cell size on alternating rows
would achieve a tessellating pattern, the desired structure.

With the grid structure now in place, the square cells would be replaced with hexagons. A new mesh
component (via a C# script) was created for this. The purpose of the mesh was for it to triangulate
every cell individually and assign the generated triangle and vertices to the mesh. The Triangulate
method is used frequently and can be invoked at any time, not just when a cell is created, as such the
method begins with clearing the old data stored and the final action of the triangulate is to recalculate
the mesh normals.
A hexagon is made of 6 triangles, a method was made for adding triangles given 3 vertices and adding
them to the vertices list in order, the crucial part of this method was that the index of the first vertex
was equal to the length of the vertex list before new vertices are added, else the first vertex of the next
triangle would not be in the correct/intended location. A loop of this for all 6 triangles was used to
generate each hexagon. A 7th corner was added to the metrics, identical to the first, to prevent an
error caused by trying to find an out of range index.

Figure 6. Hexagon Grid, using coordinates from the square grid

The cell coordinates appear to be zigzagging as shown in Figure 6, this is due to the offset of the
rows. To help work with coordinates in a more appropriate manner, a conversion script was used to
get the axial coordinates, see Figure 7, for ease of use.

12
 Figure 7. Axial Coordinates, more appropriate for hexagons

These coordinate, however, are incomplete as there is still a missing axis. This hidden axis, Y, can be
found by mirroring the axial X axis. A trick exists to working out the Y axis; all three coordinate
components added together will always equal 0. This way, we do not need to store the Y axis, but
instead compute it on demand. These coordinates are often referred to as cube coordinates due to their
3 dimensional properties and the topology appears to be that of a cube as shown in Figure 8.

Figure 8. Cube Coordinates

Figure 9. Construction of a Hexagon

Figure 9 shows cube coordinates appearing in the inspector. This would become helpful later in
development once the labels of the cells are removed, also they allow for easier debugging by
allowing the coordinates to be printed into the console more easily identifying and pinpointing cells.

13
4.2.2 Colour

Figure 10. Interactive colouring of cells

Basic interaction was implemented to allow cells to be painted a different colour on contact, as shown
in Figure 10. This interaction was used to colour the cells until implementation of automatic cell
colouring on grid generation.

The next step was to allow for colours of cells to blend, to create a more natural looking terrain. An
important step for this was to identify for each cell its surrounding neighbours. Using the directions of
a compass for these neighbours made logical sense, so they were defined as an enumeration type as
NE, E, SE, SW, W, NW (clockwise around each cell from North). The neighbours were then stored in
an array. Methods to Get and Set neighbours were added to assist in populating the array.

Next step was to set up colour blending triangulation support. A method, called AddTriangleColor,
only accepted one argument, meaning it could only allow a triangle of a single, solid colour to be
created so an alternative was added which accepted three arguments, one for each vertex of the
triangle.

Initially some odd/unintended results were being given once the cells were being coloured, as seen in
Figure 11, however, with a bit of tweaking with colour averaging and the addition of blending regions
between the hexagons, an acceptable outcome was achieved, shown in Figure 12.

14
 Figure 11. Colour Blending Cells

Figure 12. Better Blending with Triangulated Blend Regions

15
 Figure 13. Three Shapes Within Grid for Blending

Figure 14. Three Shapes shown as Mesh

Three shapes to represent the blending regions, as shown in Figure 13 and Figure 14. Hexagon has no
blending, solid colour. The quad at the hexagon edges has two tone blending and the triangle in the
hexagons corners has three-way blending. Using these blending regions avoids the effects of
blending seen in Figure 11, especially the edge corner cases which resulted in an unsightly line.

16
 Figure 15. Random Colour and Colour Variance

Figure 15 shows some variance in the colouration of the cells, achieved by having a random number
within a range assigned to the red value of the RGB used to define the colour of each cell. Changing
only the red means that the base colour of the cell remains relatively similar others of the same base
colour, i.e. all green cells look green but slightly different. At this point was also when the colours of
each cell were generated on creation of the grid, which was the beginning of the random generation of
cell states which would eventually be used as the base for cellular automata.

4.2.3 Realism

The grid was looking a bit flat now, so elevation was the next order of business. Each cell type
(referred to internally as base colour) was given a set height on generation. The brown cells were
given the highest height as they would be used to represent mountains, green cells representing
fields/flats were risen slightly, yellow/sand remained true and blue, for water, was sunk slightly.
Figure 16 shows how this gave the grid, now looking more like a map, significantly more depth than
previously. For the quad blending regions to act as slopes, the two vertices touching an elevated
neighbour y values were changed to match that of the height of the neighbouring cell. A similar
change was needed for the triangle blending regions.

17
 Figure 16. Height Change and Slopes

The effect of the height changes and the slopes between the cells gave a desired effect, but the cells
still were rather flat. To amend this, a noise map will be used to give some irregularity to the shape
and height of the cells. Figure 17 shows the texture that was chosen for this task. It contains a
different noise value in each of the four colour channels, RGBA. Functionality to then sample the
noise texture was added to the HexagonMet.cs the output of which would produce a Vector 4 with
four noise samples.

The values are calculated by bilinear filtering of the texture sample and using the world coordinates,
X and Z, for the UV coordinates of the texture. This results in a colour output which can be directly
cast as a 4D vector. These are the values that are used to distort the vertices of the hexagonal grid.

Figure 17. RGBA Perlin Noise Texture

To add the distortion to the grid, each vertex needs to be individually perturbed. For this to take effect,
a Distort method was added into the HexagonMesh script which took a position, an undistorted point,

18
and returned a perturbed one by adding the sample amount to the original position in all three axes.
Figure 18 shows the results of the Perlin Noise distortion.

Figure 18. Noise for Variation

The results are starting to look a bit more irregular as a real terrain would be, but the visualisation of
the grids and the cells within still appear to be obviously hexagonal in shape. While not necessarily an
issue, a simple, yet effective, fix for this is to add more vertices. Therefore, the triangles which were
used to make up the hexagon were each split into three, as shown in Figure 19, resulting is a much
more diverse cell shape creation due to the distortion of each vertex.

Figure 19. Subdividing Hexagon Edges for More Distortion/Variation

As can be seen in Figure 19, there are a lot of gaps/cracks that have now appeared. This is because the
connecting blend regions (the quads specifically) have not been subdivided along with the hexagon

19
faces. Therefore, these regions also needed to be subdivided, as shown in Figure 20. To see how this
would look on a larger map the terrain size was increased, as shown in Figure 21.

Figure 20. Reconnecting Gaps

Figure 21. Larger Map with Distortion

20
4.2.4 Technical Ease

At this point it made sense to bundle the edge vertices compared to working with four vertices as
individual vertices. For this, a structure to contain the four edge vertices stored clockwise along the
cells edge was created. Two new methods using this structure were created to allow for
simplification of the main triangulation method and the triangulation connection method.

Also, when the larger map was created, it was evident that there is a limit of what a single mesh can
handle. As a result, more than one mesh was needed to contain all the data needed for a larger terrain.
To achieve this, the grid was partitioned into multiple chunks of a regular size, as shown in Figure 22.

Figure 22. Map Chunks, as seen by selection

Figure 23. Larger Map

At this point (Figure 23) the maps are looking good and are suitable to be made into larger sizes.
However, there is an issue in that each cell is assigned a state randomly, leading to unrealistic looking
terrain layout. Cellular automaton is the method that has been chosen to take steps to amending this
issue, as it allows a cells state to be compared with its neighbours with their states taken into
consideration. The randomly assigned colour will be used as the base for the first pass of the cellular
automaton smoothing algorithm.

21
4.2.5 Cellular Automaton

The first step was to make rules which identify when a cell needed to be changed. The rule chosen in
this project was to change a cell when it has more of one type of neighbour than any other type. In
Figure 24, you can see in the console which cells have been identified as needing to change and to
which case. Using this as a start, the next process was to actually commit to the change in cell state.

Figure 24. Console evidencing cases which need to be changed

One pass of the cellular automata smoothing algorithm (Figure 25) improved the layout of the grid
significantly compared to the wholly random nature of the grid before the smoothing. A simple loop
was added to the smoothing algorithm which smoothed the terrain multiple times (Figure 26),
creating an even smoother and more realistic terrain style/layout. After multiple iterations, trying
different amounts of smoothing, it seemed that three loops of the smoothing algorithm produced the
most desirable results, giving terrain which isnt over-smoothed or too random-looking.

22
 Figure 25. One-Pass Smoothing

Figure 26. Multiple-Pass Smoothing

Figure 27 (below) shows a version of the smoothing algorithm that was created to produce the cellular
automata effect on the hexagonal grid. The whole thing is contained in a simple For loop, which
repeats the process (in this example) five times. The method works by sequentially passing through
every cell contained in the cell array, populating an array of that cells neighbours then keeping a
count of each type of neighbour that cell has; e.g. 1 yellow, 3 blue, 2 green. The most matching
neighbour is identified and the cell is assigned its new state of that of the most matching neighbour.
The process repeats for the next cell in the array of cells.

23
Figure 27. Constructed Smoothing Algorithm for Cellular Automata

24
4.2.6 Decoration

As part of the aims of the project, foliage and other accents are important to the project. Initially they
were aimed at being generated using Lindenmayer systems, but this idea was causing too much of a
set back in timeframe sensitive work, so an alternative method was created (Figure 28). Prefabs for
trees were created which are then instantiated into the world on specific cells using that cells centre
for a random position within that cell. A similar event happens for mountain cells using rocks as the
prefab.

Although not the initial intended way to decorate the terrain, this yielded rather successful results
(Figure 29). With this part completed, this came to the end of main implementation stages of the
project, with final alterations being mostly clean-up or minor work. Satisfactory results have been
achieved with the completion of the decoration and no more necessary work

Figure 28. Foliage Generation Method

25
Figure 29. Example of a Finished Terrain

26
 Procedural Generation of Game Content
5.0 Evaluation Design Document

5.0 Evaluation Design Document

Evaluation is a crucial part of the project as the resulting product needs to be evaluated to measure its
effectiveness to the aims and objectives set out for the project to meet. Different steps of evaluation
are carried out by the designer and an external user base. Below are the events that will take place to
gather results for the evaluation.

5.1 Methods of Evaluation

Black box testing is a method of testing software which will be conducted by the researcher/developer
of the project. This method is suitable to an acceptance level of testing, meaning testing carried out
approaching final release (a higher level) of a product. A useful advantage of using black box testing
is that the tests are carried out from a users point of view, allowing exposure of discrepancies from
the specification/terms of reference (Black Box Testing, 2016). This is crucial in evaluating whether or
not the final product meets the requirements.

User testing will allow for feedback from follow-up questionnaires. These will be carried out by
selected participants and the results of which will be analysed and evaluated.

5.1.1 User Testing

Test subjects will be selected from a group of willing participants familiar with the area of study of
the project. These participants may include students currently enrolled in the Computer Games
Technology, Computer Games Design and other related courses. A short questionnaire will be given
to the participants to complete, with questions to be answered prior to and after the testing sessions,
composed of Likert 5-point scale style questions with some allowing for open ended responses when
more detail may be required.

Participants will be given a loosely-structured task to complete. Participants will be asked to follow
simple instructions to guide them through the product then given free reign to explore the generated
content. The project researcher will be present during the user testing as to be available to answer any
questions the testing participants may have. In total, per participant, the testing session with
questionnaire would be no longer than ten minutes.

The format for the participants will be as follows;

The project will be prepared for the tester so that they can initiate the testing when they feel
comfortable to do so.
The participant will be greeted formally and briefed on the situation of the study.
The brief will involve an explanation of the study and details of the follow-up questionnaire.
Testers will be asked to answer the first two questions after giving consent, at this point they
can continue with the test.

27
5.1.2 Black Box Testing /w Example

The following table contains an example of black box testing and how it will be laid out for the grid
size input in the product. This input determines the size of the grid that will be created.

Section/Method Test Input Expected Result Actual Result Comment

Grid Size (int) 6 A grid of 6 by 6 As expected No comment

hexagons

(string) test No grid is created Crash Fixed a bug

as no valid size is which allowed
defined input value of
grid size to be
non-integer.

(float) 5.5 No grid as no As expected Previous bug fix

valid size is allowed for all
defined data types other
than integers to
be prevented
from being
entered into grid
size.
Table 1. Black Box Test

5.1.3 Questionnaire

This questionnaire will be given to the testing participant before the start of the playtest, as some
questions are required to be answered beforehand. The aim of the questionnaire is to determine
whether or not, from the tester's point of view, the game successfully generates content which would
be considered suitable to the game environment. This will help to reflect upon the aims and objectives
set out in the Terms of Reference (Appendix 1).

The following questions are to be answered before the playtest;

1. Are you familiar with games where content has been created procedurally?

[ ]1 - very familiar [ ]2 [ ]3 - neutral [ ]4 [ ]5 - very unfamiliar

2. Could you name up to 3 games you have played which use procedural generation

28
The following questions are to be answered after the playtest;

3. This project was intended to use procedural generation techniques to create game content.
Do you agree that the product presented content in this way?

[]1 - strongly agree []2 []3 - neither []4 []5 - strongly disagree

4. Was there anything about the project that you found particularly interesting and/or stood
out as exciting or interesting?

...

5. Could you give one suggestion or improvement you would like to see for the project?

...

Figure 30. Evaluation Questionnaire

Question 1 and 2 are aimed at gathering information about how familiar participants are with the term
of procedural generation of content within a game perspective. The results of this will allow
evaluation of whether or not the system being tested would be categorised as procedural generation
when compared with the results of what the answers to this question provide.

Question 3 aims to identify whether the testers agree that the project meets the requirements to create
game content using procedural techniques. The answers to this question will determine, more so than
the others, if the project can be deemed as a success. For the project to be deemed successful, 90% of
the responses to this question are required to be 1 or 2. These responses, would show that people
believe the content created in the demo of the project has been created in a procedural method and
therefore the primary aim; Investigate the use of procedural generation for the creation of terrain,
with an emphasis on the generation of suitable accents, such as foliage, would have been met.

Question 4 allows participants to give feedback on what it is about the project they liked. This will
allow determination of parts that worked well and which can be focused on when improving the
project in the future.

Question 5 provides an opportunity to gain suggestions and improvements for the project. These can
then be taken into consideration when expanding upon the project or giving insight into potential
oversights of the project, such as potential features that were missed during development.

29
5.2 Other tests

Comparisons to known/published alternatives;

As a comparison, Civilization V (Plunkett, 2016) has a very similar technical style to that displayed in
this project. Civilization uses a hexagonal grid system which employs a method of simulating the tiles
to be presented with similar geography to the surrounding tiles, providing a smooth terrain which
could represent realistic terrain.

Tests that need not be run and why?

Do you need to carry out the tests using different hardware?

Testing on different hardware setups will not be carried out for this project. This is due to the final
product being intended to be a technical demo used to demonstrate how techniques could be used to
achieve procedural generation of game content while a finished game product is not the aim.

30
 Procedural Generation of Game Content
6.0 Evaluation Results

6.1 Black Box Testing Results

The tables in Appendix 6 show the results of the black box testing carried out for this project. Black
box testing allows for the examination of the functionality of the product without the need to have
peer into the inner workings of the internal structure of the product. With this in mind, some of the
sections and methods that were tested below are from both in editor and final technical demonstration
build.

There were only a few minor changes/alterations needed to prevent some unlikely errors in the
displaying of the grid generation. These occurred when trying to enter negative integers in the grid
size, prevention of these types of entry worked around the errors that were created upon this type of
data entry.

Other than these minor issues, the results of the black box testing yielded positive results of the
product working as intended in every aspect. As a result, the product can be considered complete and
bug free.

6.2 Questionnaire Results and User Testing Analysis

Based off the results from the questionnaire (see Appendix 5) and general conversation with those
who took part in the user testing sessions, a clear majority of participants believed the product used
procedural generation techniques and methods to create game content in a successful manner. This
goes to show that the product successfully, in the eyes of user testers, met the aim of the project.

A majority of the testing participants were familiar with existing game titles which take advantage of
procedural generation, with many of them citing titles which have been reviewed earlier in this
project, such as No Mans Sky and Minecraft and many others. This shows that the group of testers, as
a whole, were familiar with the concept of game content produced in a procedural manner, meaning
that the testers had knowledge of the research area and thus are able to provide an educated response
to the questions in the questionnaire. It is essential for the project that the user group met the criteria
of being knowledgeable in the area of research.

As set out in the evaluation design, the answers to question three require 90% of participants to
answer above three on the linear scale. The results yielded 100% above this requirement and as such
the product can be deemed a success.

There was promising feedback from the user testers when they were asked what about the project they
found interesting. A repeated feature that was found to be interesting was that the entire map
regeneration lead to good variations in what ended up being presented, with an emphasis on this
leading to strong replay ability in a games related use.

...there was one map with a large mountain section that could lead to certain game-play elements
that aren't possible in a map with just water and forests for example. - A response to question four.

31
The point made in this answer is exceptional in the way that the map generation could lead to certain
compositions of the terrain, leading to potential gameplay experiences that would be unique to that
terrain composition. This is a feature that wasnt initially intended during the production of the
product, but is a welcome side effect.

Another complement of the product from a tester was that the generations were smooth and was
impressed with how everything joined up nicely. This was an intended aspect of the product and so is
nice to hear appreciation of this.

6.3 Suggestions and Improvements

There were a variety of suggestions/improvements that were given as responses in the questionnaire.
One noted the blending between blue tiles and other tiles. This instance of blending was known as
being unsightly but unfortunately wasnt acted upon at an early enough stage in development to make
it into the final product, but would be one of the primary issues to amend upon future work on the
product. This would be considered an improvement to the product.

Suggested features from the questionnaire included the ability for the player to be given more control
options when it comes to the generation of the map. The ability for the user to decide the size of the
map, for example, was one of the suggestions. If a feature such as this was implemented, there could
be potential to allow for further manipulation of the terrain to allow control of other aspects of the
map. This would be a feature that could see great benefit of the product if implemented, as there
would be more interaction for the user.

Another popular suggestion was for more diversity in cell types. This is something that wouldnt be
too difficult to implement into a finished system and would provide more variation in terrain
generation.

6.4 Summary

In general, the results from all feedback and testing session was positive. This gives a good idea as to
how the product performs against the aims and expectations of the project.

32
 Procedural Generation of Game Content
7.0 Conclusion

7.0 Conclusion

Demonstrated in this report has been the work involved in showcasing procedural generation methods
of creating game content for a terrain and accents on the terrain. There was much research undertaken
into methods and techniques of procedural generation as well as evaluation of existing game titles
which use these methods. This research was then used to shape and guide the product in the direction
it took during both design and implementation. Though there were a few hiccups during
implementation and design, which made these stages take longer than intended, the final product did
not suffer too much and is of acceptable quality. Something that could be applied if the project were
to be repeated would be consideration for design and implementation techniques should have been
taken during the literature review stage of the project to allow for smoother work rate throughout the
project, potentially avoiding long stalls. Overall, it is shown in this report that procedural generation
techniques can be used to create content for a game, as well as other uses, efficiently. With this
knowledge, the video games industry can take advantage of these methods knowing that they can be
suitable for game content.

7.1 Personal Evaluation and Reflection

This section contains the authors personal feelings about the performance, learning outcomes and
overall thoughts about the project and the different sections that make up the project.

7.1.1 Overall

Overall, I am happy with how the project and product came together. Initially progress was slow but
as more work and time was invested into the project, a more complete product was being made.
Another great boost to my moral was the feedback I received from the user testers as everyone had at
least one good thing to say about the product they tested. I was initially afraid that people wouldnt
consider the product a complete game and that would be reflected in the feedback, however, people
understood that this wasnt intended to be a game but more of a technical demonstration to showcase
the methods used in the procedural generation of content. Knowing now first-hand what these
methods are capable of when used in a game context, I can comfortable apply them into my future
work, both in and outside of the games industry.

7.1.2 Personal Evaluation on Conducting Research

Researching existing literature and game titles for this project was a first for me. Never before have I
had to research data in such a quantity before, but it was something I found very interesting and
enjoyable to carry out. Due to lack of experience in this area prior to this project, it took a while to
grasp the key skills required to carry out such a task and progress wasnt as fast as I would have
wanted it to be. However, as I practiced more and found more efficient research techniques, finding
key articles happened much more frequently and with that came more enjoyment. The skills learned
from this part of the project will surely help me in future projects and in industry, I am pleased to have
discovered these skills and can provide evidence that I can apply them effectively.

33
7.1.3 Personal Evaluation on Designing the Product

Design of this product went on substantially longer than intended, mostly due to lack of commitment
to one specific design as it was difficult to come up with a design which felt right for me and the aims
of the project. There were several designs which did not make it past a brainwave before coming to
the final design idea, and even that wasnt until several meetings with my supervisor. Once the final
design idea had established itself, it was really fun designing how to go about getting to the final
solution. Looking at various methods and techniques for procedural generation was the most fun part
of the project for me personally, followed by actual implementation of these methods.

7.1.4 Personal Evaluation on Implementation Stages

Most of the time spend on the project was for implementation. It took a lot of time to study how to
implement what was desired and a lot of looking at existing examples and guides online to achieve the
final solution. Though fun, it was very exhausting and time consuming and I could not have been
happier to present the build to the testing group and receive their positive feedback. There were a
couple of issues I bumped into during implementation. One of these issues was getting an L-System
working for tree and foliage generation. This was the biggest stumbling block I faced during this stage
of the project and it was one I never managed to overcome and instead opted to choose a different
path for the generation of these accents.

7.1.5 Personal Summary and Further Work

I am happy with the product I have created throughout this project and would be more than happy to
continue working on it and improving it in the future as there are many suggestions and improvements
that people have provided though feedback which I would find fun and challenging to implement.

Personally, I feel that completion of the product has benefitted me with a greater understanding of
how procedural generation can be used in the computer game industry. The methods I researched and
implemented proved to myself that I can apply the methods in an effective way to get the desired
results.

I could see this product leading to a strategy game like the Civilization series. More features would
need to be added to make this possible, such as base building, army management, etc., but the
foundations for this type of game are already present.

Undertaking the project has given me the ability to manage myself. Before this project I hadnt had
the opportunity to commit myself to a long-term project and didnt know an appropriate way to
conduct myself. This project forced me to develop the skills which require me to plan my time around
my other course units, organise what work needed prioritising, seek assistance when required to do so
and solve any issues that would arise in a positive manner.

If I were to undertake this project, or a similar one, again there would be a few changes I would make
in my approach. Such changes would include better time management as to not spend too much time
pondering over specific aspects, as this was something that caused some frustration to me during this
particular project.

34
References

Barnsley, M F. , Rising, H (1993). Fractals Everywhere. Boston: Academic Press Professional.

Black Box Testing (2016). Available: http://softwaretestingfundamentals.com/black-box-testing/. Last accessed

03/02/2017.

Chasm. Available: http://www.chasmgame.com/

Cook, M. (2015a). More Unpredictable Stuff. Available:

http://www.gamasutra.com/blogs/MichaelCook/20151015/256421/More_Unpredictable_Stuff.php. Last
accessed 18/03/2017.

Cook, M. (2015b). Proceedings of the Sixth International Conference on Computational Creativity. London:
University of London. 197-203. Available: http://axon.cs.byu.edu/ICCC2015proceedings/9.1Cook.pdf. Last
accessed 19/11/2016.

CRPG Addict. (2012). Game 79: Beneath Apple Manor (1978). Available:
http://crpgaddict.blogspot.co.uk/2012/12/game-79-beneath-apple-manor-1978.html. Last accessed 05/10/2016.

Davenport, J. (2016). Valve isn't making special exceptions to its refund policy for No Man's Sky. Available:
http://www.pcgamer.com/no-mans-sky-refunds/. Last accessed 10/03/2017.

Diablo Series. Available: http://us.battle.net/d3/en/

Eno, B. (1996). Generative Music "Evolving metaphors, in my opinion, is what artists do. Available:
http://www.inmotionmagazine.com/eno1.html. Last accessed 17/11/2016.

Fingas, J. (2015). Here's how 'Minecraft' creates its gigantic worlds. Available:
https://www.engadget.com/2015/03/04/how-minecraft-worlds-are-made/. Last accessed 22/11/2016.

Flafla2. (2014). Understanding Perlin Noise. Available: http://flafla2.github.io/2014/08/09/perlinnoise.html.

Last accessed 24/11/2016.

gregkwaste. (2016). No Mans Sky Procedural Content. Available:

http://3dgamedevblog.com/wordpress/?p=836. Last accessed 18/10/2016.

Jo Edkins. (2007). Shapes that tessellate. Available: http://gwydir.demon.co.uk/jo/tess/grids.htm. Last accessed

16/12/2016.

Kummer, J. (-). Hexagon Calculator. Available: https://rechneronline.de/pi/hexagon.php. Last accessed

07/04/2017.

Lena LeRay. (2016). Designing Chasm, a procedurally generated Metroidvania. Available:

http://www.gamasutra.com/view/news/282691/Designing_Chasm_a_procedurally_generated_Metroidvania.php
. Last accessed 17/10/2016.

Metroid. Available: http://www.nintendo.com/games/detail/metroid-zero-mission-wii-u

Minecraft. Available: https://minecraft.net/en/

Mojang. (2016). WE'VE SOLD MINECRAFT MANY, MANY TIMES! LOOK!. Available:
https://mojang.com/2016/06/weve-sold-minecraft-many-many-times-look/. Last accessed 22/11/2016.

35
No Mans Sky. Available: http://www.no-mans-sky.com/

Persson, M "Notch". (2011). Terrain generation, Part 1. Available:

http://notch.tumblr.com/post/3746989361/terrain-generation-part-1. Last accessed 20/11/2016.

Peytavie, A., Galin, E., Grosjean, J. and Merillou, S. (2009), Procedural Generation of Rock Piles using
Aperiodic Tiling. Computer Graphics Forum, 28: 18011809. doi:10.1111/j.1467-8659.2009.01557.x Available:
http://onlinelibrary.wiley.com/doi/10.1111/j.1467-8659.2009.01557.x/full. Last accessed 21/11/2016

Plunkett, L. (2016). Civilization V: The Kotaku Re-Review. Available: http://kotaku.com/civilization-v-the-

kotaku-re-review-1763407147. Last accessed 17/03/2017.

Rozenberg, G., Salomaa, A. (1980). The mathematical theory of L systems. New York: Academic Press.

Rozenberg, G., Salomaa, A. (1992). Lindenmayer Systems: Impacts on Theoretical Computer Science,
Computer Graphics, and Developmental Biology. Springer.

Shiffman, D. (2012). Chapter 7. Cellular Automata. Available: http://natureofcode.com/book/chapter-7-cellular-

automata/. Last accessed 18/03/2017.

Tetran. (2010). What is procedural generation and how is it done?. Available:

http://gamedev.stackexchange.com/questions/756/what-is-procedural-generation-and-how-is-it-done. Last
accessed 11/01/2017.

36
Appendix 1 Terms of Reference

Course Specific Learning Outcomes

To study the history of computer games, game genres, game structures and game
design principles and to use the skills acquired to specify and evaluate new game
applications

To become knowledgeable in the use and development of computer graphics

software/game middleware tools and to be able to apply this knowledge to the
implementation of real-time interactive systems

To learn structured approaches to computer programming

To learn how the theories and techniques of behavioural systems can be used to
enhance the playability and sophistication of computer games

To study a range of mathematical tools and techniques and to be able to use these,
in particular, to solve problems in the area of game modelling and animation

To gain an appreciation of the multidisciplinary environment in which commercial

games are designed and produced and to acquire skills in project management and
team working.

37
Project Background

The video game industry practice a large variety of differing computational techniques to
expand and push technology to its limits. A common method, dating back as far as 1978
(Beneath Apple Manor, a roguelike game which predates the genre defining Rogue), has
been to use procedural generation to create game content (CRPG Addict, 2013). This is the
computational method of using algorithms to form various aspects of a game for the user. An
example of a game that uses procedural generation to this effect is Minecraft, which, in
single player, builds a world for the user to explore which is different to any other players.
Although some games use procedural generation to create the whole game, others use the
method as a way of creating a base-layer or parts to build upon, such an example would be
a terrain or forest can be created using an array created using cellular automata.

1.2i How are you going to solve the problem?

What is your approach?

This project will explore the possibilities of a game in which most aspects are generated
procedurally. In this instance the terrain would be randomly generated using a technique,
such as cellular automaton, that would then be used to define the map, e.g. where trees
would go, water, grass, etc. This map would then be used to create a simple game.

1.2ii How will you measure success?

What is vital, and what would constitute a bonus?

Vital for success is a final product which uses some form of procedural generation technique
which creates a world that can be displayed, essentially the generated world would be used
as a baseline of creating the game, however simple the game may be as this project is only
to explore the power of procedural generation within games and not creating a fully
functioning game. Extension to this could be to add some form of control options which
affect how the map is generated, such as having islands, one land mass surrounded by
water, etc.

1.2iii Do other pieces of work similar exist?

What relevance do they have to this project?

Other pieces of work which include successful implementation of procedural generation are
the space exploration game No Mans Sky and the upcoming platformer Chasm.

The game No Mans Sky implements procedural generation in most aspects of the game
such as geometry, colour palettes and animations. Despite its controversial success, in
terms of procedural generation technology it is a massive step up in the field compared to
previous entries, as described by gregkwaste (2016) at 3DGameDevBlog. This shows that
there are still advances to be made in the area and thus shows relevance of the project for
the industry.

Chasm is an upcoming game that employs procedural generation techniques inspired by the
earlier Metroid platform games created by James Petruzzi, being released in 2017. The
game focuses less on total randomness and more about possible variations (Lena LeRay,

38
2016). A project such as Chasm brings to light that successful games from previous
generations can be reinvented using modern techniques.

Aims and Objectives

The primary aim of this project is to;

Investigate the use of procedural generation for the creation of terrain, with an
emphasis on the generation of suitable accents, such as foliage.

Personal aims of the project are;

Gain a greater understanding of procedural generation used within the computer

games industry

Improve/gain new skills in project development and management.

The aims will be met by completing the following objectives;

Identify how existing games use procedural generation

Design algorithms for procedural generation
Compare and contrast designed algorithms
Implement most suitable algorithm for each element
Provide a simple game that explores the game world
Avid testing to ensure integrity of product
Critical evaluation of content created

Problems

There are limited foreseeable issues that this project may face behind generic computer
based system errors (e.g. loss of data, etc.). Therefore, management of these issues mostly
consists of basic file management and data backups. An issue of primary concern, though
still minor, would be the likelihood of procedural generation techniques becoming
unsupported with programming language updates. This is highly unlikely to happen, as
programming languages are usually backwards compatible, however if this does happen to
the primary language (e.g. C#), a secondary language will be used instead (e.g. Java).

39
Timetable and Deliverables

Figure 31. Gantt Chart

40
Deliverable Due Date (Week beginning Monday)

Terms of Reference 17/10/16

Ethics Form 24/10/16

Literature Review 21/11/16

Product Design 12/12/16

Evaluation Design 30/01/17

Report Outline 20/02/17

Draft Slides 06/03/17

Practice Presentation 13/03/17

Report and Product 24/04/17

Table 2. Timetable of Deliverables

41
Appendix 2 Ethics Form

42
43
44
Appendix 3 Participant Information Sheet

45
Appendix 4 Risk Assessment

46
47
Appendix 5 Questionnaire Results

48
49
Appendix 6 Black Box Testing Results

Section/Method Test Input Expected Result Actual Result Comment

Chunk Count X (int) 9 A grid of 9 by Z As expected No comment

hexagons (This number
cannot actually
be altered in the
tech demo and
only when
running the
program in
editor)

(string) test No grid is Crash Fixed a bug

created as no which allowed
valid size is input value of
defined grid size to be
non-integer.

(float) 5.5 No grid as no As expected Previous bug fix

valid size is allowed for all
defined data types other
than integers to
be prevented
from being
entered into grid
size.

(int) -1 No map Error/Crash Added a simple

generation check to see if
grid size in X
direction is <=
0, and if true to
make it 1.
Table 3. Chunk Count X

Chunk Count Z (int) 9 A grid of X by 9 As expected No comment

hexagons (This number
also cannot
actually be
altered in the
tech demo and
only when
running the
program in
editor)

(string) test No grid is Crash Fixed a bug

created as no which allowed
valid size is input value of

50
 defined grid size to be
non integer.

(float) 5.5 No grid as no As expected Previous bug fix

valid size is allowed for all
defined data types other
than integers to
be prevented
from being
entered into grid
size.

(int) -1 No map Error/Crash Same fix used

generation for Chunk Count
X used to fix the
same issues.
Table 4. Chunk Count Z

Section/Method Test Input Expected Result Actual Result Comment

Camera W key Move camera The camera As expected, no

controls forward moves forward issues

Up arrow key Move camera Camera moves As expected, no

forward forward issues

A key Move camera Camera moves As expected, no

left left issues

Left arrow key Move camera The camera As expected, no

left moves left issues

S key Move camera Backwards Does what is

backwards movement of expected
camera

Down arrow key Move camera The camera As expected, no

backwards moves in the issues
backwards
direction

D key Move camera To the right the As expected, no

right camera moves issues

Right arrow key Move camera The camera As expected, no

right goes to the right issues

E key Rotate camera The camera As expected, no

clockwise spins around issues
clockwise

Q key Rotate camera The camera No Comment

counter rotates counter

51
 clockwise clockwise

Mouse wheel Camera zoom If not already at As expected, no

scroll up in, movement of min zoom value, issues
camera slows the camera will
zoom in

Mouse wheel Camera zoom If not at max As expected, no

scroll down out. Movement zoom value, the issues
of camera camera will
speeds up zoom out
Table 5. Camera Controls

Section/Method Test Input Expected Result Actual Result Comment

Command New Map Reloads the A new terrain is As expected,

Buttons on GUI Button scene, generated for the code for this
generating a the user to was simple
new terrain explore enough to not
have any
expected errors
occur

Exit Button Quits the The application As expected,

application exits nothing to
comment
Table 6. Command Buttons on GUI

Smoothing (int) any positive The smoothing As expected No comment

Algorithm - integer algorithm
Smoothing repeats inputted
cycles times

(float) any float Will not As expected This will never

value complete a actually be an
cycle as the issue when
data types do using the
not match technical demo
as the
smoothing
cycles value is
fixed and
cannot be
altered unless in
editor.
Table 7. Smoothing Algorithm - Smoothing Cycles

52