In this final part of our Minesweeper series, we'll add the ability for players to place flags on suspected mine locations.

We'll update our game logic to handle flag placement and removal, create a visual representation for flags, and implement a counter to track the number of flags placed.

By the end of this lesson, you'll have a fully functional Minesweeper game with all the classic features players expect!

Updating Globals

Let's start by updating our Globals.h. We'll register events for flags being placed and cleared, and we'll also add a string to define where our flag image is stored:

1// Globals.h
2
3// ...
4
5namespace UserEvents{
6  // ...
7  inline Uint32 FLAG_PLACED =
8    SDL_RegisterEvents(1);
9  inline Uint32 FLAG_CLEARED =
10    SDL_RegisterEvents(1);
11}
12
13namespace Config{
14  // ...
15  inline const std::string FLAG_IMAGE{
16    "flag.png"};
17}
18
19// ...

Placing Flags on Right Clicks

To place a flag, players will right click on a cell, so we need to update our MinesweeperCell class. The base Engine::Button class has a HandleRightClick() method we can override, and we'll additionally add a boolean to store whether the player has placed a flag in this cell:

1// Minesweeper/Cell.h
2
3// ...
4
5class MinesweeperCell : public Engine::Button {
6protected:
7  void HandleRightClick() override;
8  
9  // ...
10
11private:
12  // ...
13  bool hasFlag{false};
14};

In our HandleRightClick() implementation, we'll simply toggle the hasFlag variable, and report the appropriate event:

1// Minesweeper/Cell.cpp
2
3// ...
4
5void MinesweeperCell::HandleRightClick(){
6  if (hasFlag) {
7    ReportEvent(UserEvents::FLAG_CLEARED);
8    hasFlag = false;
9  } else {
10    ReportEvent(UserEvents::FLAG_PLACED);
11    hasFlag = true;
12  }
13}

Left-clicking on a cell that contains a flag shouldn't clear the cell, so let's add that logic to our HandleLeftClick() function:

1// Minesweeper/Cell.cpp
2
3// ...
4
5void MinesweeperCell::HandleLeftClick(){
6  if (!hasFlag) { ClearCell(); }
7}
8
9// ...

When the player starts a new game, all the flags should be cleared. Let's add that to our Reset() function:

1// Minesweeper/Cell.cpp
2
3// ...
4
5void MinesweeperCell::Reset(){
6  isCleared = false;
7  hasFlag = false;
8  hasBomb = false;
9  AdjacentBombs = 0;
10  SetIsDisabled(false);
11  SetColor(Config::BUTTON_COLOR);
12}
13
14// ...

The player doesn't necessarily need to mark all the bombs to win the game. As a small presentational improvement, let's just automatically flag all the cells with bombs in response to the GAME_WON event:

1// Minesweeper/Cell.cpp
2
3// ...
4
5void MinesweeperCell::HandleEvent(
6  const SDL_Event& E){
7  if (E.type == UserEvents::CELL_CLEARED) {
8    HandleCellCleared(E.user);
9  } else if (E.type ==
10    UserEvents::BOMB_PLACED) {
11    HandleBombPlaced(E.user);
12  } else if (E.type == UserEvents::GAME_WON) {
13    if (hasBomb) {
14      hasFlag = hasBomb; 
15      SetColor(Config::BUTTON_SUCCESS_COLOR);
16    }
17    SetIsDisabled(true);
18  } else if (E.type == UserEvents::GAME_LOST) {
19    if (hasBomb) {
20      isCleared = true;
21      SetColor(Config::BUTTON_FAILURE_COLOR);
22    }
23    SetIsDisabled(true);
24  }
25  Button::HandleEvent(E);
26}
27
28// ...

Rendering Flags

Now that our cells are keeping track of whether or not they're flagged, let's render some visual output for the flags. We'll add another Engine::Image member to our MinesweeperCell to render the flag:

1// Minesweeper/Cell.h
2
3class MinesweeperCell : public Engine::Button {
4// ...
5private:
6  // ...
7  Engine::Image FlagImage;
8};

