Make a Space Shooter Game With AI: Waves and Weapons
Make a Space Shooter Game With AI: Waves and Weapons
A space shooter is one of the safest genres to describe in text. Name the ship, the firing rate, how enemies arrive and how you lose, and Zugo returns a playable 2D browser game in about a minute. Building costs 6 credits, and every edit after that costs 3.
The reason it works so well is that the genre is made of numbers. Fire rate, enemy speed, spawn interval, lives: all of them are single values a generator can set and you can change by asking. The design work is choosing what those numbers should be, and that is done by playing.
What kind of shooter actually comes back?
A vertical arcade shooter by default: your ship at the bottom, enemies entering from the top, bullets travelling upward, a score, and lives you can lose. Say "horizontal" or "top-down" in the prompt if you want a different orientation, because the generator will not guess.
Collision, scoring and a game over state come out connected rather than as decoration. That matters more than it sounds. A shooter that draws bullets but does not register hits looks correct in a screenshot and dies on the first real input.
Every build is booted in a sandbox before it reaches you, so one that fails to load is marked as a failed build instead of arriving as a black rectangle. The sandbox verifies that the game runs. Whether the game is exciting is a separate question that only playing answers.
Should you start from Starforge or from a blank prompt?
Zugo ships 25 templates and five of them are games, one of which is Starforge, a wave-based space shooter. Cloning it puts a working game in your project without spending credits, which changes the arithmetic of where to start.
| Your situation | Better start | Why |
|---|---|---|
| You want a shooter today | Starforge template | It is playable before you change anything |
| Your idea is close to arcade classic | Starforge template | Repainting beats rebuilding |
| The mechanic is unusual | Blank prompt | Fighting someone else's rules costs edits |
| You want to learn the workflow | Starforge template | A working example teaches faster than theory |
| The game is one part of a larger site | Blank prompt | The build should match the surrounding project |
The template is walked through in the Starforge template. The honest trade is that a template gives you a fast, familiar shooter, and a prompt gives you a shooter shaped like your idea at the price of more iterations.
What does the prompt need to say?
Six specifics, and the first build lands close to finished.
| Element | Weak wording | Wording that works |
|---|---|---|
| Ship | "a spaceship" | "ship at the bottom, moves left and right, follows the mouse too" |
| Firing | "it shoots" | "fires automatically twice a second, bullets travel straight up" |
| Enemies | "aliens" | "enemies drop from the top in rows, drifting sideways as they fall" |
| Waves | left unsaid | "a new wave every ten seconds, each one slightly faster" |
| Failure | left unsaid | "three lives, a hit costs one, zero lives ends the run" |
| Reward | left unsaid | "points per kill, wave number shown, best score kept" |
Automatic fire is worth defaulting to. Held-key shooting turns into finger fatigue in under a minute, and it makes the difficulty curve depend on how fast someone can tap rather than on the game.
Say what should not exist as well: "no menu, no ship selection, the run starts on load" prevents a title screen you would only delete later. Prompt structure in general is covered in how to write a good prompt.
Why does the shooting feel flat?
Because a hit that produces no reaction reads as a bug. Three edits fix nearly all of it, and none of them touch the rules.
Impact feedback. Ask for a brief flash on the enemy, a small burst where it dies, and a short sound. The player needs the game to acknowledge them within a frame or two, or the whole thing feels like clicking on a spreadsheet.
Bullet visibility. Default projectiles are often small and the same brightness as the background. Ask for bright bullets with a faint trail against a dark field, and readability sorts itself out.
Firing rate. Slightly too slow feels sluggish, slightly too fast turns the screen into a wall and removes any need to aim. Start under what feels right and raise it in one step.
A fourth, less obvious one: enemies that appear exactly where your ship already is. Ask for spawns to keep clear of the player's column and unfair deaths mostly stop.
How should the waves escalate?
Difficulty in this genre is a schedule, so describe it as one. A wave that is faster and denser than the last is the whole curve, and it is more legible to a player than a single number creeping upward.
The pattern that reads best is short waves with a visible gap between them. The gap lets the player breathe, notice their score, and feel the next wave start. Continuous spawning erases the rhythm and every run blurs into the same one.
Add variety through behaviour, not artwork. One enemy type that dives, one that drifts sideways, one that takes two hits, and the same shooter suddenly asks the player to prioritise. That is three edits, and it is the difference between a demo and a game people replay.
How do you handle touch and small screens?
Touch has to be requested. The best default for this genre is that the ship follows the finger and fires by itself, because a virtual joystick plus a fire button leaves no space for the game on a phone.
Ask for the playing field to be a portrait rectangle fitted to the screen, with the score and lives outside the action rather than on top of it. Overlapping the score on the play area is a small mistake that costs you a life every run.
Test on the published address on a real phone. The sandbox check tells you the game loaded, not whether a thumb covers a third of the screen, and that difference is only visible on hardware somebody is actually holding.
What does a finished shooter cost?
Slightly more than a puzzle game, because tuning is the work here and tuning means edits.
| Action | Credits |
|---|---|
| Build the game | 6 |
| One edit | 3 |
| Hi-Fi build | 12 |
| Hi-Fi edit | 6 |
A realistic route is one build plus five or six edits: fire rate, hit feedback, wave pacing, an extra enemy type, touch control, and a game over screen worth restarting from. Pro is $25 a month for 200 credits, roughly 33 builds or 66 edits, and Business is $99 a month for 800 credits.
Free grants 5 credits, which is under the cost of one build, so a shooter from scratch does not fit there. Cloning Starforge costs no credits, which is the way to see a working shooter without paying for one.
Where does the genre hit its ceiling?
Games are 2D and live in the browser. Arcade shooters are native to that space, so the limit rarely bites, but a 3D engine project is not on the table no matter how the prompt is phrased.
Persistent leaderboards need a database, which means connecting Supabase and accepting that it is a layer on top of the game rather than a chat message. The same goes for accounts and saved progress across devices.
Boss fights with scripted phases, upgrade trees and unlockable ships are all reachable, but through a sequence of edits rather than one prompt. That is the intended workflow, and it is the honest answer to what a single description can carry. The code stays yours and exports to GitHub, and for anything commercial Zugo does not replace a development team.
What is the fastest route to something worth sharing?
Decide three things before typing: orientation, whether fire is automatic, and how many lives. Then describe the game in two sentences and let the first build be plain.
Play one full run, fix feel before content, and only then add a second enemy type. A shooter that feels good with one enemy is better than one that feels mushy with six. If you want the same loop from a different angle, the aiming problem changes completely in a top-down shooter.
Publish to an address like your-game.zugo.run, send it to three people and watch where they die. Start at zugo.dev.