Authority and interest
If you’re using the GDK for Unreal, see the GDK documentation for this topic.
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.
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 rabbit 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 because this could lead to conflicts or deadlock.
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.
Server-worker instances 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 that 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.
For example, server-worker 1 contains an NPC
Fox, and updates its
Position component to move it, while server-worker 2 contains an NPC
Rabbit and likewise updates its
Position component. Server-worker 3 contains a lettuce, and updates its
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, as your NPC moves around the world, you probably need it to behave differently depending on what’s nearby. A
Rabbit runs towards a nearby
Lettuce, or away from a nearby
Rabbitstill needs to behave correctly even if the
Lettuce or the
Fox are in a different area of authority to it.
For a server-worker instance to read the state of entity components, if it doesn’t have write access authority over them, it needs to have interest. For example, a server-worker instance that has write access authority over the
Position component of a
Rabbit might have interest in the
Position component of every
Lettuce entity within a given radius of the
Rabbit, so that it can be aware of nearby threats and food.
In the description above we have focused on interest and authority for server-worker instances. Write access authority, which is the responsibility to carry out the computation required for a component, also applies to client-worker instances. But the concept of areas of authority does not apply to client-workers, because only server-worker instances share the game world, with multiple areas of authority, between them.
Note however that interest does apply to client-worker instances, since a client-worker might have interest in entities nearby, and really big entities far away. For example, distant mountains might be relevant to a client-worker instance that needs to render them so that the player can see them as they play the game.
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.
2019-12-10 Page updated with editorial review: Updated to clarify language and improve diagram