Get SpatialOS

Sites

Menu

Access control lists

In order to read from a component, or make changes to a component, workers need to be granted access, using an access control list.

Access control lists

Every entity has a component called an access control list (ACL). (Read more about the component definition.) At runtime, EntityAcl can be edited by the worker which has write access - in the same way as any other component.

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:

Worker attributes

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.

Client-side authority

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 authority of a player’s position to that player’s client can have unintended consequences, as this opens the possibility of a rogue client using this authority 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 authority than they need, such as Client-Side Prediction.

You can change which worker has write acess 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.

Was this page helpful?

Thanks for letting us know!

Thanks for your feedback

Need more help? Ask on the forums