My game concept was simple and well understood, so Codex had no problem getting the project started. It created the basic structure in Godot, set up a playable scene and implemented the core rules. Very quickly, I had something resembling the main gameplay screen where I could move balls around the board and see whether the basic mechanics actually worked.
Within roughly two days, probably 10 to15 hours of actual work, I had the skeleton of the game.
You could start a match, play it and finish it. The basic rules worked. Points counted. Technically, it was already a game.
It just looked terrible.
Everything was built using primitive shapes and default game-engine components. Which was perfectly fine for proving that the idea worked, but it also created the first major lesson of the project: getting something functional with AI was much easier than getting something that looked like an actual product.
Setback #1: making the game look like my game
Godot has an extensive library of assets and endless capabilities to combine them into new, unique designs. If I'd dug deeper into my game engine capabilities, maybe I would have found easier ways to make my game look unique. But instead, my inexperience led me into the woods right away.I convinced myself that if I wanted the game to have any character of its own, I needed custom assets. The problem was that I am not a designer and had very little idea how to make them.
My first attempt was the obvious one: ask Codex.
It wrote Python scripts to generate some of the assets, and we tried a few iterations. The results were abysmal. Images were distorted, visually poor and nowhere near something I would put into the game.
I tried the same approach later for much simpler tasks. For example, taking an existing achievement icon and producing a greyed-out version of it for a locked achievement. Even something that basic often produced unusable results. (At the time, the model I was using in Codex was GPT 5.4)
So I tried option number two: existing asset libraries.
There are enormous numbers of game assets available either for free or for relatively little money. That certainly would have worked technically, but it wasn't what I wanted. A large part of this experiment was seeing whether I could create something that felt like my own product. Reusing recognisable asset packs would immediately make the game feel more generic. Moreover, searching through thousands of images would have added days and weeks to development.
Then I tried ChatGPT image generation.
This was much more promising. I could describe the visual direction, explain what the asset was supposed to do and generate visually interesting concepts very quickly.
But there was another problem: generating a nice image and generating a production-ready game asset are two different things.
Take the balls used in the game as an example. I could ask ChatGPT to explore different visual designs and get some genuinely good results. But getting the exact dimensions, transparency, composition and other requirements needed by the game was much harder. At the time, it would regularly generate backgrounds when I needed transparent PNGs or otherwise produce an image that needed additional preparation before it could actually be used.
Eventually I settled on a workflow that worked reasonably well:
ChatGPT → visual idea/reference asset → Canva → production asset → Codex → game
ChatGPT was good at exploring ideas and producing the visual starting point. Canva was good for resizing, cropping, removing backgrounds and preparing assets properly. Codex was then good at implementing those finished assets inside the game.
This worked, but it was much more manual than I initially expected.
And because I am extremely clumsy with design tools, preparing custom assets became one of the most time-consuming parts of early development. I probably spent three or four days on it.
The code for the game existed much earlier than the visual product.
Setback #2: the game looked great on my screen
The next problem was entirely predictable. I just didn't predict it.I was developing the game on a computer, so naturally I started by designing the interface for the screen directly in front of me.
It worked beautifully.
Then I changed the resolution to something resembling an actual mobile phone.
A significant part of the interface immediately stopped working.
Elements that looked perfectly reasonable on a large monitor became tiny. Some things didn't fit. Others took too much space. Controls that seemed obvious with a mouse suddenly weren't particularly usable on a touchscreen.
My game had an additional problem: the central game board needed to be perfectly square.
Mobile phones are very much not square.
That meant I couldn't simply stretch the gameplay area across the available screen. A large proportion of the display was inevitably outside the board, and I had to work out what to do with that space while keeping the important controls usable on both small phones and much larger desktop screens.
This led to many iterations of the interface.
And there is a simple lesson here that I would absolutely follow if I started again: Start with your most constrained target device.
If the smallest phone you support is the hardest environment for your interface, design for that first. Once it works there, expanding it to tablets and desktop screens is much easier.
Going in the opposite direction creates a lot of rework.
Even in the release version of my game, I still think there is plenty of room to improve the interface across different screen sizes.
Setback #3: localisation multiplies everything
The third problem was completely self-inflicted.I decided from the beginning that the game should support multiple languages.
There was some logic behind it. I wasn't targeting only traditional gamers. I wanted the game to be accessible to casual players as well, and later I added game modes that changed some of the core rules. People needed to understand what those modes did, and letting them do that in their own language seemed important.
So I asked Codex to build a localisation system.
Technically, this worked quite well.
All translatable labels lived in one large CSV file, which made them easy to manage. Codex could generate the translations automatically, and inserting them into the game was relatively straightforward.
The problem wasn't translating the text.
The problem was everything that came afterwards.
A label that fitted perfectly in English might be considerably longer in another language. A button that worked on desktop might now overflow on a phone. Fixing the font size could make something unreadable elsewhere.
Suddenly I wasn't testing one interface anymore. I was effectively testing combinations of: screen sizes × languages × game screens. And that became expensive very quickly.
I spent hours checking text, shortening translations, adjusting interfaces and trying to make everything readable across devices.
So another piece of advice I would give myself now is to think very carefully about whether localisation is genuinely necessary from day one.
If it is essential to your audience, build for it early.
If it isn't, postponing it can save an enormous amount of testing and interface work during the stage when your product is still changing constantly.
Setback #4: Emulators are useful. Real devices are necessary
Eventually I needed to test the game on an actual phone.I initially tried avoiding physical-device testing by setting up an Android emulator through Android Studio.
This did not go well.
The emulator itself worked, but the game refused to launch. Codex and ChatGPT spent quite a bit of time trying to debug the problem. At one point, the proposed solution seemed to involve rebuilding so much of the project that I stopped the process.
It was consuming large amounts of tokens and time to solve a problem that I could avoid by plugging in an Android phone.
So I did.
And interestingly, this was an area where Codex impressed me.
It helped set up Android Studio and ADB, installed builds directly on the phone and could access the device logs when something went wrong. That made debugging dramatically easier because Codex wasn't guessing what had happened - it could actually see the errors being produced by the device.
Emulators still have a useful role. They can catch obvious layout problems and make quick testing easier.
But there is no real substitute for testing on the device you're actually targeting.
This becomes even more important when you start using device-specific functionality. Touch controls already feel different from a mouse, but in my case I was also experimenting with functionality such as the phone accelerometer. You simply need the physical device to understand whether that experience works.
Time sink #0: App stores setup
There was another category of work I had barely thought about when starting this project: administration.AI can write your code. It can debug your Android build. It can generate your store descriptions. It cannot make Apple or Google approve your developer account faster.
Before you can properly distribute and test a mobile game, you need developer accounts, certificates, profiles, store configuration and various pieces of business or personal information.
Some of this is simply tedious. Some of it requires figuring out unfamiliar interfaces. Some of it involves providing documents. And all of it involves waiting. Lots of waiting.
If you register as a business, there can be additional verification requirements. Even individual developer accounts can require identity checks and other setup.
None of this has anything to do with whether your game is technically ready. But it can still stop you from releasing it.
Altogether, I probably spent another 10 to15 hours getting the developer accounts, Play Console and App Store Connect into a state where I could properly start testing and preparing distribution. That doesn't include the time spent waiting for approvals.
This is one of those things I would start much earlier next time. There is very little reason to wait until your product is ready before creating the accounts and completing the verification processes you know you're going to need.
Where was I after two weeks?
Despite all of these setbacks, and many smaller ones, progress was still surprisingly fast.Within around two weeks, I had a game that worked on Windows and on my Android phone.
It no longer looked like a collection of default engine shapes. It was beginning to have its own visual identity. The basic gameplay worked. The interface was usable. I could complete proper matches.
Most importantly, it was fun enough that I kept wanting to test it. I shared the build with a couple of trusted friends. They played it, enjoyed it and gave me a lot of useful feedback that eventually changed the game considerably.
Looking back at those first two weeks, the interesting part is where the time actually went.
Getting the core game mechanics working was relatively fast. Getting from working software to something that looked, felt and behaved like a real game took considerably longer. That distinction turned out to be important throughout the rest of the project.
AI made building the first 70% astonishingly fast.
Unfortunately, products aren't released at 70%.
Ignorance is bliss?
As you probably noted above, most of the setbacks I experienced were 100% self-inflicted and probably 50% avoidable. The key is in the details... and sometimes in the absence of details.Because of how coding agents work today, they are generally tuned to do what you ask them to do. It's a tricky balance: the model is incentivised to deliver the outcome the user requested without going rogue, even when going slightly off course might produce a better solution.
In my game, I have a mode called Crazy Balls. It bends the rules of the classic game by introducing temporary bonuses that alter the gameplay. How did I build it? I brainstormed bonus ideas with ChatGPT, defined how they should work, asked Codex to implement them, and then tested them by playing the game.
That worked, but it took the lion's share of the development time. And it could easily have failed if the game had been even slightly more complex.
What I should have done instead was ask Codex, or even ChatGPT, to simulate the bonuses before I locked down their definitions and implemented them. Better still, I should have started by describing the outcome I wanted and asked them to suggest ways of achieving it.
The old truism still applies: you don't know what you don't know. But LLMs often do. So when you tell an LLM not only what you need, but exactly how you think it should be done, you may get a worse result than if you stay focused on the outcome.
Putting it into product management terms: you might get much better results from LLMs and agentic coding if you focus on describing the value you want to create, rather than describing what to build - or, worse yet, how to build it.