All posts

NOTES FROM THE STUDIO

How I Vibe Coded a Billiards Game with Godot in Three Weeks

How I built and shipped Pool Max in three weeks with Godot, Codex, fast prototypes, and lessons from low-end Android devices.

Three weeks after starting, I published Pool Max, my mobile 8-ball game. I built it with a vibe-coding workflow: describe a feature to Codex, play the result, spot what feels wrong, and iterate. Today, players complete roughly 30 matches a day. Seeing real matches every day is the best reminder that the game is no longer just a project on my computer.

You can see the game on the Pool Max website. Here is how it went from a rough prototype to a Google Play release, including the parts I would change next time.

Pool Max lobby showing Play 8 Ball and Play Solo buttons, along with store, cues, and leaderboard navigation.
Pool Max lobby during development.

Why I chose Godot

I wanted an engine that would stay out of the way while I experimented. Godot is lightweight, starts quickly, and supports multiple platforms. That mattered when I was moving between a desktop development loop and an Android game.

Codex also worked well with Godot through Godot MCP. I could turn a requirement into a scene or code change, run the game, show what was wrong, and ask for the next adjustment. The useful part of AI-assisted development was not a magic prompt that built the whole game. It was the speed of that feedback loop.

First, make the shot fun

My first milestone was a playable prototype, not a polished menu. The design was primitive. I focused on whether aiming and shooting felt satisfying, whether the balls behaved predictably, and whether obvious bugs interrupted a match. A pretty screen would not have helped if the physics made a shot feel unfair.

I also mapped the core player flows before dressing them up: entering the game, starting a match, taking a turn, handling the result, and choosing what to do next. That map helped me see which screens and controls were essential for a first release.

Pool Max practice game showing the pool table, racked balls, cue ball, cue stick, and aiming guide.
A Pool Max practice table with the aiming guide visible.

Turning screenshots into a real interface

Before generating assets, I listed the UI elements the prototype actually needed: buttons, panels, player information, match controls, and feedback for the next action. Then I used Codex to turn those needs into design requirements and screenshot concepts.

Once I had a visual direction, I used Codex Goal mode to work from the screenshots toward a pixel-perfect implementation. I compared the running game with the reference, corrected spacing and proportions, and repeated. Some screens took several passes. The screenshot was a concrete target, not a substitute for checking the game on a device.

I shipped before everything was perfect

I did not wait for the game to feel finished. Some parts were rough and some issues were still there when I submitted it to Google Play. Getting a real build into players’ hands showed me which fixes mattered most. I released follow-up versions quickly instead of holding the whole project until every detail was settled.

You can play Pool Max on Google Play.

Pool Max Google Play promotional image showing an 8-ball table on a phone with the words Make Your Break.
Pool Max promotional screenshot from the Google Play listing.

The low-end Android performance detour

The hardest technical surprise was performance on lower-end phones. The Godot 4 build did not behave the way I wanted on every device, so I had to downgrade to Godot 3.6/GLES2 in a separate migration project. I tested the port on a Galaxy J7.

The current Google Play build still uses Godot 4.7.2 Compatibility. The 3.6 port is a tested migration prototype, and I am continuing it before it can replace the full production game. It has already changed how I think about choosing an engine version: test on the weakest target device early, not after the interface and gameplay are built.

What I would do differently

If I started again, I would create a reusable UI component library before implementing the full interface. I would separate buttons, cards, panels, and status elements into components with shared rules, then build screens from those pieces. I arrived at visual consistency through repeated corrections; a component library would have given me that consistency earlier.

Conclusion

Three weeks were enough to launch Pool Max, but not enough to finish learning how it should feel. The most useful part of vibe coding was making each iteration cheap: the prototype told me whether a shot was fun, screenshots gave the UI a target, real phones exposed performance problems, and players showed me which fixes mattered.

Pool Max is live, and I am still improving it one release at a time. You can follow the game on the Pool Max website or play it on Google Play.

All posts