Maze generator & solver · qwen3.8-27b

Let's write a single-file maze app. A 25x15 maze, recursive backtracker animation, A* solver animation, buttons, legend.

There's a bug: I'm leaving the `width2=""` attribute on the canvas, and it gets overwritten by canvas.width inside the JS — well, that's fine, but let's delete it. Also, the `animateSolution` function is defined inside `startSolving` before it's used — that's fine. And the `drawPathUpTo` trick that clears solutionPath and restores it — it works but it's hacky. Actually there's a subtle issue: `solutionPath.length = 0; solutionPath.push(...saved)` mutates the array — fine.

Also, in startGeneration, generateMazeSteps carves walls first, and then initWalls() resets them; after that, steps are reapplied. But genProgress's steps reference the `d` object with wall/opp names — those are fine.

Wait: inside tickGeneration, `walls[s.y][s.x][s.dir.wall] = false; walls[s.y - s.dir.dy][s.x - s.dir.dx][s.dir.opp] = false;` — this is correct.

Another concern: the token of `startSolving` — after generation completes, phase = "solving", startSolving(token). Fine.

Replay: startSolving uses astar(walls) — good, it uses the existing walls.

Delete the extraneous attribute and test in the browser.

Wait, in my edit I used a weird \r character — did I type a literal \r? Let me check the file.

Alright, that's clean. Next, let's test it in the browser.

Generation is animating correctly — the carving is progressing, start is in the upper-left, goal in the lower-right, and the legend is being displayed. Next, during animation, test a New Maze click and the solver. Wait for generation to complete (25*15=375 steps ÷ 6 per tick = about 63 frames ≈ 1 second), then A* execution (8/frame, about 375 cells = about 47 frames ≈ 0.8 seconds), and path drawing. Let me click New Maze right now (in the middle of generation) and take a screenshot.

The new maze got cleanly replaced during the animation (new carving pattern from the top-left). Next, wait for generation to complete, then check the solver in progress and the final path. Wait a bit, then take a screenshot during the solver.

Generation takes 375 steps ÷ 6 steps/tick ≈ 63 frames ≈ 1.05 seconds, then solver exploration starts. The solver explores 375 cells ÷ 8 = 47 frames ≈ 0.78 seconds, and after that the path is displayed one cell per frame (probably around 40–60 cells ≈ 1 second). Let's take a screenshot right now.

Problem: The status displays "Solved!" but no solution path is shown at all, and no explored cells are shown either. It's possible the sleep exceeded the total animation time, and the final frame got drawn... but the final frame should display the path. Wait — the issue is: inside `startSolving`, when exploration completes, it calls `animateSolution(token, ...)`, which progressively reveals the path. The final screenshot shows a fully-carved maze with no purple path. Why?

Looking at drawPathUpTo: it does `ctx.clearRect` and then sets solutionPath temporarily and calls draw(). At the end, solutionPath = the whole path. Final state should display the full path.

Hmm, but the screenshot shows no path. Could the animation have been canceled? token is genToken, and since we didn't press a button, token should still match... no wait — when we clicked New Maze, genToken was incremented, then startSolving(token) was called with the current token. No problem.

Wait — let me check: in the tick when i >= order.length, after setStatus and draw(), it calls animateSolution. Inside animateSolution, step() checks token and draws. The final path is drawn via the drawPathUpTo trick. In drawPathUpTo it does `const saved = solutionPath.slice()` but — solutionPath is the `path` itself (assigned via `solutionPath = path` in startSolving). Then it sets `solutionPath = path.slice(0, n)` — this reassigns the local binding... no, solutionPath is a module-level `let`. Reassigning is fine. draw() uses the module variable. OK.

Hmm, wait, could a JS error have happened and the animation stopped at the "Solved!" status? No — "Solved!" only gets set right before animateSolution. After that the path should be drawn.

Let me check: maybe I'm inspecting at a moment when... no, the status shows solved.

Possible bug: in tick, if i >= order.length after the for loop... `for (let j = 0; j < perTick && i < order.length; j++, i++)`. order's length is 375. i advances by 8 each frame. No problem.

