Welcome to the home stretch! In this last lesson, we'll add the finishing touches that turn our Breakout project into a complete, replayable game. Our focus will be on the overall game flow - managing how the game begins, how it can be won or lost, and how it can be started again.

We'll implement a GameState enum to keep track of the current situation. We'll use this state to trigger a loss when the ball misses the paddle and to provide visual feedback to the player when they win or lose. We'll also add a pause system, so the action doesn't start until the player is ready, and a simple keypress to restart the entire game from level one.

Finally, we'll look at how to prepare our project for distribution by creating a "release" build configuration that strips out the level editor and other development tools, leaving us with a clean, standalone game.

Ending and Restarting Games

Finally, let's implement our game ending and restarting logic.

Tracking `GameState`

Let's begin by tracking what state the game is currently in - whether the player has won, lost, or the game is still in progress. This is likely to be useful to a wide variety of games, so we'll add it to the Scene base class in our engine. We'll default it to InProgress:

Engine/Scene.h

1// ...
2
3enum class GameState { InProgress, Won, Lost };
4
5class Scene {
6public:
7  // ...
8
9  GameState GetState() const { return State; }
10
11  void SetState(GameState NewState) {
12    State = NewState;
13  }
14
15private:
16  // ...
17  GameState State{GameState::InProgress};
18};

We'll also set it back to InProgress every time we load a level:

Breakout/src/BreakoutScene.cpp

1// ...
2
3void BreakoutScene::Load(int Level) {
4  // ...
5  SetState(GameState::InProgress);
6}

Back in our BreakoutScene class, let's set this state in response to the GAME_WON and GAME_LOST events. We're not yet broadcasting a GAME_LOST event, but we'll handle that in the next section:

Breakout/BreakoutScene.h

1// ...
2
3class BreakoutScene : public Scene {
4public:
5  // ...
6
7  void HandleEvent(const SDL_Event& E) {
8    Scene::HandleEvent(E);
9    using namespace UserEvents;
10    if (E.type == BLOCK_DESTROYED) {
11      --BlocksRemaining;
12      if (BlocksRemaining == 0) {
13        CompleteLevel();
14      }
15    }
16#ifdef ENABLE_CHEATS
17    else if (E.type == SDL_EVENT_KEY_DOWN &&
18      E.key.key == SDLK_C
19    ) {
20      CompleteLevel();
21    }
22#endif
23    else if (E.type == LAUNCH_LEVEL) {
24      Load(E.user.code);
25    } else if (E.type == GAME_WON) {
26      SetState(GameState::Won);
27    } else if (E.type == GAME_LOST) {
28      SetState(GameState::Lost);
29    }
30  }
31  // ...
32};

Losing Games

When the player misses the ball with their paddle, we want the game to end. We can detect this if the ball collides with our bottom wall. When that happens, we'll push our GAME_LOST event:

Breakout/Wall.h

1// ...
2#include "Breakout/Ball.h"
3
4// ...
5
6class Wall : public Entity {
7 public:
8  // ...
9  void HandleCollision(Entity& Other) override {
10    if (
11      dynamic_cast<Ball*>(&Other) &&
12      Position == WallPosition::Bottom
13    ) {
14      SDL_Event E{};
15      E.type = UserEvents::GAME_LOST;
16      SDL_PushEvent(&E);
17    }
18  }
19  // ...
20};

Restarting

We'll let the player restart the game by pressing the "R" key. When we detect that event, we'll set our game state back to InProgress, and load the first level:

Breakout/BreakoutScene.h

1// ...
2
3class BreakoutScene : public Scene {
4public:
5  // ...
6
7  void HandleEvent(const SDL_Event& E) {
8    Scene::HandleEvent(E);
9    using namespace UserEvents;
31    else if (
32      E.type == SDL_EVENT_KEY_DOWN &&
33      E.key.key == SDLK_R
34    ) {
35      SetState(GameState::InProgress);
36      Load(1);
37    }
38  }
39  // ...
40};

Reacting to Game Loss and Victory

Now that win and loss events are being broadcast through our program, we're free to make any part of our application react to those events in the usual ways. Alternatively, we can check the state of our game at any time using the scene's GetState() function.

