5. Offloading

In this part of the tutorial, you learn how to split the computation done by the Unreal server-worker across two or more server-workers. This reduces the computational load on the main server-worker instance and lets it run other game systems at a larger scale. This process is known as offloading.

Watch the video for this part of the tutorial:

Each offloaded server-worker instance computes one set of Actor types across the whole game world. Advanced AI is a good candidate for offloading, because it is computationally expensive but latency-tolerant.

Image: Map05_Offloading. It is similar to Map03_RPCs, but the SpatialOS Runtime offloads all target dummy processing to a dedicated server-worker.

5 - Offloading
Before you play this map, make sure you do the offloading setup as described in the written documentation and video for this tutorial.

Offloading allows you to split the computation done by the main Unreal server-worker instance between two or more server-worker instances. This reduces the computational load on the main server-worker instance.

This map is similar to the RPCs map, but the SpatialOS Runtime offloads the processing for the target dummy to a dedicated server-worker. For more information, use the Inspector to examine the Actors and look at the BP_Target_Dummy Blueprint Class in Unreal Editor.

Offloading setup

In SpatialOS, we say that a worker instance has authority over an Actor when it has the responsibility to carry out the computation for that Actor. We say that the server-worker instance that has authority over an Actor is the authoritative server for that Actor.

In this part of the tutorial, you define which worker types have authority over which Actors in the game. You define a worker type to handle the target dummy. The rest of the computation will be done by the main worker type (the DefaultLayer).

To enable offloading in this map, follow these steps:

  1. Open the Example Project in the Unreal Editor.
  2. In the Content Browser, open InGameTutorial > Maps > Map05_Offloading.
  3. To stop your existing local deployment, in the GDK toolbar, click Stop Deployment.
    Don’t start the game yet.
  4. In the Content Browser, open InGameTutorial > Maps.
  5. In the Maps folder, create a new folder called Offloading.
  6. In the Offloading folder, create a Blueprint Class with SpatialMultiWorkerSettings as its parent class. Call the new Blueprint Class MultiWorkerSettings.
    Note: This is the Blueprint Class where you configure your offloaded workers and define which Actors they have authority over.
  7. Open the new Blueprint Class.

Image: The initial Multi-Worker options in the MultiWorkerSettings Blueprint Class

  1. Select the + icon next to Worker Layers.
    This creates a new layer. We call each server-worker type a “layer”, so this layer represents an offloaded server-worker. We will leave layer 0 as the DefaultLayer.
  2. Expand the new layer (element).
  3. In Name, enter Offloading.
  4. Select the + icon next to the new element’s Actor Classes.
    This is the list of Actors that this worker layer will have authority over.
  5. For the first element, select BP_DummySpawner.
    This means the offloaded server we named Offloading (the server defined by layer 1) manages BP_DummySpawner.
  6. Again, select the + icon next to the new element’s Actor Classes.
  7. For the new element, select BP_TargetDummy.
    This means the offloaded server we named Offloading (the server defined by layer 1) manages BP_TargetDummy.
  8. In Load Balance Strategy, select SingleWorkerStrategy.
  1. From the Blueprint Editor toolbar, select Compile.
  2. Save and close the Blueprint Class.
  3. In the Unreal Editor’s World Settings panel, ensure that Enable Multi Worker is selected.
    (If the World Settings panel is not visible, select Window > World Settings.)
  4. In Multi Worker Settings Class, select MultiWorkerSettings.
  5. In the Unreal toolbar, click Play.

When you play the game, this map appears to be the same as Map03_RPCs. However, the processing is split between more than one server-worker instance. You can see this in the Inspector.

Offloaded worker instances in the Inspector

To see which worker instances are running with the Inspector, follow these steps:

  1. Keep your game running and switch to the Unreal Editor.
  2. In the GDK toolbar, click Inspector. This opens the Inspector in your default web browser.
  3. In the top bar of the Inspector, click Comprehensive view > [Default] Workers.

In the Worker Table module you see UnrealWorker entries, representing the main server-worker instance and the offloaded server-worker instance respectively.

Image: The Worker Table module with the two UnrealWorker entries

To view the UnrealWorker entries:

  1. Select the checkbox next to one of the UnrealWorker entries.
    The viewport below the Worker table displays details of the UnrealWorker you selected.
  2. In the viewport, click any of the entities.
    The Entity details module displays details of the entity.
  3. In the dropdown list at the top of the Entity details module, select the BP_TargetDummy_C entity.
  4. Click the Authority tab.
    The Inspector shows which worker has authority over the components of this entity.
  5. In the dropdown list at the top of the Entity details module, select the BP_GDK_PlayerController_C entity.
    Note that the UnrealWorker that has authority over it is different from the UnrealWorker that has authority over BP_TargetDummy_C.

The offloaded server-worker instance has authority over the dummy, and the main server-worker instance has authority over the player character.

Image: Entity view for BP_TargetDummy and BP_PlayerController. Notice the different UnrealWorkers (server-worker instances) for both

Cross-server RPCs in an offloaded environment

In an offloaded environment, SpatialOS uses cross-server RPCs to allow communication between worker instances. In this tutorial, when the player fires at the target dummy, the worker instances involved in our offloaded configuration are as follows:

Event
Worker instance

The player presses the fire button.

Player’s client-worker instance

The game performs a line trace from the tip of the player’s weapon forwards to detect if the player hit something.

Main server-worker instance

If the player hit a target dummy, the game calls the DealDamage cross-server RPC.

Main server-worker instance

The DealDamage function implementation destroys the target dummy.

Offloaded server-worker instance

For another example of how cross-server RPCs would work with multiple servers, see the diagram in Cross-server RPCs.

How to set an event to operate cross-server

To set a Blueprint event to operate cross-server, set its Replicates property to Run on authoritative server (sent from server).

Image: The Replicates property in a Blueprint Class

In C++, you simply add the CrossServer tag to UFUNCTION.

Image: DealDamage event of Target Dummy set to execute on the server-worker instance that has authority over the target dummy

In the next part of the tutorial, you learn how to test your game at scale with simulated players.


2020-08-12 Page added with editorial review

Updated about a year ago



5. Offloading


Suggested Edits are limited on API Reference Pages

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