7 Tips to 7-Day Game Jams

Making games in a week isn’t easy. As someone who has built around 30 different games in less than a week, I've encountered a lot of counter-intuitive hurdles to working in this timebox.

The good news is that a week is perhaps the best amount of time to gauge a design. It offers enough time to execute the primary details of the game, while giving some space to pivot and polish as necessary. While every team is different (or solo developer for that matter), a couple of days just isn’t enough at times to really execute a design, and often a month leads to over-polish or over-design. A week keeps everything in check. And a weeklong jam will teach you a lot about your own game development; game jams really accentuate your abilities as a developer in interesting ways.

All said and done, here are seven tips for building a game in seven days:

1. Count your hours. Bank 20% for safe-keeping.

Executing in a timebox is tough. Being cognizant of time is critical to the success of your jam, and you should plan accordingly.

A weeklong game jam totals 168 hours from start to finish, but you’ll be using a subset of that. With a normal amount of sleep that’s maybe a 110 hours max. Reasonably, it's even less time than that if you count all the important human things you do daily. You’re going to eat, right? You have kids? School? You have loved ones that care about you? Don’t neglect those things (see Tip #6).

Once you figure out how much time you have, allocate the first 80% to actual development time, and leave the last 20% empty. While this seems like a lot of time, it’ll become really important for several reasons:

You will slip. Game development is hellbent on slippage, and even the most disciplined teams will find ways to fall behind.

You will change your design. You’re doing this to experiment with design, and with that you’ll change what you started, and that takes time. For every X and Y we’ll have a Z as well.

Things will go bad. It's rare anything in game development isn’t turbulent. Development is a parade of problems to fix, not smooth sailing.

You’re a human being with competing priorities. There’s always a dog to feed or a library book to return. While you can prepare for some of these things, often the unexpected will happen.

Unaccounted time is in every schedule. You’ll always forget to budget time for a main menu or a mute toggle. By buffering development you’re giving yourself runway to be successful.

Be honest with yourself and how much time you have to dedicate:

2. Prepare as much as you can before the jam even begins.

There’s quite a lot you can do before the jam begins. Here are the biggest ones:

Get your team together. While it can be fun to slap together a team after the jam starts, it’s better to get a good grasp of your team and what each member will be doing, and the time they can commit. If you’re going solo, make sure you’re committed to your jam.

Get your code base and tools together. It's a lot easier if you’re familiar with the tools and frameworks (especially if you’ve built them). Make sure you stick to the rules of the jam or sprint to ensure you’re not bringing anything into play that might be considered foul play.

Read the rules. Then read them again. Jams and sprints often have a bunch of small rules that can be overlooked. It's important you know all of them so all your hard work isn’t inadvertently disqualified. You should know the due dates and process for everything related to the jam. Don’t break the rules!

Clear the calendar. It's incredibly easy to schedule new events over your jam time. If you need the maximum time, let others know you’ll be busy.

Human basics. Ensure you've got all the basics down. Food, water, medication, electricity, internet, and a working computer are all great. Any time you can prevent going to the grocery store during the jam is a huge plus.

Computer basics. Don’t do any crazy software or OS upgrades before the sprint; nothing is worse than starting your jam debugging your machine.

3. Theme announcement, distillation, scheduling.

The theme announcement can be incredibly stressful, exhilarating, confusing, and exciting. A theme sets the entire tone and design for your game, so it rightfully earns the reaction you give it. Your ability to execute on theme is really important!

After you calm down a bit, begin to think about game ideas that immediately come to mind from the theme. Write them all down, and if any are too long, attempt to break them down even further.

By dragging out all the verbs, nouns, and feelings that you derive from the theme, you get a palette of direction to go from. Think about what these words and phrases mean to you. Think about mechanics that tie into these words.

Now it's time to design. Usually by this time some ideas start to flow, so get that brainstorm going with your team on how the game works. Think about art styles that match the mechanics and theme. Think about music and sound and how they complement that art and mechanic. For each element of design, think about how difficult it would be to execute. Some art and music styles are incredibly difficult to execute in sprints, so think about your strengths and weaknesses as you plan. Make good risk in design, don’t box yourself into the impossible.

Got the game? Time to schedule.

Within the first few hours you should know the general direction of the game and how your time is allocated between you and possible team members.

By making a plan, everyone knows when things are due, and it minimizes the chances of blockers or bad overlaps in work. Efficiency is crucial in limited-time events. Your ability to plan well will give you a much higher chance of reaching success.

Example schedule

While this schedule doesn’t work for everyone, this is basically how I would execute on-time for several of my projects.

4. Don’t be afraid to take risk. Learn to embrace failure and pivot.

Things don’t always feel right in game development, especially when you’re working on new concepts. If you have time to pivot and have purpose to pivoting, do it. We often think something is more fun or interesting than it actually is when we plan, and not being dead-set on the outcome is important. But, you should do a few things before doing a hard pivot:

Get buy-in from your team. Obviously communication is really important.

Get buy-in from others. Sometimes execution is just slightly off, or not even at all (you’re always your own biggest critic). Talk to others if something doesn’t feel right. An outsider's perspective is incredibly valuable.