For example, let's override our scene's Render() function to change the background color depending on the game state. We'll fill the surface with a solid color first, and then call the base Scene's Render() method to render our entities on top of that rectangle:

Breakout/BreakoutScene.h

1// ...
2
3class BreakoutScene : public Scene {
4public:
5  // ...
6  void Render(SDL_Surface* Surface) {
7    const auto* Fmt{SDL_GetPixelFormatDetails(
8      Surface->format
9    )};
10
11    if (GetState() == GameState::Won) {
12      SDL_FillSurfaceRect(Surface, nullptr,
13        SDL_MapRGB(Fmt, nullptr, 20, 50, 20)
14      );
15    } else if (GetState() == GameState::Lost) {
16      SDL_FillSurfaceRect(Surface, nullptr,
17        SDL_MapRGB(Fmt, nullptr, 50, 0, 0)
18      );
19    }
20    Scene::Render(Surface);
21  }
22  // ...
23};

With those changes, our background turns red when we lose:

Screenshot showing the game in the loss state

And green when we win:

Screenshot showing the game in the victory state

Pausing the Game

For our final feature, let's implement pausing. To support a paused state, let's first allow our physics and input to be paused. We'll pause them simply by disabling them, so let's update those components to support that.

Disabling Physics

To have our physics component pause when it is disabled, we can simply stop all of the updates that happen in our Tick() function:

Engine/ECS/src/PhysicsComponent.cpp

1// ...
2
3void PhysicsComponent::Tick(float DeltaTime) {
4  if (!GetIsEnabled()) return;
12}
13
14// ...

Again, we may want to take this further. For example, in our current implementation, a disabled physics component will still allow ApplyForce() and ApplyImpulse() to be used. The effect of those will be to change the acceleration and velocity of the component, which will be used as soon as it's unpaused.

This may be the preferred approach. Alternatively, it may be more intuitive to have the component effectively ignore those instructions when disabled, perhaps with an error message.

Disabling Physics on Slow Frames

The time between frames, DeltaTime, is usually very small. However, our program can sometimes stall for a much longer period.

This might be because the operating system is busy, another application is hogging resources, or we may even pause our program intentionally in a debugger.

When our program starts responding again, a huge DeltaTime will have accumulated and, when multiplied by our Velocity, the ball may move a very large distance in a single step.

This can break our game, as it can make our ball move further than the thickness of our walls in a single step. This will cause the collision to be missed and the ball to no longer be within the window.

We can rarely detect that our program is going to stop updating in advance. Instead, on each iteration of our application loop, we can check if it has been a long time since the previous iteration. Below, we'll prevent our physics component from ticking on any iteration that takes longer than 0.1 seconds:

Engine/ECS/src/PhysicsComponent.cpp

1// ...
2
3void PhysicsComponent::Tick(float DeltaTime) {
4  if (DeltaTime > 0.1) return;
5  // ...
6}
7
8// ...

An easy way to test this behavior on Windows is to move the window whilst our game is running. When this happens, Windows will pause the execution of our application loop. With our new DeltaTime check, as long as that pause is longer than 100 milliseconds, our physics simulation will pause too.

Move options to deal specifically with how our application can detect and respond to the user dragging the window are discussed in this thread on SDL's GitHub repository.

Disabling Input

Our current input commands are setting the velocity of the physics component so, when the physics component is disabled, the input component is effectively disabled too.

However, that won't be true for any other inputs we might potentially use in the future, so let's explicitly support disabling our InputComponent.

To prevent inputs from having any effect on a disabled input component, it also shouldn't tick, which will therefore stop it from polling the keyboard state. We should also disable the HandleEvent() logic so that the input component stops responding to SDL_EVENT_KEY_DOWN events:

Engine/ECS/src/InputComponent.cpp

1// ...
2
3void InputComponent::Tick(float DeltaTime) {
4  if (!GetIsEnabled()) return;
19}
20
21void InputComponent::HandleEvent(
22  const SDL_Event& E) {
23  if (!GetIsEnabled()) return;
33}

Triggering the Game Pause

Currently, our ball starts moving as soon as the program starts. That can be a little annoying, so let's open the game in a paused state, and only start the level when the player is ready.

We'll do this by disabling our paddle's PhysicsComponent and InputComponent, and our ball's PhysicsComponent.

