Global Game Jam 2013

My first ever game jam is done and dusted. I'm at home and almost de-fatigued, so I thought I'd try to get my thoughts down on the whole affair.

What's a Game Jam?

Assuming it's not just gaming types who read this, I should probably explain the principle behind a game jam. Simply put, it's a collection of developers - both professional and otherwise - who get together in a shared space to build a game in a limited period of time. Some arrive as groups whilst others turn up with the aim of allying themselves to others when they get there. All are given a time limit and a theme and then the carnage commences.

The 'Global' part of this particular jam is just what it says - teams all over the world assembled in 321 sites spread over 63 different countries.

Welcome to Bristol

The start of the carnage. Remode had hats. We had T-Shirts.

My site of choice was the Bristol location - partly because it fell under the ExPlay banner but also because I knew some of the Remode guys would be heading there. So I fleeced up fellow Boss Alien, the annoyingly young Alex Parker, and headed West.

The time limit for this particular jam was 48 hours and the theme was rather theatrically revealed as 'heartbeat'. We poached Leanne from Remode, making her an honorary Alien for the weekend and team We Heart Dragons was born.

Most team sizes were between 3 and 5 people and there was an incredible diversity of both target platform and development environment. Most teams were also aiming to either plough straight through or, at the very least, crash at the venue.

Voluntary Crunch

'Crunch' is a word that gets bandied around in the industry quite a bit. It refers to that part in development when you've got far too much work to do in too little time. When you hit crunch, you work every available hour and, to save time on pesky things like travel, you sleep at your desk. Many jammers had brought sleeping bags and the meeting room floor became the dorm. As a side note, the fearsome array of onesies was something to behold...

Of course, I've been through this particular aspect of development myself before - the crunch part, not the onesie thing - and had no real intention of going through it again. Well, if the right onesie comes along, maybe... Either way, we'd gone against the spirit of the thing and had booked a hotel. The venue was locked up each night between 1 and 6, so that's when we'd call it a night and head back for some shut-eye.

The Plan

On the journey to Bristol, Alex and I had a lengthy conversation about how we hoped to pull this thing off. We came to the conclusion that ambition would be our enemy and we should keep everything very simple indeed. Stick to what you know you can do. Get a small thing finished and polished rather than go big and fail to hit the target. Keep It Simple, Stupid.

Okay, there may have been some talk about a central server and uploading replays and what have you, but the gist was that our game needed to be easy for us to complete so that we could polish it to a mirror shine. There was also a discussion about Use Of Resources - that is to say, what we could bring as a team.

We had a good spread of disciplines - he would do the code, Leanne would do the art and I'd do the design and chip in with the other two where required. For sound, we'd raid existing music online and utilise an 8-bit sound generator for spot effects.

Overall, it was a fine plan...

..one that was almost immediately discarded when we decided to write Dungeon Keeper in a rhythm action stylee.

The Game

The idea was to protect the Dungeon Heart from the marauding heroes. To do this, you have a couple of monster-summoning Generators and a liberal spread of pit traps. TBH, this is totally based on a version of Dungeon Keeper I started working on when the idea was first bandied around the old Bullfrog office. Well, not the rhythm action bit - that genre didn't exist back then - but you get the idea.

A title screen. The dragon breathes fire...

The game was largely based around the risk / reward associated with the monster generators. The longer you left them, the more power they would accrue and the larger the monster that would appear when you activated them. Shifting this to tie in to the heartbeat theme was simply a case of replacing 'time' with 'timing' - clicking on the beat would increase the charge in the generator and allow for bigger monsters. Clicking off the beat would reset the charge and clear your combo.

As well as generators, we had pit traps. If a hero stood on a pit trap, he'd fall to his death. But the next hero would see the trap and block it up unless the player managed to reset it beforehand. Again, this is something that needed to be done on the beat.

The final part of the design linked the beat of the heart to the amount of damage it had taken. As everything happened on a beat, this meant that the game speeded up as the player took damage. This could be advantageous, in so much as it allowed creatures to spawn quicker, but it also allowed everything to move around faster - including the heroes.

Development

Glowing circles = monster generators

The development process was fun! Alex and Leanne were joys to work with and I think we made a fantastic team. There were many occasions where one of us would implement something and call the others over, then spend the next couple of minutes either laughing or going 'awwwww' at the screen. It was a little concerning that the other teams didn't seem to be doing this.

Another good sign of any game's development is when you reach that point where you run the game to check out a particular feature or bug and, long after you've found out what you need to find out, you discover you're still playing the game instead of getting on with the next thing.

