Maze Generation: Wilson's algorithm(weblog.jamisbuck.org)
weblog.jamisbuck.org
Maze Generation: Wilson's algorithm
http://weblog.jamisbuck.org/2011/1/20/maze-generation-wilson-s-algorithm
5 comments
Ah, the pleasure to see an interactive widget like the ones demonstrating the algorithm, right clicking and finding out it's not flash.
In fact, the mazes are implemented in CoffeeScript:
https://github.com/jamis/csmazes
https://github.com/jamis/csmazes
How would you express the algorithmic complexity of an algorithm like this, that incorporates a random walk which must hit a particular point before the algorithm can proceed?
In theory, this algorithm could run for any arbitrarily large amount of time. Although the probability of that is low, doesn't it make the worst-case time for this algorithm unacceptable?
In theory, this algorithm could run for any arbitrarily large amount of time. Although the probability of that is low, doesn't it make the worst-case time for this algorithm unacceptable?
You're absolutely right. Both this one and Aldous-Broder both have a worst-case where the algorithm never terminates. As for whether the algorithm is "unacceptable", that depends on the application. For games? Yeah, this is probably far from your best option for generating mazes. But for cases where you absolutely must have a uniform spanning tree, your options are limited. Wilson's is much better than Aldous-Broder, but still not perfect. Robin Houston has described a variant that combines both Aldous-Broder and Wilson (doing AB until about 30% of the field is filled, and then switching to Wilson's) which empirically improves the odds quite a bit, but as long as you're doing a blind random walk, you're pretty much never guaranteed to finish.
Ok... that's what I thought. Thanks.
By the way, thanks for this series of articles... I've found it most diverting. I guess I'm the sort of person who enjoys "recreational maze generation" :p
By the way, thanks for this series of articles... I've found it most diverting. I guess I'm the sort of person who enjoys "recreational maze generation" :p
You can bound the expected cover time of a random walk on a graph. This is an intensively studied problem:
http://scholar.google.de/scholar?q=covering+time+random+walk
iirc the expected cover time for any graph is polynomial with high probability. Something like |E|^3 or so.
http://scholar.google.de/scholar?q=covering+time+random+walk
iirc the expected cover time for any graph is polynomial with high probability. Something like |E|^3 or so.
Interestingly, even over an infinite grid you should get to your target with probability 1:
http://www.math.cornell.edu/~mec/Winter2009/Thompson/randomw...
http://www.math.cornell.edu/~mec/Winter2009/Thompson/randomw...
The worst-case is indeed arbitrarily long, but the amortized runtime can be analyzed.
See: http://en.wikipedia.org/wiki/Amortized_analysis
See: http://en.wikipedia.org/wiki/Amortized_analysis
Here is my version in Clojure: http://clojure.pastebin.com/dd5ccDkP
Runs pretty fast, even for large mazes.
Runs pretty fast, even for large mazes.
Empirically, I think I "like" the mazes this generates better than the Prim's algorithm mazes, which from what I've seen tend to look extremely uniform (haven't made one / thousands, just seen a couple). Far more computationally expensive, but unless you're making a huge maze I doubt it matters much.
So far I like the recursive subdivision algorithm best. It also has the possibility to stop the recursion for different subdivisions at different times, to generate larger dungeons in your mazes. That's not so easy to do with the other algorithms.