I’ve been doing game jams since before I could program anything, and there are a few things I’ve learned in that time. Here are all of those things:
1. Define your goals
Go around the table and ask people what their goals are. “I want to finish a game” and “I want to make something original” are different things! It’s not that you can’t work together, it’s just good to know when you’re both exhausted Sunday morning what everyone went into this wanting. Here are some great hard questions to ask some near-strangers on Friday night:
1) if you had to choose between something you thought would make people laugh, and something people would buy if we put it on sale, which would you pick?
2) If we have nothing finished on Sunday, when would you like to finish the game? Can you take Monday off? Or would you rather just chalk it up to experience and move on?
3) Is there a dream game you’ve always wanted to make?
2. Fuck that fucking theme
So you’re brainstorming with new people. You’re throwing out ideas. Suddenly you feel a little stuck.
What makes an idea good? What makes it fun? What if when you say ‘blue’ you mean what I mean but you really see a totally different color?
These are hard questions! If you ask your brain to answer them it’ll probably try to find easier questions to answer, like the one question that will 100% guarantee that you’re going to make a terrible game:
“But how well does that really fit with the theme?”
I discussed above defining your team’s goals. No one in that discussion is going to say ‘I want to follow all the rules.’ But in that difficult brainstorming moment when no one is sure if they should move forward or keep workshopping, the one thing that will be pretty easy to agree on is how well something fits with the theme. Suddenly all discussion becomes how to fit your great idea into the box you think someone has laid out for you.
Now, when people play your game, judge your game, decide to buy your game, none of them give a rat’s ass that you were assigned a theme of ‘harvest’ and ‘your body is a weapon.’
Back in my visual art days, we called this ‘assignment work.’ It’s when someone’s portfolio was obviously stuff they’d made for a class assignment, often with pages describing how their teacher had forced them to use graphite, and draw ‘something that grows in our backyard.’
The idea with game jam themes is to 1) prevent you from re-using old work 2) to make sure there’s some consistent thread between all games. Those are worthy goals, and you shouldn’t cheat at the game jam. But that’s as far as it goes: you need to pursue your own goals, and while a theme can help if you have no other preference for what to do, a theme should never stop you from making the game you want to make.
Another way to put this is that abandoning good ideas for ‘not fitting’ is putting the responsibility of making a good game on someone else. If the game is bad, it’s not your fault, you were assigned the theme of ‘lost at sea’ and so you made the game they wanted. Why, if your game is really a failure, surely you can sue the judges!
The worst thing about producing garbage that conforms to someone else’s requirements is that it feels so hollow. If you make a game where you eat hair to teach Andrew Jackson a lesson, and everyone hates it, you still made a game that one person wants to play.
So use the theme for inspiration, don’t come up with an idea before you hear it, and them make the game you want. If your game was about farming but the fun part turns out to be the way crows follow you, pursue that.
3. start with a screenshot
People are going to judge your game based on its screenshots. Whether it’s on a jam site or an app store, your screenshots promise how fun your game will be. Once you’ve got your idea hammered out, start working on a sketch of a screenshot right away. Here’s our first one:
This has multiple benefits:
* you clearly communicate with your team what the most important elements are. Anything not in the screenshot should wait until everything in there is working.
* you get scale clear early. If working in 2d, this screenshot should actually be a PSD that artists can slice up and fit buttons and characters to. That way you’re not stuck re-importing and re-scaling way-too-big sprites on Sunday
* you get something to share on Twitter
* gameplay problems are clear earlier. Take a look at our first game ‘screenshot’ above:
As the artists and designers looked at it, it became clear that the background action was totally concealed, and the ‘counter’ in the foreground was also crowded, leaving little space to display the sandwich you were making (later we realized we wanted to show all the ingredients you’d selected on the counter, so even more space was required)
Version two had a lot more space to show the background and the foreground, but the ‘hero’ was pretty tiny. I thought this was fine: he’s the player character, no one says “I want to see more of Gordon Freeman’s arms.” But the artists pushed back saying this cool character was now in the margins. We settled on adding some narrative frames to the beginning and end of the game to feature his story more.
4. Only program things you know how to program
The essential difference between a game jam and any full-time development is that you actually can tell your team “That feature is impossible.”
With a hard stop Sunday night, any feature that you can’t get working by Saturday at noon is impossible.
But isn’t it hard to predict, when coming up with ideas and making plans, what you can get done by Saturday? It really shouldn’t be. You should really only agree to make a game that you understand perfectly how to create.
If you’ve never made a game before, Unity has several great tutorials on creating several types of games, and if you use a bit of imagination, I think you can see how about 90% of the games you enjoyed last years are just different versions of the games they list there. Try to complete 1 or 2 of these tutorials before the jam and you’ll have a full quiver of stuff you do know how to do.
I address elsewhere some good reasons to leave the beaten track and figure stuff out yourself. I assure that even if you are certain that the game you’re working on is just a re-skin of the Space Shooter you made before, you will get many chances to work on new things. That little power-up idea everyone liked? That homing missile that you thought would take you a second to add? New challenges come up all the time.
5. Watch the stupid video
The biggest new feature for Game Jams in 2015 wasn’t the Unity GUI or Github’s improved binary support. It was YouTube’s ability to play a video at 1.5x speed
No one can code around the clock, and when you’re having a snack or just waking up, that’s the perfect moment to start up a tutorial on whatever you’re working on. The direct Unity ones are great, and YouTube is brimming with amateur tutorials. Just make sure you’re watching from 2014 or later.
6. stay on pace
My schedule works for me, and by sticking to it I’ve never failed to deliver a game:
6pm: meet people,
6:30PM: fidget through a keynote that feels interminable but maybe lasts 45 minutes
7PM: brainstorm an idea.
8pm: Look up some programming stuff for how to do it.
9PM: Read but only in a desultory fashion, open a new Unity project, feel overwhelmed. Go home and get some sleep
8am: start coding up your features using grey, black, and white boxes
12am: call over your whole team and say ‘the flamethrower that makes you jump higher is working!’ and show them a grey cube with some other white cubes that move around. And a debug log message. Assure them this means it’s working.
2pm: realize you, the artists, and the designer are out of sync and either roll back their expectations or start furiously working on an additional feature or two
4pm: by this time Saturday, have all features programmed. Give the designer the bad news about any stuff not yet started.
5pm: start throwing in final assets
6pm-10pm: You’ve been programming for 4 hours and haven’t done… anything important at all. you keep moving around sprites that aren’t final and adding safeties that aren’t important. Realize this and go home and get some rest
10 am: finally start working after being oddly slow all morning
11am: let the artists start testing builds. In the first 30 seconds of them playing, notice five broken things you meant to fix over a day ago
2pm: This game better be finished bud
3pm: toss in game opening, and game over, splash screens
4pm: add those sound effects and some music
5pm: fix the music volume
6pm: someone will tell you the ‘end movie’ is done. Give them a puzzled look.
7. Use a bug log
Even when I was hitting play on a game to run it for less than 30 seconds, I’m in the habit of using a notepad to jot down bugs. That way I can keep running the game and maybe notice other broken stuff, instead of stopping right there to fix the bug.
The time savings seems really minor: I rarely have ‘clusters’ of bugs to work on, so I’m just saving the time it would take me to start the game again and play to bug #2. But I find it enormously helpful.
I think the other advantage is that it clears space in my mind: I wrote down the bug, I don’t have to try and hold it in memory for even a few minutes. Maybe I wanna go use the can right after my test run, I won’t feel so tense if I know all the stuff I noted is jotted down.
One other good habit: cross stuff off your bug log, either when you fix it, or when you realize it’s low priority. Writing down a bug doesn’t mean it’s top priority, just that you don’t have to re-discover it later.
8. This is a game jam. Not a film Jam
Film Jams exist apparently! But this isn’t one. And that film you’re making to show before or after your game, it’s not going to work out. Couple things:
1) Game engines aren’t super good at showing videos. I wish I had more to say about this but I really don’t. Unity doesn’t have a way to show a video outside of the pro version, other game engines don’t do it well
2) your artists, your writers, whoever else, are going to pour time into this narrative section. They’re going to make something that includes all the ideas they came up with, the theme prompts, all of it. None of that work will be reflected in the actual game.
3) if you’re making a game where the player controls the outcome in any way, players have a less than 100% chance of seeing game-ending material. The player might win. They also might lose, or get bored and stop playing. That third option is the one you’re trying to prevent, and anything the player sees on winning the game won’t help avoid them giving up before the end.
4) people want to play the game you made. Anything that forces them into watching a prologue is actually a barrier between your audience and your game.
8. Make a great title card
I think so much of Alien’s aesthetic is described in this early shot
Most people won’t play your game.
While I do have serious concerns about time spent creating intro cinematics, I cannot stress enough how key a good title card is.
People looking at your portfolio, randos browsing a game jam site, people seeing the site preview card on Twitter, all will see your game’s title card. If it’s some random ‘programmer art’ with buttons tossed over a random image, then to some portion of your audience, that’s what they’ll know about your game.
Like the elaborate paintings on old arcade cabinets, a good title card lets people project an aesthetic into a game where it might not really be during gameplay.
Also a title card painting is a great Sunday activity for an artist, because otherwise:
9. Any resources made on Sunday will never be in the game.
When things are going really well this won’t happen. But I’ve never had things go really well. My first 3 or 4 jams I had artists bring me beautiful models, animations, sound effects, etc while I was desperately trying to get the game to build successfully. Needless to say these pieces never saw the light of day.
So what can an artist do on Sunday? 1 of 2 things:
1) Improve the resources that are in the game
If you already got a placeholder version of a sprite/model/texture, it should be easy to swap it for an improved version. This way you shouldn’t be caught fiddling with import settings late on Sunday, and you know if some final versions don’t get done you’ll have something in their place
This is my ideal flow: on Sunday morning hand the art team a rough build, and let them play it to death, writing down every bug. They might notice assets that need to be re-done at the same time, but this QA is invaluable.
the less code, the better
My first game jam game had over 900 lines of code. The game did not work at all. My last had less than 75. In Unity, the less code you’re writing yourself, the more time you’re spending using GUI tools that are extensively tested and designed to make games. Here are some things you should probably be using instead of coding up your own behavior:
- physics/physics2d and colliders
- Animations, especially those with callouts to other methods
- An animatorcontroller with several parameters
Here are two good reasons not to use an inbuilt feature and write the code yourself:
1) you came here to have fun and learn stuff, not drag icons around
2) you don’t know how animations work
Both are fair points! I’d say everything above except maybe colliders takes longer to learn than you have for the game jam. If you know how to write a state machine for animations already, or you’ll be happier knowing you tried it, have at it.
10. The more talk, the better
Whatever you can do to foster communication is beneficial. At least once in the weekend, your overtaxed brain will notice that you can’t work on the thing you really should be because you don’t have the asset/design doc/answer/test build you need to move forward. In that moment I hope you think to tell someone, but it’s super helpful to have scheduled times to check in and make sure you’re moving in the same direction.
Last weekend was my first jam where I used Slack and it was a godsend. The ability to preview images inline, share files, and save a discussion ‘history’ that we could show to others later was all key.
It also let me tune out chatter for hours knowing the important stuff would be in Slack when I wanted to get caught up.
11. There are no 10x devs, but there are 10x artists.
Lots and lots of people are good artists. They make art that looks really good, and can add a lot to your game. Sadly there’s a big range in how well an artist can help during a jam. In general, no matter how great someone’s portfolio pieces look, a production artist is going to be able to help you make a professional looking game.
If you want three characters each with a walk cycle and attack animations, then it’s best to work with someone who has experience with producing a lot of stuff fast and in the right format.
If someone has no experience or training in producing game assets, they might be great, but you’ll need to keep a close eye on their pace through Saturday morning. If they’ve just got a few roughs done by that time, consider using open game assets for your characters and having them draw backgrounds, or character portraits to use in dialogue.
This problem tends to get magnified by Sunday, when it turns out that a bunch of sprites are at the wrong scale, or their colors don’t blend well, or whatever else.
People who are good at doing visual stuff fast will also get you out of countless self-imposed scrapes. That moment when you realize the cool GUI you wrote for the start of the game won’t be ready in time, you’ll be so glad that you have someone on the team who can make an awesome splash screen:
in like minutes
13. Instruct your users
My last game was very simple. There were only onscreen controls, no advanced mode, no special goals. I still tried 4 distinct strategies to show users how to play my game.
Every time you get someone to come over and try your game, remain totally silent once they start. Anything you have to tell them must be told to the user.
Are panels like this one hacky?
you bet! But you just don’t have time to design the slow-build ‘tutorial’ level that show cleverly shows you how to play the game.