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.