Book Image

SFML Game Development By Example

By : Raimondas Pupius
Book Image

SFML Game Development By Example

By: Raimondas Pupius

Overview of this book

Simple and Fast Multimedia Library (SFML) is a simple interface comprising five modules, namely, the audio, graphics, network, system, and window modules, which help to develop cross-platform media applications. By utilizing the SFML library, you are provided with the ability to craft games quickly and easily, without going through an extensive learning curve. This effectively serves as a confidence booster, as well as a way to delve into the game development process itself, before having to worry about more advanced topics such as “rendering pipelines” or “shaders.” With just an investment of moderate C++ knowledge, this book will guide you all the way through the journey of game development. The book starts by building a clone of the classical snake game where you will learn how to open a window and render a basic sprite, write well-structured code to implement the design of the game, and use the AABB bounding box collision concept. The next game is a simple platformer with enemies, obstacles and a few different stages. Here, we will be creating states that will provide custom application flow and explore the most common yet often overlooked design patterns used in game development. Last but not the least, we will create a small RPG game where we will be using common game design patterns, multiple GUI. elements, advanced graphical features, and sounds and music features. We will also be implementing networking features that will allow other players to join and play together. By the end of the book, you will be an expert in using the SFML library to its full potential.
Table of Contents (21 chapters)
SFML Game Development By Example
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Automated resource management


Let's talk about textures and the way we've been using them so far. A texture in SFML is something you want to only have one of, since it's not cheap memory wise. Our approach so far was simply storing the textures as data members of relevant classes. A scenario that illustrates how horrendous this strategy is would be as follows: you need the same texture somewhere else. That's it. It really doesn't seem like the type of thing that you could just brush off your shoulders, as it only happens once in a blue moon. Creating multiple textures that all hold the same data is a huge waste of resources, and adding methods for obtaining textures from the classes that use them is a disaster. Not only does it clutter the class footprint, it would also mean that other classes would have to have access to the one that holds this texture. Nobody should subject themselves to such torture.

How do we remedy this situation then? By creating a class that holds all of our textures...