Global Game Jam 2013 Post Mortem


Having just completed my first Global Game Jam, I felt it was necessary that I shared a few lesson which I learned along the way. Held at NYU’s Game Center in Manhattan, we were one small sect of what would become a worldwide jam. On Friday evening I joined a team which was comprised mostly of strangers, and quickly we developed not only friendships, but also a game.
With that in mind, here are some lessons from the last 72 hours:

Finish with half a day left

By this I mean if the deadline is 5 PM on Sunday, have your game done

Showing off our game!

Showing off our game!

and ready to play by 12 o’clock that Afternoon. From there you’re just polishing, but at least you’ll know that the game works – you don’t want to make a mistake of finding out 30 minutes before the deadline that all of your scripts don’t compile, or that you’re missing valuable assets that got deleted in the last commit. We ran into that mistake, head on.

One of our artists is  incredibly talented and crafty with After Effects, so he put together a great intro scene for our game. I did the programming for the menu items, and because we waited for the last minute to implement these things, they were both dropped completely from the end product. The same thing happened with our pause menu. I wrote the script for that, but due to our last minute compilation of the project, that was missed as well.

When it was time to show off the game ours was not in the best condition. It was riddled with bugs the gameplay wasn’t tight and we hadn’t really thought about whether or not it would actually be fun to play.   have we put together the whole thing sooner we would’ve
realized this before the point of no return.

Our initial goal was to have the prototype completed after the first day (Saturday) then spend Sunday just refining that work. Of course things seldom turn out as planned, so we wound up building the game well into the last few minutes. Once we brought it to the showcase, our worst fears were soon realized – the controls were janky, and even the most basic gameplay items weren’t implemented.

Have more than one set of eyes on your code

IMG_3784In my mind programmers are the most viable asset at a jam.  My mentality is that you can never have too many. Art on the other hand you can often find online and the same goes for music, but finding competent programmers who really put the whole package together are a rare breed. That’s not to belittle what other do, but understand that most of the power lies with the programmers.
After we finished the project and were showcasing it, I took a look at some of the code I didn’t get to work on, and was able to quickly correct a number of the issue with it. Had we both shared our code with one another before the final build, these issues could have been resolved before the showcase. Besides, it’s always nice to learn from your colleagues, so I would have loved to have spent more time with the other programmer’s code.

Don’t sweat the SVN

Save everything locally to your own computer for a while and then IMG_3768
consider sharing a drop box folder with your other teammates. Far too often, teams waste of time preparing SVN and backups when really you only need to save your own items locally, then combine the project as you move along.
We spent far too much time worrying about backing things up and our version control;  valuable hours were lost. I’d prefer to just leave things in a shared Dropbox, and move them about that way. Towards the end that’s exactly what we decided to do, and it worked well.

Sleep is valuable

I frequently find that jammers like to keep working through the night and not catch any zzzz.  I don’t know about you, but to me sleep is precious and I value every minute that I get. I find I’m far more productive on a good night’s rest, so I’d rather use my time wisely, sleep briefly, and then get back to work. Besides, after certain point you just have diminishing returns when working so much for so long without sleep. You don’t the other programmer to spend his morning correcting all of your code that you wrote in an incoherent sleepy haze.

Find a tool or engine that most of your teammates are comfortable with and go with it

IMG_3775I see that unity for obvious reasons is a popular choice at most games jams now and Flixel as well, although flash is slowly becoming  extinct. Keep in mind that not everyone on your team needs to use the tool or interface. Had I done this game jam
again I would’ve probably had only one or two of us actually use Unity and rest of us work within our respective programs.

For example, I did most of my scripting without using the full build that everyone else was using. One the benefits of using unity is that it is component-based, so you can write your own scripts and just simply attach them to any object in game.

If I did a project in Unity again, I would be sure to have one level designer who puts the project together – the art, the code, the music, while the rest of us continue  lugging away on our the work we’e been giving.

Come prepared

I’m most comfortable when using two monitors so naturally I brought myIMG_3774 second. I would’ve also preferred to just work in XNA or the Unreal Engine, but sometimes it’s good to take a step outside of your boundaries and comfort zone.
I learned quite a bit from others who are more experienced than I, so not all is lost. I did have frameworks completed in the two tools mentioned earlier, and when you’re on a tight time budget, such as only having one weekend available to  program, having a framework you’re comfortable with is essential.


You can play A Pulse In The Dark right here. 

I’d also love to hear about some of your game jam survival tips!



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.