Galaxy Devlog #03 · Read the Galaxy build log
My sequel is built around travelling
from planet to planet
and conquering them one at a time.
The design calls for forty planets.
The project, however,
contains only ten planet data files.
That is not because the other thirty
are unfinished or missing.
It is a deliberate structure:
one set of ten positions is expanded
across four worlds,
and each world changes the values
that define how those positions play.
This post is about why I chose that structure,
what it saves,
and what I gave up in exchange.
The Call the Cat: Galaxy title screen.
I almost made forty separate files
One file per planet
feels like the obvious approach.
Every planet has an environment.
Gravity can change.
Friction can change.
The enemies and collectible targets can change.
If every destination looks and plays differently,
giving every destination its own file
seems honest and easy to understand.
The problem appears
when the first balance change arrives.
During August I adjusted enemy speed
and collection targets several times.
If the project had forty independent planet files,
every shared change could have meant
opening forty places,
changing forty values,
and checking whether I missed one.
Missing a file would not necessarily
produce an error.
One planet would simply behave differently
from the others,
and I might not discover it
until much later in the campaign.
That is the kind of bug
that is dangerous for a solo developer.
The game still runs,
so there is no clear alarm.
The cost arrives as repeated checking
and uncertainty.
I wrote down one principle
during planning:
The differences between planets
should come from data,
not from separate code paths.
That principle decided the file structure
before the planet count grew.
How ten files become forty planets
The source set contains
ten planet positions for one world.
When the game starts,
the system expands those positions
across four worlds:
4 worlds x 10 positions = 40 planets.
The position inside each world
determines the planet’s role.
Position one is a small introduction planet.
Positions two through four
are small regular planets.
Position five is a medium-sized mid-boss planet
and requires three runs.
Positions six through nine
return to small regular planets.
Position ten is the large boss planet
and requires five runs.
That rhythm repeats in every world.
The position stays recognizable,
while the world’s data changes
the values around it.
The galaxy map showing the ten-position route.
This means the code only needs
to understand position and order.
It does not need a unique branch
for planet 1-1,
another branch for 2-1,
and forty more chances
for the rules to drift apart.
The world data decides
the presentation and environment.
The shared expansion rule decides
where a planet sits in the sequence
and what kind of role
that position performs.
It is a small distinction,
but it changes how the project grows.
Adding content no longer means
copying a complete implementation.
It means supplying a new set of values
to an existing structure.
Then difficulty multiplies the same structure again
Each planet has three difficulty layers:
Normal, Night, and Hell.
A star belongs to a difficulty,
not to a repeated attempt.
Clearing all planets in a world on Normal
unlocks Night.
Clearing the world on Night
unlocks Hell.
The player therefore meets
the same planet three times
under different conditions.
The route and the planet identity
stay familiar,
but the challenge changes.
That gives me three progression layers
without adding another planet file
for each difficulty.
In file-count terms,
the result is useful:
The playable content triples,
while the number of source planet files
does not increase at all.
A mission in the Hot world.
This is the part that makes
data-driven design sound almost magical.
It is not magic.
The work still exists.
I still have to choose the values,
test the progression,
and make sure each layer feels different enough
to justify playing it.
What disappears is duplicated structure.
I am not maintaining a second copy
of the same planet
simply because its enemies move faster
or its collection target is higher.
What this structure costs
There is a real price.
It is harder to make one planet
completely special.
Suppose I want one destination
where gravity is reversed
only on that planet.
If that behavior does not fit
the existing data model,
I cannot just write it
into one isolated file.
I have to change the shared expansion rules
or create a genuine exception.
A careless change at that level
can affect all forty planets.
The structure is strongest
when planets differ through values,
names, art references,
environment settings,
and other data.
It becomes weaker
when one destination needs a rule
that no other destination shares.
There is also an honesty problem
in the phrase “forty planets.”
They are forty playable destinations,
but they are not forty
fully independent implementations.
They are ten structural positions
varied across four worlds.
I wrote that distinction
into the project baseline
so I would not start believing
my own marketing language:
The forty-planet commitment remains,
but the forty planets are not all authored
as separate files.
Right now,
I think that trade is worth making.
For a solo developer,
forty files that all need the same correction
are more dangerous
than ten files that generate forty destinations.
Games do not always die
because there is too little content.
Sometimes they die
because the developer can no longer maintain
the content already there.
What I change when I add another world
Expanding this structure
requires two main decisions.
First, the expansion rule has to know
that another world exists.
Second, I have to decide
how much stronger or different
the values become in that world.
I do not start by drawing and configuring
another ten planets from zero.
The data chooses the art and environment.
The code knows the positions
and their order.
Keeping those responsibilities separate
is what lets the same route grow
without turning every balance pass
into a forty-file editing session.
The part I still have not proved
The structure exists,
and it is implemented in the game.
What I have not done
is play all four worlds
from beginning to end
and prove that the full progression curve is fun.
A clean data model can tell me
that the values increase consistently.
It cannot tell me
whether the third world becomes tiring,
whether the Night layer arrives at the right time,
or whether the boss rhythm still feels good
after many hours.
Those are play-test questions.
I do not want to present
a scalable file structure
as proof that the campaign is balanced.
Static structure and actual play
are different kinds of evidence.
The next job is to run the complete route
and find out where the numbers
stop feeling like progression
and start feeling like repetition.
If you are building many stages
Before making your third stage,
stop and ask one question:
What expresses the difference
between these stages?
If the answer is code,
the project may become difficult to manage
as soon as the stage count grows.
If the answer is numbers and data,
the same structure may be able to support
dozens or even hundreds of variations.
A practical test is to place
three stages side by side
and write down only what differs.
If the list contains numbers,
names, asset references, and file paths,
those differences can probably become data.
If the list says,
“this stage runs an extra rule,”
that stage may be a genuinely different mode.
Build that rule separately,
and keep the remaining stages data-driven.
The goal is not to force everything
into one universal system.
The goal is to recognize
which differences are values
and which differences are behavior
before both become forty copies
of the same maintenance problem.
Previous:
Galaxy02 – AI Tried to Make My Game Better
Next:
why 895 sprites from my first game
could not simply be dropped into the sequel.