The Applicability of Uninformed and Informed Searches to Maze Traversal Computer Science 242: Artificial Intelligence Dept. of Computer Science, University of Rochester Nicole Dobrowolski Abstract: There are many strategies for maze traversal: always keeping your right hand on the wall of the maze, using a string to escape the Greek labyrinth, and the relevant strategy here, state-space search. I implemented three java classes to explore the functionality of three different searches. The results of these searches, when applied to the traversal of a twodimensional maze, can be expanded to the three-dimensional realm of Quagents in the Quake II game using a Socket connection to generate an agent in Quake2UR. Keywords: State-space, Search, Maze, Quagent, Quake Background and Motivation: Mazes serve as a useful backdrop for state-space searching. An environment that is divided up into equally sized units can be used to simulate states. In the case of maze traversal, there are some states that cannot be accessed and others that lead to dead ends. When a specific start state and goal state are provided, the accuracy and efficiency of search algorithms can be tested. Russell and Norvig [1] define state space as the set of accessible states from a specified initial state. For a search algorithm, this means choosing a state or states from the set of accessible states and determining if the goal state is reachable from that state or states. I chose to explore the efficacy of two uninformed searches and one informed search. The Breadth-first and Depth-first searches are referred to as uninformed because they perform the same search no matter what the context. As applied to maze traversal, I would predict that these searches would be very inefficient. Depending on how many dead ends a maze possesses, an uninformed search would waste time exploring these dead ends. This wastefulness is especially true of the Breadth-first search which will explore every possible path and thereby take forever to run if not constrained. The Depth-first search could take equally long, but will in most instances perform better than the Breadth-first search. Depending on the goal's location in the Depth-first search tree, it could be found right away if it is on the outer branch of the tree being explored as deepest. The application of an informed search is much more promising. My informed search is the A* search. The A* search is a version of the best-first search wherein the evaluation function applied to each node is the sum of the estimated cost from the child's state to the goal (as determined by an appropriate heuristic) and the actual cost of traversing from the current state to its child. Using the Manhattan Distance heuristic, a move cost of 2 units, turn cost of 1 unit, I intend to show that the A* search is superior for maze traversal. In order to apply these findings to a more realistic scenario (as opposed to solving 2D mazes), I used the URQuake system to serve as a 3D maze exploration environment. The instructions generated by the above search types can be utilized by a Quagent to traverse a maze. The Quagent is an agent in the Quake world that can be instructed to perform actions using the protocol defined in [2]. Methods: I designed a program in the Java programming language that would take as input a text (*.txt) file and print output to both the command line console and a new text file. The input must specify the dimensions of the maze, followed by its structure and the coordinates of the start and goal. The structure of the maze is indicated using '1's and '0's where the zeros represent traversable space and the ones represent walls. Coordinates are on the two-dimensional axis of rows and columns with a third dimension of direction added to account for turning. See Appendix 1 for sample input. Once the map structure input is received by the program (MazeIO.java), it constructs its own map based on the grid of '1's and '0's. This map is in the form of a three-dimensional array. Access to the map is based on [row][column][direction]. However, although there are four directions allowed (north, south, east, and west), the third dimension of the array has a length of five. The added length is relevant as a time saving device. The row and column indices of the array represent a state. From each state, there are four possible directions. If there is no wall precluding traversal in a particular direction, that direction, as indicated by its corresponding integer index, is marked with a '0'. The directions are indicated as follows: north is represented by the integer 0,
east by 1, south by 2 and west by 3. The fifth slot in the array is marked with a 0 so long as any of the preceding slots are marked by a 0. If all of the preceding slots are marked by 1 and therefore are inaccessible, marking the fifth slot with a 1 allows the search algorithms to skip over that state and not bother to explore its obvious futility. This primary processor of input and output then calls on one of three search algorithms, as specified by the user in a command line argument following the specification of the text file. The Breadth, Depth, and Astar classes contain search methods to perform Breadth-first, Depth-first, and A* searches, respectively. All three of these classes call on the Maze class to retrieve successors, that is, to determine the state-space of the current state. The Maze class uses the map array created in the MazeIO class to determine the accessible states from the current state. The Maze class contains an additional method which is called upon by the Astar class to calculate the evaluation function for each node in the search tree. The nodes of the search tree are represented by instances of the TreeNode class. The TreeNode class assembles a node to briefly represent a state. The TreeNode has static variables which can be used to access the coordinates of the state as well as the estimated cost determined for that state by the evaluation function of the Maze class. A final class, Turn, contributes to the maze traversal by providing arrays which access the cost for turning from direction a to direction b and the String instructions for which direction to turn in order to get from direction a to direction b. The evaluation function uses the array of cost values for calculation and the MazeIO class uses the array of String directions to formulate the output. The output itself comes in two forms. The program prints directly to the command line the contents of the input text file and a list of one word instructions for traversal of the maze. It also prints output to a new text file with the added information of the number of nodes in the search tree visited by the chosen algorithm. See Appendix 2 for sample output. I was able to use Rotondo and Sloan's map generation program [3] to create Bitmap image files of several maps. In order to translate these maps into the proper input format, I wrote a program to examine the pixels of the image and print out the results to a text file. Unfortunately, I was unable to get this program to work for Bitmap image files and so had to save each file generated by the code available at [3] in.gif format. Once saved as a.gif image, the program is able to translate the image to text. I then used these randomly generated maps to test the three algorithms specified above. The second part of the experiment involved the actual Quagent application. By modifying example code from the URQuake build, I built a program which takes as input the output text file of the MazeIO program and uses it to send instructions to a Quagent. I was able to modify the code provided in the tarball at [4] and convert the DrunkenMaster class to a MazeRunner class. I also got rid of some of the unnecessary functionalities such as checking the Quagents well being because that didn't seem relevant for maze traversal. I also modified the code to account for this and also to allow for command line arguments. These arguments can be used to indicate which text file with search instructions to read and there is an optional argument where the user can specify their own distance (in Quake units) for the move command. The default is 64 Quake units, such as they are. Results: In order to test the Breadth-first, Depth-first, and A* algorithms, I took maps generated by [3] and saved them in the.gif file format. Then I ran them through my conversion program which created a text file of the proper input format. I tested each algorithm on a series of five 21x21 mazes. When I tried to test the Breadthfirst algorithm, I found that a half-hour later, the program was still running with no sign of an end in sight. I then proceeded to make another set of mazes with smaller dimensions in the hopes that Breadth-first would reach completion. However, when I tested Breadth-first search on the new 11x11 mazes, the same problem occurred. Interestingly enough, the Breadth-first search has little difficulty with a non-randomized map of dimensions 11x11. This map has a highly constrained setup wherein there are limited dead ends, if any. Basically, Breadth-first search does fine if there is only one possible path though it still examined 21,402 nodes where Depth-first and A* search examine 17. As a result of this difficulty getting the Breadth-first search to cooperate with randomized mazes, I instead focused on the comparison between Depth-first search and A* search. In the five 21x21 mazes tested, the A* search consistently performed better than the Depth-first search, as predicted. A* search visited approximately half the nodes that Depth-first search did in each instance with an average of 74 nodes visited per
maze. Depth-first search, though not bad in comparison to its uninformed search sibling Breadth-first search averaged 163.6 nodes visited per maze. On a larger scale Depth-first search would most likely become time and space prohibitive. Nodes Visited 200 180 160 140 120 100 80 60 40 20 0 maze1 maze2 21 x 21 Mazes maze3 Although the smaller mazes were created in an attempt to induce the Breadth-first algorithm to cooperate, they yield interesting data about the other two searches. Again, for the most part, A* search visits half as many nodes as Depth-first search, the fifth 11x11 maze had the surprising result wherein Depth-first search performed better than A* search. Because of this the averages are a little closer this time with A* search having an average of 26.8 nodes visited per search and Depth-first search having an average of 36.8 nodes visited per search. The Quagent implementation used the output of these searches to instruct a Quagent to navigate a maze in the Quake II environment. The transfer from single word commands from the MazeIO output to instructions for a Quagent were difficult mainly in terms of determining move distance. In my experimentation running the MazeRunner Quagent in David Sloan's build [5] I found that the Quagent had a tendency to travel an extra.8 Quake units. This addition of distance units does not occur reliably enough simply subtract from the total distance every time. In order to correct for this I set it up so that a subtraction of one would occur or not occur based on a random number generator. Unfortunately, I was unable to actually test the Quagent in a maze so I have no results to report on that. Discussion: The results of my search comparisons were as predicted. The informed search, A*, was found to be superior to the Depth-first and Breadth-first searches and the Depth-first search was found to be superior to the Breadth-first search. As it turns out, not only is the Breadth-first search inefficient for maze traversal, it is wholly inappropriate. It's insistence on searching every single node in every single branch may get the solution eventually, but not soon enough to be worth anything. The Breadth-first search is especially worthless in the presence of the Depth-first and A* searches. However, there are cases of Depth-first search which could perform just as badly as Breadth-first search. If, for example, the node representing the goal state were on the opposite side of the search tree from where the search started, it could take a very long time to find the goal. The havoc that goal location in the search tree can wreak on Depth-first search results is exemplified by the node code for the fifth 11x11 maze. In this instance, the Depth-first path stumbled across the goal state by exploring less nodes than even the A* search. This has more to do with the luck of the draw in that the solution maze4 maze5 Figure 1: A graph of the two algorithms, Depth-first and A* indicating how many nodes each visited in their search for a solution to each 21x21 maze. See Appendix 2 for maze input. Nodes Visited 50 40 30 20 10 0 maze1 maze2 11 x 11 Mazes maze3 maze4 maze5 Figure 2: A graph of the two algorithms, Depth-first and A* indicating how many nodes each visited in their search for a solution to each 11x11 maze. See Appendix 2 for maze input. A* Depth-first A* Depth-first
path must have been on the traversal of the outer edge of the search tree, whereas even with its heuristic, A* searched some dead ends and thereby visited more nodes. Although I did not time how long each search method took, the time-complexity, and the disparity between the Breadth-first search and the other two searches can be explained using big-oh notation. Because Breadth-first search explores every branch at each level of the search tree, if the goal is at depth d and the branching factor is b, then we know that Breadth-first search is O(b d+1 )[1]. Since we know the branching factor is at most four, for the four possible directions of travel, this means the search is O(4 d+1 ), which is still exponential and horrifyingly slow. In a worst-case scenario, Depth-first search is also exponential. If m is the depth of the search tree, even if d < m, it is still O(b m )[1]. Again, we know the branching factor to be limited by an upper bound of 4, which certainly beats a branching factor of greater magnitude, but is still unhelpful if the Depth-first search starts off down a path on the opposite side of the tree from the desired path. It is also the case that Depth-first search may not find the shortest solution to a maze, though for the most part, mazes tend not to have multiple solutions. Despite, the overall success of the A* search, it could be improved upon by using a better heuristic. However, it seems that the Manhattan Distance heuristic is particularly appropriate for maze traversal, perhaps more so than for the 8 square puzzle. Given that the agent traversing the maze can only move in four directions, the shortest path between two states while ignoring the walls is the Manhattan Distance. Though a quality maze, with quality corresponding to the degree of difficulty, would not have such a direct path, it is a possibility. When running the algorithms on text files and outputting instructions, the state-space problem solving aspect of maze traversal is abstracted away. However, once the results of these algorithms are applied to the Quagent's world, it is more obvious that each move takes the agent to a new space. From that space it is necessary to search the states that are reachable from that state. In this instance, this is done by offline search, but similar search techniques could be used for online searching. If the Quagent had some way of knowing what his goal was, such as when away teams on Star Trek follow a single they receive on their tricorders, the A* search would only need an altered evaluation function. Otherwise, exploration would have to in some way be uninformed or else the search could be done offline and the online exploration would be pointless. Although I was unable to test the MazeRunner program in an actual 3D maze, it should function fairly well so long as the inaccuracies inherent in the "WALKBY" command do not pile up. Hopefully, the practice of occasionally subtracting 1 unit from the total distance to be traveled will help account for that problem. References: [1] S. Russell and P. Norvig. Artificial Intelligence: A Modern Approach, Second Edition. New Jersey: Pearson Education, Inc, 2003 [2] C. Brown, P. Barnum, D. Costello, G. Ferguson, B. Hu, and M. Van Wie. "Quake II as a Robotic and Multi-Agent Platform." Robotics and Vision Technical Reports, [Digital Repository], (2004 Oct.), Available at HTTP: http://hdl.handle.net/1802/1042. [3] M. Rotondo and D. Sloan. "Everything You Ever Wanted to Know About Randomly Generated Quake Mazes." [Online Document], [2005 Feb 8], Available at HTTP: http://www.cs.rochester.edu/u/brown/242/assts/mazedoc.html. [4] Available at HTTP: http://www.cs.rochester.edu/research/quagents/releases/quake2ur-latest.tgz [5] D. Sloan. "Getting Started With Quagents, 2005." [Online Document], Jan. 2005, [2005 Feb 8], Available at HTTP: http://www.cs.rochester.edu/u/brown/242/quagenthints05.html.
Appendix 1 (Sample Input): maze1.txt: 21 21 1111111111 100000000010100010021 101011101110101111101 101010001000100000001 111011101010111010111 101000100010100010001 101011101110101011111 100000101010101000001 111011111011101011111 100000001010101000001 111111101010111110111 101000000010000000001 101011101110111011111 100010000000001000001 1110100101 100010000000101000101 101111101110101011111 101000101000001000001 101011101011111110101 130000101010000000101 1111111111 1 19 0 19 1 0 smallmaze5.txt 11 11 10001010021 10111010101 10100000101 10101111101 10101000001 10101110111 10000010001 11111111101 13000000001 1 9 0 9 1 0
Appendix 2 (Sample Output): Output to command line console after command java MazeIO smallmaze4.txt -d: 11 11 10001000021 11101010111 10000010001 10111111111 10100010001 10111011101 10000000101 10101010101 13101010001 1 9 0 9 1 0 smallmaze3-asolution.txt: 11 11 10000010021 10111010101 10101000101 10101110111 10001000001 11111010101 10000010101 11101111111 13000000001 1 9 0 9 1 0 Nodes examined: 20