How We Built Space Destroyers With AI: From Gemini Chat to Playable Game
A behind-the-scenes look at how a browser space shooter goes from an idea to an arcade-ready game — using AI chatbots, copy-paste workflow, and eventually a full AI IDE.
Space Destroyers started in Google Gemini's Canvas — not a code editor, not an IDE, not a terminal. Someone described a space shooter, Gemini generated the code, and Canvas rendered it as a live, playable game right inside the chat interface. That was the first version of what would eventually become our flagship game.
This is the story of how that happened, what the workflow actually looked like at each stage, and how the tools and process evolved from "build it in Canvas" to a full AI IDE with deployment. It's honest, not polished — because the honest version is more useful to anyone trying to build something similar.
Want to play first, then read the build story?
▶ Play Space Destroyers NowPhase 1: Gemini Canvas — See It While You Build It
The thing that made Gemini Canvas so effective for getting started was the immediacy. You describe what you want, and the game appears right there in the conversation — playable, visible, no separate browser tab needed. That visual feedback loop is incredibly powerful when you're exploring a concept.
The prompt was straightforward: a space shooter with a retro neon aesthetic, enemy waves, and some kind of progression. Gemini produced a complete HTML file and Canvas rendered it inline. You could play it immediately, describe what to change, and see the updated version seconds later — all without leaving the chat.
The Canvas workflow looked like this:
- Describe the game concept in the chat
- Gemini generates code; Canvas renders it as a live preview
- Play the game right there in the chat interface
- Describe what's broken or what you want to change
- Gemini updates the code; Canvas re-renders immediately
- Repeat — the iteration loop is remarkably fast
This approach got us surprisingly far. Because you could see and play the game at every step, you caught issues immediately. "The ship moves too slow." "The explosions need to be bigger." "Add a shield power-up." Each iteration was visual and tangible — not abstract code review. By the time we'd gone through a few dozen iterations, we had a genuinely full-featured space shooter: multiple enemy types, boss fights, power-up drops, a scoring system, particle effects, and mobile touch controls. All built inside a chat window.
What Gemini Canvas Got Right
It's worth being specific about what this approach produced well:
- The initial game loop: Move ship, shoot bullets, hit enemies, score points. All working in the first output.
- Visual style: When given the neon retro-futuristic aesthetic direction, it produced canvas-based rendering with glowing particle effects that looked immediately compelling.
- Enemy variety: Multiple enemy types with distinct movement patterns emerged without much prompting. The AI seemed to know that a good space shooter needs behavioral variety.
- Rapid feature accumulation: Because Canvas let us see every change instantly, we could add features at a pace that wouldn't have been possible with a copy-paste-to-file workflow. Boss fights, upgrade paths, mobile controls, game-over screens — each took minutes, not hours.
The first playable version was legitimately fun. That's not a small thing. A lot of prototypes never get past "technically works." This one was immediately engaging — and Canvas was a big reason why, because the visual feedback kept the creative momentum going.
Where Canvas Hit Its Limits
The Canvas workflow was excellent for building the game in isolation. The problems started when we decided to actually publish it.
Space Destroyers was a single HTML file with everything inline — CSS, JavaScript, game logic, all in one document. That's fine when you're iterating in Canvas. It's a problem when you need to integrate the game into a website with shared navigation, a leaderboard API, play tracking, and a consistent design system.
The core friction: every time we wanted to add a feature or fix a bug in the game, we'd iterate on it in Gemini Canvas, get it working, and then have to manually re-integrate it back into our web page. Extract the updated JavaScript, merge it with the site wrapper, test that nothing broke in the integration. Then do it again for the next change. The round-trip cost was high and grew with every iteration.
Canvas also had a tendency to inadvertently change things we weren't trying to change. You'd ask for a new enemy type, and the power-up system would subtly break. Or you'd fix a mobile layout issue, and the score display would shift. Gemini was regenerating the full file each time, and with a growing codebase, these regressions got harder to catch. We had to start checking more carefully for edge cases after every change — which slowed down the fast iteration loop that made Canvas so appealing in the first place.
The final trigger for switching tools: the game had grown past the point where a single inline file was manageable. We needed to restructure from a monolithic HTML page to a proper project with separated CSS, JavaScript modules, and external dependencies. That kind of structural refactoring is exactly what Canvas isn't designed for.
Phase 2: Restructuring and Moving to Antigravity
The move to Antigravity — a full AI IDE built for vibe coding — wasn't just about switching tools. It required fundamentally restructuring the game first.
The Canvas version of Space Destroyers was a single HTML file with inline CSS and inline JavaScript — everything in one document. That's the natural output of a chatbot: one self-contained file. But to integrate it into a real website with shared navigation, global styles, tracking scripts, and a leaderboard API, we needed a proper project structure: separated CSS files, JavaScript as external modules, HTML as a template that pulls in dependencies. Antigravity handled this restructuring naturally because it understands multi-file projects — something Canvas couldn't do.
The key differences from the Canvas workflow:
- No copy-pasting or re-integration: Changes are applied directly to the correct file. Describe what you want, Antigravity edits the code in place. No more extracting game code from Canvas and merging it back into a web page.
- Multi-file awareness: Antigravity knows what files exist in your project. You can say "update the enemy spawn logic" and it knows which file to edit without you pasting the relevant code into the prompt. This was the biggest upgrade from Canvas — changes to the game didn't accidentally break the site wrapper, and changes to the site didn't accidentally break the game.
- Auto-publish: One of Antigravity's differentiators is that it can push changes directly to deployment. In our case, that means pushing to Cloudflare Pages — the game is live within seconds of an approved change. No more manual deployment step.
- Persistent context: Unlike a Canvas session, the project context persists. You can return to a game days later and pick up where you left off without re-explaining what you built. This was critical as Space Destroyers grew more complex.
The Space Destroyers that exists today — with boss fights, Vibe Core collection mechanics, multiple upgrade paths, and a global leaderboard — largely took shape during this phase. Canvas had established the core game and proven the concept was fun; Antigravity enabled the depth, the integration, and the ongoing iteration without the re-integration tax.
The Role of Human Judgment Throughout
One thing worth clarifying: vibe coding doesn't mean the human disappears from the process. Every feature in Space Destroyers was a deliberate creative decision. When is the first boss? What does it do? How does the difficulty ramp? What should the upgrade system reward?
The AI executes the vision. The human provides the vision — and the testing. A lot of Space Destroyers' polish came from playing it repeatedly, noticing what felt wrong, and describing the fix. "The boss appears too suddenly — add a warning indicator for 3 seconds before it spawns." "The shield power-up feels useless because the enemies move too fast to dodge anyway — make it also slow nearby enemies for 2 seconds." These are human observations about game feel that an AI couldn't notice on its own.
What We'd Do Differently
If we were starting Space Destroyers today with what we know now:
- Use Canvas for prototyping, but plan the transition early. Gemini Canvas is genuinely the fastest way to go from idea to playable game. But know going in that you'll need to restructure once you're ready to publish. Plan your file separation (external CSS, JS modules) before the game gets too complex in Canvas — it's cheaper to restructure a 300-line game than a 2,000-line one.
- Check for regressions after every Canvas iteration. Canvas regenerates the full file. Get in the habit of spot-checking features you didn't ask to change — especially edge cases like power-up interactions, mobile controls, and score calculations. The bigger the file, the more likely something drifts without you noticing.
- Write down the game design document before coding. Describe the target experience, the core loop, the progression system, and the visual style in a text file before generating any code. It acts as a stable reference for the AI and keeps the vision coherent across sessions — whether you're in Canvas, Antigravity, or any other tool.
- Test on mobile earlier. Several iterations of Space Destroyers had to be significantly revised to work well on touchscreens. This would have been cheaper to catch earlier.
The Result
Space Destroyers is a complete, polished browser game with multiple levels, boss fights, four enemy types, power-up upgrades, and a global leaderboard. It didn't start that way. It started in Gemini Canvas — a game that you could play right inside a chat window.
That origin story is worth knowing — not because it's impressive, but because it's honest. Canvas was brilliant for building and visualizing the game. It hit a wall when we needed to publish, integrate, and iterate on a live site. Antigravity picked up where Canvas left off and turned a prototype into a product. Vibe coding is a real workflow with real phase transitions — knowing when to switch tools is as important as knowing how to use them.
Play Space Destroyers — and see what a full vibe-coding development cycle can produce.
Related reading: Space Destroyers Tips: How to Beat the Boss and Reach a High Score · Free Online Space Shooter Game · What Is Vibe Coding? · Vibe Coding Tools: From Chatbots to AI IDEs