From Game Jam Prototype to Unfinished Android Game...

Post date: Feb 01, 2016 1:51:3 PM

Riding high on our unexpected second place showing of Hoard Lord during the game jam, Brandon and I decided that our little Hoard Lord concept was strong enough, and simple enough, to make a full fledged mobile game.  I set about learning what I had to do to make a game on Android.

The Technical Challenges

We had created our Hoard Lord prototype in Microsoft's XNA game framework, using the programming language C#.  Using this XNA framework, you could write games for Windows PCs, XBox, or Windows phones.  Back in 2012 when this decision was being made was right around when MIcrosoft had basically announced that they weren't developing XNA any further.  When you are relying on a framework that you didn't develop yourself to make your life easier as a software developer you're always subject to the whims of the actual owner of that framework.  In my case, Microsoft had decided that XNA wasn't worth pursuing anymore, so they weren't going to.  We knew that we didn't want to restrict ourselves to just Windows phones, and since the platform was going to die a slow death of future incompatibility issues, I started looking around at other options.  As I looked around at these other options, my choices seemed to fall into two categories: game development engines, and game development code frameworks.

An engine does most of the heavy lifting for you - you can usually quickly start dragging and dropping objects in a scene and with few, if any, lines of code have your placeholder boxes and spheres flying around the screen in no time.  The drawback is that you can become restricted by the limitations of that engine.  Using an engine you will sometimes find yourself hacking workarounds into place to avoid the default behavior of certain aspects of the engine.  Of course, you can also hit the ground running much faster and get to the meat of your game more quickly.

A framework, on the other hand, provides you the raw functionality you need - there's usually some kind of menu system framework, input handling, and file system tools.  But everything that's provided to you is in code - you have to actually put all the pieces together yourself.  That means you have a lot of freedom to use those tools or not, and use them in whichever way you see fit.  It also means that you are free to mess up the code and turn your game into a buggy mess.

I eventually found the libGDX framework.  Like XNA, libGDX doesn't actually force you to design your game in any certain way, which as a programmer and designer I like.  LibGDX is written in the programming language Java, though - which I didn't know.  Java is very similar to C# (C# is basically Microsoft's version of Java) , so I decided it was worth it to learn Java (which would obviously come in handy for other things) in order to use this new framework.  Learning Java wasn't so bad, in a couple weeks I could at least do the basics with the language, and I picked up more over time.

So at this point, we estimated it should take about 6 months to make the "new and improved" Hoard Lord - this time using LibGDX and targeting Android as the release platform.  After a few months we got the basic game functioning - you could jump around and junk would fall on you.  But, once again my home grown physics system that had been "good enough" for the game jam was proving not good enough for a "real" game!  Boxes would collide into each other and the player, penetrate into objects they shouldn't, or be violently propelled away from each other.  So eventually I decided to use the very well-documented and mature Box2D free physics engine code library, which would handle all that for me.  At this point, I had learned Java (somewhat), learned how to use libGDX (mostly), and solved all the basic physics problems, but there was a different kind of problem surfacing now... There just wasn't anything to this game!  This game felt too simple at this point even for mobile!  So now we had an ever bigger challenge than any of the technical problems - we had to make the game fun!

Here's a video showing the game about 3 years ago - when it didn't have much more than the very basics of functionality and a working physics system: