Solo game development — design notes
TL;DR: “Round the edges of the map” is not the change. Up, collision, spawning, and the camera all read from the same flat assumption, and each one has to be rewritten before a character can walk on a planet. I costed the work from the repository; I did not implement it.
On a plane, “up” is one direction. On a sphere, it is not.
Move a character to the right on a flat map and the rule is short: raise X, keep Y on the floor line. Wherever the character stands, the floor points up the same way, so “jump goes up” is one sentence that holds everywhere.
On a spherical planet, the direction out of the ground depends on where the character is standing — left side, top, underside. Move only the position and the body sinks through the surface or lies down sideways. What the movement code actually needs is the surface normal at the character’s feet, and movement, rotation, and jumping all have to read from that instead of from a global up.
The flat movement in my repository clamps horizontal range with something like `ClampX`. Converting to a sphere is not a matter of deleting that clamp. The new position has to be projected onto the surface, travel has to follow the surface, and the character’s orientation has to be reset after the move completes.
On a plane one up vector serves the whole map. On a sphere, up is whatever points away from the center at that point.
Collision has to decide what counts as floor
On a plane, the floor is below and walls are to the side, and that split is cheap to compute. On a sphere the same obstacle reads differently depending on where the character stands. Walking toward what looks like the edge of the planet, the code has to decide whether the surface underfoot is floor, wall, or a slope that can be climbed.
So “arrange the colliders in a circle” does not finish it. Whether the character has left the surface, whether it is still attached, and which tangent direction an enemy attack travels along all have to be computed against the same reference. Looking attached on screen and being attached in the physics step are separate claims.
Enemy and item positions stop being single numbers
On a flat map, “put an enemy at Y = 3” is a position. On a sphere that number carries no promise of landing on the surface. Each enemy and item needs a latitude and longitude, a projection onto the surface, and a rotation to match the surface direction at that point.
Miss this and enemies float above the planet or sink into it. The player’s start position has the same problem. A spawn point has to be on walkable surface, the camera has to frame the player from the first frame, and nothing should be close enough to collide immediately.
Four systems read from the flat assumption, and each one is its own conversion task.
A round-looking camera is not a round world
The camera decides what the player sees. On a plane, centering the character and following left and right is enough. On a sphere, the camera’s own up and depth may have to change with the surface, and the design depends on whether the player should see the whole planet or only the ground nearby.
There is a distinction worth keeping. Laying a circular background behind a flat arena makes the planet look round. Moving a character across a spherical surface changes the shared reference used by coordinates, collision, spawning, and the camera. The first can be art direction. The second is structural work.
Check whether the game is fun before paying for the sphere
The conversion is technically interesting, and that is exactly why it is easy to start. An expensive change does not make play better on its own. Whether movement and combat in the current flat arena are fun, and whether a player has a reason to come back, has to be answered first. If the current structure is weak, rounding the space moves the same problem onto a larger build instead of solving it.
The order I settled on is: confirm the current game is fun, write in one sentence which play problem the sphere solves, test surface movement for a single character in a small area, then attach collision and spawning in turn. That order is not a completion report. It is a verification sequence drawn from a repository review.
Three questions worth asking before any of the conversion work starts.
At a glance
| Assumption | What the review found |
|---|---|
| Rounding the boundary is the change | Coordinates and the surface reference change first |
| Only the character’s position moves | Movement, rotation, and jump must follow the surface normal |
| Spawn numbers carry over | Enemies and items need projection onto the surface |
| A round screen is a round world | Visual effect and physics coordinates are separate |
| Building it guarantees it is fun | Current fun and the need for a sphere are separate questions |
For anyone starting this
Do not ask an AI to “convert the flat map to a sphere.” Ask it to find which code in coordinates, collision, spawning, and the camera assumes a plane, and to separate, per item, the evidence it actually has from the verification it has not run. That keeps a list of files that will change from turning into a sentence that says the work is done.
This review was written on 2026-09-12 by re-reading `39_GALAXY_IMPLEMENTATION_BASELINE_2026-08-14.md`, `37_CODEX_HANDOFF.md`, `logs/2026-09-10_galaxy_full_review.md`, and the current working tree. Those documents contain a review of spherical movement and surface references. Unity Play Mode and device play were not run, so this is a design record of conversion cost, not a report that the conversion exists or that play improved.
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
Unity, spherical world, coordinate systems, game physics, camera design, solo development, AI pair programming
Leave a Reply