[Video Tutorial] Arkanoid in 160 lines - C++11 + SFML2

[SuperV1234]

Hello SFML community!

I've created a 40 minutes tutorial/screencast on the creation of a complete game using C++11 and SFML2.
The end result is a playable Arkanoid/Breakout clone with a paddle, a ball and destroyable bricks.

This is my first attempt at a complete C++11 game development tutorial.
I divided the code in 9 segments, that I analyze and execute individually.

The video is aimed at people with at least a basic knowledge of C++.
Having some knowledge about common game development concepts will also greatly help.

The point of the video is showing how easy it is to create something playable thanks to the new standard and thanks to SFML, and to show a possible train of thought that can be taken during game development.



I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Also, feel free to fork the game's source code at:
https://github.com/SuperV1234/Tutorials
and expand upon it: I will feature the best forks in a future video

For other tutorials: http://vittorioromeo.info/tutorials.html - or just browse my YT channel.

Thanks for watching!

[JuDelCo]

Well, that was basic but well explained. And I learned some things ! Like the use of "remove_if" (i never knew how to use it). I have two questions:

"constexpr" its the same than "#define" but more oriented to define variables ?

aaaand.... I don't understand how this code:

shape.setSize({paddleWidth, paddleHeight});

is equivalent to this one:

shape.setSize(Vector2f(paddleWidth, paddleHeight));

How exactly works the initialization with { } ? Mmm

[Nexus]

"constexpr" its the same than "#define" but more oriented to define variables ?

No, totally not. constexpr declares a constant expression, i.e. a constant known at compile time. Integral constant expressions can, for example, be used as the size of arrays.

How exactly works the initialization with { } ? Mmm

This is called uniform initialization, there are many rules how it can be applied. And it's not 100% consistent. But in this case, you can specify the constructor arguments in order.

Feel free to search for these keywords, you'll find a lot of material on the Internet

[SuperV1234]

Everything Nexus said is correct, just wanted to reiterate and show more examples.

"constexpr" its the same than "#define" but more oriented to define variables ?

constexpr int arraySize{15};
int array[arraySize]; // Valid C++11 code, arraySize is a constexpr

constexpr int getArraySize(int x) { return 15 + x; }
int array2[getArraySize(15)]; // Valid C++11, getArraySize(15) can be evaluated at compile-time

int main() {
    int temp;
    cin >> temp;

    int array3[getArraySize(temp)]; // Unvalid code, getArraySize(temp) cannot be evaluated at compile-time
    cout << getArraySize(temp) << endl; // Valid code, but getArraySize(temp) will be evaluated at run-time
}
 

Please correct me if my example above contains any mistake.

aaaand.... I don't understand how this code:

shape.setSize({paddleWidth, paddleHeight});

is equivalent to this one:

shape.setSize(Vector2f(paddleWidth, paddleHeight));

How exactly works the initialization with { } ? Mmm

Basically, there are occasions when the compiler can automatically "guess" the type, and it's not necessary to specify it. Example:

Vector2f getMyVector1() { return Vector2f(5.f, 5.f); }
Vector2f getMyVector2() { return {5.f, 5.f}; }
// The two functions are practically equivalent

Very interesting link: http://programmers.stackexchange.com/questions/133688/is-c11-uniform-initialization-a-replacement-for-the-old-style-syntax

[Nexus]

I have now watched the video too, and I really like it!
It's great how you keep the code simple and short. You explain and visualize it very well, by showing the effect of each code part (and even a collision diagram).

Some remarks (most of them are just minor, your video is really good):

• The SFML game loop requires event handling with pollEvent(). Depending on the operating system, the window may freeze otherwise.
• You could also mention that in game development, it's common to have a frame time parameter passed to update(). Maybe it would be too much to actually use it in the example, but just as a sidenote...
• The getter functions such as x(), top() etc. could be const-qualified, as well as the parameters here: isIntersecting(const T1& mA, const T2& mB). Same for testCollision(const Paddle& mPaddle, Ball& mBall).
• using namespace simplifies the code in your case, but it would be good to mention its disadvantages for larger projects. Without it, it might also be a bit clearer whether a function/class belongs to SFML or the standard library. But I think it's fine in your case in order to keep the code minimal.
• The header #include <SFML/Graphics.hpp> already contains <SFML/Window.hpp>.
• constexpr is nice, but from the video it's not clear why you didn't simply use const, as the effect would have been the same. But you explained it in your last post. const int size = 43; is already a constant expression; the power of constexpr lies in functions.

By the way, your link to uniform initialization is very informative, as it shows also a lot of the drawbacks when it's overused: Ambiguity with initializer lists and other overloads, less expressive code.

[JuDelCo]

Okay, thanks for the clarifications. Now I understand my doubts ^^

and yeah Nexus, I forgot to say that I dont like the use of "using namespace <insert lib here>"

[SuperV1234]

I have now watched the video too, and I really like it!
It's great how you keep the code simple and short. You explain and visualize it very well, by showing the effect of each code part (and even a collision diagram).

Some remarks (most of them are just minor, your video is really good):

Thanks for the feedback, I'm glad you found the video interesting.

• The SFML game loop requires event handling with pollEvent(). Depending on the operating system, the window may freeze otherwise.

Totally forgot about this! I added an annotation.

