Full Text 02

Bachelor of Science in Digital Game Development
June 2018
Evaluation of the Complexity of

Procedurally Generated Maze
Algorithms
Albin Karlsson
Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, Sweden

This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial
fulfillment of the requirements for the degree of Bachelor of Science in Digital Game Development.
The thesis is equivalent to 10 weeks of full time studies.
The authors declare that they are the sole authors of this thesis and that they have not used
any sources other than those listed in the bibliography and identified as references. They further
declare that they have not submitted this thesis at any other institution to obtain a degree.
Contact Information:
Albin Karlsson
E-mail: alkf14@student.bth.se
University advisor:
M.Sc Diego Navarro
Department of Creative Technologies
Faculty of Computing Internet : www.bth.se

Blekinge Institute of Technology Phone : +46 455 38 50 00
SE–371 79 Karlskrona, Sweden Fax : +46 455 38 50 57
Abstract
Background. Procedural Content Generation (PCG) in Video Games can be used

as a tool for efficiently producing large varieties of new content using less manpower,
making it ideal for smaller teams of developers who wants to compete with games
made by larger teams. One particular facet of PCG is the generation of mazes. De-
signers that want their game to feature mazes also need to know how to evaluate
their maze-complexity, in order to know which maze fits the difficulty curve best.
Objectives. This project aims to investigate the difference in complexity between
the maze generation algorithms recursive backtracker (RecBack), Prim’s algorithm
(Prims), and recursive division (RecDiv), in terms completion time, when solved
using a depth-first-search (DFS) algorithm. And in order to understand which pa-
rameters affect completion time/complexity, investigate possible connections between
completion time, and the distribution of branching paths, distribution of corridors,
and length of the path traversed by DFS.
Methods. The main methodology was an implementation in the form of a C# ap-
plication, which randomly generated 100 mazes for each algorithm for five different
maze grid resolutions (16x16, 32x32, 64x64, 128x128, 256x256). Each one of the
generated mazes was solved using a DFS algorithm, whose traversed nodes, solving
path, and completion time was recorded. Additionally, branch distribution and cor-
ridor distribution data was gathered for each generated maze.
Results. The initial results showed that mazes generated by Prims algorithm had
the lowest complexity (shortest completion time), the shortest solving path, the low-
est amount of traversed nodes, and the lowest proportion of 2-branches, but the
highest proportion of all other branch types. Additionally Prims had the highest
proportion of 4-6 length paths, but the lowest proportion of 2 and 3 length paths.
Later mazes generated by RecDiv had intermediate complexity, intermediate solv-
ing path, intermediate traversed nodes, intermediate proportion of all branch types,
and the highest proportion of 2-length paths, but the lowest proportion of 4-6 length
paths.
Finally mazes generated by RecBack had opposite statistics from Prims: the
highest complexity, the longest solving path, the highest amount of traversed nodes,
the highest proportion of 2-branches, but lowest proportion of all other branch types,
and the highest proportion of 3-length paths, but the lowest of 2-length paths.
Conclusions. Prims algorithm had the lowest complexity, RecDiv intermediate
complexity, and RecBack the highest complexity. Increased solving path length,
traversed nodes, and increased proportions of 2-branches, seem to correlate with
increased complexity. However the corridor distribution results are too small and
diverse to identify a pattern affecting completion time. However the corridor dis-
tribution results are too diverse to make it possible to discern a pattern affecting
completion time by just observing the data.
Keywords: PCG, Mazes, Labyrinth, Recursive Backtracker, Recursive Division,

Prims Algorithm, Randomized Prims Algorithm, Depth-first-search, Game
Acknowledgments
I would like to thank my supervisor, M. Sc Diego Navarro for his clear, to-the-point,
actionable advice. Without him, this thesis would probably be a mess. I would also
like to thank my fellow students sitting in the computer lab for being such good
company, they helped making the weeks of writing and coding a blast.
iii
Contents
Abstract i
Acknowledgments iii
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Thesis Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 5
2.1 Theoretical Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Spanning Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Weighted Graph . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 Greedy Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.5 Procedural Content Generation . . . . . . . . . . . . . . . . . 6
2.1.6 Perfect Maze . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.7 Randomized Prim’s Algorithm . . . . . . . . . . . . . . . . . . 7
2.1.8 Recursive Backtracker / Depth-First-Search Algorithm . . . . 8
2.1.9 Recursive Division Algorithm . . . . . . . . . . . . . . . . . . 8
2.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Method 13
3.1 Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 DFS Solver and Completion Time . . . . . . . . . . . . . . . . . . . . 14
3.4 Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Path Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Corridor Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 Experiment Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Results 17
4.1 Maze Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Completion Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Path Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Corridor Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Branch Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
v
5 Analysis and Discussion 29
5.1 Completion Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Branches, Path Length, and Corridors Effect On Completion Time . . 31
5.2.1 Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.2 Path Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.3 Corridors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6 Conclusions and Future Work 35

6.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A Maze Generation Algorithms 39

A.1 Prim’s Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2 Randomized Prim’s Algorithm . . . . . . . . . . . . . . . . . . . . . . 39
A.3 Recursive Backtracker Algorithm . . . . . . . . . . . . . . . . . . . . 40
A.4 Recursive Division Algorithm . . . . . . . . . . . . . . . . . . . . . . 40
B Code Examples 41
B.1 Recursive Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.2 Recursive Backtracker Code . . . . . . . . . . . . . . . . . . . . . . . 43
B.3 Recursive Division Code . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.4 Randomized Prim’s Algorithm Code . . . . . . . . . . . . . . . . . . 46
B.5 Depth-first-search Algorithm Code . . . . . . . . . . . . . . . . . . . 49
vi
Chapter 1
Introduction
Computer games are one of the fastest growing mediums today, with a large amount
of players spending many hours immersed in digital worlds filled with novel content.
So far handcrafted content has been able to keep up with the rising production costs
and expectations of players, but if costs and expectations keeps rising it may become
unsustainable1 . Procedural Content Generation (PCG) holds the potential to fix this.
PCG can aid developers with creating more novel content, faster, while saving man-
hours. It typically does this by either automatically generating content to directly
be used by the player, or as a creative aid for developers who ultimately chooses the
generated content to be used. The challenge with PCG is defining the parameters
by which content is generated that satisfies both developers and players(Shaker,
Togelius, & Nelson, 2016). One specific usage of PCG is the generation of mazes.
Mazes are useful for both level design and game design as a piece of content that
can simultaneously be used as a "physical" element of a level, and a puzzle for
the player. They are well-suited for PCG since the end result is relatively easy to
express algorithmically: a start point, an end point, and a series of puzzling sprawling
interconnected paths between them. Some examples of games featuring mazes are
the classic Pac-man, and roguelikes such as Hauberk2 , a game developed by Bob
Nystrom3 , the author of Game Programming Patterns4 .
1.1 Motivation
Game Designers want to craft a good difficulty curve for their players. If they want
mazes in their game, and if it turns out that different maze algorithms generate mazes
of different complexity, the designer would want to know which maze algorithm fits
the difficulty curve best. When a designer is short on time, like when producing
prototypes, it is useful to know the complexity level of mazes to quickly be able to
pick a suitably complex maze algorithm.
Previous research made by Kim et. al (Kim & Crawfis, 2015) proposed a frame-
work for a maze generation tool that could perhaps be improved by incorporating the
1
Steve Thodore, Why have video game budgets skyrocketed in recent years?,
https://www.quora.com/Why-have-video-game-budgets-skyrocketed-in-recent-years (accessed
11-04-2018)
2
Bob Nystrom, Hauberk, https://github.com/munificent/hauberk (accessed 31-05-2018)
3
Bob Nystrom, Rooms and Mazes: A Procedural Dungeon Generator,
http://journal.stuffwithstuff.com/2014/12/21/rooms-and-mazes/ (accessed 31-05-2018)
4
Robert (Bob) Nystrom, Game Programming Patterns, http://gameprogrammingpatterns.com/
(accessed 31-05-2018)
1
2 Chapter 1. Introduction
results of an investigation of parameters affecting completion time. This improve-

