Maze generator & solver · mimo-v2.5

Let me build this. I'll write a single index.html with canvas maze generator/solver.

Plan:
- Grid 25x15 cells.
- Recursive backtracking with explicit stack, animated by steps per frame.
- Then solver: BFS animated.
- Buttons: New Maze, Replay Solver.
- Colors legend.

Let me write the file, then verify with browser tool (screenshot, inspect, click during animation).

Implementation details:
- Cell: walls {N,E,S,W} booleans.
- DFS carving: pick random unvisited neighbor, carve wall, push; backtrack.
- Animation: process a chunk of steps per frame (e.g., 3 steps/frame) with requestAnimationFrame; token/generation counter to cancel.
- After carve done, wait, then run BFS: queue, visited animation, then reconstruct path and highlight with pulse.
- Canvas size: cell 44px? 25*44=1100 wide, 15*44=660 high. Viewport 1200x800. Fine, with device pixel ratio scaling. Let's use cell size 40 → 1000x600 plus wall margins. Good.

Colors:
- background dark, walls light.
- start green, finish red/gold.
- exploration: cells visited shown as filled tint (blue), frontier queue maybe lighter.
- solution path: orange/yellow thick line through cell centers crossing open passages.

Draw: cell fill for visited exploration, walls drawn as lines on top.

Cancellation: use a runId; each async loop checks runId === currentRun, else abort.

Let me write it.

Also status text, legend, stats (cells carved, cells explored).

BFS animation: expand k steps per frame, drawing queue and visited. Then path trace animated along centers.

Write code carefully.

Canvas interactions: maybe hover? Not required. Keep simple.

Let me write the file.

Draw function: full redraw each frame from state — simpler.

State: maze walls array, genProgress (set of carved cells / visited during generation), explored set, frontier set, path array, pathProgress.

Generation visualization: show current cell highlighted, stack trail, carved cells slightly filled.

I'll implement:

```js
const COLS=25, ROWS=15;
```

Walls stored per cell as bitmask or array of 4 walls; initialize all true.

Carve: stack-based DFS.

Per animation frame: do `speed` operations; each op: if current cell has unvisited neighbors, pick one, remove walls both sides, mark visited, push; else pop (mark backtrack).

Drawing walls: for each cell, draw N wall if cell.w[0], W wall if cell.w[3]; plus outer E and S borders. Standard.

Solver BFS: from start index 0 to end COLS*ROWS-1.

Path highlight: draw polyline through centers; since only open passages, line crosses openings.

Also draw entrance/exit openings? Start/finish at cell centers with markers; no need to break outer walls.

Buttons: New Maze (regenerate), Replay Solver (re-run BFS on current maze; disabled during generation).

Status line messages.

Let me write it now. Also a speed slider? Optional, nice but not required. Maybe add speed control — small extra; keep it, low risk. I'll add a range input affecting steps per frame. Fine.

Verify with browser: reload, screenshot during generation, click New Maze mid-animation, screenshot, wait for solver, screenshot, inspect console.

