views:

1408

answers:

12

Hey,

What are the possible ways to solve a maze?
Ive got two ideas, but I think they are not very elegant.

Base situation: We have a matrix, and the elements in this matrix are ordered in a way that it represents a maze, with one way in, and one out.

My first idea was to send a robot through the maze, following one side, until it's out of the maze. I think this is a very slow solution.

The second one passes through every successive item marked with 1, checks where it can go (up, right, down, left) chooses one way and it continues its path there. This is even slower than the first one.

Of course it's a bit faster if I make the two bots multi-threaded at every junction, but thats also not the best way.

There needs to be better solutions to send a bot through a maze.

EDIT
First: Thanks for the nice answers!

The second part of my question is: What to do in the case if we have a multi-dimensional graph? Are there special practices for that, or is the answer of Justin L. usable for that too?
I think it's not the best way for this case.

The third question:
Which of these maze solver algorithms is/are the fastest? (Purely hypothetically)

+13  A: 

Have a look at the A* pathfinder algorithm.

cypher
Thanks, this is a better representation of that what i couldn't explain because of my poor english, but thanks :) On it to read the whole one
Nort
+2  A: 

How about building a graph out of your Matrix and using Breadth First Search, Depth First Search or Dijkstras Algorithm?

Kungi
+10  A: 

Lots of maze-solving algorithms exist:

http://en.wikipedia.org/wiki/Maze_solving_algorithm

http://www.astrolog.org/labyrnth/algrithm.htm#solve

For a robot, Tremaux's algorithm looks promising.

willoller
+5  A: 

Great site: http://www.astrolog.org/labyrnth/algrithm.htm

genesiss
+72  A: 

You can think of your maze as a tree.

     A
    / \
   /   \
  B     C
 / \   / \
D   E F   G
   / \     \
  H   I     J
 / \
L   M
   / \
  **  O

(which could possibly represent)

        START
        +   +---+---+
        | A   C   G |
    +---+   +   +   +
    | D   B | F | J |
+---+---+   +---+---+
| L   H   E   I |
+---+   +---+---+
    | M   O |
    +   +---+
    FINISH

(ignoring left-right ordering on the tree)

Where each node is a junction of paths. D, I, J, L and O are dead ends, and ** is the goal. Of course, in your actual tree, each node has a possibility of having as many as three children.

Your goal is now simply finding what nodes to traverse to to find the finish. Any ol' tree search algorithm will do.

Looking at the tree, it's pretty easy to see your correct solution by simply "tracing up" from the ** at the deepest part of the tree:

A B E H M **

