DEV Community: Cliff

How to Build a Browser-Based Jigsaw Puzzle Game with JavaScript and HTML5 Canvas

Cliff — Fri, 06 Nov 2026 01:47:01 +0000

Building a jigsaw puzzle game for the browser is an interesting combination of geometry, graphics programming, and interactive game development.

Unlike a traditional grid-based puzzle, a jigsaw puzzle requires irregular piece shapes, matching edges, image clipping, and precise drag-and-drop interactions. Players should be able to move individual pieces, connect matching pieces, and gradually reconstruct the original image.

In this tutorial, we'll explore how to build a browser-based jigsaw puzzle game using JavaScript and HTML5 Canvas, starting with the basic game architecture and moving through piece generation, rendering, interaction, and performance optimization.

The goal is to create a fully playable game that runs directly in a web browser without requiring downloads or additional software.

Planning the Game Architecture

Before implementing the puzzle mechanics, it's useful to break the game into smaller components.

A browser-based jigsaw puzzle game typically needs several systems:

Component

Responsibility

Game Manager

Controls the overall game state

Puzzle Generator

Divides the original image into pieces

Shape Generator

Creates realistic jigsaw piece boundaries

Canvas Renderer

Draws pieces and the game board

Input Manager

Handles mouse and touch interactions

Snap Manager

Detects matching pieces and connections

Progress Tracker

Tracks completed pieces and game progress

Keeping these systems separate makes the game easier to maintain and extend.

For example, changing the puzzle difficulty from 16 pieces to 100 pieces should not require rewriting the rendering or interaction logic.

A basic game state might look like this:

`const gameState = {
status: "playing",

rows: 4,
cols: 4,

pieces: [],

selectedPiece: null,

placedCount: 0,

startTime: Date.now()
};`

Possible game states include:

loading: Preparing the puzzle image and geometry.

playing: The player is assembling the puzzle.

paused: Gameplay is temporarily suspended.

completed: All pieces have been correctly assembled.

This simple structure provides a foundation for implementing the rest of the game.

Creating the Puzzle Grid

The first step is dividing the original image into a rectangular grid.

Suppose the source image has a width of 1200 pixels and a height of 800 pixels.

For a 4 × 4 puzzle:

const rows = 4;
const cols = 4;

const pieceWidth = image.width / cols;
const pieceHeight = image.height / rows;

Each piece has a logical position in the completed image.

We can calculate its original coordinates using its row and column:

function getPiecePosition(row, col, width, height) {
return {
x: col * width,
y: row * height
};
}

However, these rectangular regions are only the starting point.

A realistic jigsaw puzzle requires each piece to have a unique outline, with tabs and blanks that fit neighboring pieces.

This brings us to the most important part of the geometry system.

Generating Matching Jigsaw Piece Edges

A common mistake when implementing jigsaw puzzles is generating every piece independently.

This can lead to small differences between neighboring edges, creating visible gaps or overlaps.

A better approach is to generate shared boundaries first.

Each internal boundary is created once and reused by the two adjacent pieces.

For a grid of rows and columns, we need two sets of boundaries:

Horizontal boundaries between rows.

Vertical boundaries between columns.

Each boundary contains a geometric description and a polarity.

For example:

Positive polarity: A protruding tab.

Negative polarity: A recessed blank.

A simplified edge map can be generated as follows:

function randomPolarity() {
  return Math.random() > 0.5 ? 1 : -1;
}

function createEdgeMap(rows, cols) {
  const horizontal = [];
  const vertical = [];

  for (let r = 1; r < rows; r++) {
    horizontal[r] = [];

    for (let c = 0; c < cols; c++) {
      horizontal[r][c] = randomPolarity();
    }
  }

  for (let r = 0; r < rows; r++) {
    vertical[r] = [];

    for (let c = 1; c < cols; c++) {
      vertical[r][c] = randomPolarity();
    }
  }

  return { horizontal, vertical };
}

In a complete implementation, each entry should store the full edge geometry rather than just its polarity.

The neighboring pieces then reuse the same geometry in opposite directions.

This ensures that their boundaries match exactly.

Outer puzzle boundaries are treated differently: they remain straight rather than receiving tabs or blanks.

Creating Realistic Piece Shapes with Bézier Curves

Jigsaw puzzle pieces are recognizable because of their characteristic tabs and recessed edges.

