Learn some basic game development skills in C++ with the library SDL (Simple DirectMedia Layer). In this course you learn to create a window and draw some rectangles. Later we build on top of that and design and implement a simple labyrinth game where the player has to go from one point of the screen to another end point. This course requires a fundamental knowledge of the programming language C++. Knowing C also helps.

Build a Game with SDL - Make a Labyrinth with C++ from Scratch - Beginner Tutorial

This lesson picks up from an initial exploration of Simple DirectMedia Layer (SDL), a library commonly used to develop video games.

The library header files for development were installed using apt in Ubuntu.

The function SDL_Init was used to initialize SDL. You can retrieve the errors emitted by SDL using the function SDL_GetError. You might find it useful to use the function SDL_Log for logging, the act of recording events that took place in the program.

One of the very first things you do is create a window to hold the game screen. That can be done with the SDL_CreateWindow function. Some of the arguments it takes are the title of the window, its position, and its dimensions.

Many of the functions from SDL return a pointer, so it is common to check if anything went wrong by comparing the return value to NULL, as was done with the result of SDL_CreateWindow.

The surface of the window can be retrieved using the function SDL_GetWindowSurface. You just need to pass in the pointer to the SDL_Window struct.

You can paint a filled rectangle on a surface using the SDL_FillRect function. It takes the pointer to the surface you want to paint, the pointer to the rectangle where you want to paint, and the color. You can pass NULL instead of SDL_Rect* to paint the whole surface. For the color, you can map to the required Uint32 using the function SDL_MapRGB.

The rectangle that was painted over the window surface will not appear to the user until the function SDL_UpdateWindowSurface is called.

A call to SDL_Delay was used to halt the execution of the program for a few milliseconds so the user could see something happen before it quit.

When you allocate resources such as an SDL_Window, it is important to remember to deallocate them. In this case, we used SDL_DestroyWindow to deallocate the memory used by the window and its surface.

Before the program quits, it is also important to make a call to close SDL. That is, using SDL_Quit().

Based on that initial exploration of libsdl, the lesson goes on to show how to paint a filled rectangle on a specific area of the window surface. An SDL_Rect is defined and its address is passed as the second argument to the SDL_FillRect function.

As part of more practice, concentric filled rectangles are painted at the center of the window surface.

A small square is used to represent the player on the screen. Its position is determined by an SDL_Rect structure. Its color is determined by a Uint32 variable whose value is mapped using a call to SDL_MapRGB().

We also learn to handle player input by polling events with the function SDL_PollEvent. Simply create a variable of type SDL_Event. Then pass the address of that variable to the SDL_PollEvent function. Keep calling that function as the condition of a loop, so long as the return value is not zero, meaning there is still some input to process.

We check if the event is a call to quit the program or if the event was a keyboard event where the key was pressed down.

The SDL_QUIT event type signals that we need to end the game loop and stop the execution of the program.

The SDL_KEYDOWN event type tells us we should look into player keyboard input. we check what key was pressed using the value from event.key.keysym.sym. For example, If the value is SDLK_RIGHT, it means the right-arrow key was pressed down. We then update the player position rectangle structure accordingly, based on that input signal.

We improve the player input with collision detection at the borders of the screen. That is, we cannot allow the player to walk outside the screen boundaries. That is done with simple if statement checks on the next position coordinate requested by the user.

By the end of the lesson, we have a screen with concentric filled rectangles. A small square, representing the player, can move across that screen with the keyboard arrow keys.


Exploring Game Development in C++ with SDL (libsdl / SDL2) – Beginner Tutorial from Scratch

# NBK TechWorld Live Stream Summary

## Overview
In this live stream, the SDL (Simple DirectMedia Layer) library for game development is explored using C++. The session builds on previous work, including setting up SDL and creating a simple window.

## Key Points

### Previous Session Recap
- Installed SDL 2 on a Linux Ubuntu distribution using `sudo apt install libsdl2-dev`.
- Learned to:
  - Initialize SDL.
  - Create a window centered on the screen with dimensions 640x480 pixels.
  - Fill the window with a blue color.
  - Pause for 5 seconds to view the blue screen.
  - Clean up by destroying the window and quitting SDL.

### New Features Explored
- **Filling Multiple Rectangles:**
  - Introduced the use of `SDL_Rect` for defining areas to paint on the surface.
  - Created concentric rectangles with varying colors using `SDL_FillRect`.

- **Positioning and Centering Rectangles:**
  - Discussed how to center rectangles on the screen.
  - Demonstrated changing rectangle dimensions by modifying width and height constants.
  
- **Game Loop and User Input:**
  - Implemented a game loop to handle continuous rendering and user input.
  - Used `SDL_PollEvent` to check for events like quitting the application or keyboard presses.

- **Moving a Player Rectangle:**
  - Created a square to represent a player, which moves based on arrow key inputs.
  - Implemented boundary checks to prevent the player from moving off-screen by capping the position.

## Code Highlights
- **Rectangle Structure:**
  ```cpp
  SDL_Rect rectangle1 = {x, y, width, height};
  ```
- **Color Assignment:**
  ```cpp
  Uint32 color = SDL_MapRGB(windowSurface->format, r, g, b);
  ```