Note that this approach becomes only slightly more complicated when you have "loops" in your maze (i.e., when it is possible, without backtracing, you re-enter a passage you've already traversed through). Check the comments for one nice solution.

Now, let's look at your first solution you mentioned, applied to this tree.

Your first solution is basically a Depth-First Search, which really isn't that bad. It's actually a pretty good recursive search. Basically, it says, "Always take the rightmost approach first. If nothing is there, backtrack until the first place you can go straight or left, and then repeat.

A depth-first search will search the above tree in this order:

A B D (backtrack) E H L (backtrack) M ** (backtrack) O (backtrack thrice) I
(backtrack thrice) C F (backtrack) G J

Note that you can stop as soon as you find the **.

However, when you actually code a depth-first search, using recursive programming makes makes everything much easier. Even iterative methods work too, and you never have to explicitly program how to backtrack. Check out the linked article for implementations.

Another way of searching a tree is the Breadth-First solution, which searches through trees by depth. It'd search through the above tree in this order:

A (next level) B C (next level) D E F G (next level)
H I J (next level) L M (next level) ** O

Note that, due to the nature of a maze, breadth-first has a much higher average amount of nodes it checks. Breadth-first is easily implementing by having a queue of paths to search, and each iteration popping a path out of a queue, "exploding it" by getting all of the paths that it can turn into after one step, and putting those new paths at the end of the queue. There are no explicit "next level" commands to code, and those were just there to aid in understanding.

In fact, there is a whole expansive list of ways to search a tree. I've just mentioned the two simplest, most straightforward way.

If your maze is very, very long and deep, and has loops and crazies, and is complicated, I suggest the A* algorithm, which is the industry standard pathfinding algorithm which combines a Breadth-First search with heuristics...sort of like an "intelligent breadth-first search".

It basically works like this:

  1. Put one path in a queue (the path where you only walk one step straight into the maze). A path has a "weight" given by its current length + its straight-line distance from the end (which can be calculated mathematically)
  2. Pop the path with the lowest weight from the queue.
  3. "Explode" the path into every path that it could be after one step. (i.e., if your path is Right Left Left Right, then your exploded paths are R L L R R and R L L R L, not including illegal ones that go through walls)
  4. If one of these paths has the goal, then Victory! Otherwise:
  5. Calculate the weights of the exploded paths, and put all of them back into the queue (not including the original path)
  6. Sort the queue by weight, lowest first. Then repeat from Step #2

And that's A*, which I present specially highlighted because it is more or less the industry standard pathfinding algorithm for all applications of pathfinding, including moving from one edge of the map to another while avoiding off-road paths or mountains, etc. It works so well because it uses a shortest possible distance heuristic, which gives it its "intelligence". A* is so versatile because, given any problem, if you have a shortest possible distance heuristic available (ours is easy -- the straight line), you can apply it.

BUT it is of great value to note that A* is not your only option.

In fact, the wikipedia category of tree traversal algorithms lists 97 alone! (the best will still be on this page linked earlier)

Sorry for the length =P (I tend to ramble)

Justin L.
+1 for ascii art tree
willoller
heh, added ascii maze for fun. hope it aids in understanding how to get a tree from a maze.
Justin L.
@Justin: Good answer. If the maze has loops then it becomes a graph. You can still traverse it like a tree if, instead of recursion, you iterate and use a seperate stack structure and check the stack for a node before you visit it to avoid looping.
Andre Artus
+1 for the schema, but would do -1 for the length ;)
Dominique
If you have a way of marking a path as visited, you can also avoid endless loops.
Andre Artus
@Dominique: Why -1 for the length?
Andre Artus
I would have simply explained it via recursive programming with a markup for the path already visited, but still really nice explanation ;)
Dominique
Yeah and it's so long nobody will read down to my answer boo hoo
willoller
@Justin L: Check your tree, I believe F should be a leaf node to J, not C.
Andre Artus
@Andre -- thanks; I drew the wrong line on the ascii maze >.<; also, I sort of side-stepped the looping graph as trivial because of the exact reason you said, but I guess I could have been more explicit. I'll mention your comment.
Justin L.
@Dominique - I mentioned the depth-first recursive solution, but I figured that the asker was asking for more of an in-depth analysis of programmatic maze solving, and "the possible ways". While I by no means supplied all of the possible ways, I wanted to show how the problem could be approached as a graph/tree theory problem =)
Justin L.
Very nice answer!
echo
FWIW, automatic program deadlock checkers are actually equivalent to depth first searches of graphs, where branches represent nondeterminism. It's just that the encoding of the graph – a program – is rather deeply non-trivial.
Donal Fellows
Royal answer! Kudos
mizipzor
Its a very good, and well detailed answer. Respect! :)
Nort
I'm assuming that a priority queue would be a good ADT to use for the A* algorithm, then, given your description of it?
JAB
@JAB a Priority Queue is definitely a good implementation, as the abstraction would take care of sorting, and picking the next node. What I am describing is, basically, a queue used as a Priority Queue.
Justin L.
+3  A: 

This is one of my favorite algorithms ever....

1) Move forward
2) Are you at a wall?
2a) If yes, turn left
3) Are you at the finish?
3a) If no, go to 1
3b) If yes, solved
Nate Noonen
What happens in this algorithm if the entire maze was a hallway with one right turn? :)
Mike Sherov
Ahh! you would be trapped forever!!
willoller
@Mike S: "Marching up and down the square!"
Andre Artus
I think the author was trying to describe "wall following", where you basically just follow the wall on your left (or right) side.
Gabe
@Gabe, yeah, Intro to CS class, took me 4 hours to come up with the solution on my own. Wall following is not without its caveats or failures...
Nate Noonen
+2  A: 

