Postmortem: Summer Game Jam

During the first two weeks of July, we had ourselves a game jam at work.  It was a truly awesome experience, one that every game studio should make time for at least one week out of the year.  There was so much renewed energy, so much fresh air, and so many lessons learned in such a short time.  All in all, it was invaluable.

Our Method
The game jam event was announced without warning at our weekly meeting early on a Friday.  Basically, we were told that Windows 8 is a big deal, so our studio should check it out.  For the rest of that Friday, we were given a few setup tasks, and even fewer rules:

1. Wrap up "real" work:  Basically, to put everything on hold for a week or two, we needed to get it wrapped up nicely.  This consisted of backing up work in a safe place, getting stuff checked in, and otherwise making sure the "real" work would be there when we got back.
2. Divide into teams:  Team building was given the most rules of our game jam.  We needed two to three programmers per team, and teams could have up to six people each.  We were also encouraged to work with others we don't normally work with.  This gave us about nine different teams.
3. Install Windows 8 and tools:  This task is fallout from the core goal of our game jam:  Each team was going to make a Metro-style app for Windows 8.  That was our only development rule, so it was important to get the environment and tools ready for Monday.

Initially, we were given a single week, with the possible extension into a second week depending on the studio attitude.  As I mentioned before, we went for the full two weeks, focusing on a playable prototype (while it wasn't required to make a game, every team made one) during the first week, and the second week was all about "finishing."  At the end of the first week, we had a quick presentation of each team's progress.  The second week finished out with every game playable on our meeting floor and a bit of a party. 

In my case, we had a team of six (three programmers, two artists, one designer).  However, the first week was also the first week of July, so two of our team members were out for half the week.  We had decided to work on a simple plane game, where you build a plane and it flies differently depending on the parts used.  This core concept was the primary focus for the first week, with little to no focus on the gameplay of actually flying the plane.

With a four-person team (two programmers, one artist, one designer) during the first week, we were really able to keep communication solid, open, and smooth.  With two programmers, we were able to divide tasks up completely - I handled the plane building, while the other programmer focused on flying the plane.  Our artist kicked ass, and our designer found some critical flaws early on by mocking up the build scene in Excel.  We had a strong finish for that first week.

[Quick side note:  We decided to use HTML5 and Javascript for our game, which none of us had used before.  This decision was largely based on the opportunity to try out new things, but was aided by the example code available online.]

The second week didn't go nearly as well for us.  With a third programmer and a push to include combat, we had a fair amount of work ahead of us without a clear division of work.  I was delegated to the user interface, the flight programmer continued tweaking the flight model, and the returned programmer volunteered for getting the enemies in.  It seemed like a simple division, but it quickly turned into a tangled mess.

With each of us working on the game scene, we stepped on each others' toes a fair amount.  Our returned third programmer hadn't had a full week to approach Javascript, so his ideas for an enemy architecture were based on incorrect assumptions.  All in all, we had me trying to grab any task available, and two programmers working on overly complicated systems for such a short development time that didn't have anything to give.  Once the basics of these architectures were finally put together, it was Thursday, and the code was a convoluted, overcomplicated mess.  By Friday, our enemies were shooting, but they weren't visible.  At least the UI was good and solid.

The Good
Let me stress just how great of an experience this was.  Even though our game ended up crashing and burning in the final hours, we learned such an invaluable amount through this process.

We learned the importance of enabling designers as early as possible - our designer was far too often spinning his wheels with little to work on while waiting on code.  If we had geared ourselves toward getting him set up, he would have had content churning out consistently as we got the rest hooked up how we wanted.  In short, figure out what the designers need to give you and how they'll do so, then build functionality and architecture to use that input.  This will get programmers and designers working in parallel.  This also works with artists, by the way.

Speaking of artists, just let them play and make as much content as they want.  While you may not be able to put everything into the game, artists seem happy to just keep "arting" away as long as you do your best to show off their work in game.  This worked really well for us, especially since the artist working on the build scene sits at the desk next to mine.  Whenever he had something he was happy with, he was able to grab my attention for a moment to make sure everything would work in game.  Alternatively, when I needed him to make sure I had everything right in game, he was right there.  So there's another lesson - keep artists and programmers near each other when they're working on related tasks.

As for programmers, it's important understand scope and the goals at hand.  Focus on what the content of your game is, why you're making it, who for, and otherwise get into the mindset of the designer every once in a while.  Don't hold onto complicated gameplay systems that are not fun or understandable for the player.  Don't complicate your architecture when the lifetime of your engine is two weeks.  All in all, build the right software for the task at hand.  If that task is a game jam, forgo writing perfectly correct code for code that works and takes half the time to implement.  If the product of your game jam is to be further pursued as a full product, you'll probably need to rewrite everything anyway.  If you're building something to last, that's when you write code to last.

Overall, this game jam was a blast.  It was a breath of fresh air and the boost in the team's energy was amazing.  Jamming got everyone excited and invigorated.  You could feel the difference throughout the studio, and every team member felt vital to and ownership of their project.  That's just something that doesn't happen as much on large products.  Quite frankly, it was all about having fun.

The Bad
Part of our game jam involved installing the Windows 8 preview.  This was to check out just how well everything we use for "real" work plays in the newer environment, as well as to just jump into the operating system and get some experience with the differences.  However, that meant that if we needed to go back to Windows 7 after the game jam, we'd need it to still be there.  Unfortunately, some of us used a slightly different installer that didn't give us the option to install to a different partition, wiping out our Windows 7 and upgrading it to Windows 8.

This would not have been so bad if Windows 8 agrees with all of our tools instead of one tiny detail - our internal test network doesn't acknowledge users trying to connect to our game (the real thing does work, though).  This meant that those of us that used that specific installer needed to reinstall Windows 7 and nearly every program under the sun (that's how it feels to reinstall all the tools we use on a regular basis).  Seems safe enough, but then there was the one person who reinstalled, but then was unable to connect to the network fully, keeping a developer from getting back to his day job for an extra week while working with IT to figure out the minute yet significant detail that wasn't in order during that installation process that flagged his computer as unsafe for the network.  In case you haven't guessed it, that developer was me, and that process was just not fun.  However, it did provide ample time to write about the game jam experience...

Another issue was the Monday after jamming.  You could feel the complete and utter lack of energy as everyone got back to their day job.  We went from a bustling, excited studio to one of morbid silence in the matter of a weekend.  The feeling was palpable, yet difficult to describe.  It's kind of like the end of The Graduate when Ben and Elaine get on the bus.  They're exhilarated and laughing, but then their reality sets in during the span of moments.  Their smiles fade, they try to hold on to that excitement, but it's futile.  Their life will come to some form of normality.  That return to normality from such a different world is jarring.

In Conclusion
While the fallout from our game jam cost me a week of work and a day or two of studio-wide regulation, the experience of those two weeks was incredibly inspiring and powerful.  It was a compressed learning experience that got the studio's blood flowing.  It let us shine where we wanted to, work on what we wanted, and really feel ownership over a product - something that just doesn't seem to happen on a large project.  Every studio should make the time to game jam - it really let's everyone play at game development and discover just what they're capable of in a short time, and that's just too powerful an experience to pass up.