Maze Algorithms (1997)(astrolog.org) |
Maze Algorithms (1997)(astrolog.org) |
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.
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.
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.
Initially, I wanted to create a maze generator. But I had no idea how to write it. Creating mazes by hand, I'm slowly learning how to make them work (I've gotten waaay better than I was at the beginning). So, perhaps in the future, a maze generator that generates a daily maze seeded by the current date. Idea is to start with a simple maze every Monday and gradually increase the difficulty over the week. But I'm getting a little carried away: the more I think about it, the more I don't know how to create the maze generator.
FWIW, it's MIT licensed and available here: https://github.com/tasuki/iso-maze
Wrt sensitive controls: not sure which version you played, but I just reworked the controls a whole lot to automove to the next junction when you stop touching. It took my LLM and me a lot of time, mostly because I was searching in the dark, not entirely sure what I wanted. The controls are by far the least legible part of the codebase for me!
Does it just regurgitate the well known maze generating algorithms? These generally do not lead to mazes interesting for humans...
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.
Maze Algorithms (1997) - https://news.ycombinator.com/item?id=10101728 - Aug 2015 (10 comments)
> Infinite length Mazes: It's possible to create an infinitely long Maze (a finite number of columns by as many rows as you like) by only keeping part of the Maze in memory at a time and "scrolling" from one end to the other, discarding earlier rows while creating later rows.
> An easier way to make an infinite Maze is with Eller's or the Sidewinder algorithms, as they already make Mazes one row at time, so simply keep letting them add rows to the Maze forever.
My tiny obfuscated maze program at https://tromp.github.io/pearls.html#maze will print an infinitely long maze if you enter a negative height.
Although I guess you could have an infinitely large map and an algorithm that guaranteed connectivity. Infinite ways to fail to reach the goal. But I doubt there would be much practical benefit.
To actually answer your question it should be fairly easy to convert nearly any existing algorithm to cover an infinite area by simply tiling it. A common method to avoid boundary issues is to overlap the tiles slightly.
The requirements I've come up with are:
1. Distribution of path length for any two points of a fixed taxicab distance should be some kind of long-tail distribution.
2. In general, the path between any two nearby points should often stray far outside the smallest box that contains both of those two points. Of course, this won't apply to nearby points in the same corridor. I'm not sure how best to state this formally.
3. It should be possible to calculate the exits for any cell in O(log(N)) time where N = abs(sum of the coordinates).
And the most hazy requirement of all: the maze should look decent.
AFAICT, no such algorithm exists.
I do know of an algorithm with 'nesting' that generate mazes but results in very long walls and thus does not feel random.
What do you mean by "infinity" exactly? 2^64? 2^128? Any arbitrary bigint? Periodic boundary condition?
Why perfect mazes - does that really matter? Are these supposed to be human solvable or is this some sort of abstract art? Anything human solvable requires at least one path of (very) finite length from start to finish.
Overlapping tiles and doing nothing else produces multiple paths. It's the quick and easy solution if the goal is practicality of implementation and human oriented puzzles.
If you insist on a perfect maze an obvious solution is 2^64, a periodic boundary condition, and a space partitioning tree with many children per node (ie n >>> 2). Connectivity is determined at each level. Long uniform walls can be reduced or even eliminated by warping block boundaries in various ways; among other things, you could potentially use the maze solution at each level to assign node membership for the next level.
Connected, sure, that's table stakes. But why is being non-cyclic a desirable property? (Other than it being the definition of "perfect maze", a term I've come to despise)
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.
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.
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.