SFML Game Development

So over the holiday I finished the book which was a really decent read.  Chapter 8 was had a very small section about particles which just uses a 4 point square to define a 1 pixel size square for a particle.  This is a cool idea because you can pass a bunch of vertices to the graphic engine and it will uploaded them to the graphics card for rendering. This is the most efficient way of sending a bunch of small particles and is a very clever way of creating special effects with particles.

The section on explosions was decent they just showed how to do that with a simple sprite animation.  It would of been really cool to do it with particles but I think that would've taken a couple of chapters all on its own.  It did give some insight into how we can fake many different game elements with a few good images.

The last chapter was fairly long but the topic was a little difficult to try and cram into this book.  It discusses the multiplayer aspect of games and how to network your games.  Unfortunately they could just scrape the concepts of network in just a single chapter.  Networking is a complicated subject all on its own and even the authors admit they couldn’t cover everything.  I don’t want everything I would've like to see a better design of how to integrate networking into the game code.  In this chapter they almost have to rewrite the game to add network support.  Many games do take this approach because the network design is so complex it is hard to switch it in and out for their single player modes.

Overall I would recommend this book to any serious game programmer that has a decent understanding for C++ code.  Many of their examples had typos and other kinds of errors that a beginner might not pick up on.  But don’t let this deter you from learning many of these cool new topics.  So now that you have followed me on my journey of reading this book you should go and get it yourself!

Currently I’m at 60% done with the book and there has been a lot of good information I have read in the past chapters.  Chapter 6 is about menu which has some good tips but nothing I would say is breath taking amazing.  They just discuss some of the common features of a GUI but I felt left a lot of the mouse controls out.  This may have been done on purpose with the popularity of touchscreen devices.  But with that said they created a GUI system that is based on the entity relationship and uses the state stack to extend the game features.

Chapter 7 is where a lot of action happens.  This chapter starts from a simple concept with nothing really working except for maybe the engine rendering a sprite to the screen.  Once your done with this chapter there will be a fully working game at the end.  Finally real progress can be done on the game design.  Granted there are books dedicated to the subject of creating games so them taking it all on in one chapter shows they didn’t want to spend that much time on game design.

Their collision system leave a lot to desire and even the authors admit this way maybe simple and have several buggy things that could happen.  Using a rectangle to calculate collisions can cause some major flaws in the game play where bullets may pass right through the target.

Onto my next chapter which is about particles.  Finally I’ve gotten to this chapter!

At first I didn’t think this was going to be a good chapter just because of the past chapters haven’t unearthed any new information.  But this chapter really had a few surprises!  The chapter starts out explaining how a stack can be used to manage the game state.  This is fairly standard design practices in game development because it allows a quick way to track changes from different states.

In this implementation they use a finite state machine to help track the different game states and bounce between different states.  I’ve used FSM for many different things in past project from AI to player controllers so it was refreshing to see this design pattern used in a very creative way.  The progression was easy to follow and very insightful of how it can be used and developed.

Building a game is a big project and I liked the idea that they build games from the splash screen first. Typically I leave this for last because I’m very lazy and at the end of the project we don’t have any kind of starting system. One of the next things I’m going to be focusing in on for my current game project is to add a game state manager so that the engine can always start with the splash screen.

There was one nitpicky thing I saw in their code which could of been simplified. Their enumerator code that would walk the stack could of been simplified by using a modulus algorithm instead of the if statements. I’m sure they used the if statements instead because it does make the code a little more easier for the uninitiated to follow. But this should not reflect on the writers because with their experience I’ll bet they already know how to optimize this code.

For those that would like to know example what I’m babbling on about here is an example of an enumerated value from the book:

if(value < stack.size())
{
	value++
}else
{
	value = 0;
}

To optimze this code using the modulus operator we would change it to:

value =( value + 1) % stack.size();

So in the first example code it just uses 7 lines of code that could be done in one line of code and not have to worry about evaluation. This one line of code will never allow the value to be greater than the stack size value. There is also a one liner for decrementing which I didn't show in this example but next update will have it.

Also unless you're familiar with this technique of using modulus the one line of code would require a lot more explanation than the if statement version. So for this book I have to applaud the authors in their use of the antiquated code because their trying to teach the subject and not the shortcuts.

Many times I have always wondered where and why there is a context type object in a project. The authors describe this in such a way that it has brought light to a dark subject. Working on several .Net project in the past I’ve always had to call on the context to do some special type page management. Taking this concept into the game engine now make a lot more sense. The programming dilemma I’m usually faced with is do I make the graphic system know everything or do I push it off onto the object to know how to render itself. Most of the time I try to make the graphic system as lightweight as possible so push this logic off to the objects. But this is a discussion for a later time.