ment could in turn aid developers in generating custom mazes.
Therefore this thesis aims to evaluate the complexity of different maze generation
algorithms in terms of maze-completion time, and to understand what parameters
control maze-completion time by investigating the distribution of corridors, solving
path length, and branching paths in the maze. Note that it is complexity, not
difficulty that is investigated, this is because difficulty is relative and hard to pin
down in a variable, while complexity in terms of completion-time is very specific.
Three PCG maze generation algorithms will be explored; Recursive backtracker
(RecBack), Prim’s algorithm (Prims), and recursive division (RecDiv). They were
chosen since they had been used in previous research by Foltin (Foltin, 2008), Kozlova
et. al (Kozlova, Brown, & Reading, 2015), and Kim et. al (Kim & Crawfis, 2015),
and because they offer a low implementation complexity with fast generation results,
allowing iterative testing to be performed.
During the literature review on the topic of PCG Maze algorithms, it was chal-
lenging to find formal sources that uses RecBack, RecDiv and/or Prims in a similar
context, many scientific papers on the subject almost solely rely on online sources for
reference on maze generation algorithms(ex: (Foltin, 2008), (Kozlova et al., 2015),
(Bae, Kim, Lee, Kim, & Na, 2015), (Kim & Crawfis, 2015). This situation offers the
opportunity to contribute to this area of research.
1.2 Research Questions

• RQ1: What is the difference in complexity between the maze generation al-
gorithms recursive backtracker (RecBack), Prim’s algorithm (Prims), and re-
cursive division (RecDiv), in terms of completion time, when solved using a
depth-first-search (DFS) algorithm?
• RQ2: What connection is there between completion time/complexity, and the

distribution of branching paths, corridors, and length of the path traversed by
the DFS?
Path length is explored because previous contributions by Kozlova et. al (Kozlova

et al., 2015) and Foltin(Foltin, 2008) uses it as a parameter for evaluation.
Completion time is explored both because the author hypothesizes that it could be
a good metric for complexity, and since Foltin(Foltin, 2008) uses a similar parameter
(albeit he uses human test subjects to solve mazes).
In addition, corridor distribution and branches are explored because the author
observes it can be a potential feature that could affect completion time.
1.3 Thesis Layout

This thesis consists of 6 chapters; Introduction, Background, Method, Results, Anal-
ysis and Discussion, Conclusions and Future Work, Appendix A and B. Background
contains the related work and theoretical background sections, which offers a com-
prehensive overview of maze algorithms, graph theory, and similar research. Method
1.3. Thesis Layout 3
presents the tools used for the implementation, explains what is measured, and
presents the experiment procedure. Results presents and explains the gathered data,
and exposes patterns discovered in the data. Analysis and Discussion discusses the
gathered data and patterns found in it. Conclusions and Future work uses some of
the found patterns to answer RQ1 and RQ2, and gives suggestions to keep exploring
the field of PCG Maze research. Appendix A presents pseudo-code for the maze
generation algorithms. Appendix B presents code used in the implementation used
in this study.
Chapter 2
Background
This chapter will provide the theoretical background needed for the maze algorithms,
as well as present related work in this field.
2.1 Theoretical Background

The PCG maze algorithms used in this thesis relies on graph theory as their foun-
dation. This section will present the necessary concepts.
2.1.1 Graph
The graph is one of the pillars of graph theory. A graph consists of a vertex set, an
edge set, and a mapping function called relation of incidence. This function states
that each edge has two vertices. Another graph-attribute is connectivity which is
used to distinguish between connected and disconnected graphs. In a connected
graph all vertices are connected, which means that there is a path (unbroken chain
of edges) between all pairs of vertices(Foltin, 2008). Graphs are visualized in Figure
2.1.
Graph Illustration
(a) (b)
Figure 2.1: Red dots are vertices, black lines are edges. (a) displays a disconnected
graph, where vertex 1 is not connected to the other vertices (i.e a broken chain). (b)
displays a connected graph, where all vertices are connected by an unbroken chain
of edges.
5
6 Chapter 2. Background
2.1.2 Spanning Tree

A tree in graph theory is a connected graph with no cycles(Gross, Yellen, & Zhang,
2014), a cycle being defined by Black as "A path that starts and ends at the same
vertex and includes at least one edge."(E. Black, 2017)1 . A tree is considered a
spanning tree when it includes all the graph vertices ("spans" across all vertices)
(Foltin, 2008, p.13).
2.1.3 Weighted Graph

A weighted graph has a weight associated with each edge (E. Black, 2003). A common
use of weight is having it represent the length of the edge. For instance classical
Prim’s algorithm searches for the minimum(-weight) spanning tree in a weighed
graph where weight represents edge length(E. Black, 2014).
2.1.4 Greedy Algorithm

A greedy algorithm takes the best local solution while finding an answer. The final
answer might not always be the most optimal solution, but the strength of a greedy
algorithm is that it finds a solution quickly (E. Black, 2005).
2.1.5 Procedural Content Generation

PCG is used in several games, and has many uses. Some examples of contemporary
use is to algorithmically generate game content like the loot drops in Action Role
Playing Games (ARPGs)2 , or nearly infinite voxel levels like in Minecraft 3 .
There are three different ways to procedurally generate content according to To-
gelius et. al: constructive, search based, and simple generate-and-test, where con-
structive PCG techniques generates all content in one pass. This thesis will focus
on constructive methods, since they are not as complex to implement, and generally
fast, enabling generation during runtime, providing faster iteration speeds compared
to other PCG approaches (Togelius, Yannakakis, Stanley, & Browne, 2011).
A type of content particularly well suited to procedural generation is mazes.
This is because procedural maze algorithms can generate large varieties of differ-
ent types of mazes without sacrificing quality(Kozlova et al., 2015). Three widely
known maze generation algorithms are randomized Prim’s algorithm (Prims) (Foltin,
2008)(Buck & Carter, 2015) based on Prim’s Algorithm(Prim, 1957), Recursive Divi-
sion algorithm (RecDiv ) (Kozlova et al., 2015)(Buck & Carter, 2015), and Recursive
Backtracker (RecBack ) (Foltin, 2008)(Buck & Carter, 2015) based on the depth-
first-search technique (Gross et al., 2014) (Kozlova et al., 2015). Each algorithm
produces perfect mazes, and they either produce mazes by wall adding or passage
carving. RecDiv is an example of a wall adder, while randomzied Prim’s (referred to
simply as Prims for convenience) algorithm can be made to do either(Foltin, 2008).
1
If drawn on paper, it’s edges would form a cyclical, or "round" pattern.
2
Example of a popular ARPG: Blizzard Entertainment, Diablo 3, http://us.blizzard.com/en-
us/games/d3/ (accessed 11-04-2018)
3
Mojang, Minecraft, https://minecraft.net/en-us/ (accessed 11-04-2018)
2.1. Theoretical Background 7
Both RecDiv and Prims are graph based maze algorithms. Essentially graph based
algorithms create mazes by constructing a spanning tree.
2.1.6 Perfect Maze

A perfect maze is, according to Kim et. al, comprised of a spanning tree graph, a
start location, and an end location(Kim & Crawfis, 2015).
2.1.7 Randomized Prim’s Algorithm

Prim’s algorithm is a greedy algorithm that finds a minimum-length spanning tree
in a weighted graph(Gross et al., 2014). The randomized version of Prim’s algorithm
does not need a weighted graph, since instead of it choosing the node with least
weight, it is made to instead choose a random node. See Appendix A.1 for pseudocode
of Prim’s algorithm.
Prim’s algorithm in its original form is not usable as a means to generate random
mazes since it lacks a random factor. In Prim’s algorithm the weight is what deter-
mines the frontier edge (see step 4b in Appendix A.1), so therefore it will be replaced
by a random factor as seen in the pseudocode for Randomized Prim’s Algorithm in
Appendix A.2.
See Figure 2.2 for illustration of Randomized Prim’s Algorithm maze creation.
Randomized Prims Algorithm
Figure 2.2: Randomized Prim’s algorithm

example. This algorithm requires only two
data set structures of storing cells: a set of
in-cells (grey color), and a set of frontier
cells (yellow color).
2.1.8 Recursive Backtracker / Depth-First-Search Algorithm
The Recursive Backtracker algorithm is based on the depth-first-search (DFS) al-

gorithm widely used in computer science (Foltin, 2008)(Gross et al., 2014)(Joshi,
2017). A DFS visits all vertices of a graph. Initially all vertices are marked new,
when a vertex is visited it is marked old. Depth first search explores the graph by
visiting a new -marked vertex, and then recursively call itself on all of the vertex’s
adjacent new -marked vertices(Gross et al., 2014). When a DFS cannot find any adja-
cent new -marked vertex, the algorithm "backtracks" up the recursive call chain until
it finds a vertex that has adjacent new -marked vertices, this process repeats itself
until all vertices in the graph has been visited. See Appendix A.3 for pseudocode
of the Recursive Backtracker algorithm. See Figure 2.3 for illustration of Recursive
Backtracker maze generation.
Recursive Backtracker Algorithm
Figure 2.3: Recursive Backtracker algo-

rithm example. Yellow points depict cells
where the new walk started from.
2.1.9 Recursive Division Algorithm
Recursive backtracker and Prim’s algorithm are graph-based.
Recursive Division algorithm treats the maze as a fractal - a repeating pattern

whose component parts are similar to the whole. It splits the grid into two sub-
grids, putting a wall between them and a single opening in it, linking the sub-grids
together, and then recursively repeats this process until the desired resolution has
been produced. In the end a maze has been created(Buck & Carter, 2015). The frac-
tal nature of the algorithm gives it the ability to potentially make infinitely complex
mazes. See Appendix A.4 for pseudo-code of the Recursive Division algorithm.
2.2. Related Work 9
Recursive Division Algorithm
Figure 2.4: Recursive Division algorithm

step by step. Step 1 divides the grid into
two subgrids, 2 adds a passage, then the
same process repeats in 3 to 4, recursively
until the desired resolution is met.
2.2 Related Work

Kozlova et. al investigates the path length of three two-dimensional mazes generated
by Prim’s algorithm, the Depth First Search algorithm (DFS), and the Recursive
Division algorithm. The purpose behind this is to better understand the expressive
control and ability of the different maze algorithms. Generating mazes on a 16x11
grid, they found that that DFS generally generated the longest paths, followed by
Recursive Division, and last Prims. Using a parwise two tailed t-test they also found
that the differences between the means was statistically significant. In their conclu-
sion they advise using the DFS algorithm as a base for new maze representations,
since it generates long hallways(Kozlova et al., 2015). Two things were found un-
clear; they never explicitly say what a path is, or how it is measured, or why they go
by the assumption that long hallways is a good feature of a maze. A guess is that
they define a path as a possible solution path, and the length as number of traversed
nodes. They mention long hallways in passing "[...] produces mazes that have long
and winding passes, which seems to be a good feature for a maze." they they cite
Ashlock et. al. that wrote a paper investigating search-based procedural generation
of mazes(Ashlock, Lee, & McGuinness, 2011). Ashlock et. al never explicitly state
that long hallways is a good feature of mazes, they merely say that some fitness
functions favor long, winding paths. Kozlova et. al probably took this statement
and assumed that a fitness-function favoring a certain type of result means that that
result is inherently better. This is not necessarily the case, since they could just as
well have used a fitness function favoring short paths.
Foltin made an exploratory study of human interaction with mazes. He made an

implementation in the form of a Java applet that participants used to solve mazes
pre-generated by the Randomized Prim’s Algorithm, Randomized Kruskal’s algo-
rithm, Hunt and Kill algorithm, and Recursive Backtracker. He measured successful
attempts (SA), successful attempts count (SAC), average solution time (AST), to-
tal time (TT), solution path (SP), shortest solution path (SSP), average number of
moves (ANM), and minimum number of moves (MNM). Users of the applet were
awarded "competition points" when finishing mazes to incentivize users to use the
app. Foltin states that this point system likely drew players toward completing quick-
to-solve mazes to gain the maximum amount of points. The results of the randomized
mazes statistics implied that users heavily tilted towards finishing mazes with the
lowest amount of ANM and AST of point-awarding mazes. The most popular maze
to solve, with the lowest AST and ANM but by far highest SAC was Randomized
Prim’s, and the least popular maze to solve was Recursive Backtracker (even though
it did not have the highest AST or ANM). He measured something he called "got
lost ratio", which expresses how many unnecessary moves a human took in the maze.
Kim et. al (Kim & Crawfis, 2015) proposed a search-based framework for gener-
ating perfect mazes, with the purpose of giving the designer a tool for finding the
"best" perfect maze, where "best" is up to the subjective opinion of the designer to
decide. What drives a search-based system is a fitness function. A fitness function
takes a set of user-determined variables as input, and then outputs a fitness num-
ber. The fitness function is run through a search-space (a list of sample content)
where it samples fitness variables, and then the sample that outputs the highest
fitness-number "wins", and it gets selected as output content.
They used several variables as inputs to the evaluation function. Of note is that
they had defined several types of dead-ends, and useful concepts such as decision cell
that refers to cells with more than two passages connected to it, which might also be
conceptualized as "branches". The variables used in the proposed framework were:
Metrics Per Spanning Tree:
• Number of cells
• Number of edges
• Percentage of junctions
• Percentage of crossroads
It is somewhat unclear how an edge is recorded, however one could make the
assumption that it is the number of nodes in each edge of the grid. A junction is
decision-cell with three paths connected to it, which means it has just one wall, while
a crossroad is a decision-cell with four paths connected to it, meaning it has no walls.
The percentage of junctions and crossroads is relative to the total number of nodes
in the grid.
Metrics per solution path:
2.2. Related Work 11
• Percentage of dead-ends
• Percentage of alcoves
• Percentage of forward dead-ends
• Percentage of backward dead-ends
• Percentage of turns on the solution path
• Percentage of junctions on the solution path
• Percentage of cross roads on the solution path
• Percentage of decisions on the solution path
• Relative length of the solution path
An alcove is a dead-end with no turns or decisions. It has a straight short path.

A forward dead-end looks like it is progressing towards the end-point, or continues
straight from the solution path. A backward dead-end turns away from the solution
path and away from the end point.
The search-space was created by generating several mazes with either the ran-
domized recursive backtracker or the randomized Prim’s algorithm.
Chapter 3
Method
An implementation will be used as the method to experimentally evaluate RQ1 and

RQ2.
The selected maze algorithms must be able to fulfill these constraints before they
can be used:
• Perfect maze.
• Two dimensional.
• Follows rectangular grid; the depth-first-search algorithm will follow a grid,

hence the maze needs to follow the same grid to become navigable by the
depth-first-search.
• Controllable entrance / exit; possibility to intentionally set the entrance and

exit coordinates of the generated maze.
• Solvable; the exit must be reachable from the entrance
• Determinism; possibility to intentionally generate the exact same maze. So

that experiment conditions can be replicated with the possibility to perhaps
try different maze generation algorithms than those used in this experiment.
Using a pseudo-random generator taking a seed-number as input is a method
of achieving replicable "randomness".
The algorithms will generate mazes of different resolutions; 16x16, 32x32, 64x64,
128x128, 256x256. Those resolutions are chosen to see how an exponential increase in
maze size affects the overall results of the test. Initial testing showed that resolutions
exponentially higher than 256x256 were not possible due to memory limitations.
This implementation allocated the resources for the algorithms in the RAM memory,
and when trying resolutions higher than 256x256 (specifically tested 512x512), the
memory offered by the testing machine (16 GB) was not enough. The resolutions
are symmetrical in both axis to remove its ability to affect testing results.
3.1 Development Tools

The test itself does not need a graphical representation, however it is useful for
debugging purposes as a means to visually verify that the maze algorithms produce
the intended results. The maze is visualized in 3D, by spawning and placing simple
13
14 Chapter 3. Method
3D models where the maze has walls, on the traversed path, and on the solving path.
It is visualized in 3D because of author preference and familiarity. The game engine
Unity (version 2017.4.1f1) 1 is used as the development environment since it offers a
convenient way to spawn 3D-models from code, and good integration with C#. No
visualizations of the mazes are generated for the main test in order to avoid making
the visualization a potential factor that could affect the final results.
The code written for this thesis is written in C# 2 since it is an interpreted script-
ing language with no compile times, which helps improve implementation speed. The
IDE used for writing the code was Microsoft Visual Studio Professional 2017. The
3D-models used for the 3D visualization of the maze were produced using Autodesk
Maya 2017.
3.2 Implementation Details

The algorithms were implemented to execute using a single CPU thread, because the
author prefers this type of architecture. The speed of the test is not prioritized, the
accuracy of the test is.
Several of the maze algorithms (RecBack & Prims) had to be modified so that
they do not overload the computer’s stack, causing the "stack overflow" error3 . The
depth-first-search algorithm used for solving the mazes also needed this modification.
This slowed down the maze solver, but since it is a common parameter across all
maze algorithms, this should not affect the overall results. The modification itself is
accomplished by simulating the recursivity with the use of the C# "Stack" container
class, a data-type for storing the state of the node, and a while-loop. Example code
can be found in Appendix B.1.
The complete source code for the unity project can be accessed at the author’s
GitHub 4 .
The source code for the recursive backtracker algorithm can be found in Ap-
pendix B.2, the recursive division algorithm in Appendix B.3, and Prim’s algorithm
in Appendix B.4.
3.3 DFS Solver and Completion Time

The mazes will be solved using a depth first search, since the author thinks it
might simulate how a human would traverse the maze better than A*, Dijkstra’s,
or breadth-first search. The reasoning behind this is based on the hypothesis that a
person would walk down a path until either the exit, or a dead end is reached. If a
dead end is reached, a person would walk back and try an untried path, and repeat
this process until the end is reached. DFS simulates this behavior, but it does not
1
Unity Technologies, Unity3D, https://unity3d.com/ (accessed 27-04-2018)
2
Maira Wenzel et. al, Introduction to the C# Language and the .NET Framework,
https://docs.microsoft.com/en-us/dotnet/csharp/getting-started/introduction-to-the-csharp-
language-and-the-net-framework/
3
PVS-Studio, Stack Overflow, https://www.viva64.com/en/t/0087/ (accessed 01-05-2018)
4
GitHub, Procedural-Maze-Generation, (https://github.com/Manspear/Procedural-Maze-
Generation/tree/master/Procedural_Maze_Generation/) (accessed 01-05-2018)
3.4. Branches 15
take into account some other aspects of "human" pathfinding, such as an imperfect
memory, or cognitive biases about which path gets chosen. Despite this, DFS should
suffice for the purposes of this thesis.
The completion time statistic will be recorded as the time it takes for the DFS
Solver to find a path to the end of the maze. Specifically it is the time between the
start of the execution of the solver, and the point where the end of the maze has
been reached. If instead the final time is calculated as the time between the start
of the execution, and the end of the execution, the resulting completion time could
increase significantly. This would be the case if the DFS was recursive, since then
it would have to go back up in the recursive tree until the "root" function call is
reached, where each function return would take additional time. However ever since
the DFS implementation was re-factored to no longer be recursive this is no longer
the case, making this saving of completion time somewhat redundant.
Delta-time will be recorded in milliseconds.
The source code for the depth-first solver can be found in Appendix B.5.
3.4 Branches
A branch is defined by the number of neighboring path-nodes, where the maximum
amount of branches is determined by the number of allowed path neighbors. In a grid
where only orthogonal paths are allowed, a branch can at max have 4 neighbours,
whereas if vertical paths are allowed a branch can have at max 8 neighbors. However
the minimum amount of neighbours for a branch to be considered a branch is always
1. The grid used in this thesis only allows orthogonal paths, so a branch can only
have 4 neighbours. Branches will be recorded per maze-node of a generated maze,
which means that the total number of branches will be the same as the total number
of nodes in the maze which is the same as the maze resolution (ex. 16x16 = 256).
Examples of branches are found in Figure 3.1. Branches as defined here are similar
to the "decision cells" used by Kim et. al (Kim & Crawfis, 2015). They define a
decision cell as "A cell in which there are more than two passages connected to it.",
which would make the 3 and 4 branches decision cells. However they do not explicitly
measure 2-branches/paths, and they do not measure dead ends in the same way as
1-branches, since they also measure the path leading up to the dead end.
Definition of Branches
Figure 3.1: Shows how branches are de-

fined. A shows 1 branch, which is a dead
end. B shows 2 branches, which is a nor-
mal path / corridor / road. C shows 3
branches, which is a fork. D shows 4
branches, which is a crossroad.
16 Chapter 3. Method
3.5 Path Length

Solving path length is the number of nodes in the found path to the exit. Traversed
nodes is the total number of nodes that were visited (including the solving path
length). In the code path length data is recorded by the solver.
3.6 Corridor Distribution

Corridor length will be measured as "the number of nodes in a straight chain of
nodes", see Figure 3.2 for an illustration of this definition.
Definition of Corridor Length
Figure 3.2: Shows how corridor length will

be calculated. Green rectangles encloses
corridors of length 2. Blue rectangle en-
closes corridors of length 3. Red rectangle
encloses corridors of length 6.
3.7 Experiment Procedure

1. A computer with the following specifications was used:
• Processor: Intel Xeon E5 1620 V3 3.5 GHz 10MB
• Graphics Card: NVIDIA GeForce GTX 1080
• Hard Drive: SK Hynix SC308 SATA 512GB Solid State Drive
• RAM: 16 GB DDR4
• OS: 64-bit Windows 10 Education
2. For each maze algorithm:
(a) Make sure no interfering background processes are run on the testing
computer. Do this by shutting down any major applications such as web
browsers using the windows task manager.
(b) Generate 100 mazes for each grid resolution.
(c) Solve them one at a time using the depth-first-search algorithm, auto-
matically gather the completion time, path-length, corridor distribution,
and branch distribution, and write them to a Comma-separated values-file
(file-extension .csv).
3. Pass the CSV-file into Excel for statistical analysis to answer RQ1 and RQ2.
Chapter 4
Results
All data tables presented are part of the same data set, which have been split up
into the three component parts; path length, corridor distribution, and branch dis-
tribution. Each will be presented separately, and is an average of the raw data from
100 tests per resolution per maze algorithm.
4.1 Maze Appearance
Figures 4.1a, 4.1b , and 4.1c shows representative solutions obtained by the different
maze algorithms. Several things stand out when observing the maze solutions:
• The maze walls of RecDivs look orderly, like squares stacked next to each other.
This is an effect of the recursive nature of the algorithm, since it does actually
divide the maze grid into several "boxes".
• RecBacks solution path covers much of the maze, it is also the maze algorithm
with the longest solving path. Its solution path is more winding compared to
the other algorithms.
• Prims solution path almost goes straight to the goal, it is also the maze algo-
rithms with the shortest solving path.
17
18 Chapter 4. Results
Generated Mazes Representative of Each Algorithm
(a) (b)
(c)
Figure 4.1: 32x32 mazes generated by the algorithms. (a) displays a maze generated
by RecBack, (b) shows a maze generated by RecDiv, (c) illustrates a maze generated
by Prims. Green nodes are part of the solution path, while red nodes are paths that
lead to dead ends. Bottom left is the start/entrance of the maze solver, top right is
the goal/exit.
4.2 Completion Time

Table 4.1 and Figure 4.3 shows an overview of the completion times. Figures 4.2a,
4.2b, 4.2c, 4.2d, and 4.2e graphically illustrates the completion times, which exposes
these patterns:
• At resolution 16x16: RecDiv has the longest completion time, RecBack has
intermediate completion time, and Prims has the shortest completion time.
• At all other resolutions: RecBack has the longest completion time, RecDiv has
intermediate completion time, and Prims has the shortest completion time.
4.2. Completion Time 19
Comparison of Completion Time By Resolution

g ( )
12.5
Overview 2of
3 Length
4 Branches Completion
Corridor(%)
(%)
Branches (%) Time
26.5 16x16
6 Length Completion
Corridor (%) Time 32x32
4 Length Completion
Corridor (%) Time
7000
712 90
26
80
3.5 52 Length
Length Corridor
Corridor (%)
(%) 12.5
Overview 2of
3 Length
Corridor(%)
(%)
Branches (%) Time
6 0.7 4 16x16
6 Length Completion Time
Percent (%)
11.5
6000 25.5
70
3 759 7000712
26.5 Corridor (%)
Percent (%)
5 90
25 52 Length
Length Corridor
Corridor (%)
(%)
Percent (%)
(%)(%)
11 60 58 3.56 26
5000 0.6
2.5 6 80
3.5
milliseconds
4 0.7
Percent (%)
24.5
50 57 11.5
6000 25.5
Percent
10.5 70 759
556 3
Percent (%)
4000
3 2
40
24 3511 25
Percent (%)
16x16 Percent
Percent (%)
(%)(%)
0.530 55 5000 0.6
60
6
58
210 2.5
milliseconds
23.5
1.5 454 4
milliseconds
milliseconds
Maze
yMaze
Maze Type
Ty TypeTime
Type
Solving SolvingTime
Solving Time 24.5
50 57
Percent
3000 20 2.5
10.5 556
9.5 0.423
1 353 RecBack
R RecBack
Maze Type Solving3.98
RecBack 26.11
Time 297.30
40003 2
40
24
Percent (%)
1
16x16 Percent
10 52 RecBack RecDiv
RecDiv 1,347.47 15.24
2.97 71.50
0.530 55
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
2000 22.5 RecDiv
R 2210 23.5
1.5 454
milliseconds
0 0.50 251 Maze
yMaze
Maze Type
Ty TypeTime
Type
Solving SolvingTime
Solving Time
Prims
RecDivPrims 9.17
86.73 42.49 3000
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
Prims
P 1.99 20
0.3 0 150 23 353 RecBack
Maze Type Solving3.98 26.11
Time 297.30
64x64
RecBack
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
256x256
16x16
32x32
64x64
64x64128x128
128x128256x256
16x16
16x16 32x32
32x32 64x64
128x128
256x256
16x16
64x64
128x128
256x256
32x32
1000 49
Prims 41.47 9.5
1.51 0.410
1
52
R
RecBack
RecBack RecDiv
RecDiv 1,347.47 15.24
2.97 71.50
256x256
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
22.5 R
RecDiv
16x16
32x32
64x64
128x128
256x256
16x16 16x16
32x32
64x64
128x128
128x128256x256
16x16
32x32
64x64
32x32128x128
256x256
048
RecDiv RecBack Prims
20000 0.50 251
Prims
RecDivPrims 9.17
86.73 42.49
0.2
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
P
Prims 1.99
0 0.3 0
16x16
32x32
64x64
256x256
128x128
256x256
16x16
32x32
64x64
128x128
256x256
150
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
1
64x64
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
256x256
16x16
32x32
64x64
64x64128x128
128x128256x256
256x256 16x16
16x16 32x32
32x32 64x64
128x128
256x256
16x16
64x64
128x128
256x256
32x32
RecDiv RecBack Prims Prims 41.47
RecDiv RecDiv RecBack RecBack Prims Prims 1000 49
16x16
32x32
64x64
128x128
256x256
32x32
64x64
256x256
16x16
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16 16x16
32x32
64x64
128x128
128x128256x256
16x16
32x32
64x64
32x32128x128
256x256
0.1 RecDiv RecBack Prims 0.5 048
0.2 RecDiv RecBack Prims
0
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
RecDiv
RecDiv RecBack
RecBack Prims
Prims RecDiv RecDiv RecBack RecBack Prims Prims
16x16
32x32
64x64
128x128
32x32
64x64
256x256
128x128
256x256
16x16
64x64
256x256
0 0 0.1 RecDiv RecBack Prims
16x16
RecursiveDivision 16x16
RecursiveBacktracker Prims 16x16 32x32 RecDiv
32x32
RecBack
32x32
Prims
0
RecursiveDivision RecursiveBacktracker Prims RecursiveDivision RecursiveBacktracker Prims
16x16
RecursiveBacktracker Prims 16x16
(a) (b)
32x32 Completion Time 32x32
4 Length Completion
Corridor (%) Time
4 Length
Overview
Corridor (%) Overview 2of
3 Length
64x64 Completion
Corridor(%)
Completion(%) Time
Time
2of Completion Time
3 Length Corridor(%)
(%) 12.5 4 Branches (%)
Branches
12.5 64x64
(%)
Branches Time 4 26.5 128x128
16x16 Completion
Corridor (%) Time
6 Length Completion Time
4
7000712
26.5
90
16x16 Completion
6 Length Corridor (%) Time 7000712
25
90
26 52 Length
Length Corridor
Corridor (%)
(%)
3.5300 80
3.5
3.56 25 26 52 Length
Length Corridor
Corridor (%)
(%) 6 0.7
milliseconds Percent (%)

80
3.5 11.5
6000 25.5
0.7 70
Percent (%)
11.5
6000 25.5 3 759
Percent (%)
70 759 3511 25
Percent (%)
(%)(%)
3 60
Percent (%)
3511 58
25 50004 20
250 0.6 6
Percent (%)
(%)(%)
2.5
milliseconds
60 58
milliseconds
5000 24.5
50 57
4 20 0.6 6
Percent
2.5 2.5
milliseconds
milliseconds
24.5
50 57 10.5 556
Percent
2.5
10.5 40003 2
40
24
Percent (%)
16x16 Percent
556 0.530
milliseconds
40003 2
40
24 55
Percent (%)
200
16x16 Percent
0.530 2210 15
milliseconds
55 23.5
1.5 454
milliseconds
Maze Type
Ty Maze
yMaze TypeTime
Type
Solving SolvingTime
Solving Time
2210 15 23.5
1.5 454 3000
milliseconds
Maze
yMaze TypeTime
Type SolvingTime
Solving Time 20
3000 20
Maze Type
Ty Solving
9.5
1 0.423
1 353 R
RecBack RecBack
RecBack 26.11
Time 297.30
9.5 0.423
1 353 R
RecBack RecBack
RecBack 26.11
Time 297.30 1.5150 10 52 RecBack RecDiv
RecDiv 1,347.47 15.24
2.97 71.50
256x256
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
1.51 10 52 RecBack RecDiv
RecDiv 1,347.47 15.24
2.97 71.50
20000 10
22.5
0.50 251 RecDiv
R
256x256
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
2000 22.5 RecDiv

R Prims
RecDivPrims 9.17
86.73 42.49
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
0.50 251 Prims
P 1.99
0 10 1 0.3 0 150
64x64
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
256x256
Prims 9.17
16x16
32x32
32x32 64x64
64x64128x128
128x128256x256
256x256 16x16
16x16 32x32
32x32 64x64
128x128
256x256
16x16
64x64
128x128
256x256
32x32
RecDivPrims 86.73 42.49
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
Prims
P 1.99 Prims 41.47
1 0.3 0 150 1000
64x64
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
256x256
16x16
32x32
64x64
64x64128x128
128x128256x256
256x256 16x16
16x16 32x32
32x32 64x64
128x128
256x256
16x16
128x128
256x256
32x32
64x64
49
Prims 41.47 100
16x16
32x32
64x64
128x128
256x256
16x16 16x16
32x32
64x64
128x128
128x128256x256
16x16
32x32
64x64
32x32128x128
256x256
1000 49 048
0.5 RecDiv RecBack Prims
16x16
32x32
64x64
128x128
256x256
16x16 16x16
32x32
64x64
128x128
128x128256x256
16x16
32x32
64x64
32x32128x128
256x256
048 0 5 0.2
16x16
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
0.5 0.2 RecDiv RecBack Prims RecDiv RecBack Prims
0 5
64x64
16x16
32x32
128x128
256x256
16x16
32x32
64x64
128x128
256x256
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
RecDiv RecDiv RecBack RecBack Prims Prims

16x16
32x32
64x64
128x128
128x128
256x256
32x32
64x64
256x256
16x16
64x64
256x256
RecDiv RecDiv RecBack RecBack Prims Prims 0 50 0.1
16x16
32x32
64x64
128x128
32x32
64x64
256x256
16x16
64x64
128x128
256x256
256x256
0 0.1 RecDiv RecBack Prims

RecDiv RecBack Prims 0 32x32 RecDiv
32x32
RecBack
32x32
Prims
0 32x32 RecDiv
32x32
RecBack Prims
32x32 0 0
0 64x64
RecursiveBacktracker Prims64x64
64x64 64x64 Prims64x64 128x12816x16 128x128
16x16 128x128
RecursiveDivision
16x16
RecursiveBacktracker
16x16 RecursiveDivision RecursiveBacktracker Prims 16x16
RecursiveDivision RecursiveBacktracker Prims 16x16 RecursiveDivision RecursiveBacktracker Prims
RecursiveDivision RecursiveBacktracker Prims RecursiveDivision
RecursiveDivision RecursiveBacktracker
RecursiveBacktracker PrimsPrims
RecursiveDivision RecursiveBacktracker Prims
(c) (d)
32x32)Comf( p%etion)Time
4)Length)Corridor)
12.5
l vervieO)ow )Comf
256x256)Comf
64x64)Comf
4)Branches) ( %
2)Branches) p(etion)Time
3)Length)Corridor) (%% petion)Time
petion)Time
4
000
712
26.5 128x128)Comf
16x16)Comf petion)Time
6)Length)Corridor)petion)Time
( %
7000
90
5300
6
25 26
80
3.5 5)Length)Corridor)
2)Length)Corridor) (( %
%
11.5
000 0.7
25.5
70
6000
16x16 Percent) ( % %
3 759
3511
Percent) ( %
Percent ( %
25
Percent) (
60 58
000
4 20
250 0.6
2.5
24.5
6
57
50
5000
5
10.5 556
Percent) ( %
2
mippiseconds
000
3 40
24
0.530
piseconds
55
200
2210 15 4000
23.5
1.5 454
piseconds
Maze Type
Ty Maze
yMaze TypeTime
Type
Solving Solving
Solving Time
Time
000 20
353 RecBack
Maze Type Solving3.98 26.11
Time 297.30
9.5
1
5150 0.423
1
10 52
R
RecBack RecBack
3000 RecBack RecDiv
RecDiv 1,347.47 15.24
2.97 71.50
256x256
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
000 22.5 251 RecDiv

R
0 10 0.50 Prims 9.17
mip
RecDivPrims 86.73 42.49

16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
Prims
P 1.99
1 0.3 0 150
64x64
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
256x256
16x16
32x32
64x64
64x64128x128
128x128256x256
256x256 16x16
32x32
32x32 64x64
128x128
256x256
16x16
64x64
128x128
256x256
32x32
mip
Prims 41.47
000
100 2000 49
16x16
32x32
64x64
128x128
256x256
16x16 16x16
32x32
64x64
128x128
128x128256x256
16x16
32x32
64x64
32x32128x128
256x256
048
5 0.2 RecDiv RecBack Prims
0 5
16x16
32x32
16x16
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
1000RecDiv RecDiv
RecDiv RecBack
RecBack
RecBack Prims
Prims
Prims
16x16
32x32
64x64
128x128
256x256
32x32
64x64
256x256
16x16
64x64
128x128
256x256
0 50 0.1 RecDiv RecBack Prims

0 0 32x32 32x32 32x32
RecDiv
RecDiv RecBack
RecBack Prims
Prims
0 0 256x256 256x256 256x256
64x64
RecursiveBacktracker Prims64x64
128x128 16x16 128x128 16x16 128x128
RecursiveDivision
RecursiveDivisionRecursiveBacktracker
RecursiveBacktracker Prims 16x16
Prims
RecursiveDivision
RecursiveDivision RecursiveBacktracker
RecursiveBacktracker PrimsPrims
(e)
Figure 4.2: Y axis is expressed in milliseconds, signifying the time it took for the
solver to find the goal. X axis shows grid resolutions for each maze algorithm.
4 Length Corridor (%)

12.5
Overview 2of
3 Length
Corridor(%)
(%)
Branches (%) Time
7000
712
26.5
90
6
26
80
3.5 52 Length
Length Corridor
Corridor (%)
(%)
Percent (%)
11.5
6000 25.5
70 759
5 3
Percent (%)
25
Percent (%)
(%)(%)
11 60 58
5000 2.5 6
milliseconds
4 24.5
50 57
Percent
10.5 556
4000
3 242
40 Percent (%)
16x16 Percent
55
30
210 23.5
1.5 454
3000 20
23 353
9.5
1 1
10 52
256x256
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
2000 22.5
0.50 251
0
16x16
32x32
16x16
32x32
64x64
128x128
256x256
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
150
64x64
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
256x256
64x64128x128
128x128256x256
64x64128x128
256x256
128x128
256x256
16x16
32x32
32x32 64x64
256x256 16x16
16x16 32x32
32x32 64x64
16x16
64x64
32x32
1000 0
49
16x16
32x32
64x64
128x128
256x256
16x16 16x16
32x32
64x64
128x128
128x128256x256
16x16
32x32
64x64
32x32128x128
256x256
048
0
16x16
16x16
32x32
64x64
128x128
256x256
128x128
256x256
256x256
16x16
32x32
64x64
16x16
32x32
64x64
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
RecDiv RecDiv RecBack RecBack Prims Prims
16x16
32x32
128x128
256x256
128x128
64x64
256x256
32x32
64x64
16x16
64x64
256x256
RecDiv
RecDiv RecBack
RecBack Prims
Prims
Figure 4.3: Y axis is expressed in milliseconds, signifying the time it took for the
solver to find the goal. X axis shows grid resolutions for each maze algorithm.
Completion Time
Maze Type Resolution Completion Time (ms)
RecDiv 16x16 0.59
RecBack 16x16 0.51
Prims 16x16 0.47
RecDiv 32x32 2.38
RecBack 32x32 3.46
Prims 32x32 1.52
RecDiv 64x64 12.26
RecBack 64x64 22.14
Prims 64x64 7.18
RecDiv 128x128 56.26
RecBack 128x128 271.18
Prims 128x128 33.32
RecDiv 256x256 362.14
RecBack 256x256 6,440.04
Prims 256x256 164.85
Table 4.1: Completion time (in millisec-

onds) per resolution.
4.3. Path Length 21
4.3 Path Length
Path Length
Maze Type Resolution Completion Time (ms) Solving Path (%) Solving Path Nodes Traversed Nodes
RecDiv 16x16 0.59 BB.a0 k9.1P 1k5.BB
Recr mcs 16x16 0.51 61.5a 105.96 14P.0a
7 3i2 8 16x16 0.k4 P1.aB BP.90 150.69
RecDiv BPxBP P.Ba PB.1B 146.Pa 46P.Pa
Recr mcs BPxBP B.k6 55.0k k5P.40 aPP.k6
7 3i2 8 BPxBP 1.5P 1k.B9 100.1a 696.k1
RecDiv 6kx6k 1P.P6 16.0P kaP.0a B,009.PP
Recr mcs 6kx6k PP.1k k9.B5 1,6PP.5P B,Pa4.65
7 3i2 8 6kx6k 4.1a a.k0 PB6.9P P,aP0.46
RecDiv 1Pax1Pa 56.P6 11.04 1,Pk5.4P 11,Pka.40
Recr mcs 1Pax1Pa P41.1a B9.66 5,555.16 1k,004.64
7 3i2 8 1Pax1Pa BB.BP k.54 51P.BP 11,P09.aP
RecDiv P56xP56 B6P.1k 4.Pk B,196.90 kk,1kP.16
Recr mcs P56xP56 6,kk0.0k B6.05 1a,BBP.aa 50,a59.61
7 3i2 8 P56xP56 16k.a5 P.k9 1,06B.1a kP,6B9.56
Table 4.2: An overview of the average path length data, sorted by resolution. Com-
pletion time is in milliseconds. Solving Path (%) is Solving Path Nodes divided by
Traversed Nodes, which is the proportion of Traversed Nodes that is solving path nodes.
Solving path nodes is the number of nodes that is part of the completion path. Tra-
versed nodes is the total number of nodes "walked" or "traversed" by the DFS solver,
including nodes that were not part of the completion path.
Table 4.2 contains both Solving Path Nodes, and Traversed Nodes. In Figure 4.1b
the sum of the green nodes is the Solving Path Nodes, while the Traversed nodes
is the sum of both the red and green nodes combined. Table 4.2 shows that at
higher resolutions, the RecBack has significantly higher completion time than the
other algorithms. RecBack also has the highest amount of traversed nodes and
solving path nodes, meanwhile Prims has the lowest completion times, and the lowest
amount of solving path nodes and traversed nodes. RecDiv comes in between Prims
and RecBack in all fields, being statistically closer to Prims than RecBack.
Figure 4.4 shows that Solving Path (%) decrease in a linear manner when reso-
lutions are increased.
Path Length Increase

Maze Type 16x16 - 32x32 (%) 32x32 - 64x64 (%) 64x64 - 128x128 (%) 128x128 - 256x256 (%)
RecDiv 524.52 394.77 373.81 392.42
RecBack 477.95 399.73 426.07 363.08
Prims 462.15 405.04 397.40 380.38
Table 4.3: Increase of solving path length per resolution change.

Increase is how much longer (in percent) the higher resolution
solving path is compared to the lower resolution path. Increase is
calculated as solving path nodes of the higher resolution divided
by the solving path nodes of the lower resolution times 100.
Solving
Solving Path Nodes ChangePath
per(%)
Resolution Increase
70
450 Prims Completion Time Increase
RecBack
RecDiv Completion
Completion Time Time Increase
Increase
60
400 600 4 32x32
Length Completion
Corridor (%) Time
2500
700
12.5
Overview 4 3 Length
64x64
Branches 2of
256x256 Completion
Corridor Completion
Completion
(%)
Branches (%)(%) Time
Time Time
350
50 500
128x128 Completion Time
4 16x16 Completion Time
(%)(%)
600
20007000712
26.5 6 Length Corridor (%)
300 7000
90
40 400 500Solving 25
Resolution 3.5
26 52(%)
Length
Length Corridor
4 Length Corridor
(%)
Corridor (%) 5 (%)
Percent (%)
Percent
Maze Type
300
6 Time 802 Length Corridor (%) 3 Length Corridor
3.5
(ms) Length Corridor (%) 6 Length Co
0.7
Percent (%)
Percent (%)
250 1500600011.5 25.5

Rec. 59 s4, s4 Maze Type 16x16
26 - 32x32 (%) 32x32
7x70 - 64x64 (%) 64x64 B36
7a6x7 - 128x128
B7 (%) 128x128 - 37
s26 256x256 (%) 361x
Percent
30 300 400 6000 3 759

Percent (%)
RecDi cv s4, s4 3
Rec. 11
559 267s25
60 7B36 7B 7B6s1 1x36aa B7640 1a160s s260s 1xB63B 76a1
Percent (%)
(%)(%)
200 58
5000 4 cv20 0.6
250 2.5 6 x7
milliseconds
k P5r m s4, s4 300

RecDi 26 3a 3aa6 7s602 1xx6a1 B36B2 3B462a ss602 141620 76a7
milliseconds
20 200 1000 24.5

5000 50 57
Percent
Rec. 59
150 1B, 1B k2.5
P5r10.5
m B610
2 556s7
34B6 7a671 327623 B36Bx 1xa632 s26a1 102610 3617
milliseconds
4000 3 40
24
1B, 1B 200
Percent (%)
128x128 Percent
0.5
milliseconds
RecDi cv 1634 55 7B67B B76x1 ss673 76s0

10 100
200 30
100 1B, 1B 500 2 210 15 4000 23.5
1.5 454
milliseconds
k P5r m s6 7B 7B67B Maze Type sxMaze

B36Maze TypeTime
Type
Solving Solving
Solving ss6Time
71
Time 76a1
1003000 20
Rec. 59
0 43, 43
0 9.5
1
sB6B4
0.4 231 353 7a64s Maze
RecDi B36 31RecDi
cvType
RecDi cvcv 16
Solving Time
x0 Bxa6B46
s26 12ss
74 36B7
50
RecDi cv 43, 43 1.5
0 150 BB6s310
3000 52 7B60a RecDi B46cvs3Rec.59 59 s813a63a ss6
Rec. as67B
s7672B3 76s3
256x256
16x16
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
0 - 32x32 22.5 32x32 - 64x64 64x64 -
Rec. 128x128
59 128x128
B6xa - 256x256
16x16
32x32
16x16
32x32
64x64
16x16
64x64
64x64
32x32
256x256
256x256 128x128
16x16 256x256
128x128
64x64 256x256
k P5r m 43, 43
2000 0 10 16x16a6 0.5
-s0 0 251 7B60a B36
59k2x-k128x128
P5m
r m ss6 74
x6 7643
32x32 32x32 -64x64
64x64 64x64
Rec. P 5r128x128 046128x128
a1 3B6 3xsa-256x256
256x256
16x16
32x32
16x16
32x32
64x64
128x128
256 256x256
64x64
x64 128x128
256x256
16x16
32x32
64x64
128x128
256x256
0 16x16 -
0.3 32x32 32x32 - k P64x64
5r m - s6 128x128
xx -
1 150
64x64
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
256x256
64x64128x128
128x128256x256
128x128
256x256
128x128
256x256
16x16
32x32
32x32 64x64
16x16
16x16 32x32
32x32 64x64
16x16
64x64
32x32
Rec. 59 sB0, sB0 746 B4 0 7a64s k P5r B36

m 31 3s63a s2643 36sx
RecDi cv 16x16
sB0, sB0
1000
- 100
32x32Bas6 2000
s0 49 - 64x64
32x32 716s1 64x64 B46B4 - 128x128 ss634128x128 - 256x256 7623
16x16
32x32
64x64
128x128
256x256
x16 16x16
32x32
64x64
128x128
128256x256
16x16
32x32
64x64
x32128x128
x64256x256
048
k P5r m sB0, sB0 0.5 0.2
116 1B RecDiv 7B6x3 RecBack B36B0 ss633 Prims 767x
0 5 14B6
64x64
16x16
16x16
32x32
128x128
256x256
128x128
16x16
32x32
64x64
32x32
64x64
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
Rec. 59 B74, B74

RecursiveDivision 1000
s3
RecDiv
RecDiv
RecDiv
7a641
RecBack
RecursiveBacktracker
RecDiv RecBack
B3632 RecBack
Prims RecBack
s2647
Prims
Prims
Prims36s0
Prims
128
x16
x32
x64
x32
256
x16
RecDi cv B74, B74 50 0 48332623 716B1 B46Bs ss63a 7627

k 5 B74 B74
0.1
43 07 RecDiv
71 2B B3 B1 RecBack 3 Prims
7 74
Figure 4.4: Y axis is expressed in percentile units, that signify the proportion of
Traversed Nodes that is Solving Path Nodes (values taken from Table 4.3). X axis
shows grid resolutions for each maze algorithm.
4.4. Corridor Distribution 23
4.4 Corridor Distribution
Corridor Distribution
Maze Type Resolution Completion Time (ms) 2 Length Corridor (%) 3 Length Corridor (%) 4 Length Corridor (%) 5 Length Corridor (%) 6 Length Corridor (%)
RecDiv 16x16 0.59 5B.95 ak.a5 10.k5 k.P9 1.51
Recr mcs 16x16 0.51 5a.1P a5.64 10.41 5.BP a.91
7 3i2 8 16x16 0.kB 51.40 ak.a0 11.40 5.B5 P.aB
RecDiv PaxPa a.P4 5B.5P ak.a9 10.BP k.P5 1.6a
Recr mcs PaxPa P.k6 5a.5a a5.9P 11.5k 5.14 a.54
7 3i2 8 PaxPa 1.5a 5a.5a ak.19 11.5P 5.BP a.4a
RecDiv 6kx6k 1a.a6 5B.61 ak.kP 10.56 k.a5 1.Ba
Recr mcs 6kx6k aa.1k 5a.4B a6.1k 11.5a 5.1k a.Pa
7 3i2 8 6kx6k B.14 5a.4B ak.09 11.56 5.6k a.4a
RecDiv 1a4x1a4 56.a6 5B.61 ak.kP 10.6k k.19 1.B1
Recr mcs 1a4x1a4 aB1.14 5P.1P a6.a6 11.k6 5.0k a.aa
7 3i2 8 1a4x1a4 PP.Pa 5a.9k ak.a4 11.kk 5.59 a.B4
RecDiv a56xa56 P6a.1k 5B.6P ak.k0 10.65 k.14 1.Ba
Recr mcs a56xa56 6,kk0.0k 5P.aP a6.a1 11.kB 5.05 a.a1
7 3i2 8 a56xa56 16k.45 5P.0a ak.aP 11.k9 5.56 a.Bk
Table 4.4: An overview of the corridor distribution data, sorted by resolution. Com-
pletion time expressed in milliseconds. The Corridor (%) columns each signify the
proportion of corridors in the entire maze that is of that length.
There are corridor lengths higher than length 6 presented in this section, but the
appearance of such corridors was a rare occurrence, therefore those were left out
of the presented data. Table 4.4 shows that the corridor distribution of each maze
algorithm does not differ much per resolution change. However there is a slight
difference in corridor distribution between the algorithms.
Observing Figures 4.5a, 4.5b, 4.5c, 4.5d, and 4.5e resulted in Table 4.5, which
compares the corridor lengths of each algorithm to each other. Those comparisons
exposes these patterns:
• Prims, the algorithm with the fastest completion time has the fewest 2 and 3
length paths, but the highest proportion of 4, 5 and 6 length paths.
• RecDiv with the intermediate completion time has the highest proportion of
2 length paths, intermediate proportion of 3 length paths, and the lowest pro-
portion of 4, 5 and 6 length paths.
• RecBack, with the slowest completion time has the lowest proportion of 2 length
paths, highest of 3 length paths, but a intermediate proportion of 4, 5 and 6
length paths.
Path Length Comparison

Maze Type Length (nodes) H M L Maze Type Length (nodes) H M L
RecDiv 2 X RecDiv 2 X
RecDiv 3 X RecBack 2 X
RecDiv 4 X Prims 2 X
RecBack 2 X Prims 3 X
RecBack 3 X RecDiv 4 X
RecBack 4 X RecBack 4 X
Prims 2 X RecBack 5 X
Prims 3 X Prims 5 X
Prims 4 X RecDiv 6 X
Prims 6 X Prims 6 X
Table 4.5: Blue is sorted by algorithm, green is

sorted by corridor length. Shows a relative com-
parison between the corridor lengths of the differ-
ent maze algorithms. H = highest relative propor-
tion, M = intermediate relative proportion, L =
lowest relative proportion.
10
0
20
30
40
50
60
70
80
90
RecDei vBak P Percent (%)
RecDei vBak P 16x16
4.5
48
49
50
51
52
53
54
55
56
57
58
59
0
1
3
4
5
6
10L5
11L5
12L5
9L5
210
11
712
32x32
16x16 16x16
16x16 RecDei vBak P
RecDei vBak P 64x64
RecDiv
32x32 32x32
22L5
23L5
24
24L5
25
26
26L5
23
25L5
10
0
20
30
40
50
60
70
80
90
32x32
128x128
64x64 RecDei vBak P 64x64
16x16
64x64
RecDiv
16x16
256x256
geDC)o
48
49
50
51
52
53
54
55
56
57
58
59
128x128 128x128
32x32
128x128
32x32
16 16x16
256x256 256x256
64x64
256x256
64x64
geDC)o
32 32x32
16x16
128x128
16x16 16x16
128x128
64 64x64
4Br 3B
32x32
RecBack
16x16 256x256
32x32
32x32
cmtei
Percent (%) 256x256
(c)
(a)
16x16 Percent
28 128x128
Percent
(%)(%)
64x64
i Ds2B
16x16
64x64
64x64
vs
32x32
22.5
23.5
26.5
23
24
24.5
25
26
25.5
1.5
2.5
3.5
0
1
2
3
16x16
10
0.50
20
30
40
50
60
70
80
90
4.5. Branch Distribution
RecBack
32x32
enB
256x256
geDr mDd
56
ak
r cm
32x32
128x128 128x128
64x64 Percent (%) 128x128
32x32
16x1616x16
64x64
1
6
16x16 16x16
RecDiv
16
RecDiv
048
49
50
251
52
353
454
55
556
57
58
759
4Btei vs B( %cc)h%cBak P
64x64
256x256 256x256
128x128
32x32
128x128 256x256
64x64
32x32
32x32
geDr mDd
16x16 32 32x32
16x16 16x16
B( i%cc)h%cB
128x128
16x16
16x16
256x256
64x64 64x64
256x256 128x128
32x32 64x64 64x64
RecDiv
64
RecDiv
Prims
PDs enBakakP P
RecDiv
32x32 256x256
32x32 32x32
16x16
128x128
128x128 16x16 32x32
256x256
64x64128x128 28 128x128
64x64 16x16
64x64 64x64
Prims
64x64
Rc). n
256x256
32x32
256x256
256x25632x32 16x16
256x256
2Btei vs B( %cc)h%cBak P
128x128 56
128x128 32x32
128x128 128x128
16x16
64x64
64x64 128x128
32x32
4 Branches
16x16
3 Length
Branch Distribution
256x256 16x16 16
RecBack
RecBack
256x256 64x64
256x256 256x256
Rc) n
32x32
128x128 256x256
64x64
(%)
128x128
32x32
32x32
16x16 32
(e)
16x16 128x128
52 Length
64x64
256x256
256x256
64x64
2 Branches
32x32
.5
24
23
.5
.5
25
26
.5
.5
32x32 64x64
RecBack
10
0
20
30
40
50
60
70
80
90
RecBack
32x32 32x32
RecBack
128x128
128x128 16x16
16x16
Corridor(%)
128x128
64x64 64x64 Percent (%) Percent (%)
16x16
64x64
(%)
6
64x64 16x16 Percent (%)
RecDiv

