A couple of weekends ago, I did something that I’ve wanted to do since I found out about them about 3 months ago. I participated in a game jam.

What’s a game jam, you ask? Is that – like back in the day – when you’d plug in your original Nintendo game cartridge only to have it show corrupted graphics on the TV and be completely unplayable until you took out the cartridge, blew on the connectors, and reinserted it back into the NES? Haha, silly reader. That’s what I would have thought until 3 months ago.

No, a game jam is when game developers get together in small groups to design and create a game! They are often associated with a competition, like Ludum Dare (more on this later), but they don’t have to be. There is also usually an element of time crunch – we wrote ours in about 30 hours over the weekend.

Ludum Dare is a popular game jam held every four months. Members of the LD community suggest and vote on the themes for each competition. After the final vote, the theme is announced and the competition begins. From this point on, entrants have 48 hours to design and create their game based on the theme.

The astute reader would then point out that the last Ludum Dare occurred in August… so what gives? Well, since jamming is apparently addictive, there are Mini LD competitions in the other 9 months. This is where our game jam session fits into the puzzle.

On Friday, I was contacted by a friend (founder of Binary Gambit – I’ll call him BG from now on) asking if I was available last minute to co-jam over the weekend. I jumped at the chance and took a train to his place and arrived Saturday morning at about 10:30. I prebooked my return train for 6pm on Sunday, so we had our time crunch built in.

The first thing we did before we started hacking away was to talk. About our feelings. No, not really. We had to decide a few things before we could begin! Important things like:

  1. Which framework should we use to code? (Ideally something that could compile for multiple platforms)
  2. What kind of game do we want to make?
  3. What kind of food were we going to order for dinner?

Ok, that last one wasn’t really important to do before hand, but we got it out of the way.

The framework decision came down to two: cocos2d-x or LÖVE. I am very familiar with cocos2d-x, as Gus on the Go is written using it. BG is very familiar with LÖVE. Being able to run your game on multiple platforms is very important because the judges, the members of the LD community, run various operating systems and devices. We initially thought that making the game playable in a browser would be good, because then anyone could play… but LÖVE doesn’t work for that and my JavaScript skills would probably require looking at reference material constantly. I usually code cocos2d-x in C++, but the version that can create HTML5 games requires JavaScript (and is appropriately called cocos2d-js). Based on this, we decided to go with LÖVE. LÖVE uses Lua, which is a simple language to pick up, especially for seasoned coders.

So that was that. I was going to have to ramp up my Lua skills, which on Saturday morning at 10:30 was basically non-existent. This made more sense than using a framework, for which we both would have to ramp up our skills.

We then discussed ideas. The theme of the Mini LD was RACE. I wanted to do something with raptors (who doesn’t?) and suggested we create a game where you race raptors. BG was up for it and we started sketching out the concept. BG is quite experienced in game jams and his #1 rule is to limit the scope of the game – otherwise, the game will likely never reach a playable state by the end of the jam.

We decided to limit motion by only allowing three lanes for running. Each lane was subdivided into three lanes where obstacles could appear. The player was anchored to the center of the lane, but could temporarily swerve left or right to avoid obstacles. A player could also bust through obstacles of the same color.

As a twist, we added two friendly, AI controlled players in the other lanes. The user controlled player could force a switch with a neighboring AI controlled player, but not the other way around. If the user is sadistic, he could create situations that would force the AI players to crash!

We started by assigning a major task to each of us. BG coded the environment and the obstacles and I took on the players and controls. To make things simpler and faster, we also started with single colored polygon representations for everything on the screen – 9 sided polygon for the players and rectangles for the obstacles.

When we each finished our initial pieces, we manually merged them together and started a git repository for version control. After this all future code merges were handled (mostly) automatically by git.

Simultaneously, we started collecting features we wanted to put in the game and bugs into an issues tracker. This helped us enormously in a few ways:

  1. It forced us to subdivide problems into smaller, manageable pieces
  2. It allowed us to easily prioritize and divide work among us
  3. It kept us from committing code in monolithic chunks (very handy if you need to remove code later!)

This system we put in place ended up in a very efficient game creation process. We even managed to sleep about 6 hours! Frequently, jammers pull all nighters for game jams…

Overall, I found the entire game jam experience to be fantastic! I’m quite proud of our little game and what we accomplished in such a limited time. The one downside was that we never got the raptors in the game… we ended up with spaceships, which is a tolerable substitution in my book.

If you’d like to play the game, you can download it here.


The game has been tweaked a little since the version we uploaded for the MiniLD competition. Checkout out the latest and greatest here.

NOTE: If you download the love file, you’ll have to download LÖVE.

Be sure to let me know what you think!

If you’d like to follow me on twitter, I’m @yonomitt. Binary Gambit is @BinaryGambit