Solo game development — verification notes
TL;DR: I concluded that iOS would show an empty shop after reading one condition. A second condition prevented the purchase provider from existing at all. The code was fine; my explanation was not.
I found a gate and stopped reading
While aligning the legal pages for Call the Cat: Galaxy with the actual build, I needed to explain what happened when an iOS player opened the shop.
I read the function that opens it. Its condition was simple: if the device is mobile, open the window. iOS is mobile, so I wrote that the window would open with no products in it.
That sounded plausible. It was also wrong.
There was a second gate
The person checking the actual device told me that screen did not appear. So I followed the path again instead of defending the first answer.
Opening a window and creating its purchase cards are separate gates.
The opening condition was in one place. The condition that creates product cards was elsewhere. That second gate only allows store products on Google Play.
| What I read first | What the full path showed |
|---|---|
| Mobile devices can open the shop window | Opening the window is only the first condition |
| iOS is mobile | The card-rendering condition checks the platform again |
| No products means an empty shop | On iOS, the purchase provider is not created for this path |
The important correction is not merely that I missed a line. I had described a screen that the application does not produce.
Nothing in the code needed fixing
The two gates were not a defect. Separating the decision to open a window from the decision to render purchasable products is a reasonable design.
The thing that had drifted was the document. The text made it sound as though purchases might be available on Google Play or Apple. The corrected wording separates the platforms and says that the current App Store build does not provide in-app purchases.
If I had trusted my first explanation, I might have changed working code to remove an empty shop that never existed. That is how a documentation error becomes a new bug.
Why an AI answer can stop too early
An AI often finds the first condition that answers the question and turns it into a sentence. Unless asked to trace the whole path, it may not look for another condition in a different file that blocks the same behavior later.
People can make that mistake too. The difference is that a person can then open the screen. A text answer cannot do that on its own.
Copy this — three questions after an AI reads code
Three questions that turn a code claim into a verifiable path.
Use this prompt before copying an AI’s explanation into a document or a product page.
Find every condition, including conditions in other files, that can block this behavior.
List the path in execution order with file and line references.
Then tell me one concrete action that would verify the conclusion on the actual screen.| Check | Why it matters |
|---|---|
| Every blocking condition | The first gate is rarely the whole behavior |
| Execution order | A later gate can invalidate an earlier, true observation |
| A screen-level check | It keeps a code reading from becoming an invented UI claim |
At a glance
| Item | Detail |
|---|---|
| Initial claim | iOS would open an empty shop |
| What was missed | A separate product-card gate limited to Google Play |
| Actual result | The purchase provider is not created for that iOS path |
| Code change | None |
| Document change | Platform wording was corrected to match the build |
| Verification boundary | The correction came from checking the actual device; reading code alone had not proved the screen |
Solo dev of Call the Cat, shipped after 178 days
on Google Play and Steam.
The sequel, Call the Cat: Galaxy, is now on the App Store — still building it in public.
Tags
AI coding, code review, Unity, mobile games, in-app purchases, solo development
Leave a Reply