Authority and interest
The core idea of SpatialOS is that your worker instances have access only to a part of the game world. This access is governed both by what the worker instance has authority over and what it has interest in.
Every SpatialOS component on every entity in the world needs a worker instance to compute it - that is, to make changes to its value in the game world. For example, if there’s an NPC with a
Position component, you probably want something to move that NPC around in the world. But you don’t want more than one worker instance at a time to make changes to this component. To deal with this, SpatialOS only allows one worker instance to have write access authority to an entity’s component at any one time. Only the worker instance with write access authority can make changes to an entity component’s value.
Write access authority is a responsibility: the responsibility to carry out the computation required for a component. This is the case for both client-worker and server-worker instances; however, it’s only server-worker instances that share the game world between them, with multiple areas of authority. When an entity moves from one server-worker instance’s area of authority to another, write access authority over the entity’s components is handed over.
How are those areas of authority defined?
You define areas of authority when you decide on the load balancing strategy for the server-worker type that has write access permission to a certain type of component. The “load” in load balancing is the computation associated with all the components that instances of this server-worker type have write access permission to.
The following diagram shows areas of authority for three server-worker instances: each instance has write access authority over certain components in their area of authority. Which components they have write access authority over depends on their worker type’s write access permission.
To carry out the computation associated with a component, a server-worker instance needs more than just write access authority over that component. It also needs to know the status of other components on other entities which it doesn’t have write access authority over.
For example, an NPC moving around the world might need to behave differently depending on what’s nearby. A rabbit might run towards a nearby lettuce, or away from a nearby fox. Even if the lettuce or the fox are in a different area of authority to the rabbit, the rabbit still needs to behave correctly.
To deal with this, a server-worker instance has interest. That is, it wants to read the state of entity components, even if it doesn’t have write access authority over them. For example, a server-worker instance that’s simulating a rabbit might have interest in every entity within a 100m radius of the rabbit, so that the rabbit is aware of the nearby foxes and lettuces.
Note that interest doesn’t apply to server-workers only: a client-worker instance might have interest in both entities nearby, and really big entities far away, such as distant mountains. Distant mountains might be relevant to a client-worker instance because it needs to render them so that the player can see them as they play the game.
Our three server-worker instances have interest in entity components which are outside each of their areas of authority.
Sending and receiving updates
When a worker instance that has write access authority makes changes to a component’s value, it sends an update to other worker instances via SpatialOS.
A worker instance with interest in an entity’s component can receive those updates, but it needs specific circumstances to have active read access and actually receive those updates. You set up these circumstances when you configure your SpatialOS game world.