The Toronto Game Jam is opening for registration later this year. I'm hoping to participate again since it's been a great experience every time. As of last year myself and a friend have participated in the Toronto Game Jam three times. The event, also known as TOJam, has developers come together at George Brown College for three days of manic development of crazy game ideas.
Participating in a jam can be overwhelming but also rewarding and fun as hell. Over the last few events I've had things go right and things go wrong. Here are some tips to help avoid some of the worse pitfalls that you can hit during a jam.
Tip 1: Know what you're going to make in advance
At TOJam you have from Friday at 10:00AM until Sunday at 6:00PM to create your game. While you don't need things to be set in stone you should know that you're making a puzzle game and if will be based on sliding tiles or stacking blocks. If you don't know what you want to make then you'll be using up your time figuring out what to do instead of doing it.
The week before the game jam we take our one or two paragraph "elevator pitch" and write a simple list of what needs to exist to fulfill that pitch. We then refine that list into a detailed set of tasks we want to complete on each day of the jam. With the list we can grab work as it's ready and keep dead time minimal.
Tip 2: Know what features you can drop
Murphy's law always strikes. Something goes wrong and suddenly the deadline is looming. When figuring out what to do for the game you should have some idea of what features you can drop without ruining it. Generally this list will be very short but it's always handy to have if you fall behind schedule.
Making a list of optional features is also a good gut-check on whether you've got a realistic schedule. If the list is long then your project is probably too large. A schedule that feels like it has too little work on each day is better than one with too much. You can always add work and scope to a project while you're working on it. It's much harder to cut scope down when you're running out of time.
Tip 3: Balance your workload between team members
If you're jamming solo you don't have to worry about this. If not it's critical that everyone has something to do. One trick is to have broad but shallow task trees. If C depends on B which depends on A then they can only be done by one person. Sure you could work on A then your partner can work on B but you can't work on C while your partner works on B. A way of fixing this is adjusting your design so B and C depend on A but not on each other. From a coding perspective using interfaces and loose coupling helps a lot.
In our latest jam, TOJam 12, we had a number of lethal hazards which could be activated by a button. In the bad case character death would depend on development of some arbitrary hazard which would depend on implementing the button to activate it. To avoid this we set up the button with two observable events, OnPressed and OnReleased and gave the player character a "Killed" method. By having a simple interface everything that was activated by the button could be developed independently. By having the "Killed" method player death could be written independently from any specific way of killing the player.
Another trick is to group your tasks into distinct streams. During the start of TOJam 12 I developed the base skeleton of the game while my team mate whiteboxed levels. The only dependency here was that I needed at least one level to load to start the game which was done well before I needed it. Later on I worked on handling player death while my teammate composed the title theme song for the game.
Tip 4: Have a library of game creation tools in advance
When jamming it's important to always be working on the game you want to make. The last thing you should be doing during a game jam is building a tile map editor. In TOJam 11 we lost about four hours to writing input handling code for a twin stick shooter. That took away time from more important tasks like generating bullet patterns, spawning enemies and so on.
Tip 5: Minimize the number of variables the game's design
I'm not a professional game designer so I'm not sure if "variable" is the right word. What I refer to is a thing that can be changed to alter the feel and balance of a game. The speed of a character, enemy hit points, number of enemies, how often they shoot, how often you shoot and so on. All of these variables add complexity to the process of making a game "feel" the way it should. Having lots of low hitpoint enemies could make you feel powerful. Having a few high hitpoint enemies would feel quite different. Having lots of high hitpoint enemies could make the game feel dangerous, scary or simply unfair. In all these cases I'm only changing two variables, the number of enemies and their hitpoints.
At TOJam 11 we produced a twin stick shooter called MANT: The Man Ant. The twist is that the bullet patterns would be generated procedurally. This also was the biggest headache. Pattern generation worked but it was extremely unbalanced. Sometimes patterns would be pathetically easy. Sometimes the game would produce enormous unavoidable walls of gigantic bullets. We burned up at least half a day trying to get a consistent and fun difficulty curve but still had huge differences between sessions. The game was a "finished" working product but it wasn't very fun.
Our next project was a puzzle platformer built around using dead bodies left behind when your character dies to reach different goals. Variables are generally level specific and mostly independent. Things like how quickly a door should close or how often a gun should fire. Tweaking still took around half a day but we stopped tweaking because we were done rather than being out of time.
ToJam Specific Extra
If you're driving from another city don't forget to take traffic into account. The 401 and Gardiner Expressway are infamous for a reason.
Related Links
Toronto Game Jam website
Our TOJam 11 project (not a great game in my opinion)
Our TOJam 12 project (you can find more details on how the jam went in the development log)
