From a question ask in the official SFML forum which linked to a tutorial by Anthony Lewis at GameDevGeek.com I took the challenge up on me and converted that small game engine or maybe it would be better just called a state machine from SDL to SFML. In the near future I also hope to rewrite the original tutorial but of course inserting my insights and explain the additional changes I made. Also I’d like to get some more or less official approval that I’m allowed to copy bits and pieces from Tony’s text but unfortunately he didn’t reply to my e-mail (via the contact form) yet. So here a few things about it.
For all those that don’t understand what a state machine is, here a quick definition:
It is conceived as an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition, this is called a transition. – Wikipedia
So there you have it; we have a finite number of states of a game, like the menu, the splash screen, the game and the credits screen. The machine is running as long as there’s an active state and only one state can be active. (More details in the upcoming/original tutorial.)
So since the code is completely based on that tutorial it also uses the same states, namely IntroState, MenuState and PlayState. You start off with the IntroState and then by pressing any key you’ll proceed to the PlayState from which you can either invoke the MenuState or exit the application. From the MenuState you can only switch back to the PlayState.
After some thinking I’ve changed actually quite a lot of the GameEngine class and how states get created, paused, resumed and destroyed. I’ve also decided to use a few nice language features (e.g. RAII or std::unique_ptr<T>) so the code can now get described as C++ code rather than C with classes code.
Those changes, next to the ‘artistic’ advantages, give you more flexibility in using the states, as you can reset a state by just recreating it and it ensures that all three functions HandelEvents(), Update() and Draw() get called before a new state gets started, thus minimizing possible strange behaviors.
So overall it’s a nice little demo for a state machine and I might just as well use it in some future project. So feel free to literally check-it-out (or better git pull) on GitHub. If you got any questions then just put them in the comments, if you have any suggestions or bug reports use the issue tracking system of GitHub.