RecDiv
k
048
49
150
251
52
353
454
55
556
57
58
759
256x256
256x256 32x32
32x32
22.5
23.5
24
24.5
25
26
26.5
23
25.5
256x256
10
0
20
30
40
50
60
70
80
90
Length Corridor
128x128
128x128 128x128
32x32
128x128
16x16
64x64 16x16 32x32
16x16
64x64 16x16 Percent (%)
Prims
16x16 16x16
Corridor (%)
Prims
16x16
(%)
256x256
256x256 256x256
64x64
256x256
48
49
50
51
52
53
54
55
56
57
58
59
32x32
128x128 32x32 64x64
RecDiv
32x32
128x128
32x32 RecDiv
32x32 32x32
16x16 16x16
128x128
16x16 32x32
16x16 64x64128x128 16x16
64x6464x64
256x256 64x64
Prims
256x256
64x64 RecDiv 64x64
Prims
RecDiv 256x256
32x32 64x64
Prims
32x32 32x32
RecDiv
32x32
RecDiv
128x128 128x128256x256 32x32

Corridor Length Comparison
128x128
128x128 128x128 128x128
64x64 16x16
64x6464x64 128x128
64x64 256x256 256x256 16x16 64x64
RecBack
RecBack
256x256
256x256 256x256 256x256
128x128 32x32
128x128
128x128 256x256
128x128 16x16 32x32 8x128
16x16
other resulted in Table 4.7, which helped expose some patterns:

