To get the most out of this page, we recommend you read the previous pages on SpatialOS concepts. If you need further information about terminology used, take a look at the glossary.
SpatialOS hosts the server element of your multiplayer game. You set up the server hosting via SpatialOS deployments.
In production, you always use cloud hosting, but during development you can test your game with both cloud hosting and local hosting (where your development machine emulates cloud hosting).
As you learned in Workers and load balancing, you decide how many server-worker instances your world needs, and how to organise them across the world. In a deployment, SpatialOS starts those server-worker instances for you, running them on machines in the cloud (and orchestrating this for you - you don’t need to interact with the machines directly).
SpatialOS also mediates client-worker connections.
A deployment run is an instance (running or stopped) of a deployment. Each deployment run of a cloud deployment is assigned an
int64 number as a unique identifier, which is called the Run ID. (Local deployment runs don't have Run IDs.)
You might find the Run ID useful in situations when the deployment name is not enough to uniquely identify a specific run of deployment. For more information, see Deployment runs.
The SpatialOS Runtime manages your game world. There is one Runtime instance for every game deployment. It is made up of the following parts:
- Entity database: Holds the canonical store of all SpatialOS entity data.
- Bridge: Handles server-worker and client-worker instance connections and manages their read access.
- Load balancer: Coordinates each worker instance’s write access to the entity database.
Each server-worker and client-worker connection is assigned a unique bridge that communicates with other parts of the Runtime on the worker instance's behalf. The bridge makes sure the worker instance only receives updates about the part of the game world that it is allowed to receive updates about.
Your worker instances don't communicate with the entity database directly. Instead, when a worker instance wants to make a change to an entity, it sends that request to its bridge. The bridge then forwards the request to the entity database on the worker instance's behalf.
2019-10-23 Page updated with editorial review: Edited "Deployments" and "Deployment runs"
2019-09-11 Page created with editorial review: Moved "Deployments" section here from the "Workers and load balancing" page; added "Runtime" section
Updated 11 months ago