C++ / SFML
Minesweeper
An independent C++ desktop implementation of Minesweeper built with SFML, covering board generation, recursive reveals, event-driven input, win and loss flow, and file-backed features like a leaderboard.
Implementation highlights
Board generation and tile state
The game starts with a dynamically generated board, randomized mine placement, and per-tile state that has to stay consistent across reveals, flags, and end-game checks.
Reveal logic and game loop
Recursive tile revealing was one of the most interesting parts because it required translating familiar gameplay rules into safe, repeatable program behavior.
UI features and persistence
Beyond the base game, I added a timer, debug mode, win/loss handling, and leaderboard storage through file I/O so the project felt like a complete application instead of a minimal clone.
Overview
Minesweeper was one of the earlier projects that helped me get comfortable building a complete interactive application from a familiar ruleset.
Even though the game is simple to describe, it still requires clear state handling, recursion, rendering, input management, and a good finish on the surrounding features.
It remains a useful portfolio piece because it shows classical programming fundamentals and the habit of carrying a project through to a fully playable result.
Problem / Goal
The goal was to recreate Minesweeper faithfully enough that the board behavior, reveal logic, flags, and win/loss states all felt correct.
Games make state bugs visible immediately, so the project required careful handling of tile state, control flow, and end conditions.
I also wanted it to feel more complete than a basic classroom demo, which meant adding supporting systems like a timer, debug mode, and leaderboard handling.
Approach / Architecture
I used C++ and SFML for rendering and input, with CMake to keep the project organized and buildable.
Board generation handled randomized mine placement and adjacency logic, while the gameplay layer controlled reveals, flags, and state transitions.
Recursive reveal behavior was central because blank regions need to expand correctly without breaking the rest of the board state.
On top of the core gameplay, I added file-backed leaderboard behavior and other quality-of-life features to make the application feel finished.
Engineering details
The board model had to track whether tiles were hidden, revealed, flagged, or mined, plus their neighboring mine counts.
Recursive tile revealing was a practical exercise in turning game rules into code without creating broken edge cases or repeated work.
Input handling and rendering had to stay synchronized with gameplay state so the interface reflected the current board correctly.
Leaderboard and timer behavior introduced file I/O and more persistent state management around the main event loop.
Challenges
Recursive game logic is easy to get wrong if the tile state model is not consistent.
Games expose visual bugs quickly, so even small mistakes in control flow or state updates were obvious during testing.
Adding support features like debug mode and a leaderboard made the project more complete, but also introduced more moving parts to manage cleanly.
What I learned
This project helped me get more comfortable with event-driven programming, OOP structure, and recursion in a concrete setting.
It also reinforced the value of finishing the surrounding application details instead of stopping at the core mechanic.
Even as an earlier project, it still reflects how I like to build: make the logic correct, then keep polishing until the experience feels complete.