- **Event Handling Loop:**
  ```cpp
  while (!quit) {
      SDL_PollEvent(&event);
      if (event.type == SDL_QUIT) {
          quit = true;
      }
      // Move player based on key presses
  }
  ```

### Summary
- The stream covered creating and managing rectangles in SDL, centered positioning, handling user input, and ensuring player movement is bounded by the screen's dimensions.
- The final program demonstrates moving a rectangle on the screen using keyboard inputs while maintaining boundary checks.

## Conclusion
The session successfully introduced fundamental concepts in game development using SDL 2 in C++, focusing on graphics rendering and user interaction. Participants were encouraged to experiment with adding further features, such as more complex shapes and game mechanics.

**Thank you for attending! See you next time!**

fff2-01 Exploring Game Development in C++ with SDL (libsdl / SDL2) – Beginner Tutorial from Scratch

The goal of this lesson is to draw a game map with tiles that are loaded from a text file.

The screen can be segmented into small squares of length 32 pixels. If the width of the screen is 640px, then there will be 640px ÷ 32px = 20 tiles across. If the height of the screen is 480px, then there will be 480px ÷ 32px = 15 tiles down.

The game map can be stored in a text file using the following simple format: each line represents a row of tiles in the screen. To identify the type of tile for each cell, we use an integer number. The number for each cell is separated from the other by a space.