In our constructor, we initialize this variable in much the same way we initialized the bomb image:

1// Minesweeper/Cell.cpp
2
3// ...
4
5MinesweeperCell::MinesweeperCell(
6  int x, int y, int w, int h, int Row, int Col)
7  : Button{x, y, w, h}, Row{Row}, Col{Col},
8    FlagImage{
9      x, y, w, h,
10      Config::FLAG_IMAGE},
11    BombImage{
12      x, y, w, h,
13      Config::BOMB_IMAGE},
14    Text{
15      x, y, w, h,
16      std::to_string(AdjacentBombs),
17      Config::TEXT_COLORS[AdjacentBombs]}{};
18
19// ...

Finally, in our Render() method, if the cell has a flag, we'll render the FlagImage:

1//  Minesweeper/Cell.cpp
2
3// ...
4
5void MinesweeperCell::Render(
6  SDL_Surface* Surface){
7  Button::Render(Surface);
8  if (hasFlag) {
9    FlagImage.Render(Surface);
10  } else if (isCleared && hasBomb) {
11    BombImage.Render(Surface);
12  } else if (isCleared && AdjacentBombs > 0) {
13    Text.Render(Surface);
14  }
15
16#ifdef SHOW_DEBUG_HELPERS
17  else if (hasBomb) { BombImage.Render(Surface); }
18#endif
19}

Running our game, we can now right-click in any uncleared cell to place a flag. Left clicking a flagged cell should have no effect, but right clicking it will remove the flag:

Flag Counter

Let's add a counter to our footer, so the player can keep track of how many bombs they have yet to place flags on. This indicator will span the full height of the footer, with its width and color controlled by Config variables in Global.h:

1//  Globals.h
2
3// ...
4
5namespace Config{
6  // ...
7  inline constexpr int FLAG_COUNTER_WIDTH{100};
8  // ...
9  inline constexpr SDL_Color FLAG_COUNTER_COLOR{
10    80, 80, 80, 255};
11  // ...
12}
13
14// ...

Let's create our Minesweeper/FlagCounter class. It inherits from Engine::Rectangle, and will contain an Image and Text element side-by-side.

The position and size of the Rectangle will be controlled by constructor arguments, with the color coming from our Config namespace.

The Image will be placed at the top left of the Rectangle, with its height being based on the FOOTER_HEIGHT config variable, and its width being the same as the height to ensure it is square. We also apply a 24 pixel padding to make the image slightly smaller.

The Text variable uses slightly more arithmetic to ensure it appears to the right of the Image. We also set the initial string to be the total number of bombs in the grid. We set the color to white, and the font size to 20:

1// Minesweeper/FlagCounter.h
2#pragma once
3#include <string>
4
5#include "Globals.h"
6
7#include "Engine/Rectangle.h"
8#include "Engine/Text.h"
9#include "Engine/Image.h"
10
11class FlagCounter : public Engine::Rectangle {
12public:
13  FlagCounter(int x, int y, int w, int h)
14    : Rectangle{
15        x, y, w, h, Config::FLAG_COUNTER_COLOR},
16      Image{
17        x, y,
18        Config::FOOTER_HEIGHT - Config::PADDING,
19        Config::FOOTER_HEIGHT - Config::PADDING,
20        Config::FLAG_IMAGE,
21        24},
22      Text{
23        x + Config::FOOTER_HEIGHT, y,
24        w - Config::FOOTER_HEIGHT - 24, h,
25        std::to_string(Config::BOMB_COUNT),
26        {255, 255, 255, 255}, 20}{}
27
28private:
29  Engine::Image Image;
30  Engine::Text Text;
31};

We'll override the base rectangle's Render() method to ensure the Text and Image are also rendered:

1// Minesweeper/FlagCounter.h
2
3// ...
4
5class FlagCounter : public Engine::Rectangle {
6public:
7  // ...
8
9  void Render(SDL_Surface* Surface) override{
10    Rectangle::Render(Surface);
11    Text.Render(Surface);
12    Image.Render(Surface);
13  }
14
15 // ...
16};

