Design Minesweeper
Design a Minesweeper game that supports board generation with hidden mines, user actions like reveal and flag, and win/loss detection based on game rules.
Minesweeper is a classic single-player puzzle game where the player’s objective is to reveal all non-mine cells on a grid without triggering a mine. The game requires logic, deduction, and careful strategy.
Game Overview
- The game board is a 2D grid of hidden cells, some of which contain mines.
- The player interacts with the board by clicking on cells.
- If the revealed cell contains a mine, the game ends in a loss.
- If the cell is safe, it reveals a number from
0to8indicating how many of its adjacent cells contain mines. - If the number is
0, all adjacent cells are automatically revealed recursively. - The player can also flag a cell if they suspect it contains a mine.
- The game ends in a win when all non-mine cells are revealed.
In this chapter, we’ll explore the low-level design of a Minesweeper game.
Lets start by clarifying the requirements:
1. Clarifying Requirements
Before starting the design, it's important to ask thoughtful questions to uncover hidden assumptions and better define the scope of the system.
Here is an example of how a conversation between the candidate and the interviewer might unfold:
Candidate: Should the game support different board sizes and difficulty levels (e.g., Beginner, Intermediate, Expert)?
Interviewer: Yes, support configurable board sizes and mine counts based on difficulty levels.
Candidate: Should the player be allowed to flag suspected mines, or is it enough to only reveal cells?
Interviewer: Yes, players should be able to flag and unflag cells they believe contain mines.
Candidate: Should the first cell the player clicks on always be safe, or can it contain a mine?
Interviewer: Good question. The first click should always be safe—it must never reveal a mine.
Candidate: What happens when a player clicks on a cell with no adjacent mines? Should we auto-reveal surrounding cells?
Interviewer: Yes, if a cell has zero adjacent mines, the game should recursively reveal its neighbors until all non-mine cells with adjacent mines are found.
Candidate: Is there a time limit or scoring mechanism based on how fast the user completes the board?
Interviewer: No time limit, but we can show a simple timer for reference. No scoring for this version.
Candidate: Should we support undo functionality or saving and resuming the game?
Interviewer: Not in this version. Let’s keep the scope limited to a single continuous game session.
After gathering the details, we can summarize the key system requirements.
1.1 Functional Requirements
- Support multiple board sizes and difficulty levels (e.g., 9×9 with 10 mines, 16×16 with 40 mines, 30×16 with 99 mines)
- Ensure the first click is always on a non-mine cell
- Allow users to reveal a cell or flag/unflag a cell
- Display the number of adjacent mines for revealed cells
- Automatically reveal connected empty cells when a zero-adjacent-mine cell is clicked
- End the game with a "Game Over" if the player clicks on a mine
- Declare a win if all non-mine cells are revealed
- Display a timer showing elapsed time
1.2 Non-Functional Requirements
- Modularity: The system should follow object-oriented design with clearly separated components such as Board, Cell, GameEngine, and Timer
- Extensibility: The design should allow future features such as scoring, saving game state, themes, or multiplayer mode
- Testability: The game logic (e.g., mine generation, flood-fill revealing) should be unit-testable
- Responsiveness: Actions like cell reveals and flag toggles should reflect instantly on the UI or console
- Maintainability: Code should be easy to understand, extend, and debug
- Determinism for Testing: Optionally support seeded mine placement to allow consistent behavior during testing