A short introduction

In 2015, I was invited to do a talk at the Nordic Game Jam for the less seasoned jammers, focussing on the do's and don't's that could help people have a better jam experience. Now, with a new jam season under way, I decided to turn it into this article, based on my own experience, sparring with colleagues and a bit of Game Jam research. Among other things, I found a survey done after a Ludum Dare a few years back where some of the responses really surprised me. The survey concluded that:

27% were not happy with their games
Almost 70% reported that they had to cut features or simplify design
Almost 40% ran out of time before they could finish
33% said that their game had no sound effects and/or music
29% said that they did not finish their game

Judging from this, it seems to me like a lot of people are having unsatisfying jam experiences. I mean, if you go to a game jam hoping to create a great game and end up dissatisfied with what you did - perhaps even failing to finalize your project - that would be a bad experience. However, I have a pretty good idea why this happens so/too often, and I have some suggestions on how to avoid this and have happier jammers who make more (and perhaps even better) games. So here goes – A Recipe for Great Game Jam. I've added suggestions for "Jam Spice" and other "Additional info" to boxes like this one below to seperate these from the main text - but I hope you take time to check out these info boxes as well :)

Measure the right amount of time

Jam time: Before you start jamming

A surprisingly common jam mistake is failing to realize how little time you actually have. When people ask “What is a game jam?”, the usual answer is along the line of: “A game jam is an event where you join a team to make a game in 48 hours.” Even the Nordic Game Jam (the world’s biggest on-site jam) has this description in their FAQ. There is just one thing... It's (often) wrong. Let's take a look at the NGJ as our example.

Friday, there are a lot of talks – which is awesome – ending with the keynote at around 7 pm. This is followed by Jam-kickoff at around 8 pm. Usually, this is where the jam theme is revealed and it takes about an hour. Then the team-building process starts which takes another hour or so. At the other end of the jam, submission deadline is at 2 pm Sunday afternoon, which means you should be finished a little before that time.

This leaves you and your team with around 40 hours, not 48. That means – compared to the usual jam description – you are already down 20% of your estimated development time before you even get started. If you then factor in time for 6 hours to sleep, eat and clear your mind each day (which I would strongly advise you to do), then that is another 12 hours gone. This leaves you with 28 – not 48 hours to create your game. That is almost half of the scope of the description, which is something you really need to take into account if you want to avoid being part of the 29% did-not-finish statistic. Rather, plan for 24 hours of development time and then add a nice bonus feature to your epically polished (albeit small) jam game, than having to cut features Saturday, because you suddenly realize that you have 28 hours, not 48.

Take 1 cup of motivation and add 1 team

Jam Time: Friday around 9 PM

Creating or joining a team is most likely going to be one of the first things you do during a jam and it's one of the most important. To have a good experience, you really need to be part of the right team.

I know it's sort of a cliché, but before going to a Game Jam, you should really try to figure out why you're going. You might say, “I just want to make games”, but in that case I'd challenge you to think a bit harder, because most likely there are more nuances to your motivation.

Is your primary goal to have fun? To win? To learn? To grow your network? Are you hellbent on a specific genre? Do you want to experiment? What skills do you want to pitch in with? and so on... (and if you, like I, see yourself mainly as a game designer, don’t be afraid to offer to pitch in on art, sound, testing, getting coffee (!) etc - sometimes going out of your comfort zone is a key part of the whole jam experience).

Now, once you know why you are jamming, what your ambitions are and what you have to offer, you really need to be honest about that with your team. Best case scenario is that you all agree and head off to jam. Worst case: You figure out that you want different things and you go your separate ways to form other teams. It is way better to figure this out at jam start, than halfway through.

When I did the “Recipe for Great Game Jam” talk at NGJ15, I had the crowd answer my own anonymous web-survey, which included a multiple choice of why were part of the jam. These are the results: (which to me seem to explain why the vibe at jams are uniquely positive and people are almost always ready to help each other out, including other teams).

(only) 2% were there to win
2% didn’t know
11% were there to make a great game
15% to challenge themselves
15% “to have fun, i guess…”
15% to meet people and grow their network
40% to learn and improve their skills

As a final team-building note, jamming is really hard in big teams, because with bigger teams comes demand for better communication for the team to scale efficiently. I would suggest going for a team size of 2-4 people as a rule of thumb.

Carve out 1 idea (preferably fresh and unused)

Jam Time: Friday around 10 PM

Having found the right team, you – as a team – need to figure out what game you want to make. If this challenge is not tackled in a controlled manner, you often end up with either a severe case of Blank Canvas Syndrome or too many ideas pointing in all directions. The usual consequence of this is you spend way too much time doing jam ideas which leaves you with too little time to actually turn the final idea into a game.

In the initial concept phases (in jams, as well as paid projects), constraints are not a hindrance, but actually really helpful tools, when seeking to define the canvas you're working within. Remember the wise words of Donald Norman, who said: “Design is the successive application of constraints until only a unique product is left”.

