Hitchhiker's Guide to a Game Jam

I love game jams: joining a community to build strange, fun, creative projects together; learning the push and pull of collaborating well; building skills and gaining experience I can turn into a portfolio. Across more than a dozen game jams, some successful and some probably less so, I've come to love the experience. So let's talk about what it takes to do well in a jam, the pitfalls that can lead to disappointing results, and the decisions you can make before, during, and after the event to get the most from it.

For the uninitiated, a game jam is an event where participants are challenged to create a new game—usually a video game—from scratch. A jam can last anywhere from a few hours to an entire month. Developers boot up their game engines, artists break out their sketchbooks, composers open their digital audio workstations, and everyone's skills come together to craft a single experience. When all is said and done, participants share their work and play one another's games. Think of it as a hackathon where the finale is less show-and-tell and more gaming marathon.

Although I've gone solo in past jams, this guide will largely assume a collaborative lens. A big part of the appeal, for me, is meeting new people and bringing different styles and tastes together. Working in a team isn't necessarily easier than jamming alone, but it can make game jams an accessible entry point into game development for those without the time or expertise to build games themselves. You can contribute writing, design, art, music, or another specialty without needing to swallow the whale of building a whole game yourself. Jams can serve as a great arena to develop a focused craft.

Ready to get jamming? Lovely—let's start at the beginning.

Before the Jam

You know you want to gain some experience with game jams, but how do you even find them? The premier place for finding different jams is itch.io. It hosts game jams and their submissions, while also serving as a marketplace and distribution hub where creators can share their work. Many organizers use itch.io because it makes joining, submitting, and playing jam games straightforward.

itch.io offers a huge range of jams, which can be overwhelming at first. If you are having trouble choosing one, look for recurring jams with established communities, such as:

• Brackeys Game Jam
• GMTK Game Jam
• Mini Jam
• GBJam
• Boss Rush Jam
• Ludum Dare

Choosing a jam matters, but it is even more important to understand why you want to jam. Do you want to meet other aspiring game developers? Try out a new technique or workflow? Sharpen a particular skill? Knowing your goal will help you choose a suitable jam, find like-minded teammates, and be more intentional about the time you spend participating.

That leads to finding a team. Most game jams have a forum, Discord server, or other community space where participants discuss the jam, share progress, and look for collaborators. You will find people looking to work in specific roles, as well as teams looking to fill gaps.

A good team-search post should include:

• Role: What you do.
• Experience or tools: Your relevant skills, engine familiarity, or past work.
• Availability: Your time zone and how much time you can contribute.
• Looking for: The roles or type of team you hope to join.
• Portfolio: A link to previous work, if you have one.

If you do not yet have a portfolio, I encourage you to make one. It does not need to be elaborate. Even a small collection of past projects, sketches, music, writing, or prototypes can show potential teammates what you would bring to a project.

There are a few types of posts and teams that I tend to avoid. For example, I am cautious when a team has already decided exactly what game it will make before the jam begins. That may work for some groups, but it can feel less collaborative if new members are being asked to execute someone else's personal project. I prefer teams where everyone has some ownership over the game's concept and direction.

I also tend to avoid very large teams, especially when the members are strangers to one another. There is nothing inherently wrong with a large team, but communication and decision-making become much harder as team size increases. I prefer smaller teams where everyone has a shared understanding of the project and can contribute to important decisions. That said, take this advice with a grain of salt. Larger teams can absolutely produce great jam games, particularly when the members already know and trust one another. For example, Pip Flip Paradise and Hickory came from teams of seven or more. If you already have a group you work well with, there is no reason not to jam together.

So, let's say you've found a team, either a group of new people or familiar friends. You can set yourselves up for success by establishing clear communication before the jam begins. Here are a few tools your team might use:

• Discord for group chat and quick updates.
• Google Docs for design notes and shared planning documents.
• Git for version control, including game assets when appropriate.
• Trello for task tracking.
• Miro for moodboards and visual brainstorming.
• itch.io for the eventual submission.

You do not need every tool on this list. In a short jam, too many tools and communication channels can create more work than they save. If a single update requires changing a Miro board, editing a document, and posting in two Discord channels, the process will quickly feel clumsy. Keep communication overhead low. The easier it is to move between chatting, planning, and making the game, the better.

It is also important to establish how everyone works. Share your availability and time zone so the team can set realistic expectations. Let your teammates know what kind of work you enjoy, where you feel confident, and where you might need support. You may have shared a portfolio already, but this is also a good time to discuss your creative preferences before the design process begins.

A composer might share their biggest inspirations. An artist might mention a style they want to explore during the jam. A programmer might explain that they are trying a new tool or engine feature. A writer might mention a type of story they would rather avoid. These details are useful context. During the design phase, the team can account for one another's interests and limits so that everyone has a project they are excited to make.

Now your tools are set up, your team knows a little more about one another, and everyone has access to the project repository. The jam is about to begin, and you're ready.

