SFML Game Development -- A book on SFML

[Kanefa]

Nexus, you mentioned that the command system approach is less common.  I have been wondering why you chose that approach over a more conventional approach, like an event system. 

The main difference I see is the command system couples the event with the action.  Whereas an event system would simply broadcast an event and let the game components handle them.  In this regard the event system seems more flexible.  Also, the command system is reliant on the scene graph. 

Could you explain why you chose this system?  What advantages do you see?

[eXpl0it3r]

I'm not Nexus or any other author of the book, however in a general context, I can say, that the command system matched the created game better, than the general purpose event system. Which is one of the more important lessons to learn when creating games. Write code that fits your game needs. Don't just write code, because it's more generic or because everyone seems to include that feature.

[Nexus]

A command is more powerful than an event that holds only state and no functionality. You can simulate a classical event system using the command system, but not vice versa:

Command c;
c.category = ...;
c.action = [myEvent] (SceneNode& node, sf::Time) { node.handleEvent(myEvent); };

A difference is that the functionality is defined on the caller side rather than on the entity side. In this respect, commands are similar to direct function calls, but delayed and without knowledge of the receipents. Entities don't need to be prepared to handle a certain event correctly, the functionality can be implemented unintrusively using the public API of each entity. On the other side, this can be a drawback if you know absolutely nothing about the entities or require different reactions depending on the entity type. With commands, you don't have explicit case differentiations (switch statement), and there is no need to downcast events or their attributes. Furthermore, lambda expressions make it possible to take into account the context of the caller, and transport information back to it, without widening the caller's public API (for example, the EmitterNode and ParticleNode are connected in this way).

The book was also a good opportunity to introduce design choices that are not seen in every game. People will eventually learn different approaches, and can choose the one that best fits their needs.

[nvangogh]

I couldn't wait to get this book and bought the kindle edition. It is ok on the kindle, but I'm going to buy the hard copy when I can because I like to make notes. This is a great book that I am enjoying reading!

[Groogy]

I couldn't wait to get this book and bought the kindle edition. It is ok on the kindle, but I'm going to buy the hard copy when I can because I like to make notes. This is a great book that I am enjoying reading!

Love to hear that you enjoyed it

[Hysler]

Hey guys, I've been a lurker on this forum for some time now and just decided to join. I bought this book (hard copy) a little over a month ago and I have to say that it's been extremely useful and fun for me to go through. I just completed chapter 6 last night and am moving on to chapter 7 as of right now!

So thanks a lot for all of your hard work and time, it's very much appreciated  .

[jannugimes]

I am going to get one soon, thanks or sharing..

[nathanchere]

Just want to make sure I'm not re-inventing the wheel here - has anyone else already ported the book samples to SFML.Net yet?

[zsbzsb]

Just want to make sure I'm not re-inventing the wheel here - has anyone else already ported the book samples to SFML.Net yet?

Not that I am aware of.

[SeriousITGuy]

I was just looking over the implementation of the ResourceHolder class again yesterday and recognized that ResourceIdentifiers.hpp uses enums nested in namespaces. I think the main purpose of this would be to "emulate" strongly typed enums (as of  c++ enums are not strongly typed) so that no name conflicts arise.

C++11 offers enum classes which serve the purpose of strongly typed enums, so that one is enforced to use the strong name of an enum member.

So my question is, could the following code

namespace Textures
{
        enum ID
        {
                Eagle,
                Raptor,
                Desert,
        };
}

be rewritten to

enum class TextureID
{
        Eagle,
        Raptor,
        Desert,
};
 

to accomplish the same goal? One must then reference to a member of this enum class via TextureID::Eagle instead of Texture::Eagle.
I don't want to do this just for the features sake, but to eliminate the additional namespace, because I think it's a not intended use for a namespace, and an enum class is a real type compared to a classical enum.
I think this is a worthwhile refactor, but would like to here more expert opinions on this.

Thanks in advance.

[Nexus]

The book introduces strongly typed enums and mentions that they are not used because of compatibility with more compilers (page 37). So this choice is intended

The namespace around enums was a C++98 idiom to introduce scope. It's quite nice in my opinion, but not really necessary anymore with enum struct/enum class.

[SeriousITGuy]

Heck, completely missed the part on strongly typed enum's in your book, should read more carefully and browse code less.
OK, question answered, my next implementation will make use of enum classes.

But with that the next question arises:
The command system uses an enum for the receiver categories, where only one bit is set per enum member. The purpose is clear to construct compound categories via &-operator and to check compound categories via |-operator. I know I can contruct such a enum class with bitwise members, but do the bitwise operators still function the same way as with normal enums?

[Nexus]

We don't use enum to combine the flags, Command::category is of type unsigned int. Only the single flags are enums.

As far as I know, you can't combine strongly typed enums with binary operators because they don't support implicit conversion to integral types. So you'd have to cast the values, or overload the operators.

You should however not try to store the results of flag combinations in enum types, since enums are intended to provide a small finite set of possible values, i.e. the enumerators. Either use unsigned int as we do,  or think about a dedicated type-safe Flag<Enum> class template.

[Kojay]

Overloaded bitwise operators can return bool (which is presumably what you want to use them as?).

[SeriousITGuy]

Yeah overloading bitwise operators seems like a good idea. I will put it on the "to-research"-list and will come back later to it. For now I stick with storing categories as unsigned int as in the book, because it's a very easy and pragmatic implementation.

Thanks for the answers so far
Cheers!