Login Register
Email RSS Feed Twitter Facebook YouTube

How to win a Game Jam

How to win a Game Jam

Dave Sharp currently works with Binary Asylum, but he is a games industry legend and has forgotten more about making games than any of us will ever know. Here’s his thoughts on how to win a Game Jam. This advice isn’t just for Game Jams, following these tips would make any games development process better.

Writing games is hard. Writing games that people want to play is really hard. Games development can take you through extreme emotional states: euphoria when everything is going well, edge of the abyss when it isn’t. Game Jams like the one last weekend in Scotland provide those who aspire to be in the games industry with a snapshot of that experience – all in just 48 hours. That compression of time and the need to create something that others will appreciate can make for a compelling rollercoaster experience for the participants.

Reflecting on last weekend’s event I was trying to decide if there was anything radically different this time around by comparison to last year. Other than the number of participants I think the answer overall is “no”. I saw the same expectant, optimistic and enthusiastic crowd at the start of the event. Once the theme was announced I saw the same basic mistakes take place with a large number of the teams – everything that goes wrong for a team at these events can be traced back to mistakes and poor decisions in the first 2-3 hours. I saw some awesome creativity in action with some very talented individuals driving their teams forward. I saw some great ideas come to fruition at the end of the event and it’s been fun to play everyone’s games over the past day or two.

Having won several game jams in the past I think there are definitely some key factors to doing well. Not everything can be predicted or negated; you just don’t know what the situation will be once the theme is revealed. I do think that there are scenario’s that can be avoided with some basic rules though:

Don’t rush to start: It’s a common sight to see several teams at a game jam that have very quickly come to an idea and launched into development within an hour of the start of the event. It takes time to get to a point where the idea makes sense and is achievable in the time and with the team available. My general thought is that we need to allow 10% of the available time to be consumed with the basic concept. This is kind of like the pre-production phase of a regular games development and is essentially about de-risking what we are doing.

Roles and Responsibilities: Clearly define who is in the best position skills wise to deliver what aspect of the game. Egos need to be put to one side – it’s a simple decision based on experience and background. I still see teams where one person “gets there way” by forcing the team to accept them as the lead coder or artist when it becomes clear that another member of the team should have filled that role. I just don’t allow this – my team knows who is making a decision about what aspect – it’s non negotiable.

Keep it simple: I try to avoid certain kinds of games concepts that will need complex tech, 48 hours just isn’t enough time to get to extensive collision detection or AI into a working condition. I always look for games that have minimal amounts of either of these two techniques. The trick is to have one core mechanic delivered beautifully rather than a bunch of features done averagely.

Stick to the plan: Firstly you need to have one to stick to. A lot of teams “wing it” from the beginning, but this will only get you so far and then you will hit problems. When I’m responsible for the planning for the game jam team I tend to plan out 8 hours in advance and create breakpoints where I can examine where we are and what the issues are and make a change if necessary. It’s usually around 5 x 8 Hour plans over the course of the event. Whatever the plan is we stick to it no matter what but I also give any member of the team the right to yank the emergency cord at any point if something is becoming a problem. The thing here is to change the design to fit the code available, not to keep pressing the coders to meet the design.

Manage needs and expectations: This might be an odd one, but over the course of my 25 years in the games industry I’ve come to recognise this as a particularly powerful skill to have in a producer’s arsenal. Needs and expectations are twofold. The team has needs and expectations itself. It needs to have an understanding of everyone’s role; it expects to have something to show at the end of the event, it possibly expects to be in the running to win the event. All this needs managing and keeping in check. Other people’s expectations also need to be managed. Over the course of the event there will be numerous requests for information on progress, sometimes by other teams, other times by the organisation around the event. The message the team puts out can often be very positive and create a feeling of excitement within the team. If misjudged the message can be something less than positive and can engender a different feeling altogether. When anyone comes asking I like to be moderate with our teams message – middle of the road – it always seems prudent to be cautiously optimistic in the message rather than give everyone the idea we’re about to bring the house down with our game.

Attention to detail: Small details make all the difference. I try and judge things on a risk versus reward basis. If the team is contemplating something in the art that I think will really draw the judge’s attention and has minimal time overhead it’s a no brainer. Conversely a feature with several hours production time that has no guarantee of standing out is pretty much a no-no. I favour small spot effects in the art, nice lighting, the use of contrast has been particularly effective in winning game jams. I don’t think it’s onerous or difficult to focus on a small number of cool and cheap (time wise) features to really make the game stand out at the point of judging. When the game design is agreed I often go straight into looking things like cut-scenes, menus, social network integration and high score tables. These things really make a prototype feel like a game in a bigger sense.

In summary, I think the notion of a games jam and the opportunity it represents for students to mix it with professionals is an extraordinary one. No other industry sector has anything comparable although I suspect that one or two other sectors are waking up to the idea. Students can get a massive infusion of experience and technique from those of us who have been doing it for a while. For those of us that have been doing it for a while it’s a pleasure to work with people who are free from the cynicism that sometimes accompanies mainstream game development. Personally I love the idea of working with students at this level to try and raise their abilities, their aspirations and their fundamental capacity to enter the industry and have their dream career. If I could wish for anything it would be that more professional games companies would involve themselves with sponsoring and supporting these events. Ultimately it has to be a very valid way of developing and identifying the new talent we desperately need as an industry.

Dave Sharp currently works with Binary Asylum and you can follow him on Twitter too. He once again mentored two award winning teams at the Scottish Game Jam 2012 with Shplem and SpaceScape


Leave a Reply

Skip to toolbar