When we first started writing publicly about False Contact, we used server meshing as shorthand for a much broader problem: how to keep one shared universe coherent while distributing simulation across more than one machine. That shorthand became too imprecise. Server meshing is one possible technique for scaling simulation; it is not the thing that makes a universe persistent, and it is not a prerequisite for one world.
The architecture we are working toward separates those concerns deliberately. False Contact can maintain one persistent economy, one ownership model and one durable history while individual live simulations remain bounded and independently hosted. That distinction matters because simulation scaling, network scaling and persistence scaling are related problems, but they are not the same problem.
One persistent world is a state problem
A live simulation contains the state required to resolve what is happening now: movement, combat, physics, temporary effects, local AI and the other systems that have to respond within a tight frame or tick budget. Much of that state is transient. It exists because a simulation is active and can disappear when it is no longer relevant. Persistent world state has a different job. Ownership, durable inventories, structures, transactions, claims, reputation, economic state and other lasting outcomes have to remain valid after the simulation that produced them has ended.
That persistent layer is the part that must stay singular. Two groups can occupy separate live instances of the same location without creating two versions of the world underneath them. A structure should not acquire two owners because it happened to be represented in two simulations, a market should not fork into separate histories, and a durable object should still resolve back to one authoritative state. This is what we mean by one world: not that every active entity must be simulated by one process, but that persistent facts do not fragment when simulation does.
Simulation scaling and persistence are different layers
It is easy to collapse both problems into the phrase “server meshing,” but doing so hides an important architectural distinction. A simulation node has to resolve the high-frequency state assigned to it, while persistence has to retain meaningful outcomes beyond that node’s lifetime. Those paths have very different performance requirements and should not be treated identically.
A projectile in flight belongs in the authoritative simulation. Its position may update many times per second and there is no reason to synchronously persist every update. The ownership transfer of the weapon that fired it is a different class of state because that outcome may need to remain true tomorrow, after the original simulation has disappeared. Putting durable storage directly into latency-sensitive gameplay loops would create unnecessary contention and latency, so transient state remains with the live simulation while durable events cross into persistence only when the universe actually needs to remember them.
The exact boundary between those layers is part of the architecture we are still implementing and testing, and we are deliberately not publishing the topology or internal protocols behind it yet. The principle is straightforward even if the implementation is not: real-time simulation and durable world state solve different problems, and the architecture should respect that difference.
Density is not the same as concurrency
Player count by itself is a poor scaling metric. Five hundred players distributed across many locations are a very different problem from five hundred players occupying the same interaction space. In the first case, most participants may have no reason to know that the others exist. In the second, the simulation may need to evaluate large numbers of visibility, replication and interaction relationships continuously.
That is why we care more about interaction density than a headline concurrency number. As density rises, the amount of work can grow quickly because each additional participant can create new relationships with many entities already present. The server has to determine who can see whom, who can affect whom, which objects are relevant to which players, which events need to be replicated and how often those relationships change.
This is also why statements such as “1,000 players in one hangar” are not particularly useful engineering targets on their own. Are those players standing still, moving, fighting or operating vehicles? Can every participant see and affect every other participant? How many networked entities surround them, and at what replication frequency? Without that context, the number tells us very little about the actual workload. We would rather publish density figures after measuring a representative simulation than choose one early because it sounds impressive.
Relevancy and network culling
Network replication is one of the places where scale is won or lost. A client should not receive every replicated entity in the universe, or even every replicated entity running on the same simulation node. It should receive the subset that is relevant to its current context, which is where interest management, spatial partitioning, relevancy rules and network culling become important.
A nearby ship involved in combat may require frequent position and gameplay updates. The same ship much farther away may need lower-frequency updates, a reduced representation or none at all. An entity with no plausible effect on the client should generally not be replicated to it. Reducing the replicated set matters in both directions: it lowers bandwidth to the client, but it also reduces server-side replication work because every active relationship has a cost. Efficient culling therefore starts before the network packet is built, with the way the simulation identifies which entities are worth considering in the first place.
Replication frequency matters for the same reason. Not every property deserves the same update rate. Position and combat state may be highly time-sensitive, while slowly changing state can tolerate much lower frequencies. Treating all state as though it deserves the same bandwidth would waste CPU and network budget on information the player cannot meaningfully use. There is also a security benefit here: information that a client does not need should ideally never reach that client. Network culling is not a substitute for server authority, but reducing unnecessary information exposure also reduces what a modified client can inspect.
One simulation instance does not have to be infinite
Our current architecture does not require a live simulation instance to span multiple machines at launch. That is a deliberate simplification. A bounded simulation instance can remain a coherent authority domain while a simulation node hosts one or more such instances. If a location becomes sufficiently busy, additional instances can be created without creating a second persistent universe underneath them.
This solves a different problem from server meshing. Instancing controls density by reducing how many participants share the same live simulation. Server meshing attempts to increase how much simulation can remain inside one shared authority space. Those techniques should not be treated as interchangeable, and neither one determines whether the underlying world is persistent.
For launch, we would rather understand the real capacity of a bounded simulation model and work from measured limits than make dynamic authority partitioning a prerequisite for the entire game. If testing later demonstrates that an individual simulation genuinely needs to exceed the practical capacity of a single node, distributing authority across multiple nodes remains an architectural option. At that point, the added complexity would be responding to a measured bottleneck rather than an assumption made years earlier.
Where server meshing fits
Server meshing broadly describes distributing simulation authority across multiple servers while presenting the result as one connected simulation space. Static approaches can partition authority along predefined boundaries, while more dynamic approaches can move or reshape those boundaries according to load. Both introduce difficult engineering problems around authority ownership, cross-boundary interaction, replication, consistency and failure handling.
Those problems are real, and if False Contact eventually requires that capability we will have to solve them. What has changed is that we no longer treat dynamic server meshing as synonymous with the architecture of False Contact itself. One persistent world does not depend on it. Persistence can remain global while simulation is instanced and distributed, and a player can move between simulation contexts without changing which universe their ship, inventory, reputation or economic activity belongs to.
That separation gives us a cleaner development path. We can establish and test the persistent world model first, measure actual simulation density and only add additional distribution complexity when the workload demonstrates a need for it. Complexity should earn its place.
Geographic distribution solves another problem again
Latency introduces a different axis. The machine simulating a player should ideally be close enough that network round-trip time remains acceptable, but geographic placement should not decide which version of the universe that player belongs to. Hosting is an infrastructure concern, not a world boundary.
That means the same persistent universe can be supported by simulation capacity in different regions without creating independent regional shards. Players in different parts of the world may be hosted differently, but durable facts should still resolve back to the same underlying state. If players separated by large physical distances need to interact in the same live simulation, there are unavoidable latency trade-offs because software architecture cannot remove the speed of light. Placement, group composition and latency policy therefore become things to measure and manage rather than things to pretend do not exist.
What we do not want is to solve latency by quietly creating separate universes whose economies, ownership and histories drift apart.
The difficult part is consistency under failure
A distributed system is easy to describe when everything is healthy. The harder questions begin when something stops being healthy. A simulation process can crash, a connection can disappear midway through an action, two systems can temporarily disagree about event order, or a write can succeed in one place while failing somewhere else. A persistent game cannot assume that every operation completes cleanly.
That is one reason the boundary between transient simulation and durable outcomes matters so much. The system needs clear authority over what is allowed to become persistent and enough information to recover sensibly when a process disappears. Otherwise a technical failure can become a duplicated item, conflicting ownership state or some other inconsistency that players carry forward indefinitely.
We are not publishing our failure-handling model in detail at this stage, but it belongs to the same architectural problem. “One world” only means something if important facts remain coherent when infrastructure behaves imperfectly.
What we are actually building toward
The public requirement is simple to state even if the implementation is not. False Contact is intended to have one persistent world. Durable ownership, economy, history and other meaningful state should remain authoritative regardless of where or how the live simulation responsible for a player happens to be running.
Live simulation can be divided. Players can be instanced where density requires it. Simulation can be geographically distributed where latency requires it. Relevancy, spatial partitioning and network culling can reduce the amount of state any one client or replication relationship has to process. What should not fragment is the persistent universe underneath those systems.
Much of this is still architecture rather than proven capability. We have design decisions and implementation work ahead of us, but no density number we are prepared to present as demonstrated yet. That comes after representative workloads, profiling and failure testing. When we eventually publish those numbers, we want them to describe something that actually ran.
The architectural position underneath all of it is much simpler:
One world is the requirement. How many simulations it takes to run that world is an implementation detail.