```
0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0
0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

Each integer determines what kind of tile to be drawn. The number 0 represents the floor tile; the player can walk over it. The number 1 represents the wall tile; the player should not be able to walk on it.

As an example, consider this piece of the map, with 3 tiles across and 3 tiles down. The rendered game map image follows the data file:

```
0 1 1
0 0 0
1 0 0
```

![](/images/3by3gamemap.png)

After establishing the format for the game map, we create thefile GameMap.txt to store the tile identifiers.

In order for the program to draw the map, it needs to know what to draw. So we have to open the map file and read its contents.

We create the function loadGameMap to do that. It uses the fstream header to allow us to use the ifstream class. You can instantiate an object using the constructor, passing the name of the file as argument. After that, you check if the file is open, then proceed to iterate over the contents using the >> operator inside a loop:

```
while (gameMapFile >> tileId)
```

The variable on the left-hand side of the >> operator is the object bound to the file; the variable on the right holds the value of the next integer number read.

We store that value in an array of integers of size 20 × 15 = 300 elements. Each of those elements stores the id of the tile, so we know what kind to draw later, be it floor or wall.

After going through the data file, you should make sure to close it.

Once we load the identifiers for each tile into memory, we need to create a surface to paint them. We write the createGameMapSurface function to do that. It goes through each element in the array of tile identifiers and figures out where to paint each little square.

You can draw the tiles in many different ways. The lesson does it top to bottom, left to right. That is, it starts with the first row, then paints a tile in each column there. Next, it goes to the second row, then paints the tiles left to right. Repeat until there are no more rows to paint.

The function SDL_FillRect needs a pointer to a SDL_Rect to know what area of the surface to paint. We set the x and y members of the structure using the column and row position of the tile, respectively.

For a given row (of fixed y coordinate), the tiles are laid out along the x axis. So to get the coordinate for the tile at column index j, you multiply it by the width of the tile, 32 pixels:

```
rectangle.x = j * 32
```

To figure out the x coordinate, you do something similar, but involving the row index i, multiplying it by the height of the tile:

```
rectangle.y = i * 32
```

Note both i and j are counted starting from zero, not one. That is why I called them indices.

Once you have those two coordinates, you know exactly where to paint on the surface. But you do not yet know what kind of tile to paint. To figure that out, you look into the array of tile identifiers.

The lesson used a one-dimensional array to store the two-dimensional map. Because of that, we need a formula for the index of the element.

A two-dimensional array could have been used in this case. It could make development easier and there would not be a need for a formula here.

In any case, you can figure out the formula with this simple grid of 3x3:

![](/images/arrayelementindexmapping.png)

To get the element that is in the second row, second column, you consider:

For the column, we can get there if we add the column index j to the tile index: tiles[j]. The second column has index 1, so we have tiles[1].

That would give us the second column for the first row. To get to the second row, we need to add the total number of tiles for a single row. In the 3x3 example, it is 3. So we have 1 + 3 = 21, making the retrieval statement be tiles[4].

In general, the formula is

```
i * TILES_PER_ROW + j
```

For the case where the screen has a width of 640px, the tiles per row would be 20, if each tile has a width of 32px. The formula now being:

```
i * 20 + j
```

After getting the identifier for the tile, use a conditional such as an if statement to define the parameters for the tile that will be drawn. If the tile id is 0, make it have black color. If the tile id is 1, make it have white color.

We do it in a very simple way, but in practice you substitute the color statement for whatever configuration is necessary to render that tile. For example, the tile could be an image rendered out of a tile sheet and the statement would pick the correct clip from that tile sheet.


Loading the Game Map from a File and Painting it on the Window Surface – SDL Tutorial

fff2-02 Loading the Game Map from a File and Painting it on the Window Surface – SDL Tutorial

Mapping Coordinate to Corresponding Tile and Implementing Wall Collision – SDL2 Tutorial

# Summary of SDL2 Labyrinth Game Lesson

## Overview
In this lesson, we continued developing the Labyrinth game using SDL2. The focus was on implementing collision detection so that the player cannot walk through walls.

## Key Points

- **Initial Setup**: 
  - The player can move in the game world, but walls need to be defined (white parts) to prevent movement through them (black parts).

- **Background Color Corrected**: 
  - The walkable tile color was changed to black (RGB: 0, 0, 0).

- **Collision Detection Implementation**:
  - Collision detection logic was added to prevent the player from moving into wall tiles.
  - The algorithm first checks if the player's new position would collide with a wall based on the current position and intended movement direction.
  
- **Coordinate Mapping**:
  - An essential step included converting the player's position to tile coordinates. 
  - The player's pixel position is mapped to the corresponding tile ID in a one-dimensional array representing the game map using a derived formula.

- **Tile ID Function**:
  - A function `map_coordinate_to_tile_ID` was created to convert coordinates into their respective tile indices and IDs.

- **Wall Checking Logic**:
  - Added logic to evaluate the next tile's ID when moving in any direction, verifying if it's walkable or not (e.g., wall tiles vs. floor tiles).

- **Refactoring**:
  - The repetitive nature of the code for different player movements (up, down, left, right) was highlighted, encouraging further refactoring to simplify the logic.

- **Final Touches**:
  - A clear structure emerged in the code, with specific checks for each direction the player might attempt to move.
  - The final implementation maintained the player's actual position separate from the temporary new position used in collision detection.

## Conclusion
The lesson concluded with a successful implementation of wall collision detection, reinforcing understanding of coordinate mapping and collision logic. Viewers were encouraged to refactor the code further for efficiency and readability.

## Call to Action
The instructor requested support through subscriptions, comments, and notifications to help others interested in the topic and concluded the lesson.

fff2-03 Mapping Coordinate to Corresponding Tile and Implementing Wall Collision – SDL2 Tutorial

Defining the Entrance and Exit Position for the Labyrinth Game in SDL

# SDL Labyrinth Game Development Summary

## Overview
In this lesson, we aim to enhance the SDL-based labyrinth game by implementing an entrance and exit for the player. The current setup allows for movement and wall collision detection, but does not yet define a start and finish point.

## Objectives
1. **Define Entrance & Exit**: Determine starting and ending points of the labyrinth according to the game map.
2. **Modify Game Map Format**: Update `gamemap.txt` to include coordinates for the entrance and exit.
3. **Visual Representation**: Use colors (green for entrance and red for exit) to visually indicate these points on the screen.
4. **Game Logic**: Check for player movement into the exit tile to win the game and provide options for restarting.

## Implementation Steps

### 1. Update Game Map Format
- Modify the `gamemap.txt` to include two lines at the beginning for entrance (X, Y) and exit (X, Y) coordinates.
- Convert these coordinates into tile indices.

### 2. Code Adjustments
- Update `main.cpp` to read the new format and store entrance and exit positions using SDL Rect.

### 3. Drawing Entrance & Exit
- Implement functions to paint the entrance and exit within the game window:
    - **Paint Entrance**: Draw a filled rectangle at the entrance coordinates with the specified color.
    - **Paint Exit**: Do the same for the exit.
- Ensure that the drawing operations are called after loading the game map.

### 4. Player Movement Logic
- Implement logic to check if the player has reached the exit tile. If so, display a win message and prevent further movement until the player decides to restart.

### 5. Debugging and Testing
- Validate that the entrance and exit coordinates are correctly parsed and displayed.
- Ensure that the painting functions do not overlap or erase previous drawings (like the player).

## Challenges Faced
- Identifying and correcting coordinate indexing (X as column, Y as row).
- Properly handling SDL functions to ensure that colors and rectangles are drawn correctly without overwriting other components.
- Adding visual feedback for progress and winning conditions.

## Conclusion
In this session, we've set up the foundation for a labyrinth game, creating a clear start and finish with visual indicators. Future lessons will cover enhancing visual feedback to indicate game states, like winning and restarting the game.

---

Feel free to continue to the next lesson where we will add more features to improve user interaction and feedback within the game.

fff2-04 Defining the Entrance and Exit Position for the Labyrinth Game in SDL

Improving the Codebase with Refactoring using Game class for Better Management

fff2-05 Improving the Codebase with Refactoring using Game class for Better Management

Wraping Up The Migration of Logic from Main to the Game Class

```markdown
# Refactoring Game Logic to Game Class

In this session, we continued refactoring the logic from `main.cpp` into a dedicated `game` class, focusing on organizing the game loop and related functionalities.

## Key Changes and Steps

1. **Game Loop in the Game Class**:
   - Moved the game loop from `main.cpp` to a new `run` function inside the `game` class.
   - Updated `main.cpp` to call `game.run()`.

2. **Private Variables**:
   - Defined `quit` as a private member of the `game` class.
   - Moved the polling event and player position variables into the `game` class.

3. **Handle Player Input**:
   - Created a new member function `handlePlayerInput()` in the `game` class to manage player inputs.

4. **Player Position Management**:
   - Moved the player position variable to the `game` class as a private member.
   - Implemented a function `setPlayerPosition()` that sets the initial position of the player after loading game maps.

