The games that we make can be built to run on Windows, Mac and Linux! The code we use will be identical for each. However, each version does need to be compiled and linked on the platform for which it is intended and Visual Studio will not be able to help us with Mac and Linux.

It would be unfair to say that this book is entirely suited for Mac and Linux users, especially complete beginners. Although, I guess, if you are an enthusiastic Mac or Linux user, and you are comfortable with your operating system, the vast majority of the extra challenges you will encounter will be in the initial setup of the development environment, SFML, and the first project.

To this end, I can highly recommend the following tutorials which will hopefully replace the next 10 pages (approximately), up to the section Planning Timber!!!, when this book should again become relevant to all operating systems.

For Linux, read this for an overview: http://www.sfml-dev.org/tutorials/2.0/start-linux.php .

For Linux, read this for step-by-step guidance: http://en.sfml-dev.org/forums/index.php?topic=9808.0 .

On Mac, read this tutorial as well as the linked out articles: http://www.edparrish.net/common/sfml-.osx.html .

Installing Visual Studio can be almost as simple as downloading a file and clicking a few buttons. It will help us, however, if we carefully run through exactly how we do this. For this reason, I will walk through the installation process a step at a time.

The Microsoft Visual Studio site says that you need 5 GB of hard disk space. From experience, however, I would suggest you need at least 10 GB of free space. In addition, these figures are slightly ambiguous. If you are planning to install it on a secondary hard drive, you will still need at least 5 GB on the primary hard drive because no matter where you choose to install Visual Studio, it will need this space too.

Now we can turn to SFML.

This short tutorial will take you through downloading the SFML files that allow us to include the functionality contained in the library. In addition, we will see how to use the SFML DLL files that will enable our compiled object code to run alongside SFML:

Now we are ready to start using C++ and SFML in Visual Studio.

As setting up a project is a fairly fiddly process, we will create a project and then save it as a Visual Studio template. This will save us quite a significant amount of work each time we start a new game. So, if you find the next tutorial a little tedious, rest assured that you will never need to do this again:

Phew, that's it! Next time we create a project, I'll show you how to do it from this template. Now let's build Timber!!!

There are a number of websites that allow you to contract artists, sound engineers, and even programmers. One of the biggest is the www.upwork.com. You can join this site for free and post your jobs. You need to write a clear explanation of your requirements as well as state how much you are prepared to pay. Then you will probably get a good selection of contractors bidding to do the work. Be aware, there is a lot of unqualified contractors whose work might be disappointing, but if you choose carefully you will likely find a competent, enthusiastic, and great value person or company to do the job.

Sound effects can be downloaded for free from sites like www.freesound.org but often the license won't allow you to use them if you are selling your game. Another option is to use an open source software called BFXR from www.bfxr.net, which can help you generate lots of different sound effects that are yours to keep and do as you like with.

Once you have decided which assets you will use, it is time to add them to the project. These next instructions will assume you are using all the assets supplied in the book's download bundle. Where you are using your own, simply replace the appropriate sound or graphic file with your own, using exactly the same file name.

Let's take a look at these assets, especially the graphics, so we can better visualize what is happening when we use them in our C++ code.

Graphical assets form the individual parts of the screen in our Timber!!! game. Take a look at the graphical assets and it should be clear where, in our game, they will be used.

The sound files are all .wav format. These are files containing the sound effects that we will play at certain events throughout the game. They were all generated using BFXR. They are:

As you can see, the only code that needed to change was a little bit at the very top. The first line of code is this:

// Include important C++ libraries here 
 

Any line of code that starts with // is a comment and is ignored by the compiler. As such, this line of code does nothing. It is used to leave any information that we might find useful when we come back to the code at a later date. The comment ends at the end of the line, so anything on the next line is not part of the comment. There is another type of comment called a multi-line or c-style comment, which can be used to leave comments that take up more than a single line. We will see some of them later in this chapter. Throughout this book I will leave hundreds of comments to help add context and further explain the code.

Now that you know what comments are for, you can probably take a decent guess at what the next line of code does. Here it is again:

#include "stdafx.h" 

The #include  directive tells Visual Studio to include, or add the contents of another file before compiling. The effect of this is that some other code, that we have not written ourselves, will be a part of our program when we run it. The process of adding code from other files into our code is called pre-processing and, perhaps unsurprisingly, is performed by something called a pre-processor. The file extension .h stands for header file.

