What are workers?
If you want anything to happen in your simulated world, you’ll need workers.
SpatialOS manages the world, keeping track of all the entities and what state they’re in. But on its own, it doesn’t make any changes to the world. All the logic and computation is done by workers.
Workers can be thought of as ‘spatial microservices’ that connect to a simulated world, and can read what’s happening, watch for changes, and make changes of their own. For example, a player’s client is one kind of worker. When a player presses a key, the client sends an update to SpatialOS saying that an event has happened on the entity that is the player’s avatar: for example, that the “fire” button has been pressed.
When this happens, the response to this event is also carried out by workers. A logic worker might need to create a new entity, the bullet. The client visualizes the action of firing. A physics worker checks to see if the bullet collides with anything. And if it hits another player, workers come in again, to carry out the logic of reducing health, and so on.
Which workers you need depends on your simulated world. Most games will need, at least:
- managed workers (that implement server-side logic and physics)
- clients (for players to interact with and view the game)
But you can have workers for whatever you need. You could have a worker that fetches data from outside sources (for example from a database, or real-time weather data, or a social network feed) and makes it part of the simulated world, or a worker that specializes in pathfinding and routing.
Building your simulated world in this way allows SpatialOS to scale it massively, without the complexity of more traditional approaches.
The amount of work that each type of worker needs to do will vary. It might be that, for one type of worker, there’s not much for it to do - so you only need one instance of the worker to do the work for the whole world.
But what happens when that amount of work increases, for example if a lot of players connect? Suddenly, that single instance of the worker can’t get all that work done. It might become incredibly slow, or fall over altogether.
This is where it becomes important that every entity in the world has spatial locality: it allows SpatialOS to split up the work in different areas of the world, and allocate it to different instances of a worker. When an instance of a worker is struggling with a high workload, SpatialOS automatically detects this. It then starts up new instances of the worker, and gives them responsibility for an area of the world, reducing the amount of work each instance is doing to a level it can handle.
This also means that an entity won’t necessarily stay on the same worker instance, even if that entity doesn’t move. SpatialOS may change which areas of the world a worker instance is responsible for, so entities move from one worker instance’s area to another. Even though the entity may be staying still, the worker instance itself is effectively moving.
Workers connect to your simulated world. They can:
- read the current status of entities in the world
- watch for changes to components
- make changes of their own
Standard types of workers
Types of workers include:
Unity is a game engine. SpatialOS provides an SDK so you can easily integrate Unity with a SpatialOS simulated world. As a worker, Unity is commonly used for physics simulation and game logic.
You can build a worker in Unity using the Unity SDK.
You can also use Unity as a client worker, which players of your game can use to connect to your simulated world.
Unity clients are normally used to visualize the simulated world, and send player input (like key presses and mouse movements) to SpatialOS for other workers to respond to.
You can build a client in Unity using the Unity SDK.
Unreal is a game engine. SpatialOS provides an experimental SDK so you can integrate Unreal with a SpatialOS simulated world. Similar to Unity, Unreal is commonly used for physics simulation and game logic. You can build a worker in Unreal using the experimental Unreal integration.
Similar to Unity, you can also use Unreal as a client worker, which players of your game can use to connect to your simulated world.
Unreal clients are normally used to visualize the simulated world, and send player input (like key presses and mouse movements) to SpatialOS for other workers to respond to. You can build a client in Unreal using the experimental Unreal integration.
You can build a worker in C++, using the C++ worker SDK.
You can build a worker in C#, using the C# worker SDK.
You can build a worker in Java, using the Java worker SDK.
Managed and external workers
Most workers that connect to SpatialOS are managed: the workload of instances of the worker is controlled by SpatialOS, and if an instance becomes overloaded, SpatialOS will start more instances to handle the load.
Game clients, used by players to connect to a game, are an exception. Because each instance is tied to a player, and runs in the player’s machine, SpatialOS can’t manage their workload in the same way. These are external workers.
The work that workers do
The work done by workers includes:
- Get input from the outside world, and write it to a component
- Watch for changes to components
- When something changes,
- Run some logic
- Write to a component
For more information about the kinds of work a worker can do, see the documentation for the worker.
Write access to components
Multiple worker instances can read from a component, but only one of them at a time can write to a particular component.
In order to either read or write from an entity, worker types and instances need to be given access, using an access control list on each entity.
For more information, see Understanding write access.
For information how you can configure workers, see the worker configuration documentation.