5. **Initialization**:
   - Set initial values for variables like player position and window surface in the constructor of the `game` class to avoid garbage data.

6. **Code Organization**:
   - Created a new header file `tileType.h` to define tile constants used throughout the game.
   - Ensured all function declarations and definitions were consistent and accessible.

7. **Error Handling**:
   - Compiled the code multiple times to identify and fix errors, ensuring all changes were integrated properly and functions called correctly.

## Compiling and Testing

After refactoring, the game was compiled with several iterations to fix any errors:
- Missing semicolons and undeclared functions were rectified.
- Optimized header inclusions in `game.h`.

The final test confirmed that the game logic worked as intended, with smooth gameplay and functional quitting mechanisms.

## Conclusion

The entire game logic has now been successfully refactored into the `game` class, enhancing code organization and readability. This change allows for better maintainability and scalability of the game's architecture.

Thank you for watching, and see you in the next lesson!
```


Let's continue our refactoring of the logic in main.cpp so it goes to the game class.
So let's pick up from 991.
We have the event.
We have player position.
We have the game loop.
And right after game loop we have the cleaning up of the surface and window.
So let's see what we can do here.
So let's think about this.
Well the game loop right here, we can make the game loop and place that into a function
in the game class.
So this function in game class will be responsible for running the game loop.
So we can just call it run.
So game.run would be the function where you are going to call.
And then we can finish off, wrap it up with putting the free surface and destroy window
in the shutdown of the game.
And these variables go as private variables.
How about that?
Okay so let's start doing that.
So first I'm going to take the while loop.
I'm going to cut.
I'm going to go to game.cpp.
I'm going to paste.
Oops, actually I want to make a function for that.
So before I paste go to game.h.
Add a new public member function.
Call it run.
No parameters.
No return types.
It's void.
Go back to game.cpp.
Let's call void game colon colon run.
Let's paste the code for the game loop here.
Now we need the variable quit.
So let's go back to main.cpp.
We can cut line 93 and put it before line 147.
And we can have the variable there as local.
You probably could have it as a private member later on if you want to reference the quit
from any other member function.
But for the time being I can leave it here.
So we while quit.
So we have the polling of the event.
Now we need the event as well.
So go back to main.cpp.
Cut line 91.
Move that to here line 148.
And we pull the event.
If the type is as deal quit.
Quit is true and the loop will finish.
Else if event.type then we call the handle player input.
Now we need this function handle player input.
Let's define it as a member function of the game class game.h go back.
Let's call it void handle player input.
And for the parameters you probably won't need them.
Let's take a look.
Go back to game.cpp.
We're calling it the event actually reminding we are going to need the event here if it's
a local here.
But you could also place this as a private variable.
So let's first just deal with the ones we don't have yet.
So event is here.
So that's fine.
Player position we don't have it.
Let's go back to main.cpp.
We have a player position right here.
Let's take this player position because something that's of interest to perhaps more than just
one member function.
So I'm going to cut this and I'm going to go back to game.cpp.
Now for that part actually I want to set it somewhere else.
Let me backtrack a little bit.
So the player position here is using the interest position dot x and interest position dot oi.
So we need to we're going to do the following.
We're going to take left hand side which is the declaration of the variable.
We're going to make that a private.
And then the right hand side will be the definition that's going to happen as we call game a new
function.
Let's call this new function to set the player position.
The problem is we have to do it right after these because the entrance position is only
set when we load the game maps right so we cannot just initialize this in the constructor
of the game class.
So let's take that.
So I'm going to cut actually I'm going to copy the left hand side.
I'm going to make it go to the game header file as a private SDL wreck player position
right there.
Now going back to main I'm going to take this except the tie and I'm going to remove it
and I'm going to create a new function.
I'm going to call it set player position.
Okay, so let me go back to game.h and add that function avoid set player position.
No parameters and game.cpp.
That's actually the initial position or is it the player?
Yeah, that would be set initial position.
That's fine.
Let me add here void game.coloncollinset player position and I'm going to paste that code saying
that the player position equals the entrance position.x and suppose it's the y 32 32.
So we assume the assumption is that this function will only be called after these coordinates
coordinates where the interest position have been set.
So set if that assumption and go back here to main it's been called go back to game.cpp
we have that here and you probably want to set some initial value in the constructor
if you want for the rack otherwise might have the garbage data.
So usually when you have all these variables you want to set some default value just in case.
So if the player position for example let's go to game.cpp.
I'm going to say player position equals I'm going to say x 0 y 0 with the style size hide
the style size.
So in case there doesn't something happens I don't know the play position not set at
least it will be in the very first column in line.
I can also do that for the others if you want a game map surface.
Maybe you can set that to null because it's a pointer.
No exit position entrance position is here.
The tiles are going to deal that later so I'll leave it there.
Window surface and window.
Window is null.
Window surface is null.
Just to have an initial value.
The other ones these are supposed to be constants I would say a static constant but let's do it.
Let's do it later.
It don't have to be that if you want anyway.
I forgot the game loop right so I have to say game.run.
So the loop around here.
And we can move these free surface and destroy window to the shutdown function.
Right before the quits.
And let's check the variable names game map surface here.
Destroy window window window is here game.h.
It seems like everything is in place and we have set player position here.
The run event select backtrack what we had.
So we had a handle player input right.
We don't need player position.
We don't need game map tiles.
So let's go to this function.
Is it here yet?
It's not.
We have to go back to main.cpp and cut the handle player position function.
And base any game.cpp.
Let me put it at the end.
And put the prefix game colon colon before the function name handle player input.
And move the second and third because they are already as accessible as private data members.
Let's add this to the header.
I just copy this part and remove the prefix.
Oh, it's already here. Sorry.
There you go.
Now since you have this event here, actually you can also make that a private so you don't have to have it passed.
So I'll remove that from the handle player input and I'll cut and paste into the private member of game.
So we have an event here.
Now make sure to go back to the game loop in the game run and remove this declaration because it's already been...
It's already instantiated, right?
It's already done in here.
Now going back to the game run.
We have the polling of the event and we have player input.
We don't need an event anymore here.
After that, this is the input part.
We have the split surface game map surface.
Okay, window surface fine.
Now we have this return.
Maybe you want to crash.
For now, player color, surface...
Actually, this game player color doesn't have to be set.
Does it have to be set in the loop here?
So perhaps I could take this and make it a private member as well.
So let's do it the following.
I'm going to copy this, go to game.h.
I'm going to paste it here.
Event 32 player color.
And then I go back to game.cvp.
And in the definition, I'm going to do that in...
Well, I could do it right after setting up the window surface.
Let's take this out of here.
Let's see if we can work this out.
Where is the window surface made?
Set in create window right here.
Right after that, maybe from made,
instead of after creating the window,
we can set the player color.
We can say set player color here.
And I'm going to make this function.
Go to game.h, white set player color.
And then go to game.cvp and define it.
White set player color.
I forgot the game colon colon.
And I just paste that code and remove the type because it's already declared.
And it takes the window surface format,
assuming it's already...
window surface already exists.
And it sets that color.
You know what I'm using?
Like the set, setter name you could mention.
Even though it's not proper,
like usually it would take parameter and that stuff.
So I'm not thinking in terms of setter here, okay?
I'm just making a void function to do something without returning anything.
Okay, so that looks great.
And then we don't have that in the loop anymore.
So it's already done only once.
I don't know if it's going to cause problems.
We'll see later.
So we're done here.
Let's go back to handle player input and take a look.
So we're calling this, that, you know, something,
map coordinate to title ID, that's something we don't have here.
So let's go back to main.cpp.
We have map coordinate, title ID.
We also have is blockable, right?
So maybe we want to take all of these and let's see,
put in a game.cpp, add the prefix game,
colon, colon, game, colon, colon to the function names,
then you just copy the function names to the header file.
But before I do that, let me check if we need these parameters.
Map coordinate style ID, let's see.
It's giving a new position in the game map tiles.
Game map tiles are right accessible.
So I don't need that.
I remove that.
So we'll go back to map coordinate,
remove the second argument from the calls.
And finally, go back to the function and remove the second parent.
Oh, sorry.
Is it second?
Yeah, it's the second.
We already have tiles as a private of game.h.
Game class has a private variable here.
Where is it?
Here, line 12.
Go back to where we were.
Let me remove all these spaces for me.
Go back to game.cpp.
Okay, so we're good with this function.
Now go back to the calls.
We're also referencing is walkable tile.
That's also okay.
Let's reference in this thing called floor.
We don't have that.
Okay, so let's go back to main.cpp.
So we have this style type.
I could take that and put in game.h.
That's totally fine, but I'm actually going to make a new file.
I'm going to say tile type.h.
And I'm going to place it here.
And then I'm going to put a guard.
I'm going to say if and death.
Okay, so we're going to go back to game.
underscore underscore tile underscore type underscore h underscore underscore.
Then define the very same symbol.
So the next time we won't do anything.
We'll include it again.
And that's the enum.
And then we can include this from wherever we're referencing.
I think it was in game.cpp right floor.
So we can go all the way up there and include
the tile type.h.
When we compile game.cpp we already included.
So we don't have to add this to the g++ command statements.
So we got that.
And seems like we are done with everything.
We isolated all the logic outside of main to the game class.
We created a new object called game instance of the game class.
And we run all these commands to initialize the game.
And at the end shut down and in between create the windows set to player color.
Load the game map for debugging purposes, print the game map.
Then we set up the game app surface and then set the player position initially.
And then we run the game loop.
Now it's time for us to try compiling it and see if we have any problems that we have to address.
So I'm going to close this and do it again.
And it's a lot of problems.
So let's go to the very first one.
As I told you before, there are likely to be problems and we just handle one by one.
Let's go to the very first one at the top.
And file included from main to cpp.
Game.h.
So it's saying from main to cpp line 5 include game.h.
Let's go to game.h.
Game.h line 31 column 26 line 31 column 26.
I'm missing a semicolon.
So I add a semicolon here.
And the second problem is the same thing.
We can just rerun if we want.
And then go back and see now game.cpp 150 game.cpp 150 line 150.
It's saying what no matching function to call page entries.
Because of the second argument, we don't need that anymore because it's already a private member of the class.
Right.
We can see here line 13 14 we're ready to have that and we can just remove it and we can check the call the declaration.
The definition here X signature doesn't have it.
So we fix that problem.
Let's compile it again.
Next problem is map coordinate to title ID is not declaring the scope.
Okay.
So did I add that to the we have these two that add that to the header?
Seems like I didn't write to let's copy this.
Let me add it here to the public member function of game plus and do the same for the walkable tile is walkable tile.
Back to game.h on public at this new function remove the prefix game.com.
See that.
And it finally compiled.
Let's see if we're in the right place.
It works.
There's collision go up, go down to the right, go to the left, go down.
Looking good.
Let's go through the bottom here.
It seems like everything's working fine.
And that's our whole refactoring.
And then click exit and it works just fine.
Okay.
So in this lesson we finished the refactoring to move all the logic from the main dot CPP file.
And I forgot to save that.
So let me check again.
Sorry.
Yeah, that's fine.
Yeah, so we moved all the game logic to the game class.
We created this game dot h file.
And we have all these private members that are accessible by every single member function under the public, not necessarily on the public, but could be private too.
The public just because we want to be able to call all these methods from the outside as we create an instance of the game object in class.
And that object we can call these functions because they're public and these functions in turn they themselves can access the private data members.
Because the game class is a local variable to main, its scope will be until main is over.
So for the duration of the game, as long as it's running, there will be no problems with variables going away due to scoping being closed.
So the game will persist.
The object will exist as long as the function main is running.
So until the end, we can do initializing up to the end shut down the game to make sure as the L is closed.
And in between you have all these things setting up of the game until the game look of the run method.
So the run is where the game look is.
We do all this stuff, checking for input first, and then we do the repainting and update the Windows service.
And we created this style type.h2.2 just to make things more organized.
Just one thing I want to do before we move on is check these headers game class game header check for C of the includes here.
So we have all these includes for using SDL.
That's fine.
So none of these use anything unknown here.
So that's fine.
Now, since I have this here, let me make sure it's not there in the game implementation.
It's not here.
That's fine.
As of main.cpp, let's go back here.
All we have to know here is the game.
So it's here.
Do we need to have SDL here?
No.
Do we need to have string here?
No, we're not using.
We need to have IOS stream now.
F string, no.
So remove all those.
Let's recompose, see if nothing messed up.
All right.
So I think we're good here.
Thank you so much for watching and see you in the next lesson.
Goodbye.


fff2-06 Wraping Up The Migration of Logic from Main to the Game Class

Compiling the Game in the Command Line with a Makefile and the make Command

```markdown
# Summary of the Makefile Lesson

