Industry veteran and frequent Game Jam winner Dave Sharp talks about where you should be throughout the weekend.
48 Hours isn’t a lot of time. Well it is and it isn’t. The passage of time when you’re working to a tight deadline – like a game jam – is either something that you manage or it will come back to hurt you, big time.
I’ve always tried to block time out over the course of a game jam event.
The first four to six hours are essentially thinking time. Take the theme, play with it, add a twist, review it with the team and the do it all again. Typically this means burning through four or five initial ideas with ideas six, seven and eight starting to look like viable prospects. In my head I’d like the idea we are going to run with agreed by around midnight. I also decide on what our plan b will be. If our game is not shaping up I want enough time to pivot onto something else. It might be just a reduced version of the game design or in some instances it is actually a different game altogether.
Midnight to around 7am on day one is the time frame for creating an initial prototype. We resolve all the tech issues, we create a single level (which will become the training level in the final game) and we develop our content or level building process. The process is key; once established we can produce a large number of levels at high speed to give us some choice as to what goes into the game. Taking a proper break around 7am for some sleep, food or some fresh air has always seemed to make sense. At this point I commit to plan A and ditch any notion of plan B – we’re now solely focused on our main game design.
Coming back from the break is about creating a bulk of content that we will edit together to form the size and shape of the game we want to submit. By around 4pm at the end of day one I want to be sitting playing a very rough version of the final game. There should be a menu system with basic selections, a simple training level and the initial selection of playable levels in the game. It’s likely to be buggy, unbalanced and without music but essentially working.
The event at this point is now 50% complete in terms of time but the framework of our game is 100% complete. I like this ratio and it’s usually the point where I know we’re looking good or up against it time wise. 6am on the second morning a new set of activities kicks in. Over the course of the night I’m conscious that we need to get our code clean and really limit the amount of new code added. 6am on day 2 represents (if possible) a code freeze so we can finalise what we have. This also the first time I start to consider what’s required for submitting the game to the event website. If progress is good at this point and our code base is solid I often see what bells and whistles the team can manage to improve the product overall. A lot of the time this is extra work in the tutorial or adding cut scenes between levels to convey a simple story line.
The last mental checkpoint is around midday on day 2. We need clean code and the only thing we are concerned with is balancing issues and being ready to submit our game with time to spare.
By way of example here is a game play video of a game called Shoal developed by a game jam team at the Scottish Game Jam in 2011.
The game was developed under the exact process above for me represents a very good outcome for a game developed in 48 hours. Its processes and planning that can vastly change a team’s fortunes at a game jam event and I often see it as being the activity that the team engages in that makes all the difference.