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.

Yxi – Alpha Demo Video

Here’s my progress on Yxi so far. I lot of work has gone into getting physics right and also making bosses with random parts.

As of yet there aren’t that many boss parts, but the system will randomly choose parts to build the boss. When the player blasts one of the arms, only that arm gets destroyed; the rest of the boss is still alive.

Other things this video demonstrates are how the player gets pushed back upon contact with the boss, how coins follow the player, what player death currently looks like, how shooting the main body will kill the whole boss, and how turrets slowly turn towards your direction.

Yes the graphics are very ugly, and the boss is currently boring. It’s a work in progress, so this will hopefully turn into something fun. 🙂

Continue reading

Ludum Dare 27 – Postmortem

Image 007

[This was cross-posted from Ludum Dare.]

This was my first Ludum Dare adventure and also my first game jam. I usually avoided game jams because I was under the impression that you must suffer sleep loss. Funny, I found a lot of Ludum Dare advice saying to get a good night’s rest, but that’s besides the point.

My best impression with Ludum Dare was the wonderful community here. There was a lot of positive energy, which I don’t usually see on the interwebs. I would like to thank everyone for making such a wonderful community of game developers and for making this game jam. And thanks to everyone who played my game. I was surprised by the amount of people who liked my game!

The game can be played here. Video here.

Image 010

Continue reading