16x16
52 henLtg
3 Length
64x64
256x256
256x256 16x16
32x32 64x64 6x256
RecBack
32x32
RecBack
32x32
128x128
16x16 32x32
(d)
(b)
16x16
64x64128x128 16x16
64x64 64x64
2 Branches
RecBack
256x256
32x32 64x64
RecBack
32x32
RecBack
256x256
henLtg Corridor
32x32
RecBack
128x128
128x128 128x128
Corridor(%)
16x16
64x64 128x128
64x64
Prims
16x16
Corridor (%)
(%)
64x64
Prims
(%)
256x256
256x256 256x256
32x32
128x128 256x256
128x128
32x32 8x128
16x16
16x16 16x16
64x64
256x256 16x16
Prims
256x256
64x64 6x256
Prims
32x32
32x32 32x32
128x128 32x32
128x128 16x16
64x64
64x64 64x64
of corridors in the maze. X axis shows grid resolutions for each maze algorithm.
Prims
256x256
Prims
Prims
64x64
Prims
256x256 32x32
128x128
128x128 128x128
128x128
Observing figures 4.6a, 4.6b, 4.6c, 4.6d, while comparing the maze algorithms to each
25
However there is a difference in the proportions of branches between the algorithms.

Table 4.6 displays an overview of the branch distribution data. It is observed that
branch distribution does not change much for the algorithms between resolutions.
calculated from dividing the number of corridors of stated length by the total number
which signifies the proportion of corridors that is of stated length. Proportion is
corridors of stated length across resolutions. Y axis expressed in percentile units,
Figure 4.5: Length is stated in the title of each sub-figure. Shows distribution of
256x256
256x256
64x64 256x256
256x256
8x128
• RecBack, with the highest completion time, has the highest distribution of
2-branches, but the lowest distribution of every other branch type, with 4-
branches close to 0% distribution.
• Prims is the opposite to RecBack, with the lowest completion time, lowest
distribution of 2-branches, and the highest distribution of all of the other branch
types.
• RecDiv, with medium completion time has medium distribution across all
branch types.
Maze Type Resolution Completion Time (ms) 1 Branches (%) 2 Branches (%) 3 Branches (%) 4 Branches (%)
RecDiv 16x16 0.59 Ba.69 kP.0r B1.6k B.6r
Recmsc4 16x16 0.51 10.a0 a9.k9 9.a1 0.11
7 3i2 8 16x16 0.ka r k.a1 r 6.P0 Br .0k 5.k5
RecDiv r Bxr B B.r P Ba.r P kP.1P B1.a1 B.ak
Recmsc4 r Bxr B r .k6 10.r B a9.a0 9.Pr 0.15
7 3i2 8 r Bxr B 1.5B r 5.11 r 5.P0 Br .B9 5.P1
RecDiv 6kx6k 1B.B6 Ba.k0 kP.0r B1.aP B.aP
Recmsc4 6kx6k BB.1k 10.06 P0.0P 9.a0 0.16
7 3i2 8 6kx6k a.1P r 5.k6 r 5.19 Br .r 0 6.06
RecDiv 1BPx1BP 56.B6 Ba.r k kP.06 B1.P5 B.ak
Recmsc4 1BPx1BP Ba1.1P 10.0B P0.15 9.65 0.1P
7 3i2 8 1BPx1BP r r .r B r 5.59 r k.95 Br .r k 6.1B
RecDiv B56xB56 r 6B.1k Ba.r 9 ka.9P B1.P6 B.a6
Recmsc4 B56xB56 6,kk0.0k 9.9a P0.Bk 9.61 0.1P
7 3i2 8 B56xB56 16k.P5 r 5.aB r k.a6 Br .r r 6.19
Table 4.6: An overview of the branch distribution data, sorted by resolution. Com-
pletion time in milliseconds. Each Branches (%) column signifies the proportion of
nodes with that number of branches. Note that the sum of all branch columns in one
row is 100, since the sum of all branches is 100% of the branches. Further note that
the total number of branches is equal to the total number of nodes in the maze (which
is the same as the resolution of the maze), since each node has branches.
4.5. Branch Distribution 27
Maze Type Branches H M L Maze Type Branches H M L