First Hours of the Jam

Most game jams have a theme or prompt. Some recurring jams have an ongoing constraint as well. GBJam, for example, focuses on games that could plausibly run on a Nintendo Game Boy, while Boss Rush Jam centers on encounters with imposing foes. Other jams reveal a fresh theme when the event begins.

In addition to the jam's rules, there is usually a prompt that is not revealed until the event begins. That opening prompt gives every participant a common starting point. It also helps ensure that the games are made during the jam itself and have a throughline among them.

A theme like “Unlucky” might inspire mechanics built around uncertainty: card games, dice rolls, gambling, or risk management. “Trust No One” could lead to riddles, hidden information, suspicious characters, or observation-based challenges. The GMTK Game Jam's 2026 theme, “Count Down,” produced thousands of different interpretations of the same simple phrase. Browse GMTK's jam archive for examples.

The first few hours of the jam are laser-focused on this prompt. All the participants will be asking themselves, “What game can we make that responds to this prompt in an interesting way?” Now is the time to put on your design hat, break out a notebook, and let your imagination run amok.

My first recommendation may sound counterintuitive: do not immediately brainstorm as a group. Give everyone twenty to thirty minutes to think on their own first. Some of the jam games I am most proud of began with each team member generating ideas independently, then coming together to share, combine, refine, and choose an approach.

As you process the prompt, let your brain toss and turn it, and while it's doing that, start brain-dumping onto paper. What games, films, books, or real-world experiences does it remind you of? What nouns, verbs, and adjectives capture its feeling? What situations could it create? Do not judge your ideas too early. The goal is to have material to work with when the team reconvenes.

It can help to think about ideas along two dimensions:

• How simple or complex is the game?
• How familiar or surprising is its interpretation of the prompt?

Let's illustrate this with GMTK's 2026 theme, “Count Down.” A simple idea would be to have a player complete a level or puzzle within a certain amount of time. This would be a fairly straightforward game to build and would lead to an intuitive, understandable playing experience. Depending on their goals, that will work wonderfully for some developers and designers. However, those with more development or design experience may think, “I've already made or played that game,” and want a more novel experience.

Maybe they make the game more complex by ditching the initial race-against-time idea altogether, or by tuning it to be more interesting. You could add complexity by giving the player only three seconds to complete each level. That immediately creates design questions: Are there checkpoints? Can the player earn extra time? Do combos multiply the remaining time? Are there obstacles that drain time faster?

Complexity can make an idea more interesting, but it comes at a cost. Every new rule is something the player must learn and something the game must teach clearly. You can also add complexity in directions unrelated to the central prompt: combat systems, upgrades, movement abilities, or more elaborate level design. Just be careful that your design isn't spread too thin. It's better to do a couple of things really well than touch lightly on many mechanics. Highly rated jam entries often have surprisingly simple, clever mechanics executed with a great user experience.

A surprising idea does not need to be complicated. It often takes one familiar rule and gives it a meaningful twist. Completing a level before a timer expires is familiar. Completing a level in three seconds is more unusual. Now imagine that the player is a parasite with only three seconds to survive in each host, so they must constantly jump to a new host to stay alive.

The time limit is no longer just an interface element. It becomes part of the game's fiction, its tension, and the player's decisions. One way to estimate the strength of a jam concept is how well it does these three things:

1. Twist a familiar expectation.
2. Make that twist meaningfully affect play.
3. Create a believable scenario or fantasy.

You can learn a lot by playing games from past jams. The example above was the driving concept for Chronophage. Look for entries that use one clear mechanic, teach it quickly, and build an entire experience around it. Count Me Dead twists tense quick-draw duels into charming tests of attention and brainpower. Lucky Punk turns bullets in a revolver chamber into a deck-building resource. Sleep Walker offers another useful example of a familiar genre with an unexpected player role. Good game design can come from anyone, but good taste develops through intentional play.

When you come back together, share ideas without becoming too attached to your own. A teammate's rough idea may inspire a better version of yours, or two unrelated ideas may combine into something stronger. In my experience, this kind of cross-pollination produces some of the most memorable jam concepts.

As the team discusses ideas, collect references that clarify the direction you are considering. A small shared folder, document, or Miro board is enough. Gather a few examples for the visual style, sound and music, game feel, interface, and specific mechanics you want to study. References should help the team communicate clearly, not become a pile of inspiration that nobody revisits. Use them to identify what you want to capture, then create your own version of it.

Once you've agreed on an idea that all team members are happy with, communicate to set a scope for the game. This is where the abstract idea starts to become concrete tasks, and you should get a sense of what you'll be able to accomplish within the allotted time.

Your game does not need to be an hour-long experience. A short, focused, polished game is usually more enjoyable than a longer game with many underdeveloped ideas. Define the smallest version that delivers the central idea.

