Talk:Maze generation algorithm

message: The article says "Pick a random wall from the list. If the cell on the opposite side isn't in the maze yet", but doesn't explain what the opposite is the opposite of!
The algorithm specifies to pick arbitrarily. I suggest the section rewritten.  —Preceding unsigned comment added by 84.238.88.224 (talk) 21:06, 1 April 2010 (UTC)
thread_title:  Randomized Prim's algorithm 

message: How are these two different? One uses recursion, whilst the other both keeps an explicit stack and uses recursion; other than this (rather pointless, from a programmer's perspective) implementation detail, I can't imagine how the two would produce different results.
Also, is there any reason why the description of the recursive backtracker is in between the description of the randomized Prim's algorithm and its modified version? Is it somehow the intention that the recursive backtracker is a modified Prim's algorithm? Because it doesn't look much like one.
- Anon. 2007-04-02
:Indeed, recursive backtracking is merely one way of implementing a depth-first search. (Another way is to use a stack.) Therefore I've merged the "Recursive backtracker" section into the "Depth-first search" section. I also moved the "Modified version" of Prim's algorithm into the Prim's algorithm section proper. Thanks, Cruiser1 22:52, 24 September 2007 (UTC)
thread_title:  "Depth-first search" versus "Recursive Backtracker" 

message: The Kruskal's algorithm as stated is/was slow and unnecessarily restrictive!  Kruskal's algorithm works on any connected graph, not just rectangular and hexagonal matrices.  Kruskal's algorithm does usually take O (E log E) because finding the least costly edge each time costs (log E).  In the random Kruskal's algorithm you just need to select a random edge each time, which only costs O(1).  So the cost will be number of edges times the cost to join two regions.  But it is easy to show that there are disjoint set implementations that can perform the needed union-find operations in constant time, so the total time to generate the maze is only O(E).   Kevin Saff 04:21, 7 Feb 2004 (UTC)
thread_title:  Kruskal's algorithm 

message: The comment that a maze generated "depth first" MUST have "many long corridors" is not true, in my experience. A preponderance of long corridors only occur if the random selection among the available paths (ie neighbors) is weighted towards the "directly ahead" neighbor OR recursion ONLY occurs when a change of direction occurs (thus, new branches do not occur within straight corridors, but only from turns, which can create what looks like a straight corridor, later). If the selection is unbiased, and EVERY step is recursed (or the backtracing routine is not biased against straightways) the maze will typically have some, but not a preponderance of straight corridors. Is is possible to add  bias to the algorithim so that it generates mazes of varying "curviness" along a continuum from "mostly straight" to "perfectly curvy"
Please see http://ccl.northwestern.edu/netlogo/models/community/maze-maker-2004 for a NetLogo model that generates mazes of varying curviness. (James Steiner[JPS])
I think that line means to say that the algorithm results in fewer dead ends; there are lots of paths without forks — in this sense they are strait. Perhaps it should be clarified. 65.96.153.126 03:41, 10 March 2006 (UTC)
thread_title:  Depth First  = Straight is not quite right 

message: The comment "it will typically be relatively easy to find the way to the square that was first picked at the beginning of the algorithm, since most paths lead to or from there, but hard to find the way out." is not true, in my experience. Any node on maze built as described can have from 1 to 4 exits, and that includes the start-point. For example, if the first branch works it's way around to "surround" the start-point. So, there is no inherent advantage for solving the maze in starting at the same node the maze was originally generated from.
Some statements that _can_ be made about such a maze are:
* A path exists between any two nodes in the maze
** Therefore Any two nodes on the "outside" of such a maze can be selected as the start and end: a path always exists between them.
[JPS]
: I agree: This statement should be deleted because the stating point isn't special. It is true that there's a path from each point in the maze to the starting point but this is the case with any other poin too. 46.114.154.73 (talk) 03:03, 14 June 2014 (UTC)
thread_title:  Depth First = start location is obvious is not true 

message: Why the picture for an example of the amorphous maze is linked isntead of being shown directly in the page?--TiagoTiago (talk) 17:37, 10 February 2009 (UTC)
thread_title:  Why the pic is linked? 

message: http://www.urticator.net/maze/
is that somthing that should go in the article somewhere? (like on external links or somthing) --TiagoTiago (talk) 17:39, 10 February 2009 (UTC)
replies: text: Although there are a number of interesting Maze web sites and Maze programs out there, it's important to remember that Wikipedia is not a link farm. Any links must support or expand on in a meaningful way the article purpose, namely algorithms for generating Mazes. (Yes I realize some existing links are inappropriate.) The most unique thing about the site above is how it renders 4D Mazes. Therefore a link to it would be more appropriate on the main Maze article, or better yet a more general article about how to render and interect with 4D environments. Thanks, Cruiser1 (talk) 15:26, 15 February 2009 (UTC)
thread_title:  A open source 4D (and 3D( maze game program 

message: Here's a JavaScript version of the example code given in the article. SharkD  Talk  01:11, 7 January 2011 (UTC)
thread_title:  JavaScript version of sample code 

message: I would like to request reinstating the entry that somebody removed on August 30, 2011, as below:
A maze can also be generated without the use of cells. An amorphous maze creates mazes with walls placed at totally random angles. The algorithm is based on extending the wall by a small segment at a time without crossing over a pre-existing one. 
''
The reason given for the deletion was "spam". Therefore, the new entry removes external links, although the original page referenced by the old entry added significant value to the article because the page described in detail the mathematics behind this very unconventional method of generating mazes. In my opinion, not mentioning the very existence of amorphous mazes is tantamount to a loss of knowledge.
Thank you.
Nbeverly (talk) 01:30, 31 August 2011 (UTC)
thread_title:  Non-cell-based algorithm 

message: Hello! This is a note to let the editors of this article know that :File:MAZE 30x20 DFS.ogv will be appearing as picture of the day on September 19, 2012. You can view and edit the POTD blurb at Template:POTD/2012-09-19. If this article needs any attention or maintenance, it would be preferable if that could be done before its appearance on the Main Page so Wikipedia doesn't look bad. :) Thanks! —howcheng  {chat} 16:53, 17 September 2012 (UTC)
thread_title:  [[:File:MAZE 30x20 DFS.ogv]] to appear as POTD soon 

message: Does the section "Python Code Example" really add anything to the article? I can't even tell which algorithm it's attempting to implement. -- 205.175.124.30 (talk) 01:04, 20 September 2012 (UTC)
replies: text: I just neatened it up, but yeah, its purpose does seem vague.  What really should be provided is *pseudocode* (which ironically enough, is what Python should read like, and this example doesn't.)  At least then we could decipher its purpose.  --Frizzil (talk) 07:34, 21 October 2012 (UTC)
thread_title:  Python Code Example? 

message: Do the the Life-like cellular automata mentioned really count as maze generators?  The both seem to create many, small 'mini-mazes' embedded in a larger space.  That is, the generated 'passages' are not fully connected, so that it is not always possible to reach all passages from all other passages.  I've tried various starting conditions, generation times and the like, but this always seems to be the case.  In fact it doesn't seem to make much difference which state (on/off, 0/1, whatever you want to call the cell values) you choose as 'passages' and 'walls'; you get a very similar result.
Rule B3457/S678 (I don't know if it has a name) seems like a better candidate for a maze generator.  Though it does generate some open space in the maze (i.e. 'rooms', 'chambers') it also tends to produce mazes that are more nearly fully connected (though there are still some isolated areas generated).  Works well from a 50/50 random initial grid in about 20 or so cycles.  — Preceding unsigned comment added by 109.156.183.198 (talk) 17:07, 24 May 2013 (UTC)
replies: text: I noticed that in some tests I did with those rules, thanks for giving me a rule that actually works  — Preceding unsigned comment added by 103.238.195.106 (talk) 23:21, 26 August 2020 (UTC)
thread_title:  Cellular automata? 

message: Also, why is this called recursive? As it currently stands this pseudocode is not recursive. 66.225.134.125 (talk) 16:58, 5 September 2017 (UTC)
replies: text: Based on the date of the above question I suppose it refers to this version Special:PermanentLink/786021378#Recursive_backtracker from 16 June 2017, which indeed included an iterative implementation with an explicit stack only. I have added an explicit recursive description of the algorithm in this edit Special:Diff/927108903#Recursive_backtracker on 20 November 2019. Hopefully this is clear now why this approach is 'recursive'. --CiaPan (talk) 21:48, 27 August 2020 (UTC)
thread_title:  Why is it recursive? 

message: A hexagonal maze would be nice. 71.46.106.61 (talk) 04:41, 21 March 2015 (UTC)
thread_title:  Hexagon 

message: The article text describes a modified Prim's algorithm in which for each step you "Pick a random wall from the list".  But the image "MAZE 30x20 Prim.ogv" demonstrates the classical Prim's algorithm as run against a graph with random edge weights.  There is a difference between the two, as the article text acknowledges the difference, saying "classical Prim's on a graph with random edge weights would create mazes stylistically identical to Kruskal's".  It seems to me misleading to use in the animated image a stylistically different algorithm from the one laid out in the accompanying text.
Sbj42 (talk) 23:54, 12 October 2016 (UTC)
thread_title:  MAZE 30x20 Prim.ogv doesn't match algorithm described in the text 

message: The python code examples should be removed or replaced. The first (depth-first search) example outputs a maze that only works for small sizes, and at large sizes just looks becomes a grid. The second example doesn't name the algorithm and creates a maze with no start or end. 
ElThomas (talk) 03:46, 4 November 2017 (UTC)
replies: text: One of examples has been removed on 7 November 2017 Special:Diff/809224405 and the other one on 29 January 2020 Special:Diff/938094805 (together with a C language example). --CiaPan (talk) 08:14, 16 September 2020 (UTC)
thread_title:  The Python Code Examples Have Problems 

message: The SVG image :File:Chamber-finished.svg in the 'Recursive division method' section (Special:PermanentLink/979701783#Recursive division method) is wrong - it contains an inaccessible, single-cell area in the lower-left corner.
Additionally the whole section is unsourced.
Should it be deleted? --CiaPan (talk) 08:53, 22 September 2020 (UTC)
replies: text: The entire article is already flagged with "needs additional citations for verification". The recursive division algorithm is mentioned in many sources, such as published book "Mazes for Programmers", so I wouldn't delete the whole section. The only flaw is in the picture "Illustration of Recursive Division" step 5, which indeed has an isolated cell. However that's not necessarily a bug, since recursive division first subdivides the area (see step 2 picture) and then adds doorways within those walls. Perhaps step 5 is really just near the end, before that last doorway is added? Of course, if that's so then step 5 shouldn't be titled "completed". We could fix step 5, or if we really want to remove something, then since there's already an animated GIF illustrating recursive division, we could potentially remove the set of "Illustration of Recursive Division" pictures. Thanks, Cruiser1 (talk) 23:22, 23 September 2020 (UTC)
thread_title:  Recursive division method section unsourced