Design Minesweeper Game
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?
Interviewer: Yes, support configurable board sizes and mine counts.
Candidate: What actions should a player be able to perform on a cell?
Interviewer: Players should be able to reveal a cell, flag a cell as suspected mine, or unflag a flagged cell.
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: How do we determine game outcomes?
Interviewer: If a player reveals a mine → Game Over. If all non-mine cells are revealed → Player Wins.
Candidate: Is there a time limit or scoring mechanism based on how fast the user completes the board?
Interviewer: You can ignore timer or scoring mechanism 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 configurable board sizes and mine counts (e.g., 9×9 with 10 mines, 16×16 with 40 mines, etc..)
- Support different mine placement algorithms
- Allow players to reveal a cell or flag/unflag a cell
- Automatically reveal connected empty cells when a zero-adjacent-mine cell is clicked
- End the game with "Game Over" if the player clicks on a mine
- Declare a win if all non-mine cells are revealed
1.2 Non-Functional Requirements
- Modularity: The system should follow object-oriented design with clearly separated components
- 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
- Maintainability: Code should be easy to understand, extend, and debug