Actually wait — a real bug candidate: `order` contains `key(0,0)` at the start, and neighbors are pushed with each relaxation. That's fine.

Let me check the console for errors — no errors in console, just sandbox warnings. Hmm.

Let me look at draw() more carefully: the solution path is drawn after explored/carving fills, and before the start/finish squares. Path is drawn in purple with strokeStyle. Should be visible...

Wait — `animateSolution` is a function declared inside `startSolving`, declared with `function` after its use site? It's called inside the `tick` closure, which is called via rAF after declaration. No problem.

Hmm, actually, could the problem be that the screenshot was taken after the path was drawn, and then... no, the path should be persistent.

Let me debug in the browser: inspect with a script? The browser tools only have reload/inspect/click/key/type/scroll/screenshot/motion. "inspect" — let me run that to see the console state. Actually, let me click Replay Solver, immediately screenshot, and check the mid-exploration frame, and after a while the final frame.

Actually wait — I think the problem is the rAF inside the sandboxed iframe might be throttled, or... but the status updates and the maze drawing worked.

Let me re-examine drawPathUpTo once more:

```
function drawPathUpTo(n) {
  ctx.clearRect(...);
  const saved = solutionPath.slice();
  solutionPath = path.slice(0, n);
  draw();
  solutionPath.length = 0;
  solutionPath.push(...saved);
}
```

`path.slice(0, n)` — `path` is the original complete path array from astar. OK. draw() draws solutionPath. No problem.

Hmm, one possibility: after the final tick, at p === path.length, drawPathUpTo draws the full path. The last screenshot should show it. It doesn't.

Wait a second — could `astar` have returned an empty path (found = null)? Then order would be non-empty (all 375 cells), exploration finishes, status "Solved!", animateSolution with path.length = 0 → step() executes p = min(1, 0) = 0, drawPathUpTo(0) draws nothing, p < path.length is false → stop. So an empty path means no purple line is shown!

Why would A* fail to find? The walls are... check: inside tickGeneration, walls are applied with `walls[s.y][s.x][s.dir.wall] = false; walls[s.y - s.dir.dy][s.x - s.dir.dx][s.dir.opp] = false;`. In generateMazeSteps, the direction d has dx,dy pointing toward the neighbor; the wall on the current cell is `d.wall`, and the neighbor is at cur + (dx,dy). The reverse application uses s.x - dx... wait: the step s = {x: pick.nx, y: pick.ny, dir: pick.d}. So s is the new cell. Its neighbor (the cell from which we carved) is at s - d = (s.x - d.dx, s.y - d.dy). Correct: walls[s.y][s.x][d.wall] is the wall on s facing direction d — hmm, is that right?

In generation: walls[cur.y][cur.x][d.wall] = false — the wall on the current cell in direction d (toward the neighbor). Then walls[ny][nx][d.opp] = false — the wall on the neighbor cell in the opposite direction.

Step records pick = {x: nx, y: ny, dir: d}. In tick: walls[s.y][s.x][s.dir.wall] = false sets the wall on the new cell in direction d. But in generation it set the wall on the current cell in direction d and the wall on the new cell in direction opp! So the tick generation is carving the wrong wall: for the new cell, it removes the wall in direction d (facing the next cell in that direction), not the wall in direction opp (facing the previous cell).

So the tick-carved maze is wrong — a different maze from generateMazeSteps' walls (which get discarded). The maze drawn might still be a valid maze? Let me think: each step carves walls[s][d] (from the new cell in direction d = the direction from the parent to this cell... no wait, d points from parent toward the child, so from the child in direction d is a cell beyond). So the maze carved by the tick is: for each parent→child move, remove the wall of the child in the direction of motion. This is not the correct pairing — the wall of the parent in direction opp is never removed. So the passages are shifted: a passage is carved between the child and the next cell in the same direction — this might carve into cells that weren't the intended neighbor, creating loops or disconnects.

So the displayed maze is actually incorrect, and A* might still find a path... but the screenshot shows no path. Hmm, but A* should find a path if connected. Maybe the shifted carving is leaving the maze disconnected? Probably yes: for the last move (when the child is a dead end) — child in direction d: removing a wall there might be a duplicate, or it might connect two cells that should be walled off elsewhere. Disconnects are possible.

