Starforge Template: A Wave Shooter You Edit by Chat

Starforge template: a wave-based space shooter you can reshape

Starforge is a playable arcade shooter, one of the five game templates in the Zugo gallery of 25. Your ship auto-fires while you steer, enemies arrive in waves, every fourth wave brings a boss, and drops upgrade your guns. Cloning it into a project costs no credits, and edits go from there.

It runs in a browser canvas in 2D, on desktop and on phones. Below is what a round actually contains, which parts are solid, and how to turn it into a different game without breaking the loop.

What happens in a round of Starforge?

You start with three lives and a ship that fires on its own, so the whole game is about where you are rather than when you shoot. Enemies stream down in waves, and the wave number is the difficulty dial: more of them, faster, with tougher types unlocking as you go.

The escort before a boss is a nice piece of pacing that most first attempts at this genre miss. It clears the screen, gives you a breath, and makes the boss entrance read as an event rather than as another spawn.

When you lose your last life the run ends with the wave you reached, and Enter or Space starts the next one. The game also pauses itself when the tab loses focus, which sounds trivial until you alt-tab mid-boss and come back to a dead ship.

How does the ship control?

Two schemes ship together and both stay live. On desktop you steer with the arrow keys or WASD and hold Space to focus-fire, which narrows your movement for accuracy. On a phone or with a mouse you drag, and the ship follows your finger with a slight lag that keeps it from feeling twitchy.

Sound is generated in the browser rather than loaded as audio files, so there are no media assets to host and nothing to wait for. It also means there is no mute button, which is the single most common first edit people make before showing the game to anyone.

Which parts are worth keeping, and which are placeholders?

The loop itself is the valuable part. Spawning, collision, the wave curve, the drop timing and the boss cadence are tuned to feel fair, and that tuning is exactly what takes longest when you start from an empty prompt. Keep the skeleton and change what sits on top of it.

The presentation is the placeholder. The name, the palette, the ship silhouette, the enemy shapes and the banner text are all cosmetic, and all of them move in a single edit each. A reskin from space to underwater, insects or medieval siege changes nothing about how the game plays.

The score is honest but temporary. The best score shown on the title screen resets when the page reloads, because the template has no storage behind it. A leaderboard that survives visits needs a real database, which is the Supabase connector rather than a chat edit.

Who should start from Starforge instead of a blank prompt?

Start here if you want a shooter and you care more about how it feels than about how it was built. You get a working difficulty curve on the first click, and the gap between a rough shooter and a fun one is almost entirely in that curve.

Start here too if the game is a means to an end: a landing page toy, a conference booth attraction, a class exercise, a birthday present with someone's face on the boss. In all of those, the loop matters less than the theme, and the theme is the cheap part to change.

Describe it from scratch instead when the mechanic is genuinely different. A tower defence, a turn-based fight or a physics puzzle shares almost no code with this, and edits would spend credits deleting what is here. The wider question of what the builder can and cannot do with games is covered in can AI build a game.

How do you reshape it without breaking the loop?

Change one system at a time and play a round after each edit. Games differ from sites here: a page either renders or it does not, but a game can look perfect and feel wrong, and only playing shows you which.

1. Reskin first. Name, colours, ship and enemy shapes, background. Cheapest change, biggest apparent difference.
2. Then the numbers. Lives, wave size, speed ramp, how long drops last. This is where the difficulty actually lives.
3. Then the boss. Health, attack pattern, how often boss waves come round.
4. Then a new mechanic. A shield, a bomb, a second weapon. One per edit, so you can tell what changed.
5. Then the shell. Title screen wording, mute control, the game-over message.
6. Publish and watch someone play. The address looks like yourgame.zugo.run, and your own domain can sit on top.

Precise prompts win here more than anywhere else. "Make it harder" gets you an interpretation. "Give bosses twice the health and make boss waves every third wave instead of every fourth" gets you the change you meant, and you can feel it immediately.

What does reworking a game cost?

The clone is free and calls no AI, so nothing is spent until the first change. Tuning a game usually takes more edits than finishing a landing page, because you are chasing a feel rather than a layout, so budget on the higher side.

Free gives you 5 credits. Pro is $25 a month for 200 credits, roughly 66 edits, which is far more tuning than any single arcade game needs. Business is $99 a month for 800 credits. Every build is opened in a sandbox before it reaches you, so a version that fails to run is never handed over.

A simple build takes around a minute, and a reskin edit is quicker than the round you play to check it. That ratio is what makes iterating on a game practical: the waiting is not the bottleneck, deciding what to change is.

Which edits do people ask for most?

"Add a mute button in the corner and remember the setting." "Put my logo on the ship and make the enemies match our brand colours." "Add a shield power-up that absorbs one hit and shows as a ring around the ship."

Difficulty requests come constantly, and the good ones are specific: "make the first three waves slower so new players survive longer, and keep the ramp after that." Vague ones cost the same 3 credits and give you something you then have to measure by playing.

Mobile requests are worth making early: "make the canvas fill the phone screen in portrait and keep the drag control comfortable for a thumb at the bottom of the screen." Most people you send a game link to will open it on a phone.

How do you know the game actually got better?

Play three full runs before and three after, and write down the wave you died on each time. It is a crude measure and it is still better than an impression, because your impression of difficulty shifts as you get more practice at your own game.

Watch one other person play without explaining anything first. The place where they get confused in the first ten seconds is almost always the control hint, not the game. That single observation usually pays for the whole editing session. Writing prompts that produce checkable changes is covered in how to write a good prompt.

Where are the honest limits?

Games here are 2D and run in a browser. There is no 3D engine, no native app build, no console target. For a shooter that is not a real constraint, but it does define the ceiling.

No scores survive without a database. The best score on the title screen lives only in the current page. A shared leaderboard needs storage and identity, which is a separate stage of work rather than one chat message.

Very specific game logic is reached by editing, not by one prompt. Multi-phase bosses, saved progress, an unlock economy: all reachable, none of them arriving in a single request. On a genuinely complex product Zugo does not replace a development team, and the source is always yours through the GitHub export. How the whole gallery is organised is laid out in the Zugo templates guide.

The fastest way to judge it is to play it. Open the gallery at zugo.dev, start Starforge in the preview, survive to the first boss, and you will know within two minutes whether this is the loop you want to build on.