Solo game development — verification notes
TL;DR: Static checks, a build, an install, and a first screen are four different claims. An AI that says “build succeeded” has told you about one of them. This is the table I use to keep the other three empty until someone actually looks at a phone.
Four claims that are easy to merge into one
Read “build succeeded” and it is natural to assume the game will now run. A build packages development files into something a platform can install. Running the game means putting that file on an actual phone, opening it, and checking that the first screen and the controls behave.
Packaging bread without the machine jamming is not the same as eating the bread and finding it good. The first result is real, and it does not stand in for the second.
“Different” here does not mean the game failed on a device. It means the verification records in my repository keep builds and static checks separate from Unity Play Mode and device review. The point is not to distrust the result; it is to avoid writing an unchecked result down as either success or failure.
Static check, build, install, run — each stage proves only its own scope.
Static checks read the code without running it
A static check inspects files and code without executing the program. It can confirm that required functions exist, that platform settings do not conflict, that a package identifier or a specific string is correct, and that a regression command passes.
What that tells you is whether the source and settings satisfy the conditions you wrote down. It catches wrong names, missing references, and drift between documents and code before anything runs. What it cannot tell you is whether a character actually moves on screen, or whether a button reads the touch position correctly.
Syntactically correct code and enjoyable play are also separate questions. Passing a static check is real evidence, but it is not a substitute for a runtime result.
A build produces a file you can install
A build bundles code into a file for a target platform such as Android or iOS. What belongs in the record at this stage is whether compilation and packaging finished, where the artifact landed, and what the package identifier and version are.
“The Android build succeeded” means the process of producing an Android artifact completed. It does not say that the file installed on a particular phone, or that the app opened as far as its first screen. Signing, permissions, OS version, and free storage are all conditions that get tested for the first time in a real install environment.
Install and run add an environment
Installing checks whether the file can be placed on the device. Running means opening the installed app and checking that the start screen appears, that it does not hang while loading, that the aspect ratio is right, and that the core inputs work.
A device introduces variables the development machine did not have: OS version and screen size, whether permissions were granted, network state, storage, signing state, and where a touch actually lands. A scene that passed in the editor or in CI still has to be confirmed on hardware.
The current Galaxy review records keep Android and iPhone hardware checks and Unity Play Mode as separate, user-run verification items. So the most I can say from the present evidence is that the scope of static review and build artifact creation has been confirmed. Install, first screen, and input stay blank until someone checks them on a device.
Ask an AI for evidence, not for a verdict
Ask “is it done?” and the answer can flatten a narrow check into a broad claim. Asking for artifacts and unverified items together makes the boundary visible.
Write down which command you ran for the static check and which for the build. Record the artifact’s exact path, size, package name, and version. Then split out, item by item, whether Unity Play Mode, installation on a real device, the first screen, and the core inputs were checked. Do not mark anything you did not check as a success.
That prompt is not written to distrust the AI. It is a work record so the next person does not repeat the same checks. Its purpose is to show the gap between “a file exists” and “a player can play the game.”
Ask for artifacts and unchecked items in the same answer, and the boundary writes itself.
“Ready to ship” is wider still
Even a confirmed run does not finish a store release. Stores have app signing, version numbers, screenshots and descriptions, policy items such as privacy, advertising, and sign-in, and a review result on top of all of it. Opening correctly on a device and passing Apple’s or Google’s review are different pieces of evidence.
So the record should carry “build succeeded,” “installed on this device,” “reached first screen,” “core input confirmed,” and “submitted for review” as separate lines. Not widening one stage’s result into the next stage’s completion sentence is what keeps the last week before release from getting confusing.
At a glance
| Sentence | What it actually proves |
|---|---|
| Static checks passed | Conditions confirmed without executing anything |
| The build succeeded | Artifact creation for the platform finished |
| It installed | The file reached one specific device |
| The game runs | Someone opened it on hardware and looked |
| We can ship | Signing, store data, policy, and review are still separate |
For anyone starting this
When a build result comes back, record the artifact and version first, then the device name and OS version, then check install, first screen, and core input separately. If you get stuck partway, write down the error for that stage. Simply refusing to chain an unchecked item onto a “probably fine” is enough to remove the most dangerous misunderstanding in AI-assisted development.
This post was written on 2026-09-12 by re-reading `39_GALAXY_IMPLEMENTATION_BASELINE_2026-08-14.md`, `37_CODEX_HANDOFF.md`, and `logs/2026-09-10_galaxy_full_review.md`. Those records separate static compilation and structural verification from Unity Play Mode and Android/iPhone hardware review. This post adds no new claim that a specific device failed, and does not claim a successful device run.
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
game builds, device testing, Unity, Android, AI code verification, release preparation, solo development
Leave a Reply