You have probably started five game projects and finished zero of them. That is the normal beginner pattern, and it is the single biggest reason beginners stay beginners: finishing a game is a completely different skill from starting one, and you only get better at it by doing it under a real deadline. A game jam is where you practice finishing. This chapter covers what a jam actually is, the main jams you can join, how to cut a huge idea down to something you can build in a weekend, an hour-by-hour plan for 48 hours, what order to build things in, what to cut when the clock runs out, how to use free assets without breaking any rules, how to prepare ahead of time so you do not waste jam hours on boilerplate, and what a good submission looks like.
A game jam is a timeboxed event (meaning it has a fixed start time and a fixed end time, no extensions) where you build a game from nothing to a submitted, playable state within that window. The most common lengths are 48 hours (one weekend) or 72 hours (a long weekend). At the exact start time, the organizers announce a theme — a word or short phrase, like "Roles Reversed" or "Combine two genres that shouldn't work together" — and every entrant has to connect their game to it somehow, in whatever way they interpret it.
Nobody knows the theme in advance. That is the point: you cannot pre-build a game over months and just paste the theme on top at the last second (well, some people try, and it usually shows). You start truly from zero — zero design, zero art, zero code beyond whatever reusable template you personally prepared beforehand, which section 5 covers.
After the deadline, most jams have a separate, longer rating period — days or weeks where every entrant plays and rates other entrants' games. Section 11 covers what to do during that period.
Open your own projects folder right now, if you have one. It probably looks something like this:
This is not a personal failure. It is what happens by default when a project has no deadline and no audience. Without a deadline, "just one more feature" is always available, forever, and there is no external pressure to ever call it done. Without an audience, nobody notices if you quietly let it die in month two.
A jam removes both of those excuses at once. The deadline is real and public — the submission page closes at an exact time, no exceptions. The audience is real too — other jam entrants will actually open your game and rate it, which means "finish it or nobody ever sees it" is not a hypothetical. Under that pressure, you are forced to practice the exact skills a real studio job needs every single day: deciding what is actually necessary versus what is nice-to-have, cutting features under a deadline, shipping something imperfect on time rather than something perfect never, and packaging a build that a stranger can actually run. None of that shows up when you have unlimited time on a solo project. All of it shows up in 48 hours.
You do not need to invent your own jam or wait for the perfect moment. There are several large, well-run jams that happen on a predictable schedule, plus thousands of smaller community jams running at almost any given time.
Joining one is the same basic process everywhere: make a free account on itch.io, browse to itch.io/jams, find a jam that is currently open for registration, and click "Join Jam" before it starts. When the start time hits, the theme is revealed on the jam's page. You build for the jam's duration, then submit your game's page (with a playable build attached) before the deadline. Many jams also expect — or require — that you rate a few other people's games afterward, which section 11 covers.
Scope means literally everything the finished thing needs to contain — not just "features," but every menu screen, every piece of art, every sound effect, every level, every bug fixed, and the exported build itself. Beginners almost always think of scope as "the cool mechanics I want," and forget that a working main menu, a way to lose, and an exported .exe that doesn't crash are also part of the scope.
Here is the single most useful rule for jams: your first idea is always too big. This is not a maybe — it is close to a law of nature. The moment a theme is revealed, your brain gets excited and imagines the maximum, most ambitious version of a game around it, not the minimum buildable one. Everyone's first idea, every single jam, needs to be cut down, usually more than once.
Here is a worked example of that cutting process, starting from a genuinely too-big idea:
Notice what survived to v3: there is still a clear player action (attack, dodge), a clear threat (waves of one monster), a clear win/lose framing (survive as long as possible), and a clear scoring hook (seconds survived, which is instantly readable by anyone rating it). What got cut was everything that multiplies the amount of content you would need — a whole village, ten craftable items, a procedural generator — without multiplying how fun the core 10 seconds of gameplay is.
The repeatable process: write your idea down in one sentence. For every noun and verb in that sentence, ask "can I cut this and still have a game?" Keep cutting until you cannot cut anything else without losing "a game" entirely — specifically, until removing one more thing would remove your win condition, your lose condition, or the one input the player has to learn.
The 48 jam hours are for building the parts of your idea that are actually new. They are not for re-solving problems you have already solved in a previous project — how to switch scenes, how to play a sound effect, how to read player input. Every hour spent rebuilding that boilerplate during the jam is an hour not spent on your core mechanic. The fix is simple: build a small template project in your own free time, before any jam starts, and copy it as the very first commit of every jam project you do.
At minimum, a jam template should already solve three things: reading player input in one place, loading scenes, and playing audio. Here is a compact starting point for each, using a pattern called a singleton (a class that guarantees only one instance of itself exists and stays reachable from anywhere via a static Instance field — useful here specifically because you want exactly one audio manager and one scene loader for the whole game, not one per scene).
using UnityEngine;
// One place that reads raw input, so gameplay code never calls
// Input.GetAxis directly. Swap the inside of this file for a new
// control scheme without touching any other script in the jam.
public class InputReader : MonoBehaviour
{
public static InputReader Instance { get; private set; }
public Vector2 Move { get; private set; }
public bool JumpPressed { get; private set; }
void Awake()
{
Instance = this;
}
void Update()
{
Move = new Vector2(Input.GetAxisRaw("Horizontal"), Input.GetAxisRaw("Vertical"));
JumpPressed = Input.GetButtonDown("Jump");
}
}
using UnityEngine;
using UnityEngine.SceneManagement;
// Put this on an empty GameObject in a "Bootstrap" scene that loads
// first. It survives every later scene load, so any script anywhere
// can call SceneLoader.Instance.LoadScene(...) without a reference.
public class SceneLoader : MonoBehaviour
{
public static SceneLoader Instance { get; private set; }
void Awake()
{
if (Instance != null && Instance != this)
{
Destroy(gameObject);
return;
}
Instance = this;
DontDestroyOnLoad(gameObject);
}
public void LoadScene(string sceneName)
{
SceneManager.LoadScene(sceneName);
}
}
using UnityEngine;
// Also lives in the Bootstrap scene. Anything in the jam game can
// call AudioManager.Instance.PlaySfx(clip) starting hour 1, instead
// of you rebuilding an audio system at hour 30.
public class AudioManager : MonoBehaviour
{
public static AudioManager Instance { get; private set; }
public AudioSource musicSource;
public AudioSource sfxSource;
void Awake()
{
if (Instance != null && Instance != this)
{
Destroy(gameObject);
return;
}
Instance = this;
DontDestroyOnLoad(gameObject);
}
public void PlaySfx(AudioClip clip)
{
sfxSource.PlayOneShot(clip);
}
public void PlayMusic(AudioClip clip)
{
if (musicSource.clip == clip) return;
musicSource.clip = clip;
musicSource.loop = true;
musicSource.Play();
}
}
Worked trace of the guard clause in SceneLoader and AudioManager: imagine you accidentally leave a second copy of the Bootstrap object sitting inside your Level1 scene, from an earlier test. When Level1 loads on top of the real Bootstrap scene, Unity calls Awake on both AudioManagers. The first one (the real one, already Instance) sees Instance != null && Instance != this is false for itself, so it proceeds normally. The second one (the accidental copy inside Level1) sees Instance is already set to some other object, so the condition is true, and it destroys itself immediately. Result: exactly one AudioManager survives no matter how many accidental copies get loaded, and you never hear two overlapping music tracks. Without that guard clause, both would survive, and you would get exactly that bug — this is also Exercise 3 at the end of this chapter.
A rough schedule keeps you from either freezing up at hour 0 or realizing at hour 40 that nothing works yet. This is not a rigid law — adjust it to your own speed — but the checkpoints matter more than the exact hour numbers.
The hour-12 checkpoint is the most important line in that whole table. "Playable by hour 12" means someone else could sit down, press a button, and actually do the core action of your game — even with gray rectangles instead of art, even with no sound. If you are still not there by hour 12, the honest move is to cut scope again on the spot, not to push forward hoping you will "catch up" later. Jams do not reward optimism about your remaining hours; they reward what is actually running when the deadline hits.
The other checkpoint worth memorizing is "submit early." Build your first actually-submittable, exported package well before the real deadline — around hour 44 to 46 in the table above — because exports fail, upload sites get slow right at the deadline when everyone uploads at once, and your own computer can crash at the worst possible moment. A rough build submitted at hour 45 beats a perfect build that never finishes uploading at hour 48.
A vertical slice means one thin path through the entire game, fully working start to finish, instead of every system being partially built at the same time. The name comes from imagining your game as layers stacked horizontally (menu, level 1, level 2, enemy AI, audio) — a vertical slice cuts straight down through all of them at once, but only wide enough to prove one full loop actually works.
Building the fun part — the core mechanic — before the menu is not just a style preference. There are two concrete reasons. First, if the core mechanic is not fun, nothing else you build matters, and you need to find that out as early as possible while there is still time to change direction; a beautiful main menu attached to a boring mechanic is still a boring game. Second, most jam raters spend well under a minute per game — that minute needs to be spent playing your core loop, not clicking through a title screen and an options menu to get there. A jam game can, if time runs out, start the player directly in gameplay with no main menu at all, and lose almost nothing for it.
A concrete order of work that follows from this:
By hour 36 or so, almost everyone is behind their own plan. That is normal, not a sign you did something wrong. What matters is cutting the right things, in the right order, so what remains is still a complete, working game rather than a pile of half-finished features.
Roughly in order from "cut this first, nobody will miss it" to "cut this only as an absolute last resort":
Two things are never on that cut list, no matter how little time is left:
A fast self-check before you submit: hand the build to a friend, in person or over a call, say nothing at all, and watch what happens in the first 30 seconds. If they are already doing the core action of your game by then, you are done. If they are staring at a black screen or asking "wait, how do I start," fix that specific thing before touching anything else — it outranks every remaining polish task on your list.
Nobody expects you to draw every sprite and compose every track from scratch in 48 hours — with one exception: some jams, like Ludum Dare's Compo track from section 3, specifically require you to build every asset yourself during the jam window, as part of the challenge. Check your specific jam's rules first. Outside of that kind of strict solo track, using free or licensed assets is completely normal and expected.
Common places to find them: kenney.nl (a huge library of game art, almost all released as CC0), opengameart.org (art and music with mixed licenses — check each asset's page individually), freesound.org (sound effects, mixed Creative Commons licenses), and the itch.io asset marketplace (some packs free, some paid, license stated on each page).
The license on each asset tells you what you are allowed to do with it. Three you will see constantly:
Crediting is simple: add a CREDITS.txt file to your build, or a credits section on your itch.io page, listing each asset, its creator, its license, and a link.
CREDITS
Music: "Chiptune Adventure" by KubaAudio (CC-BY 4.0)
https://opengameart.org/example-music-page
SFX: Kenney "Interface Sounds" pack (CC0)
https://kenney.nl/assets/interface-sounds
Font: "Press Start 2P" by CodeMan38 (OFL)
https://fonts.google.com/specimen/Press+Start+2P
Your itch.io page is the game's first impression, and it happens before anyone even presses play. Three things on that page matter far more than beginners expect:
Prefer a web build (WebGL, or whatever your engine's browser export is called) over a downloadable zip whenever your engine supports it. A rater is far more likely to click "play in browser" on the spot than to download a zip, extract it, and run an unsigned .exe from a stranger past an antivirus warning — friction at this stage directly costs you plays and ratings.
Submitting is not quite the end. Two things are worth doing right after, and one decision is worth making once the dust settles.
First, rate other people's games. Many jams expect this, and some — GMTK's ranking system is a well-known example — partly base your own game's visibility on how many other games you rated. Beyond the incentive, this is genuinely one of the fastest ways to learn: you get to see what dozens or hundreds of other people built under the exact same theme and time limit you had, which makes it very easy to spot ideas, tricks, and scope decisions you would not have thought of yourself.
Second, read the feedback you get without getting defensive about it. Comments and ratings tell you, in aggregate, what worked and what confused people — if five different raters all say "I didn't understand how to attack," that is not five people being unfair, that is a real signal about your section-8 "understandable in 30 seconds" rule not quite landing. Look for patterns across multiple pieces of feedback rather than reacting hard to any single comment.
Third, once a week or two has passed, decide whether the game is worth expanding into something bigger — a portfolio piece with more content, better art, and more polish than a jam weekend allows. Not every jam game deserves this, and that is completely fine; the value of the exercise was in finishing it, not in every single result being a keeper. A reasonable way to decide: if you still want to open and play it after a week away from it, and the core mechanic tested well with other players (not just you), it is a good candidate for a scoped post-jam expansion. If neither of those is true, archive it, keep the template improvements you made along the way (section 5), and bring what you learned into your next jam instead.
Instance field.One reasonable cutting path (yours does not need to match exactly — the process matters more than the exact result):
v1 (the too-big dream): "A 4-player online co-op survival game where you build a base, craft weapons, fight a day/night monster cycle, trade with an NPC town, and unlock a skill tree." Cut: no multiplayer/networking at all (section 8 says this is always the first thing to go), no NPC town or trading, no skill tree.
v2 (still too big): "Solo survival: build a small base out of 3 wall pieces, craft 2 weapon types, survive a day/night cycle where monsters only attack at night." Cut: no building system (building under time pressure means placement logic, snapping, and its own UI — too much for a weekend), no crafting, keep only the day/night monster timing idea.
v3 (buildable in a weekend): "A fixed arena. Monsters spawn only during a repeating 'night' phase shown by the screen darkening; the player has one weapon and must survive each night phase, with a short safe 'day' phase to recover between waves. Score = number of nights survived."
Scope check on v3: (1) a way to lose — yes, get caught by monsters during a night phase; (2) a way to win or a score — yes, nights survived, instantly readable by a rater; (3) one core input to learn — yes, essentially just attack/aim. All three pass, so v3 is a real, buildable scope.
72 hours is 1.5 times 48 hours, so multiplying every hour boundary from section 6 by 1.5 gives:
The key idea being tested here is that the checkpoint is a fraction of total jam time (one quarter), not a fixed hour count. A longer jam gives you more hours per phase, but the same proportion of "figure out the core mechanic" versus "build content" versus "polish" still applies.
AudioManager, copied into a rushed jam template, is missing something from the version in section 5. During the jam, restarting a level after a game-over reloads the whole scene, which contains its own copy of the Bootstrap object. Players report hearing two overlapping music tracks after restarting a few times. Find the bug and fix it.
using UnityEngine;
public class AudioManager : MonoBehaviour
{
public static AudioManager Instance { get; private set; }
public AudioSource musicSource;
void Awake()
{
Instance = this;
DontDestroyOnLoad(gameObject);
}
public void PlayMusic(AudioClip clip)
{
musicSource.clip = clip;
musicSource.loop = true;
musicSource.Play();
}
}
The bug is the missing duplicate-instance guard from section 5. Awake here unconditionally sets Instance = this and calls DontDestroyOnLoad(gameObject), with no check for whether an Instance already exists. Every time the level scene reloads (which includes its own Bootstrap copy), a brand new AudioManager runs Awake, overwrites Instance to point at itself, and also calls DontDestroyOnLoad on itself — but the previous AudioManager, from the scene load before that, is never destroyed. It is still alive, still has its own musicSource playing in a loop, and nothing ever stops it. After a few restarts, you have three or four AudioManagers all quietly playing music at once.
using UnityEngine;
public class AudioManager : MonoBehaviour
{
public static AudioManager Instance { get; private set; }
public AudioSource musicSource;
void Awake()
{
if (Instance != null && Instance != this)
{
Destroy(gameObject);
return;
}
Instance = this;
DontDestroyOnLoad(gameObject);
}
public void PlayMusic(AudioClip clip)
{
musicSource.clip = clip;
musicSource.loop = true;
musicSource.Play();
}
}
With the guard restored, every new AudioManager checks whether a different one is already the live Instance before doing anything else. If one is, the new duplicate destroys itself immediately in Awake, before it ever gets a chance to touch DontDestroyOnLoad or start playing anything. No matter how many times the level scene reloads, exactly one AudioManager is ever alive at once.
That covers game jams end to end: what a jam actually is, the main ones you can join this year, why the deadline itself is the thing teaching you something, how to cut an idea down to a real weekend-sized scope, an hour-by-hour plan with a hard playable-by-a-quarter-of-the-way checkpoint, building the fun part before the menu, what to cut and the two rules you never cut, using free assets without breaking anyone's license, preparing a template so jam hours go toward your actual game, and what a submission page needs to earn a stranger's 30 seconds. The next theme reveal you see, you already know the entire path from zero to a finished, submitted game.