We did that. A lot. Say we wanted to check that heroes fell down the traps. We'd watch the first guy fall but we wouldn't quit out until we'd completed the level. It's clearly not the most efficient use of your time but it's a great indicator that something's going well with the design.

Critical Path

As with all projects, this one hinged on a couple of key areas. Without these features, we would not be able to make the game. As such, these were the first things we worked on. The main thing was the AI - pathfinding was going to be crucial and neither Alex nor myself had written a routine like that. Thankfully, Alex is a bit of a demon coder and the answer to whether or not we could pull this off was discovered only a couple of hours into the development cycle.

Do-gooder heroes with their torches. Bastards.

When it comes to project scheduling, the important bit is to first work out what it is that you need to do - essentially a comprehensive task list. You can then simply work out how long each thing will take, total it up and that will tell you if the thing is possible or not.

Leastways, that's the idea. In reality it's never as simple as that for two reasons - Dependance and Feature Creep.

Dependance is the Critical Path stuff I mentioned. Some tasks rely on others to have been completed beforehand and therefore can't be done in any old order. If your project has lots of Dependance, then these tasks can't be solved by simply throwing manpower at them.

Feature Creep is when you start adding things to the task list as you go along. In some ways this can be a good thing and is always prefaced with the phrase "wouldn't it be cool if...". More often than not it's just that this is something you didn't anticipate when you were doing the initial planning or one of your riskier tasks has thrown up a number of issues that you have to resolve. Either way, it's very important to stay on top of this stuff if you ever intend to hit a deadline.

Personally, one of the hardest things I've had to learn how to do is to ignore a really cool "wouldn't it be cool if..." because it just wouldn't fit - even though it would make the thing Massively Awesome. John Cleese did a fantastic talk on creativity one time, the general gist of which is that you have these two distinct phases. Working out what to do (being all creative and stuff) then Actually Doing It (implementing whilst not being distracted by creativity). Obviously this is incredibly relevant, especially when the deadlines involved are so harsh. Decide what you're going to do then do the damn thing. Ideally, given longer, you'd have a chance to repeat the cycle with the new information that you gained from the process - iterating on your initial design and making improvements.

Of course, you don't get anywhere near the time for that at a game jam, so you'd better make sure your design is up to spec first time out and that anything that poses a risk is resolved as soon as humanly possible.

The Final Push

At close of play on the Saturday night, we're in good shape. There are only a few things left to go in and the game is quite fun as is. A couple of bugs to sort out, but nothing that's filling us with fear. Still, we resolve to err on the side of caution and get in bright and early to give us the most time before submission.

Sunday even starts out very well indeed. We throw in a scoring mechanic and Leanne actually runs out of art to produce - resorting to making papercraft plans for the in game figures. With a couple of hours to go, it's all in the bag. I may even have tweeted something to that effect.

You know that bit in the movies where someone says "At least it isn't raining" or when Murray Walker announces that "surely nothing can stop him now!"? You also know that those phrases practically ensure that the very next scene is one of a complete thunderstorm or all four wheels spontaneously flying off the car in different directions.

That. That happened. That always happens.

For some inexplicable reason, the final two hours were spent putting out all manner of fires. Systems that had been working since the first couple of hours curiously exploded and refused to work, taking others with them. Alex and I got pretty frantic and I can only apologise to anyone who actually tried to talk to me during that time.

Thankfully bugs were (mostly) fixed, levels were authored and, with little or no testing, the game was uploaded to the site. Okay, not the site as, with however many thousands of games all going up at once, the GGJ site gave up the ghost, but we got ours on to the official ExPlay dropbox, which, we were reliably informed, would count.

Jammed

With that, all that remained was for the presentation of all of the games. At steak [sic] were two tickets to what can only be described as "Grill Fest" - some kind of meat-based trade show. Why? I'm not entirely sure, but it certainly added a bit of... gloss? No, sauce? Meatiness? - to the Microsoft Surface T-Shirts.

Under the highly-scientific, make-a-lot-of-noise based voting system, we came an honourable second, which I'm quite pleased with. I know I like the winning thing, but this was definitely more about sitting down with a couple of mates and having fun making a game - something that certainly shouldn't be taken for granted.

So there you have it. GGJ13 done and dusted. Hit up their site and try out our game. Leave comments (and possibly even how many points you managed to score) in the comments.

But don't click on Continue - just refresh the page instead for a new game :)