When I originally wrote this document, it felt pretentious, and stopped right before publishing. But after a review, it feels like it might be a good reference for some.
I love jamming, and I have been doing it for 8+ years. compulsively at some points (12+ jams a year). Here are a few insights that might help you.
Attitude
A “jam game” is not the same as a “game” (at least, most of the time). Take this to your advantage. Some good games are the result of iterating over a jam game. But the “real games” take a long time to make.
So, start by jamming, the game comes second. It is good to initially focus on the experience: the days (or weeks) that you spend on the project. A smaller time investment means you can experiment, but are also free to stop at any time. Any advance is positive. The first milestone is being able to submit something, and bonus points by doing it at a healthy pace!
Also, you are not alone: the other people in the jam (team and community) are going through the same as you. Aim towards being positive with your feedback (during and after), open about your ideas, questions, and doubts, and be happy to help. No matter how many jams you do, this is the first jam for somebody. If your project gets delayed a bit but somebody else’s weekend improves because of you, that’s a win in my book.
WHY do you jam?
You can do jams for multiple reasons. It is important to know what is your personal goal before starting. Also, when working within a team, you need to know each others’ expectations, ensuring that these expectations are compatible.
There are many good reasons why to jam, here are the ones I prefer:
- To learn: a jam is a great sandbox to learn a new tech or tool, even a new role. You can do it by experimentation, or by assisting somebody with the skill you want to learn. It is important to know that if your goal is to learn, then you need to reduce your expectations about your contribution to the final product. That’s OK.
- Work together: it is a great way of knowing people, and a magnificent tool for team-building.
- Finish a game: Doing a jam is about reaching the end, and submitting something. If you arrive to do that, then you achieve the goal of doing a jam game. This can be harder than it seems, especially your first time (and when you get confident, you will probably overreach the next time around). Your first step is to go small, no, smaller than that.
- Make a good game (and win!): You can take a competitive attitude when jamming… but I would argue that being surprised by the results gives you the freedom to explore. Eventually, you might/will win. Winning is the result of a combination of factors:
1. you got lucky
2. You are comfortable with your tools and process,
3. you got the right people around you,
4. you probably ended with something elegant (minimalistic and focused),
5. with a decent amount of polishing
HOW do you jam?
Prepare
It is better to start the jam with the environment prepared. Whether working with others or alone, I try to prepare the tools in advance (install the latest unity, make a git repo if using git, etc).
Don’t over-prepare: avoid adding libraries you will not need, or working on assets or designs before the jam starts.
Plan
A rough plan requires the following steps:
Idea -> Identity -> gameplay -> polished version -> submission
Personally, I prefer to divide the time into three equal chunks:
1. Identity: define the core of the game
2. Gameplay: add all secondary elements
3. Polish
Each of these thirds is divided into 2-3 hour sprints (3 sprints per day in a 72h jam), so you can take a break and check on your team. Two hours is a good time to test something, without losing your main objective. Worst case, you waste 2 hours.
For the anecdote, the origin of the thirds is a very fancy squiggle:
The IDEA
Learning about the THEME
Jams normally release the theme the day that they start. Try to receive it with a clear mind, to be inspired by it. When in a team, learning about the together avoids people fixing a personal idea, but that’s up to you.
If part of the theme is revealed earlier, you can start loosely exploring options, but try to stick to the actual design and development for the jam span: it is more fair for others and also saves you from obsessing with an idea that might not fit the final theme.
Something I found problematic is when the theme is released late in the day (usually Friday night). Being creative after a whole week of work can be counterproductive. I think you can still do it, but I would work until the next morning, after a second short discussion to ensure the idea still holds.
The brainstorm
To go from the theme to your idea, you will probably brainstorm. There are many resources and talks on how to brainstorm (like THIS ONE)
The single most important thing about brainstorming sessions is to keep it short (30 min). An obvious jam game is better than a convoluted one. If there are multiple good ideas and people don’t completely agree, do a prototyping iteration where each person or group builds a proof of concept in a few hours using any medium (but be aware that people may not want to abandon their idea afterward).
When in doubt, my advice is: choose one idea, don’t force a middle-ground between multiple ideas. If one member championed a concept and you all agreed to do it, give that person the role of design lead. Question their idea, but only as a way to help them find answers to their design flaws later on. Follow a single vision, and improve it together.
Depending on the types of games you like, my advice on how to find ideas or identities might not be relevant. Still, here are my preferred starting points:
- A known idea with a twist
- Two ideas that should not work together (that’s why I love the minijam)
- Drive inspiration from a different domain
- Be silly
Board games as starting points are a personal favorite and are recommended by indie devs. Board games are defined by clarity and elegance, small numbers, and technically easy to implement. Plus the game can be physically prototyped and tested before the coding starts.
⚠️Scope traps: I personally love simulation games and procedural generation in general, and I have tried to cram these tech-heavy features into a weekend jam, resulting invariably in frustration. There’s a time and a place for procedural, and that’s the procjam. More generally, it is fine to lean heavily into tech (or other aspect), but you need to reduce your expectation of also making a game.
The Identity
So, you selected an idea. Now you need to build towards your game identity. You can refer to it as the game pillars.
Unless you are super-trained or have great intuitions, it is hard to have a game concept in your head that ends up being implemented exactly as expected. But you have the time to experiment.
For jamming, I like Forward design (a concept that I cannot remember where I read). You have an idea you like, you build something, and it is perhaps not what you expected but there are interesting unexpected questions… so you can push that, and then again, and then the game designs itself. To avoid the process from diverging too much, you can always compare it against the first idea you liked, and see if it’s fitting.
For me, what tends to work is to have a gameplay gimmick, and fiddle around until it feels like I can build from it. Works well with puzzles, where you can add a new rule and check how well it combines with the previous ones.
You can spend the first third of your time doing that, but it is better if, by the end of this time, you converge into a somewhat stable concept and its implementation.
The game
At this point, you can start adding secondary elements, without breaking your identity, and adjusting the very rough edges of your prototype.
Also after the core identity is put down, it is easier to divide the remaining tasks. If the project duration will be longer than 2 days, start with a super simple task list and prioritize them, focusing on the most important one at the time, avoid parallel work until after you set the general framework. Keep in mind that 4 people don’t solve a project 4x the size in the same time, the overhead gets larger with task overlapping.
Communication and task distribution are then essential. You all need to be on the same page, but also moving forward is more important than being right (if it works, then great, you can improve it in the next iteration).
Unless not allowed, using libraries is strongly recommended. A jam is not about engine building, and in most cases, the code will be quick and dirty (most jam code crumbles, ideally after submission). The code is a means towards an end: good gameplay.
Build
As soon as possible, I recommend you start making builds and sharing with others (no later than mid-jam). It is good to have an external view of the project, but it is equally important to get rid of any building problems early on.
Building also means checking the performance (a good reason for regular builds).
If you use Unity or Godot, I strongly recommend doing a game that works in WebGL. This also makes it easier to do beta testing, you can upload your game (to itch.io for instance) and pass the link to others, they can test it and see the progress.
If you do tests, better to do so over the built version.
Polish
This is the most important task that you might not have the time to do. I have been insisting on doing something small, mainly because polishing is what makes your game stand out (see the classic talk Juice it or lose it and the art of screen shake).
From debugging, sound & VFX, to menus, every minute spent increases your quality.
My single most liked tool for juice is tweening, followed by sounds (initially free ones, and now using bundles).
Document, Share & Play
You do not need to wait until the end of your development to share your jam advances. I personally love recording short gifs that capture the progress, and what makes me happy. This is also a great way of keeping a development log, or just looking at old projects. Share it online, or keep it for yourself, either way, capture the moment.
Jamming is as much about making a game as it is about playing other people’s games. It is a great exercise, it is inspiring as there will be always people better than you, but also people joining the community that you can be a positive influence. So, be positive.
There will be tons of games, and being active socially will give you visibility, if you are into winning. Even if I dislike the super competitive attitude, it is a required step if you want to go into the big leagues: Indie game development.
Joan Sol Roo - Personal Website 