At the end of April I had my first Game Jam with our local Sac Game Jam meetup. It was loads of fun, and a valuable experience. For this jam series, all teams start from the ground up, beginning by deciding on a game concept, mechanics, and then building out the prototype. This is all done within a relatively small period of time (around  6 hours), and at the end we all demo our creations, for better or worse.

My team went with a tug-of-war concept, and we used ActionScript using the Flixel framework.  We consisted of two ActionScript programmers, and a graphic designer. Let me just say, graphic designers are awesome. We were lacking some key equipment, so we restored to taking photos of the hand drawn images using a cellphone. Low tech, but it worked out. The paper cut-outs had a neat look too! In the end we made a mad dash to make things presentable, and while we had something to show, there was more we had wanted to include that didn’t make the cut.

There are many pitfalls that can be encountered throughout the prototyping process which can snare both newbie, and experienced jammer. These traps can be enticing,  often giving the facade of being critically important (“the game will be nothing without this!”), and in some cases of no importance (“we can figure this out later”, “this will be a snap!”). These can be avoided through preparation, planning, and restraint. Here are some tips I’ve gathered from this experience that I found noteworthy and will apply in future jams.

1.) Come prepared, don’t learn the framework at the game jam

There should be a basic understanding of how to use the framework,  not mastery, but some familiarity. The key issue is you don’t want to be spending chunks of time struggling with a mechanic or feature. This will eat up what little time you have like Pacman.

2.) Prototype, quick and dirty

Don’t worry too much about what it looks like, in code or graphically. You’re strapped for time, no one is going to care if it’s all nightmarish spaghetti code (*shudder*). Ya, it would be awesome if you could OOPify things with Player->doSomeAction(enemy), but you may be complicating things, which results in bottlenecks further down the line.  Make everything public, keep it in a single file unless absolutely necessarily.  In addition, don’t worry about animating sprites, or anything like that. This is just a prototype to give the idea of what you’re game will be like. Resort to using colored blocks and shapes if need be. Prototype like the wind!

3.) Start with simple game mechanics

Decide on core mechanics within the first moments of the jam, and keep those mechanics simple. It’s really easy to get carried away with game mechanics and lose sight on your main objective. Mechanics that require conditions and checking (ex. buff/debuff system) should be boiled down to something more manageable so that it doesn’t become a hold up. Even if the mechanics sound too simple, stick with them until it’s been implemented. If they really are that simple, you will have time to expand and add.

4.) Divide up features when working in groups

Working with another programmer adds a layer of trickiness. You now have to be careful of not stepping on the other fellow’s toes. Avoid overlap, and give ownership to features. Break things out logically like movement, item collection, and enemy collision. This is a practice that should be started at the very beginning so that there is a minimal amount of duplication.

5.) Be ready to share your stuff

When working with a group, be sure you have a way to efficiently share code at any time. There are many services out there, such as DropBox, but it doesn’t have to be that fancy. E-mail will work just as well. If you don’t have something setup in advance, resort to what ever is the most effective that doesn’t take long to setup. Advanced forms of code sharing, such as version control (Subversion, Github) may be tempting, but should most likely be avoided due to complications that can arise, such automated merging, and conflicts. From a coders perspective, you should know what is being removed or added.

Conclusion

Well there you go, a handful of pitfalls to watch out for from a great learning experience that was Game Jam #4.  There will be more that I will be sharing as I journal more past and future jams.  The important thing is to keep looking how to improve yourself, and most of all to have fun.

Thanks go out to GameDevRadio.net for their podcast on prototyping (and others).