RecDiv 3 X Prims 1 X
Prims 1 X Prims 3 X
Prims 2 X RecDiv 4 X
Prims 4 X Prims 4 X
Table 4.7: Blue is sorted by algorithm, green is

sorted by branches. Shows a relative comparison
between the branches of the different maze algo-
rithms. H = highest relative proportion, M = in-
termediate relative proportion, L = lowest relative
proportion.
Branches Comparison
1 Branches (%) 2 Branches (%)

40 90
35 80
30 70
Percent (%)
Percent (%)
60
25
50
20
40
15
30
10 20
5 10
0 0
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
64x64
128x128
256x256
32x32
RecDiv RecBack Prims RecDiv RecBack Prims
(a) (b)
6 Branches (%) 3 Length

4 Branches Corridor(%)
(%)
2 Branches (%)
26.5
25 7 90
6
26
80 2 Length Corridor (%)
20 25.5
70 59
Percent (%)
5 25
Percent (%)
Percent (%)
Percent (%)
60 58
15 4 24.5
50 57
3 40
24 56
Percent (%)
10 55
30
23.5
2 54
5 20
23 53
1 10 52
22.5
0 0 0 51
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
50
2534253
62462
64x64
13413
62462
1284128
13413
1284128
2534253
13413
62462
1284128
2534253
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
64x64
128x128
32x32
3x43x
3x43x
3x43x
49
48
16x16
32x32
64x64
28x128
56x256
16x16
32x32
64x64
28x128
56x256
16x16
32x32

RecDiv RecBack Prims RecDiv RecDiv RecBack RecBack Prims Prims
(c) (d)
Figure 4.6: The compared branch type is stated in each sub-figure. Y axis is expressed
in percentile units, signifying the proportion of all branches that are of the stated type.
X axis shows grid resolutions for each maze algorithm.
Chapter 5
Analysis and Discussion
This chapter will present, explain, and argue for and against patterns found in the
results of each data set in turn.
5.1 Completion Time

The data presented in Section 4.2 shows that in all resolutions, except 16x16, RecBack
is slowest, Prims is fastest, and RecDiv is intermediate.
The order of complexity of the maze algorithms coincides with the order of path
length in the work of Kozlova et. al (Kozlova et al., 2015), who calculated the
mean of path lengths of the RecDiv, Prims, and RecBack (called depth first search)
algorithms. Since path length seems to correlate with complexity (argumentation
found in Section 5.2), their findings should increase the confidence in the answer to
RQ1.
The order of complexity of the maze algorithms also partially coincides with the
findings of Foltin (Foltin, 2008). Foltin investigated RecDiv and Prims (among some
other algorithms) and recorded the average completion time of humans solving those
mazes. The data shows that RecBack took longer for humans to solve than Prims. It
implies that they found RecBack harder to solve, which implies increased complexity.
Since Foltin did not use RecDiv and he used human test subjects instead of a solver
algorithm, his results does not directly correlate as much as Kozlovas. However his
results does imply that the results found in this thesis may also be applicable to
human test subjects.
It is uncertain what exactly makes the completion time of RecBack so much higher
than Prims and RecDiv. One could think that since the completion time is the time
it takes for the DFS solver to reach the goal, each traversed node takes time for the
solver to traverse. Therefore the traversed nodes should be directly correlated with
completion time. However it is not explained by the traversed nodes, since RecDiv
on resolution 256x256 has only traversed 15% more nodes than RecDiv, which does
not explain the 1̃800% higher completion time. However the amount of solving-path
nodes of RecBack is 5̃.73 times higher than RecDiv, which could mean that it is
part of the answer. Or perhaps the completion time difference can be found as a
combination of solving path nodes and traversed nodes, or in a statistic not taken
into account. It could be the case that it is because of a software error, however it is
unlikely since the change in traversed nodes, solving path nodes, and completion time
is too consistent with previous contributions. Previous contributions were looked
through to find the answer to the big difference in completion time. Foltin (Foltin,
29
30 Chapter 5. Analysis and Discussion
2008) measured the average completion time of maze resolutions similar to the 16x16,
32x32, and 64x64 resolutions used in this thesis. His completion time increase seem
to approximately coincide with the ones found between resolutions 16x16, 32x32, and
64x64 found in Figure 5.2 (however his increase is smaller, and less even). However it
should be noted that his resolutions are not the same as in this thesis, and the solving
time he gathered was that of humans, not a DFS. No other contributions measuring
the completion time of mazes of differing resolutions has been found. which makes
answering the completion time increase difference the task of future research.
While observing Table 4.1, of note is that the difference in complexity seems to
get smaller as maze resolutions get lower. This might occur since as the maze grid
gets smaller, the number of possible maze variations inside that grid gets smaller, and
therefore outputs of the algorithms seem more and more similar. So the difference
in complexity between the maze algorithms seems to be directly proportional to the
resolution of the maze grid.
Prims Completion Time Increase

600 32x32
4 Length Completion
Corridor (%) Time
12.5
Overview 3
64x64
4 Branches of
256x256
Length Completion
CorridorCompletion
Completion
(%)
2 Branches (%)(%) Tim
Tim
500 4
7000712
26.5 128x128 16x16
6 Length Completion
Completion
Corridor (%) TimTi
7000
90
400
Resolution 3.5
25 26 5
2 Length
Length Corridor
Corridor (%)
(%)
Percent (%)
ze Type Solving
6 Time (ms)
300 802 Length Corridor (%) 3 Length Corridor (%) 4 Length Corridor (%) 5 Length
3.5
0.7
11.5
6000 25.5
c. 59 s4, s4 267x70 7a6x7 B36B7 s2637
300 6000 3 759
Percent (%)
cDi cv s4, s4 3511 25

267s 7B6s1 B7640 s260s
Percent (%)
Percent (%)
60 58
50004 20 0.6
250 2.5 6
milliseconds
m s4, s4 263a 7s602 B36B2 ss602

milliseconds
200 24.5
50 57
16x16 Percent (%)
c. 59 1B, 1B 2.5
10.5 5000
B610 7a671 B36Bx s26a1
2 556
milliseconds
40003 40
24
Percent (%)
0.5
milliseconds
cDi cv 1B, 1B 1634 55 7B67B B76x1 ss673