You might be wondering what this code will do? The stdafx.h file actually contains more #include directives itself. It adds into our program, all the necessary code that is required to run our program on Windows. We will never need to see this file and definitely don't need to concern ourselves with what is in it. We just need to add the line of code at the top of every game that we make.

What is more significant and relevant to us, and the reason it is worth discussing the #include directive, is that we will add many more #include directives at the top of our code files. This is to include code that we will use and take the trouble to understand.

The main files that we will be including are the SFML header files, which give us access to all the cool game coding features. We will also use #include to access the C++ Standard Library header files. These header files give us access to core features of the C++ language itself.

That's two lines squared away, so let's move on.

The next line we see in our code is this:

int main() 

The code int is what is known as a type. C++ has many types and they represent different types of data. An int is an integer or whole number. Hold that thought and we will come back to it in a minute.

The main() code part is the name of the section of code that follows. This section of code is marked out between the opening curly brace { and the next closing curly brace }.

So, everything in between these curly braces {...} is a part of main. We call a section of code like this, a function.

Every C++ program has a main function and it is the place where the execution (running) of the entire program will start. As we progress through the book, eventually our games will have many code files. However, there will only ever be one main function, and no matter what code we write, our game will always begin execution from the first line of code inside the opening curly brace of the main function.

For now, don't worry about the strange brackets that follow the function name (). We will discuss them further in Chapter 4: Loops, Arrays, Switch, Enumerations, and Functions-Implementing Game Mechanics, where we will get to see functions in a whole new and more interesting light.

Let's look closely at the one single line of code within our Main function.

Take a look at the entirety of our Main function again:

int main() 
{ 
   return 0; 
} 

We can see that inside Main there is just one single line of code, return 0;. Before we move on to find out what this line of code does, let's look at how it is presented. This is useful because it can help us prepare to write code that is easy to read, and distinguish, from other parts of our code.

First notice that return 0; is indented to the right by one tab. This clearly marks it out as being internal to the main function. As our code grows in length we will see that indenting our code and leaving white space will be essential to maintaining readability.

Next, notice the punctuation on the end of the line. A semicolon ; tells the compiler that it is the end of the instruction and whatever follows it is a new instruction. We call an instruction terminated by a semicolon, a statement.

Note that the compiler doesn't care whether you leave a new line or even a space between the semicolon and the next statement. However, not starting a new line for each statement will lead to desperately hard-to-read code, and missing the semicolon altogether will result in a syntax error so that the game will not compile or run.

A section of code together, often denoted by its indentation with the rest of the section, is called a block.

Now that you are comfortable with the idea of the main function, indenting your code to keep it tidy and putting a semicolon on the end of each statement, we can move on to find out exactly what the return 0; statement actually does.

Actually, return 0; does almost nothing in the context of our game. The concept, however, is an important one. When we use the return keyword, either on its own or followed by a value, it is an instruction for the program execution to jump/move back to the code that got the function started in the first place.

Often this code that got the function started will be yet another function somewhere else in our code. In this case, however, it is the operating system that started the main function. So, when the line return 0; is executed, the main function exits and the entire program ends.

As we have a 0 after the return keyword, that value is also sent to the operating system. We could change the value of zero to something else and that value would be sent back instead.

We say that the code that starts a function, calls the function, and that the function returns the value.

You don't need to fully grasp all this function information just yet. It is just useful to introduce it here. There's one last thing on functions before we move on. Remember the int from int Main()? That tells the compiler that the type of value returned from Main must be an int (integer/whole number). We can return any value that qualifies as an int. Perhaps 0, 1, 999, 6358, and so on. If we try and return something that isn't an int, perhaps 12.76, then the code won't compile and the game won't run.

Functions can return a big selection of different types, including types that we invent for ourselves! That kind of type, however, must be made known to the compiler in the way we have just seen.

This little bit of background information on functions will make things smoother as we progress.

You can actually run the game at this point. Do so by clicking the Local Windows Debugger button in the quick-launch bar of Visual Studio, or you can use the F5 shortcut key.

You will just get a flash of a black screen. This flash is the C++ console, which we can use for debugging our game. We don't need to do this for now. What is happening is that our program is starting, executing from the first line of Main, which of course is return 0; and then immediately exiting back to the operating system.