Finally, we'll implement a HandleEvent() method so that the FlagCounter can update appropriately:

When the player places a flag, we decrement the number of available flags
When the player clears a flag, we increment the number of available flags
When the game is won, we set the available flags to 0 because, when the game is won, our MinesweeperCell objects automatically place flags where all the bombs were
When the user restarts the game, the number of available flags is set to its initial value.

Additionally, when any of these events occur, we call the Text member's SetText() function to inform it what number it should be rendering:

1// Minesweeper/FlagCounter.h
2
3// ...
4
5class FlagCounter : public Engine::Rectangle {
6public:
7  // ...
8
9  void HandleEvent(const SDL_Event& E){
10    if (E.type ==
11      UserEvents::FLAG_PLACED) {
12      --FlagsAvailable;
13    } else if (E.type ==
14      UserEvents::FLAG_CLEARED) {
15      ++FlagsAvailable;
16    } else if (E.type == UserEvents::GAME_WON) {
17      FlagsAvailable = 0;
18    } else if (E.type == UserEvents::NEW_GAME) {
19      FlagsAvailable = Config::BOMB_COUNT;
20    } else { return; }
21    Text.SetText(
22      std::to_string(FlagsAvailable)
23    );
24  }
25
26private:
27  // ...
28  int FlagsAvailable{Config::BOMB_COUNT};
29};

Finally, let's add it to the UI. As before, we add it as a member of our MinesweeperUI, and add it to our Render() and HandleEvent() functions.

We reduce the width of the NewGameButton to make space in the footer, and then do some arithmetic to set the FlagCounter's position (x and y) and size (w and h).

The calculations involved to determine these constructor arguments is getting excessively messy and something we'd typically want to address.

Given we're essentially finished with this project, we'll leave it like this for now. However, it's a problem we should consider solving in our Engine module to make future projects easier. We discuss options for this later in the lesson.

Our final MinesweeperUI class looks like this:

1// Minesweeper/UI.h
2#pragma once
3#include "Globals.h"
4#include "Minesweeper/Grid.h"
5#include "Minesweeper/NewGameButton.h"
6#include "Minesweeper/FlagCounter.h"
7
8class MinesweeperUI {
9public:
10  void Render(SDL_Surface* Surface){
11    Grid.Render(Surface);
12    Button.Render(Surface);
13    Counter.Render(Surface);
14  }
15
16  void HandleEvent(const SDL_Event& E){
17    Grid.HandleEvent(E);
18    Button.HandleEvent(E);
19    Counter.HandleEvent(E);
20  };
21
22private:
23  MinesweeperGrid Grid{
24    Config::PADDING, Config::PADDING
25  };
26  NewGameButton Button{
27    Config::PADDING,
28    Config::GRID_HEIGHT + Config::PADDING * 2,
29    Config::WINDOW_WIDTH - Config::PADDING * 3
30    - Config::FLAG_COUNTER_WIDTH,
31    Config::FOOTER_HEIGHT - Config::PADDING
32  };
33  FlagCounter Counter{
34    Config::WINDOW_WIDTH - Config::PADDING
35    - Config::FLAG_COUNTER_WIDTH,
36    Config::GRID_HEIGHT + Config::PADDING * 2,
37    Config::FLAG_COUNTER_WIDTH,
38    Config::FOOTER_HEIGHT - Config::PADDING
39  };
40};

Our game is now complete and should be fully working! Remember to disable the SHOW_DEBUG_HELPERS definition to hide the bombs:

Complete Code

Complete versions of the files we changed in this part are available below

The remaining project files (which were not changed in this section) are available here:

We're also using the following assets:

Assets/Rubik-SemiBold.tff available from Google Fonts
Assets/bomb.png available from IconFinder
Assets/flag.png available from IconsDB

Improvement Ideas

