Yes, this page is a good overview of the sorry state of maze generation. The maze-creating algorithms might be interesting for computer scientists, but they're terrible at creating mazes interesting for humans!
First, I'm not sure "perfect maze" is a good requirement - well placed loops make mazes more interesting. Second, "uniform" is a useless metric: generating all mazes with equal probability leads to the mazes being visibly uninteresting, with many short dead ends. Same goes for the other metrics.
Inspired by the above, I'm in the process of creating a maze game for my kid: https://maze.tasuki.org/
So far I hand-crafted the mazes. The initial idea was to generate them, but I quickly found out that generating interesting mazes was hard. And generating interesting mazes in 2.5D with with weave and without walls is even harder.
So I'm practicing maze creation. My newer mazes are much better (and take me less time to create) than the first attempts. I think eventually I'll be able to write down the algorithm I use for maze creation.
> The maze-creating algorithms might be interesting for computer scientists, but they're terrible at creating mazes interesting for humans!
Not sure what would lead you to that conclusion. There's only so much you can do with (for example) a two color palette and no lawn art but it goes without saying that there's nothing restricting an implementation to the sort of minimalist methodology that's so useful for demonstrating an algorithm for the reader.
The last time this was posted [0] someone linked this article [1] which provides a nice visual demonstration of the structural differences between a few of the algorithms (scroll down for the color floods I'm referring to). Of course this can all be implemented as a graph (ie nodes that have coordinates) rather than as a grid, empty space expanded (ie coordinates subjected to an arbitrary series of affine transformations), branches of the tree overlaid after the fact to add weave (ie rotating and translating the coordinates of subtrees), nodes expanded to represent larger areas instead of single grid cells, whatever you'd like.
Also see the modifying in blocks algorithm applied to an escheresque tileset [2] (from this article [3]) which will produce a solvable 3D maze (multi-path and multi-solution) if given an appropriate tileset.
The WFC/model synthesis article is very interesting, thanks.
Yes the color floods are stunning, but these are exactly the algorithms which do not produce very interesting mazes. In particular, I don't think the "no loops" is a good maze property - the loops just have to be interesting.
It really depends on what you mean by "interesting". The algorithms that you're complaining produce uninteresting results are minimal cores for the purpose of illustrating the theory. Simply don't use them in isolation. A perfect maze is more difficult to generate than one with loops or multiple solutions.
Assuming a simple two tone block representation simply convert some walls to pathways at random.
Given a more complex graph representation and assuming the use of a compatible data structure (ie no limitation on cycles) the conversion is similarly trivial. Add vertices between nodes at random, keeping away from the two terminal nodes and probably also making sure that there's a certain distance between the two newly interconnected nodes.
> It really depends on what you mean by "interesting".
Yes. I haven't gotten far enough in my journey to be able to formulate that.
The first insight is that the details of branching make a difference: humans don't pick the routes with the same likelihood at a crossroad.
Loops seem fine for the wrong paths looping onto other wrong paths: having to backtrack is somewhat unsatisfying, plus loops make the solving less mechanical - it's necessary to keep an eye where you'd been and where you haven't. It's possible to get confused and take the same wrong path twice, once from each direction. But certainly it matters where the loops are and how exactly they're formed - "simply convert some walls to pathways at random" is not the right way to construct them.
And I guess I think there should be one solution, though perhaps it can have few short loops somewhere in the middle (so it isn't really "one solution" anymore).
I wish there was research on how easy/difficult differently constructed mazes of a specific size are for humans to solve.
So you only want dead ends to have loops? You might try computing the depth of each node, marking the solution, and then assigning each branch off of the solution a unique color.
At that point knocking out walls only within the same color won't interfere with the solution.
Alternatively you could take care to track depth and knock out walls between different colors only when the total resulting path length would be greater than the existing solution.
Just go try stuff! All of the examples on Bostock's page that I linked earlier link to JS implementations that you could fork.
Well, I don't have "walls" - my maze is sort of 2.5 dimensions - so that complicates things somewhat. I wonder whether there's an algorithm to "lift" a 2d maze with walls into my 2.5d maze, and I think if it's possible it's WFC or model synthesis. I will go try stuff, just haven't gotten around to it yet :)
You do have walls, they're just implicit. There obviously must be a way for someone looking at it to tell which directions they are permitted to move in.
Don't think of it as an image but rather as a graph of the passable tiles. You can render the nodes and vertices in various different ways.
Yes but not each constellation of walls can be lifted into the 2.5 dimensions: it's important that two neighboring flat cells which are separated be at different heights. Also I do not want the path to be occluded.
The 2.5D rendering gives a lot of opportunities to visually obscure the insight that’s necessary to solve the maze. It makes me think that a good maze should have a “oh, duh” moment. There were a few times where the false assumption I had to resolve was very close to the starting point. Tricky stuff.
And you designed all of these by hand? That is very impressive. How many mazes are there? The way I would start automating some of this would be to build a catalog of these visually tricky blocks that require the player to resolve a false assumption. Then I think it would be a matter of stitching these together in novel ways. Maybe the stitching procedure can be implemented by expressing a constraint system and solving for a stitching that has the properties you want.
I’m on a touch screen and I would say that the movement is a little bit sensitive. Concretely this means I found myself… going in a direction I didn’t intend to. Maybe this is a skill issue on my part. I don’t have alternative controls to suggest and I probably don’t understand the mechanics of the movement enough to even suggest which parameters to tweak.
This is a great list! A while back I also enjoyed reading “Mazes for Programers” and playing around with different maze generation algorithms from that book over a holiday break. The book isn’t super deep, but it has a fun set of projects and further ideas/reading as well. https://pragprog.com/titles/jbmaze/mazes-for-programmers/
Some interesting stuff I wasn't familiar with, thanks.
I really like the book Mazes for Programmers by Jamis Buck [1].
Also, my open source Dungeon generator is a (slightly-misnamed) maze generator [2]. It produces 2D maps, and also 3D files (OBJ and MTL) for use in Blender etc. I like to think it does a more 'reasonable' job than many, but I am biased.
There's something really satisfying about reading a 1997 paper and seeing that it is still completely relevant. The fundamentals haven't changed but the scale at which we can apply them has.
36 comments
First, I'm not sure "perfect maze" is a good requirement - well placed loops make mazes more interesting. Second, "uniform" is a useless metric: generating all mazes with equal probability leads to the mazes being visibly uninteresting, with many short dead ends. Same goes for the other metrics.
Sean C Jackson makes some good mazes: https://www.seancjackson.com/
---
Inspired by the above, I'm in the process of creating a maze game for my kid: https://maze.tasuki.org/
So far I hand-crafted the mazes. The initial idea was to generate them, but I quickly found out that generating interesting mazes was hard. And generating interesting mazes in 2.5D with with weave and without walls is even harder.
So I'm practicing maze creation. My newer mazes are much better (and take me less time to create) than the first attempts. I think eventually I'll be able to write down the algorithm I use for maze creation.
> The maze-creating algorithms might be interesting for computer scientists, but they're terrible at creating mazes interesting for humans!
Not sure what would lead you to that conclusion. There's only so much you can do with (for example) a two color palette and no lawn art but it goes without saying that there's nothing restricting an implementation to the sort of minimalist methodology that's so useful for demonstrating an algorithm for the reader.
The last time this was posted [0] someone linked this article [1] which provides a nice visual demonstration of the structural differences between a few of the algorithms (scroll down for the color floods I'm referring to). Of course this can all be implemented as a graph (ie nodes that have coordinates) rather than as a grid, empty space expanded (ie coordinates subjected to an arbitrary series of affine transformations), branches of the tree overlaid after the fact to add weave (ie rotating and translating the coordinates of subtrees), nodes expanded to represent larger areas instead of single grid cells, whatever you'd like.
Also see the modifying in blocks algorithm applied to an escheresque tileset [2] (from this article [3]) which will produce a solvable 3D maze (multi-path and multi-solution) if given an appropriate tileset.
[0] https://news.ycombinator.com/item?id=10101728 [1] https://bost.ocks.org/mike/algorithms/#maze-generation [2] https://www.boristhebrave.com/wp-content/uploads/2021/10/esc... [3] https://www.boristhebrave.com/2021/10/26/model-synthesis-and...
Yes the color floods are stunning, but these are exactly the algorithms which do not produce very interesting mazes. In particular, I don't think the "no loops" is a good maze property - the loops just have to be interesting.
Assuming a simple two tone block representation simply convert some walls to pathways at random.
Given a more complex graph representation and assuming the use of a compatible data structure (ie no limitation on cycles) the conversion is similarly trivial. Add vertices between nodes at random, keeping away from the two terminal nodes and probably also making sure that there's a certain distance between the two newly interconnected nodes.
> It really depends on what you mean by "interesting".
Yes. I haven't gotten far enough in my journey to be able to formulate that.
The first insight is that the details of branching make a difference: humans don't pick the routes with the same likelihood at a crossroad.
Loops seem fine for the wrong paths looping onto other wrong paths: having to backtrack is somewhat unsatisfying, plus loops make the solving less mechanical - it's necessary to keep an eye where you'd been and where you haven't. It's possible to get confused and take the same wrong path twice, once from each direction. But certainly it matters where the loops are and how exactly they're formed - "simply convert some walls to pathways at random" is not the right way to construct them.
And I guess I think there should be one solution, though perhaps it can have few short loops somewhere in the middle (so it isn't really "one solution" anymore).
I wish there was research on how easy/difficult differently constructed mazes of a specific size are for humans to solve.
At that point knocking out walls only within the same color won't interfere with the solution.
Alternatively you could take care to track depth and knock out walls between different colors only when the total resulting path length would be greater than the existing solution.
Just go try stuff! All of the examples on Bostock's page that I linked earlier link to JS implementations that you could fork.
Don't think of it as an image but rather as a graph of the passable tiles. You can render the nodes and vertices in various different ways.
> You do have walls, they're just implicit.
Yes but not each constellation of walls can be lifted into the 2.5 dimensions: it's important that two neighboring flat cells which are separated be at different heights. Also I do not want the path to be occluded.
The 2.5D rendering gives a lot of opportunities to visually obscure the insight that’s necessary to solve the maze. It makes me think that a good maze should have a “oh, duh” moment. There were a few times where the false assumption I had to resolve was very close to the starting point. Tricky stuff.
And you designed all of these by hand? That is very impressive. How many mazes are there? The way I would start automating some of this would be to build a catalog of these visually tricky blocks that require the player to resolve a false assumption. Then I think it would be a matter of stitching these together in novel ways. Maybe the stitching procedure can be implemented by expressing a constraint system and solving for a stitching that has the properties you want.
I’m on a touch screen and I would say that the movement is a little bit sensitive. Concretely this means I found myself… going in a direction I didn’t intend to. Maybe this is a skill issue on my part. I don’t have alternative controls to suggest and I probably don’t understand the mechanics of the movement enough to even suggest which parameters to tweak.
Again, great work.
I really like the book Mazes for Programmers by Jamis Buck [1].
Also, my open source Dungeon generator is a (slightly-misnamed) maze generator [2]. It produces 2D maps, and also 3D files (OBJ and MTL) for use in Blender etc. I like to think it does a more 'reasonable' job than many, but I am biased.
- [1] http://www.mazesforprogrammers.com
- [2] https://github.com/kcartlidge/Dungeon
Maze Algorithms (1997) - https://news.ycombinator.com/item?id=10101728 - Aug 2015 (10 comments)