We can approximate these shapes using cubic Bézier curves.

A cubic Bézier curve is defined by four control points:

P0: Starting point.

P1: First control point.

P2: Second control point.

P3: Ending point.

Its mathematical representation is:

B(t) = (1-t)³P0
+ 3(1-t)²tP1
+ 3(1-t)t²P2
+ t³P3

where t ranges from 0 to 1.

By adjusting the control points, we can create the rounded head and narrow neck of a traditional jigsaw tab.

For example, Canvas provides a convenient method:

ctx.bezierCurveTo( controlX1, controlY1, controlX2, controlY2, endX, endY );

A simplified edge renderer might look like this:

function drawTab(ctx, x, y, width, depth, direction) {
  const w = width;
  const d = depth * direction;

  ctx.lineTo(x + w * 0.25, y);

  ctx.bezierCurveTo(
    x + w * 0.25, y - d * 0.15,
    x + w * 0.28, y - d * 0.55,
    x + w * 0.40, y - d * 0.55
  );

  ctx.bezierCurveTo(
    x + w * 0.45, y - d * 0.95,
    x + w * 0.55, y - d * 0.95,
    x + w * 0.60, y - d * 0.55
  );

  ctx.bezierCurveTo(
    x + w * 0.72, y - d * 0.55,
    x + w * 0.75, y - d * 0.15,
    x + w * 0.75, y
  );

  ctx.lineTo(x + w, y);
}

The direction determines whether the tab protrudes or curves inward.

For a production-quality game, the geometry should also account for:

Consistent endpoints and tangent directions.

Variable tab widths and depths.

Different shapes for horizontal and vertical edges.

Reversed traversal when rendering neighboring pieces.

Shared control points to prevent mismatched boundaries.

The objective is to generate varied-looking pieces while maintaining mathematically consistent connections.

Constructing the Complete Puzzle Piece

Once all four edges are available, we can construct the outline of each piece.

A convenient strategy is to trace the shape clockwise:

Start at the top-left corner.

Draw the top edge from left to right.

Draw the right edge from top to bottom.

Draw the bottom edge from right to left.

Draw the left edge from bottom to top.

Close the path.

A simplified structure looks like this:

function createPiecePath(ctx, piece) {
  const { x, y, edges } = piece;

  ctx.beginPath();
  ctx.moveTo(x, y);

  drawEdge(ctx, edges.top);
  drawEdge(ctx, edges.right);
  drawEdge(ctx, edges.bottom, true);
  drawEdge(ctx, edges.left, true);

  ctx.closePath();
}

Here, drawEdge() is a reusable function that renders the corresponding edge geometry.

For a clean implementation, it is helpful to define each edge in local coordinates and apply transformations when placing it on different sides of the piece.

This avoids duplicating the same Bézier geometry for horizontal and vertical boundaries.

Rendering Puzzle Pieces with HTML5 Canvas

With the geometry generated, we can start rendering the actual puzzle.

The key technique is Canvas clipping.

Instead of creating a separate cropped image for every piece, we draw the original image through each piece's irregular clipping path.

This preserves image alignment across the entire puzzle.

The basic process is:

Save the current Canvas state.

Translate to the piece's position.

Define its clipping path.

Draw the original image.

Restore the Canvas state.

For example:

function renderPiece(ctx, image, piece) {
  ctx.save();

  ctx.translate(piece.currentX, piece.currentY);

  const path = createLocalPiecePath(piece);

  ctx.clip(path);

  ctx.drawImage(
    image,
    -piece.sourceX,
    -piece.sourceY
  );

  ctx.restore();
}

The important detail is that every piece uses the same original image coordinate system.

This means that when all pieces are placed correctly, the image lines up seamlessly.

We can also draw a border around each piece:

ctx.save();

ctx.translate(piece.currentX, piece.currentY);

const path = createLocalPiecePath(piece);

ctx.strokeStyle = "rgba(0, 0, 0, 0.25)";
ctx.lineWidth = 1.5;

ctx.stroke(path);

ctx.restore();

Additional visual effects such as shadows, hover highlights, and selection outlines can make the game feel much more responsive.

Implementing Drag-and-Drop Interaction

A jigsaw puzzle would not be playable without intuitive piece movement.

Each piece needs to track two different positions:

Its original position in the completed puzzle.

Its current position on the game board.

A simple piece object might look like this:

