Writing a Game: Feels like I’m Going Around in Circles…

Warning: This is going to be far less technical, and more about the journey of learning that I’m enjoying.

As per my previous blog post, and from several tweets I’ve posted, I’ve been slowly plodding away on doing some game development in my spare time and in my holiday break. I originally started doing this because I’ve always loved games, and was deeply inspired by the indie game development scene and some of the incredible ideas that were coming out of that.

That also being said, I was really keen to try a new programming challenge. Something totally outside of my usual purview, and doing game programming seemed like a perfect fit for that, as it sat so far outside my usual environment of building web based business applications. What I didn’t realise was how much it was going to push me in both directions that we new and also topics that I’ve learnt (far?) in the past and unfortunately forgotten much about.

One aspect that has totally blown me away was the architectural idea of “Entity Systems” (ES) for game development. (I’m not going to explain it here, there are way too many good articles on this, but if you want to read more click the link above). For what is such a relatively new idea in software development (< 10 years old if what I believe is correct), it fits so incredibly perfectly into how to write some insanely flexible game architectures, I have been rolling it around inside my head for other ideas of where it can be applied.

Since the last blog post, I refactored my entire code base into an ES architecture, and that was a fair bit of a mental shift away from a traditional OO model, but the more I use it, the more it just makes an incredible amount of sense. From the screen shot below you can also see I started adding some graphics to the page too, to make a little nicer to look at.


Some of the basics (and beginnings) for this came from the awesome SpriteLib project, but I also decided to start doing some drawing and try my hand at doing some of my own pixel art. Most people probably don’t know this, but I used to draw a lot. I even spent a year in design school… but to be honest, I was nothing special at it and ended finding a real passion for programming. But doing this game programming stuff has got me sketching out little characters and whatnot again, so it’s been a real pleasure to rediscover this passion for drawing that I haven’t touched in probably over a decade.

My next step in the game is to do some basic physics, nothing too special, just a player and some jumping to move around the world. Suddenly I’m back in high school doing kinematics and dynamics! I’ve still got all my old maths and physics notes from high school, so I’m pouring over that and also reading some great websites as well, and the concepts and equations are slowly coming back to me.

While doing that though, I started to look at the development cycle of Slick2d and the fact that it seemed like many people (including the original developers themselves) where moving over to libGDX. Comparing Slick2D and libGDX, you can clearly see that Slick2d has a far lower barrier to entry that libGDX. From my review of libGDX, having some knowledge of OpenGL and how 3D graphics work (even on a 2D project) is going to be a huge boon. So now I’m wondering – do I switch to libGDX? It looks more active, performant and gives far more options for distribution (desktop, web, android).

Again, I’m back to looking at old code from University – specifically my 3D programming class, and trying to make heads and tails of the OpenGL code I had previously written (in C++ no less). It vaguely makes sense, but there are concepts there I have either partially or totally forgotten (what is a Quad again? And different projection modes? no idea). Therefore, I’m going to keep playing with OpenGL some more, just to get that basic foundation under my feet, starting with the very low level lwjgl project with JRuby, and just keep going forward one step at a time, and then probably refactor my code again into libGDX once I’m done. While I don’t think I have to really know OpenGL to use libGDX, I always feel more confident having the base understanding under my feet. That and I think it’s a direct path to re-learning concept as vectors and 3d math with matrices that really is core to any sort of advanced game programming (yeah, forgot most of that too).

So overall, it feels like I am going around in circles a bit – but not in a bad way. I’m finding old things that I used to love doing (drawing and math) and rediscovering the joy I had in doing them, and although it’s frustrating knowing that you have forgotten the knowledge you wish you still knew, it’s a delight to reopen these memories and play with them once again.

Leave a Comment


  • Adam Tuttle | December 5, 2013

    Wow, all this talk of OpenGL stuff is taking me back to my days in uni too! If I recall correctly, Projections are about perspective. I only remember learning 2 projections. One where everything on the horizon gathered to a point (as in the old comic where 2 parallel lines “intersect” when the guys drawing them on the ground go so far that the lines appear to touch at the horizon) and another where the lines would never intersect.

    It’s been a long time and I don’t remember much more than that… except that I now do a lot of photography and it’s a similar concept to aperture (not sure if you’re into photography at all…) with a high aperture number the shutter doesn’t open very widely and all beams of light are traveling more or less straight into the lens; whereas with a lower aperture number the shutter opens very widely and there’s much more indirect/reflected light entering the lens.

    Probably a terrible way to explain it… sorry! 😛