Validating Paths in a Browser-Based Word Puzzle Game

airobus — Sat, 13 Jun 2026 05:42:22 +0000

Word puzzle games often look simple: players connect letters, form words, and finish the board.

The implementation is less simple.

A browser-based word puzzle needs to answer a few important questions:

Is the selected path legal?
Are the selected tiles adjacent?
Is any tile reused?
Does the selected path form an accepted word?
Can the final board be completed fairly?

This post focuses on the validation layer behind a small word path puzzle game.

Representing a tile

A tile needs more than just a letter. It also needs a position.

const tile = {
  row: 1,
  col: 2,
  letter: "R"
}

The row and col values are important because every movement rule depends on position.

Without stable coordinates, the game cannot reliably check whether two tiles are connected.

Checking adjacency

The first rule is movement.

If diagonal movement is allowed, a tile can move to any of the eight neighboring tiles.

function isAdjacent(a, b) {
  const dx = Math.abs(a.row - b.row)
  const dy = Math.abs(a.col - b.col)

  return dx <= 1 && dy <= 1 && !(dx === 0 && dy === 0)
}

This function rejects the same tile and accepts horizontal, vertical, and diagonal neighbors.

If the puzzle should only allow horizontal and vertical movement, the rule can be changed:

function isOrthogonallyAdjacent(a, b) {
  const dx = Math.abs(a.row - b.row)
  const dy = Math.abs(a.col - b.col)

  return dx + dy === 1
}

This small difference changes the entire feel of the puzzle.

Diagonal movement gives players more freedom. Orthogonal movement creates stricter paths and often makes puzzles easier to analyze.

Preventing reused tiles

A common rule in word path puzzles is that a tile cannot be reused inside the same path.

The simplest way to check this is to store each tile coordinate in a set.

function hasDuplicateTiles(path) {
  const seen = new Set()

  for (const tile of path) {
    const key = `${tile.row},${tile.col}`

    if (seen.has(key)) {
      return true
    }

    seen.add(key)
  }

  return false
}

This prevents loops where the player returns to a tile that has already been used.

Validating the full path

Once adjacency and duplicate checks exist, a full path validator is simple.

function isValidPath(path) {
  if (path.length === 0) {
    return false
  }

  if (hasDuplicateTiles(path)) {
    return false
  }

  for (let i = 1; i < path.length; i++) {
    if (!isAdjacent(path[i - 1], path[i])) {
      return false
    }
  }

  return true
}

This only validates movement.

It does not decide whether the path forms a real word. That should be handled separately.

Converting a path into a word

A path can be converted into a word by joining the tile letters.

function pathToWord(path) {
  return path.map(tile => tile.letter).join("")
}

Then it can be checked against an accepted word list.

function isAcceptedWord(path, acceptedWords) {
  const word = pathToWord(path).toLowerCase()
  return acceptedWords.has(word)
}

For puzzle games, I usually prefer a curated answer list instead of a large dictionary.

A large dictionary may create many accidental valid words. A curated list gives the designer more control over the intended solution.

Checking board coverage

Some word path puzzles require the final solution to cover every required tile.

That means the game needs to know how many unique tiles are covered by all solved paths.

function getCoveredTiles(paths) {
  const covered = new Set()

  for (const path of paths) {
    for (const tile of path) {
      covered.add(`${tile.row},${tile.col}`)
    }
  }

  return covered
}

Then the board can be checked like this:

function isBoardComplete(paths, requiredTileCount) {
  return getCoveredTiles(paths).size === requiredTileCount
}

This is useful because a puzzle can contain valid words but still be incomplete.

A fair board should not leave impossible or confusing leftover tiles.

Avoiding overlapping solution paths

If each tile should belong to only one final answer, paths must not overlap.

function pathsOverlap(paths) {
  const used = new Set()

  for (const path of paths) {
    for (const tile of path) {
      const key = `${tile.row},${tile.col}`

      if (used.has(key)) {
        return true
      }

      used.add(key)
    }
  }

  return false
}

This check becomes important when generating puzzles automatically.

A generator can accidentally create boards where multiple solution paths fight for the same tile.

A practical generation approach

For a first version, I would not start with fully random letters.

Random boards are easy to create but hard to make fair.

A more controlled approach is:

choose a board size
choose a small curated word list
place each word as a legal path
reject overlapping paths
check board coverage
review difficulty before publishing

This is not a perfect generator, but it is a useful starting point.

For browser games, a small reliable generator is better than a large unreliable one.

Daily puzzles are easier to control

An infinite random mode sounds exciting, but quality control becomes harder.

Daily puzzles are easier because the game only needs one good board per day.

That allows extra checks:

path legality
word validity
board coverage
duplicate tile prevention
difficulty review

For a small V0, daily mode is often the better choice.

Final thoughts

The hard part of a word path puzzle is not rendering the grid.

The hard part is validation.

Before adding accounts, leaderboards, animations, or sharing features, the core rules should be solid:

legal movement
no reused tiles
accepted words only
no invalid overlap
complete board coverage

Once those rules work, the game becomes much easier to improve.

I used this approach while experimenting with a small independent browser puzzle project. The main lesson was simple: build the validator first, then build the game around it.

How I Built a Performant Logic Puzzle Game with Next.js and a Web Worker

airobus — Tue, 19 Aug 2025 02:05:11 +0000

Hey DEV community!

I've always been a huge fan of logic puzzles. Recently, I got hooked on the Queens puzzle game but felt the classic rules were a bit too simple. This sparked an idea: what if I could create a more modern, more challenging version?

Today, I'm excited to share the result of that idea: Enhanced Queens Game, a free-to-play web game I built from scratch.

🎮 You can play it here: queens game

This post is a quick breakdown of the journey, the tech stack, and one interesting technical challenge I solved.

The Core Idea: Adding a "Third Dimension"
The biggest change from the classic puzzle is the addition of colored regions. On top of having only one queen per row and column, you must also have only one per colored block. This simple twist turns a 2D puzzle into a much deeper 3D spatial reasoning challenge.

![Insert a GIF of the gameplay, showing the colored regions and a queen turning red]

The Tech Stack
I chose a modern stack to build this, focusing on performance and developer experience:

Framework: Next.js (for great SEO and fast performance)

Language: TypeScript (a must for managing complex game logic)

Styling: Tailwind CSS (for building the clean UI quickly)

The Coolest Technical Challenge: Real-time Validation without Lag
A key feature is that a queen turns red instantly if it breaks a rule. On larger 7x7 boards, checking all conflicts (row, column, region, and adjacency) on every single move could potentially lag the main UI thread.

The solution? A Web Worker.

I offloaded the most intensive validation logic to a separate background thread using a Web Worker (solveQueensWorker.ts in the repo). The main thread sends the current board state to the worker, the worker runs the heavy computations, and then sends the results (any conflicts) back.

This ensures the UI remains buttery smooth and responsive, even while complex calculations are happening in the background. It was a perfect use case for a worker and a fun problem to solve.

Feedback Welcome!
This has been an incredibly rewarding personal project. I'd be honored if you'd take a look. I'm open to any and all feedback—whether it's on the game's difficulty, the UI/UX, or the code itself.

Thanks for reading!

DEV Community: airobus