Fork, don’t replace. Try to make a step toward your new direction, but save a backup in case you need to go back.

Even if everything is going perfect, massaging mechanics is some of the most interesting work you’ll do in a game jam. Make sure you aren’t forgetting to tweak and modify your original design. Continue to think about how you could improve your game as it comes to fruition.

5. Facilitate good communication.

Good communication is not just about your internal team, but also the greater jam. Your jam team should know how they’re going to communicate and share content ahead of time. Teams shouldn’t be relying on finding a Dropbox, common email, or GitHub repo while the jam is already in action. Think about where you’re facilitating the bulk of your communication. Slack? Skype? Google Hangout? Ensure everyone has buy-in and is good with the medium of choice.

Sharing your jam in-progress is a great way to give developers and players insight into your design and development progress. Try sharing screenshots, quick builds, and pics of your team hard at work. Even if you don’t see the immediate value of it, other devs thrive in knowing that they’re in the company of a hard week’s work, and so will you. Likewise, you’re building traction with players and getting them excited and supportive.

6. Be a human being. Keep morale positive.

The pressures of completing a 7-day sprint are really high. In nearly every situation it doesn’t make sense to skip sleep for three days or forego eating to get a few extra hours of programming. Beyond being grumpy and terrible to work with, your work will be compromised dramatically. Your priorities should be aligned with your own needs, first and foremost, then to the jam. Plan effectively. A week is a good amount of time to execute.

Jams are supposed to be fun and engaging. While often jams are a competition, by no means should competition get in the way of you being nice or helping another team. Game jams live and thrive on developer comradery. Both inter- and intra-team drama can be frustrating. The unexpected always rears its head during short development sprints. The best mindset is to keep calm and adjust appropriately. Ultimately positive attitude, patience, friendliness, helpfulness, and teamwork will get everyone to the finish line in good spirits.

7. Learn from what was accomplished. Apply to the future.

While jams are a great way to see if mechanics work, the larger takeaway might not even be a finished game. Game jams are a great time to learn about yourself, others, and what you can accomplish in a short period of time. You might have accidentally stumbled upon a mechanic that you’ll use in the next great game, or you might have met a new artist or programmer that perfectly jives with your style. Often we learn what we’re really good or bad at in a pinch (for me I’m terrible at building levels quickly, but I’m really fast at comping and programming UI). Sometimes we make human mistakes, like forgetting to delegate who was supposed to order pizza, or running out of coffee and having to send someone out to the coffee shop. As you do more jams, you get better, and as you begin new games you’ll already be ahead of where you were just a week ago.

Document and write your outcomes. Share them with the jammers, and bring your experience to others just getting started. It helps you digest your game jam experience and helps others process theirs.

Follow us on Twitter to keep up-to-date with our weekly blog posts.

More articles you might like:

Hello, my name is David Finseth and I am a Technical Artist at Synapse Games. I work across multiple games to create visuals that require some technical and artistic components. A big part of my job is working on particle effects for our mobile games. I am very passionate about this work and wanted to share my process and some tips for creating these effects with you. Particle effects are a unique tool that can add interactivity and responsiveness to your games. They excel at creating a lot of movement and impact. Particle effects can be used to create magical fireballs, swirling dimensional portals, or for directing the player's attention to a glowing treasure chest. First, I am going to break down the process that I go through when I make particle effects in Unity. Later I will go over some technical tips and tricks. Most of these examples are from work that I did on the games Spellstone and Animation Throwdown. The Process Breaking down the requirements: The first thing I do when I start to make a particle

pictured: Thumper Dark Souls is more likely associated with anguish than euphoria as a series, but it -- and other notoriously difficult games -- are where we can find some of gaming’s most pleasurable moments. If you work through your urges to throw your controller at a wall, you might be lucky enough to experience the joy that keeps us all coming back for more “YOU DIED” screens. We’re going to delve into what leads to these experiences, why they feel so good, and how they can be designed. That feeling? It’s called “flow.” Named by Mihály Csíkszentmihályi in the 1970s in response to interviewees describing the feeling as being carried along by water, flow is a deep, pleasurable immersion in the activity you are engaged in. Most commonly used in reference to creative pursuits like painting or performing music, this experience is absolutely found in games as well. To find yourself in a state of flow, first there are some parameters: You know your goal You know how to accomplish your goal You are receiving feedback

At Kongregate we have the privilege of working with a wide variety of game developers, many of whom are enthusiastic to open up their game pitches with an x-statement. X-statements attempt to summarize a game succinctly using two subjects, often referencing other video games, mechanics, art styles, or popular media. Very often they look like this: “My game is Crossy Road meets Mad Max.” “What if Towerfall had Dark Souls-style sword combat?” “I’m working on a game that is Cooking Mama meets Elite Beat Agents.” Developers view x-statements as a thesis to a game pitch. Well-crafted x-statements can evoke both a sense of gameplay and market positioning, transporting a reader to really understand where your game is going. Likewise, a poorly crafted x-statement can be damaging, setting the wrong tone and ultimately damaging the concept or creating confusion around what is being created. As a publisher, x-statements give us a glimpse into the mind of game developers. An x-statement says a lot about how game developers think they should be marketing a game to their audience. It shows succinct