What a Two Week Game Jam Taught Our Studio

We blocked off two weeks, picked a theme out of a hat and told everyone to finish something playable by the end. No carrying work over, no polishing a favorite old project, just build and ship. We expected it to be a fun break. What we did not expect was how much it would change the way we work on normal projects afterward. This devlog is the honest version: what we made, where the plan fell apart, and the handful of habits from the jam that survived into our regular schedule because they plainly made us better at finishing small games.

Why we ran a jam instead of planning more

Our problem was not ideas. It was a drawer full of half finished projects that each stalled around the sixty percent mark. A jam forces the opposite habit: a hard deadline so close that overthinking is impossible. We hoped that by making something end to end in two weeks, we would relearn how to finish rather than how to start. The constraint was the point. A two week clock removes the option of endless planning and replaces it with the only question that matters, which is whether the thing is playable yet.

Day one went to scope, not code

The most useful hour of the whole jam happened before anyone opened an editor. We wrote down the single core action each game would be built around and crossed out everything that was not that. One person wanted a crafting system, a shop and three enemy types. By the end of the meeting the plan was one enemy and no shop. That felt like a loss on day one and like the only reason we finished by day fourteen. Cutting scope early is painful because you are cutting the parts you are most excited about, which are usually the parts you have no time to build well.

The middle days were where projects nearly died

Around day six the energy dropped. The novelty was gone, the core loop worked but felt flat, and the temptation to start over with a better idea was strong. This is the exact spot where our normal projects usually die, and the jam made it visible. We pushed a rule: no restarts, make the thing you have less bad. Nobody restarted. Every game that felt doomed at day six was fun by day ten, not because the idea improved but because we finally spent time on feel rather than features. The lesson stuck hard, because we had watched the same despair end projects before with no deadline to force us through it.

Playtesting daily changed everything

We handed builds to each other every single day instead of waiting for a polished version. Early it was embarrassing to show something broken. It was also the fastest feedback we had ever had. A bug that would have hidden for weeks got caught in an afternoon because someone else played it with fresh hands. By the end, daily playtesting felt normal rather than exposing. We carried this straight into our main projects, where we had previously guarded unfinished work out of pride and paid for it with late surprises.

What we actually shipped

Three small games, all finished, all rough. One was a one button dodging game that is genuinely fun for about five minutes, which is exactly what it was scoped to be. One was a tiny puzzle that works but needs more levels. One barely made it and taught us the most, because it was the one whose maker refused to cut scope on day one and spent the back half of the jam cutting it anyway under worse conditions. Three finished rough games beat three polished unfinished ones, and we had the drawer to prove how rare finishing had been for us.

The habits we kept

Three things survived the jam. The one sentence core before any code. The no restart rule once a loop works. Daily builds in each other hands. None of these are clever or new. All of them are things we knew in theory and ignored in practice until a deadline made ignoring them impossible. The jam did not teach us techniques, it taught us to actually do the obvious things we had been avoiding, which turns out to be most of the job.

How we run jams now

We do a short one every couple of months, and we treat the output as disposable on purpose. The games are not the deliverable, the habits are. Occasionally a jam game is good enough to grow into a real project, and when that happens it already has a working core loop and a maker who knows it inside out. More often the game gets shelved and the person returns to their main work sharper at finishing. Either outcome is a win, which is why a practice that started as a break became a permanent fixture.

Frequently asked questions

Is two weeks too short to make anything good? It is short enough to force a tiny scope, which is why the games end up good at the one thing they do. A bigger game in two weeks would be bad everywhere. A tiny game in two weeks can be genuinely fun, because all the time went into one action done well.

What if the game feels boring halfway through? That is the normal midpoint slump, not a sign the idea is wrong. Resist restarting. Spend the remaining time on feel, the small response and feedback that make an action satisfying, rather than adding features. Most games that feel dead at the halfway point come alive once the core gets that attention.

Should jam games become real projects? Only the rare one that still feels fun a week later. Most are better left as practice. The value of a jam is the finishing habit it builds, not the games it produces, so do not force a weak jam game to grow just because you made it.

Finishing as a skill you practice

The jam did not give us a hit game. It gave us proof that we could finish, and a short list of plain habits that make finishing likely. Scope small, refuse to restart, test daily. We run jams now not for the output but to keep those habits sharp, because the drawer of unfinished projects taught us that finishing is the part worth practicing.