
- •Credits
- •Foreword
- •About the Authors
- •About the Reviewers
- •www.PacktPub.com
- •Table of Contents
- •Preface
- •Introducing SFML
- •Downloading and installation
- •A minimal example
- •A few notes on C++
- •Developing the first game
- •The Game class
- •Game loops and frames
- •Input over several frames
- •Vector algebra
- •Frame-independent movement
- •Fixed time steps
- •Other techniques related to frame rates
- •Displaying sprites on the screen
- •File paths and working directories
- •Real-time rendering
- •Adapting the code
- •Summary
- •Defining resources
- •Resources in SFML
- •Textures
- •Images
- •Fonts
- •Shaders
- •Sound buffers
- •Music
- •A typical use case
- •Graphics
- •Audio
- •Acquiring, releasing, and accessing resources
- •An automated approach
- •Finding an appropriate container
- •Loading from files
- •Accessing the textures
- •Error handling
- •Boolean return values
- •Throwing exceptions
- •Assertions
- •Generalizing the approach
- •Compatibility with sf::Music
- •A special case – sf::Shader
- •Summary
- •Entities
- •Aircraft
- •Alternative entity designs
- •Rendering the scene
- •Relative coordinates
- •SFML and transforms
- •Scene graphs
- •Scene nodes
- •Node insertion and removal
- •Making scene nodes drawable
- •Drawing entities
- •Connecting entities with resources
- •Aligning the origin
- •Scene layers
- •Updating the scene
- •One step back – absolute transforms
- •The view
- •Viewport
- •View optimizations
- •Resolution and aspect ratio
- •View scrolling
- •Zoom and rotation
- •Landscape rendering
- •SpriteNode
- •Landscape texture
- •Texture repeating
- •Composing our world
- •World initialization
- •Loading the textures
- •Building the scene
- •Update and draw
- •Integrating the Game class
- •Summary
- •Polling events
- •Window events
- •Joystick events
- •Keyboard events
- •Mouse events
- •Getting the input state in real time
- •Events and real-time input – when to use which
- •Delta movement from the mouse
- •Playing nice with your application neighborhood
- •A command-based communication system
- •Introducing commands
- •Receiver categories
- •Command execution
- •Command queues
- •Handling player input
- •Commands in a nutshell
- •Implementing the game logic
- •A general-purpose communication mechanism
- •Customizing key bindings
- •Why a player is not an entity
- •Summary
- •Defining a state
- •The state stack
- •Adding states to StateStack
- •Handling updates, input, and drawing
- •Input
- •Update
- •Draw
- •Delayed pop/push operations
- •The state context
- •Integrating the stack in the Application class
- •Navigating between states
- •Creating the game state
- •The title screen
- •Main menu
- •Pausing the game
- •The loading screen – sample
- •Progress bar
- •ParallelTask
- •Thread
- •Concurrency
- •Task implementation
- •Summary
- •The GUI hierarchy, the Java way
- •Updating the menu
- •The promised key bindings
- •Summary
- •Equipping the entities
- •Introducing hitpoints
- •Storing entity attributes in data tables
- •Displaying text
- •Creating enemies
- •Movement patterns
- •Spawning enemies
- •Adding projectiles
- •Firing bullets and missiles
- •Homing missiles
- •Picking up some goodies
- •Collision detection and response
- •Finding the collision pairs
- •Reacting to collisions
- •An outlook on optimizations
- •An interacting world
- •Cleaning everything up
- •Out of view, out of the world
- •The final update
- •Victory and defeat
- •Summary
- •Defining texture atlases
- •Adapting the game code
- •Low-level rendering
- •OpenGL and graphics cards
- •Understanding render targets
- •Texture mapping
- •Vertex arrays
- •Particle systems
- •Particles and particle types
- •Particle nodes
- •Emitter nodes
- •Affectors
- •Embedding particles in the world
- •Animated sprites
- •The Eagle has rolled!
- •Post effects and shaders
- •Fullscreen post effects
- •Shaders
- •The bloom effect
- •Summary
- •Music themes
- •Loading and playing
- •Use case – In-game themes
- •Sound effects
- •Loading, inserting, and playing
- •Removing sounds
- •Use case – GUI sounds
- •Sounds in 3D space
- •The listener
- •Attenuation factor and minimum distance
- •Positioning the listener
- •Playing spatial sounds
- •Use case – In-game sound effects
- •Summary
- •Playing multiplayer games
- •Interacting with sockets
- •Socket selectors
- •Custom protocols
- •Data transport
- •Network architectures
- •Peer-to-peer
- •Client-server architecture
- •Authoritative servers
- •Creating the structure for multiplayer
- •Working with the Server
- •Server thread
- •Server loop
- •Peers and aircraft
- •Hot Seat
- •Accepting new clients
- •Handling disconnections
- •Incoming packets
- •Studying our protocol
- •Understanding the ticks and updates
- •Synchronization issues
- •Taking a peek in the other end – the client
- •Client packets
- •Transmitting game actions via network nodes
- •The new pause state
- •Settings
- •The new Player class
- •Latency
- •Latency versus bandwidth
- •View scrolling compensation
- •Aircraft interpolation
- •Cheating prevention
- •Summary
- •Index

Making a Game Tick
shape.setFillColor(sf::Color::Cyan); while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed) window.close();
}
window.clear();
window.draw(shape);
window.display();
}
}
All this application does is to open a window onto which we can render, with a width of 640 pixels and a height of 480 pixels. Its title says "SFML Application". Then, a cyan geometric circle is created, and while the window is open, it is drawn to the screen. Finally, for each time the circle is drawn, the program checks for user input that may have arrived from the underlying window. In our case, we only handle the sf::Event::Closed event, which arrives every time the application
is requested to terminate, such as when we click on the close button, or press an application-terminating shortcut, such as Alt + F4.
If you failed to understand a part of or the whole snippet of code, don't fear. This book contains all you need to know about this and much more.
A few notes on C++
C++ is a very powerful, but also very complex programming language; even after years one never stops learning. We expect you to understand the basic language features (variables, data types, functions, classes, polymorphism, pointers, and templates), as well as the most important parts of the standard library (strings, streams, and the STL). If you feel unsure, we recommend reading a good C++ book, before or in parallel to this book, since SFML and our code sometimes uses advanced techniques. Game development is a difficult topic on its own; it is very frustrating if you additionally have to fight C++. Even if it takes some time to reasonably learn the programming language, it is a good investment, since it will save you days of tedious debugging.
[ 10 ]
www.it-ebooks.info

Chapter 1
You may have heard that in 2011, a new C++ standard was released, which introduced a lot of extremely useful features. We are going to use a few C++11 features in the book, and show how they can improve code. Each time we use a new
C++11 technique, we will briefly explain it.
An issue that is widely underestimated, especially by beginners, is the importance of clean code. Before making a game, it is always a good idea to have a rough imagination of the game features and their implementation. It may help to draw sketches on a paper, in order to visualize contexts better. Also during development, it is crucial to keep an eye on the code design, and to refactor messy code where necessary.
Some key aspects of good code are as follows:
•Modularity: In this the functionalities are separated, and dependencies between them are reduced to a minimum. This allows you to maintain and debug application parts locally, as well as, to change the implementation of a module without affecting the other modules. Concretely, we achieve this by widely avoiding global variables, distributing functionality to different classes, and keeping interfaces between them small. We also split the code base to different headers and implementation files, and try to include only what is really necessary.
•Abstraction: In this, the functionality is encapsulated into classes and functions. Code duplication is avoided. The usage of low-level operations, such as manual memory management (new/delete) is minimized, because it is inherently error-prone, and replaced with idioms such as
RAII. In short, keep most of your code on a high abstraction level, such that it is expressive and achieves a lot of actions within a few lines. When you need boilerplate code, wrap it into functions, so that the code using it still looks clean.
•Code style: One thing, be consistent. It does not matter what naming convention you use, or if you have a space between if and the opening parenthesis, so long as you stick to one style. It is important that you keep the code readable and expressive, so that you still recognize what you have done after several weeks. Use comments where appropriate.
After this initial sermon, we hope that you have recognized how a well-structured code can keep up your motivation to develop, while on the other hand, a total mess is contra-productive and frustrating, when it comes to maintenance, debugging, or integration of new features. Don't be afraid if this advice sounds very abstract; you will automatically gain experience while developing projects.
By the way, the code we are going to develop during the chapters is available for download on the Packt Publishing website.
[ 11 ]
www.it-ebooks.info