My experience making a game with SFML

HedronSpace_Screen2

For three weeks, I was doing C++ game programming to further increase my skills. This resulted in the game I call HedronSpace. My first time making a game in C++ was BlockDodger, but there were a few challenges with the engine code. BlockDodger used SDL for the low-level application code and it was very tricky to find a way to get audio to play and to get HUD-style font drawing to work out of the box.

That was one of the reasons why I made this new game in SFML. SFML offers an easy-to-use and object-oriented interface to make desktop applications. However, not everything was a walk in the park. SFML uses OpenGL for its low level graphics needs, but only offers a user-friendly interface to create application with 2D graphics. Fortunately, you can make 3D applications with SFML, but you’ll be mostly on your own.

That prompted me to make a little engine (I use that term loosely here) that wraps around SFML and offers easy to use 3D functionality for games (but only for simple abstract games). It’s called SF3DEW (which stands for SFML 3D Engine Wrapper) and took up most my 3 weeks doing C++ game programming.

Continue reading

BlockDodger – My Second Ludum Dare Post-Mortem

Image 003

You can download BlockDodger for Windows on its Ludum Dare page, or watch a quick video showing the gameplay. It also open-source, so anyone can see the inner working on Github.

You are a green block that must dodge red blocks by either moving around or shooting blue bullets. You can only shoot one bullet at a time. The game goes on forever until you lose or quit.

The game is really simple because it was made in C++ using Visual Studios 2012 and OpenGL. Before the 28th Ludum Dare started, I was working on a graphics wrapper that was an object orientated enhancement to the OpenGL tutorials at open.gl. You can download the graphics wrapper in a zip file here.

The libraries I used for the graphics wrapper and the game include GLM (for vector and matrix math), GLEW (for OpenGL extensions), FreeImage (for loading texture files), and SDL 2 (for windowing and program management).

I’ll keep this brief. These are the things I am proud of with this game:

  • I made a GameObject system that makes it easier to create entities in the game with common properties like position and color. Each GameObject also has an Update and Draw routine, which are called by a GameObject Manager (called GameObjectCtrlr in code).
  • The graphics wrapper I mentioned earlier (in code it’s called GraphicsCtrlr). It makes using modern OpenGL functionality (OpenGL 3 or greater) much easier and a little more object oriented. The alternative was to have a bunch of procedural function calls but that would be infeasible for drawing multiple objects.
  • I made a little wrapper class to basic SDL functionality called ProgramCtrlr which really cleans up the main function.
  • Actual game logic gets a class of its own (called GameLogicCtrlr). The good thing about this is that it prevents another manager class such as GameObjectCtrlr or ProgramCtrlr from having too many responsibilities.
  • I also made a really simple collision detection algorithm that treats the blocks as spheres and uses the squared distance. Using the squared distance prevents the computer from using square root functions. Both of these features make collision detection relatively fast.
  • I learned a few tidbits about class design and a lot of intermediate C++ concepts while making this game. Concepts I dealt with include friends, static members, polymorphic storage of objects, statically allocated singletons, a user case for protected virtual destructors (they’re usually public), dynamic dispatching (using virtual functions), and other such concepts.

These were the things that gave me trouble:

  • My texture management isn’t the most versatile implementation, so I had to hack a temporary solution to choose different textures.
  • SDL’s event system is currently implemented in my code to process one event at a time. Because of this, the controls are very bad (you can only use one key at a time). I did not have time to find a solution.
  • I was encountering several access violations when iterating lists because of semicolons that were accidentally placed right after the for-loop header. (ex. for(...); {}) The compiler never gives a warning about this. Took a few hours to find out.
  • It took me forever to get my head around random numbers and time functions in C++. It limited my “level design”.
  • My current implementation for resetting the level involves too much cleanup.
  • An object pool would have been very useful for the red blocks, but I didn’t have time to implement or use one.
  • I should have implemented factories for GameObject, but didn’t have time to.

That about wraps up my experience in my second Ludum Dare jam. Thanks for reading.

**Update: I made a slightly better version of BlockDodger with better controls and interesting spawning pattern.  It’s avaliable on it Ludum Dare page, or download the zip directly.