Authority and interest

GDK for Unreal

If you're using the GDK for Unreal, this page does not apply to you. See the GDK documentation on authority and interest.

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. The worker instance with write access authority over the component must carry out the computation required for that 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.

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 Edible component.


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 Fox. The 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 Fox and Lettuce entity within a given radius of the Rabbit, so that it can be aware of nearby threats and food.

Client-worker instances

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.

More information

2019-12-10 Page updated with editorial review: Updated to clarify language and improve diagram

Updated about a year ago

Authority and interest

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.