Start Building

I Built a Game in 48 Hours - Here's What I Learned

I gave myself one weekend to go from zero to a playable game. No prior design doc, no art pipeline, no marketing plan. Just a timer, an engine, and a lot of coffee. Here's what actually happened - the good, the messy, and the lessons I'd use again on the next 48-hour run.

Why 48 Hours?

Short time limits force hard choices. You can't polish everything, so you learn what matters first: a clear loop, one or two feelings, and a build that runs. I picked 48 hours because it's long enough to ship something real but short enough that scope creep has nowhere to hide. If you've ever wondered whether you could finish a game in a weekend, this is one way to find out.

The Setup - Before the Timer Started

I did minimal prep the night before:

  • Engine: Unity (already installed and updated).
  • Genre: Top-down arcade - simple movement, one main mechanic, no story.
  • Art: Placeholder shapes and a single free sprite pack as fallback.
  • Sound: One or two free SFX; music optional.

I did not write a GDD, set up analytics, or plan DLC. The goal was one playable build and one lesson per 12 hours.

Hours 0-12 - Core Loop and Feel

Goal: One character, one clear action, one response from the game.

I got the player moving in the first hour. By hour four I had a single "thing" the player does (collect, avoid, or shoot) and one feedback (score, hit, or game over). The rest of the block went into making that loop feel okay - a bit of juice, a simple UI, and a restart flow.

What worked: Picking one verb and one feedback. No secondary mechanics yet.

What didn't: I tweaked movement for too long. In a 48-hour build, "good enough" movement at hour 6 beats "perfect" at hour 20.

Lesson 1: Lock the core loop in the first quarter of the jam. If it isn't fun with boxes and placeholders, it won't magically get fun with art.

Hours 12-24 - Content and One Twist

Goal: A few levels or waves, and one twist on the core loop.

I added a simple progression: three "stages" that were really the same mechanic with more obstacles or a slightly different layout. Then I added one twist - a power-up or a second state - that changed the feel without rewriting the game.

What worked: Reusing one mechanic and reskinning it (faster spawns, different shapes) kept scope small. The twist gave the game a "second act" without a new code base.

What didn't: I briefly designed a second character with different abilities. I dropped it by hour 18. It was the right cut.

Lesson 2: One twist is enough. Two twists is a second game. Save the rest for the next jam.

Hours 24-36 - Polish and Pain Points

Goal: Fix the top three things that make the game feel broken or confusing.

I made a list of the most annoying or confusing moments and fixed only those. One was a collision bug, one was unclear feedback, one was a boring first 30 seconds. I did not add new features.

What worked: Playing the build every hour and writing down "what feels bad" kept focus on impact. Small fixes (better SFX, clearer text, one new particle) made the game feel much more finished.

What didn't: I lost an hour chasing a "nice to have" visual. In a 48-hour jam, nice-to-haves are the enemy.

Lesson 3: Polish the pain points, not the wish list. Players notice "this doesn't feel broken" more than "this has one more effect."

Hours 36-48 - Build, Test, and Ship

Goal: A stable build, one short description, and one place to play it.

I spent the last 12 hours on stability and shipping. I tested on a clean machine, fixed one critical bug, wrote a short description and a few bullet points, and built for one platform (PC). I uploaded to itch.io and shared the link.

What worked: Defining "done" as "playable by someone else" forced me to cut everything that wasn't in the build. The itch.io page was three sentences and a GIF. That was enough.

What didn't: I didn't leave buffer for "last hour" bugs. Next time I'll aim to have a candidate build at hour 44 so the last four hours are buffer.

Lesson 4: Ship the build you have. A finished small game beats an unfinished big one.

What I'd Do Differently Next Time

  • Scope the first 12 hours in advance. I'd write down "one verb, one feedback" and not add a second mechanic until that's in.
  • One art pass, then stop. I'd pick a style (e.g. simple shapes or one asset pack) and stick to it. No "one more pass" on art.
  • Buffer the last 6 hours. I'd treat hours 42-48 as "fix and ship only" - no new features.
  • Record the build early. I'd capture a short clip at hour 24 so I have something to share even if the final hour goes wrong.

Takeaways for Your Own 48-Hour Run

  • Pick one core loop and protect it. Everything else supports that loop or gets cut.
  • Cut early and often. The best feature in a 48-hour game is the one you didn't add.
  • Polish pain points first. Fix what's broken or confusing before adding more content.
  • Define "done" before you start. For me it was "playable by a stranger on itch.io." Yours might be different - but define it.
  • Ship the build. A small, finished game is a win. A big, unfinished one is a lesson with nothing to show.

If you run your own 48-hour (or 72-hour) challenge, bookmark this and revisit it when scope creep hits. And when you ship, share the link - the best part of jams is seeing what other people build under the same clock.

Found this useful? Share it with your team or your next game jam crew. For more on scope and shipping, check out our Launch Your First Indie Game course and our Guide to Game Development with AI Tools.