Maze generator & solver · grok-4.7

I will build a canvas-based maze generator and solver visualization using HTML, CSS, and JavaScript.

I am planning the implementation details. The maze will use a 25 by 15 grid with randomized recursive backtracking to ensure a perfect spanning tree. Generation will animate wall carving in real time. After completion, a BFS or A* solver will trace the path and highlight it. New Maze will cancel any active animation and generate a fresh layout. Replay Solver will reuse the existing walls without modification.

I will use a dark theme with thick walls. Start will be green, finish red, exploration blue, and the solution gold. A legend will mark each state. Animations will run via setTimeout or requestAnimationFrame with cancel tokens.

I am refining the layout. The viewport will be 1200 by 800 pixels, with cells sized around 28 to 32 pixels. I will use an explicit stack instead of recursion so each wall-carving step can be animated in sequence.

I have finalized the algorithm details. The generator will use an explicit stack to carve walls and step backtracking through each cell. The solver will run BFS on open passages, record parent cells, and reconstruct the path for highlighting. New Maze will increment a generation ID, clear pending timeouts, reset the grid, and restart generation.

I will disable the Replay Solver button while generation is active. A fresh maze cannot be replayed until the current animation completes.

I am finalizing the visual layout. The page will have a header, New Maze and Replay Solver buttons, a status line, a canvas, and a legend. I am setting cell size to 32 pixels and padding to 16 pixels. Walls will be drawn as grid lines between cells.

The canvas will be 800 by 480 pixels plus padding. Walls will be drawn as 3 to 4 pixel lines. I am defining eight cell states: empty, visited during generation, current carving cell, start, finish, explored, frontier, and solution path. The legend will mark Start, Finish, Exploration, and Solution. Generation animation will run at roughly 8 milliseconds per step, taking about five to six seconds.

I am adjusting the animation timing. Generation steps will run at 15 milliseconds per frame so the wall carving remains clearly visible and New Maze can be clicked mid-animation. The solver will follow at a similar pace, then highlight the final path more slowly. I am also adding a run ID counter to prevent race conditions when canceling active animations.

I am refining the animation token logic. A single `runId` counter will cancel stale animations for both generation and solving. New Maze increments the token and triggers a fresh grid, while Replay increments it only to launch the solver on the existing maze. I am now writing the polished CSS.

The visual palette is set to dark navy with amber accents and system fonts. Status messages will read "Carving passages…", "Solving with BFS…", and "Path found (N steps)". Each wall will be stored as a four-direction object, and the solver will only traverse cells where the connecting wall has been removed.

I am finalizing the drawing order. Cell floors will be filled first, then state colors, then walls, and finally start and finish markers. Exploration will use a semi-transparent blue inset so walls remain visible. The solution path will be drawn as a thick polyline through cell centers.

I will highlight the current cell during generation and paint carved cells in a muted teal so progress is obvious. After generation finishes, I will reset all cell colors to neutral floors before the solver begins, letting it paint exploration states cleanly. The entire implementation will live in a single file. I am also preparing to verify the output in the browser.

I am now writing the HTML structure with a canvas and legend. I will use requestAnimationFrame with a time accumulator for smooth, cancellable animation. A sleep helper using Promises will manage step delays.

I am refining the animation cancellation logic. A `timers` array will hold every timeout ID so a single `cancelAll()` call can clear all pending steps at once. The `runId` counter will also be checked after each `await` inside an async generator to prevent stale animation frames from continuing after a New Maze click.

I noticed a subtle bug in the animation cancellation logic. When `cancelAll` clears pending timeouts, those promises never resolve, so any old async generator awaiting a step will hang forever. This is acceptable because the stale animation is discarded anyway.

I realized the runId check must happen at the very start of every timeout callback. If a callback were to fire after newMaze resets the grid, it would draw onto the fresh grid instead of the old one. Because JavaScript is single-threaded, this race is unlikely unless an await yields control between the timer scheduling and execution.

I am now writing the `schedule` helper. It will queue callbacks with a frame counter and token so each animation step can be cancelled cleanly.

I decided against the `schedule` helper. An async/await loop with token checks and cleared timeouts is simpler. If a timeout fires after `newMaze` increments the runId, the promise resolves and the old generator exits on its next token check.

I am locking in the animation timing. Generation will step every 16 milliseconds so wall carving remains clearly visible. The solver will run at 10 milliseconds per step, and the final path highlight will use 18 milliseconds. A full 375-cell maze should take roughly twelve seconds to generate.