At a jam, rather than trying to materialize an idea out of thin air, I suggest you start carving away your idea by narrowing down possibilities again and again using constraints. In a jam environment, your first constraint is usually the jam theme, which is not meant to be a hindrance, but rather a catalyst and tool to help you zero in on what will be your unique jam idea. Other useful constraints would be the team’s skill set – for instance, I've had some of my best jams in a group with no artist, forcing our team to seek other or at least simpler ways to express our ideas visually. Tech constraints, such as target device, number of players, art style, scope (because your team agrees that you actually want sleep during the jam) and so on. These and many other constraints that are easily defined based on the team's skills, hardware, ambitions and size, can really help you narrow down the room for ideas and help you save valuable time by not chasing ideas that are not viable.

Peel your idea, puré and let it set

Jam Time: Friday around midnight

Ideally, after a couple of hours your team has settled on an awesome game idea and perhaps you have even taken time to add some spice to your jam. Now, it's time to take that idea and peel away anything that is unnecessary for the idea to live. It should be kind of self evident that scope and planning is key to as successful jam, but – due to the time pressure – people have a tendency to skip this. But that is a really bad idea. Just a little planning goes a long way at a jam and I can tell you, it is way easier and more time-efficient to kill ideas as opposed to features you have already spent time designing (or even worse, implementing) before you realize that they are not fun, out of scope or whatever may be the reason for cutting them.

To me a good rule of thumb is to answer the following questions:

What is the core of the game?
Can we simplify our core to make it easier to build, easier to design, easier to use, easier to understand, without losing the core experience and relevance of our game?
What are the features we need for the core game? (At a jam, anything else is polish :) )
What are the features that most effectively help convey how we want the game to make players feel while playing it. (This is your nice-to-have list, which should also be prioritized on its own)

This kind of planning is essential to avoid becoming part of the “almost 70% reported that they had to cut features or simplify design” statistics. Prototyping, testing and cutting features are a normal part of game development and iterative processes, but at a jam you simply do not have time to repeatedly “waste” hours on precious code/art/sound that doesn’t make it into the game. So by planning the best you can and being honest about which features are truly essential (and prioritizing those), you can keep waste to a minimum - So I urge you to take some time carving out the core of your idea, before rushing into implementing it.

Often this is also a great time to get a couple of hours of sleep. Going to sleep, knowing what to build and then waking up with a fresh(er) mind to just make a final status check over breakfast to see if you can actually trim your idea even more has worked wonders on more than one occasion for the teams I've been a part of.

Constantly stir design and gradually add essential code, art and sound

Jam Time: Saturday from 7 AM

After a few hours of sleep and a nice breakfast (remember to eat!), you should be ready to start building your game. However, you should really remember to stir your game design and revise your plan ever so often. The sooner you can cut elements that you realize won't work for one reason or another, the better - because the less time you will waste. Also in my experience, even on small jam teams, it has been a great advantage to designate someone the “project manager”, so that it is their task to make sure that time isn't slipping.

Looking at the Ludum Dare survey, 95% reported that they did not use time-management techniques and at the same time, almost 40% reported that they ran out of time before they could finish their game and 33% ended up with a game without sound and/or music... So if you want a successful jam, you really shouldn't skip planning and resource management despite the time pressure.

Apart from making a plan, there's a few additional pointers that can help ease the process of building your jam game and help make it better.

First off, use known tools if at all possible. I mean, a 30-hour-ish window is tight for making a game. You don't really want to start learning new tools on top of that. Unless you are really looking to build up a challenge for yourself, stick with what you know tool-wise.

Secondly, when planning your tasks, you should prioritize getting the core of the game to work ASAP to confirm that your idea is actually both viable and fun. Then when it works, you can make it pretty. This way you are more likely to have (at least) a core game to show off at the end of the jam, but it will also allow you to test your game and gather valuable feedback over the hours that follow.

Lastly, remember: “if you don't need it, don't build it”. It might seem self-evident, but during a jam, you can save a lot of time by keeping in mind that a jam game is not supposed to be publishable right after the jam – it's more like a prototype to demonstrate a great idea and experience. With this in mind, you should consider whether scoring systems, win or loose conditions, progression, pick-ups and power-ups – all the things we take for granted in games – are actually nice-to-have in your jam game. Consider this - does the core experience in Super Mario lie in the power-ups, timers and coin collection, or is the core game about simple platforms, jumps and truly satisfying controls? (That felt almost rhetorical).

And maybe you end up with time to get coin-pickup into the game, but that doesn’t necessarily mean that you also need the coins to have a function (or even a counter for that matter). That would be even more polish - during a jam nice-to-have features should not/does not result in new need-to-have features.