In this lesson, we learned how to create a Makefile to streamline the compilation process of a program, specifically using the G++ compiler from the GNU Compiler Collection (GCC). Traditionally, compiling each source file (CPP) and linking libraries through the command line can be tedious, especially for larger projects with many files. Instead of listing all files manually, a Makefile automates this process.

### Key Concepts

- **Makefile**: A file containing rules and instructions to automate the build process. It defines targets, prerequisites (dependencies), and commands needed to build the program.
  
- **Targets and Prerequisites**: 
  - The target is the name of the file to be generated (e.g., the final executable).
  - Prerequisites are the files that must exist before the target can be built (e.g., object files).

### Steps to Create a Makefile

1. **Define the Target**: 
   - For the game executable, the example target is `labyrinth` which depends on the object files `main.o` and `game.o`.

2. **Compile Object Files**:
   - Each object file is generated from its corresponding CPP file using G++ with the `-c` option to prevent linking.
   - Commands are added under the target line, and it's important to use tabs (not spaces) for indentation.

3. **Create Build Directory**:
   - To keep the source directory clean, a separate `build` directory is created for object files and the executable.

4. **Automation with Make**:
   - After setting up the Makefile, simply running `make` in the command line will handle the building process.
   - Make detects changes in source files and only recompiles what has changed, rather than recompiling everything, which saves time.

