Home / Featured Articles / Making Games: Game Jams and Roguelikes

Making Games: Game Jams and Roguelikes

Sometimes, making games is a frustrating, arduous, painful process…and then you start making the game.

Designing games is something that I find not only fun, but rewarding. Modelling stuff or doing the other “making stuff” aspects of game development, not so much. A couple of weeks ago at the Toronto Global Game Jam, I had to opportunity to make a game. In three days. With only a few hours sleep. In a smelly room. Boy was it fun…and frustrating.

This was me after Day Two.

My team and I (Team Rough and Tumble Jr.) decided to make a clock-punk rogue-like dungeon crawler, with a 3D environment and a 2D character. It’s a mouthful, I know. And not something we figured was even remotely possible to do in 3 days, but we tried valiantly anyways.

The biggest issue when we started was limiting the scope. Our original design had four characters (soldier, witch, monk, and mechanic); five environments (Forest, Mountains, Mountain Temple, Cathedral Basement, and the Town); different combat mechanics for each character (the soldier used cooldowns, the witch used health as a resource, the monk used body temperature to enhance his attack and defense, and the mechanic used a robot); and let’s not forget the Rogue-like dungeon creation. It’s a lot for even a seasoned development studio to do, let alone a bunch of fledgling designers with three days. We decided early on to limit the scope as much as possible, and then add more with any time remaining. We ended up with one character instead of four, one level instead of five, one enemy that was a recolour of the character, basic AI; these were the kinds of limitations we put on ourselves in order to have any chance of success. Limiting scope this much also helps protect against feature creep, which is when additional, unplanned features get added as development goes on (because hey, adding a flaming particle effect to the sword is really cool, right?). The less you’re aiming for, the less impact little extras have on your development time.


This was our main character, after we reduced our scope.

The other issue we had was employing friends who had never done a game jam before. There was two of them, and they’re 2D artists; but they had never done a game jam before and the environment we were in ended up more as a nerf-war and less of a game development studio. Don’t get me wrong, having introduced nerf to the rest of the team after the jam has proved very stress-relieving (even for the professors); but during the jam, it did more harm then good. Distractions during game jams, and indeed during all of development, are something that you need to keep in check at all times. We ended up with the roughest of rough alphas because of the distractions.

This is a screen from our early alpha during the jam. Looks good, doesn’t it?

In the end though, we have a proper alpha, and below you’ll see a screenshot of one of the interior buildings in the Town being built (it’s all very rough, mind you). We managed to get the town exterior done, the dungeon is indeed randomly generated (with proper spacing too!), and while we have a fair ways to go with it, it’s coming together.


This is the interior of one of the buildings in the Town from our Alpha.


Protip for doing any game jam: design small, implement quickly, and do the cool stuff at the end if you have time. I’ve done three jams so far (Game Prototype Challenge and TGGJ 2012/2013), and this was the first and only time I’ll attempt something this big.

About Daniel Spiler

From the frigid wasteland of Canada, Dan has been immersed in video and tabletop games since he was a small child. Then he grew up and realized he still loved all that stuff, so he spends his adult money on fun things like TCGS, Video Games, Manga, and his plethora of cats (there's like...5).

Check Also

BG’s Game of the Month for November 2023 is RoboCop: Rogue City

RoboCop might’ve been an underdog at retail, but it was an overwhelming winner for our …