SFML Game Development -- A book on SFML

[notnowlewis]

Bought this book at the weekend, really enjoying it so far. A chapter on box2d would be great for the next version

[Lo-X]

Bought this book at the weekend, really enjoying it so far. A chapter on box2d would be great for the next version

I agree :p

[Syntactic Fructose]

This is amazing, I love seeing how far SFML has progressed since I first heard of this. Getting the book asap



EDIT Q: If i order this on amazon am I also able to grab an e-book of it? I enjoy amazon shipping 

[MetalCoder]

I recently bought the book and am pretty happy with it. Everything is detailed nicely and it explains it throughly as you go along. Overall I'd highly reccommend this book.

[eXpl0it3r]

Look what I got today!

[Groogy]

Awesome! <3
From the whole team, thanks for the support and all the bug reports we have gotten
Will be putting out a public repository for the code pretty soon, we are still trying to choose a fitting license.

[Aster]

Hiya. I started reading the PDF/eBook, and I have to say; I'm slightly disappointed.

Even on the first few pages, I found grammar and spelling mistakes that really told me that Packt didn't even try to correct the book. Books take a long time to write, and a lot of care, and I know this.

Before you start telling me I'm some useless kid who doesn't know what they're talking about, I'll quickly state my position; I'm #sfml's grammar Nazi, and I'm taking part in the IB diploma program, mainly focusing on English, which happens to be my first language.

Writing a book with multiple people is almost as difficult as trying to write software with a C++ developer, a C developer, and a Java developer combined, in Perl. It's possible, but chances are, you'll get mixed up and disagree on a lot of things. And that's exactly how it felt reading this book. I could tell exactly who wrote what, even with my little experience on this forum, because you all write in different ways, and have different approaches to solving problems, which is obviously a Human trait.

Where things went wrong, is that, as far as I know - and this isn't an insult or anything - all of the authors are ESL (English Second Language), and each are coming from different languages, which often leads to expressions being "borrowed" from said "Mother Tongue" to English. Another thing that Packt should have proofread.

It hurts me to blame the authors, but I can't blame the publisher for not re-writing the whole book. Upon reading the first paragraph (and it took me a lot of scrolling to get there, author descriptions and all that go at the end of the book), I wanted to stop reading. The book seemed like a wall, it was slang, but it was menacing, I didn't feel invited to continue reading. The introduction felt more like a conclusion, it didn't feel thought-out.

As a side-note, It would have been nice if they had indented the paragraphs, for the sake of readability. And syntax highlighting would have been great, too.

Another thing that irks me is the obvious amount of effort that was put into it. Books are hard work, and writing a 300-page book in 6 months is obviously going to lead to mistakes and whatnot. You used "we" in a way that really only included yourself. You're constantly missing verbs in sentences because you write the way you were to speak. The titles weren't centered either, and their names were slightly ridiculous. You all had different coding styles, different indenting in code, and even that irked me.

You all seemed so focused on finishing the book according to the deadline that you didn't pay attention to producing a quality book, and working like that is good for a forum post, a text message, an e-mail to your coworker, but not a book.

I guess what I mean is, it's not easy to write a book, and don't write books like forum posts.

[Lo-X]

I disagree with you about so many points.