100
200
10
22 15 4000 30
23.5
1.5 454
milliseconds
m 1B, 1B s67B 7B67B sxMaze

B36Maze
Maze Type TypeTime
Type
Solving Solving
Solvingss6Time
71
Time
c. 59 43, 43 3000 sB6B420
353 7a64s Maze B3631RecDi
cvcv 16 s26B46
12ss
74
0 9.5
1 0.4 231 RecDi cvType
RecDiSolving Time
x0 Bxa6
cDi cv 43, 43 1.5150 BB6s310
3000 52 7B60a B46Rec.
-RecDi s3Rec.59 59 s813a63a ss6
59 cv
7B
s76
as672B3
256x256
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
12832128
16x16
2000 - 32x32 22.5 32x32
251 - 64x64 64x64Rec.
128x128 128x128
B6xa - 256x256
m 43, 43 0 10 a6s0 0.50 7B60a B362x r m ss674
5r m 59k Pk5rP5m
k PRec. xxa1 3B6x6
046 3xsa
8x128
6x256
16x16
32x32
8x128
6x256
16x16
32x32
64x64
64x64
16x16
s6
1 0.3 150
4x64
6x16
2x32
4x64
6x16
2x32
6x16
2x32
4x64
x128
x256
x128
x256
8x128
6x256
8x128
6x256
66x16
22x32
44x64
66x16
22x32
44x64
66x16
c. 59 sB0, sB0 746B4 0 7a64s k P5r B36

m 31 3s63a s2643
1000
100 Bas2000
32
cDi cv sB0 sB0 s0 49 71 s1 B4 B4 ss 34
Figure 5.1: Y axis is change/increase, described in percentages

as how the completion time of the higher resolution compares
to the completion time of the lower resolution . Change/In-
crease is calculated as larger resolution completion time divided
by smaller resolution completion time times 100. X axis shows
grid resolutions for each maze algorithm.
5.2. Branches, Path Length, and Corridors Effect On Completion Time 31
Prims Completion
RecBack Completion Time Increase
Time Increase
600 4 32x32
Length Completion
Corridor (%) Time
2500
12.5
Overview 3 Length
64x64
4 Branches of
256x256 Completion
CorridorCompletion
Completion
(%)
2 Branches (%)(%) Time
Time Ti
500
2000
4
7000712
26.5 128x128 16x16 Completion
Completion
6 Length Corridor (%) Time
Time
7000
90
400 3.5 25 26 52(%)
Length
Length Corridor
4 Length Corridor
(%)
Corridor (%) 5 (%)
( )
Resolution Solving
6 Time (ms)
300 80
3.52 Length Corridor (%) 3 Length Corridor Length Corrid
0.7
Percent (%)
1500
11.5
6000 25.5
s4, s4 267x70 7a6x7 B36B7 s2637
300 6000 3 759
Percent (%)
s4, s4 3511 267s
Percent (%) 25 7B6s1 B7640 s260s
Percent (%)
60 58
5000
25020 0.6 2.5 6
milliseconds
s4, s4 263a 7s602 B36B2 ss602
1000 4
milliseconds
200 24.5
50 57
16x16 Percent (%)

1B, 1B 2.5
10.5 5000
B610 7a671 B36Bx s26a1
2 556
milliseconds
40003 40
24
Percent (%)
0.5
milliseconds
1B, 1B 1634 55 7B67B B76x1 ss673
100
200
500 2 21015 4000 30
23.5
1.5 454
milliseconds
1B, 1B s67B 7B67B Maze Type sxMaze

B36Maze TypeTime
Type
Solving Solving
Solving ss6Time
71
Time
43, 43 3000 sB6B4 20
23 353 7a64s Maze B36 31RecDi
Type
RecDi cv
Solving
cv Time B46
s26 12ss
74
Bxa6
0
43, 43 1.5
9.5
1 0.4
BB6s310
1
52 7B60a
RecDi cv
B46cv
16x0
s3Rec.59 59 s813a63a ss6 7B
3000 RecDi Rec. s76
as672B3
150
256x256
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
0
2000 - 32x32 22.5 32x32
251 - 64x64 64x64 -
Rec. 128x128
59 128x128
B6xa - 256x256
43, 43 0 10 a6s0 0.50 7B60a B36 2xk P5
r m ss674
Rec. 5
9k P5r m 128x128sa
046a1 3B6x6
3x
16x16
32x32
16x16
32x32
64x64
128x128
256x256
64x64
128x128
256x256
16x16
32x32
64x64
16x160.3
- 32x32 50 32x32 - 64x64 k P64x64
5r m - 128x128 s6xx - 256x256
1
64x64
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
28x128
56x256
28x128
56x256
16x16
32x32
64x64
16x16
32x32
64x64
16x16
32x32
sB0, sB0 746B4 0 1 7a64s k P5r B36
m 31 3s63a s2643
sB0, sB0
1000
100 2000
Bas6 s0 49 716s1 B46 B4 ss634
x16
x32
4x64
128
256
x16
x32
4x64
128
256
x16
x32
048
sB0 sB0 05 0 1B
11 2 RecDiv 7B x3 RecBack B3 B0 ss 33 Prims

Prims Completion Time Increase

RecBack
RecDiv Completion
Increase
600 4 32x32
Length Completion
Corridor (%) Time
2500
700
12.5
Overview 3 Length
64x64
4 Branches of
256x256 Completion
CorridorCompletion
Completion
(%)
Time Tim
500
600 4
20007000712
26.5 128x128 16x16 Completion
6 Length Completion
Corridor (%) Time
Time
7000
90
400
Resolution 3.5
500Solving
25 26 5
2 Length
Length Corridor
Corridor (%)
(%)
802 Length Corridor (%) 3 Length Corridor (%) 4 Length Corridor (%) 5 Length Corridor
3.5
6 Time (ms)
300 0.7
Percent (%)
Percent (%)
1500
11.5
6000 25.5
s4, s4 26 7x70 7a6x7 B36B7 s2637
300 400 5 6000 3 759
Percent (%)
s4, s4 3 267s25 7B6s1 B7640 s260s

Percent (%)
Percent (%)
11 60 58
50004 20 0.6
250 2.5 6
milliseconds
s4, s4 300 26 3a 7s602 B36B2 ss602

milliseconds
200 1000 24.550 57

16x16 Percent (%)
1B, 1B 2.5
10.5 5000
B610 56 7a671 B36Bx s26a1
2 5
milliseconds
40003 40
24
1B, 1B 200
Percent (%)
0.5
milliseconds
1634 55 7B67B B76x1 ss673

100
1B, 1B 500 2 200
210 15 400023.530
1.5 454
milliseconds
s6 7B 7B67B sxMaze
B36Maze
Maze Type TypeTime
Type
Solving Solving
Solving ss6Time
71
Time
100
3000 20
43, 43 sB6B423 353 7a64s Maze B36 31RecDi
Type
RecDi cvcv 16
Solving Time B46
s26 12ss
74
Bxa6
0
43, 43 1.5
9.5
1 0.4
BB6s310
1
52 7B60a
RecDi cv
B46cv
x0
s3Rec.59 59 s813a63a ss6 7B
0
0 150 - 32x323000 RecDi Rec. s76
as672B3
256x256
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
2000 22.5 32x32
251 - 64x64 64x64Rec.
- 128x128
59 128x128
B6xa - 256x256
43, 43 0 10 16x16a6 0.5
-s0 0 7B60a B36
59k2x-k128x128
P5m
r m ss674
x6
32x32 32x32 -64x64
64x64 64x64
Rec. P 5r128x128 046 128x128
a1 3B63xsa
- -256x256
256x256
16x16
32x32
16x16
32x32
64x64
128x128
256x256
64x64
128x128
256x256
16x16
32x32
64x64
16x16 -
0.3 32x32 32x32 - k P64x64
5
r m - s6128x128
xx
1 150
64x64
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
56x256
28x128
56x256
28x128
28x128
56x256
28x128
56x256
28x128
56x256
16x16
32x32
64x64
16x16
32x32
64x64
16x16
64 64
32x32
sB0, sB0 746 B4 0 7a64s k P5r B36

m 31 3s63a s2643
sB0, sB0
1000
100 Bas6 2000
s0 49 716s1 B46B4 ss634
x16
x32
x64
128
256
x16
x32
x64
128
256
x16
x32
x64
0
05 0 2 R Di48 R B k Pi

5.2 Branches, Path Length, and Corridors Effect On

Completion Time
To draw conclusions about potential connections to complexity, patterns offering
clear opposites was searched for. Such patterns makes it easier to predict what effect
Average Completion Time
Maze Type Completion Time (ms) Maze Type Completion Time (ms)
RecBack 1,347.47 RecBack 297.30
RecDiv 86.73 RecDiv 71.50
Prims 41.47 Prims 42.49
(a) (b)
Maze Type Completion Time (ms) Maze Type Completion Time (ms)
RecBack 26.11 RecBack 3.98
RecDiv 15.24 RecDiv 2.97
Prims 9.17 Prims 1.99
(c) (d)
Table 5.1: Completion time expressed in milliseconds. (a) Presents the average
completion time between all resolutions for each maze algorithm. (b) Presents the
average completion time between the resolutions 16x16, 32x32, 64x64 and 128x128,
for each maze algorithm. (c) Presents the average completion time between the
resolutions 16x16, 32x32 and 64x64, for each maze algorithm. (d) Presents the
average completion time between the resolutions 16x16 and 32x32, for each maze
algorithm.
5.2. Branches, Path Length, and Corridors Effect On Completion Time 33
a change should induce.
5.2.1 Branches
Branch distribution patterns found in Table 4.7 indicate that completion time is
directly proportional to the amount of 2-branches. A high distribution of 2-branches
leads to a lower distribution of all other branch types, which in turn hypothetically
would reduce the number of possible paths to the goal, making finding the solution
path harder.
Figures 4.1c and 4.1a illustrates this hypothesis. Figure 4.1c which illustrates a
maze generated by Prims, has a solving path that goes almost straight between start
and finish. Prims as the algorithm with the least amount of 2 branches, and the
highest amount of all other branch types, makes it the most interconnected maze,
which makes direct paths to any point in the maze more likely to occur.
Figure 4.1a is the opposite, with the highest proportion of 2-branches, and the
lowest proportion of all other branch types, making it the least interconnected maze.
Because of its low interconnectivity, it’s solution path winds through the maze, cov-
ering a large portion of the maze grid.
5.2.2 Path Length
What stands out in Table 4.2 is the completion time of RecBack on resolution
256x256. The other solving path nodes are much smaller. This difference might
look so large as to indicate an error in the test, but looking at Figure 4.3 and 5.4
show that the increase of solving path length has remained relatively even, which
indicates that results had a low variation in the test. By observing the path length
data in Table 4.2, one can discern a pattern that seems to indicate that a lower
amount of solving path nodes and traversed nodes, leads to lower completion times.
This is unsurprising, since traversing nodes is what takes time for a solver searching
for the exit.
Mazes with relatively short solution paths seem to get solved faster. Perhaps
if one thinks of the solution path as "the minimum amount of nodes to traverse
to solve the maze". Solvers traversing mazes with short solution paths would then
at minimum traverse fewer nodes than solvers traversing mazes with long solution
paths.
Kozlova et. al (Kozlova et al., 2015) measured path lengths of the same maze
algorithms as in this thesis. They also found RecBack to have the longest average
path length, Prims to have the shortest average path length, and RecDiv to have
intermediate path length. They used a non-uniform grid of resolution 16x12 for
their maze algorithms, of a lower resolution that in this thesis (lowest 16x16), so the
results, even if similar overall, are not perfectly correlated. But still it is unlikely
that it is by accident that the size orders are the same.
Solving Path Nodes Change per Resolution Increase

450 Prims Completion Time Increase
RecBack
RecDiv Completion
Increase
400 600 32x32
4 Length Completion
Corridor (%) Time
2500
700
12.5
Overview 3 Length
64x64
4 Branches of
256x256 Completion
Corridor Completion
Completion
(%)
Time Time
350 500
128x128 Completion Time
600 4
20007000712
26.5
7000
90
16x16
6 Length Completion
Corridor (%) Time
Percent (%) 300 500Solving 25 52(%)
Length
Length Corridor (%)
4 Length Corridor
Corridor (%) 5 (%)
400 26
Resolution 3.5
Percent (%)
Maze Type 6 Time (ms)
300 802 Length Corridor (%) 3 Length Corridor
3.5 Length Corridor (%) 6 Length C
0.7

Percent (%)
Percent (%)
250 1500
11.5
6000 25.5
Rec. 59 s4, s4 26 7x70 7a6x7 B36B7 s2637 361x
300 400 5 6000 3 759
Percent (%)
RecDi cv s4, s4 311 267s 25 7B6s1 B7640 s260s 76a1
Percent (%)
Percent (%)
60 58
200 5000250 20 0.6 2.5 6
milliseconds
k P5r m s4, s4 300 4 26 3a 7s602 B36B2 ss602 76a7
milliseconds
200 1000 24.550 57
16x16 Percent (%)

Rec. 59 1B, 1B 2.510.5 5000
B610 7a671 B36Bx s26a1 3617
150 2 556
milliseconds
4000 3 40
24
1B, 1B 200
Percent (%)
0.530
milliseconds
RecDi cv 16 34 55 7B67B B76x1 ss673 76s0
100
100 1B, 1B 500 2 200
10
15 4000
23.5
1.5 454
milliseconds
k P5r m 2 s6 7B 7B67B B36sxMaze
Maze Type
Type
Maze Type Solving Time Solving
Solving ss6Time
71
Time 76a1
100
3000 20
Rec. 59 43, 43
0 9.5
1
sB6B4
0.4 231 353 7a64s Maze
RecDi B3631RecDi
cvType
RecDi cvcv 16
Solving Time
x0 Bxa6B46
s26 12ss
74 36B7
50
RecDi cv 43, 43 1.5 BB6s3 10 52 7B60a B46Rec.
s3Rec.59 59 s813a63a ss6 7B
s76
72B3 76s3
00 150 3000 -RecDi59 cv as6
256x256
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
2000 - 32x32 22.5 32x32
251 - 64x64 64x64Rec. 128x128 128x128
B6xa - 256x256
k P5r m 43, 43 0 10 a6 0.5
s0 0 7B60a B362x
-k128x128
P5m
r m ss674 7643
16x16 -- 32x32
32x32 32x32--64x64
64x64 5r64x64
k PRec.m 59k-P 5r128x128 046 3B6x6
128x128
a1 3xsa
- -256x256
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
0 16x16
0.3 32x32 64x64 s6128x128
xx
1 150
64x64
16x16
32x32
64x64
16x16
32x32
16x16
32x32
64x64
128x128
256x256
128x128
256x256
128x128
256x256
16x16
32x32
64x64
64x64128x128
128x128256x256
256x256 16x16
16x16 32x32
32x32 64x64
64x64128x128
256x256
16x16
64x64
128x128
256x256
32x32
Rec. 59 sB0, sB0 746 B4 0 7a64s B36
k P5r m 31 3s63a s2643 36sx
RecDi cv 16x16
sB0, sB0
1000
- 100 2000 49
32x32Bas6s0 32x32 - 64x64 716s1 64x64 B46B4 - 128x128 ss634128x128 - 256x256 7623
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
x128256x256
16x16
32x32
64x64
2x32128x128
256x256
048
k P5r m sB0, sB0 0.5 0.2
116 1B RecDiv 7B6x3 RecBack B36B0 ss633 Prims 767x
0 5 14B6
16x16
32x32
128x128
256x256
16x16
32x32
64x64
128x128
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
256x256
16x16
32x32
64x64
128x128
Rec. 59 B74, B74 1000
s3
RecDiv RecDiv
RecDiv
7a641
RecBack RecBack
RecDiv
B3632 RecBack
Prims RecBack
s2647
Prims
Prims36s0
Prims
x128
x256
6x16
2x32
4x64
x256
6x16
2x32
4x64
6x16
4x64
RecDi cv B74, B74 50 0 48332623 716B1 B46Bs ss63a 7627
k P5r m B74, B74
0.1
s43607 RecDiv
7162B B36B1 RecBack ss63x Prims
7674
0 32 32 32 32 32 32
Figure 5.4: Y axis is change/increase, described as how much

