Why we're building AsteronEngine

ClaudeCitizen begins with a simple promise that turns out to be technically unreasonable: you should be able to stand on a planet, walk into your ship, take off, cross the atmosphere, enter orbit, leave through the airlock, and come home again—without the universe quietly swapping itself out around you.

That promise touches everything. Position precision. Physics. Rendering depth. Gravity. Networking. The meaning of “up.” Even the apparently ordinary act of walking across the deck of a ship becomes interesting when the deck is rotating, accelerating, and travelling millions of metres from the centre of the world.

General-purpose engines are designed to serve many kinds of games. That breadth is their strength. ClaudeCitizen, however, keeps pressing against a particular cluster of assumptions: float-sized worlds, one inertial frame, origin rebasing, and a hard boundary between an editor operated by a person and source files operated by tools.

So we started AsteronEngine.

Why we stepped away from Unity

ClaudeCitizen began in Unity, and that was not a mistake. Unity gave us a fast way to discover the game. It let us assemble worlds, test characters and ships, work with the Synty art library we love, and learn which ideas felt exciting when someone actually had a controller in their hands.

We did not leave because Unity is a bad engine. We left because the game kept asking it to work against some of its most deeply rooted assumptions.

A conventional game world is usually a few kilometres across and built from 32-bit transforms. ClaudeCitizen wants precise movement on the deck of a ship while that ship is travelling at orbital scale. That made floating-point precision one of the largest factors in our decision.

A 32-bit float does not preserve the same precision everywhere. As a position grows, the distance between adjacent representable values grows with it. A useful approximation is

$$\Delta x \approx |x|\,2^{-23}.$$

At ten million metres from the origin, neighbouring positions are roughly a metre apart. Subtle character motion, contact points, animation, and small objects cannot remain subtle when the coordinate system itself moves in metre-sized steps. An origin shift can make the camera’s neighbourhood precise again, but it does not remove the problem—it requires every relevant system to agree on when and how the universe moved.

That precision problem was connected to everything else. A conventional character has one stable idea of “up.” Ours can walk under radial gravity, cross into a moving ship’s local frame, and then step into weightless EVA. Origin rebasing, multiple camera ranges, special ship-local controllers, and careful handoffs can each solve part of that—but the seams between those solutions became the architecture of the game.

The editor boundary mattered too. Unity is built around a rich visual editor and serialized assets. We increasingly wanted scenes and prefabs to be readable text: something a person can manipulate visually, an engineer can review in a diff, and an AI agent can edit and test headlessly. None of those desires makes Unity wrong. Together, they made our particular fit increasingly expensive.

The switch is not an attempt to erase what came before. The visual identity, the Synty assets, the gameplay lessons, and the worlds we have already imagined all move forward with us. Unity helped us learn what ClaudeCitizen needs; AsteronEngine is our decision to encode those needs at the foundation.

One game, on purpose

AsteronEngine is not intended to become a general-purpose engine or a product with a marketplace and licensing tiers. It is a purpose-built native engine for ClaudeCitizen: a seamless, persistent, planetary-scale space game.

That narrower mission lets us make unusually strong decisions:

• Authoritative world positions use 64-bit precision. Nearby rendering and physics can still use efficient local coordinates, but we do not move the universe underneath the simulation.
• Moving reference frames are a first-class primitive. Planets, ships, and stations can all carry their own local worlds.
• Simulation advances deterministically at a fixed rate while rendering remains free to run as quickly as it can.
• The client/server boundary exists even in single-player.
• Authored content is readable text. The editor and an AI agent are two views onto the same source of truth.

We are writing the engine in C++20 and targeting Vulkan directly. We use proven libraries where the problem is already solved—Jolt for physics, ozz-animation for skeletal animation, and meshoptimizer for mesh processing—and concentrate our effort on the connective tissue that makes this particular universe possible.

A little of the math

Building around the game does not mean writing everything from scratch or decorating the project with complicated equations. It means choosing a few mathematical models that make many apparently different problems become the same problem.

Moving reference frames are the clearest example. If a character is walking inside a rotating ship, their velocity in the ship’s parent frame is

$$\mathbf v_p = \mathbf v_f + R_f\mathbf v_l + \boldsymbol\omega_f \times (R_f\mathbf x_l).$$

The terms are the frame’s linear velocity, the character’s rotated local velocity, and the tangential velocity contributed by the ship’s rotation. That final cross product is why stepping out of a spinning station or releasing into EVA preserves the motion you physically ought to have. Boarding, walking inside a ship, landing, and EVA do not need unrelated hand-authored corrections; they are consequences of the same transform.

Planet terrain follows a similarly compact rule. Given a unit direction $\mathbf d$, planet radius $R$, and one authoritative height function $h$, the surface is

$$\mathbf S(\mathbf d)=\bigl(R+h(\mathbf d)\bigr)\mathbf d.$$

That one function feeds rendering, collision, object scattering, and editor previews. The large forms come from authored planetary data; deterministic multi-octave gradient noise adds local relief directly in three-dimensional direction space, so detail crosses cube-face boundaries without a seam.

The renderer then spends detail only where it can be seen. A terrain node’s geometric uncertainty is projected into pixels:

$$E_{px}=E_g\, \frac{H}{2\tan(\theta_y/2)}\, \frac{1}{\max(D-r_n,\epsilon)}.$$

When $E_{px}$ is larger than our pixel budget, the node splits. Near a character’s boots the ground becomes dense; across an ocean or from orbit it becomes dramatically cheaper. The underlying world never changes—only the amount of it we ask the GPU to describe.

These equations are not impressive because they are exotic. They are valuable because each one removes a pile of special cases. That is the recurring idea behind AsteronEngine: find the model that lets the game stay one connected place.

Why now?

Writing an engine has traditionally meant accepting an enormous implementation cost before the game could begin. AI changes that calculation, but perhaps not in the obvious way.

The difficult part is not knowing that meshlets, cube-sphere terrain, clustered lighting, or deterministic simulation exist. The difficult part is choosing the right constraints, establishing ownership between systems, and then carrying those decisions consistently through thousands of details.

AI makes implementation dramatically more tractable. It does not make architectural judgement optional. If anything, it makes clear written decisions more valuable: an agent can move quickly when the destination and the boundaries are precise.

That principle shapes the engine itself. Scenes and prefabs are diffable text. Every subsystem has a headless bench. Builds must remain fast. Anything that can only be done through a GUI is a design failure; anything that can only be done by typing coordinates is a usability failure.

What we’ll share here

This devlog is the public notebook for that work. We will show the successes, but also the abandoned approaches, strange rendering artifacts, benchmark results, and decisions that changed after meeting reality.

Expect posts about planetary terrain, reference frames, visibility-buffer rendering, animation, deterministic simulation, editor tooling, and the work of turning separate technical achievements into one connected journey.

The goal is not merely to build impressive subsystems. It is to let a player walk from the ground to the stars and feel that it was always one place.

That is the standard AsteronEngine has to meet.