Let's add a new private helper function, and call it in the constructor:

Breakout/Paddle.h

1// ...
2
3class Paddle : public Entity {
4public:
5  Paddle(BreakoutScene& Scene) : Entity{Scene} {
6    // ...
7
8    SetIsPaused(true);
9  }
10
11  // ...
12
13private:
14  void SetIsPaused(bool isPaused) {
15    Input->SetIsEnabled(!isPaused);
16    Physics->SetIsEnabled(!isPaused);
17  }
18
19  // ...
20};

We implement similar logic for our ball. We mostly care about the PhysicsComponent so we stop the ball from moving, but we can additionally toggle the CollisionComponent as a optional optimization. It reduces event traffic when the game is lost but the ball continues to overlap with the bottom wall, thereby causing additional GAME_LOST events to be broadcast every tick.

Breakout/Ball.h

1// ...
2
3class Ball : public Entity {
4public:
5  Ball(BreakoutScene& Scene) : Entity{Scene} {
6    // ...
7
8    SetIsPaused(true);
9  }
10
11  // ...
12private:
13  void SetIsPaused(bool isPaused) {
14    Physics->SetIsEnabled(!isPaused);
15    Collision->SetIsEnabled(!isPaused);
16  }
17};

If we run our game now, it starts in a paused state. Every time we load a new level, we load a new ball and paddle, so we also effectively pause between levels.

Unpausing the Game

We'll let the user press their space bar to start each level. When they do that, and the game is in the InProgress state (that is, they haven't already won or lost), then we'll unpause our paddle:

Breakout/Paddle.h

1// ...
2
3class Paddle : public Entity {
4public:
5  // ...
6
7  void HandleEvent(const SDL_Event& E) override {
8    if (
9      E.type == SDL_EVENT_KEY_DOWN &&
10      E.key.key == SDLK_SPACE &&
11      GetScene().GetState() == GameState::InProgress
12    ) {
13      SetIsPaused(false);
14    } else if (
15      E.type == UserEvents::GAME_WON ||
16      E.type == UserEvents::GAME_LOST
17    ) {
18      SetIsPaused(true);
19    }
20  }
21
22  // ...
23
24};

And similarly, for our ball:

Breakout/Ball.h

1// ...
2
3class Ball : public Entity {
4public:
5  // ...
6  void HandleEvent(const SDL_Event& E) override {
7    if (
8      E.type == SDL_EVENT_KEY_DOWN &&
9      E.key.key == SDLK_SPACE &&
10      GetScene().GetState() == GameState::InProgress
11    ) {
12      SetIsPaused(false);
13    } else if (
14      E.type == UserEvents::GAME_WON ||
15      E.type == UserEvents::GAME_LOST
16    ) {
17      SetIsPaused(true);
18    }
19  }
20  // ...
21};

Refactoring Duplicate Code

We just added some duplicate code across our Paddle and Ball classes, with the HandleEvent() function in particular being identical. A small amount of duplication - particularly at the end of the project - isn't particularly problematic.

However, if we found ourselves needing to repeated this a third time, or if we were going to expand these functions with more identical logic in the future, we should consider refining our approach.

Our component system often gives us the natural way of solving problems like this - creating a new component that our entities can share. For example, a BreakoutPauseManager component might look something like this:

Breakout/BreakoutPauseManager.h

1#pragma once
2#include "Engine/ECS/Component.h"
3#include "Engine/ECS/PhysicsComponent.h"
4#include "Engine/ECS/InputComponent.h"
5#include "Config.h"
6
7class BreakoutPauseManager : public Component {
8public:
9  BreakoutPauseManager(Entity* Parent)
10  : Component{Parent} {
11    SetIsPaused(true);
12  }
13
14  void HandleEvent(const SDL_Event& E) override {
15    if (
16      E.type == SDL_EVENT_KEY_DOWN &&
17      E.key.key == SDLK_SPACE &&
18      GetScene().GetState() == GameState::InProgress
19    ) {
20      SetIsPaused(false);
21    } else if (
22      E.type == UserEvents::GAME_WON ||
23      E.type == UserEvents::GAME_LOST
24    ) {
25      SetIsPaused(true);
26    }
27  }
28
29private:
30  void SetIsPaused(bool isPaused) {
31    if (InputComponent* Input{
32      GetOwner()->GetComponent<InputComponent>()
33    }) {
34      Input->SetIsEnabled(!isPaused);
35   }
36
37   if (PhysicsComponent* Physics{
38     GetOwner()->GetComponent<PhysicsComponent>()
39   }) {
40     Physics->SetIsEnabled(!isPaused);
41   }
42  }
43  
44   if (CollisionComponent* Collision{
45     GetOwner()->GetComponent<CollisionComponent>()
46   }) {
47     Collision->SetIsEnabled(!isPaused);
48   }
49  }
50};