The first thing we notice in our new code is another, albeit slightly different, #include directive. #include <SFML/Graphics.hpp> tells the pre-processor to include the contents of the file Graphics.hpp contained within the folder named SFML which we created while setting up the project.

So what this line achieves is that it adds code from the aforementioned file, which gives us access to some of the features of SFML. Exactly how it achieves this will become clearer when we start writing our own separate code files and using #include to use them.

What matters, for now, is that we have a whole bunch of new functionality provided by SFML, available for use.The next new line is using namespace sf;. We will come back to what this line does in a few paragraphs-time.

We will more fully discuss OOP, classes, and objects as we proceed through the book. What follows is the briefest introduction, so we can understand what is happening.

We already know that OOP stands for object-oriented programming. OOP is a programming paradigm, a way of coding. OOP is generally accepted throughout the world of programming, in almost every language, as the best, if not the only, professional way to write code.

OOP introduces a lot of coding concepts, but fundamental to them all are classes and objects. When we write code, whenever possible we want to write code that is reusable. The way we do this is to structure our code as a class. We will learn how to do this in Chapter 6: Object-Oriented Programming, Classes and SFML Views.

All we need to know about classes, for now, is that once we have coded our class, we don't just execute that code as part of our game instead we create usable objects from the class.

For example, if we wanted a hundred zombie Non-Player Characters (NPCs) we could carefully design and code a class called Zombie and then, from that single class, create as many zombie objects as we like. Each and every zombie object would have the same functionality and internal data types, but each and every zombie object would be a separate and distinct entity.

To take the hypothetical zombie example further, but without showing any code for the Zombie class, we might create a new object based on the Zombie class like this:

Zombie z1; 

The object, z1, is now a fully coded and functioning Zombie object. We could then do this:

Zombie z2; 
Zombie z3; 
Zombie z4; 
Zombie z5; 

We now have five separate zombies, but they are all based on one carefully coded class. Let's take things one step further before we get back to the code we have just written. Our zombies can contain both behaviors (defined by functions), as well as data that might represent things such as the zombie's health, speed, location, or direction of travel. As an example, we could code our Zombie class to enable us to use our zombie objects, perhaps like this:

z1.attack(player); 
z2.growl(); 
z3.headExplode(); 

We will design our class to enable us to use the data and behaviors in the most appropriate manner to suit our game's objectives. For example, we could design our class so that we can assign values for the data for each zombie object at the time we create it.

Perhaps we need to assign a unique name and speed in meters per second, at the time we create each zombie. Careful coding of the Zombie class could enable us to write code like this:

// Dave was a 100 meter Olympic champion before infection  
// He moves at 10 meters per second 
Zombie z1("Dave", 10); 
 
// Gill had both of her legs eaten before she was infected 
// She drags along at .01 meters per second 
Zombie z2("Gill", .01); 

The point is that classes are almost infinitely flexible, and once we have coded the class, we can go about using them by creating an object from them. It is through classes and the objects that we create from them that we will harness the power of SFML. And yes, we will also write our own classes, including a Zombie class.

Let's get back to the real code we just wrote.

Before we move on to look more closely at VideoMode and RenderWindow, which, as you've probably guessed, are classes provided by SFML, we will learn what the using namespace sf; line of code does.

When we create a class, we do so in a namespace. We do this to distinguish our classes from those that others have written. Consider the VideoMode class. It is entirely possible that, in an environment like Windows, somebody has already written a class called VideoMode. By using a namespace, we, and the SFML programmers, can make sure that the names of classes never clash.

The full way of using the VideoMode class is like this:

sf::VideoMode...

The code using namespace sf; enables us to omit the prefix sf:: from everywhere in our code. Without it, there would be over 100 instances of sf:: in this simple game alone. It also makes our code more readable as well as shorter.

Inside the Main function we now have two new comments and two new lines of actual code. The first line of actual code is this:

VideoMode vm(1920, 1080); 

This code creates an object called vm from the class called VideoMode and sets up two internal values of 1920 and 1080. These values represent the resolution of the player's screen.

The next new line of code is this:

RenderWindow window(vm, "Timber!!!", Style::Fullscreen); 

In the previous line of code, we were creating a new object called window from the SFML provided class called RenderWindow. Furthermore, we were setting up some values inside our window object.