I am locking in the canvas resolution. Each cell will be 34 pixels, with a 3-pixel wall line and a 2-pixel inset so walls do not get covered by cell fills. The outer border will always be drawn as walls.

I have locked in the exact hex color values for every cell state. The floor will be dark navy, carved cells muted teal, the current cell bright cyan, exploration blue, frontier light blue, and the solution path gold. The start marker will be a green circle and the finish marker a red diamond. During solving, the generation current-cell highlight will be hidden so the solver can paint its own states cleanly. After BFS completes, the final path will animate cell by cell with a gold overlay and a polyline, and the status line will display the total step count.

I will add a stats line showing the grid dimensions and confirming the maze is perfect. I verified that randomized recursive backtracking produces a valid spanning tree, and BFS on the dual graph of open passages finds the shortest path. Replay Solver will reset exploration colors without altering the walls array, so the existing maze stays intact.

New Maze will reset every wall to true and clear visited flags. A subtle grid will keep uncarved cells darker than carved ones during generation, and the backtracking stack head will move visibly as the algorithm retreats. Live animation will replace any step recording. Console logging will be kept minimal, and I may expose the maze state on the window for debugging.

I am adding an aria-live region for screen-reader accessibility. I have drafted the Fisher-Yates shuffle helper and the recursive backtracking generation loop, which tracks the current cell and filters valid unvisited neighbors.

The generation loop now removes walls between the current cell and its chosen neighbor, marks that neighbor visited, pushes it onto the stack, and redraws before pausing. The initial cell is already marked visited so it appears carved immediately; unvisited cells render as solid blocks until their walls are cut. I am now beginning to draft the solver.

The solver is now being written. It uses a BFS queue with a `seen` array and a `parent` map to track visited cells and reconstruct the path. Each step checks whether the current cell is the finish, then scans open passages in all four directions while skipping walls and already-visited neighbors.

The solver marks frontier cells when they are enqueued. It reconstructs the path by backtracking through the parent map from finish to start, then reverses the array. The final path will be drawn cell by cell.

A dev assertion will verify that the reconstructed path never crosses a wall. The UI will use system fonts, button hover states, and a disabled replay style. A CSS title icon and canvas border with shadow will add polish. The canvas will scale to devicePixelRatio for crisp lines.

I am finalizing the canvas sizing logic. The element will be sized to `COLS * CELL + 1` pixels, and its backing store scaled by `devicePixelRatio` so lines stay crisp on high-DPI screens. I am also deciding how to draw walls: filled rectangles at integer coordinates will avoid blurry lines from centered sub-pixel positioning.

I refined the cell geometry. Each cell will be 30 pixels, with a 4-pixel wall strip and a 26-pixel interior. The canvas will be sized to `COLS * CELL + WALL` by `ROWS * CELL + WALL`. I will draw the entire grid as filled walls first, then punch out open interiors so the maze looks carved.

I decided to draw the canvas by filling each cell interior with its state color, then painting wall rectangles on top of the edges where walls exist. This avoids the need to punch out open passages and keeps the wall lines crisp.

Mirrored walls mean drawing only the top and left edges of each cell, plus the outer right and bottom borders, avoids double-drawing gaps. The start and finish markers are being drawn. The solution path will be rendered as a rounded 4-pixel polyline.

The start and finish markers will be circles and diamonds inset at radius one-quarter of the cell size. The solution path will sit safely above the walls because its center-to-edge distance exceeds the wall thickness. Unvisited cells during generation will render in a darker blue-gray, visited cells in a warmer tone, and the current cell in an accent color. These generation states are not required to appear in the legend.

A `phase` variable will toggle between generation, solving, and finished states. The `cellColor` function now returns distinct colors for the start and finish cells, a bright cyan current cell during generation, a dark blue-gray unvisited cell, and a warm brown solution path.

I am finalizing the legend: a green square for the start and a rose square for the finish. During solving, exploration colors will be drawn as inset rings so the start and finish badges stay visible.

The legend will add a blue square for exploration and a gold square for the solution path. Status messages will show live progress, such as "Generating maze… 120/375 cells" and "Exploring… 80 cells visited". The replay button is disabled only while generation is active; it remains enabled during solving so the user can restart the solver on the same walls, and clicking new maze cancels any running animation.

The page will auto-start generation on load. The layout is designed to fit within a 1200 by 800 viewport without scrolling. A note will be added to confirm the generated maze is perfect.

