4. Plan entity representations

In this section we’re going to decide how to represent the HealthPickup entity in our client-workers and in our server-workers. Let's review the relevant design constraints listed above:

  1. A pick-up grants health to a single player which walks over them.
  2. After the health pack is consumed, it is no longer visible to clients and no longer grants health.
  3. After a period of time, the health pack is "respawned" and is available to be picked up again.
  4. Critical interactions like: collision detection between the player and the health pack and granting the health is done on the game logic worker. That is to say, we do not trust the client.

From these we can derive some rules about how the UnityClient and UnityGameLogic workers should represent the HealthPickup entity:

  • The UnityClient client-worker should display a visual representation for each health pack in the world. It should only display health packs that are currently "active". It should not do any collision detection.
  • The UnityGameLogic server-worker should have a physical representation for each health pack in order to do the collision detection. The collider on the health pack should be turned off when the health pack is not active. It does not need to visualise the health pack.

The FPS Starter Project uses the SpatialOS GDK's MonoBehaviour workflow. In this workflow SpatialOS entities are represented by Unity prefabs. Crucially, you can use different prefabs to represent the same type of entity on different types of workers. This allows you to separate client-side and server-side entity representation, as we planned above.

The FPS Starter Project uses the AdvancedEntityPipeline implementation of the IEntityGameObjectCreator interface from the GameObject Creation feature module to handle the instantiation of GameObjects to represent SpatialOS entities.

This tracks associations between entities and prefabs by matching their Metadata component's metadata string to the entity types defined in the prefab mapping assets in Assets/Fps/Config/, such as ClientPrefabMapping. If the worker receives information about a new SpatialOS entity then the GameObject Creation package instantiates a GameObject of the appropriate type to represent that entity.

Client-side entity prefabs are mapped in Assets/Fps/Config/ClientPrefabMapping, while server-side ones are defined at Assets/Fps/Config/GamelogicPrefabMapping.

The Assets/Fps/Config/ClientPrefabMapping asset defines 2 prefabs for the Player entity type using an OwnedWorkerEntityResolver, OwnedPrefab and UnownedPrefab. The OwnedPrefab will be instantiated for the client's own player, and the UnownedPrefab for all others. This can be used to differentiate between "your" player representation, and other players.

Updated about a year ago

4. Plan entity representations

Suggested Edits are limited on API Reference Pages

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