In my opinion, the SFML View class is one of the neatest classes. If after finishing this book you make games without using a media or gaming library, you 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? 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 exactly 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 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 or view of the world.

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

Or consider a game where there is a small area of the screen that represents the entire game world but at a very high level, or zoomed out, like a mini map.

Even if our games are much simpler than the previous two examples and don't need split screens or mini maps, we will likely want to create a world that is bigger than the screen it is being played on. This is, of course, the case with Zombie Arena.

And if we are constantly moving the game camera around to show different parts of the virtual world (usually tracking the player) what happens to the HUD? If we draw the score and other on-screen HUD info and then we scroll the world around to follow the player, then the score will move relative to that camera.

The SFML View class easily enables all these features and solves the problem with very straightforward code. The trick is to create an instance of View for each and every camera. Perhaps a View for the mini map, a View for the scrolling game world, and then a View for the HUD.

The instances of View can be moved around, sized, and positioned as required. So the main View following the game can track the player, the mini-map view can remain in a fixed zoomed-out, small corner of the screen, while the HUD can overlay the entire screen and never move, despite the fact that the main View can go wherever the player goes.

Let's look at some code using a few instances of View.

Create and initialize a few instances of View:

// Create a view to fill a 1920 x 1080 monitor 
View mainView(sf::FloatRect(0, 0, 1920, 1080)); 
 
// Create a view for the HUD 
View hudView(sf::FloatRect(0, 0, 1920, 1080)); 

The previous code creates two View objects that fill a 1920 x 1080 monitor. Now we can do some magic with mainView while leaving hudView completely alone:

// In the update part of the game 
// There are lots of things you can do with a View 
 
// Make the view centre around the player           
mainView.setCenter(player.getCenter()); 
 
// Rotate the view 45 degrees 
mainView.rotate(45) 
 
// Note that hudView is totally unaffected by the previous code 

When we manipulate the properties of a View, we do so as shown previously. When we draw sprites, text, or other objects to a view, we must specifically set the view as the current view for the window:

// Set the current view 
window.setView(mainView); 

Now we can draw everything we want into that view:

// Do all the drawing for this view 
window.draw(playerSprite); 
window.draw(otherGameObject); 
// etc 

The player might be at any coordinate whatsoever. It doesn't matter because mainView is centered around the graphic.

Now we can draw the HUD into hudView. Note that, just as we draw individual elements (background, game objects, text, and so on) in layers from back to front, we also draw views from back to front as well. Hence a HUD is drawn after the main game:

// Switch to the hudView 
window.setView(hudView); 
 
// Do all the drawing for the HUD 
window.draw(scoreText); 
window.draw(healthBar); 
// etc 

Finally, we can draw or show the window and all its views for the current frame in the usual way:

window.display(); 

Now we have learnt about View, we can start coding the Zombie Arena main function and use our first View for real. In Chapter 10, Layering Views and Implementing the HUD, we will introduce a second instance of View for the HUD, fix it, and layer it over the top of the main View.