longer (in percentages) the higher resolution solving path is com-
pared to the lower resolution solving path. Change/Increase
is calculated as larger resolution solving path nodes divided by
smaller resolution solving path nodes times 100. X axis shows
5.2.3 Corridors
It is hard to draw a conclusion around corridor distribution’s effect on completion
time, since the differences in corridor length in Table 4.4 is at most around 3%, and
at least below 1%. It is hard to make the case that a higher proportion of long
corridors lead to faster completion times, because there is no clear opposite that says
what makes for slower completion times.
Chapter 6
Conclusions and Future Work
In this chapter, conclusions that can be drawn from the tests are stated and presented
as answers to the research questions.
This study has attempted to provide level designers, developers, and game de-
signers with information to evaluate and understand what makes some mazes more
complex than others. To do this a software implementation was developed to per-
form tests on three different maze generation algorithms across five different maze
resolutions, which gathered their solving path length, traversed nodes, corridor dis-
tribution, branch distribution, and completion time data.
RQ1: What is the difference in complexity between the maze generation algorithms
recursive backtracker (RecBack), randomized Prim’s algorithm (Prims), and recur-
sive division (RecDiv), in terms of completion time, when solved using a depth-first-
search (DFS) algorithm?
Answer: Overall RecBack is more complex than RecDiv which is more complex than
Prims which is the least complex. Maze resolution is directly proportional to com-
plexity. This means that in low resolutions, the differences in complexity between
the algorithms are less pronounced than at higher resolutions. The complexity of
RedDiv is more similar to Prims than RecBack.
RQ2: What connection is there between completion time/complexity, and the distri-
bution of branching paths, distribution of corridors, and length of the path traversed
by DFS?
Answer:
• Branching Paths: Complexity seems to be directly proportional to 2-branches.

Also since the proportion of one branch-type affect the proportions of other
branch-types, there is a direct inversely proportional relationship between all
branch types.
• Corridor distribution: There is not an easily observable pattern between

the corridor-distribution-results of the three algorithms that seem to affect the
overall completion time.
• Path length: Complexity seems to be directly proportional to both solving

path nodes and traversed nodes.
It has in the end been observed that using solving-time as an absolute metric
for complexity might not be beneficial since it heavily favors mazes with the longest
35
36 Chapter 6. Conclusions and Future Work
solution-paths. The observation is that the "most complex maze" would be a maze
where every node in the grid is part of the solution path, which might not be ideal
for gameplay scenarios. However it could perhaps still be useful as part of a fitness-
function to be used to craft mazes similarly to what Kim et. al did (Kim & Crawfis,
2015).
6.1 Future Work

For future work, other researchers could try replicating the test results which would
be beneficial for the relatively sparse field of study of mazes. Perhaps a metric
for complexity better than DFS solver completion time could be found. A search-
algorithm specifically crafted to more closely simulate human behaviour (like having
an imperfect memory, making it retread already walked paths). No search-algorithm
that takes into account human has been found, therefore it would perhaps be ben-
eficial if such an algorithm was developed, perhaps by closely observing humans
solving mazes, and then translate the observed behavior to algorithms. It would
provide more accurate results when measuring complexity of mazes, and could per-
haps prove to have other uses. Researchers could perform a statistical analysis on
the data presented to determine if the data is statistically significant. The devel-
opment of a more standardized language around mazes should be looked into to
nurture further research into this area. Perform tests on maze algorithms besides
those used in this study to expand the body of knowledge. Further research testing
the parameters investigated here could develop a more complex application which
allows for direct control over the proportions of the parameters, which would allow
researchers to more precisely investigate them, and to evaluate the correctness of
the answers to Research Question 2. A suggestion for PCG types suited for such an
application would be either an evolutionary algorithm, a grammar based one, or a
search-based one. An example of a search-based application that generates mazes
was developed by Kim et. al (Kim & Crawfis, 2015), who investigated ways to con-
trol maze-generation. Their paper is a good start-off point for future work in that
area.
When exploring the possibility to numerically quantify the difference in com-
plexity between the algorithms, finding numerical differences that were true for all
resolutions proved unfeasible to do by simple observation. Table 5.1a shows the av-
erage completion time between all resolutions for each algorithm. Using that data
would make RecDiv 2.1 times more complex than Prims, and RecBack 15.5 times
more complex than RecDiv. However if the completion time for 256x256 is left out
of the average completion time data the resulting data is shown in Table 5.1b. Using
that data would make RecDiv 1.7 times more complex than Prims, and RecBack
4.16 times more complex than RecDiv. Tables 5.1c,5.1d shows the completion times
as high resolutions are removed from the average completion time data. No clearly
discernible pattern in the increasing complexity has been found in Figures 5.1, 5.2
and 5.3, except that the completion time tends to get higher as resolutions increase.
In order to help explain completion time, patterns for complexity that are true for
all resolutions could be found by developing an extrapolation function.
References 37
References
Ashlock, D., Lee, C., & McGuinness, C. (2011, September). Search-Based Proce-
dural Generation of Maze-Like Levels. IEEE Transactions on Computational
Intelligence and AI in Games, 3 (3), 260–273. Retrieved 2018-04-11TZ, from
http://ieeexplore.ieee.org/document/5742785/ doi: 10.1109/TCIAIG
.2011.2138707
Bae, C.-M., Kim, E., Lee, J., Kim, K.-J., & Na, J.-C. (2015). Genera-
tion of an arbitrary shaped large maze by assembling mazes. In 2015
IEEE Conference on Computational Intelligence and Games, CIG 2015
- Proceedings (pp. 538–539). Retrieved from https://www.scopus.com/
inward/record.uri?eid=2-s2.0-84964443933&doi=10.1109%2fCIG.2015
.7317901&partnerID=40&md5=e95c8a5bcfed6808a0062ca6fb30c048 doi:
10.1109/CIG.2015.7317901
Buck, J. (2011, December). Maze Generation: Recursive Division. Re-
trieved 2018-04-04TZ, from http://weblog.jamisbuck.org/2011/1/12/maze
-generation-recursive-division-algorithm
Buck, J., & Carter, J. (2015). Mazes for programmers: code your own twisty little
passages. Dallas, Texas: The Pragmatic Bookshelf. (OCLC: ocn919295242)
E. Black, P. (2003). weighted graph. Retrieved from https://www.nist.gov/dads/
HTML/weightedGraph.html
E. Black, P. (2005). greedy algorithm. Retrieved 2018-04-09, from https://www
.nist.gov/dads/HTML/greedyalgo.html
E. Black, P. (2014). minimum spanning tree. Retrieved from https://www.nist
.gov/dads/HTML/minimumSpanningTree.html
E. Black, P. (2017, August). cycle. Retrieved from https://www.nist.gov/dads/
HTML/cycle.html
Foltin, M. (2008, August). Automated Maze Generation and Human Interaction.
Masaryk University, Faculty of Informatics, 83. Retrieved 2018-04-05, from
https://is.muni.cz/th/143508/fi_m/thesis.pdf
Gross, J. L., & Yellen, J. (1999). Graph theory and its applications. Boca Raton,
Fla: CRC Press.
Gross, J. L., Yellen, J., & Zhang, P. (Eds.). (2014). Handbook of graph theory (Second
edition ed.). Boca Raton: CRC Press, Taylor & Francis Group.
Joshi, V. (2017, September). Deep Dive Through A Graph: DFS Traver-
sal. Retrieved 2018-04-10TZ, from https://medium.com/basecs/deep-dive
-through-a-graph-dfs-traversal-8177df5d0f13
Kim, P. H., & Crawfis, R. (2015, July). The quest for the perfect perfect-maze. In
(pp. 65–72). IEEE. Retrieved 2018-04-05TZ, from http://ieeexplore.ieee
.org/document/7272964/ doi: 10.1109/CGames.2015.7272964
Kozlova, A., Brown, J. A., & Reading, E. (2015, August). Examination of
representational expression in maze generation algorithms. In (pp. 532–
533). IEEE. Retrieved 2018-04-04TZ, from http://ieeexplore.ieee.org/
document/7317902/ doi: 10.1109/CIG.2015.7317902
Prim, R. C. (1957, November). Shortest Connection Networks And Some Gener-
alizations. Bell System Technical Journal , 36 (6), 1389–1401. Retrieved 2018-
38 Chapter 6. Conclusions and Future Work
04-05TZ, from http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm

?arnumber=6773228 doi: 10.1002/j.1538-7305.1957.tb01515.x
Shaker, N., Togelius, J., & Nelson, M. J. (2016). Procedural Content Generation
in Games. Cham: Springer International Publishing. Retrieved 2018-04-
08TZ, from http://link.springer.com/10.1007/978-3-319-42716-4 doi:
10.1007/978-3-319-42716-4
Togelius, J., Yannakakis, G. N., Stanley, K. O., & Browne, C. (2011, Septem-
ber). Search-Based Procedural Content Generation: A Taxonomy and Survey.
IEEE Transactions on Computational Intelligence and AI in Games, 3 (3), 172–
186. Retrieved 2018-04-04TZ, from http://ieeexplore.ieee.org/document/
5756645/ doi: 10.1109/TCIAIG.2011.2148116
Appendix A
Maze Generation Algorithms
A.1 Prim’s Algorithm

Foltin (Foltin, 2008) credits Gross et. al (Gross & Yellen, 1999) for the following
Prim’s algorithm pseudocode:
Input: a weighted connected graph G.

Output: a minimum spanning tree T.
1. Choose an arbitrary vertex s of graph G.
2. Initialize the Prim tree T as vertex s.
3. Initialize the set of frontier edges for tree T as empty.
4. While Prim tree T does not yet span G
(a) Update the set of frontier edges for T

(b) Let e be a frontier edge for T with the smallest edge-weight.
(c) Let v be the non-tree endpoint of edge e.
(d) Add edge e (and vertex v ) to tree T.
5. Return Prim tree T.
A.2 Randomized Prim’s Algorithm

Foltin (Foltin, 2008) provides pseudocode for generating a Random Prim’s Algorithm
Maze:
1. Choose a random cell within the maze grid (given by its width and height) and
design it as a start cell.
2. Add the start cell to (by now empty) inCells set.
3. Mark cells around the start cell as frontier, i.e. add them to frontierCells set.
4. While frontierCells set is not empty:
(a) Choose a random frontier cell cF from frontierCells
39
40 Appendix A. Maze Generation Algorithms
(b) Choose a random in-cell cI adjacent to cF.

(c) Add cF to inCells
(d) Mark all out-cells around cF as frontier.
(e) Add a path between cI and cF to the maze paths set.
(f) Remove cF from frontierCells set.
A.3 Recursive Backtracker Algorithm

Foltin provides pseudocode for generating a Recursive Backtracker maze(Foltin, 2008):
1. Design a randomly chosen cell as the current cell and add it to the stack.
2. IF the current cell has any unvisited neighbors THEN
(a) randomly choose one of them and design it as the next cell
(b) add next cell to the stack
(c) create path between current cell and next cell
(d) mark next cell as the current cell
3. ELSE pop a cell from the stack and design it as the current cell
4. WHILE stack is not empty
(a) loop back to 2
A.4 Recursive Division Algorithm

Jamis Buck provides pseudocode for implementing the Recursive Division algorithm(Buck
& Carter, 2015)(Buck, 2011):
1. Begin with an empty field
2. Bisect the field with a wall, either horizontally or vertically. Add a single
passage through the wall.
3. Repeat step 2 with the areas on either side of the wall.
4. Continue, recursively, until the maze reaches the desired resolution.

Appendix B
Code Examples
B.1 Recursive Code

Example of recursive depth first search and stack-safe depth first search produced by
Albin Karlsson (Author of thesis), written in C#. Will not work out-of-the-box since
some non important functions were left out, but should provide enough guidance to
an interested developer.
class Node
{
bool isSpecial = false ;
Node [] children = new Node [4];
// ... Functions for initializing children
void removeChild ( int childIndex )

{
children [ childIndex ] = NULL ;
}
}
Node recursiveDepthFirstSearchFunc ( Node currentNode )

{
foreach ( Node child in currentNode . children )
{
if ( child . isSpecial == true )
return child ;
else
{
Node result =
recursiveSearchFunc ( child );
if ( result . isSpecial == true )
{
return result ;
}
}
}
return currentNode ;
}
41
42 Appendix B. Code Examples
Node StackSafeDepthFirstSearchFunc ( Stack < Node > stack )

{
while ( stack . Count > 0)
{
// Pop removes element from top of stack ,
and returns it .
Node currentNode = stack . Pop () ;
for ( int i = 0; i <

currentNode . child ren . Count ; i ++)
{
Node child = currentNode . children [ i ];
if ( child == NULL )
{
// Do nothing
}
else if ( child . isSpecial == true )
return child ;
else
{
// Remove child so that it ’ s
// not processed again next time
currentNode . removeChild ( i ) ;
// Add the current node to the
stack again
// to continue the child loop next
time
stack . Push ( currentNode ) ;
// Child pushed to top of stack so
that
// it is processed in the next
while loop iteration .
stack . Push ( child ) ;
// Stops the for loop
break ;
}
}
}
// No node with isSpecial == true was found .
return Node () ;
}
void main ()
{
const int numNodes ;
Node nodeNetwork [ numNodes ];
B.2. Recursive Backtracker Code 43
// ... Fill the node network , with only one node

// ... with " isSpecial " set to true .
Node result = recursiveSearchFunc ( nodeNetwork [0]) ;

print ( " Yippie ! " ) ;
else
print ( " Too bad " ) ;
Stack < Node > stack ;
// Push adds an element to top of stack .

stack . Push ( nodeNetwork [0]) ;
result = StackSafe De pth Fi rs tSe ar ch Fun c ( stack ) ;
print ( " Yippie ! " ) ;
else
print ( " Too bad " ) ;
}
B.2 Recursive Backtracker Code

