Galaxy Devlog #11 · Read the Galaxy build log
I do not write code and I cannot read it. Call the Cat: Galaxy, the Unity sequel to a game I already shipped, is written line by line by AI agents. My job is to say what I want, set the rules they work under, and check whether what comes back is actually right.
This one is about the temptation that shows up the moment you start moving old code to a new engine.
The first temptation when you move to a new engine
We are porting a separate game we shipped previously into a mini-game mode inside the game we are building now (internal name: LogMode). Work like this naturally creates the thought, “since we’re in here anyway, let’s make it a little nicer.” You want to add one more button, or smooth out something that felt awkward.
But if the first goal of a port is reproducing the original, then any behavior that was not in the original is not an improvement — it is a separate feature. Mix it into the same change, and later, if something goes wrong, it becomes hard to tell whether the port was done incorrectly or an approved improvement caused the problem.
So we fixed the standard for this porting work into one line:
Bring over what the original does. Do not add what the original does not do. Do not remove what the original does.
A 7-step procedure for reading the original and comparing it against the Unity implementation.
Not porting by eyeballing a screenshot
We do not write code from looking at a single screen of the original. The original was built in a different engine (GameMaker), which gives every object separate functions for “on create” (`Create`), “every frame” (`Step`), and “when drawing” (`Draw_0`, `Draw_64`). For each feature, we read those original functions first — writing down input, state transitions, draw order, coordinates, and text separately, then comparing them line by line against the Unity side.
A real excerpt from the audit: matching the original’s values against Unity’s, side by side.
For example, the mobile LogMode’s page labels 1, 2, and 3 map to the internal `log_page` values 0, 1, and 2. Change that one number carelessly, and the screen still opens, but it points at a different page than intended. What matters here is not memorizing function names — it is fixing the original’s input, state, and draw order as the reference first.
Improvements get filed as a separate request
If a button or animation that differs from the original is genuinely needed, it does not get slipped quietly into the porting code. It gets logged separately as a “feature request,” and only gets approved after the original has been fully and faithfully copied.
That separation narrows down the cause when something breaks — you can tell whether the original was ported incorrectly or an approved new feature caused the problem. What’s confirmed right now is the diff rules and static checking; it does not mean every screen of the ported mode has been confirmed in Play Mode.
Copy this
Copy the following as a work card before starting a porting task.
1. Write down the original file and function names. 2. Bring over the original's variables, numbers, text, and branches first. 3. Diff Create / Step / Draw order against each other, one at a time. 4. Build a table of coordinates, units, and input reference points. 5. Anything not in the original does not get implemented — leave a TODO instead. 6. File improvement ideas as a separate request. 7. Any code path not in the checklist needs a written reason for being added.
What this post is worth
This approach does not make development look fast. What it does is make it possible to trace whether a given behavior is “the original game’s actual behavior” or “a new convenience feature we added.” Beyond porting, remakes, and platform moves, this same idea applies any time you have an AI modify existing code: what you need is not prettier code, but a standard for confirming the behavior is identical.
Next post
After the original is diffed, you still have to decide where that input is allowed to happen. The next post covers why Steam gamepad input got narrowed down to combat only, instead of every screen.
Solo dev of Call the Cat, shipped after 178 days
on Google Play
and Steam.
Now building the sequel, Call the Cat: Galaxy, in public.