SFML Game Development -- A book on SFML

[Oldie]

Is the source code from the book applying all the principles of SOLID design? Namely what is found here: http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29.
I have not checked myself because I am not skilled enough. Examples of what could be such designs are the scene graph and the command system, but it is just a guess.

[select_this]

The code is thoughtfully designed, if that's what you're asking. Whether it fully commits to SOLID principles or not is besides the point; in some cases it's probably not even relevant (after all, it is a demonstration project, not an extensible framework on which future titles will be built).

[eXpl0it3r]

The question is: What does it matter to you, if you can't even verify it yourself.

Besides that principals are there to give a good orientation and should not be forced on to everything. Use it where it makes sense, adjust it where needed.

[Mörkö]

I have just finished the book, so here's a small review of it.

I liked the relaxed nature of the text. There were times when a sentence was convoluted, ill formed, or didn't sound like natural English, but it was OK in general. The reason I liked the tone of the book may be because the previous book I read was by Stroustrup, so I guess just about anything feels approachable in comparison.

What I disliked most was the ordering of how different concepts are introduced. I concede to being a programming newbie, and that it's possible the authors had good reasons (which I don't understand) for structuring the book like they did, but mixing the game design with the game engine design was a mistake in my opinion. What the book should have been like, is to build the pure engine in the first chapters without any airplanes or sprites, and in the latter part of the book create a game on top of the finished engine.

This approach would have left all the chapters much cleaner, and probably shorter. Instead of introducing the SFML concepts mixed in with the game code, mixed in with game engine logic, the author would have been free to to describe either one in focus and greater detail. Of course the downside is for the reader to not get to the fun stuff immediately, but I'm arguing that the gain in terms of clarity and succinctness would have been more than well enough worth that trade.

As a bonus, it would let the reader start experimenting with their own game quickly, instead of having to either start over, or to spend the effort of cutting out all the airplanes from their code if they want to make some other kind of game.

That was my main gripe. As a whole I really did like it, and I'm glad to have been introduced to so many useful mechanics, such as the scene graph and command system, although I'm still somewhat confused about lambdas and some other things.

It's a pretty solid introduction for someone wanting to get into C++ game dev, and for now I will recommend it if the topic comes up.

Big thanks to the authors for this book.

[zsbzsb]

t it's possible the authors had good reasons (which I don't understand) for structuring the book like they did

create a game on top of the finished engine.

http://scientificninja.com/blog/write-games-not-engines

[Mörkö]

The article may have a point about someone who just wants to make a very small game. I would agree, if I'm making flappy bird then I will not bother defining a core framework (i.e an engine) before starting on the game logic.

But in anything more complex, I would definitely start by defining some kind of engine first. You may not have to do that, and if you are an expert programmer then perhaps you won't make any fundamental mistakes along the way, mistakes which would force you waste time refactoring deep parts of the game.

But that's all when just talking about someone simply making a game.

However, the book is something else than a diary of an indie developer, it's actually trying to teach something, and my point is that it would have done a better job of doing so by separating the game from the game engine.

[Ixrec]

It's just as true of big games.  You can't write a useful game engine without a very clear concept of what the actual game is going to be.  Otherwise you simply don't know what the engine needs to do.

Theoretically you could try to write an engine that supports every kind of game every dreamt up by anyone, but we've all seen what happens when you try that.  And even if you succeeded, it wouldn't be anywhere near as good as an engine designed for the particular kind of game you actually want.

What the book could potentially have done is say "we'll be making an engine for a 2D platformer" and then just assume everyone knows what a 2D platformer needs to do.  But, I think the target audience of the book is people who are new to game programming, and do not necessarily know on a technical level what a 2D platformer will and won't need to do.

[viettimetravel]

I'll be sure to get myself a copy as well.

[Oldie]

The question is: What does it matter to you, if you can't even verify it yourself.

Besides that principals are there to give a good orientation and should not be forced on to everything. Use it where it makes sense, adjust it where needed.

It could matter to me because I am interested in applying good design from the start. If I am told that, yes, this principle and that principle are applied in the book, in this concept and that concept, I know I can then look up myself. The good thing about it is that we have both clear explanations from the book and access to the source code for implementation details. So I'd be able to learn about such advanced topics more easily.
BTW my goal is not to copy and paste source code into my own project. I want to understand topics and put what I can get from that into my own code.

[select_this]

It could matter to me because I am interested in applying good design from the start. If I am told that, yes, this principle and that principle are applied in the book, in this concept and that concept, I know I can then look up myself.

The problem with this is that most of these principles are pretty subjective. One programmer might find a class too granular while another might argue that it perfectly fits the definition of SRP.

[Nexus]

Thank you for the feedback.