The cell size is fixed at 32 pixels, making the canvas 800 by 481 pixels and centered. A `runId` token will cancel stale animations when the user clicks New Maze or Replay Solver. A `wait` helper and a `stopAnimations` cleanup routine will manage the async generation and solving timers.

The solver will reset exploration and solution flags without altering the wall array. The New Maze handler cancels pending timers, reinitializes walls, disables replay, redraws the grid, and starts generation with a fresh token. The Replay Solver handler does the same but skips wall recreation when the maze is already ready. I verified that incrementing runId before passing it as a token prevents stale animation callbacks from interfering.

A `pathIsOpen` helper will validate the reconstructed solution path. It checks that each step moves exactly one cell in a cardinal direction and that no wall blocks the passage. If the path is invalid, it logs an error to the console so the browser check can catch it.

The generation delay is set to 16 milliseconds per step so the user can click New Maze while the animation is still running. The solver will validate that the reconstructed path ends at the finish cell.

A thin progress bar will sit beneath the status line for visual polish. A flood-fill check after generation will confirm every cell is reachable, logging an error if any are isolated. The directional constants and wall removal logic are being double-checked.

I confirmed the mirrored wall logic: clearing a cell's right wall and its neighbor's left wall prevents double-drawing gaps, while the outer right border is drawn explicitly. I am now adding letter badges for Start and Finish.

The Start and Finish badges are drawn as filled circles with bold white text centered inside. They render after the solution line so they stay visible above the path. Frontier and visited cells share the same exploration color.

A footer hint will clarify that New Maze restarts generation while Replay Solver preserves the existing walls. The buttons will use the exact labels required by the spec. The canvas will be the sole visualization element, not a DOM grid. A status element with id="status" will expose live phase text for inspection.

A `data-phase` attribute on the body will expose the current phase for inspection. A `data-cells` attribute will track how many cells have been carved. The generation animation will look like a waffle grid that gradually opens as walls are removed, making progress obvious.

The current cell during generation will be highlighted by a bright cyan inset stroke. The stack path was considered but skipped to avoid clutter. A potential hang from rapid replay was noted.

I am refining the `wait` helper to store each pending promise and its timeout ID in a `waiters` array. When the user clicks New Maze, the cancel routine will flush and reject all outstanding timers immediately. This prevents a backlog of stuck promises from rapid button mashing.

The `wait` helper now stores each pending promise and its timeout ID in a `waiters` array. The `stopAnimations` routine increments the run token and immediately rejects every outstanding timer, preventing a backlog of stuck promises from rapid button mashing.

The status line will also display a live progress fraction during generation.

The solver animation delay is being increased to 25 milliseconds per cell so the current-cell highlight stays visible throughout the path.

Generation delay is set to 18 milliseconds per step so the wall removal is clearly visible. The solver delay is 22 milliseconds per BFS step, making the full run about 17 seconds total. This gives enough time to inspect visible steps and start the solver early.

Generation delay is being reduced to 12 milliseconds per step so the full animation finishes in about nine seconds. The page title will be "Maze Generator & Solver". The CSS will avoid generic AI gradients and use a distinctive visual style.

The CSS will use a deep ink and brass/teal editorial palette with radial gradients for depth. The New Maze button will be filled teal, and the Replay Solver button will be an outline brass style. I am ready to write the file.

The BFS solver will mark frontier cells when they are expanded, then draw the frame once before dequeuing the next cell. The start cell is marked explored immediately, and the finish cell receives both the visited style and its badge once dequeued.

The solution path will draw on top of the exploration trail so both remain visible. A `resetGrid` helper will fully clear all cell flags and wall states before each new generation begins, ensuring the previous view is completely erased before the first carve step.

The wall layout is fully verified: top and left edges are handled explicitly, internal walls align with the right and bottom neighbors, and solver movement uses the same wall flags. A flood-fill connectivity check will run after generation and log to the console only if any cell is unreachable. The app element will expose `data-phase`, `data-carved`, and `data-path-ok` attributes for inspection. The browser tool will be invoked during the generation animation to capture the progress.

The browser tool has no wait action, so I will use bash sleep between screenshots to capture the generation animation. I am writing a complete index.html and centering the app at 920 pixels wide.

The canvas will be 800 by 480 pixels, with each cell sized at 32 pixels so the 3-pixel walls look crisp. A small square cursor will mark the active cell during generation for clearer screenshots. Buttons will use `type="button"` to prevent accidental form submission, and text selection will be disabled to avoid jitter. The final status message will report the shortest path length and confirm that every cell is reachable via a unique simple path.