How I Built a Mobile Game With AI Agents (An Honest Log)

The first board came fast

The early prototype looked like this.

The first playable board. It looked like nothing, but you could swap tiles, form matches, and earn a power. That was enough to prove the core loop could exist.

This is why AI coding agents feel so powerful. When the task is clear, they move quickly.

A specific instruction like this one has a known shape, with many examples of the logic out in the world:

Make a match-3 board where adjacent tiles can swap, matches clear, gravity drops new tiles, and a power appears after a chain.

The agent got me from idea to something playable very quickly.

That first win matters. It gives you energy, something to test, and a reason to stop talking about the idea and start reacting to the product. That is a real advantage.

But once the board existed, the work changed. The question was no longer “can a match happen?”

It became “can this become a game someone would keep playing, trust with their progress, and install from a real app store?”

That is a much harder question.

What the game became

Tropic Tumble grew from that plain board into a full mobile game. It now has an island campaign, thousands of levels, powers, boosters, missions, treasure, a journal, leaderboards, cloud save, purchases, beta builds, and a proper release path.

Here is the same game later, on an actual phone.

The board was the start. The current game is the board plus the systems around it: home hub, avatar and pet state, treasure, rewards, persistence, and the release path that lets players get it safely.

The island map, April to now. It began as numbered circles on a debug path and became a world of illustrated islands. Same screen, with the whole project in between.

It is easy to say “AI helped me build a game in a few months” and make it sound like one smooth line from prompt to launch. That is not what happened.

The board came fast. The product took longer because I kept raising the bar:

• The campaign could not feel like one endless board; it needed islands, progression, and a sense of place.
• Player progress could not disappear because a phone died or the app closed.
• Purchases had to be granted, persisted, restored, and verified.
• Leaderboards had to show real data, even with only a few players.
• The game had to behave on a real Android phone, not just in the editor.
• The iPhone path had to be its own release lane, with its own signing, review, and store setup.
• The build had to be small enough to ship.
• The screens had to look like a finished game, not a technical demo.

That is the difference between a prototype and a product.

The timeline was not only build time

The clean version of the timeline looks simple, but each stage opened more.

For Android, the waiting is not optional on a new personal Play Console account. Google requires a closed test with at least 12 testers opted in continuously for 14 days before you can apply for production access.

Then Google reviews that request, which its help page says usually takes 7 days or less but can take longer.

So the moment the build is technically ready is not the moment the public launch happens.

You can easily be looking at three weeks or more before production is even available, and that is before any store review, rejected metadata, missing screenshots, or beta-feedback fixes.

iOS has its own version. You can get an internal build into TestFlight, but external testing and production are still tied to Apple’s review. A build must pass Beta App Review before external testers can use it, and production submission has its own App Review path.

iOS readiness is not one narrow feature working. It is an end-to-end trust chain, and every link has to hold: the TestFlight build installs, the in-app purchase metadata is right, login and auth work, ads load, leaderboards return real ranks, the listing survives review, all proven on a device.

I asked for that whole chain, because it is easy to confirm the one thing you were looking at and call the platform ready while the link you did not check is the one that fails review.

So yes, AI made the build faster. But mobile launch still has gates. You wait on platforms, testers, and review, and you fix what they expose.

That waiting is not wasted. It is when you:

• Tighten the store listing.
• Test payments again.
• Ask what the first players are confused by.
• Research where your audience actually is.
• Prepare support flows.
• Decide what waits until after launch.

The store setup is its own project

One thing AI does not make obvious at the start is how many separate pieces you have to set up before a mobile game can go live.

For Tropic Tumble, the work was not only Godot and game code. It was all of this:

Area	What had to be handled
Android release	App bundle, signing, version codes, Play Console tracks, closed testing, production access, release notes
iOS release	Xcode export, certificates, provisioning profiles, App Store Connect records, TestFlight, review screenshots
Store presence	Name, description, screenshots, feature graphics, age rating, privacy answers, support URL, website
Money	In-app purchases, restore flows, receipt validation, entitlement state, test purchases, failed purchases
Player systems	Login, cloud save, progress sync, leaderboards, beta feedback, data cleanup
Operations	Backend environment, tokens, logs, crash checks, build verification, rollout notes
Marketing	Launch page, app screenshots, ad creative, social accounts, research, tester recruitment

Store setup turns into player support fast: purchase screens, settings, restore paths, support IDs, privacy, and terms all have to exist before launch feels real.

None of those rows is exciting the way the first playable board is. But they are the work that makes the game real.

This is where my QA background helped most. Releases teach you to care about boring questions:

• What exact build is this?
• What environment is it pointed at?
• Which account made this purchase?
• Did the item grant once, or did it grant twice?
• If the app closes during a sync, what state survives?
• Does the leaderboard show the truth with three players, not only with three thousand?
• Can I prove the release artifact is the one I tested?

The UI can look fine while the system is wrong. I have seen that in QA work for years, and building this game made me live it every day.

That last question is why “ship it” never meant a narration of what an agent did. A release is an artifact family, and I asked for the whole family, not the story.