Made stack-safe to prevent stack overflow. Accomplished through simulating recur-
sivity by the use of a Stack-container, and a while loop.
void recursiveBackTrack ( IntVector2 pos )
{
List < IntVector2 > directionList = new
List < IntVector2 >() ;
// initializing list of directions
directionList . Add ( NORTHDir ) ;
directionList . Add ( SOUTHDir ) ;
directionList . Add ( WESTDir ) ;
directionList . Add ( EASTDir ) ;
shuffleDirections ( directionList ) ;
Stack < stackState > theStack = new

Stack < stackState >() ;
theStack . Push ( new stackState ( pos , directionList ) ) ;
// set current cell as visited
grid [ pos .X , pos . Z ]. Visited = true ;
while ( theStack . Count > 0)

{
stackState tempState = theStack . Pop () ;
IntVector2 po = tempState . pos ;

grid [ po .X , po . Z ]. Visited = true ;
// Now loop through neighbours . If found
neighbour , call self , with neighbours
position
foreach ( IntVector2 dir in
tempState . directions )
{
Stack < IntVector2 > tempStack = new
Stack < IntVector2 >() ;
if ( IsDirCoordValid ( new IntVector2 ( po .X ,
po . Z ) , dir ) && grid [ po . X + dir .X , po . Z
+ dir . Z ]. Visited == false )
{
if ( dir == NORTHDir )
{
grid [ po .X , po . Z ]. NorthWall =
false ;
grid [ po . X + dir .X , po . Z +
dir . Z ]. SouthWall = false ;
}
if ( dir == SOUTHDir )
{
grid [ po .X , po . Z ]. SouthWall =
false ;
dir . Z ]. NorthWall = false ;
}
if ( dir == WESTDir )
{
grid [ po .X , po . Z ]. WestWall = false ;
dir . Z ]. EastWall = false ;
}
if ( dir == EASTDir )
{
grid [ po .X , po . Z ]. EastWall = false ;
dir . Z ]. WestWall = false ;
}
theStack . Push ( tempState ) ;

List < IntVector2 > tempDirs = new
List < IntVector2 >( directionList ) ;
shuffleDirections ( tempDirs ) ;
dir . Z ]. Visited = true ;
B.3. Recursive Division Code 45
theStack . Push ( new stackState ( new

IntVector2 ( po . X + dir .X , po . Z +
dir . Z ) , tempDirs ) ) ;
break ;
}
}
}
B.3 Recursive Division Code

A recursive function, it did not need to be made stack-safe. Most of it is taken from
the implementation code of Buck (Buck & Carter, 2015).
void recursiveDivision ( int X , int Z , int width , int
height , int orientation )
{
if ( width < 2 || height < 2)
return ;
bool horizontal = ( orientation == HORIZONTAL ) ?

true : false ;
int wx = X + ( horizontal ? 0 : Random . Range (0 ,

width - 2) ) ;
int wz = Z + ( horizontal ? Random . Range (0 , height
- 2) : 0) ;
int px = wx + ( horizontal ? Random . Range (0 ,

width ) : 0) ;
int pz = wz + ( horizontal ? 0 : Random . Range (0 ,
height ) ) ;
int dx = horizontal ? 1 : 0;
int dz = horizontal ? 0 : 1;
int length = horizontal ? width : height ;
int dir = horizontal ? SOUTH : EAST ;
for ( int i = 0; i < length ; i ++)

{
if ( wx != px || wz != pz )
{
if ( dir == SOUTH )
{
grid [ wx , wz ]. EastWall = true ;

if ( wz + 1 < gridX )
grid [ wx , wz + 1]. WestWall = true ;
}
if ( dir == EAST )
{
grid [ wx , wz ]. SouthWall = true ;
if ( wx + 1 < gridZ )
grid [ wx + 1 , wz ]. NorthWall = true ;
}
}
wx += dx ;
wz += dz ;
}
int nx = X ;
int nz = Z ;
int w = horizontal ? width : wx - X + 1;

int h = horizontal ? wz - Z + 1 : height ;
recursiveDivision ( nx , nz , w , h ,
chooseOrientation (w , h )) ;
nx = horizontal ? X : wx + 1;
nz = horizontal ? wz + 1 : Z ;
w = horizontal ? width : X + width - wx - 1;

h = horizontal ? Z + height - wz - 1 : height ;
recursiveDivision ( nx , nz , w , h ,
chooseOrientation (w , h )) ;
}
B.4 Randomized Prim’s Algorithm Code

void primsAlgorithm ( int startX , int startZ )
{
// start from a nodes , all adjacent nodes are
frontier .
// Pick a random frontier node , add it to the
maze . Now add the adjacent nodes to the new
node as frontier too .
// rinse repeat until no more frontier cells .
B.4. Randomized Prim’s Algorithm Code 47
List < IntVector2 > frontier = new

List < mazeLoc > inCells = new List < mazeLoc >() ;
// Add directions
List < IntVector2 > directionList = new
// initializing list of directions
directionList . Add ( NORTHDir ) ;
directionList . Add ( SOUTHDir ) ;
directionList . Add ( WESTDir ) ;
directionList . Add ( EASTDir ) ;
// frontier . Add ( new mazeLoc ( startX , startZ ) ) ;

inCells . Add ( new mazeLoc ( startX , startZ ) ) ;
grid [ startX , startZ ]. Visited = true ;
foreach ( IntVector2 dir in directionList )

{
// Add valid adjacent cells to frontier .
if (( startX + dir . X >= 0 && ( startX + dir . X <
gridX ) ) && ( startZ + dir . Z >= 0 && startZ
+ dir . Z < gridZ ) )
{
if ( grid [ startX + dir .X , startZ +
dir . Z ]. Visited == false && grid [ startX
+ dir .X , startZ +
dir . Z ]. AddedToFrontier == false )
{
grid [ startX + dir .X , startZ +
dir . Z ]. AddedToFrontier = true ;
frontier . Add ( new IntVector2 ( startX +
dir .X , startZ + dir . Z ) ) ;
}
}
}
visualizePrimSolver ( frontier , new IntVector2 (0 ,

0) ) ;
while ( frontier . Count > 0)

{
// Get current frontier cell coordinate
shuffleDirections ( directionList ) ;
int CFI = Random . Range (0 , frontier . Count ) ;
// A ) Choose random frontier cell from

frontier - list
IntVector2 CFC = new
IntVector2 ( frontier [ CFI ]. X ,
frontier [ CFI ]. Z ) ;
grid [ CFC .X , CFC . Z ]. Visited = true ;
// frontier . Remove ( frontier [ CFI ]) ;

{
// Add valid adjacent cells to frontier .
if ( IsDirCoordValid ( CFC , dir ) )
{
if ( grid [ CFC . X + dir .X , CFC . Z +
dir . Z ]. Visited == false &&
grid [ CFC . X + dir .X , CFC . Z +
dir . Z ]. AddedToFrontier == false )
{
grid [ CFC . X + dir .X , CFC . Z +
dir . Z ]. AddedToFrontier = true ;
frontier . Add ( new IntVector2 ( CFC . X
+ dir .X , CFC . Z + dir . Z ) ) ;
}
}
}

{
// If cell adjacent to this frontier has
already been visited , carve path to
it . ( only once per frontier - loop )
if ( IsDirCoordValid ( CFC , dir ) )
{
if ( grid [ CFC . X + dir .X , CFC . Z +
dir . Z ]. Visited == true )
{
carveInDirection ( dir , CFC .X ,
CFC . Z ) ;
break ;
}
}
}
frontier . RemoveAt ( CFI ) ;
}
}
B.5. Depth-first-search Algorithm Code 49
B.5 Depth-first-search Algorithm Code

solverBack fastSolveMazeReadyForVisualization ( int X ,

int Z , List < IntVector2 > SolvingPath ,
List < IntVector2 > VisitedPath )
{
List < IntVector2 > lDirectionCheck = new
lDirectionCheck . Add ( NORTHDir ) ;
lDirectionCheck . Add ( SOUTHDir ) ;
lDirectionCheck . Add ( WESTDir ) ;
lDirectionCheck . Add ( EASTDir ) ;
Stack < StackStateSolver > solverStack = new

Stack < StackStateSolver >() ;
List < IntVector2 > localSolvingPath = new

List < IntVector2 >( SolvingPath ) ;
shuffleDirections ( lDirectionCheck ) ;
solverStack . Push ( new StackStateSolver ( new

IntVector2 (X , Z ) , lDirectionCheck ,
localSolvingPath , VisitedPath ) ) ;
while ( solverStack . Count > 0)

{
StackStateSolver tempStackState =
solverStack . Pop () ;
if ( tempStackState . pos . X == gridX - 1 &&

tempStackState . pos . Z == gridZ - 1)
{
tempStackState . solvingPath . Add ( tempStackState . pos ) ;
tempStackState . visitedPath . Add ( tempStackState . pos ) ;
solvedPath = tempStackState . solvingPath ;
triedPath = tempStackState . visitedPath ;
// Solver finished . Convert from seconds
to milliseconds
return new solverBack ( true ,
( Time . realtimeSinceStartup -
startSolveTime ) * 1000 f ) ;
}
bool isValidPath = false ;
grid [ tempStackState . pos .X ,

tempStackState . pos . Z ]. SolverVisited = true ;
if ( tempStackState . hasBeenAdded == false )

{
tempStackState . visitedPath . Add ( new
IntVector2 ( tempStackState . pos .X ,
tempStackState . pos . Z ) ) ;
tempStackState . solvingPath . Add ( new
IntVector2 ( tempStackState . pos .X ,
tempStackState . pos . Z ) ) ;
tempStackState . hasBeenAdded = true ;
}
foreach ( IntVector2 dir in

tempStackState . directions )
{
if ( IsDirCoordValid ( tempStackState . pos ,
dir ) )
{
if (! grid [ tempStackState . pos . X +
dir .X , tempStackState . pos . Z +
dir . Z ]. SolverVisited )
{
if ( dir == NORTHDir )
{
if
(! grid [ tempStackState . pos . X
+ dir .X ,
tempStackState . pos . Z +
dir . Z ]. SouthWall &&
! grid [ tempStackState . pos .X ,
tempStackState . pos . Z ]. NorthWall )
{
isValidPath = true ;
}
}
if ( dir == SOUTHDir )
{
if
+ dir .X ,
dir . Z ]. NorthWall &&
B.5. Depth-first-search Algorithm Code 51
tempStackState . pos . Z ]. SouthWall )

{
}
}
if ( dir == WESTDir )
{
if
+ dir .X ,
dir . Z ]. EastWall &&
tempStackState . pos . Z ]. WestWall )
{
}
}
if ( dir == EASTDir )
{
if
+ dir .X ,
dir . Z ]. WestWall &&
tempStackState . pos . Z ]. EastWall )
{
}
}
if ( isValidPath )
{
solverStack . Push ( tempStackState ) ;
shuffleDirections ( lDirectionCheck ) ;
solverStack . Push ( new

StackStateSolver ( new
IntVector2 ( tempStackState . pos . X
+ dir .X ,
dir . Z ) , lDirectionCheck ,
tempStackState . solvingPath ,
tempStackState . visitedPath ) ) ;
break ;
}
}
}
}
}
return new solverBack ( false , 0) ;
}
Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, Sweden

Full Text 02

Uploaded by

Copyright:

Available Formats

Full Text 02

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Text 02

Uploaded by

Copyright:

Available Formats

Bachelor of Science in Digital Game Development

Evaluation of the Complexity of

Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, Sweden

Faculty of Computing Internet : www.bth.se

Background. Procedural Content Generation (PCG) in Video Games can be used

Keywords: PCG, Mazes, Labyrinth, Recursive Backtracker, Recursive Division,

6 Conclusions and Future Work 35

A Maze Generation Algorithms 39

results of an investigation of parameters aﬀecting completion time. This improve-

1.2 Research Questions

• RQ2: What connection is there between completion time/complexity, and the

Path length is explored because previous contributions by Kozlova et. al (Kozlova

1.3 Thesis Layout

2.1 Theoretical Background

2.1.2 Spanning Tree

2.1.3 Weighted Graph

2.1.4 Greedy Algorithm

2.1.5 Procedural Content Generation

2.1.6 Perfect Maze

2.1.7 Randomized Prim’s Algorithm

Randomized Prims Algorithm

Figure 2.2: Randomized Prim’s algorithm

2.1.8 Recursive Backtracker / Depth-First-Search Algorithm

The Recursive Backtracker algorithm is based on the depth-ﬁrst-search (DFS) al-

Recursive Backtracker Algorithm

Figure 2.3: Recursive Backtracker algo-

2.1.9 Recursive Division Algorithm

Recursive backtracker and Prim’s algorithm are graph-based.

Recursive Division algorithm treats the maze as a fractal - a repeating pattern

Recursive Division Algorithm

Figure 2.4: Recursive Division algorithm

2.2 Related Work

well have used a ﬁtness function favoring short paths.

Foltin made an exploratory study of human interaction with mazes. He made an

• Percentage of forward dead-ends

• Percentage of backward dead-ends

• Percentage of turns on the solution path

• Percentage of junctions on the solution path

• Percentage of cross roads on the solution path

• Percentage of decisions on the solution path

• Relative length of the solution path

An alcove is a dead-end with no turns or decisions. It has a straight short path.

An implementation will be used as the method to experimentally evaluate RQ1 and

• Follows rectangular grid; the depth-ﬁrst-search algorithm will follow a grid,

• Controllable entrance / exit; possibility to intentionally set the entrance and

• Solvable; the exit must be reachable from the entrance

• Determinism; possibility to intentionally generate the exact same maze. So

3.1 Development Tools

3.2 Implementation Details

3.3 DFS Solver and Completion Time

Figure 3.1: Shows how branches are de-

3.5 Path Length

3.6 Corridor Distribution

Figure 3.2: Shows how corridor length will

3.7 Experiment Procedure

4.1 Maze Appearance

Generated Mazes Representative of Each Algorithm

4.2 Completion Time

Comparison of Completion Time By Resolution

milliseconds Percent (%)