This past weekend, I joined a group to participate in the 2013 Global Game Jam – and all things considered, we failed. But that’s a good thing: while our game did not materialize in the way we envisioned, this coding session taught us a number of valuable lessons on how to make games in general, and most importantly, on how to work efficiently given the constraints of such an event.
After taking part in my first game jam last year, I felt like I had it figured out: we ended up with a game called Beach Bully. While not particularly innovative or ambitious in scale, finishing it certainly felt like a success. After 2 long nights, we managed to get it working by Sunday afternoon. We had sound, graphics, and a couple of different levels. Our group even managed to spend some time polishing it, and adding extra features like a score-counter. While I can’t speak for everyone, I certainly entertained the idea that this would be the way each Jam would go. Oh, sweet hubris!
So what was different this time? After an extensive brainstorming session, we refined our initial idea for a few hours on Friday evening, and then started coding, and making graphics, and working on the level design in earnest on Saturday morning. Noon came and went. By early evening, we were still tossing ideas back and forth, however we had nothing playable; nothing even closely resembling a game. Then, we hit a wall as we realized that different parts of the team had been working on divergent sets of assumptions. The game design had run off in one direction, the technical implementation in another. We discussed the problems, we tried to come up with solutions, but ultimately that just wasted even more time. As the clock hit midnight, it became clear that the game we had envisioned was not going to happen on this weekend, no matter what.
Nonetheless, we put in another sprint on Sunday. Ultimately, we did manage to produce something, but realistically it didn’t satisfy anyone on the team. The parts that were playable weren’t very fun; the theme of the game was muddled, and the design seemed questionable. During our post-mortem discussion, we came up with a number of points that we feel would have made the experience more rewarding, and ultimately more successful. Looking back, we did follow some of these unwittingly during our first game jam; others we had to learn the hard way this time around.
- Get playing!
Get to the point of having something playable as soon as possible. There is no way of knowing if a game idea will work until you can test it, and you just don’t have the luxury of rewriting the core of your game, so get something out there for the whole team to play with. It’s fine if it’s just boxes and circles flying around a black background. Shoot for this by noon of the first day of coding at the latest, and go from there. - Don’t make a game
Wait…what? Yeah, you heard me right. Unless you are making a Mario clone, or a variation on Tetris, don’t focus on creating a full game. Think of a single mechanic that you think would be fun, and get it to work quickly (see point #1). By the time you are ready, you will have either decided that a) the mechanic isn’t that much fun after all, or b) you’ll have 29 and a half ideas on how to make it even better. - Have a design spec
While I am usually not a fan of formalizing a design too much, we noticed that as you work with a team of more than a couple of people, there are too many interpretations of how the game should work. None of these are “wrong” per se, but they introduce incompatibilities between the different your code, design, and artwork. At least during the initial phase, after coming up with ideas, sit down for a few minutes and spell things out for everyone – even if it is on a napkin. - Be concise
This is probably just a personal pet peeve of me, but if you cannot describe your game mechanic in a single picture, it’s probably not going to happen in a weekend. Further, I think you probably need to spend more time to get to the core of what makes the game a game. Try to explain your idea to someone who wasn’t part of your team’s design discussions that way, and you’ll see.
That being said, I am in the process of evaluating a number of game authoring tools for the next Ludum Dare in April, where I will be able to put all of these rules to test. Wish me luck!
Leave a Reply