Firstly, the vm object is used in order to initialize part of the window. At first this might seem confusing. Remember, however, that a class can be as varied and flexible as its creator wants to make it. And yes, some classes can contain other classes.

Next we use the value Timber!!! to give the window a name. And we use the predefined value Style::FullScreen to make our window object full screen.

Let's see our window object in action.

You can run the game again at this point. You will see a bigger black screen flash on then disappear. This is the 1920 x 1080 full-screen window that we just coded. Unfortunately, what is still happening is that our program is starting, executing from the first line of Main, creating the cool new game window, then coming to return 0;, and immediately exiting back to the operating system.

The very first thing we see in the new code is this:

while (window.isOpen()) 
{ 

The very last thing we see in the new code is a closing }. We have created a while loop. Everything between the opening { and closing } of the while loop will continue to execute, over and over, potentially forever.

Look closely between the parentheses (...) of the while loop as shown highlighted in the next code:

while (window.isOpen()) 

The full explanation of this code will have to wait until we discuss loops and conditions in Chapter 4: Loops, Arrays, Switch, Enumerations, and Functions-Implementing Game Mechanics. What is important for now is that, when the window object is set to closed, the execution of the code will break out of the while loop and onto the next statement. Exactly how a window is closed will be covered soon.

The next statement is of course return 0;, which ends our game.

We now know that our while loop will whiz round and round, repeatedly executing the code within it, until our window object is set to closed.

Just inside the while loop we see what, at first glance, might look a bit like ASCII art:

      /* 
      **************************************** 
      Handle the player's input 
      **************************************** 
      */ 

This previous code is simply another type of comment. This type of comment is known as a C-style comment. The comment begins with /* and ends with */. Anything in between is just for information and is not compiled. I have used this slightly elaborate text to make it absolutely clear what we will be doing in this part of the code file. And of course you can now work out that any code that follows will be related to handling the player's input.

Skip over a few lines of code and you will see that we have another C-style comment announcing that, in that part of the code, we will be updating the scene.

Jump to the next C-style comment and it is plain where we will be drawing all the graphics.

Although this first project uses the simplest possible version of a game loop, every game will need these phases in the code:

Now let's look at the code that actually does something within the game loop.

Firstly, within the section labeled Handle the player's input we have the following code:

if (Keyboard::isKeyPressed(Keyboard::Escape)) 
{ 
     window.close(); 
} 

This code checks whether the Escape key is currently pressed. If it is, the highlighted code uses the window object to close itself. Now, the next time the while loop begins, it will see that the window object is closed and jump to the code immediately after the closing curly brace } of the while loop and the game will exit. We will discuss if statements more fully in Chapter 2: Variables, Operators, and Decisions-Animating Sprites.

At the moment there is no code in the Update the scene section, so let's move on to the Draw the scene section.

The first thing we do is to rub out the previous frame of animation using the code:

window.clear(); 

What we do now is draw each and every object from the game. At the moment, however, we don't have any game objects.

The next line of code is this:

window.display(); 

When we draw all the game objects, we are drawing them to a hidden surface ready to be displayed. The code window.display() flips from the previously displayed surface to the newly updated (previously hidden) one. This way, the player will never see the drawing process as the surface has all the sprites added to it. It also guarantees that the scene will be complete before it is flipped. This prevents a graphical glitch known as tearing. The process is called double buffering.

Also, notice that all this drawing and clearing functionality is performed using our window object, which was created from the SFML RenderWindow class.

Run the game and you will get a blank, full-screen window that remains until you press the Esc keyboard key.

The SFML RenderWindow class allowed us to create our window object to take care of all the functionality that our game's window needs.

We will now explore two more SFML classes, which will take care of drawing sprites to the screen. One of these classes, perhaps unsurprisingly, is called Sprite. The other class is called Texture. A texture is a graphic stored in memory on the Graphics Processing Unit (GPU).

An object made from the Sprite class needs an object made from the Texture class in order to display itself as an image. Add the following highlighted code. Try and work out what is going on as well. Then we will go through it one line at a time:

int main() 
{ 
   // Create a video mode object 
   VideoMode vm(1920, 1080); 
 
   // Create and open a window for the game 
   RenderWindow window(vm, "Timber!!!", Style::Fullscreen); 
 
   // Create a texture to hold a graphic on the GPU   
   Texture textureBackground;   

   // Load a graphic into the texture
   textureBackground.loadFromFile("graphics/background.png);   

   // Create a sprite
   Sprite spriteBackground;   

   // Attach the texture to the sprite
   spriteBackground.setTexture(textureBackground);   

   // Set the spriteBackground to cover the screen
   spriteBackground.setPosition(0,0); 
 
    
   while (window.isOpen()) 
   { 

First, we create an object called textureBackground from the SFML Texture class.

Texture textureBackground; 

Once this is done, we can use the textureBackground object to load a graphic from our graphics folder, into the textureBackground, like this:

textureBackground.loadFromFile("graphics/background.png"); 

Next, we create an object called spriteBackground from the SFML Sprite class with this code:

Sprite spriteBackground; 

Then, we can associate the texture object textureBackground with the Sprite object spriteBackground, like this:

spriteBackground.setTexture(textureBackground); 

Finally, we can position the spriteBackground object in the window object at coordinates 0,0:

spriteBackground.setPosition(0,0); 

As the background.png graphic in the graphics folder is 1920 pixels wide by 1080 pixels high, it will neatly fill the entire screen. Just note that this previous line of code doesn't actually show the sprite. It just sets its position ready for when it is shown.

The object, backgroundSprite, can now be used to display the background graphic. Of course you are almost certainly wondering why we had to do things in such a convoluted way. The reason is because of the way that graphics cards and OpenGL work.

Textures take up graphics memory and this memory is a finite resource. Furthermore, the process of loading a graphic into the GPU's memory is very slow. Not so slow that you can watch it happen, or that you will see your PC noticeably slow down while it is happening, but slow enough that you can't do it every frame of the game loop. So it is useful to dissociate the actual texture textureBackground from any code that we will manipulate during the game loop.

As you will see when we start to move our graphics, we will do so using the sprite. Any objects made from the Texture class will sit happily on the GPU, just waiting for an associated Sprite object to tell them where to show themselves. In later projects we will also reuse the same Texture object with multiple different Sprite objects, which makes efficient use of GPU memory.

In summary:

So all we need to do now is use our double-buffering system, provided by our window object, to draw our new Sprite object (spriteBackground), and we should actually get to see our game in action.

Finally we need to draw that sprite, and its associated texture, in the appropriate place in the game loop.

Add the highlighted code:

/* 
**************************************** 
Draw the scene 
**************************************** 
*/ 
       
// Clear everything from the last run frame 
window.clear(); 
 
// Draw our game scene here 
window.draw(spriteBackground);           
 
// Show everything we just drew 
window.display(); 

The new line of code simply uses the window object to draw the spriteBackground object, in between clearing the display and showing the newly drawn scene.

Run the program now and you will see the first signs that we have a real game in progress.

It's not going to get Greenlit on Steam in its current state, but we are on our way at least!

Let's take a look at some of the things that might go wrong in this chapter, and as we proceed through the book.

The most likely cause of problems in this chapter will be configuration errors. As you probably noticed during the process of setting up Visual Studio, SFML, the project template, and the project itself, there are an awful lot of filenames, folders, and settings that need to be just right. Just one wrong setting could cause one of a number of errors in which the text doesn't make it clear exactly what is wrong.

If you can't get the empty project with the black screen working in the Creating a reusable template section, it might be easier to start that section again. Make sure all the filenames and folders are appropriate for your specific setup and then get the simplest part of the code running (the part where the screen flashes black and then closes). If you can get to this stage, then configuration is probably not the issue.

Compile errors are probably the most common error we will experience going forward. Check that your code is identical to mine, especially semicolons on the ends of lines and subtle changes in upper and lower case for class and object names. If all else fails, open the code files in the download bundle and copy and paste it. While it is always possible that a code typo made it into the book, the code files were made from actual working projects - they definitely work!

Link errors are most likely caused by missing SFML .dll files. Did you copy all of them into the project folder in the section Creating a project from the template?

Bugs are what happen when your code works, but not as you expect it to. Debugging can actually be fun. The more bugs you squash the better your game and the more satisfying your day's work will be. The trick to solving bugs is to find them early! To do this I recommend running and playing your game every time you implement something new. The sooner you find the bug, the more likely the cause will be fresh in your mind. In this book we will run the code to see the results at every possible stage.