Once you've decided on your initial tasks, it is time to get to work and start development.

Development During the Jam

There are a lot of different roles that could contribute to a game jam game, so I'll keep my development advice role-agnostic.

Firstly, try to update folks on progress frequently. During a jam, it's great to see the game slowly coming together over time. Conversely, silence during a jam can allow anxiety or confusion to creep in, slowly draining motivation. Sharing work frequently also allows for a feedback loop in which everyone can adapt and adjust toward a central vision.

An artist might share character art and animations, prompting a writer to rethink dialogue or characterization. A developer might share a clip of the prototype, helping the composer decide which sound effects would support the game best. A writer might share an early narrative draft that establishes a tone for the art direction and music.

Just like their namesake, game jams benefit greatly from the back-and-forth interplay of different elements. The game becomes stronger when people can see one another's work and respond to it.

A game jam can also be a great portfolio opportunity, regardless of your role. If that is part of your goal, feel free to challenge yourself. Just remember that a jam has a strict time limit. You will not have time to make every part of your work perfect, and that is understood when people look at game jam projects. Aim for work you are proud of, then focus on getting it into the game.

During development, prioritize the core game loop. The team should build a playable version of the primary mechanic as early as possible. If you are programming, prototype the core interaction first. If you are creating art or music, focus first on the assets that make that core interaction readable, satisfying, and complete. Build outward from there.

Life can interrupt a jam at any time. Someone may get sick, have an emergency, lose a day of work, or simply run out of energy. That is why it is so valuable to have a very early version of the game, even if it is rough. A small working game is a much better foundation than a large collection of disconnected assets and unfinished systems. Make sure you have a version zero of the game as soon as possible.

Now, if you're jamming and you find that you're having a ton of fun, great! Still, pay attention to your pace. You do not want to reach the final stretch feeling overwhelmed by the amount of work remaining. This is where your earlier planning and scope decisions matter most. If you need to cut a task or feature, communicate that as early as possible. Cutting work early can save your teammates from spending time on assets or systems that will never make it into the final build.

A key perk of creating the core game loop early is having a first draft of your game experience built. This is where teammates can play the game, run into bugs, hit snags, get confused, and find all the ways in which the game could be better. Finding problems is good. Do not expect the game to work perfectly on the first attempt. The earlier you uncover an issue, the more time you have to address it.

You can prevent many avoidable problems by giving and requesting clear implementation guidance. Tell the developer whether a character animation should loop. Ask what material a door is made from before creating its sound effect. Create a simple interface mockup so the developer understands how the screen should be arranged. If something is unclear, ask instead of guessing.

Now for the end of the jam: make sure to budget at least an hour and a half for submission time. Some jams allow late submissions or grace periods, but many do not. Try to have a submit-ready build well before the deadline.

Playing the game from its actual itch.io page often gives you a fresh perspective. You may notice a missing instruction, a broken download, an unclear control, or a small presentation issue that did not stand out during development. In my experience, there are almost always last-minute adjustments to make, so leave yourself enough time to make them without panic.

The Games

You have finished your game, exchanged virtual high-fives with your teammates, and submitted your entry. The hardest part is over, but the fun is not. Now you get to enjoy the fruits of everyone else's labor by playing their jam games.

This is one of my favorite parts of a game jam. The experience shifts from an intense development sprint into something closer to a small festival. Dozens or even thousands of teams have interpreted the same theme in completely different ways. Playing their games is an opportunity to celebrate that creativity and learn from the choices they made.

It is also your chance to give back to the jam community. Play other teams' games and leave feedback when you can. Honest, thoughtful feedback helps developers understand what worked, what was unclear, and what issues stood out during play. Even a short comment about a mechanic, visual, sound effect, or moment you enjoyed can mean a great deal to the people who made it.

Try to be specific. Instead of only saying, “Great game,” explain what made it memorable. Did the controls feel satisfying? Did the game teach its central mechanic clearly? Did the art establish a strong mood? Did the game make you laugh, feel tense, or want to try again after failing? Specific feedback is more useful, and it helps you think critically about your own experience as a player.

Playing other jam games will also strengthen your own design instincts. What makes a game frustrating? What makes another game easy to understand? What turns a familiar idea into something surprising? Have fun while you play, but pay attention to how each game makes you feel and why.

As time passes, you will likely receive feedback on your own game as well. That is valuable. It can show you what players enjoyed, what did not click, and whether the experience matched your team's intentions. Keep an open mind and an open heart when reading it. Positive and negative feedback are both useful signals that can help you grow throughout your game development journey.

Whether your first jam ends with a polished little game or an unfinished experiment, you will have learned something valuable. You will have practiced making decisions under pressure, collaborating with others, adapting when plans change, and turning an idea into something people can play. That is worth celebrating. Take what worked with you, learn from what did not, and bring both into your next jam. The best way to get better at game jams is simple: keep making games, and keep having fun playing them.