Hmmmm, I vaguely remember a solution involving a stack back in compsci class in college...does anybody remember more?

Jan Kuboschek
+7  A: 

An interesting approach, at least I found it interesting, is to use cellular automata. In short a "space" cell surrounded by 3 "wall" cells turns into a "wall" cell. At the end the only space cells left are the ones on route to the exit.

If you look at the tree Justin put in his answer then you can see that leaf nodes have 3 walls. Prune the tree until you have a path.

Andre Artus
I rather like this elegant solution, and it reminds me a lot of the [Dead End Filling Algorithm](http://www.astrolog.org/labyrnth/algrithm.htm#solve) posted by willoller
Justin L.
+2  A: 

Just an idea. Why not throw some bots in there in the monte carlo fashion. Let's call the first generation of bots gen0. We only keep the bots from gen0 that have some continuous roads in this way:
-from the start to some point
or -from some point to the end

We run a new gen1 of bots in new random dots, then we try to connect the roads of the bots of gen1 with those of gen0 and see if we get a continous road from start to finish.

So for genn we try to connect with the bots form gen0, gen1, ..., genn-1.

Of course a generation lasts only a feasibil finit amount of time.

I don't know if the complexion of the algorithm will prove to be practical for small data sets.
Also the algorithm assumes we know start and finish points.


some good sites for ideas:
http://citeseerx.ist.psu.edu/
http://arxiv.org/

+1  A: 

I had a similar problem in one of my University Comp. Sci. courses. The solution we came up with was to follow the left hand wall (right hand wall will work just as well). Here is some pseudocode

While Not At End
    If Square To Left is open,
        Rotate Left
        Go Forward
    Else
        Rotate Right
    End If
Wend

That's basically it. The complex part is keeping track of which direction your facing, and figuring out which grid position is on your left based on this direction. It worked for any test case I put up against it. Interesting enough the Professors solution was something along the lines of:

While Not At End
    If Can Go North
        Go North
    ElseIf Can Go East
        Go East
    ElseIf Can Go South
        Go South
    ElseIf Can Go West 
        Go West
    EndIf
Wend

Which will work well for most simple mazes, but fails on the a maze that looks like the following:

SXXXXXXXXXXXXX
   X         X
   X         X
   X         X
 XXX         X
 X X         X
 X XXXXXXXXXXX     XXXE
 X                 X
 XXXXXXXXXXXXXXXXXXX

With S and E being the start and end.

With anything that doesn't follow the wall, you end up having to keep a list of the places you have been, so that you can backtrack if necessary, when you fall into a dead end, and so that you don't get caught in a loop. If you follow the wall, there's no need to keep track of where you've been. Although you won't find the most optimal path through the maze, you will always get through it.

Kibbee
@Kibbee: I suspect that you did not give the full algorithm, because this one spins/occilates at the entrance. If you are trying the Wall Follower keep in mind that if the exit is inside an island (surrounded by a path) it will just loop.
Andre Artus
+1  A: 

If the robot can keep track of its location, so it knows if it has been to a location before, then depth-first search is the obvious algorithm. You can show by an adversarial argument that it is not possible to get better worst-case performance than depth-first search.

If you have available to you techniques that cannot be implemented by robots, then breadth-first search may perform better for many mazes, as may Dijkstra's algorithm for finding the shortest path in a graph.

Norman Ramsey
+1  A: 

Same answer as all questions on stack-overflow ;)

Use vi!

http://www.texteditors.org/cgi-bin/wiki.pl?Vi-Maze

It's truly fascinating to see a text editor solve an ascii-maze, I'm sure the emacs guys have an equivalent ..

schemathings
Or play Rogue !
belisarius