• You could also mention that in game development, it's common to have a frame time parameter passed to update(). Maybe it would be too much to actually use it in the example, but just as a sidenote...
• The getter functions such as x(), top() etc. could be const-qualified, as well as the parameters here: isIntersecting(const T1& mA, const T2& mB). Same for testCollision(const Paddle& mPaddle, Ball& mBall).

I wanted to keep the video as simple as possible. I will probably improve the existing code in future videos, and I will deal with const-correctness and frame time.

• using namespace simplifies the code in your case, but it would be good to mention its disadvantages for larger projects. Without it, it might also be a bit clearer whether a function/class belongs to SFML or the standard library. But I think it's fine in your case in order to keep the code minimal.

Again, I chose to use using namespace for simplicity. I will deal with its drawbacks in future videos.

• The header #include <SFML/Graphics.hpp> already contains <SFML/Window.hpp>.

Didn't know about it, guess it doesn't hurt to include it anyway.

• constexpr is nice, but from the video it's not clear why you didn't simply use const, as the effect would have been the same. But you explained it in your last post. const int size = 43; is already a constant expression; the power of constexpr lies in functions.

True, I didn't show the "real benefits" of constexpr. I may do some "quick" videos about C++11 feature, where I show where they can be most useful.

[SuperV1234]

Thanks to everyone for the feedback!

I've uploaded the second episode of "Dive into C++11" on my YouTube channel.



Playlist: http://www.youtube.com/playlist?list=PLTEcWGdSiQenl4YRPvSqW7UPC6SiGNN7e

The video is quite long - if you want to skip to the parts you may find most interesting, here's a schedule:

0:00 - constexpr addendum
3:20 - uniform intialization syntax addendum
10:10 - 1st segment (const-correctness, noexcept, event polling)
19:40 - 2nd segment (FPS and Frametime management)
34:15 - 4th segment ("time-slicing" for consistent logic with any FPS)
45:10 - 5th segment (refactoring)

In this episode we will learn more about two previously mentioned new awesome C++11 features: "constexpr" and "uniform initialization syntax".

Most importantly, we will also deal with a very big issue that every game developer must face: FPS/frametime, and how to avoid the game from behaving differently on slower/faster machines.

In addition, we'll also briefly learn about "const-correctness" and using the "noexcept" keyword.

We will analyze the "time-slice" method to allow the game to run smoothly and consistently on every machine.

In the last code segment, we will also "refactor" our code by creating a `Game` class, making our source much easier to read and maintain.

I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Feel free to fork the game's source code at: https://github.com/SuperV1234/Tutorials

[JuDelCo]

Ill copy and paste the same i commented in youtube:

I see the constexpr functions like "inline functions" with the only difference they can be used to declare an array because the "compile-time" feature

[SuperV1234]

Ill copy and paste the same i commented in youtube:

I see the constexpr functions like "inline functions" with the only difference they can be used to declare an array because the "compile-time" feature

`constexpr` allows compile-time computation: I don't think the standard allows (or prohibits) simple inline non-`constexpr` functions to be computed at compile-time. It's also useful for compile-time meta-programming and stuff like tuple unpacking and tuple searches.

`inline` functions are not really comparable to `constexpr`, in my opinion. Also, `inline` functions are not only a (probably deprecated) way of suggesting compiler optimizations, but they also have the (in my opinion, very useful) feature of allowing multiple definitions of the same function, as long as the body is exactly the same. In fact, I use (abuse) `inline` functions all the time in my header-only libraries.

[Josh_M]

Inlining a function just removes the overhead of the function call. Inline functions, like functions, are generally evaluated at run time. The more you can evaluate at compile time the better .

[Nexus]

Also, `inline` functions are not only a (probably deprecated) way of suggesting compiler optimizations, but they also have the (in my opinion, very useful) feature of allowing multiple definitions of the same function, as long as the body is exactly the same. In fact, I use (abuse) `inline` functions all the time in my header-only libraries.

Exactly. The inline keyword required to fulfill the ODR (one definition rule) and allows function definitions in headers.

inline is only a hint to the compiler to inline the function. Don't overuse this keyword for optimizations; often, it's of advantage to define functions in .cpp files. Link-time code generation still allows them to be inlined (but automatically).

[SuperV1234]

Again, thanks to everyone for the feedback.

I've uploaded the third episode of "Dive into C++11" on my YouTube channel.


Playlist

In this episode we'll take a break from game development to delve into C and C++'s memory and lifetime management. We'll talk about automatic variable lifetime, pointers in general and dynamic memory allocation.

The intended audience for this tutorial/screencast are people who have some experience with C++ in general, and who watched the previous episodes. This episode may be very interesting for those with experience with C++ who want to learn more about variable lifetime and memory management.

I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Feel free to fork/analyze the source code at: https://github.com/SuperV1234/Tutorials

[ptchaos]

Hi Vittorio,
thanks for the videos. Really enjoying folloing them 

[SuperV1234]

Hi Vittorio,
thanks for the videos. Really enjoying folloing them 

Thank you!



Update: I've finished writing the source code for part 4 of the tutorial.
Since I'll be busy this week it will take a while before I start recording.

The source code is available here. If anyone is not currently busy, I'd really like to hear some feedback on the code before I start recording, so that the quality of the final video could improve. Thanks!