Vibe Coding: How My Icebreaker Game Came to Life Through Collaborative Iteration

Hey fellow game devs! 👋 

I'd like to share something cool that happened while I was working on another project. It was a kind of digression whereupon I started this little icebreaker-themed puzzle game. It turned out to be an example of what "vibe coding" would be like. 

Instead of getting bogged down in rigid specs and requirements, I focused on how the game should feel like to play. It's kinda like when you're jamming with friends and the music just flows—you're not thinking about the technical theory, you're just going with what sounds (or in this case, plays) right.

My Icebreaker Game Adventure

I had worked on the design of this icebreaker game sometime back. It had been on the back burner for a while. Instead of diving into the complex game mechanics, I began with the visual experience. I would say things like:

- "I want it to look like *this* but not like *that*"

- "Make those buttons bigger—they're too tiny to click comfortably"

- "The ship's trail should still show even when it crashes"

These weren't technical requirements—they were about how the game should look and behave. That's exactly how I want to design games! I didn't plan everything out upfront (which honestly, I never do anyway 😅). Instead, it was build, play, and refine:

Basic UI → Compact Layout → Responsive Design → Visual Polish

Each step was driven by "hmm, this doesn't feel quite right" rather than "this doesn't meet the spec." It's so much more natural this way!

When I hit a snag like the ship not responding to mouse clicks in the more difficult levels, I'd engage the AI agent:

- "Hey, why isn't this working?"

- "Oh, it's probably the CSS scaling vs canvas resolution thing"

It's almost like having a coding buddy, but not quite, which can be just as exasperating when it comes to solving an issue with the code!

The whole process was full of these emotional moments:

- "Yes! That's exactly how it should look!"

- "Wait, showing explosions when you win is confusing"

- "The trail isn't displayed when the ship crashes"

I didn't start with the game logic. It was more on how the game should feel to play. I made tiny tweaks constantly.

- "Make those buttons a bit bigger"

- "The trail should render on top of everything"

- "Remove the ship's image and its background when it crashes"

Each change can be immediately tested and rolled back if it didn't work. Although I must add that the cost to make those changes using the AI agent can add up to quite a bit.

The best solutions came from this back-and-forth interaction:

- Me: "The ship's trail still can't be seen when it collides"

- AI agent: "Let me investigate the rendering order..."

- Me: "Oh! The trail should be rendered last"

- AI agent: "Exactly! That makes perfect sense!"

All in all, vibe coding is about leaving the major task of coding to AI. On the flip side, it doesn't relieve you from the work of having to resolve issues when they come up. And the problems DO turn up when you least expect it. It's at those times that AI can seemingly behave human-like when they come up with those idiotic and silliest of responses in their code. At any rate, it's been a fun learning experience.