`const piece = {
id: 0,

correctX: 120,
correctY: 80,

currentX: 350,
currentY: 220,

isDragging: false,
isPlaced: false
};`

When the player selects a piece, we record the pointer offset:

function startDrag(piece, pointerX, pointerY) {
  piece.isDragging = true;

  piece.dragOffsetX = pointerX - piece.currentX;
  piece.dragOffsetY = pointerY - piece.currentY;
}

While dragging:

function movePiece(piece, pointerX, pointerY) {
  if (!piece.isDragging) return;

  piece.currentX = pointerX - piece.dragOffsetX;
  piece.currentY = pointerY - piece.dragOffsetY;
}

When the pointer is released, the game can check whether the piece is close enough to its correct position.

For browser games, the Pointer Events API is particularly useful because it supports mouse, touch, and pen input through a unified event model.

For example:

canvas.addEventListener("pointerdown", handlePointerDown);
canvas.addEventListener("pointermove", handlePointerMove);
canvas.addEventListener("pointerup", handlePointerUp);

canvas.addEventListener("pointercancel", handlePointerUp);

For mobile browsers, setting an appropriate touch-action CSS property on the game interaction surface also helps prevent unwanted browser gestures while dragging.

Detecting Correct Placement and Snapping Pieces

A simple snapping system compares the current position of a piece with its original position.

We can use Euclidean distance:

function checkSnap(piece, threshold = 20) {
  const dx = piece.currentX - piece.correctX;
  const dy = piece.currentY - piece.correctY;

  const distance = Math.hypot(dx, dy);

  if (distance < threshold) {
    piece.currentX = piece.correctX;
    piece.currentY = piece.correctY;

    piece.isPlaced = true;

    return true;
  }

  return false;
}

This works well for a basic puzzle where pieces are placed directly into their final positions.

However, more advanced games can support connections between neighboring pieces before they reach the correct location.

For example, when two pieces are close enough and their corresponding edges match, they can snap together and form a larger group.

This introduces the concept of connected piece clusters.

A cluster can be represented as a collection of pieces that share a common movement offset.

When the player drags one piece in a connected cluster, all the other pieces move with it.

This creates a more natural puzzle-solving experience, especially for larger puzzles.

Adding Difficulty Levels and Game Progress

A complete browser-based jigsaw puzzle game should offer more than just a fixed grid.

Different piece counts can provide different difficulty levels.

For example:

Difficulty

Grid

Total Pieces

Easy

3 × 3

Medium

5 × 5

Hard

8 × 8

Expert

10 × 10

100

The actual difficulty also depends on the image itself, the shape variation, and whether players can use a reference image.

A progress tracker can be implemented with a simple counter:

function updateProgress(gameState) {
  const total = gameState.rows * gameState.cols;

  const progress = gameState.placedCount / total;

  if (progress >= 1) {
    gameState.status = "completed";
  }

  return progress;
}

Other useful gameplay features include:

A timer to track completion time.

A preview of the completed image.

A shuffle function.

A restart option.

A completion animation.

A responsive puzzle board for smaller screens.

These features turn the underlying rendering engine into a more complete game experience.

Optimizing Performance for Desktop and Mobile Browsers

Performance becomes increasingly important as the number of pieces grows.

A 3 × 3 puzzle is relatively easy to render. A 100-piece puzzle requires more careful management.

Several techniques can help.

Separate rendering layers

Instead of redrawing everything unnecessarily, divide the game into layers:

Background and board.

Static completed pieces.

Loose puzzle pieces.

Active dragging and interaction effects.

Use offscreen rendering

Static piece images can be rendered into offscreen canvases and reused.

This reduces repeated clipping and drawing operations.

Optimize hit testing

Checking every pixel of every piece is expensive.

Start with bounding-box checks to eliminate pieces that are clearly not under the pointer. More precise path-based checks can then be performed on the remaining candidates.

Avoid unnecessary redraws

A requestAnimationFrame-based rendering loop can be used to update the game smoothly, but static scenes do not need to be redrawn continuously.

Consider device pixel ratio

High-density mobile screens require careful Canvas scaling to keep puzzle edges sharp without creating excessively large rendering surfaces.

The best optimization strategy depends on the puzzle size, device capabilities, and rendering architecture.

Putting Everything Together

At this point, we have the major building blocks of a browser-based jigsaw puzzle game:

Grid generation determines the number and dimensions of pieces.