We could then delete the HandleEvent() and SetIsPaused() functions from both our Paddle and Ball classes, and instead attach a BreakoutPauseManager component to them in their constructors:

Files

Breakout

Select a file to view its content

Excluding the Editor

With all our features in place, we're now ready to ship our game! The last step is to disable any undesirable preprocessor definitions (such as DRAW_DEBUG_HELPERS and ENABLE_CHEATS).

We also need to detach our editor from the project. Our files already include preprocessor directives that will exclude editor-specific logic when the WITH_EDITOR macro is not defined.

However, our editor source files are still being sent to the compiler, and that may cause compilation issues or other problems. The simplest way to solve this is to include the #ifdef checks in those files, too. This means that, when WITH_EDITOR isn't defined, those files will be empty by the time the compiler sees them.

For example:

Editor/src/Actor.cpp

1#ifdef WITH_EDITOR
46#endif

A more elegant solution would involve conditionally not sending those files to be compiled at all. The build management tools included in most IDEs should let us automate this.

In Visual Studio, for example, you can select the files in the Solution Explorer, right-click on them, click on Properties, and set Excluded From Build to "Yes" for any build configuration that should not include the editor:

Screenshot showing excluding files in Visual Studio

If you're using CMake, the simplest option is to set() a variable. We can then append the files to the build and set the preprocessor directive only if that variable is ON:

CMakeLists.txt

1cmake_minimum_required(VERSION 3.16)
2set(CMAKE_CXX_STANDARD 20)
3
4# Change me to ON to enable the editor
5SET(WITH_EDITOR OFF)
6
7project(Breakout VERSION 1.0.0)
8
9# List of source files excluding editor files
10set(SOURCE_FILES
11  "main.cpp"
12
13  "Engine/src/Scene.cpp"
14  "Engine/ECS/src/Component.cpp"
15  "Engine/ECS/src/CollisionComponent.cpp"
16  "Engine/ECS/src/ImageComponent.cpp"
17  "Engine/ECS/src/PhysicsComponent.cpp"
18  "Engine/ECS/src/InputComponent.cpp"
19  "Engine/ECS/src/Commands.cpp"
20
21  "Breakout/src/BreakoutScene.cpp"
22  "Breakout/src/Ball.cpp"
23)
24
25# Add editor files to the list if WITH_EDITOR is ON
26if(WITH_EDITOR) 
27  list(APPEND SOURCE_FILES 
28    "Editor/src/Button.cpp" 
29    "Editor/src/Blocks.cpp" 
30    "Editor/src/Actor.cpp" 
31    "Editor/src/ActorTooltip.cpp" 
32    "Editor/src/Level.cpp" 
33  ) 
34endif() 
35
36add_executable(Breakout
37  ${SOURCE_FILES}
38)
39
40target_compile_definitions(Breakout PUBLIC
41  # CHECK_ERRORS
42  # ENABLE_CHEATS
43  # DRAW_DEBUG_HELPERS
44)
45
46# Conditionally set the WITH_EDITOR preprocessor definition
47if(WITH_EDITOR) 
48  target_compile_definitions(Breakout PUBLIC 
49    WITH_EDITOR 
50  ) 
51endif() 
52
53target_include_directories(
54  Breakout PUBLIC
55  ${PROJECT_SOURCE_DIR}
56)
57
58set(SDLTTF_VENDORED ON)
59set(VENDOR_DIR "${PROJECT_SOURCE_DIR}/vendor")
60add_subdirectory(${VENDOR_DIR}/SDL)
61add_subdirectory(${VENDOR_DIR}/SDL_image)
62add_subdirectory(${VENDOR_DIR}/SDL_ttf)
63
64target_link_libraries(Breakout PRIVATE
65  SDL3::SDL3
66  SDL3_image::SDL3_image
67  SDL3_ttf::SDL3_ttf
68)
69
70set(AssetDirectory "${PROJECT_SOURCE_DIR}/Assets")
71add_custom_command(
72  TARGET Breakout POST_BUILD
73  COMMAND
74    ${CMAKE_COMMAND} -E copy_if_different
75      "$<TARGET_FILE:SDL3::SDL3>"
76      "$<TARGET_FILE:SDL3_image::SDL3_image>"
77      "$<TARGET_FILE:SDL3_ttf::SDL3_ttf>"
78      "$<TARGET_FILE_DIR:Breakout>"
79  COMMAND
80    ${CMAKE_COMMAND} -E copy_directory_if_different
81      "${AssetDirectory}"
82      "$<TARGET_FILE_DIR:Breakout>/Assets"
83  VERBATIM
84)

