Chapter 22: Using Game Objects and Building a Game

This chapter is the final stage of the Space Invaders ++ project. We will learn how to receive input from a gamepad using SFML to do all the hard work and we will also code a class that will handle communication between the invaders and the GameScreen class, as well as the player and the GameScreen class. The class will allow the player and the invaders to spawn bullets, but the exact same technique could be used for any kind of communication that you need between different parts of your own game, so it is useful to know. The final part of the game (as usual) will be the collision detection and the logic of the game itself. Once Space Invaders ++ is up and running, we will learn how to use the Visual Studio debugger, which will be invaluable when you are designing your own logic because it allows you to step through your code a line at a time and see the value of variables. It is also a useful tool for studying the execution flow of...

Spawning bullets

We need a way to spawn bullets from both the player and each of the invaders. The solutions to both are very similar but not identical. We need a way to allow GameInputHandler to spawn bullets when a keyboard key or gamepad button is pressed, and we need InvaderUpdateComponent to use its already existing logic to spawn bullets.

The GameScreen class has a vector holding all the GameObject instances, so GameScreen is the ideal candidate to move a bullet into position and set it moving up or down the screen, depending on who or what triggered the shot. We need a way for the GameInputHandler class and InvaderUpdateComponenet to communicate with the GameScreen class, but we also need to restrict the communication to just spawning bullets; we don't want them to be able to take control of any other part of the GameScreen class.

Let's code an abstract class that GameScreen can inherit from.

Coding the BulletSpawner class

Create a new header file in the...

Handling the player's input

Add some more declarations to the GameInputHandler.h file so that your code matches what follows. I have highlighted the new code to add:

#pragma once
#include "InputHandler.h"
#include "PlayerUpdateComponent.h"
#include "TransformComponent.h"
class GameScreen;
class GameInputHandler : public InputHandler
{
private:
    shared_ptr<PlayerUpdateComponent> m_PUC;
    shared_ptr<TransformComponent> m_PTC;
    bool mBButtonPressed = false;
public:
    void initialize();
    void handleGamepad() override;
    void handleKeyPressed(Event& event, 
        RenderWindow& window) override;
    void handleKeyReleased(Event& event, 
        RenderWindow& window) override;   &...

Coding the PhysicsEnginePlayMode class

This is the class that will do all the collision detection. In this game, there are several collision events we want to watch out for:

• Has an invader reached the left- or right-hand side of the screen? If so, all the invaders need to drop down one row and head back in the other direction.
• Has an invader collided with the player? As the invaders get lower, we want them to be able to bump into the player and cause a life to be lost.
• Has an invader bullet hit the player? Each time an invader bullet hits the player, we need to hide the bullet, ready for reuse, and deduct a life from the player.
• Has a player bullet hit an invader? Each time the player hits an invader, the invader should be destroyed, the bullet hidden (ready for reuse), and the player's score increased.

This class will have an initialize function that the GameScreen class will call to prepare for detecting collisions, a detectCollisions function that...

Making the game

By the end of this section, we will have a playable game. In this section, we will add code to the GameScreen class to bring together everything we have been coding over the last three chapters. To get started, add an instance of PhysicsEngineGameMode to GameScreen.h by adding an extra include directive, as follows:

#include "PhysicsEnginePlayMode.h"

Then, declare an instance, as highlighted in the following code:

private:
    ScreenManagerRemoteControl* m_ScreenManagerRemoteControl;
    shared_ptr<GameInputHandler> m_GIH;
    PhysicsEnginePlayMode m_PhysicsEnginePlayMode;
…
…

Now, open the GameScreen.cpp file, add some extra include directives, and forward-declare the BulletSpawner class, as highlighted in the following code:

#include "GameScreen.h"
#include "GameUIPanel.h"
#include "GameInputHandler.h"
#include "GameOverUIPanel...

Understanding the flow of execution and debugging

Much of the last four chapters has been about the code structure. It is very possible that you still have doubts and uncertainties about which class instantiates which instance or in what order the various functions are called. Wouldn't it be useful if there was a way to execute the project and follow the path of execution from int main() right through to return 0; in the Space Invaders ++.cpp file? It turns out we can, and the following is how to do it.

We will now explore the debugging facilities in Visual Studio while simultaneously trying to understand the structure of the project.

Open the Space Invaders ++.cpp file and find the first line of code, as follows:

GameEngine m_GameEngine;

The preceding code is the first line of code that gets executed. It declares an instance of the GameEngine class and sets all our hard work in motion.

Right-click the preceding line of code and select Breakpoint | Insert Breakpoint...

Reusing the code to make a different game and building a design mode

On a few occasions, we have already discussed  the possibility that this system we have coded can be reused to make a totally different game. I just thought it was worth giving this fact a full hearing.

The way that you would make a different game is as follows. I have already mentioned that you could code the appearance of game objects into new components that derive from the GraphicsComponent class and that you could code new behaviors into classes that derive from the UpdateComponent class.

Suppose you wanted a set of game objects that had overlapping behaviors; consider perhaps a 2D game where the enemy hunted the player and then shot at the player at a certain distance.

Maybe you could have an enemy type that got close to the player and fired a pistol at the player and an enemy type that took long distance shots at the player, like a sniper might.

You could code an EnemyShooterUpdateComponent...

Summary

In this chapter, we finally completed the Space Invaders ++ game. We coded a way for game objects to request bullets to be spawned, learned how to receive input from a gamepad, and we put in the final logic of the game to bring it to life.

Perhaps the most important thing to take from this chapter, however, is how the toil of the last four chapters will help you get started on your next project.

There is one final chapter in this slightly chunky book, and it is a short and simple one, I promise.