Vibe Arcade Blog

Dev stories, game design, and the art of building with AI

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.

· Vibe Arcade

game dev vibe coding AI tools behind the scenes

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 Now

Phase 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:

  1. Describe the game concept in the chat
  2. Gemini generates code; Canvas renders it as a live preview
  3. Play the game right there in the chat interface
  4. Describe what's broken or what you want to change
  5. Gemini updates the code; Canvas re-renders immediately
  6. 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 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:

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:

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