Mine Sweeping World

Mine Sweeping World is a live browser game that reframes classic Minesweeper as a persistent world map. Each world tile is its own Minesweeper board, with difficulty, board size, mine density, completion state, player progress, weekly maps, and social progression layered on top.

The project started from a compact design idea: a world map where every coordinate opens a deterministic Minesweeper game. I used it as an AI-assisted solo development project, but treated the work like a small production system rather than a throwaway prototype: the game has accounts, cloud saves, leaderboards, admin tools, map generation, scheduled weekly rotation, player profiles, achievements, and live deployment.

Table of Contents

• Overview
• Game and World Design
• Client-First Architecture
• Backend and Deployment
• World Map Authoring Tool
• Progression and Live Operations
• AI-Assisted Development Workflow
• Outcome

Overview

The core game is intentionally familiar: players reveal cells, flag suspected mines, and clear boards of different sizes and mine densities. The larger design goal was to make many small Minesweeper sessions feel like progress inside a shared world.

The current live version uses a weekly world map. The active public map is loaded from the backend, includes custom per-difficulty colors, and is displayed as a pixel-art style Canvas world. Completed tiles reveal stronger color, unfinished tiles stay lighter, and active or failed tiles carry separate state feedback. The result is a simple but readable visual loop: each cleared board illuminates another part of the map.

My responsibilities covered the entire stack:

• Game rules, board generation, reveal/chord behavior, win/loss handling, restart flow, and resumable sessions.
• Canvas rendering for the world map, board UI, hover tooltips, status overlays, mine/flag icons, and interaction feedback.
• Authentication, Google OAuth integration, JWT refresh, user roles, profiles, achievements, lives, and leaderboards.
• PostgreSQL schema design, migrations, serverless API routes, map snapshots, and progress persistence.
• Admin-facing tools for user management, game settings, and custom world-map authoring.
• Production deployment and debugging on Vercel with Supabase-backed data.

Game and World Design

The first version used coordinate hashing to assign each world tile a difficulty tier. I then moved from an infinite map to a more intentional bounded world, which made progression, camera constraints, and map readability easier to control.

Each tile can become a separate board with its own dimensions and mine density. The implementation supports multiple in-progress games at once: when the player returns to the world map, the current board pauses and its state can be resumed later. This lets the world map behave like a hub rather than a single locked session.

The difficulty model was tuned through several visual and gameplay passes:

• Easy, Normal, Medium, Hard, Expert, and Master tiers use different board sizes and mine ratios.
• World tiles have distinct idle, active, won, and lost presentation states.
• Later map versions support custom colors per weekly map, so a map can preserve its pixel-art identity while keeping gameplay difficulty separate from display color.
• Hover tooltips expose difficulty, board size, mine density, and tile state without cluttering the map.

This is the same kind of technical-art tradeoff I often care about in production: keep the data model clean, then build presentation rules that make the system readable to players.

Client-First Architecture

The game logic stays client-first for immediate interaction. Opening cells, placing flags, flood reveal, chording, and timer updates happen locally, so the board feels responsive even when cloud sync is involved.

The server only stores meaningful state snapshots:

• Which world tile the save belongs to.
• Board status: active, won, or lost.
• Mine, revealed, and flagged arrays.
• Flag count, revealed count, first-click state, hit index, and elapsed time.

In the database, these compact board arrays are stored as binary-friendly data rather than expanded rows per cell. That keeps per-grid saves small and makes it practical to preserve many world tiles per user.

This architecture was deliberate: the client owns moment-to-moment gameplay, while the backend owns persistence, identity, progression, and shared social data.

Backend and Deployment

The backend went through a real production-style evolution. I first designed a Node.js and Fastify service with PostgreSQL, JWT auth, and WebSocket presence. After moving to Vercel, I adapted the architecture to Serverless Functions, since persistent WebSockets were not a good fit for the target hosting environment.

The deployed version uses:

• Vercel rewrites for the static game pages and API routes.
• Supabase PostgreSQL for users, progress, world maps, snapshots, settings, lives, illuminate credits, and leaderboard data.
• JWT access tokens with refresh-token handling.
• Google OAuth through Supabase Auth, then exchange into the game's own auth model.
• Public API routes for active map, presence, leaderboard, and weekly stats.
• Protected admin routes for user roles, game settings, and map management.

Several deployment bugs became useful engineering passes rather than one-off fixes: Vercel routing format changes, Supabase SSL connection behavior, migration file path issues inside serverless functions, schema/API column mismatches, OAuth redirect handling, token refresh edge cases, and the Hobby plan's 12-function limit. To stay within the function budget, I consolidated related API endpoints such as auth and admin operations behind resource/action parameters.

World Map Authoring Tool

The strongest technical-art part of the project is the admin world-map generation tool. Instead of hardcoding maps by hand, I built a browser-based editor that turns uploaded images into playable world maps.

The tool supports:

• Image upload with pixel-art/reference modes.
• K-means++ initialization and K-means color quantization.
• Automatic color cluster mapping into background plus six gameplay difficulty tiers.
• Manual paint editing for individual cells.
• Custom grid dimensions.
• TXT import/export for map data interchange.
• Difficulty swapping that remaps both gameplay data and display color.
• A custom HSV color picker with live preview, numeric controls, hex input, and reference-image opacity handling.
• Saved map management, activation, and scheduling for future weekly maps.
• Tier distribution stats so the map can be checked against intended difficulty balance.

This tool makes the game much more than a static JavaScript board. It creates a small content pipeline: author an image, quantize it, rebalance difficulty, tune colors, save it to the database, schedule it, and let the live game load it for players.

Progression and Live Operations

As the project grew, I added systems that make the game feel closer to a live service:

• User accounts with username/password login and Google OAuth.
• Persistent progress per user and per world tile.
• Leaderboards and weekly ranking percentages.
• Lives that regenerate over time and can undo a loss state.
• Illuminate credits, awarded by clearing harder tiers and spent to complete lower-tier tiles.
• Admin-configurable life regeneration timing and illuminate conversion ratios.
• User profile pages with avatar, display name, play history, and achievements.
• Weekly map rotation with historical snapshots, so past map performance remains available after the active map changes.

The weekly map switch performs a snapshot pass before clearing active state for the new map. That keeps current-week gameplay fast while preserving historical records for profile history and achievement logic.

AI-Assisted Development Workflow

I used AI heavily during development, but the project still required the same judgment I would apply to a production tool or game feature. The development history shows frequent iteration: requirements changed, hosting constraints appeared, UI states were refined, deployment failures needed diagnosis, and data contracts had to be corrected.

The useful pattern was not "AI writes the game." It was closer to rapid technical direction:

• Break a system into small, testable steps.
• Ask for implementation drafts or debugging hypotheses.
• Read and validate the resulting code paths.
• Keep a detailed development log so architectural decisions and fixes did not disappear.
• Refactor when platform constraints made the first approach impractical.

That workflow let me move quickly while still making senior-level calls around architecture, data ownership, UX readability, and production reliability.

Outcome

Mine Sweeping World is a live project, but more importantly it is a compact demonstration of how I think as a technical artist: take a simple interaction, expose the hidden systems around it, build tooling so content can scale, and keep iterating until the product is understandable, maintainable, and usable.

For portfolio purposes, the project shows a blend of gameplay implementation, web engineering, UI/UX iteration, backend deployment, data modeling, and tool development. It also reflects a practical AI-native workflow: moving fast, but still grounding decisions in system design, debugging evidence, and production constraints.