Game-Off 2012 Followup

Failure, but it’s not all bad!



Last time I talked about getting into Github’s game-off-2012 contest and I exclaimed how I would blog about my trials and tribulations. Well, it’s been a month and there’s been nothing but radio silence! I’ll change that here.

A month is a long time to use to create a prototype, however, I did a few stupid things and won’t be able to enter the contest.

What Went Right


I was able to dedicate a lot of my spare time to this project and didn’t alienate my friends, family, or significant other. I think the key take away for me is that I was able to use the time I set aside for this project wisely. The rest of my life didn’t suffer because I was able to fully concentrate on what I needed to do in 2-3 hour uninterrupted blocks.

The only thing that suffered a little is my sleeping habbits, but more on that when I discuss what went wrong.

Pretty solid start

When all is said and done, I have a pretty solid starting point to a finished game.

There is a good rule of thumb out there, “don’t make an engine, make a game”. While I did suffer from putting a lot of my effort into switching languages and libraries in the beginning, I never put effort into designing an engine, it was all very specific for the game. The way I coded, I put some thought into where I might be able to refactor things later, but I never let it expand to a more general case.

In the end, I created a component/entity framework in the vein of Crafty. I didn’t stick with crafty because I didn’t like some of the projects design decisions, like focusing on both DOM and Canvas rendering techniques and trying to be a general case for a wide range of browsers.

Really, at this point, I want to target the latest stable of just Chrome and Firefox, and I want to focus on using the canvas to display all game content.

Now, when I say “component/entity framework” I really mean that I created about 100 lines of javascript containing 3 things:

  1. A function for registering a component
  2. A function for creating an entity from a list of components
  3. A method that implements a publish/subscribe pattern for all entities (and a global game object)

Perhaps I’ll write more about it in the future, it probably deserves it’s own post.

What Went Wrong

Technology Switching

This was my biggest setback.

I started off strong, using Haxe+Haxepunk. By November 1st, I found that I did not enjoy developing in haxe – I do not know AS3, I do not know the flash libs, I do not use windows, and I don’t really have a feel for the community.

Great stuff, I got quite a bit done. However, when I hit a wall, I was quickly discouraged and switched gears to my old friend, javascript.

I started off messing with Crafty.js, a really spiffy little component-entity based engine. I think I could have got a lot done with it, but there were a few things I ran into that made me want to switch off of it:

  1. More a matter of taste: I wasn’t planning on ever doing DOM based rendering and I felt like there were to many concessions to trying to handle both DOM and canvas.
  2. I didn’t like how their module system tried to make you use hosted files. Easily worked around, and still a matter of taste, but I didn’t like it.
  3. Assets: only a handful of image and audio formats are covered by the asset manager, and there’s no way to really extend the main code from your own project without jumping through hoops that you really shouldn’t need to.
  4. The documentation sucks, there’s a bunch of pages that don’t show anything, and the documentation for the framework itself didn’t really explain much sometimes.
  5. Demo’s are not of a quality that I would expect.

So, after working through that for a bit, I thought I might fall back to melonJS, which I’ve used before and enjoyed. I didn’t get very far into using this library though. The time waster here was that I considered it at all.

After working with the good bits of Crafty, going to melonJS felt like I was going backwards a bit. Let me say, melonJS is a great framework that provides great support for Tiled/TMX maps and has pretty much everything you need to make a solid javascript based game. Crafty, at its core, just felt like a better way to design a game in javascript.

This is when I decided that I could probably create a core like Crafty’s fairly quickly, and I could probaby convert most of the audio, asset, scene, input, etc, code I’ve already written for other projects into this sort of design.

I was right about that, but my timeline suffered, and then some life stuff popped up, and I stopped working on the game for almost a week. Bam. Out of the contest.

If I had started from the beginning with what I have now? Probably would be polishing a prototype by now.

Rewriting Core Code

The second biggest setback was doing rewrites of portions of the core of my code. Avoidable? Maybe, but the rewrites were inevitable, and they really did prevent a lot of time and pain spent on things that would get changed later anyway.

Not enough up-front design

I think I could have put together a better design doc for the game itself. With no clear path, and so much time on my hands, I tended to focus more on the techical side of the game, and less on the visuals, interaction, and general game design.


While I was able to put a lot of spare-time effort into this game, and was able to avoid alienating anyone in my life, my sleep schedule suffered for it. This made me rely on caffinated and sugary drinks to stay alert and active, which did nothing good for my health.

I’m happy to say there was never a point where I was sleep deprived – I never got less than between 5 or 6 hours of sleep. But that takes a toll when you’re body likes having even just slightly more than that (I usually feel fine with between 6.5 and 7.5 hours).

Where to go from here

I’ll be continuing this project even if I can’t complete it for the contest. I think it has potential, and it has been quite enjoyable.

I have a lot more to do, so I’m sure hopeful that I’ll be writing more posts about it in the future!