The rest of the chapter shows very detailed examples of how to push different game states on to the stack. Which I’ll leave to you to read but the last point I really liked about this chapter was their quick discussion of multi threading which is an important part in game development these days. The example they discussed was the progress bar. Almost every game these days will show the loading progress of their game so that players don’t get discouraged that the game has crashed. This is where threading comes into play.

The game engine needs to keep running so opening the load process into a separate thread will allow the game engine to keep simulating and offload the actual loading process to the new thread. Then we just put code in place for the other thread to report back to the game loop how complete the loading has gone. That is the idea behind creating a second thread in the state stack but there are many other great places we could use an additional thread to help offload the main game loop.

The chapter does a great job at introducing mutexes and how we use them in SFML. If you don’t know why a mutex is important let me put it this way. Say we have 4 or 5 threads that need to access a shared resource. If more than one thread access and changes this data we could end up with some really odd results. This is where a mutex comes in, it allows the thread that needs access to the data structure a way to lock it while it is in use.

Back to SFML they provide a platform independent way of creating thread and the interface is really easy to learn and use. I liked the simplicity of their design which is refreshing to see since many of the other ways get complex. C# has a very elegant thread system which SFML has done a great job in mimicking. C++ is such a powerful language there has been many different multithreaded system designed. The downside is that Linux, Windows, and other OS’s use a different way to implement this feature. This is what really excited me about SFML was now they wrapped this into a tight and easy system to use.

So if you haven’t picked up this book yet I would highly recommend it just for this chapter alone. I’m still reading the book but at this point I have learned some really great concepts which will help me in my current project. Is this going to be a desk reference? Probably not but it gives a lot of really good ideas.

This chapter goes into great details about the main two different ways to manage input.  SFML does have a nice interface into the input system that queues up events and just waits for us to pull them off the stack.  Isn’t that nice of them to do this for us.  The queue holds more than just input events so we will need a system to filter out the unused events and capture out input events.  This polling process is typical for most input systems because it allows the game to progress and not worry about any input received from the player.

The other way to get input from the player is to pull directly from the hardware when it is needed.  Or as the book called it Real Time Input.  The nice thing about the SFML library they have anticipated this need and have provided classes to directly talk with the input hardware be it a joystick, mouse, or event the keyboard on the PC.  Yes people play games on more than just the PC these days so get used to it.

Part of the events in SFML also include all the standard events like windows closing, windows out of focus/in focus, etc…  This is where we can tie many of the important features of our game into standard functionality.  The most common one we need to deal with is the window close event.  If we just ignore this event then our program will run on for ever and we will upset a lot of customers.

The go into length about discussing how to retrieve and manipulate the kind of data each system can report back when asked.  Like the mouse class reports the mouse position at all times and we have to track our last polling position of the mouse in order to calculate the delta distance moved of the mouse.  This is great but when have accessed this information in Windows in the past it was already being tracked like this by the OS!  So now the library is now changing the data from the OS to make it form to their ideals.  This isn’t a bad thing because most of the time all we really want to know is where the mouse is on the screen.  Or even where on the screen did the user actually click.

Suffice it to say if you’re going to want to track the distance moved by the mouse between pollings this will be an additional data structure you will need to add.  Not really much of a surprise here because vector math is a very common thing found in games these days.  All movement in a game can be described as a vector.

Now the real reason we wanted to read this chapter was how can we accepts different kinds of input from the user and parse it out as in game commands.  Like how do we make the player move left or right?  Well in all the examples they have hardcoded the keyboard to accept WASD as the standard form of input.  Which means if the player wants to use a different set of keys their out of luck unless they personally know the programmer.

The chapter tries to build up from the hardcoded of the keyboard to a more versatile input system that can be mapped.  While I was reading this chapter a lot of different ideas kept popping into my head on how we could solve this problem.  Their final approach is to abstract out the key used in input from the command used to run the event.  Event better they use special C++ tricks to swap out the called function from the command so we can tie into it with our game but still use this structure for just about any kind of input we want.

There is a lot of complex concepts in this chapter but once you understand what their trying to accomplish it is an amazing bit of code that in the long run will make it easier for us to manage player input.  If you’re interested in more about how this dynamic system works do a good search on std::function which is a C++11 new feature.

Overall this chapter has some good ideas but could use some optimization and better explanations of the concepts provided.  Many times the author shows us some codes and says see this is how it works.  But in my experience you do need to provide a little better explanations so we get a better understanding of the ideas you're presenting.  Just as a reader note it did take me a few days to read this chapter because it was packed with so much information.  I’ll probably need to go back some day and reread it so I can better grasp the concepts their trying to present.

This is a long chapter full of decent ideas and concepts for managing your game data.  Many of the topic covered in this chapter just skim of the topic and leave you with some code to try and figure out.  This is kind of tainted since I’ve been using the Kindle version of the book on my cell phone so in print this probably isn’t an issue.  I’ll leave it at the code fragments get fairly broken at time and hard to read.

The game management system they are build is very coupled to the technology in SFML which is great for those who want to only use SFML for their graphic library.  For me though I want to be able to swap out the graphic engine when needed so abstracting that to a full different layer will not be possible with their code.  Now this doesn’t mean I’m not going to take ideas and hints from this chapter for some of the work I’ll be doing.

One key section in this chapter I really enjoyed but they didn’t cover much was the section on “Alternative entity designs”.  With a small game just using inheritance won’t be much of a problem because in the end you’ll end up with maybe 5-10 special classes.  But think about large scale games.  How many different kinds of enemies and game objects do you find in a typical AAA game title?  It depends but most are in a high number.  So creating a special class for each type of game object would bog down your programmers and make the game very rigid in design.

There has to be a better design pattern that can address this and make the objects work based on data instead of code.  This is where the link come in and they end the section very abruptly and say want to learn more go here.  Thanks for peaking my interest and then dropping the subject because you're worried about how many pages your book will be!

The information discussed on transformations is great and easy to implement.  I definitely liked building your objects as a hierarchy and not like I have done where objects can only be linked through a special case class.  Going this route and making it so children inherit their location based on their parent will make it so objects can easily move around the game screen.  In my link object class this has been an issue because I need to know where the object origin was placed before the link object has moved.  So the calculation are more complex than they need to be and will probably be super buggy in the end.

Transformation also contain more information in them then just the x and y coordinates of the objects.  It should contain rotation and scaling information which will make some of the more down the road features easier to design.

I really didn’t like their layer design because it was tied to an enum data type that would make it more rigid in design then it really needed to be.  Don’t get me wrong it isn’t that this design couldn’t be changed but it requires code editing to make it bigger.  In some ways when you’re designing the graphic subsystem it is important to not let it run away with your design needs.  Limiting the number of layers will help keep the performance decent but then take away some special case needs.

Talking about the graphic system this is where the designs show how closely it is tied to the SFML technology.  This is fine if you only want to use SFML for your graphics library and many of really good games can be designed this way.  But for me having the flexibility to change out the graphic system is an important feature.  Now being able to abstract this out with templates is very possible but will take some design testing to make it work.  Granted this book is called SFML game development so I expect to see this couple more closely with their code base.

Overall I liked a lot of the template or modern design approached discussed in this chapter and I will be certain to start integrating their concepts into my current game engine design.

This was your typical introductory chapter to game development.  It does a good job about explaining the basic concepts of SFML and game development.  It goes into some code about the main game loop and how it should be organized.  Nothing really new and surprising here but reiterates the importance of asset management.

The first chapter glosses over some core concepts in game design which I hope they will loop back and discuss in more details.  Their section on Drawable objects and Updateable objects was brief and didn’t provide any real good ideas.  The past couple of books I have read did a better job describing this topic.  Just goes to show you don’t take one book as the definitive source on good information.

The author does a decent job and discussing some of the new C++11 concepts that the book will try and address.  Although I’m still fairly new to some of these concepts I’ve been programming in C++ for 6-8 years so found some of their ideas a little more confusing than it cleared up.  The examples I tried with Visual C++ 2013 failed to work and when I tried to figure it out just wound up in a mess of code that didn’t compile.

Now then SFML does look very promising and it has made me look deeper into the current graphic library I’ve been using SDL.  The two libraries have a lot of common features just that SFML looks more like a C++ implementation then SDL which seems more C like designed.  In either case having a good asset management system is an import part of your project.  Make sure when you’re planning to design your own game engine that you put plenty of thought into this topic.

To be honest I have yet to download the SFML library because I’ve been really busy working on my current game engine project.  It is nice to have a project like this in place as I read the book because now I can think about using different design patterns.  This maybe one of my next big addition to the game engine I have been working on.

So I started the book like I always like to, with the introduction chapter and the preference.  So far the author seems overly thankful to his coauthors for helping write this book.  Great I get that you are thankful but there was no need to continue thanking them several times in both the preference and the introduction.  The couple of things I took from these two section was one author has written a good library for particle effects which I'm hopping the chapter on particles covers!

I may just jump to this section to have a peek.  No I will resist the temptation although I may lookup the particle library.