Building a large online game is not one problem. It is a dependency graph of systems, and some mistakes become dramatically more expensive once enough other work has been built on top of them. A ship model can be replaced. A UI can be redesigned. A foundational assumption about persistence, authority or entity ownership can spread through years of gameplay code before anyone decides it was wrong.
That is why the development order for Stellar Mariner starts below the visible game. Before we have large amounts of content depending on them, we want clear answers to questions such as what an entity is, which state is transient, which state is durable, where authority lives, how ownership is represented, how simulation is divided, and what information actually needs to cross the network. Those decisions do not make the game interesting by themselves, but they determine how expensive almost everything above them will be to build and change.
This article is about that reasoning rather than the detailed implementation. We can be specific about the engineering principles without publishing internal topology, protocols or failure-handling logic before those systems have been proven.
Systems before features
A feature is normally something a player can point to. A system defines rules that multiple features can depend on. We want to solve as much as possible at the system level before allowing individual gameplay features to invent their own version of the same problem.
Inventory is an obvious example. Cargo, character equipment, ship storage, warehouses and containers may all need different interfaces and rules of use, but they should not each invent a separate concept of what an item is, who owns it or how it moves between entities. A shared entity and containment model gives those features a common foundation. The same principle applies to identity, ownership, persistence, transactions and other concepts that will appear throughout the game.
The alternative is attractive early because individual features move quickly, but the cost appears later. Every new activity needs translation layers between systems that were never designed to agree. Exceptions accumulate, edge cases multiply and behaviour becomes dependent on which subsystem happens to own a particular object at that moment. We would rather pay more of that cost early by defining the contracts once.
That does not mean designing every future gameplay mechanic now. It means identifying the concepts that many future mechanics will rely on and making those concepts stable enough to build against.
Stable contracts, not frozen architecture
There is a difference between architecture that is stable and architecture that is untouchable.
Foundational systems need explicit contracts. Other parts of the game need predictable answers about entity identity, state ownership, persistence guarantees and authority. If those contracts move continuously, every dependent system moves with them and development becomes an exercise in repeatedly repairing interfaces.
At the same time, an architecture document has not earned permanence simply because it is detailed. Implementation, profiling and failure testing are allowed to invalidate it. In fact, one reason to attack the foundational work first is to discover bad assumptions while the dependency graph above them is still small.
Our goal is therefore to stabilise interfaces and invariants, not preserve every implementation decision forever. The internal machinery can change as long as the contract seen by the rest of the game remains coherent. That is a much healthier boundary for a project expected to evolve for years.
Separate transient simulation from durable state
Persistence is one of the areas where that separation matters most.
A live simulation handles high-frequency state: movement, physics, combat, temporary effects, local AI and other information that may change many times per second. Most of it belongs in memory with the authoritative simulation and has no reason to become durable. Writing every positional update or projectile state into persistent storage would add latency and contention without creating useful history.
Durable state has different requirements. Ownership transfers, persistent inventory changes, transactions, structures, claims, reputation and other outcomes may need to remain authoritative long after the simulation that produced them has ended. Those events cross a boundary from live simulation into the persistent world because the universe still needs to know about them later.
Keeping those paths separate is fundamental. The database should not sit in the latency-sensitive firing loop, and the simulation should not be the only place where durable facts exist. Exactly how those systems communicate is internal architecture, but the boundary itself is a deliberate design constraint.
One world, bounded simulations
The persistent world and the live simulation are also different scaling domains.
Stellar Mariner is designed around one persistent world, but that does not imply one global simulation instance. Live simulations can be bounded. Crowded locations can run multiple instances. Simulation capacity can be placed geographically where latency and load justify it. Those choices affect who is being simulated together, but they should not create independent copies of ownership, economy or history.
That distinction lets us keep the launch architecture simpler. A simulation instance can remain one coherent authority domain rather than requiring dynamic authority partitioning across multiple machines from day one. If measured simulation density later shows that an individual instance needs more capacity than one node can provide, additional distribution techniques remain available. They become responses to a demonstrated bottleneck rather than prerequisites chosen before we know the workload.
This is one of the areas where our thinking evolved during design. Earlier versions of the architecture placed more emphasis on server meshing as part of the foundation itself. The current position is more precise: one persistent world is the requirement; meshing is one possible technique for scaling a live simulation if the need is eventually proven.
Relevancy is part of the architecture
Networking scale is not solved simply by adding machines. The amount of state being considered and replicated matters just as much.
A client should only receive entities and state relevant to its current simulation context. That requires interest management, spatial partitioning, network culling and variable replication frequency. A ship within combat range may require frequent updates. The same entity at a much larger distance may need a reduced update rate or no replication at all. Slowly changing state does not need the same network treatment as movement or combat.
The server-side cost matters too. Culling an object before transmission is useful, but the architecture also has to avoid evaluating enormous numbers of irrelevant relationships in the first place. Spatial indexing and relevancy rules reduce the candidate set before replication work becomes expensive.
This is why we do not treat a headline player count as a useful architectural target by itself. Concurrency distributed through the universe is different from interaction density inside one simulation. The number of relevant relationships, the type of entities involved and the update frequencies required all contribute to the actual workload.
Authority has to be explicit
Persistent multiplayer systems become fragile when two systems can both reasonably believe they are authoritative for the same fact.
Authority therefore needs to be explicit. A live simulation must know which state it is responsible for resolving. Durable systems need clear ownership over the persistent facts they accept. Transitions between contexts cannot depend on whichever component happened to update last.
This is especially important around boundary conditions: players moving between simulations, ownership changing during a failure, objects being created or destroyed, or a process disappearing before all of its work has completed. The happy path is rarely the difficult part of distributed architecture. Recovery and disagreement are.
We are not publishing the internal authority-transfer or recovery model at this stage. Those details are implementation-specific and still need to earn confidence through testing. What matters publicly is that they are being treated as foundational problems rather than edge cases to solve after the rest of the game depends on them.
Failure is part of the design
A distributed online game cannot be designed around the assumption that every service is healthy all of the time.
Processes crash. Connections disappear. Requests time out. Operations can partially complete. Two components can temporarily disagree about what happened. If the architecture has no explicit answer for those conditions, technical failure eventually leaks into the persistent world as duplicated objects, invalid ownership or state nobody can explain.
That means failure handling needs to be part of the original system design. Durable operations need enough information to resolve whether an outcome actually happened. Simulation state needs clear boundaries around what can safely disappear. Recovery behaviour has to favour a coherent world over blindly preserving every transient action that happened immediately before a failure.
This is not glamorous work, but persistence makes it unavoidable. A session-based game can often discard a bad match and start another. A persistent universe inherits its mistakes.
Procedural systems at planetary scale
The same systems-first philosophy applies to the physical universe.
Stellar Mariner is intended to contain planetary-scale environments. At that scale, hand-authoring every square kilometre is neither practical nor desirable. Large-scale structure needs rules: terrain generation, environmental distribution, resource placement and other systems capable of producing variation while respecting the physical and artistic constraints of the world.
Procedural generation is not a substitute for design. It is a way of expressing design at scale. The rules still need authored intent, and important locations still need deliberate composition. The useful distinction is between things where hand placement creates meaning and things where hand placement simply becomes repetitive labour.
Even basic planetary properties belong to this systems approach. Mass, gravity, rotation and orbital behaviour describe the same physical body and cannot be treated as unrelated values. When those numbers disagree, the world design needs to change rather than asking the implementation to hide the contradiction.
Performance is a design constraint
Performance also has to enter before content volume becomes large enough to hide architectural mistakes.
Every major system consumes part of a finite budget: simulation time, replication work, memory, physics, AI, rendering and storage operations. An expensive feature is not isolated if it competes with everything else running in the same frame or server tick. By the time a system has years of content built around it, replacing an inefficient model can become much more expensive than profiling it when it was still small.
That is why representative workloads matter. A system running correctly with five entities does not prove anything about its behaviour with hundreds. An empty server says little about density. A database operation being fast in isolation says little about what happens when many durable events arrive concurrently.
We want performance questions attached to the systems that create the workload, not deferred to a final optimisation phase after those systems have become difficult to change.
Foundations before polish
This development order has an obvious drawback: the early work is less visually impressive.
A replicated ownership transition, a durable event path or a well-defined authority boundary does not make a compelling screenshot. A finished ship does. That creates a temptation to build the visible parts first and solve the infrastructure once the project looks more like a game.
We are deliberately resisting that order.
That does not mean art and gameplay wait until some theoretical architecture is perfect. Technical systems need real content to exercise them, and the universe needs visual development alongside engineering. The difference is that presentation should not force unstable foundations to become permanent simply because replacing them would now destroy months of polished work.
The purpose of foundations is to make later development easier, not to become an engineering project with no game on top of it. As the underlying systems become stable enough to depend on, the balance should increasingly move toward ships, characters, worlds, activities and content.
What this means today
Much of the architecture described here is still architecture. That distinction is intentional.
We have decisions about entity state, persistence, authority, simulation boundaries and replication that are detailed enough to implement against. Those decisions now need code, profiling, failure testing and representative workloads before we can call them proven. Some assumptions will survive. Others will change.
The goal is not to eliminate that change. It is to make the important mistakes while changing them is still affordable.
If the foundation works, players should eventually have very little reason to think about any of it. They should see a ship that remains theirs, cargo that arrived because somebody moved it, a world that remembers what happened, and a universe that continues behaving coherently while the infrastructure underneath it changes and scales.
That is what the architecture is for.