To make the most of our learning, it can be helpful to go back to our project and change some things around, reworking how things are designed, or even completely rebuilding it.

This self-directed learning helps solidify the concepts we've covered, and makes it easier to apply them to new projects that won't have as much guidance. Some ideas on how the project could be reworked are below:

Refactoring

Something we should constantly be reviewing is areas of our code that seem quite complex and difficult to follow.

For example, our program has a very simple visual layout, with a grid at the top and a new game button and flag counter side by side at the bottom.

However, the code to establish such a simple layout is already difficult to write and follow:

1// ...
2
3class MinesweeperUI {
4public:
5  void Render(SDL_Surface* Surface){
6    Grid.Render(Surface);
7    Button.Render(Surface);
8    Counter.Render(Surface);
9  }
10  // ...
11private:
12  MinesweeperGrid Grid{
13    Config::PADDING, Config::PADDING
14  };
15  NewGameButton Button{
16    Config::PADDING,
17    Config::GRID_HEIGHT + Config::PADDING * 2,
18    Config::WINDOW_WIDTH - Config::PADDING * 3
19    - Config::FLAG_COUNTER_WIDTH,
20    Config::FOOTER_HEIGHT - Config::PADDING
21  };
22  FlagCounter Counter{
23    Config::WINDOW_WIDTH - Config::PADDING
24    - Config::FLAG_COUNTER_WIDTH,
25    Config::GRID_HEIGHT + Config::PADDING * 2,
26    Config::FLAG_COUNTER_WIDTH,
27    Config::FOOTER_HEIGHT - Config::PADDING
28  };
29};

Laying objects out in columns and rows is a recurring problem, so we could consider introducing generic classes like Column and Row that take care of that for us.

These classes can simply position children next to each other vertically or horizontally, and could accept arguments to control things like the padding between objects:

1// ...
2#include "Engine/Column.h"
3#include "Engine/Row.h"
4
5class MinesweeperUI {
6public:
7  void Render(SDL_Surface* Surface){
8    Layout.Render(Surface);
9  }
10  // ...
11  
12private:
13  MinesweeperGrid Grid;
14  NewGameButton Button;
15  FlagCounter Counter;
16
17  Column Layout{
18    Grid,
19    Row{
20      Button, Counter
21    }
22  }
23};

Gameplay Improvements

Currently, our game places bombs before the user clears the first cell. This can cause unfair outcomes, such as the first cell containing a bomb.

Many implementations of Minesweeper do not choose bomb positions until after the user clicks their first cell. This allows them to guarantee the cell is safe so the player doesn't lose immediately.

Additionally, it allows them to place bombs further away from this starting point. For example, we can ensure the adjacent cells to where the player starts have no bombs, either.

This results in the first click clearing a large area of the grid, allowing the player to proceed strategically and reducing the probability they'll need to make guesses.

Pooling Image Data

Currently, the cells in our grid are generating surfaces unnecessarily. For example, if our settings specify the grid has 50 cells, then 50 bomb images are loaded, and 50 identical surfaces are held in memory.

Flag and text surfaces are similarly wasteful. Every cell that shows a 3 image, for example, is generating its own surface, which is identical to every other 3.

Additionally, if a cell ultimately has 3 adjacent bombs, the bomb placement algorithm has it generate 1 and 2 surfaces which it discards before the player ever sees them.

These suboptimal approaches are fine for a simple game running on modern hardware, but we should consider reworking it anyway as learning opportunity. We'd want to pool these common surfaces into a shared location where our cells can access and share them.

We can optimize this concept even further by pooling the separate images into a single image, called a texture atlas. The original Microsoft version of Minesweeper might have a texture atlas that looks like this:

Cells could then select the data they want by providing a source rectangle to the SDL_BlitSurface() or SDL_BlitScaled() functions:

1#include "MinesweeperAtlas.h"
2
3// ...
4
5void Render(SDL_Surface* Surface) {
6  SDL_BlitScaled(
7    MinesweeperAtlas::Surface,
8    MinesweeperAtlas::Bomb,
9    Surface,
10    &Destination
11  );
12}
13
14// ...