For an Android beta that meant bumping the version name and code, exporting the AAB, producing the deobfuscation mapping and native-symbol ZIPs that make a crash report readable, verifying the file hashes, and handing me the exact filenames.

A green build log is not an uploadable build. The files are.

Security got the same treatment, because a security pass is more than a grep for secrets. A gitignored file does not always stay out of the shipped app; the build can package it anyway.

So the question is not “is this in the repo,” it is three: what is tracked, what is ignored, and what actually lands inside the Android artifact.

I had the audit follow that last path, because the artifact is what players install, and the only copy that can leak anything.

The pivot I did not plan

My first plan was smaller: no ads, no purchases, no backend, local save only. A simple single-player game that lived on the phone.

That plan did not survive the product becoming real.

Each system pulled in the next one.

• Once you care about progress, you start caring about cloud save.
• Add purchases, and you must honour them across sessions and devices.
• Add leaderboards, and the server has to be the source of truth.
• Add beta testers, and you need a way to understand what happened when something breaks on their phone.

That last one hides a rule that took real care. When a player reinstalls or signs in on a second phone, the restore has to bring their progress back without ever costing them anything, with the server staying the authority so the restore is reconciled, not trusting whatever a device reports.

That boundary is the difference between a player trusting your game with their progress and watching a reinstall wipe a month of it.

So the game moved from local prototype to live-service product. Not because an AI agent demanded complexity, but because the product I wanted to ship needed those systems.

This is also where I had to be careful not to fake maturity. A small player count is a real product state. If the leaderboard has three players, it should show three players correctly.

I did not want fake activity to make the game look busier than it was. I wanted the system to work honestly for twelve testers, then scale from there.

That one rule shaped a lot of decisions.

The part nobody sees

Once the game grew accounts, an economy, cloud save, and leaderboards, the hardest testing stopped being about the screen and started being about the server. A live-service product is mostly the part the player never sees, and that is the part I have spent years testing in fintech and e-commerce.

The trap is the same everywhere: the button works, the coins animate, the leaderboard shows your name, and underneath, the entitlement granted twice, the save only reached the device, or the rank is three hours stale.

A green screen is not proof the server did the right thing.

Leaderboards and purchases look like UI. The real test is backend truth: who earned what, what rank is current, which entitlement was granted, and what survives the next sync.

So I held the backend to four guarantees, and tested each by breaking it on purpose:

• The economy is granted exactly once. Purchases and rewards have to survive retries and dropped connections without ever granting twice or granting zero, so the grant is idempotent and decided on the server. The client cannot talk it into a different answer.
• The save survives the worst day. Not “does it save” but “does it come back, intact, on a different phone, after a reinstall.” Those discontinuity tests find real persistence bugs, and a quick happy-path check never runs them.
• The leaderboard tells the truth. I hit staleness directly after a backend refresh, where ranks no longer matched the scores behind them. The board has to be real and current, and an impossible score has to be refused by the server, not displayed.
• One player stays one player. Identity is the quiet one. A player has to map to exactly one account, enforced on the server so it holds no matter how the app launches or reconnects. The screen never hints when that slips. You only catch it by checking who the backend thinks you are, not what the device shows.

Because I come from testing, each guarantee is a test that tries to break it, not a hope that it holds.

The economy test grants a reward and checks the balance moved by exactly the right amount and no more. The save test takes a frozen save from an older build, loads it into a fresh install, and treats any dropped field as a release blocker.

The leaderboard test is the one I think about most, because the bug it guards is invisible on the screen: a rank could quietly drop out of the middle of the board, and the test refuses to pass unless every place is still accounted for.

Those are three samples from a bigger habit. The game carries more than four hundred headless test runners, the kind you launch with godot --headless and read as a plain pass or fail, including contract tests that pin behaviour I never want an agent to quietly change, like how a power and a combo clear the board.

The ones I rely on most are visual-capture tests: they boot a screen, render it, and save it to an image, so a layout regression leaves a picture I can look at instead of a green tick I have to trust.

The agent writes most of them once I describe the rule. Deciding the rule, and whether a pass really proves the promise, stays with me.

The most valuable fairness work a small team can do is simple to state: make the server the authority on anything that matters, so a modified client can lie to its own screen all day and change nothing real.

Get that boundary right, and a cheat that would hurt other players has nothing to grab onto.

Where the agents helped

The agents were genuinely useful. I would not have built this much this fast without them.

They were strong at work with a clear shape:

• Building systems from a detailed spec.
• Refactoring code when I could explain the desired behaviour.
• Searching a large codebase for the layer that owned a bug.
• Reading device logs and pointing to suspicious failures.
• Generating level data and helping validate it.
• Drafting store copy, test notes, release notes, and checklists I could edit.
• Helping me move between Android, backend, website, and store tasks without starting cold each time.

I also learned to run them more like a small studio than one magic assistant: different agents on different jobs, with project instructions so they stopped wandering away from the way I wanted the game built.

That workflow is in how I run three AI coding agents like a studio.

The important part is that I directed. The agents produced. I decided.

That distinction matters.

Where the agents kept failing

Every place the AI struggled was a place a tester would expect.

