A maze generator needs to choose a direction, but choosing randomly from up, right, down, and left is only part of the problem. Some moves leave the grid, some enter cells already accounted for, and some violate the layout’s wall spacing. This console maze experiment separates those restrictions from the random choice itself.
Describe the legal moves first
The builder initializes a grid and a separate cell manager. The grid holds the maze’s tile values; the cell manager tracks which coordinates have been visited or otherwise accounted for. Generation adjusts the requested dimensions to odd values and initializes the border before selecting an entrance.
At the current position, the builder checks each cardinal direction. Bounds, coordinate parity, and the cell manager determine whether that direction is available. The accepted directions become bits in a mask. Up, right, down, and left each have a distinct bit, so several choices can be represented together in one value.
This gives the random generator a small interface: accept the mask, then return one permitted direction. The builder owns the geometry rules. The direction generator owns the choice among the options it receives.
Random does not have to mean independent
The direction generator remembers its previous output. If that direction is still allowed, a Bernoulli trial can repeat it. Otherwise it samples a direction and rejects choices absent from the mask. A complexity parameter changes the repeat probability, giving the implementation a way to influence runs of movement.
That is a control in the algorithm, rather than a measured description of the resulting mazes. Calling a parameter “complexity” does not itself establish how difficult a maze will be to solve, how often it turns, or what distribution of passages it produces.
Keeping somewhere to return to
As generation advances, it records positions on a path stack. When the current run has no available direction, backtracking removes positions until it finds a place with further options. The builder can then carve another passage and continue. Visited-cell tracking and the stack serve different purposes: one records which cells are accounted for, while the other records the route available for backtracking.
The scope of this example
The surviving program depends on historical logging and platform code, so it has not been built unchanged in the current environment. Its source is useful for examining the direction mask, repeat policy, and backtracking state, but there is no current runtime result here establishing completion or maze quality. The exact development relationship to my other maze and pathfinding experiments is also unresolved.