Our entities can now detect collisions thanks to the CollisionComponent, but they still pass through each other like ghosts. This lesson bridges the gap from detection to reaction. We'll implement two fundamental collision responses:

1. Stopping, such as a character landing on a floor.
2. Bouncing, such as a ball reflecting off surfaces.

We'll approach this by adding a virtual HandleCollision() function to our Entity() base class, allowing different entity types to define their unique reactions.

Building on our basic SDL window setup, this lesson introduces interactivity by focusing on mouse input.

We'll explore how SDL represents mouse actions through its event system. You'll learn to detect when the user moves the mouse, clicks buttons, or even moves the cursor into or out of the application window.

Key topics include:

• Processing SDL_MOUSEMOTION events to get cursor coordinates.
• Understanding SDL's coordinate system.
• Detecting mouse button presses and releases (SDL_MOUSEBUTTONDOWN, SDL_MOUSEBUTTONUP).
• Identifying which mouse button was clicked.
• Handling double clicks.
• Responding to the cursor entering or leaving the window (SDL_WINDOWEVENT_ENTER, SDL_WINDOWEVENT_LEAVE).

So far, we've learned how to create a window and fill it with a solid color. While useful, most applications need to draw more specific shapes and images.

One of the most fundamental shapes in 2D graphics is the rectangle. Rectangles are essential for user interfaces (buttons, text boxes), game elements (sprites, collision boxes), and defining areas on the screen (viewports, selection boxes).

SDL provides tools specifically for working with rectangles. We'll learn about the SDL_Rect type for defining position and size, and the SDL_Color type for managing colors independently of screen formats. We'll then combine these to draw rectangles and make them respond to basic mouse interaction.

In earlier lessons, we saw how to draw shapes and handle mouse events for individual elements in SDL. While this works for simple examples, managing dozens or hundreds of UI elements directly in our main function quickly becomes unmanageable.

This lesson introduces techniques for structuring larger SDL applications. We'll learn how to create "manager" classes that take responsibility for specific parts of the UI, keeping our main code clean and organized.

We will cover:

• Creating a UI manager class.
• Using std::vector to manage multiple components dynamically.
• Applying inheritance to create specialized components.
• Leveraging polymorphism to handle different component types uniformly.
• Building hierarchies of managers for complex UIs.

Our applications can draw shapes, but how do we let users interact with them meaningfully? This lesson focuses on creating clickable buttons, and having those clicks cause some meaningful effect in our program.

We'll start by designing a Button class, reusing some logic from our existing Rectangle class. We'll discuss the concepts of inheritance and composition as ways to structure our code.

Key topics include:

• Handling mouse events like clicks and hovers for buttons.
• Designing class APIs for extensibility using virtual functions.
• Implementing different communication patterns between UI components (parent-child, child-parent, arbitrary, global).
• Using forward declarations and separate source files to manage dependencies.

Previously, we’ve seen how SDL implements an event queue, which we can interact with using functions like SDL_PollEvent(). As standard, SDL will push events onto this queue to report actions like the user moving their mouse (SDL_MOUSEMOTION) or requesting the application close (SDL_QUIT).

However, we can also use SDL’s event system to manage custom events, that are specific to the game we’re making. For example, if we were making a first-person shooter, we could use this system to report when player fires their weapon or reloads.

In this lesson, we'll learn how to register and use custom events to create these game-specific behaviors.

We'll also look at how to organise our code around a custom event system, and see practical examples of how custom events can be used to manage game state and handle complex user interactions.

Our entities can now move realistically thanks to the PhysicsComponent, but they pass right through each other! This lesson introduces the CollisionComponent, responsible for defining an entity's physical shape for interaction. You'll learn how to:

• Create a CollisionComponent with offset, width, and height.
• Calculate the component's world-space bounding box each frame.
• Implement basic collision detection between entities.
• Integrate the CollisionComponent with the Entity and TransformComponent.
• Visualize collision bounds for debugging.

By the end, your entities will be able to detect when they overlap, setting the stage for collision response in the next lesson.

In this lesson, we'll enhance our entity-component system by adding basic physics simulation. We'll create a dedicated PhysicsComponent responsible for managing an entity's physical properties and behavior. You'll learn how to:

• Store and manage physical state like Velocity, Acceleration, and Mass.
• Implement core physics updates within the component's Tick() method, including gravity.
• Provide methods - ApplyForce() and ApplyImpulse() - for external factors to influence the entity's motion.
• Integrate the PhysicsComponent with the EntityComponent and TransformComponent.
• Connect player input to the physics system using commands.

By the end, you'll have a reusable component that allows entities to move realistically under the influence of forces like gravity and player input.

In this lesson, we'll take our first steps into drawing graphics with SDL. We'll learn about SDL Surfaces, the canvases we draw onto, understand how colors and pixel formats work, and use this knowledge to change the background color of our window.

Inheritance is useful, but sometimes we need more flexibility. This lesson introduces composition, a powerful design pattern where we build complex objects by combining smaller, focused "component" objects. We'll explore why inheritance isn't always the best fit and see how composition allows us to mix and match capabilities like animation, audio, and physics for different game entities.

As we build more complex projects, the objects we need to build become more and more powerful. Objects in a game, for example, might need capabilities including:

• The ability to be animated
• The ability to emit audio
• The ability to simulate physics and collide with other objects

A class that includes all of these capabilities would already be quite complex, and these represent only a tiny subset of the capabilities that objects need in more complex games.