Edge generation creates matching boundaries.

Bézier curves define realistic tabs and blanks.

Canvas clipping maps the original image onto each piece.

Pointer events enable interactive dragging.

Snap detection handles correct placement.

Game state management tracks progress and completion.

The complete gameplay flow can be summarized as:

The most important architectural decision is keeping geometry, rendering, interaction, and game state independent.

This makes it easier to add new features without introducing unnecessary complexity into the core puzzle engine.

Try a Browser-Based Jigsaw Puzzle Game

The techniques discussed in this tutorial are the foundation of an interactive jigsaw puzzle experience.

If you want to explore how a browser-based jigsaw puzzle game works in practice, you can try Jigsaw Puzzle Spot.

It offers free online jigsaw puzzles that can be played directly in the browser, providing a practical example of image-based puzzle gameplay without requiring a separate application or installation.

Conclusion

Building a browser-based jigsaw puzzle game with JavaScript and HTML5 Canvas involves several interesting engineering challenges.

The most important ones are generating matching piece geometry, rendering irregular shapes, maintaining image alignment, and implementing intuitive drag-and-drop interactions.

By separating these systems into reusable components, it is possible to build a flexible puzzle engine that supports different image sizes, difficulty levels, and gameplay mechanics.

What starts as a simple image-splitting exercise can become a surprisingly rich browser game development project.

And the best part is that the entire experience can run directly in a modern web browser.

Building a Browser-Based Boggle Game with Astro and Vue 3

Cliff — Sat, 26 Sep 2026 23:29:23 +0000

Building a word game looks simple at first.

A Boggle-style game seems to need only a letter grid, a word list, some input handling, and a score counter. But once the game needs to work well on both desktop and mobile, the implementation becomes a combination of UI state management, graph traversal, word validation, touch interaction, and performance optimization.

I recently built a browser-based Boggle game using Astro and Vue 3, and this article explains some of the engineering decisions behind it.

The goal was not to build a large game engine. Instead, I wanted a lightweight architecture where Astro handles the website and content-oriented pages, while Vue manages the interactive game itself.

The resulting project is Puzzle Boggle.

Why Astro + Vue 3?

Astro is particularly interesting for projects that contain both static content and interactive applications.

A word game website usually has two very different types of pages:

Content and informational pages
Highly interactive game pages

A traditional SPA can handle the second problem well, but it can be unnecessarily heavy for the first one.

Astro provides a useful separation between the two.

The static parts of the site can be rendered by Astro, while Vue components can be introduced where interactive behavior is required.

The basic architecture looks roughly like this:

Astro
│
├── Layout
├── SEO / Metadata
├── Content Pages
├── Game Pages
│
└── Vue
    ├── GameBoard
    ├── LetterTile
    ├── WordInput
    ├── ScorePanel
    └── GameResult

The important idea is that not everything needs to become a Vue application.

Only the parts that actually need client-side state need to be hydrated.

Separating the Game UI From the Website

One of the first architectural decisions was separating the website layer from the game layer.

The Astro side is responsible for things such as:

page structure
navigation
metadata
informational content
SEO
static layouts

Vue is responsible for:

current game state
selected letters
user input
word validation
scoring
timers
animations
game completion

This separation makes the project easier to reason about.

The game can behave like a small application inside a larger content-oriented website.

For example:

src/
├── components/
│   ├── GameBoard.vue
│   ├── LetterTile.vue
│   ├── ScorePanel.vue
│   └── GameResult.vue
│
├── composables/
│   ├── useGame.ts
│   ├── useBoard.ts
│   └── useTimer.ts
│
├── data/
│   ├── dictionaries/
│   └── puzzles/
│
├── pages/
│   ├── index.astro
│   ├── daily-challenge/
│   └── boggle/
│
└── layouts/
    └── Layout.astro

This is not the only valid structure, but separating UI components, game logic, and data early makes the project much easier to maintain.

Modeling the Boggle Board

The board can be represented as a two-dimensional array.

For example, a 4 × 4 board can be represented as:

const board = [
  ['T', 'R', 'A', 'P'],
  ['E', 'S', 'I', 'N'],
  ['L', 'O', 'G', 'D'],
  ['M', 'E', 'T', 'A']
]

Each cell needs to contain more than just a letter during gameplay.

A useful internal representation is:

interface Cell {
  row: number
  col: number
  letter: string
}