As an example, our team at NGJ 2013 won “most innovative game” with a game (Twisted) that had no meaningful scoring system, no win or loose conditions implemented and a forced (timed) progression, so that we were sure to make it through all 4 levels within our 2 minute presentation. However, the core vision of the game was still clearly present and communicated, and our 3 man (1 programmer) team would have had no chance of finishing the game had it not been for brutally pushing feature after feature into the nice-to-have pile.

Taste and stir design. Polish to taste.

Jam time: Saturday around 8 PM

Around this time, you have probably been building away for some 10-12 hours, following your plan perfectly :) (if you are even faster - thumbs up! you’re awesome!) Now, this is the suggested timing to aim for in regards to having a first playable prototype (which may be rudimentary) – and once you do, test it. Test it yourself and on other people too... Just because you get it, doesn't necessarily mean other people do.

In the Ludum Dare survey, 71% reported that they did not play test their game. That's a lot of people essentially flying blind. It may end up working out without testing, but that requires a lot of either skill, experience or luck. My suggestion is to remember to test your game, analyze the results and revise your design the very moment you have something playable. Ask the teams around you to take time for quick test and to give you some constructive criticism - most likely you are surrounded by skilled developers, who - in the true jam spirit - are willing to help if they have time - and as noted, most people don’t jam to win. Then, when your first test results are in, you can plan for the remaining 12-ish hours of production you have left until you have to have a final build for submission.

Testing your game will give you extremely valuable information for both improving your game and your presentation – and by testing early on, you actually have time to use your findings to help direct your final implementation. From this point on, simply rinse and repeat the process of building, testing and revising design as many times as possible to make your game as polished as possible.

Providing your early tests are positive in regards to the core experience, this will also leave you with a significant amount of time to polish your game, which is something that can have a profound impact.

If you have time over your morning coffee (or whatever makes you tick), I would suggest watching this talk by Jan Nijman (Vlambeer) on “The art of Screenshake” which has a interesting showcase of polishing the look and feel of a simple core game.

Pour into a nice game jam jar, label it and show it off!

Jam time: End of jam, Sunday afternoon/evening

Often, a rather overlooked part of game jams is the presentations, which are (to me at least) about the most fun part of the whole experience. This is when you are done with all your hard work: You can relax, see what awesome games the other teams have created, show off your own game, vote for stuff and generally have a great time with the people with whom you have just spent a whole weekend making games.

However, in my experience, a lot of teams seem somewhat taken by surprise by the fact that they need to present their game and quite frankly fail to prepare - and as Benjamin Franklin said: “By failing to prepare, you prepare to fail”. You've just spent two days of your free-time slaving to create the most awesome game you can in no time at all. Then, if you ask me, you also owe it to yourself (and your game) to give it a proper send-off.

Often, the presentations are short. At the Nordic Game Jam they are usually 2-3 minutes as sometimes there have been almost 200 games made and presented. So you really should know what to do in that time, so (again) make a plan as a team. Do we have the right hardware and can we connect to the projectors? Who does the talking? Who demo’s the game? How do we best demo the game? I really urge you to figure out all these things beforehand, because otherwise your presentation time flies right by and, honestly, that's a waste of your efforts.

And a last, all-important note on presentation (for the sake of both you and your audience): For those 2-3 minutes on stage, you need to believe in your game. Show us what you’ve made, strut your stuff and don’t apologize for your game’s shortcomings. All jam games have shortcomings. That is not something you need to apologize for. So instead of telling us what your game is not or could have been, if only…. show us what you’ve got and be proud of it. If you made it thru the jam, submitted a game and actually made it on-stage to present, you are allowed to be proud - because it is hard to make a game in 28 hours.

So... That's it. A recipe for a wonderful jar of game jam - I really hope you found it interesting and that this article might help improve the jam statistics just a little bit :)

And a big thanks to the kind friends and colleagues who have helped out by giving their input.

Happy Jamming! (See you at NGJ17)

- Anders Rauff-Nielsen

Twitter: @andersrauff

Links section

(As promised) Links to Nordic Game Jam games I took part in creating, as well as relevant videos and related sites:

E.V.I.L. (a mobile Conspiratory Read-em-up Action Puzzle game)

Sneaky Elvis (a Rythm-based stealth puzzle game - won “Best audio” and “3rd place” at NGJ15)

Sneaky Elvis Game play video/review (He actually makes it thru in the end :) )

Twisted (Experimental arcade-game deconstruction - won “Most innovative game” at NGJ13)

BoingWauw (An experimental social co-op communication/memory game, where you make and intuitively translate abstract sounds into abstract images. As you progress, the procedurally generated sounds and images become increasingly complex - won “Jury’s Choice Award” at NGJ12)

A link to Funday Factory

Links to Widowgrove and my Widowgrove Facebook page

A link to Emil Kjæhr and Jacob Korsgaard’s Stalagflight (NGJ 2013)

A link to Kyle Gabler’s Global Game Jam Keynote from 2009

A link to Jan Nijman’s (Vlambeer) talk on “The art of Screenshake”

A link to Luke Spierewka’s webpage

A link to the past (just for good measure)