Concerning code design: we did put a large focus on OOP principles such as modularity, abstraction and encapsulation. We even emphasized the importance of them in the first chapter. At the same time, we tried to keep things simple, so you will find a quite pragmatic application of these principles. We have not intended to provide a totally abstract code base that can serve for any possible game, but rather to show solutions to many common problems in game development, and in particular applied to our game. Design decisions are regularly discussed with respect to their advantages and disadvantages.

Concerning separation of engine and game: there are several reasons why we have not structured the book like this. One is mentioned in the last paragraph: we tried to be pragmatic. Since the book is about development of a game and not an engine, we have never intended to provide a framework to fit all purposes. Nevertheless, several techniques (e.g. scene graph, commands, resource management) are abstract and generic enough to be applied elsewhere. Another important point is that a book should be interesting to read, and writing half of the chapters about development of an abstract engine without showing the use cases isn't. Keep also in mind the audience: SFML Game Development requires no previous knowledge of game development, a lot of readers are complete newcomers. In my opinion, the first thing one should learn in game development is definitely not writing an engine. Doing so would require considerable practical experience, without which will be difficult to understand all the decisions behind it.

[nikniknaks]

What is required knowledge of c++ to read this?

I know the basics of c++ like pointers reference but dont have an practical experience on it.

Is my knowledge enough?

[Nexus]

An intermediate level of C++ is required. If concepts like classes, OOP, templates, exceptions, function objects, memory management or the STL are new to you, I recommend reading a good C++ book (preferably one with C++11) in advance.

If you have already basic understanding of the programming language, it is also possible to learn more advanced C++ concepts in parallel to our book, however it requires some discipline. You shouldn't worry too much about the new standard C++11 though, the book was written with C++98 programmers in mind -- we quickly explain every new feature we use, and readers are free to have a deeper look at them on their own.

To sum up, it really depends on how much you already know and the way you learn new things, but I'd say good C++ knowledge (and some practical experience) is definitely an advantage.

What you can also do is have a look at some parts of the source code and see if you understand it.

[nikniknaks]

So far I am reading c++ primer 5th edition. But that book is like a thousand page and even though i have some programming experience in java i dont have a single practical experience in c++.

What i know is functions, pointers, reference, OOP and ofcourse classes

What i dont know, memory management although i know about something about heap and stack, STL(is vector, arrays, string, character part of STL?), and templates.

Do you think i can still read the book?

[Nexus]

I think it should be possible, even if difficult. You will recognize when things are unclear -- in that case, just don't hesitate to read up the corresponding parts in the C++ Primer.

By the way, this book is a thousand pages because C++ is a very complex language, and all the books (and tutorials) claiming to teach the language within a few weeks are blatantly lying. You don't need to know every corner of the language in order to develop games, but it's important that you understand the core principles and philosophies.

Especially when you come from a Java background, you have to be very careful to not adopt Java techniques, when the C++ equivalents look completely different. The languages look similar on the surface, but they're not at all. Some notable examples:

• In Java, the main abstraction feature is the class, i.e. object-oriented programming. Everything is modeled with hierarchies of classes and interfaces. C++ provides many additional abstraction mechanisms: templates (which are far more powerful than generics), global functions, function objects (instead of callback interfaces), typedef, namespace + ADL. A bigger focus is laid on generic and functional programming paradigms.
• C++ uses value semantics, reference semantics (as in Java) have to be stated explicitly. This implies that objects have a defined state (not null) during their lifetime. It also makes ownership explicit, whereas Java references are shared among their users. In modern C++, you rarely allocate objects with new, at least not without packing them into a smart pointer. The default way to create objects is by using the automatic storage ("stack"), dynamically allocated objects are encapsulated. A consequence of this is that you have to be aware when and for how long your objects live, they won't be automatically kept alive as long as you use them.
• C++ provides deterministic destructors, which allows for strict resource management in the form of RAII. That is, all the times where Java forces you to call close(), C++ can release resources automatically. RAII is a more advanced form of the try-with-resources statement, that spans not only local variables, but any scope.
• Exceptions are less prominent than in Java. C++ provides no checked exceptions, and the general approach is to let RAII handle resource deallocation and rollback semantics, allowing you to have much fewer try/catch statements.
• C++'s philosophy is "zero abstraction overhead", where Java makes operations as safe and context-aware as possible. One implication is that a lot of operations in C++ lead to undefined behavior if you use them incorrectly (e.g. index out of bounds), in order to not waste performance on checks that are useless in correct code. In general, logic errors are rather caught by assertions (debugging feature) than exceptions. Classes and functions in C++ don't exist at runtime anymore, they're a pure compile-time abstraction mechanism; Java keeps records of them for reflection.