With those changes, we can now easily prepare a version of our game that doesn't include our developer tools. Remember, our game still needs the output of those tools, such as the "Level1.bin" files.

Ensure that those are included alongside all the other assets (such as image files, fonts, and SDL's library files) that our program needs at run time.

Complete Code

Complete versions of all the files we updated in this lesson are available below:

Files

Breakout

Engine

CMakeLists.txt

Select a file to view its content

A zip file containing all of the code is available here:

breakout-end.zip

The fonts and images used in our screenshots are available here:

Summary

Our Breakout clone is now finished! We introduced a GameState enum, implemented win and loss conditions, gave the player a way to restart, and created a pause system that activates at the start of levels and on game-end conditions.

Finally, we prepared our build system to easily exclude the editor for a release version.

Here's what we've accomplished in this project:

We built a fully featured Breakout clone with multiple levels.
We created a data-driven workflow with a separate level editor.
We implemented a component-based engine for managing game entities.
We handled player input, physics, and complex collision responses.
We managed the overall game state, including winning, losing, pausing, and restarting.

Breakout: Final Touches

Ending and Restarting Games

Tracking `GameState`

Engine/Scene.h

Breakout/src/BreakoutScene.cpp

Breakout/BreakoutScene.h

Losing Games

Breakout/Wall.h

Restarting

Breakout/BreakoutScene.h

Reacting to Game Loss and Victory

Breakout/BreakoutScene.h

Pausing the Game

Disabling Physics

Engine/ECS/src/PhysicsComponent.cpp

Disabling Physics on Slow Frames

Engine/ECS/src/PhysicsComponent.cpp

Disabling Input

Engine/ECS/src/InputComponent.cpp

Triggering the Game Pause

Breakout/Paddle.h

Breakout/Ball.h

Unpausing the Game

Breakout/Paddle.h

Breakout/Ball.h

Refactoring Duplicate Code

Breakout/BreakoutPauseManager.h

Files

Excluding the Editor

Editor/src/Actor.cpp

CMakeLists.txt

Complete Code

Files

Summary

Understanding Screen & World Space

Game Development with SDL3

Breakout: Final Touches

Ending and Restarting Games

Tracking GameState

Engine/Scene.h

Breakout/src/BreakoutScene.cpp

Breakout/BreakoutScene.h

Losing Games

Breakout/Wall.h

Restarting

Breakout/BreakoutScene.h

Reacting to Game Loss and Victory

Breakout/BreakoutScene.h

Pausing the Game

Disabling Physics

Engine/ECS/src/PhysicsComponent.cpp

Disabling Physics on Slow Frames

Engine/ECS/src/PhysicsComponent.cpp

Disabling Input

Engine/ECS/src/InputComponent.cpp

Triggering the Game Pause

Breakout/Paddle.h

Breakout/Ball.h

Unpausing the Game

Breakout/Paddle.h

Breakout/Ball.h

Refactoring Duplicate Code

Breakout/BreakoutPauseManager.h

Files

Excluding the Editor

Editor/src/Actor.cpp

CMakeLists.txt

Complete Code

Files

Summary

Understanding Screen & World Space

Tracking `GameState`