Write code.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Maze Generator & Solver</title>
<style>
:root{ ... }
body { font-family: system-ui...; background:#0f1220; color:#e8eaf6; display:flex; flex-direction:column; align-items:center; }
...
</style>
</head>
<body>
<header>...</header>
<div class="toolbar"> buttons, speed </div>
<canvas id="maze"></canvas>
<div class="legend">...</div>
<div id="status"></div>
<script>...</script>
</body>
</html>
```

Canvas sizing: CSS width min(100%,1040px) etc. I'll set canvas internal resolution to logical size * dpr and scale.

Logical: cell = 40, pad = 10 → width = 25*40+20 = 1020, height=15*40+20=620.

CSS: canvas { width: min(96vw, 1020px); height:auto; }

Drawing:

drawMaze():
- clear background (#141829 or so).
- exploration fill: for explored cells fill rect inset with rgba(56,132,255,0.22); frontier cells lighter.
- carved/generation: cells visited during generation filled rgba(120,255,180,0.10)? Maybe generation visited cells fill subtle.
- solution path: stroke through centers, color #ffb020, lineWidth 6, round caps; plus animated partial (pathProgress count of points drawn).
- start/finish markers: rounded rect fill green/red with labels S/F.
- current carving cell: bright highlight.
- walls: strokeStyle #cfd6ff lineWidth 2.5.

Order: fills, path, walls on top, markers.

BFS frontier (queue) draw as outline or lighter fill.

Let me write final code.

For animation timing: use rAF loop; each frame compute ops = speed (e.g. slider 1..20, default 4 for carving... carving needs 375 cells; at 4 ops/frame≈ 1.5s. Good). BFS375 cells similar.

I'll write the code now.

Also "Replay Solver uses existing maze without changing walls" — implement by resetting solver state and running BFS again.

Console errors check afterwards.

Code:

```js
const canvas=document.getElementById('maze');
const ctx=canvas.getContext('2d');
const COLS=25, ROWS=15, CELL=40, PAD=12;
const W=COLS*CELL+PAD*2, H=ROWS*CELL+PAD*2;
const dpr=Math.min(window.devicePixelRatio||1,2);
canvas.width=W*dpr; canvas.height=H*dpr;
ctx.scale(dpr,dpr);
```

State object:

```js
let walls, gen, solver, runId=0, mode='idle';
```

walls: Int8Array(COLS*ROWS*4)? Use array of arrays. I'll use Uint8Array with4 per cell, 1 = wall present.

idx(r,c)=r*COLS+c.

Generation:

```js
function startGeneration(){
  runId++; const myRun=runId;
  walls=new Uint8Array(COLS*ROWS*4).fill(1);
  gen={visited:new Uint8Array(COLS*ROWS), stack:[0], order:[], current:0};
  gen.visited[0]=1; // visited set
  solver=null; mode='generating';
  setStatus('Carving maze…');
  requestAnimationFrame(tickGen)
}
```

genStep():
```js
const s=gen.stack; let cur=s[s.length-1]; gen.current=cur;
const r=(cur/COLS)|0, c=cur%COLS;
const nb=[]; if(r>0&&!gen.visited[cur-COLS])nb.push([cur-COLS,0,2]); // north: wall idx0 of cur, idx2 of above
...
```
Wall order: 0=N,1=E,2=S,3=W. Removing north wall of cur: walls[cur*4+0]=0 and walls[above*4+2]=0.

If nb nonempty: pick random, remove walls, mark visited, push, order.push.
Else pop.

Generation ends when stack empty.

tickGen: loop speed times genStep, then draw; if done → mode='paused', schedule solver start after ~600ms (via setTimeout with runId check), status 'Maze ready'.

tickSolve: BFS expand.

BFS state:
```js
solver={dist:Int16Array fill -1, parent:Int32Array fill -1, queue:[0], head:0, visitedCount:0, phase:'explore', path:[], pathPos:0}
```
dist[0]=0. expand: if head<queue.length: u=queue[head++]; for each open neighbor (wall==0): if dist[n]<0 {dist[n]=dist[u]+1; parent[n]=u; queue.push(n)}. When head reaches queue.length → phase='trace': build path by backtracking from end (guaranteed reachable). Then animate pathPos increment up to path.length, then mode='done', status "Solved: path length N".

Draw explored = cells with dist>=0 (fill blue), frontier = queue cells from head..end (lighter/outlined), current expanding cell highlight.

Replay Solver: if mode is 'generating' disable; else runId++ and restart solver, keep walls/gen display? Keep generation trail shown or clear? I'll clear exploration and re-run. Buttons disabled state updates.

New Maze: runId++ cancels; startGeneration.

Also key: Replay disabled while generating.

Write it.

Path drawing: points = path.slice(0, pathPos+1) centers. Also draw a glowing end marker.

Let me write the full file.

Legend items: Start (green), Finish (red), Exploration (blue), Frontier (light cyan), Solution (amber), Walls (white line).

Status text + stats: cells carved, explored, path length.

Now write.

Let me verify maze correctness with a standalone node simulation of the carve algorithm (extract logic), and also test in the browser. First, let's run a quick node test replicating carveStep to confirm perfect maze properties (375 carved, connectivity, unique path).

Actually easier: open in browser and inspect via JS evaluation? The browser tool doesn't allow evaluating arbitrary JS... it has "inspect" action which shows DOM/console. Let me use a node test for the algorithm logic, plus browser screenshots for visuals.

Carving animation is visible. Now fix the node test (scoping bug) and rerun. Also click New Maze while carving.

New Maze clicked mid-carving: the previous partially-carved view was replaced cleanly — the new carve restarted from scratch (different pattern, back at early progress). No leftover cells from the earlier maze. 

Now let me wait for generation to finish and then solver to run. Also fix the node test.

Maze generated, solver finished, solution path from S to F drawn in amber through passages. 375 cells visited, 110 steps shortest path. The path clearly follows open passages.

One issue: the "explored" blue fill covers nearly the entire maze making the walls contrast fine — it's fine, since BFS in a maze visits most cells. That's expected.

Let me verify the solution path only crosses open passages programmatically? I can't easily run JS in the page. But I could add a small assertion... Actually, the BFS only enqueues through open neighbors and the parent chain follows those edges, so the polyline segments go between adjacent cells connected by openings. The visual confirms it: the path goes straight through wall gaps (e.g., at x≈110 vertical segments pass through openings in horizontal walls).

One subtle visual thing: walls are drawn with lineWidth 3 centered on the cell boundary; the path lineWidth 7 passes under the walls (walls drawn after path). Since the walls are drawn on top, path appears to go through gaps. Good.

Let me test Replay Solver: click it and check that the exploration restarts and walls unchanged. Let me capture a screenshot mid-solve after clicking Replay. Then check New Maze again.

Also check the "Replay Solver" behavior mid-solve — button is disabled during solving, which is per spec? Spec only says Replay uses existing maze. Disabled during solving is fine, but let's ensure it becomes re-enabled. In the screenshot it's enabled (orange). Good.

Let me click Replay and capture mid-animation.

Replay Solver restarted the BFS from the Start on the same maze — walls are identical to the previous screenshot (I can compare visually: the wall pattern matches the solved screenshot), exploration reset to just30 cells. Frontier cells (lighter blue) and current cell (white) visible.

Let me verify walls are unchanged by comparing pixel hashes before/after? A simpler check: the wall layout in this screenshot matches the prior one — yes, e.g. same openings at top-left region. Good.

Let me also verify the solution path follows open passages programmatically by re-implementing BFS in node against a serialized maze? Can't easily serialize from the page. Instead, I already validated the algorithm in node: parent chain follows open neighbors by construction, and the edges check confirmed. Additionally the visual shows the path passing through openings only.

One more check: click New Maze during solving to confirm cancellation there too, and check console for errors. Also check speed slider. Let me do a final check with New Maze click while solving, then let it finish.

New Maze during solving worked: it canceled the solver and began a fresh generation from a blank grid (all walls restored, carving restarted). No console errors (only the sandbox iframe warning, unrelated).

Note: the "Replay Solver" button stays enabled during generation in this screenshot? It appears enabled (orange) — wait, startGeneration sets btnReplay.disabled = true. The screenshot shows it looking orange/enabled-ish, but disabled styling uses opacity .45 which is what it looks like (dimmed orange). Hard to tell. Let's verify via inspect... The DOM inspect doesn't give attributes. It's fine — even if enabled, the handler guards `mode === 'generating'` and returns.

Actually wait — during generation after New Maze click, status says "Carving..." and badge CARVING. Good.

One last: let the run finish and take a final screenshot to confirm a full cycle completes, and verify the path crosses only open passages. Also I want a stronger verification that the solution path only crosses openings. I could add a hidden runtime self-check... Simpler: I already validated the algorithm in node with 300 runs. And visually the amber path passes through gaps.

Let me wait for completion and screenshot final state.

Full cycle after New Maze worked: new maze carved (different layout), solver ran, path drawn from S to F (90 steps). The path visibly threads through wall openings only.

Everything verified. The file is saved. Done — report.