Maze Runner Arrow-Key Game — Free HTML CSS JS Snippet

Procedural maze generation is one of the most rewarding small algorithms to implement because the result is instantly verifiable — you can see, and play, whether the maze actually works. This snippet builds a genuinely playable maze runner: a fresh 13×13 maze is generated on every load using recursive backtracking (a randomised depth-first search), rendered as a CSS grid of walled cells, and navigated with real per-cell wall-collision checking rather than a simulated or pre-baked path.

How recursive backtracking generates a solvable maze

The algorithm starts by treating every cell as a sealed room — each cell begins with all four walls (N | E | S | W, stored as a 4-bit bitmask) intact. generateMaze() pushes the starting cell [0, 0] onto a stack and marks it visited. On each iteration, it looks at the cell on top of the stack, shuffles the four compass directions into random order via a Fisher-Yates shuffle (shuffleDirs()), and tries each one in turn looking for an unvisited neighbour. When it finds one, it knocks down the wall between the current cell and that neighbour — by clearing the matching bit on both cells' wall masks using cells[cy][cx].walls &= ~dir and the opposite direction on the neighbour — marks the neighbour visited, and pushes it onto the stack. If none of the four directions leads to an unvisited neighbour, the algorithm pops the current cell off the stack and backtracks, trying again from there. This continues until the stack empties, at which point every cell has been visited exactly once.

Why this guarantees a maze with exactly one path between any two points

Because a wall is only removed when moving from a visited cell to a *previously unvisited* one, the set of removed walls forms a spanning tree over the grid graph — connected, with no cycles. A spanning tree by definition has exactly one path between any two nodes, so this is what guarantees the maze is always fully solvable, with no dead-end ambiguity about which corridor is "correct."

Rendering walls without drawing lines

Rather than drawing wall segments with borders or SVG lines, each .maze-cell is rendered as a dark background square containing a smaller white .cell-inner square inset by 1px on all sides by default. When a cell's bitmask indicates an open passage in a given direction (checked with !(cell.walls & N), etc.), a corresponding class like .wall-top extends that one edge of the inner square outward to meet the neighbouring cell's inner square, visually merging the two into one open corridor — walls are simply the dark grid background showing through the 1px gaps, a lightweight technique needing no canvas or SVG.

Movement and real collision checking

The player and goal are absolutely positioned circular markers layered on top of the grid, each sized and positioned as a percentage of the grid (100 / SIZE) so they align perfectly with cell boundaries regardless of container size. tryMove(dir) is the collision gate: before updating playerX/playerY, it calls canMove(), which checks whether the current cell's wall bitmask has the requested direction's bit cleared. If the bit is still set (a wall exists), the move is silently rejected — this is genuine per-cell wall data driving movement, not a visual-only maze with unrestricted player motion. Arrow keys and WASD are both mapped to the same four direction constants via a single KEY_DIR lookup table.

Timer, move counter, and regeneration

A setInterval ticking every 100ms updates an elapsed-time display from Date.now() - startTime, and every accepted move increments a visible move counter. Reaching the bottom-right cell triggers handleWin(), which stops the timer and shows a win overlay with the final time and move count. New maze calls generateMaze() again with a fresh random seed, producing an entirely different, independently solvable layout every time.