Don't worry if you're not sure how you would set this up now. We revisit asset management multiple times throughout the course, and future projects will use increasingly more sophisticated techniques.

Difficulty Modes

Most Minesweeper games allow players to choose their preferred difficulty - typically, easy, medium or hard.

Harder difficulties increase the size of the grid, and increase the number of bombs within the grid. It would involve a lot of changes to set our game up to support this. However, it wouldn't require any new concepts - we know everything we need to set this up.

The SDL_SetWindowSize() function (official documentation) let's us programatically resize the window, which can be useful if our grid size changes based on difficulty setting.

Reducing Event Traffic

To keep things simple, our project routed pretty much every event through to every relevant object in our game. This results in a lot of excess traffic, where object's HandleEvent() functions are invoked with an event the object has no interest in.

Every function call that results in no effect has an unnecessary performance cost, and that's especially true when the functions are virtual.

An obvious way to reduce this traffic is having each parent check an event is relevant to its children before forwarding it:

1void HandleEvent(const SDL_Event& E){
2  if (isRelevantToChildren(E.type) {
3    for (auto& Child : Children) {
4      Child.HandleEvent(E);
5    }
6  }
7};

However, this limits flexibility. When creating a parent class, we often won't know what type of children we'll eventually be managing.

Even if we did know exactly what event types the children are interested in, declaring that within the parent would typically be a bad design.

To keep our code well organised and understandable, the event types that a class is interested in should be managed within that same class. For example, the event types that MinesweeperCell objects are interested in should be declared in MinesweeperCell class.

Objects can then provide that list to their parent, or to some object that is managing event traffic. For example:

1class Child: public EventReceiver {
2  // Subscribe to event types from constructor
3  Child(EventReceiver* Parent) {
4    Parent->SubscribeToEventTypes({
5      UserEvents::GAME_START,
6      UserEvents::GAME_END,
7      UserEvents::CELL_CLEARED,
8      // ...
9    })
10  }
11  
12  // ...
13}

This system can become increasingly elaborate - for example, objects may subscribe or unsubscribe from events at different points during their lifecycle:

1class Child: public EventReceiver {
2  // ...
3  void SetIsDisabled() {
4    // No longer interested in mouse events
5    Parent->UnsubscribeToEventTypes({
6      SDL_MOUSEMOTION,
7      SDL_MOUSEBUTTON
8    })
9  }
10  
11  // ...
12}

Designs that implement these inversions of control are often called publish-subscribe pattern or observer pattern. We cover this in more detail in the next chapter.

Timer and High Score

Usually, Minesweeper tracks how long it takes us to complete a game, and keeps track of our fastest time. Implementing this now may require research into some new topics. For example, the C++ standard library includes chrono, a system for working with time. We covered it in our beginner course:

Dates, Times and Durations

Learn the basics of the chrono library and discover how to effectively manage durations, clocks, and time points

View Related Lesson

Remembering our best time within a single session is easy, but keeping track of it from one session to the next requires saving the data to the player's hard drive.

Again, the C++ standard library can help us here. We cover it's file system utilities in our advanced course:

Working with the File System

Create, delete, move, and navigate through directories and files using the std::filesystem library.

View Related Lesson

Alternatively, mechanics like these can be implemented using functions provided by the SDL library. SDL_GetTicks64() (official documentation) can be used to track the time between two events, and RWops (official documentation) can be used to read and write data to the hard drive.

We'll cover the SDL timing and read/write functions later in the course.

Summary

Well done on finishing your Minesweeper project! We've successfully added flag placement functionality, complete with visual feedback and a counter in the UI.

These final features round out the gameplay, allowing players to mark potential mine locations and strategize their moves.

With all elements now in place, you have a fully-featured Minesweeper game that offers the same engaging puzzle-solving experience as the classic versions.

Congratulations on your achievement!

Placing Flags