Game Dev · June 28, 2026

Building a Shmup for a Game Jam: Scope, Speed, and the Art of Shipping

Shmups appear frequently in game-jam entries for a reason: the core loop is tractable in a weekend, the genre conventions are well-understood, and a basic vertical scroller with a few enemy types and one boss is genuinely fun if the controls feel tight and the feedback is good. But shmups also have a longer list of required systems than they appear to — and scoping them wrong is the most common reason a jam entry misses the mark. Here is how to do it correctly under time pressure.

Published June 28, 2026

A game jam shmup has two distinct failure modes. The first is shipping nothing: the team spent two days building a procedural bullet engine and an AI system and never finished the player ship or the enemy sprites. The second is shipping something unplayable: the controls feel floaty, there is no death feedback, the game runs at 15 fps on a laptop, and the single available enemy type fires bullets the same color as the background. Both failures come from misunderstanding what the minimum viable shmup actually requires.

The non-negotiable core: four systems you cannot skip

A jam shmup needs exactly four things to be a playable game that people enjoy. The player ship with responsive movement and firing. At least one enemy type that moves and fires bullets the player must dodge. Collision detection between player, enemy bullets, and player bullets. A death state with restart. That is it. Everything else — power-ups, multiple enemy types, a scrolling background, music, a score system, a boss fight — is additive and should be scheduled after the core is verified to feel good.

The fastest path to a fun core is to use a game engine you already know well, start from a project template or even a prior jam project, and get the player ship moving and firing in the first two to three hours of the jam. If the ship does not feel good to control by hour three, stop building features and fix the controls. A shmup where the player ship controls feel correct is already 40% of a good jam entry, even with placeholder art and no enemies yet.

Time budgeting for a 48-hour jam

A realistic time breakdown for a solo developer on a 48-hour jam shmup with sleep built in:

Hours one through four: engine setup, player movement and firing, placeholder collision detection. Hours five through ten: first enemy type with basic movement and firing, collision detection producing game over, a basic background (solid color or single tile). Hours eleven through sixteen: score display, restart flow, second enemy type or a variant of the first with different patterns, basic explosion feedback. Hours seventeen through twenty-four: boss fight if the core is solid, or additional polish on controls and feedback if not. Hours twenty-five through thirty-six: audio (sound effects are higher priority than music for feel), title screen, win/lose screens, difficulty tuning. Final twelve hours: bug fixing, web export verification, jam page setup, final playtesting.

The boss fight appears at hour seventeen with a conditional because it is significant scope. A jam shmup with no boss but excellent controls, readable bullet patterns, and three polished enemy types is a better entry than one with a spectacular boss fight, floaty controls, and inconsistent feedback. Evaluate honestly at hour sixteen before committing to boss work.

What to cut without hesitation

Power-up systems are usually the first thing to cut in a jam shmup. They require drop logic, pickup collision, visual representation, stacking rules, and loss-on-death logic. A game with a single fixed weapon that fires well feels better than a game with five weapon upgrades where none of them feel satisfying because the polish time was spent on the power-up system rather than the base shot. If you want to include weapon variation, a single double-tap bomb mechanic or a charged shot is faster to implement and almost as engaging as a full power-up tree.

Level editors, procedural generation, and online leaderboards are all post-jam features. Do not begin them during the jam. A jam entry is not a shipped product; it is a compressed prototype that demonstrates a concept. Demonstrate the concept, not the surrounding infrastructure.

What to protect even when time is short

Three things justify time investment even in the last hours of a jam: hit feedback, death feedback, and audio. These are the systems that make a game feel real rather than like a prototype, and they have an asymmetric cost-to-impact ratio. A screen flash and audio cue on enemy death takes fifteen minutes to implement and makes every kill satisfying. Screen shake on player death takes ten minutes and makes the game-over moment land emotionally. A single looping music track — even a free CC0 chiptune from a public library — transforms the game feel more than any feature added in the same time.

Difficulty tuning also belongs in the protected category, and this is where jam developers most often underestimate the work. Your bullet speeds and enemy counts are calibrated to your own reflexes after many hours of play. Fresh players at your jam entry's page will find them brutal. In the last few hours, play-test with the most conservative bullet speeds and densities you can tolerate and then reduce them further. A shmup that a stranger can survive long enough to see the second enemy type will get more play time and more votes than one they bounce off in thirty seconds because the first wave is too dense.

Engine choice and export reliability

Jam shmups that run in the browser get significantly more plays than those requiring a download. Godot's HTML5 export, Pygame with Pygbag for web export, or a native web framework like Phaser all produce browser-playable games. Whichever you choose, test the web export at the beginning of the jam on your build machine, not at the end. Web audio, keyboard focus, and asset loading have engine-specific quirks that can require hours to fix if they surface at submission time. Build and export early; rebuild and test again every eight hours.

The jam itself is not the end of a good shmup prototype. The best jam shmup entries are the ones that get post-jam polish passes: the controls that were 90% of the way there get finished, a second boss phase gets added, the score system that was cut for time gets implemented. A jam is a forcing function for completing the core; the core you ship is the foundation of something worth continuing.