SFML Complete Game Tutorial

[Azurus]

You should probably explain what the 'virtual' keyword is, how it works, etc. in part 6 too.

[Serapth]

I covered off the virtual keyword in part 4 and mention it briefly ( about it's absence ) in part 5.  The series is meant to build off the previous part, or each part would go from being long to being enormously overwhelmingly hugely long!

[sbroadfoot90]

oh my god I can't wait for part 7. Any idea when it will be done?

[Serapth]

Soon (tm).


A bad case of the flu ripped its way through the Serapth household and I am just now regaining the ability to string a cognitive sentence together.

The code is written, just need to finish the write up.

[kolofsson]

Dear Serapth, I have read your tutorial.

First of all, I would like to thank you for the hard work you put in this. It's really nice to see people dedicate their free time to help others.

I have to say, however, that your tutorial has made me more scared than eager to make a game. In the beginning of your tutorial you wrote:

I am writing it in C++ because regardless to all the people say “DON’T DO THAT IN C++!” the vast majority of people still do.

...people state things like “I hate OOP, I’ll just use functions”.

I have no academic programming experience, I'm more of a hobbyist programmer, so I'm not really aware of what people say. After reading your tutorial, I'm thinking they may have a point . I tried writing stuff in a couple of programming languages and I have to say that the best memories come from writing in PHP. For me, PHP is very easy to use and the syntax is easy to understand. PHP is packed with useful functions and very well documented on the php.net website.

From the history of programming I know that OOP is a step forward in making programming more abstract and "human". However, for me, objects make the source code so difficult to understand/grasp. For me, OOP should give me a set of blocks to play with. That's what I like SFML for.

However, your tutorial shows the true face of the OOP. Public/ protected/ private/ virtual/ constructor/ destructor/ static class, put a tilde here, an asterisk there and a colon. All this stuff makes my head explode and I don't consider myself to be a dimwit.

To conclude, I have read your tutorial thoroughly and understood a portion of it. To me the most useful part is the final product, which is the attached project file. The tutorial itself is an explanation of how and why you made the source code look like that. I will try to fiddle with that source code, but it looks like ultra complex to me, and I would never ever come up with anything similar so I don't know if I will make big use of it. I understand that your tutorial was meant for us to take over at some point and create similar stuff to what you did, but I think it's too complex for me.

I attempted to make a game with SFML once, but had to focus on other stuff. Now I would like to start over, that's why I read your tutorial. My game can be found here:
http://grebocin.com/upload/screenway08.zip

I made this game after fiddling with with SFML Pong example, which is much less complex than what you're offering (without objects, private, public, virtual etc.). I don't know if it makes sense for me to make this game, as you clearly state in your tutorial that not following it will lead to a fail.

[Serapth]

Hi kolofsson,

One thing to keep in mind, my tutorial is just one way of doing things and in many cases I absolutely overkill and that is on purpose.  There is nothing wrong with writing your code along the style of the SFML examples, doing things in that manner is much easier to get your head around.  

The problem is the examples are just that, examples.  They are meant to showcase how something works, not how to actually create a full game.  What you will find is once you start adding complexity to your game things are going to start turning into a mess really fast.  There aren't too many tutorials out there on actually laying out a game, so when I see beginners code it's often all in a single file with hundreds or thousands of lines of code all often in a single function.  Then again, this is a perfectly valid way to start.

This is what my tutorial is attempting to address.  There is a very good reason why there aren't many such tutorials and first off is they take a hell of a lot of space and time, look how long it is already and it's not even a functional game yet.  There often isn't space within a book, or in the case of SFML, it's well outside the scope of what should be documented. Again though, I am just showing one possible way of doing things and I am (hopefully) doing it in such a way that people walk away with a better concept of how to lay out a game and how OO programming works.  I am also over doing things, so although this is a simple pong game, you cant take the knowledge and some of the classes and apply them to any kind of game you wish to create.

However, there is nothing to say you need to make your game object oriented.  A great many games aren't programmed using objects, take a look sometime at the Doom/Quake source code that John Carmack released for an alternative approach.  It is simply one way to approach the problem of code complexity and there is no single "right" way.

All that said, judging by the comment  "Public/ protected/ private/ virtual/ constructor/ destructor/ static class, put a tilde here, an asterisk there and a colon" C++ is probably not the language for you, as these things are the bread and butter of C++ programming.  Compared to many other procedural programming langauges ( C#, Java, Python, Lua, Ruby, etc ) C++ has a downright byzantine syntax.

In all honesty, I don't really recommend C++ as a starter language, especially if you are approaching it from a hobbyist perspective.  If you are willing to do yet more reading this is my advice for beginning developers that want to get into game programming.  It is a very long read and I tried to keep bias to a minimum, but a number of new game developers have told me they found it extremely useful, hopefully you will too.  At the very least when you are done reading you should be a little bit more knowledgeable!  If you are doing this as a hobby, it is something you should have fun doing!

One other thing though, what looks like a foreign language will in time become natural.  In some cases it is simply a matter of time and effort and what initially makes your head want to explode will eventually become second nature to you.  We all go through it to a certain degree.  I do however find many languages are much more intuitive than C++, which should make your learning process much cleaner.

Fortunately, SFML has bindings for just about every programming language you might consider working with.  It is a clean, well designed and mostly intuitive library which is very good for a beginner.  Therefore whatever language you go with, SFML is a very good choice to stick with.

[kolofsson]

Allright, I'll follow your advice and read the guide. I like your writing style. You know a lot about making games, you write in an non-boring manner, which brings me to a question: who are you? Are you a professional developer?

When it comes to choosing programming language, I went with C++ because SFML is made in C++ and I knew C. I even tried reading books about programming in C++ but it was a few years ago and I forgot. Moreover a friend who is a professional programmer himself recommended C++ "as the pro choice" and told me not to fool around with C#. Finally, I don't fully understand the concept of bindings and how to make them work, they seem to me like another layer of complexity. And, as I fell in love with SFML, I did not want to use any other library.

[Serapth]

Bindings are usally just an interface layer that makes a library available to other languages.  Languages are able to call code written in other languages, they just require a bit of translation in the middle, this is essentially what a binding provides.  In the end you are still using SFML, just through a translation layer that makes it work in another language.  Your friend did you a disservice, but his (bad) advice is all to common, generally among younger/newer developers sadly.

As to me, I was a professional developer, even worked in games when I first graduated, but now I created a start up and work for myself while raising my 3 year old.  Now that pretty much all the coding is complete on my other project, I am getting back into games and writing.  Now is perhaps the greatest time to be an indie developer, so I am rather enjoying it.

[Nexus]

Very good tutorials! Good to see there are so many nice contributions to SFML

You have a clean code style: Clear identifiers, almost no manual memory management, good distribution of responsibilities to different classes, const correctness, use of the STL and constructor initializer lists. Many advanced C++ programmers still have problems with these things. Your explanations to new language features are clear and helpful.

I have however a few remarks, of which some are quite details, but I thought I'd mention them nevertheless:

• While I agree that globals like your class with statics are convenient and clean for small project, they can easily lead to problems, such as here. Here are some reasons against global variables in general, which are especially relevant for bigger projects. I think you should mention the issues or provide a corresponding link, because they are hard to recognize automatically.
  
• I wouldn't use _ at the beginning of identifiers. You say yourself that it indicates a non-portable extension. Indeed, global identifiers beginning with _, or identifiers beginning with _ and capital letter, or identifiers containing __ are reserved for the implementation. Because the exact rules are difficult to remember and easy to confuse, I would generally avoid _ at the beginning. You can use a convention such as mVar, myVar or m_Var...
• Clearing and displaying the window should happen outside the event loop.
• You can write it-> instead of (*it). for member access through a pointer.
  
• Prefer ++it over it++ if the expression's value is not needed, since pre-increment may be faster.
  
• I would declare iterators inside the for loop, this is especially an advantage if you have multiple for loops (with maybe different iterator types). Generally, declare variables as local as possible.
• In VisualGameObject.h, you forgot to include the <SFML/Graphics.hpp> and <string> headers.
  
• GetSprite() returns a non-const reference (sf::Sprite&). That makes the points you mention invalid, since the caller has direct access to the sprite and the implementation is doomed to store a sprite internally. Prefer sf::Sprite (copy) or const sf::Sprite& (const reference which can be changed to a copy without breaking code) as return type.
  
• Instead of if(x) return true; else return false; you can write return x;
  
• You write "the biggest difference between a class and a struct is that a class defaults to private while a struct defaults to public". Actually, it's the only difference ;)
  
• "Back to part six"... it should be "Forward".
• I wouldn't use assertions for runtime errors (like an image that is not found), because the  assert expression is not evaluated in Release mode. But you can use it to catch logic errors (which don't occur if the code is correct), such as calling Start() more than once.

[Serapth]

Thanks for the excellent feedback Nexus!

I really wish you'd mentioned some earlier as some are a nightmare to change at this point!

I can and will edit in a blurb about the possible perils of globals, that is a very good idea.

The _ thing, I know I shouldn't do it, I really really really know I shouldn't do it, but I can't help myself  It's a coding habit I picked up a long time back and although its frowned upon I really find it intuitive, especially because it groups all private members together in intellisense which is handy.  I know prefixing with m would have the same effect, but I personally at least think the prefix alphabet soup makes things more difficult to read.  Granted, in a tutorial I really should have coded to the established norm, but in this case I couldn't help it.

On the coding changes, I will see what I can do about addressing each mistake in code.  In some cases it makes a massive amount of work because of the way my blogging software does code samples in the posts.  




The choice to use asserts was one of those things I went back and forth on, and made a point of addressing that it was just one option in the comment.  As much as anything, I wanted to present the concept of asserts because they aren't mentioned nearly enough.  I think I will go back and add a bit further detail about the behavior of asserts during release mode.  I still feel they are a valuable concept to introduce.


Instead of if(x) return true; else return false; you can write return x;
Where did I do this?





As to struct/class, when I started with C++, I was coming from C and I seem to remember there being some arcane rule that a C++ to be compatible with a C struct under certain circumstances  ( perhaps composed of entirely POCO types ) would not contain a v-table.  This is a very old and very vague memory, so I decided to cover my ass and use
"biggest difference"

[Nexus]

I really wish you'd mentioned some earlier as some are a nightmare to change at this point!

Sorry, I haven't read the tutorial earlier :?

If I can be of help at changing a specific thing, just tell me

Instead of if(x) return true; else return false; you can write return x; Where did I do this?

For example here:

Code: [Select]

if(_gameState == Game::Exiting)
    return true;
else
    return false;
You could write

Code: [Select]

return _gameState == Game::Exiting;
But as mentioned, it's a detail. If you find the first variant more clear, use it. In my opinion, the second can be read faster if you understand boolean expressions

As to struct/class [...]

Your description isn't wrong, it's even very good. I also use struct for PODs, simple data wrappers or functors and class for "real" classes. But technically, one could use both in every situation. I mentioned it because many beginners think the class keyword is somehow the mighty variant of struct (probably because it is taught like this in books).

[kolofsson]

Hey Serapth , I have read your introduction to becoming a game dev. From what you wrote I understand I should either choose C# or Python. The problem is, I would like to stick to SFML and would not like to start learning XNA (I also would like my game to run on Mac and Linux). So, would you approve of going with C# + Monodevelop + SFML? I should add I'm not a fan of Visual Studio cause its bloated, its like a swiss army knife when I just need a knife. Hence the monodevelop.

Regarding the bindings, I only see bindings for C# and Python for version 1.6. Is it possible to compile a fresh nighly build of SFML and use the bindings?

If I went with C# + SFML, would your game from scratch tutorial still be of use to me?

I also took some time to see the differences between programming languages. So, what I like in programming languages is: weak type strength, implicit types, dynamic type checking, failsafe i/o, easy implementation of associative arrays.

From what I've seen in comparisons, I should either go with Python or Lua. However, AFAIR there are no up to date bindings with SFML for these .

I do not see the big difference between C++ and C#. My friend told me, that if I used C++, I could still do a majority of what I need to achieve without getting into the complex stuff. For a hobbyist programmer, I don't see where is the simplicity that C# brings. I can see that there are more built-in functions and easier to use too.

[Serapth]

I am not actually sure of the status of 2.0 .NET bindings, someone else will have to answer that question.  When just starting out though, I would recommend going with the stable supported version, that is why I based my tutorial around 1.6, although there aren't very many differences.

I don't really get the Visual Studio == bloated comments, but I see them all the time.  I absolutely love Visual Studio, I think it is one of the greatest pieces of software ever written and I am simple staggered by what it can accomplish.  There isn't even an ounce of hyperbole in that comment, I truly think its a wonderful piece of software and when recently using XCode or before that Eclipse it made me realize just how much I do love VS.  Now there is a ton of functionality in there that you don't need, which is why the Express versions are often a good place to start, but I don't really get that bloat part.  It loads in a matter of seconds, will open an exceptionally large project file in seconds, the compile times seem comparable to G++, the generated code is quite tight, the debugger is hands down the best debugger on any platform, ever.  About the only complaint I can think of is the few seconds of pause when running an application, but that's the price you pay for such amazing debugging.  Anyways, thats just my opinion on that subject.  Now the IDE vs text editor approach that has been argued since the first IDEs appeared, thats a different conversation.


But yeah, go ahead and use monodevelop, its a perfectly capable ide with the advantage of being able to work ( and consistently on ) on Windows, Mac and Linux, which is a nice perk.

As to if my tutorial would still be useful, thats a big fat sorta.  The setup portions obviously wouldn't be, but then .NET projects are a hell of a lot easier to configure than C++ so that is a lesser factor anyways.  The structure of my game however could be duplicated in C# and the code would look remarkably similar.  I actually code C++ in a very C#ish way, as that's been my primary language since it was released.  That said, there aren't too many tutorials out there on how to properly lay out a simple game, or design class hierarchies, etc... and that information will still be useful.  Additionally, the SFML calls will be nearly identical as well.  Obviously all the C++ specific bits will be mostly of no value if you go with C#.

Python or Lua are both perfectly valid options, although I would suggest Python over Lua simply because there is more documentation and help available for Python.  Lua was primarily created as a language to embed within other languages, although it has obviously grown beyond that purpose.  If it was me though, I would choose C#, but thats my personal bias again.  C# is the closest (mainstream) language to C++ but worlds more approachable.


As to the language differences, what you mentioned are some of the differences, but mostly as applied to Python/Lua vs C++.  C# is a strongly typed language, just like C++, although C# moved more towards weak typing with C# 4.  I personally think dynamic was a step in the wrong direction, but that's a argument well beyond the scope of this conversation.


The advantages to C# over C++ for a beginner are well beyond the scope of this conversation and a lot of it doesn't isn't necessarily core language features.  The C# build and configuration process is a world simpler than C++, there are no header files or preprocessor and the errors are a world easier to comprehend.  The first time you have to decode a C++ template error or warning, you will understand exactly what I mean.

Plus frankly the C# syntax, especially when dealing with templates vs generics, is a bunch easier to comprehend.  Plus the standard libraries are far superior, I don't think even the biggest C++ zealot would argue against that.  It also has a vastly run time support ( an advantage of running in a VM ), which benefits a developer in a number of ways, but the explanation of why are a bit premature.


I don't mean to make this into a C++ vs C# thread, by these are the reasons I think a programmer is better off learning with C#, especially if the syntax bothers you.

[kolofsson]

Waiting for part 7, Serapth...  :wink:

[Serapth]

Soon, soon I promise.


I learned a valuable lesson to try and put this chapter together.

I can't teach math.  It simply can't be taught in a tutorial, the subject is too overwhelmingly massive and had I thought about this upfront I would have saved a ton of time!


Take for example this method ( from Pang7 )

float GameBall::LinearVelocityX(float angle)
{
   angle -= 90;
   if (angle < 0) angle = 360 + angle;
      return (float)std::cos( angle * ( 3.1415926 / 180.0f ));
}


It is straight forward enough, but seriously how the hell do you explain to someone WHY it works.  In order to do that you need to go waaaaayyyyyyyyyyyy back to early high school math and explain so many concepts.  You need to explain Radians, Cartesian coordinates, then you have to get into Pythagorean's theorem and work your way forward.  Simply put, it is wayyyy beyond the scope of a tutorial and I am frankly not expert enough in mathematics to do the subject justice.

Sadly I went looking for good resources to link on each specific subject ( velocity, rotation, etc... ) but couldn't find a consisive site, anyone have a good recommendation?


Anyways, I attempted to explain the math and well... that was not a very productive end.  The code is written though, just need to polish the much more stripped down blog post to go with it.  Again, soon.  I also took a brief detour to explore Google's recently released PlayN ( not ready for prime time ).  Unfortunately, I am easily distracted by shiny objects.

As I am operating on about 7 hours total sleep from all of last weekend, so soon is not today however.