Actually wait — is the visible maze really a valid perfect maze? Visually it looks plausible. But per the analysis, the walls are wrong. Example: moving right from (0,0) to (1,0): generation removes (0,0).right and (1,0).left. Tick removes (1,0).right — carving between (1,0) and (2,0)! And (1,0).left still has a wall. So the start is walled off → A* can't even move from (0,0) → found = null → no path. That explains it.

Fix: in tickGeneration, apply walls correctly: the step should store both endpoints. Better approach: save step = {from: {x,y}, to: {x,y}, dir} or save a pair. In generateMazeSteps push {x: pick.nx, y: pick.ny, dir}, and the cur cell is stack[length-2]... simpler: store {cx, cy, nx, ny, wall, opp}.

Let me fix it: in generateMazeSteps record steps.push({fx: cur.x, fy: cur.y, x: pick.nx, y: pick.ny, wall: d.wall, opp: d.opp}), with the first step {fx:0,fy:0,x:0,y:0,wall:null}.

In tickGeneration: if s.wall: walls[s.fy][s.fx][s.wall] = false; walls[s.y][s.x][s.opp] = false.

Also, to verify the maze's validity, add a quick connectivity check? Can I use a browser script? The browser tool has no eval. I can test the generator logic directly in node to verify: extract the algorithm and run BFS connectivity in node. Let's do that after the fix.

Also, to make the replay check "explored follows open passages" more visible, the exploration animation is fast (8/frame, 375 cells → 47 frames). Well, that's fine.

Let me apply the fix.

Also, I'll remove the unused initial `genProgress = generateMazeSteps();` — no, let's keep it. That's because it generates the steps, and afterwards initWalls gets reset and reapplied. It works correctly: generateMazeSteps returns the steps (the walls are also carved into `walls` but discarded). Then initWalls() clears them, and re-applies step by step. Good.

To confirm connectivity and that a path exists, let's verify the algorithm standalone in Node.

pathOpen: false — but this might be a bug in my verification script, not the maze. The wall name I used in A* was `d` obtained from the N map: "top"/"bottom"/"left"/"right" — same names. Path check: for adjacent cells a, b: if a.y < b.y, then the direction from a to b is "bottom", not "top"! I had it written as `(a.y<b.y?"top":"bottom")` — that's wrong: if b is below a (b.y > a.y, i.e., a.y < b.y), then the wall is "bottom". In other words, my checker is inverted. Let me fix the check: d = a.x===b.x ? (b.y>a.y ? "bottom" : "top") : (b.x>a.x ? "right" : "left").

Logic is verified. Next, retest in the browser: reload, and capture the generation and solver stages.

Generation animation looks correct (start cell is connected, walls are open between carved cells). Next, wait about 1.2 seconds for generation to complete and catch the solver's mid-exploration (after generation, exploration takes about 0.8 seconds). Generation: 375 steps / 6 = 63 frames ≈ 1.05 seconds. To catch the mid-exploration, sleep for 1.5 seconds and then take a screenshot.

Generation takes about 63 frames (about 1 second), and the solver's exploration takes about 47 frames (about 0.8 seconds). After sleeping for 1.5 seconds, it might have progressed to a mid-stage of the solver or to a completed state. Taking a screenshot.

With this, the maze is fully generated, the explored region (yellowish) is displayed, and the purple solution path from the green start point to the red endpoint is passing through the open passages — visually confirmed. The path is following the corridors.

Next, test that Replay Solver works on the existing maze (walls don't change). Click it and take a screenshot midway through exploration.

The replay works: the walls haven't changed from before, the exploration is restarting from the start point (a small yellow region), and the path is being redrawn gradually. All good, no issues.

One more check: "New Maze" is already covered. I could also click New Maze again to confirm a clean replacement and that the console is error-free. Console was clean. Just to be safe, I'll quickly do one more New Maze test and a final screenshot to confirm the console is clean, then report back.

New Maze cleanly cancels and starts a new generation — the old exploration/path have been removed. Console is clean (only harmless sandbox-related iframe warnings from the harness). Done. Report.