It could not judge the visual quality. An agent could tell me a screen had the right nodes, buttons, and callbacks. It could not reliably tell me the button looked too big, the spacing felt wrong, the art looked stretched, or the screen felt cheap.

That was my job: run the game, look at the actual phone, and say, “No, this is not good enough.” The visual side became its own lesson in designing a game with AI.

It treated green checks like proof. A passing test, a successful export, or a clean log line is evidence, not the whole truth. I kept having to ask: what does this actually prove? Did we test the promise, or only the screen? Did the purchase grant on the backend, or did the button only close the modal?

It fixed symptoms before causes. The hardest billing bugs were like this. The agent would patch one layer, the symptom would get quieter, and the real problem would still be there. The useful move was the QA move: follow the chain. Buy, grant, persist, restore, refresh the UI, then prove the state survives.

It could not decide what was fair or fun. It could generate levels, suggest powers, help tune numbers. But whether a level felt satisfying or unfair was my call. Whether the game should push an ad, sell a retry, or let the player keep going was my call. The agent can produce options. It cannot own the values of the product.

Here is the division of labour I trust now:

Work	Good agent work	Human judgment
Turn a clear feature spec into code	✓	~
Search logs and trace a broken contract	✓	~
Generate first-pass levels or copy	✓	~
Decide whether the screen looks polished	✗	✓
Decide whether a level is fun and fair	✗	✓
Approve a release to real players	✗	✓

✓ strong fit   ~ useful with review   ✗ do not hand this over

The fights that made it real

The most frustrating work was not the first board. It was the work that made the game survive contact with a real phone and real store systems.

At one point a single move took far too long to resolve because the board logic had grown heavy. The editor could hide that. A real Android phone could not.

I had to feel the lag, capture evidence, then work with the agent to find the hot paths and move heavy work out of the player’s way. The fixes were unglamorous and specific:

• Defer a heavy screen like the treasure board until it is actually opened.
• Load the home hub’s art asynchronously so it does not block the first frame.
• Skip scenes already loaded so moving between the map and a level does not rebuild them.
• Chase a one-to-two frame tile jitter that only appeared after the board refilled.

None of that shows up in a screenshot. You feel it on a real device, or you miss it.

Local source inspection is not acceptance. When an agent told me a leaderboard and race-screen slowdown was fixed, I made it prove it on the actual phone: pull the device logs, filter to the game’s process id, and read what the running build did, not what the source claimed.

That found the real issue. The agent patched the race UI and the perf path, then built a QA APK, installed it on the phone, and we confirmed it there. It also reported, honestly, that some backend latency was still there. I would rather have that than a clean story.

And when logs already existed from an earlier run, the rule was to use them: filter the saved logs, do not waste an hour reproducing a failure you already captured.

The build size also became a problem. A game with islands, art, effects, and polish gets heavy fast. I had to compress assets, re-export, check the result on a real screen, and keep asking whether the game still looked good. Not glamorous, but it decides whether the app is practical to download.

The billing work tested my patience most. Purchases are not just a button and a receipt. They are identity, store state, backend validation, entitlement grants, token handling, restore flows, and UI refresh.

If one layer lies, the player pays the price. I treated that as a release-blocking risk because it is. Building Tropic Tumble made that lesson personal.

This is where “show me the evidence” became my rule. Not “the agent said it was fixed.” Not “the build passed.” Evidence.

I could have launched smaller

This is the part I want the timeline to reflect properly.

There was a point where I could have pushed a smaller version forward. The game existed. The core loop worked. The Android path was moving and the iOS path was being worked through.

But I made a product decision to add more:

• More levels.
• More islands.
• A stronger home and world flow.
• Better purchase handling.
• Better sync and backend behaviour.
• Better store assets.
• More player-facing systems around the board.

That was not AI slowing me down. That was me choosing the product I wanted to launch.

It matters because people talk about AI builds as if the timeline is only “how long did the code take?” That is the wrong question. A better one:

What version are you willing to put your name on, and what evidence would make you comfortable shipping it?

For me, the answer kept moving as the game became more real.

What I would tell another QA person

If you have a QA background and you are wondering whether you can build a real product with AI agents, you can. Your QA background is not separate from that work. It is the advantage.

You already know how to question a system. You know a green build can still hide a broken promise, that the release artifact matters, that real devices matter, and that payments, data, and identity deserve more suspicion than a pretty screen.

Use that.

Give the agents the work they are strong at. Let them build, search, refactor, draft, and inspect. But keep the judgment, the visual eye, and the release call. Keep asking:

• What does this actually prove?
• What happens on the actual device?
• What happens with real data?
• What happens when the store, the backend, and the UI disagree?
• What would make me uncomfortable shipping this?

The first playable Tropic Tumble board took a couple of hours. The real game took much longer because shipping is not the same as generating code.

That is not a complaint. That is the honest log.

AI gave me speed. QA gave me standards. The game needed both.

If you want to try this, start smaller than a full game. Take one real feature you understand, give an agent the actual code and a clear definition of done, then test what it gives you on a real device as if a stranger wrote it. The gap between what it claims and what you can prove is the whole job.