Global Game Jam 2015

This year was my second time participating in the Global Game Jam, and my third 48-hour jam overall. Along that storied history, I’ve learned a few things about how to be an effective and successful (defined here as ending the jam with a playable prototype that isn’t embarrassing for something made in a weekend) jammer. Here are some of those learnings, distilled into handy, categorized-tip form.


  • As soon as the theme is announced, write down every interesting idea you can. Try to work with a partner to cover more ground. Once you’ve got a long list of ideas you’re proud of, throw them away. Everyone comes up with the same obvious ideas at first. Track down the diversifier list, make a note of anything that piques your interest. By now, people will probably have started pitching their concepts and recruiting for teams. Notice how many ideas you came up with are pitched. If anyone has a unique take that livens up the idea for you, great, you have a potential teammate! If not, network a bit. Form a team based on personality compatibility, work ethic, shared tool expertise, whatever it takes. Nail down an idea when you’re good and ready.
  • Don’t make a narrative-driven game. Or, if you do, expect it to turn out as a mildly interactive short story. There’s so little time in a game jam, you really only have time to deliver an innovative game mechanic (potentially) or a compelling story (potentially), but not both. Can some teams pull it off? Sure, but to give yourself the best chance of success, especially if you or your teammates are new to jamming, pick one domain to excel at (potentially).
  • Make a multiplayer game. Everyone wants to make something they can be proud of – and hey, making anything in one weekend is something to be proud of – but seeing other people enjoy the fruits of your labor makes the effort all the sweeter. Competing against other humans is inherently compelling. You don’t have to generate a bunch of content to give your game longevity; competition is the original user-generated content. Again, this isn’t a hard-and-fast rule, just a way to get a leg up and improve your odds of success.

Team Formation

  • Find an artist, fast. At least at our location, the crowd tends to be extremely programmer-heavy. Art is just as much of a time sink as coding, is more important for convincing people to pay attention to your game, and there are fewer artists to go around. Do the math, then when the slower teams are busy doing theirs, bribe an artist or three to join up with you. If you are an artist, forget everything I just said. And join my team.
  • Find a sound designer. Same deal with artists, only even more rare. You might be able to get by with some free sound libraries and music, but you probably have enough on your plate. On the plus side, their work is usually less time-consuming, so they might be able to help out on more than one team at once. Also on the list as a reminder: don’t forget about sound!
  • Know where to draw the line on team size. A few is better than one, but in my experience, very large teams (more than 6 people) are disproportionally likely to fail. Too many cooks in the kitchen spoils the binary, or something.


  • Make something playable ASAP. A game jam isn’t an exercise in game development, it’s an exercise in prototyping. You want to run as many experiments as possible in the short amount of time you’ve got. Get to that step as early as possible, then iterate.
  • Don’t invest in “systems.” Every minute working on a feature besides the bare minimum required to test it is less time you could be working on another feature, and a wasted minute if the feature doesn’t pan out once it’s in.
  • Invest in time savings. Concentrating on the minimum viable product doesn’t mean you shouldn’t improve your code if it will save time. If you notice you’re doing some of the same things over and over, feel free to write a tool, refactor, whatever. The key is recognizing the right trade-offs. These three text popup classes all do kinda the same thing. Do they work? Leave well enough alone. Are you tweaking one and then spending more than a few moments updating the other two to match? Maybe it’s time to consolidate.
  • Add, don’t delete. There’re going to be a lot of moving pieces. Lots of wheels in motion. Lots of balls in the air. Everyone’s doin’ stuff, is what I’m saying. The last thing you want to do is make a destructive change that sets a teammate back. You want everyone firing on all cylinders. Don’t overwrite that asset you want to change, fork it and make changes to the copy. Don’t change the API of a class someone else is using, or if you must, give them a heads-up first.
  • Use source control. I mean, duh. It doesn’t matter what you use, just use something. The ability to merge changes and back out mistakes is invaluable. Don’t spend any more time on it than you have to, though. Making a new branch for every feature is probably overkill.
  • Pitch new ideas to your team. Bias for action is critical in a game jam. You need to be confident and capable enough to deliver without micromanagement. But please, before you unilaterally change the entire direction of the game, run your suggestion past the rest of the team. A fresh set of ears might help expose flaws you were too close to the idea (or too sleep-deprived) to see.


  • Don’t wait until the last minute to add a title screen. Once you feel pretty good about your core loop, put some time into game flow. At the bare minimum, you need a title screen/main menu, victory/end conditions, and preferably, a way to get back to the main menu to close the loop.
  • Build a standalone version early. Demoing in the IDE is amateur hour. Build a playable executable. Do it as soon as it makes sense so you can identify potential issues. Often, your resolution or aspect ratio will be different in a standalone version. You don’t want to hit export at the last minute, go up to present, and find half your UI elements off the screen.
  • Stop development 1 hour before the end. Throwing stuff in at the last minute is the perfect recipe for a broken demo. Plan to finish at least an hour early, then spend the rest of the time fixing bugs, polishing, and working on your presentation so you don’t sound like a doof.
  • Make your deliverable playable in a browser, if possible. This is particularly easy in Unity. It’s not necessarily a deal-breaker, but if you don’t want your game to end up in the vast forgotten wasteland of past jam games, keep in mind that 99% of people are going to pass over anything that requires them to download an executable.

If you only take one thing from this

  • Don’t be afraid to fail! A game jam is a grueling exercise, but you’re going to get something out of it – a cool prototype, lessons learned, contacts, or just a good time. You learn more from failure than success. Don’t go in expecting to lay the groundwork for a product, just have fun, do your best, and make something you’re proud of!
Bookmark the permalink.

Comments are closed