The row and column coordinates are important because Boggle is fundamentally a path-search problem.

A player is not simply selecting letters.

They are creating a path through adjacent cells.

The Core Gameplay Problem Is a Graph Traversal

This is probably the most interesting part of implementing Boggle.

Each letter tile can be considered a node in a graph.

A tile can connect to its neighboring tiles:

A B C
D E F
G H I

From E, the player can potentially move to:

A B C
D   F
G H I

That means the game board can be treated as a graph where each tile has up to eight neighbors.

The eight possible directions are:

const directions = [
  [-1, -1],
  [-1,  0],
  [-1,  1],
  [ 0, -1],
  [ 0,  1],
  [ 1, -1],
  [ 1,  0],
  [ 1,  1]
]

When a player selects a tile, the game needs to determine whether the next tile is adjacent to the previous tile.

A simple helper function can handle this:

function isAdjacent(
  a: Cell,
  b: Cell
): boolean {
  const rowDistance = Math.abs(a.row - b.row)
  const colDistance = Math.abs(a.col - b.col)

  return (
    rowDistance <= 1 &&
    colDistance <= 1 &&
    !(rowDistance === 0 && colDistance === 0)
  )
}

The next important rule is that the same tile cannot normally be used twice in the same word.

So the game state needs to maintain the path:

const selectedCells = ref<Cell[]>([])

When the player selects a new tile, the game checks:

Is this tile adjacent to the previous tile?
Has this tile already been selected?
If valid, add it to the current path.
Otherwise reject the selection.

These rules become especially important on mobile devices where users interact with the board using touch rather than a mouse.

Using Vue 3 Composition API

Vue 3's Composition API is a good fit for this type of game because game logic can be separated into reusable composables.

For example:

const score = ref(0)
const currentWord = ref('')
const selectedCells = ref<Cell[]>([])
const foundWords = ref<string[]>([])
const gameOver = ref(false)

Then the logic can be organized into functions:

function selectCell(cell: Cell) {
  if (!canSelect(cell)) {
    return
  }

  selectedCells.value.push(cell)
  currentWord.value += cell.letter
}

And:

function submitWord() {
  const word = currentWord.value.toLowerCase()

  if (!isValidWord(word)) {
    resetSelection()
    return
  }

  if (foundWords.value.includes(word)) {
    resetSelection()
    return
  }

  foundWords.value.push(word)
  score.value += calculateScore(word)

  resetSelection()
}

This is one of the reasons I prefer Composition API for interactive game components.

The state and behavior can stay close together without forcing the entire game into one huge component.

Word Validation Is a Separate Problem

The board traversal algorithm and the dictionary system should not be tightly coupled.

These are two different problems:

Can the player create this sequence of letters?
                    ↓
              currentWord

                    ↓

Is this sequence a valid word?
                    ↓
               dictionary

Keeping them separate makes the game easier to modify.

For example, the dictionary can be loaded into a Set:

const dictionary = new Set([
  'apple',
  'orange',
  'stone',
  'game'
])

Then validation becomes very fast:

function isValidWord(word: string) {
  return dictionary.has(word)
}

In a real game, the dictionary is obviously much larger.

One of the interesting engineering challenges is therefore not simply "finding words", but deciding how much dictionary data should be loaded into the browser.

Client-Side vs Server-Side Validation

For a casual browser word game, client-side validation can be extremely fast.

The flow can be:

Player
  ↓
Select tiles
  ↓
Build word
  ↓
Check dictionary
  ↓
Calculate score
  ↓
Update UI

This avoids sending a network request every time the player submits a word.

For a competitive game, however, there is another consideration.

If the client is responsible for everything, a technically sophisticated player can potentially manipulate the game state.

For a casual game this may be acceptable.

For competitive scoring or leaderboards, important results should be verified on a server.

That leads to a useful distinction:

Local gameplay
    ↓
Fast client-side validation

Competitive result
    ↓
Server-side verification

This architecture also makes it easier to introduce daily challenges or leaderboards later.

Generating Interesting Boards

Random letters do not necessarily produce an interesting Boggle board.

A completely random board can generate too many impossible combinations or produce boards with very few playable words.

A better approach is to treat board generation as a constrained problem.

For example:

Random letters
      ↓
Generate candidate board
      ↓
Evaluate board
      ↓
Check word count
      ↓
