Galaxy Devlog #02 · Read the Galaxy build log
I am porting one mode from my first game
into its sequel.
The original was built in GameMaker.
The new version is being rebuilt in Unity.
I thought moving an existing game
would be easier than making something new.
Instead, the hardest part was stopping AI
from trying to make it better.
This is why the first rule
in my porting document now says:
do not improve the original.
The original mode running in GameMaker.
Porting and redesigning are different jobs
A port means rebuilding the same thing
with a different tool.
But while rebuilding it,
the original can start to look awkward.
A button may feel slightly out of place.
Some information may be hidden.
An action may take one step more
than you would choose today.
It is tempting to fix those things
while you are already touching the code.
AI is especially eager to do that.
Ask it to move a feature
and it often adds one more helpful idea.
Most of the time that instinct is useful.
During a port, it is dangerous.
What actually changed without permission
On August 3, 2026,
several differences surfaced at once.
None of them had been requested.
First, the game vibrated every time
the player was hit.
The original did not do that.
Its vibration was limited to a specific stage,
but the port had quietly added the logic
that being hit should always trigger feedback.
Second, enemies and decorations appeared
outside the game area.
The original clipped everything
to the playable region.
That clipping step had been missed during the move.
This was not even a new feature.
It was an original behavior
that disappeared during the rebuild.
Third, a half-price continue rule was missing.
Under a specific condition,
the original game cuts the continue cost in half.
The rule was clearly present in the old code,
but it had not made it into the Unity version.
Fourth, the button shown after death
had been renamed.
The original chooses a different label first
depending on the situation.
The port replaced those labels
with one standardized name.
It probably looked cleaner.
It was also different.
The fifth change was the one
that worried me most.
The port invented a display
that did not exist in the original.
It showed the remaining time
for a feature at all times.
The original keeps that information gray
and only reveals it when the player
moves the mouse over it.
An entirely new piece of UI had appeared.
The same mode after the Unity port.
Why a seemingly helpful change is a problem
The obvious question is:
if the new version looks better,
what is the harm?
There are three problems.
First, nobody proved that it was better.
The original decision may have had a reason.
Perhaps the remaining time stayed hidden
to keep the screen from feeling crowded.
If I change that without checking,
the game starts drifting before I understand
which parts made the original work.
Second, the differences become impossible to trace.
Once twenty small changes pile up,
I cannot tell whether a strange behavior
came from the original
or was introduced during the port.
At that point, even opening the old project
no longer gives me a clean answer.
Third, this is a game
that has already been sold.
If someone who played the original
finds the same mode inside the sequel,
small changes in controls and feedback
may not feel like improvements.
They may feel like a broken promise.
The rule I put at the top of the document
I created a separate fidelity document
for the port and placed this rule at the top:
Move what exists in the original.
Do not add what is not there.
Do not remove what is there.
Then I added one more line:
The default task is copying.
If creation is required,
ask for permission first.
Before making a change,
the AI now has to answer three questions.
Is there an original file and function
that support this change?
If not, did it ask first?
And the most important one:
"It would be more convenient on mobile"
is not permission.
What the rule changed
The first thing this document changed
was not the code.
It changed the conversation.
Before, I would notice something strange and ask,
"Why did this end up like this?"
Then I had to trace the change backward
until I found the cause.
Now I can ask one question:
"Where is that in the original?"
If there is no source for it,
the change is reverted immediately.
There is no need to debate
whether the idea was good.
The rule does not ban convenience forever.
It only fixes the order of operations.
First, port the game faithfully.
After the port is complete,
decide what should be improved
as a separate job.
If I port and redesign at the same time,
I lose control of both.
If you are starting a port
Before opening the old project,
make a separate list called
things to improve later.
When you see something awkward during the port,
do not fix it on the spot.
Put it on that list.
After the faithful version is complete,
review the list one item at a time.
That keeps moving and redesigning
from becoming one tangled task.
If AI is helping with the port,
do not leave this as a sentence in one prompt.
Put it in a rule document
that stays with the project:
The default task is copying.
AI is built to be helpful.
If left alone,
it will eventually try to add something.
That is not a bad instinct.
It is simply the wrong instinct
for a fidelity-first port.
Previous:
Galaxy01 – I Gave Two AIs Separate Folders
Next:
how I built forty planets with ten files
instead of making one file for every planet.