Yes english is not their mother tongue (neither it's mine), as well as many other programming book writers. You can't blame them for bad expression translations or few grammar mistakes.
In my point of view, every expression was understandable.

I don't think authors disagree in the book. I really do not know how they proceeded, but I felt that they did the whole project all together and then divided the writing between each other. Of course we feel who's writing what chapter, but that's perhaps because I'm used to read forum posts from authors or because I know, for example, that an author already had that project including that functionality the chapter is talking about.

About identation it's diffenrent between my Kindle and the real book, perhaps it's the same for you, dunno.

Unlike you I really was in the book, it was difficult to dettach myself from it. I think that point is only a matter of point of view, each reader is different.

I do liked the way they wrote the book. Perhaps they wrote it a bit like they speak, but since english isn't my first tongue that makes easier for me to understand it. When I want to read "real" english I just take a litterature book.

My point is that the book isn't only aimed to english and american guys. There's a lot of people around the world that were waiting for it. There are probably less english mother tongue people around here than english second language people. I think you're a bit hard. That's also good to point out grammar mistakes for future corrections.


Be happy a common french guy haven't written it, we're (in average) very bad in english and I think you've seen that in my post (sorry !).

[Aster]

Yes english is not their mother tongue (neither it's mine), as well as many other programming book writers. You can't blame them for bad expression translations or few grammar mistakes.
In my point of view, every expression was understandable.

There weren't a few, there were many mistakes. It's Packt's job to correct such mistakes, but it's also the authors' job not to make such mistakes.

I don't think authors disagree in the book. I really do not know how they proceeded, but I felt that they did the whole project all together and then divided the writing between each other. Of course we feel who's writing what chapter, but that's perhaps because I'm used to read forum posts from authors or because I know, for example, that an author already had that project including that functionality the chapter is talking about.

I didn't say they disagreed, they had very different writing and coding styles, and sometimes following a sort of "mini standard" can be important.

Unlike you I really was in the book, it was difficult to dettach myself from it. I think that point is only a matter of point of view, each reader is different.

I do liked the way they wrote the book. Perhaps they wrote it a bit like they speak, but since english isn't my first tongue that makes easier for me to understand it. When I want to read "real" english I just take a litterature book.

Perhaps as someone who has English as a first language, I notice these issues more than someone who is ESL, but they're still present, and Packt is a English/Indian publisher.

My point is that the book isn't only aimed to english and american guys. There's a lot of people around the world that were waiting for it. There are probably less english mother tongue people around here than english second language people. I think you're a bit hard. That's also good to point out grammar mistakes for future corrections.

I don't categorize the designated audience by nationality, but rather by language. I'm of course aware that there are more ESL people on this forum than otherwise, but for all languages, books written for adults should always be accompanied with an academic level of said language, because that kind of language is what people will speak later on.

Be happy a common french guy haven't written it, we're (in average) very bad in english and I think you've seen that in my post (sorry !).

I'm Belgian, living near the French border, I'm aware of some people's English levels around here.

[Klaim]

(and it took me a lot of scrolling to get there, author descriptions and all that go at the end of the book)

Well no. I have tons of programming books and none put the author description at the end, only a shorter one at the back. The reasons is that you want to see if the author is supposed to be an expert in the domain before even considering the book.
As you said you scrolled, I think you used the epub or even pdf version which when read in, say, a Sony Reader or iPad, will begin at the very first page, while if you use the mobi version with a Kindle, you open the book directly to the beginning of the book. It's mostly a packaging issue or a format desing issue or a reader implementation issue.

Whatever, my point is when I received the access and open the book on a Kindle, my first reflex was to go back to check the authors description (I don't know a lot about people around here).

Note that with paper you jump faster to whatever you want.

[Lethn]

Did someone accidentally change the extension when they uploaded the source code? I downloaded it and it says .zip.htm so when I open it it buggers up and goes to waterfox then loads lots.

Edit: Oh wait lol for some reason my computer defaulted to waterfox by default, I changed to winrar and it works fine now.

[Jamz]

I picked up a copy of the book and so far it's been an frustrating experience for various reasons and I'm only Chapter 2...

In Chapter 1 you list the update() method which a little futher on you modify to include delta time. Confusingly but the latter code listing has introduced a 'PlayerSpeed' variable which left me wondering if it was relevant for the new functionality, it wasn't so why was it changed?

Chapter 2 doesn't build on what was just built in Chapter 1. The demo code in the download makes no use of the 'Game' class at all, why not ? I thought the idea was to progressively build a top-down shooter ?

I really hope it get's better, as it is now I wouldn't recommend it.

James

[The Hatchet]

So, I'm up to chapter 5 now though my own personal opinion is that this book is pretty awesome, I can see where others are having frustrations with it.  From what I've taken away from this book so far is that it isn't for absolute beginners.  This book doesn't hold your hand by having you type 'xxx' on line 7, then 'yyyy' on line 8 and 'zzzz' on line 9.  Instead it kinda hits on the major ideas presented in the chapter with showing code for the meat&potatoes part of the programs.  Usually I read through a chapter, load up the finished source code for said chapter, read through the code, look at the parts that are explained in the chapters and incorporate what isn't talked about myself into my own code.

I agree that it could have been written a bit better, maybe with having each chapter contain a section that lists each file that will be created or edited in the current chapter.  There are a few times the authors start writing about idea and throwing functions and methods out only to in a section later finally say that these function belong in 'Whatever.hpp" file.  I find rewriting the code from the source to my own project is far stronger for my own personal learning methods than just being told to write this, then that, then this, then that.  When I don't understand a chunk of code I refer back to the chapter and reread the ideas presented and then it usually sticks.

So far I give the book an 8/10 on content but a 4-5/10 on execution.

[Nexus]

Thanks for the feedback!

Confusingly but the latter code listing has introduced a 'PlayerSpeed' variable which left me wondering if it was relevant for the new functionality, it wasn't so why was it changed?

It is relevant, because we take into account the elapsed time and multiply it with the player speed. Before we just had the constant 1. The idea of this approach was to introduce delta times and show how they can be used for a frame-independent timing.

Chapter 2 doesn't build on what was just built in Chapter 1. The demo code in the download makes no use of the 'Game' class at all, why not ? I thought the idea was to progressively build a top-down shooter ?

Many functionalities are modular. First we define them on their own, later we incorporate them into the game. Don't worry, resources will be used in Chapter 3

I agree that it could have been written a bit better, maybe with having each chapter contain a section that lists each file that will be created or edited in the current chapter.

Okay. Maybe this shouldn't be part of the book (it's probably rather annoying to have a list of files at the beginning of every chapter), but rather of the code base, like some kind of a changelist between subsequent chapters.

There are a few times the authors start writing about idea and throwing functions and methods out only to in a section later finally say that these function belong in 'Whatever.hpp" file.

We could have mentioned the corresponding file more often, but we felt it isn't necessary, because mostly the file name is implied by the class name. Otherwise, we tried to mention it (but since the file is less important than the functionality itself, it may appear later in the text).

[Lo-X]

Hi there,

I would like to integrate Box2D with the "engine" (I really need to find another word) that you make us do in the book. I'm not a Box2D expert but I already used it and have some notions. Still I don't really see how to do it to be nice-coding stuff...

What I was thinking about :
- Add the b2world object to our World, making it iterating for collision in update() method
- Add a b2body to SceneNode or perhaps to Entity ?
- I don't really know how to handle shapes and fixtures, nor joints
- Edit: oh yeah, and I wonder about the best way to link World(+b2world) to our Entities/Bodies (should be deduced by the rest of the architecture, I guess)

Is it a good start ? Do you have ideas or leads for things that are missing ?

In parallel I think about adding a LUA SceneNode that's able to launch a script when triggered by some events. I did added LUA to my projects before and creating a SceneNode is easy so that shouldn't be a problem, I'll keep in tuch peope around here that would like to do it too as soon as it's done.