Check difficulty
      ↓
Accept / regenerate

The board generator can evaluate a candidate board using a dictionary and estimate how many valid words are available.

This creates an interesting separation between:

Board generation
Word discovery
Difficulty evaluation
Gameplay

A deterministic seed can also be useful.

For example:

generateBoard(seed)

If the same seed produces the same board, a daily puzzle can be reproduced consistently.

This is useful for a daily challenge system because every player can receive the same puzzle.

Designing a Daily Challenge

A daily puzzle introduces another interesting engineering problem.

The simplest model is:

date
  ↓
deterministic seed
  ↓
board generator
  ↓
daily board

For example:

const seed = createDailySeed('2026-09-26')

const board = generateBoard(seed)

The server does not necessarily need to store every generated board if the generation algorithm is deterministic.

Instead, the date can act as the source of the seed.

This can significantly simplify the data model.

The same concept can also be used for:

daily Sudoku
daily Wordle-style games
daily crossword puzzles
daily logic puzzles

Mobile Interaction Is Harder Than Desktop Interaction

A desktop implementation can start with:

mousedown
mousemove
mouseup

But mobile users interact with their fingers.

That introduces several issues:

Finger size is much larger than a mouse cursor.
The finger can obscure the selected tile.
Touch movement can accidentally trigger page scrolling.
Rapid movement between tiles needs to feel responsive.
The selection path needs clear visual feedback.

The interaction therefore needs to be designed around touch from the beginning rather than treating mobile as an afterthought.

A good Boggle interface should make the current path visually obvious.

For example:

[ T ][ R ][ A ][ P ]
       \   \
        [ E ][ S ]

The exact visual design can vary, but the user should immediately understand:

which tiles are selected
what word is being formed
where the path started
what happens when the finger moves

Keeping the Vue Component Manageable

One mistake I wanted to avoid was putting everything inside GameBoard.vue.

A game board can quickly become responsible for:

Board rendering
Touch events
Mouse events
Word validation
Scoring
Timer
Animations
Game state
Statistics
API calls

That becomes difficult to maintain.

Instead, I prefer smaller responsibilities.

For example:

GameBoard.vue
    ↓
useGame()
    ↓
useBoard()
    ↓
useWordValidation()
    ↓
useScore()

The components handle presentation while composables handle stateful behavior.

This is especially useful when the same game logic needs to be reused by different interfaces.

Astro Handles the Site, Vue Handles the Game

The final architecture can be summarized as:

                    Astro
                      │
          ┌───────────┼───────────┐
          │           │           │
       Content      SEO        Routing
          │                       │
          └───────────┬───────────┘
                      │
                  Vue Island
                      │
              ┌───────┴────────┐
              │                │
          Game Board        Game State
              │                │
        Touch / Mouse       Composables
              │                │
              └───────┬────────┘
                      │
                 Word Engine
                      │
              ┌───────┴────────┐
              │                │
          Dictionary       Board Logic

This architecture keeps the interactive portion focused while allowing the rest of the website to remain lightweight.

It also leaves room for future features without turning the entire website into a monolithic JavaScript application.

What I Learned From Building It

The biggest lesson is that a simple word game is actually several different engineering problems combined together.

The core gameplay requires:

Grid modeling
Graph traversal
Path validation
Dictionary lookup
Scoring
State management
Touch interaction
Board generation
Difficulty balancing
Performance considerations

The technology stack is only part of the problem.

The more interesting challenge is finding clean boundaries between these systems.

Astro works well for the website layer because it allows the application to contain static and interactive parts without forcing everything to become a client-side application.

Vue 3 works well for the game layer because reactive state and composable logic map naturally to gameplay.

And the Boggle rules themselves provide a surprisingly interesting algorithmic problem.

A Small Game Is a Good Engineering Exercise

One reason I enjoy building browser games is that they force you to think about both software architecture and user experience.

A Boggle board is small.

The number of rules is small.

The interface is small.

But implementing it well requires thinking about algorithms, state, input devices, performance, accessibility, and product design at the same time.

That's what makes these projects useful engineering exercises.

If you'd like to see the result, I've published the browser version as Puzzle Boggle.

The project is still evolving, but building it has been a useful way to explore how Astro and Vue 3 can work together for a small, interactive web application.

I hope some of these architectural ideas are useful for anyone building a browser game or another interactive application with Astro and Vue.