Chapter 8: SFML Views – Starting the Zombie Shooter Game

In this project, we will be making even more use of OOP and to a powerful effect. We will also be exploring the SFML View class. This versatile class will allow us to easily divide our game up into layers for different aspects of the game. In the Zombie Shooter project, we will have a layer for the HUD and a layer for the main game. This is necessary because as the game world expands each time the player clears a wave of zombies and, eventually, the game world will be bigger than the screen and will need to scroll. The use of the View class will prevent the text of the HUD from scrolling with the background. In the next project, we will take things even further and create a co-op split screen game with the SFML View class doing most of the hard work.

This is what we will do in this chapter:

• Planning and starting the Zombie Arena game
• Coding the Player class
• Learning about the SFML View class
• Building...

Planning and starting the Zombie Arena game

At this point, if you haven't already, I suggest you go and watch a video of Over 9000 Zombies (http://store.steampowered.com/app/273500/) and Crimson Land (http://store.steampowered.com/app/262830/). Our game will obviously not be as in-depth or advanced as either of these examples, but we will also have the same basic set of features and game mechanics, such as the following:

• A Heads Up Display (HUD) that shows details such as the score, high score, and bullets in clip, the number of bullets left, player health, and the number of zombies left to kill.
• The player will shoot zombies while frantically running away from them.
• Move around a scrolling world using the WASD keyboard keys while aiming the gun using the mouse.
• In-between each level, the player will choose a "level-up" that will affect the way the game needs to be played for the player to win.
• The player will need to collect "pick-ups"...

OOP and the Zombie Arena project

The initial problem we are faced with is the complexity of the current project. Let's consider that there is just a single zombie; here is what we need to make it function in the game:

• Its horizontal and vertical position
• Its size
• The direction it is facing
• A different texture for each zombie type
• A Sprite
• A different speed for each zombie type
• A different health for each zombie type
• Keeping track of the type of each zombie
• Collision detection data
• Its intelligence (to chase the player), which is slightly different for each type of zombie
• An indication of whether the zombie is alive or dead

This suggests perhaps a dozen variables for just one zombie, and entire arrays of each of these variables will be required for managing a zombie horde. But what about all the bullets from the machine gun, the pick-ups, and the different level-ups? The simple Timber!!! and Pong games also started to get...

Building the player – the first class

Let's think about what our Player class will need to do and what we require for it. The class will need to know how fast it can move, where in the game world it currently is, and how much health it has. As the Player class, in the player's eyes, is represented as a 2D graphical character, the class will need both a Sprite object and a Texture object.

Furthermore, although the reasons might not be obvious at this point, our Player class will also benefit from knowing a few details about the overall environment the game is running in. These details are screen resolution, the size of the tiles that make up an arena, and the overall size of the current arena.

As the Player class will be taking full responsibility for updating itself in each frame (like the bat and ball did), it will need to know the player's intentions at any given moment. For example, is the player currently holding down a keyboard direction key? Or is...

Controlling the game camera with SFML View

In my opinion, the SFML View class is one of the neatest classes. After finishing this book, when we make games without using a media/gaming library, we will really notice the absence of View.

The View class allows us to consider our game as taking place in its own world, with its own properties. What do I mean? Well, when we create a game, we are usually trying to create a virtual world. That virtual world rarely, if ever, is measured in pixels, and rarely, if ever, will that world be the same number of pixels as the player's monitor. We need a way to abstract the virtual world we are building so that it can be of whatever size or shape we like.

Another way to think of SFML View is as a camera through which the player views a part of our virtual world. Most games will have more than one camera/view of the world.

For example, consider a split screen game where two players can be in different parts of the world at the same time...

Starting the Zombie Arena game engine

In this game, we will need a slightly upgraded game engine in main. We will have an enumeration called state, which will track what the current state of the game is. Then, throughout main, we can wrap parts of our code so that different things happen in different states.

When we created the project, Visual Studio created a file for us called ZombieArena.cpp. This will be the file that contains our main function and the code that instantiates and controls all our classes.

We begin with the now-familiar main function and some include directives. Note the addition of an include directive for the Player class.

Add the following code to the ZombieArena.cpp file:

#include <SFML/Graphics.hpp>
#include "Player.h"
using namespace sf;
int main()
{
    return 0;
}

The previous code has nothing new in it except that the #include "Player.h" line means we can now use the Player class within our code...

Managing the code files

One of the advantages of abstraction using classes and functions is that the length (number of lines) of our code files can be reduced. Even though we will be using more than a dozen code files for this project, the length of the code in ZombieArena.cpp will still get a little unwieldy toward the end. In the final project, Space Invaders++, we will look at even more ways to abstract and manage our code.

For now, use this tip to keep things manageable. Notice that on the left-hand side of the code editor in Visual Studio, there are several + and - signs, one of which is shown in this diagram:

There will be one sign for each block (if, while, for, and so on) of the code. You can expand and collapse these blocks by clicking on the + and - signs. I recommend keeping all the code not currently under discussion collapsed. This will make things much clearer.

Furthermore, we can create our own collapsible blocks. I suggest making a...

Starting to code the main game loop

As you can see, the last part of the preceding code is the game loop (while (window.isOpen()){}). We will turn our attention to this now. Specifically, we will be coding the input handling section of the game loop.

The code that we will be adding is quite long. There is nothing complicated about it, though, and we will examine it all in a moment.

Add the following highlighted code to the game loop:

// The main game loop
while (window.isOpen())
{
    /*
    ************
    Handle input
    ************
    */
    // Handle events by polling
    Event event;
    while (window.pollEvent(event))
    {
        if (event.type == Event::KeyPressed)
        {      ...

Summary

Phew! That was a long one. We have done a lot in this chapter: we built our first class for the Zombie Arena project, Player, and put it to use in the game loop. We also learned about and used an instance of the View class, although we haven't explored the benefits this gives us just yet.

In the next chapter, we will build our arena background by exploring what sprite sheets are. We will also learn about C++ references, which allow us to manipulate variables, even when they are out of scope (that is, in another function).

FAQ

Q) I noticed we have coded quite a few functions of the Player class that we don't use. Why is this?

A) Rather than keep coming back to the Player class, we have added all the code that we will need throughout the project. By the end of Chapter 13, Sound Effects, File I/O, and Finishing the Game, we will have made full use of all of these functions.