Things I Learned in TOJam

Couple of weeks back I  participated in TOJam #6, Toronto’s annual game jam. The event has transformed from a small gathering of wannabes into a real developer community event, drawing more game professionals and lots of media attention (more on that here).

For me this was a new experience, and a challenge to conquer: could I really complete a game in one weekend? The way I see it, some developers run half marathons, and I do the TOJam, which in itself is a marathon of sorts.

UPDATE:  Posted a link to Play the game in the Postmortem Article.

The different games that I’ve worked on so far had a schedule from 6 months up to 3 years. I know something about game production, and I figured its just a matter of good planning and narrowing the scope of the game, so that it could be done in 3 days.

The Game

Our game is a side scroller called ‘Pileup’, in which a cart drives on tracks using mostly gravity and the goal is to get the cart to the exit point. Game elements include track switches and elevators. It was developed from an early concept of an Angry Birds clone to a roller coaster type game with physics.

We used our own game framework as a base for the game code, most of it was written on the two weeks prior to the jam. I will cover the more technical aspects in a later post, were I intend to provide a full post mortem of the game.

The Team

Our team was composed of myself, Gavyn Elrick, Pavel Samsonov and Junko Shelton. Up until the jam itself, all previous work was done individually and most of it was code only, so we had to manage the tasks somehow. I had to double as a game producer and keep track of the progress during the jam.

First Impressions

The event was a lot of fun – people came with lots of energy and creativity. Peeking into each other monitors was very interesting, different technologies from Flash to Unity, XNA, and even HTML5. The place was packed with over 250 artists and coders enthusiastic to show off their creative skills.

The desktop machines supplied by George Brown College were surprisingly convenient –  despite the fact that I usually dislike Macs, I found the Mac Pro running Windows 7 (with Bootcamp) extremely fast, and heavyweights like Flash Builder 4.5 and Photoshop run  like a dream.

Planning

Surprisingly, the most difficult part was nailing down a game concept. Since I already had a basic game framework I kept saying to everyone: ‘Coding is the easy part, just get me a good game idea and we’ll take it from there’.

We struggled with the game concept for a few weeks before the jam. At first we tried to come up with some idea that is simple enough to do in a short time, but can still be fun to play (even for a very short time). All we could think of is ‘throw things at some breakable objects and have them bounce around’. Not very original. After getting some more input from friends this changed into ‘roll this ball shaped character somehow to the target point’ in different sceneries – that looked simple enough.

We actually started the jam without a solid game concept. By lunch time we had it more or less done, and then we just went with the ‘cart on tracks’ idea as the base of the game.

Code Like Hell

From there it was simply coding the game elements and designing the levels. Between two coders and two artists the progress was slow and steady. Time flew and things finally started to fall into place on Saturday evening, when we got the first playable level.

We somehow made the deadline of Sunday 8pm. I got very little sleep that weekend, and the longest sprint was about 40 hours straight.

Final Result and Conclusion

So we ended up with about 3-5 minutes of gameplay in 3 levels. Having completed the game jam, I came with some new found realizations about game production that is compressed to a very short time:

  • Narrow the scope of the game. If it looks you are not likely to develop a feature within the limited schedule, pass on it and spend the time on what is within reach.
  • Stay focused. When an idea looks even half good, hammer it down without hesitation. It may not come out great, but you’d be able to improve on it once it materializes.
  • Know your limits. Build upon the tried and true, that part that is proved to work. Experimenting during final coding is too risky, and you’ll waste valuable time.

All in all, doing the TOJam was a wild ride, and totally worth it.