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.

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.