Looking at the output of Eller's algorithm, I have to say that it's not the one I'd go with. Here's a visualisation of many maze algorithms: https://www.jamisbuck.org/mazes/ - the "recursive backtracker" algorithm featured at the top of the list (comes in a parallelizable variant) is the most popular answer for this StackOverflow Q&A: https://stackoverflow.com/questions/38502/whats-a-good-algor... To get a sense of w…
Eller’s Algorithm (2012)
21–29 of 29 posts
Re: Eller’s Algorithm (2012)
#22My initial designs for doing it by hand (since my stack space is limited) was to draw the outline of the correct solution and then fill in dead ends and other passages. If they watched me making it, though, it became very easy to solve, and the complexity of the maze depended on how well I did at designing the main solution.
So I did a bunch of research on maze algorithms and some experimentation of my own. Eller's was one I considered but without being able to take notes it was hard to keep track of the set structure. Recursive division is fairly easy to do by hand but creates ugly mazes.
The other constraint that I had was that I was designing mazes that were created by wall addition, rather than passage carving (limitations of the media) so many of the algorithms just couldn't apply (like recursive backtracking), or were tricky to figure out how to translate to a wall addition version.
The algorithm I settled on is what Think Labyrinth calls the "Perfect" wall addition algorithm. It generates perfect mazes and is capable of generating all mazes (and depending on how you choose segments, it can be made uniform, but my human brain based random number generator is limited). Basically you choose a spot on any wall at random, and start drawing a line from there. The line can fork, and turn, and wind all around, but it can never touch another wall. Then, at some point, you pick up the crayon and start again at another random point. Now whenever I see a maze I can't help but look at the structure of the walls, and see the forest of trees rooted on the outer edge rather than the open passages in the maze itself.
Re: Eller’s Algorithm (2012)
#23Looking at the output of Eller's algorithm, I have to say that it's not the one I'd go with. Here's a visualisation of many maze algorithms: https://www.jamisbuck.org/mazes/ - the "recursive backtracker" algorithm featured at the top of the list (comes in a parallelizable variant) is the most popular answer for this StackOverflow Q&A: https://stackoverflow.com/questions/38502/whats-a-good-algor... To get a sense of w…
Does anyone happen to know which of those algorithms are equivalent, under the following definition of equivalent? • Maze generation algorithms A and B are equivalent if for any maze that A can generate, it is possible for B to generate that maze too, and vice versa. For those pairs of algorithms that are equivalent, what pairs are equivalent under this stronger definition? • Maze generation algorithms A and B are eq…
Re: Eller’s Algorithm (2012)
#24I wonder which algorithms are most easily generalised to three or more dimensions. Also what would be the best way to visualise and navigate a 4d maze? I can imagine one where the maze structure changes as you go forwards or backwards in time, and in each cell you may or may not be able to time travel. The number of time coordinates wouldn't have to be very large to make this fiendishly difficult.
Re: Eller’s Algorithm (2012)
#25I wonder which algorithms are most easily generalised to three or more dimensions. Also what would be the best way to visualise and navigate a 4d maze? I can imagine one where the maze structure changes as you go forwards or backwards in time, and in each cell you may or may not be able to time travel. The number of time coordinates wouldn't have to be very large to make this fiendishly difficult.
That 4d structure sounds like a very steep jump in complexity. I love it, and I imagine I might never finish one.
Re: Eller’s Algorithm (2012)
#26This other referenced article helped me figure out why this was a big deal: http://weblog.jamisbuck.org/2010/12/29/maze-generation-eller... Basically, you can lazily generate a maze of infinite length . That's pretty cool.
(I had the same thought and wondered if e.g. PacMan256 etc. were using this.)
Re: Eller’s Algorithm (2012)
#27This other referenced article helped me figure out why this was a big deal: http://weblog.jamisbuck.org/2010/12/29/maze-generation-eller... Basically, you can lazily generate a maze of infinite length . That's pretty cool.
But, presumably, you might end up with a maze that you can't get from the left edge to the right edge because the joining hole in the middle hasn't been generated. Which would be less than fun to play. (I had the same thought and wondered if e.g. PacMan256 etc. were using this.)
I went ahead and implemented it in TypeScript (https://www.npmjs.com/package/lazy-eller) and that would only require a minor modification to the final row sub-algorithm to permit additional downward connections.
Re: Eller’s Algorithm (2012)
#28I wonder which algorithms are most easily generalised to three or more dimensions. Also what would be the best way to visualise and navigate a 4d maze? I can imagine one where the maze structure changes as you go forwards or backwards in time, and in each cell you may or may not be able to time travel. The number of time coordinates wouldn't have to be very large to make this fiendishly difficult.
For https://github.com/gliese1337/M4ZE.js (a prototype 4D maze navigation game), I used a 4D specialization of Prim's algorithm. There is no time travel involved--it's just straight-up 4 fully equivalent spatial dimensions, with full 4D maneuverability and no privileged directions. At any given time, the maze is visualized as a 2D projection of a 3D hyperplanar slice through the maze, and one type of control action is to rotate your viewing hyperplane.
It is actually far easier to navigate than I initially thought it would be when I started working on it. I recently implemented a 4pi-steradian all-around view to make it a little bit easier, but the bump in navigation ease is minor (though I kept it because it's cool, and allows for tricks like running the maze entirely backwards). User testing so far indicates that kids and teenagers adapt to it quite quickly, while most adults have significantly more trouble.
Re: Eller’s Algorithm (2012)
#29I wonder which algorithms are most easily generalised to three or more dimensions. Also what would be the best way to visualise and navigate a 4d maze? I can imagine one where the maze structure changes as you go forwards or backwards in time, and in each cell you may or may not be able to time travel. The number of time coordinates wouldn't have to be very large to make this fiendishly difficult.
Anything based on graph traversal generalized trivially. And any maze-generation algorithm by definition will generate a spanning tree, so you can always post-process the generated trees to re-embed the graph in an arbitrary number of dimensions. For https://github.com/gliese1337/M4ZE.js (a prototype 4D maze navigation game), I used a 4D specialization of Prim's algorithm. There is no time travel involved--it's just…