### Example Makefile Structure

```makefile
labyrinth: build/main.o build/game.o
    g++ -o build/labyrinth build/main.o build/game.o -lSDL2

build/main.o: main.cpp
    g++ -c main.cpp -o build/main.o

build/game.o: game.cpp
    g++ -c game.cpp -o build/game.o

build:
    mkdir -p build
```

### Conclusion

By creating a Makefile, you improve the build process, avoid cluttering your development directory, and allow for easier recompilation of files. This lesson emphasizes the importance of automation in software development and how tools like Make can enhance productivity. 

Thank you for watching, and see you in the next lesson!
```

Welcome back to another lesson. We are going to learn how to make a make file to improve
the compilation workflow or build process. As we have right now, if I want to compile
my program, my game, for my case, I'm using the compiler G++ from the GNU compiler collection
GCC. And every time I want to do it via the command line, I have to specify every CPP file
that I have. And I have also to link to the SDL2 library with the dash L option. And that process
will generate a file called a.out that I can execute via the command line so I can power up the
game here. Now imagine in a production scenario, right where you have an actual real world game
that's pretty big, there's there, there are going to be lots of files. And it's going to be, it's
going to be really painful to type all the list of files every time you want to compile it. Of course,
today, many, much of this process is already automated via GUI IDs and the such. But since we
are keeping it simple, and I'm building everything from the command line, I'm going to stick to a
command line tool called make. And we're going to have a file called make file. So the make file will
contain a set of instructions to tell. So it instructs, you give it a set of rules that will be used
to build the program. And pretty much is like this. So if you want to generate the executable for
your program, you need this object file, and you need that other object file, so on. In our case, we
can see here, if I go to the right hand, the left hand sidebar here, of my text editor, I have these
files of the extension dot o dot o, these are object files that are generated, right? When I compile
each of these individual CPP files. And for example, we have the game object game dot o, and we have the
main object, my main dot o. So in order for us to build the game, we are going to need game dot o. And
we're going to need main dot o. Now, each of those files, they need instructors, instructions as to how
to build them, right? And for example, for game dot, all, we need to compile it with g plus plus. So we
are going to give a command in order to generate the file game dot o. And the same goes for main dot o. And
these two files are requirement or prerequisite to the main, the overall target here, that is the game
program itself, the program executable. And that program executable requires the building of game dot
o and the main auto, the prerequisites. Okay. So keep that in mind, those words that I said, they were
intentional, all these keywords, targets, they have prerequisites or dependencies. And we have the commands in
order to build those files. Okay, with that, let's create a file. I'm going to call it the make file. Okay, I put the
first letter capitalized. So the make file. So what I want to do is improve my compilation and make this kind of
automatic. So whenever I want to compile, all I have to say is instead of typing g plus plus main dot cpp game dot
cpp dash lsdl two and so on, I just need to type make in it automatically look, look at the make file and build the
program for us. It also helps when you change a specific file. And it will detect that you only change that
specific file, therefore, you only need to rebuild that one specific file instead of rebuilding the whole thing over
again from scratch. So that saves a lot of time. So so the executable name is a dot out, this is just generic,
because I did not specify. So we want to give it we want to give our game a name. Maybe I want to call a lab ring. So
let's call lab.
Labyrinth, did I did I spell that right? Okay, so this is the target. So the target is the whole game itself. And this
target, I'm going to put a colon here, and I'm going to put a space. And this requires what main dot cpp game dot
cpp and a linking to SDL to well, to make the labyrinth, we need the compiled object files. And these will be the main
auto and game auto. Okay, these are the requirements to build a labyrinth. Now, if we already have those requirements,
which we will define how to make them later, we can go ahead and compile everything. Okay. So we are going to say g plus
plus now I have to give the object files. The way I did it before let me kill this was by just passing cpp. But now I just
want to pass the object files. So I'm going to look at the manual page for the g plus plus command, I'm going to say man
space g plus plus there's an option that we can use. So it takes the it will take the object file. Okay, so let me see
dash c option says not to run the linker. We're going to need this for when we're going to create the object files. That's one
thing. Let's see. Okay, so we don't need an option. I don't think we need an option for that. Just the C is going to be used
later. But we did see the dash all for how to make that specific file. So dash all is the output. Go back to the beginning. You have
the option dash all for output. That's what we want to rename a dot out to actually lever it. So I'm going to say dash all lab
labyrinth. And I'm going to put main dot oh, the end auto like that. Okay, so this is going to generate the executable called
labyrinth because of dash option output. And then it's going to take in order to generate the executable you need the main dot
oh and game dot oh, now we also need the linker. So don't forget at the end dash LSTL to
now in order for us to get generate main dot on game dot oh, we need to define a new target here like a dependent target. I'm going to
call it main dot oh colon. And we are going to specify whether it needs anything. What's the requirement for us to have main dot
oh, well, we need some file to exist. And this file is the main dot CPP file. So the requirement here is the prerequisite that the file
main dot CPP exists. Now the command to generate main dot oh will be g plus plus. Now we're going to use the dash C. So we do not link
anything we just generate the main auto file. And that will be main dot CPP like that. Now just do the same thing for game game
dot oh in order to generate this target, you need to have the file game dot CPP. It needs to exist. And to be to build game dot
oh, the command is g plus plus dash C. So you don't link you just generate the object file. And it's going to be sorry game dot CPP. Now, now
that we have this big file, let's try it out. I'm going to quit with Q from the man page. And I'm going to say make. And you can see it
executed first g plus plus main CPP, g plus plus dash oh, and so on. And notice I didn't I didn't show this one. And I think it's
because it's already generated. And it detected that it was already there. But you can see there's a lab reading factor to execute
will hear that I can see it executes the program. Okay, so you can see the compilation process leave these residual files
right the game dot oh, main dot oh, and so on. So it's kind of a mess here, having these files together with the actual source code. So
that's not a good thing. So we have to clean that up. And a good way to approach this is to create a new directory just for those built
files, you can call it build directory or the distribution directory dist, whatever you want. Okay, so I'm going to create this directory
called build. So I'm going to place all the dot oh files there. And maybe I also want to generate lab reading there so it doesn't mix with
the source code. Another common practice is to create a dedicated directory for the source code called SRC. You can also do that. But I'll leave
that to you to do on your own. Okay, now to be able to make the build I obviously could just create the directory and move the files manually
myself. But every time I run make it's gonna do the same thing again, and I have to manually move them. So what I'm going to do is I am going to go here in the
make file and change it. So it generates the targets in the build directory. Okay, so let's think about that. First thing North generate this thing
called labyrinth. This target needs I'm going to say at please generate it at build slash a reverend. And also, you want to take the main
auto from build slash main auto and build slash game dot oh
and that's one way but then it's going to go to the requirement here and the requirement it's going to create in the same directory maybe I can use
let me think about this. Maybe you can use a dash a little option here. And say build slash
main dot oh, it's kind of redundant. No, maybe there's a battery. And I think there is. And this ought to want to be big. Game dot oh, let me remove these object files
here that I have I'm going to say our star dot oh
and they're gone now from my current directory I must remove a dot out our M a dot out. Also going to remove library
and let's see what happens I think there's we also need to build stuff to create directory so it's not gonna be okay you can see there's an error
assembler messages build slash main dot oh, no search file or directory. So we tried to build
that. Okay, so we also need to create the build directory here. Let me think about this depends on main depends on game depends on so let's make it depend on
the build. And I'm going to define the build target to be no prerequisites for build but we have to make a directory I'm going to use mkdir build
like that. And I'm going to say make again. Let's see what we have now a brand g++ dash c main dot CPP dash build slash main dot oh, and the other ones. Let's see what's in the build directory
how game dot oh main dot oh and labyrinth let's say dot build slash labyrinth. And we see the game actually executes. So that worked.
Okay. I am just curious I think if we put the target. What happens if we do build slash main dot oh, and here I remove.
Never mind, you can try it on your own if you want to do it another way maybe there are all these optimizations we can make to the make file, make variables and so on.
Because as the project bill as the project scales, you're going to have more and more files, so you don't want to repeat yourself every single time so you have to make targets and it's pretty much the same kind of pattern.
So there are ways you can optimize the make file with us. So you don't repeat yourself as much but I'll leave that to you if you want to do your own own research and learn more about that.
Okay, so this is looking good. Let's see something is not right here. I see what's going on. You see, every time a run make it's rebuilding everything but that should not be the case why because I already built everything.
So it's not detecting that I rebuilt everything and actually we are going to have to refactor this never mind what some of those stuff has done before.
And the reason it's not detecting that I already built it's probably because my target is specifying like that instead of having the build slash.
So if I put build slash here main dot oh and I put build slash game dot oh and here labran build slash game dot oh what would happen.
So it didn't execute the other ones I want to remove the directory build. Let me see our M dash R. I removed the directory build.
And I want to see when I run make again. It made the build directory salon. And if I run make again now it detected that I already built main dot oh game dot oh but it did not detect labran.
And it's probably because I need to build slash labran here.
There you go. So now it detected that already had built labran the executable itself it says make build slash labran is up to date.
So that that that fixed that problem of detecting whether you had already compiled everything. So it will save you a lot of time.
Not having to redo the thing that's already built.
So say I changed game dot CPP for example I add some comment here and I save and I do make it detected that game was changed and it rebuilt game dot oh and then rebuild the labran note it did not have to.
Rebuild main dot oh because it didn't change game dot CPP was the file that changed.
So that's nice.
Let me revert this.
Let's have an overview what we did in this lesson. We learned to make a make file so that we can use the make command to conveniently compile the project and recompile it.
Whenever there are changes in the source code it will automatically detect changes and recompile the specific files accordingly.
That helps you save time instead of recompiling everything over again from scratch.
It just takes the files that changed and compiles those.
And then compiles the executable again.
To make to use a make file have to define targets that require dependencies or prerequisites.
The target is at the left hand side of the colon.
The prerequisites are at the right hand side of the colon.
Now under that entry you have to specify a command or a set of commands that will generate that target.
You have to press tab and then type the command under the entry with the colon.
Okay like we did here.
Make sure use like that.
This thing should be a tab not a space.
I don't think the space will work.
So make sure to use a tab.
And here we define build slash library if this target because we want to separate the object files and executable into its own build directory to not clutter the source code directory.
So we have the target on the left hand side.
This is the main one that will generate the executable for the game.
And we have the prerequisites.
The executable depends on the build directory existing.
And in order to have the build directory you have to make MKDR build here.
It will automatically detect whether it already exists or not.
Then we have the main.o file.
And in order to generate the file you have to look at the entry for main.o here.
This target build slash main.o depends on the file main.cpp existing.
And in order to generate build slash main.o we use g++ dash c so we don't link we just generate the object file main.cpp and I put a dash o so it can generate under the build directory build slash main.o.
Same thing for game.o.
Build slash game.o depends on the game.cpp file existing.
And the command to build to create the file build slash game.o is g++ dash c game.cpp dash o build slash game.o.
And with those prerequisites met and their generation already complete it will go ahead and finally execute the command in line two.
That will generate the executable build slash labyrinth g++ dash o build slash labyrinth.
It depends we need build slash main.o and build slash game.o those object files and then no forget to link with the dash l sdl two and that would generate build slash labyrinth that we can execute in a command line with dot slash build slash labyrinth.
With that we reach the end of this lesson. Thank you very much for watching and see you in the next one.
