A component called an access control list is used to manage which types of workers can have access to components. You can read and manipulate this component in the same way as any other component.
Which specific worker instance actually has write access is managed by SpatialOS at runtime.
Thinking about write access
In order to read from a component, or make changes to a component, workers need to have access. Which workers are allowed which type of access is controlled by an entity’s access control list (ACL).
Access control lists
The ACL determines:
- which types of workers can see an entity, and read its components
- for each component on the entity, which type of worker can write to it
Only one worker at a time can write to a component. This prevents simultaneous changes putting the simulated world into an inconsistent state.
For example: position is usually simulated on a physics worker, so we want to give a physics worker write access to the position component. An instance of the physics worker will have write access to the component; and while it has write access, it has complete control over the component. Nothing else can change the position of that entity.
See the example ACLs in the language-specific docs:
In its bridge configuration, each worker has attributes that it sends to SpatialOS. For example, it says it’s a Unity worker (it has the “physics” attribute), or a player client (it has the “visual” attribute). SpatialOS uses these attributes to work out what components a worker can have access to.
These attributes are referenced in the access control list. There, you specify what attributes a worker must have to be able to see an entity, and to write each of its components.
In an online game, you often want to give control of some components to the client.
For example, you could model user input as changes to a
PlayerControlsComponent that contains, as properties or events,
all the actions a user might make.
You could also choose to give the client control over other components, like their player entity’s position. This can help compensate for network latency. To do this, give write access on the component to the particular client that controls the player entity.
Note that giving write access to a player’s position to that player’s client can have unintended consequences, as this opens the possibility of a rogue client using this write access for its own advantage, for example making the player move faster than the game logic allows, or able to pass through walls. There are more involved techniques that can be used to compensate for network latency while not giving clients more access than they need, such as Client-Side Prediction.
You can change which worker has write access to a component at runtime. This means you can switch between server-side and client-side control by updating an entity’s ACL component.
All workers must have write access to at least one component.