Once more, Kurius asked me to do a presentation for them, and I was more than happy to oblige. This time, it was about game jams, something I have quite a bit of experience with, and that I’d been meaning to write an article about for a long time.
Here’s the script of my presentation. I’ll likely have the recorded version linked sometime in the next few days or something. EDIT: Okay it took more than a few days for the video to release but here it is:
Hey everyone! I’m Justin, and today I’m going to be talking to you a bit about how to survive a game jam.
Some of you may remember me as one of the people who presented at Kurius’ previous Learnathon 21. To anyone who does, hi again! It’s honestly great to be back. Thanks to Kurius for inviting me again.
For those who don’t know, I’m a game designer at Ubisoft, currently working on Rainbow Six Siege. Before that I worked on Hyper Scape, and before that I worked in the mobile and indie games industries…
But most importantly for this talk, I’ve participated in a few Game Jams. Well, more than a few. I’ve kind of lost track of how many of them I’ve done, actually. What you see on screen isn’t even an exhaustive list! I’ve done all kinds of jams. Some turned out great, some terribly. I’ve won some jams, I’ve lost many more, and I’ve learned a lot. That’s why I can say with confidence that…
Game Jams, hackathons, or whatever you want to call them, are genuinely fantastic ways to develop your skills! The experience you gain, the friends you make, and the trials you overcome are basically like speed training for a career in games or any sort of development. Not to mention they can be a lot of fun! I honestly can’t recommend them enough, so to those of you participating, I say good on you! For those of you that aren’t, you definitely should when you get the chance.
That said, doing a game jam can be pretty intimidating, especially if it’s your first time. There’s a lot to take in, and a lot can go wrong. So with that in mind, I prepared a few tips to not only survive, but thrive in a game jam environment, from start to finish.
Before you even start the jam, there are some things worth keeping in mind. If I’m not mistaken, you’ve already started this jam, so some of these might be a little late for you, but it’s worth keeping in mind for future jams.
The single most important part of a jam is your team. It doesn’t matter what the theme is or what challenges or resources you might have if your team isn’t built properly.
There’s multiple facets to that. The first is of course your roles. Ideally, you want a team of people who can each specialise in a certain part of the work, with a bit of flexibility to help out with other parts as needed. Generally speaking, in a five or six person team, you want a distribution roughly like this:
1-2 Artists
1-2 Programmers
1 Designer/Project Manager/Flex
1 Musician/Audio Designer (optional)
Artists and programmers are easy to stack on a single team because there’s usually more than enough work to split between them without them stepping on each other’s toes. With just about everything else, one is more than enough.
Now, that isn’t to say you can’t do a game jam with a team of only designers or programmers. However, you’ll definitely have a much easier experience if you keep things balanced. Trust me, I’m speaking from experience on this one. In fact, want to see what a game jam game with no artist looks like? It looks like this.
Roles aren’t the only type of balance to consider when thinking about your team. It’s also important to consider what your goals and methodologies are. There’s no “wrong” way to do a game jam, but it’s best to figure out what everyone on the team wants out of the jam before diving into it. For example, if you’re there to participate casually and practice your coding skills, but the rest of the team is looking to aggressively compete for the top spot, you might find yourself mismatched.
Figure out your intentions early. That way you don’t end up with shattered expectations or bad blood within the team, because you never want that.
You’d be surprised at how many people come to a game jam without the equipment they’ll need to actually participate. This is of course a bigger deal if you’re physically attending a venue and not doing the jam remotely, but it can apply then as well. Make sure you have all or most of the software and hardware you’ll potentially need to do your roles in the jam. As a team, it’s also a good idea to come up with a few standard ways to communicate and share files before you start working. If nothing else, make sure you have a default way to contact each other for emergencies. You never know when you’ll need it.
A dev gym is quite simply a dedicated space to test things out and experiment. In the context of a game engine like Unity, that would be a simple scene. This is a very useful thing to have in general, but especially in a game jam since it allows you to work on things without directly modifying the game. This will be critical if multiple people are working on the project directly, integrating their assets and putting things together. As a rule, I always keep one gym per programmer at least. It can save a lot of headache in the long run, since mistakes made in a gym won’t break the rest of the game. This is also good training for working in the industry, since we use the same concept there too.
By the way, gyms aren’t exclusive to programmers. Level designers can make good use out of them. Artists can use them to test out shaders and lighting effects. Even sound designers can set up an environment to test their sound effects and music.
Point is, don’t do all your test work in the final scene. That’s a recipe for disaster.
Game jams are all about time management. A key to successfully completing a game jam is to properly distribute your time across the different tasks you need to perform. If you don’t do this, chances are you’ll find yourself scrambling to make your half-finished game work in the last hour. Usually because you wasted the first day or two thinking “ah we’ve still got plenty of time to figure things out”. You don’t. Not really, anyway.
A good way to get around that is to simply set deadlines for yourself. Once you go over that deadline, it’s time to put your pencils down, make a decision, and move on.
Now, this can be different for every team and every jam, but here are the deadlines I typically used for a classic 48 hour game jam (adjust as needed for the length of your jam):
Hour 5: Have a rough concept
Hour 8: Finalise the concept, plus have a basic main menu, gameplay scene, and game over screen
Hour 10: Confirm that what you’re trying to do is technically possible and have a task list
Hour 24: Have the basic gameplay loop and core mechanics and assets made
Hour 30: Have a unpolished but playable first version
Hour 40: Have a polished presentable version
Hour 46: Have a submission and presentation ready
Hour 47: Submit a final version
Hour 48: Submit any last minute fixes
These benchmarks are on the aggressive side and not a hard rule (especially for your first jam), but if you can manage to follow them then you ought to have ample comfort room to make your game as good as it can possibly be. There’s nothing wrong with spending more time on any particular step if you really need it, but it can get really easy to lose track of time while looking for the perfect idea or fiddling with the same platform for far too long. Keep the timeline in the back of your mind so that you aren’t surprised by it at the end.
Your team is all set up and you’re ready to come up with a plan. These first hours are critical, and will be a good indication of whether or not your game will be a success or not. So, how do you plan like a pro?
For those of you that aren't familiar with the concept of scope, it just means how big and complex your project is going to be. Scoping is one of the most critical parts of any project, but it's especially true for game jams. One of the biggest killers of any game jam game is having a scope that's too big. Being ambitious is good, but you need to know your limits.
So, how do you scope? The best place to start is by figuring out your MVP.
No, I don’t mean Most Valuable Player. I mean your Minimum Viable Product. This term simply means the most simple basic version of what you want to build. If you have your MVP, you have a game. It might not be a very good looking or well-performing game, but you have a game. That’s more than what some teams finish with.
Set your initial scope with that objective in mind. Break down your ideas into their simplest form that still makes some sense. How quickly can you build that? Is it realistic given the time and resources you have? If you’re not sure, the answer is probably no, so try to go for something smaller and simpler.
Of course, for some of you this is your first game jam, so you might not really know how to do this yet. That’s fine; it comes with practice. My recommendation is just to start as small as you possibly can. For example, in a lot of jams that I've done, my trick is to figure out a simple mechanic that I can build by the end of the first night. I then build that mechanic and if it works and is fun, then we've completed 80% of the jam right there. Everything after that is polish.
To give you some examples, I built the game "You Must Be This Tall to Ride" based on the physics of balancing two bodies one on top of the other. I literally slapped two blocks one on top of the other, connected them, and gave them each a set of controls. We played around with the physics and bingo. Meanwhile, To [ERROR] is [!HUMAN] as a game was just using voice recognition tech to drive a choice narrative.
Don’t just take my games as reference. In the very first jam I did, I sat next to the guys who made Starwhal. All they had for their idea was a pair of floppy characters that could rotate and stab each other in the heart. Starwhal went on to be a very successful party game. The point is, you can make a lot out of a very simple concept, so think small, and build up from there.
As important as scope is to surviving in a game jam, that doesn’t mean you can’t push your boundaries. Actually, game jams are a wonderful place to experiment with new ideas and test things you might not get a chance to try. Game jams are where I learned a lot of things I wouldn’t have learned otherwise. Dynamic sound integration, VR controls, and voice commands to name a few. So to be clear, I’m NOT saying not to experiment. But sometimes, you’ll come up with a cool idea and try it out, only to discover after several hours of hair pulling that it won’t work. It happens, and that’s why you should have a backup plan.
Home Is Where The Hoard Is was a game where you slapped slimes in VR. Simple enough idea. However, we very nearly had to scrap it because I found out early on that I didn’t have the tech necessary to use the Occulus Rift. Fortunately, we figured out a workaround a couple hours in. We were lucky. Don’t rely on being lucky. Rely on being prepared.
Plus who knows, maybe you’ll figure out a creative way to use the resources you have left over from your first idea.
It can be tempting to say that you’re going to pull all-nighters and work crazy hours to get the work done in time. I used to do it all the time. I was always the one that stayed up all night the first night setting everything up and then taking a power naps later. I would do that by sleeping a whole lot just before the jam, and then passing out for all of the next day after the jam.
I don’t recommend doing that. It would completely mess up my sleep schedule, and once I got a 9 to 5 job it didn’t work at all. Plus sometimes it would backfire and I’d just be super sleepy and inefficient for the entire second half of the jam.
Instead, I propose a simple idea: The time spent sleeping and eating ARE part of your scope, so count them in your plan. They’re as important as any other task, if not more so. Normalizing a healthy jam schedule is something we all should do, for everyone’s benefit.
Once you have a general idea of what your game is going to be, it should be pretty easy to figure out what you’ll need. That said, I’ve seen a lot of jammers just jumping directly into building their game with no real plan. Sometimes this can be fine, but I’ve also seen a lot of those same groups realise at some point in the last four hours that they completely forgot something important.
The solution is pretty simple. Make a list. Put it somewhere that the entire team can see and update as they progress. You can do this with a simple document, a project board like Trello, or even with post-its. Even better if you can label them with priorities and other info for additional tracking.
Just like it’s a good idea to have a task list, it’s a good idea to assign responsibilities in the team. For example, I used to do a lot of game jams as part of a team where I was one of two programmers. Often, we would organise ourselves so that I handled everything that was related to the menus and point scoring, while he handled things related to the controls and characters. That way, each of us could work on a backlog without stepping on each other’s toes. Likewise, our two artists on the team would usually split environment art and character art. How you divide the work can be up to your actual team, but setting these divisions helps to ensure that you don’t accidentally duplicate or forget work. Of course, if one of you finishes your side of things, then there’s nothing stopping you from picking off of the other pile.
You’ve got your idea down, you know what you need to do. Now it’s time to actually make your game! You’ve planned everything out, so surely, there’s nothing that can go wrong, right?
Wrong! The very first thing to keep in mind is that if something can go wrong in a game jam, it will. Because game jams are so short and high pressure, mistakes and oversights happen, no matter how much you prepare.
I once did a jam at a camp, and their power supply wasn’t able to handle all the computers set up at the venue, so we had a blackout. Everyone ended up running their computers on portable generators, and our team’s generator broke down several times over the course of the jam. Stuff happens. Sometimes it’s a technical issue. Sometimes it’s a personal one. There’s a lot that can go wrong in just those few hours.
Game jams are stressful. It’s important that you know that going in, and be mentally prepared to handle the unexpected. Sometimes you’ll be able to get through it with some clever solutions or sheer tenacity. Sometimes you won’t, and your team will crash and burn. That’s okay. Game jams are meant to be a learning experience, and you can learn a lot from these failures. Just keep that in mind and don’t get too worked up over it.
Basically, don’t stress. It’s only a game jam.
Speaking of stress, one of the easiest ways to avoid being stressed in the final hours of a jam is to make sure you keep your priorities in order. You wouldn’t believe how many games I’ve seen start with the optional cosmetic stuff and then leave building the actual game for the end. To me, that just seems like a great way to turn your hair white from stress.
When you’re trying to figure out what to work on next from your task list, I recommend using these questions:
Do I need this for the game to function? (i.e. is this part of the MVP?)
Do my teammates need this to do their work? (i.e. Am I blocking someone?)
If the answers to either of these questions is yes, then deal with that first. Doubly so if it’s both. Everything else is fluff, and can be done afterwards when you get to the polish stage.
I’ve seen a lot of game jam participants get really ambitious with how much content they want to make. I’m talking multiple big sprawling levels or a whole bunch of different features and modes.
Something to remember is that the people who will be looking at and judging your game will only be seeing it for a few minutes, and aren’t likely to play it more than once. So chances are, if you make something that has a lot of content, they aren’t going to see it, and as far as they’re concerned, if they don’t see it, it doesn’t exist, no matter how much time you put into it.
Focus your energy on making a vertical slice. That means a small, focused experience that is very deep. A single very pretty and well made level with only a couple really tight mechanics will always beat out several kinda meh levels and a bunch of buggy mechanics.
I said it just a moment ago, but it bears repeating. Game jams are very forward-facing experiences. The vast majority of the time, people aren’t really going to look at how things work behind the scenes or take the time to uncover all the content you made. They’re going to look at what they see right in front of them, interact with that for a few minutes, and then leave. Presentation will often trump substance in a jam. You can use this fact to your advantage.
Is there a volcano in the distant background of your game? Don’t bother modelling the whole thing. Just model the part that they’ll see. Or better yet, get a 2D image and slap some lighting effects on it. There’s a lot of corners you can cut when you realise just how many details people are ignoring. Pour all that extra time you save into the things that are going to be in people’s faces. Prioritise what your audience will actually see, and slap dash everything else. That is the essence of making a good game jam game. It’s what we in the business call “efficiency”.
Efficiency really is the name of the game in game jams, and one very simple and effective way to significantly boost your efficiency is templates. Consider most of the games you’ve seen, and just how many things in those games are basically slightly modified versions of the same thing.
Take for example a classic FPS soldier enemy. Now, say you add four adjustable values: health, speed, attack range, and fire rate. Even if you only had two thresholds for each, you can now make all sorts of different types of enemies. By having a base with a few tweaks, you can make a variety of things, without having to rebuild something from scratch each time. Building a couple templates can allow you to create quite a lot of variety at very little cost.
This logic can be extended to a lot of things, and even across game jams, depending on how much you’re allowed to carry over. For instance, I had built a game menu during one jam, and turned it into a template that I used to set up a whole bunch of other games. It wasn’t anything fancy, but I saved myself a solid hour of building an intro and game over page with basic menu controls. All the games you see here? Same code for the menus. That’s an hour I was able to use on things to actually make the game better.
This should probably be obvious, but unless you’re working solo, game jams are a team sport. You don’t win team sports by having everyone hide in their corners and never interacting with each other. As a team, you need to be in constant communication. Let people know what you’re working on and what you’ll need next from your teammates. Check in on what your teammates are doing so that you’re all on the same page. Ask your teammates for help and get their perspective on what you’re doing. These are all useful interactions you should be doing regularly.
Even if it isn’t directly in service of the game, just chat with each other from time to time. Social interaction builds the bond between your team, and can make your other interactions go more smoothly. Plus it’s a way to manage your stress and have fun. We are social animals, and we work best when we’re interacting with others.
A little detail that can easily be forgotten is that not all of us always use the same standards or words in our work. To give you an example, during one jam I asked one of my teammates to give me some graphical assets and sent him the dimensions I needed for them. A few hours later, I received the images, only to realise that they were severely distorted. We realised the problem pretty quickly: I had been using pixels in my measurements, but he had been using points. This meant that we had to go and revise all of his images to fit properly with our pixel-based resolution. This could have easily been avoided had we made sure we were using the same units of measurement in the first place.
Same goes for language. I’ve worked with a lot of francophones, and I can tell you that there are a lot of terms that don’t translate the way you think. One of my favourite examples is when I received a project-wide mail with this message. In this case it didn’t cause any trouble, but you can see how easily a single word can change the meaning of something.
Is a platform a flat surface you walk on, or is it the hardware you’re running the game on? When you say “running”, do you mean the game is running, or the character? Is HP a measure of your health, a brand of printer, or a delicious brown sauce? Silly as it might seem, try to keep this sort of thing in mind when you communicate with each other.
Something to add for the programmers out there is that the single most easy place to mess up on this front is with your in-game constants and variables. Always try to name your values in a way that makes them easy for everyone to read and understand, not just you. It can save a lot of headache in the long run, and is just good general practice.
In all the chaos of a game jam, it can be really easy to forget about things. That why I suggested you make a list and always stay in communication. You really don’t want surprises near the end of a jam just because everyone forgot about something.
Ideally, you might have someone on your team who is the designated project manager, looking over everyone’s work and making sure that the important tasks are being completed when they need to be. If not, then everyone has a certain responsibility to check up on the task list. Be careful not to fall into the trap of “I thought you were taking care of that”.
Save. Save. SAVE! I can’t count the number of times I’ve seen people in jams despair because they didn’t save and suddenly their computer crashed or something else happened that caused them to lose hours worth of progress. Save often. Make backup saves. Put your stuff in a shared location so that even if your computer dies, someone can download it and continue. Just… Save.
In the vast majority of game jams, there’s a bit at the end where you show your game to other people. It can be judges, fellow participants, or even the general public. Point is, you’re likely going to be showing it off. With that in mind, most jams expect you to do a little presentation, or write a blurb. Most people consider this step an afterthought and neglect it in favour of spending that time on their game. This is a mistake.
Unless you’re a pro improviser (and very very very few people are), it’s a good idea to prepare a little something ahead of time, maybe about half a day before the final deadline. Because game jams put so much emphasis on presentation, this is your opportunity to direct the audience’s attention. Highlight the best parts of your game, and hide or gloss over the broken and unfinished bits. A good presentation will do wonders for how the audience will look at and experience your game, and can make a huge difference, while requiring relatively little effort.
I’m willing to bet that when the jam is over, a lot of you out there are going to talk to your teammates about how your game could actually be really great if you put a bit more work into it and you’ll all agree that you should stay in touch and get back together to finish the job. I can also tell you that about 95% of you will never actually do that, and many of you will never talk to each other again other than to maybe wish each other happy birthday on Facebook every year. I say this from experience. That’s literally what I was doing as I wrote this.
Honestly, there are very few game jam games that are worth revisiting after the jam (there are some, just not many). The people you meet as part of a jam however… Nothing is more important in the video game industry (or any industry, for that matter) as connections, and no connection is stronger than the bond forged by going through trials together. Game jams give you a unique insight into how your teammates work and behave under pressure, and what they’re capable of when they push themselves. That knowledge is invaluable, and likewise, you can show off your skills to your teammates.
Keep track of the people you worked well with and keep their contact info on hand. You’ll never know when they’ll come up again. I’ve personally given referrals to many people I’ve done game jams with, because I know they’re the kind of people that can get the job done. Something to keep in mind.
That’s it! Well, not really. I could probably list a dozen more suggestions, but there’s only so much time and I need to focus on using it efficiently (see what I did there). Hopefully some of these tips will help you in your journey. Most likely you’ll have to learn many of them first hand. But that’s what game jams are for. So, above all, learn, and have fun. If you do that, then no matter the game you put out, every game jam will be a success.
Best of luck!