Entities

In the previous sections, we have covered entities in context of the server's game state and entities in context of the client-server communication. Entities on the client side are - again - a little different.

Entity Class Types

There are four types of entity classes. Each type has a different purpose.

Base Entities

This is the base class for an entity which holds the base functionality for an entity. This type class is not used directly but is inherited by other entity classes.

INFO

Not every entity class needs to inherit from a base entity class if there is no shared functionality.

Remote Entities

A dynamic or server entity that is created from the server's game state and is not owned by the current client. It is responsible for updating the entity based on the server's game state. These Entities might be owned by another client or are updated directly by the server.

Local Entities

A dynamic entity that is created from the server's game state and is owned by the current client. It has a physics body that can collide with other local or shared entities and the world bounds. It can update the server's game state for its corresponding game state entity.

Shared Entities

A static entity that is created from the server's game state and can be updated by any client. It has a physics body that can collide with local entities and the world bounds. It can update itself based on the server's game state and also updates the server's game state if needed.

Interfaces

Entity Interface

Each entity class must implement the Entity interface which defines the basic entity methods:

The update method is called every frame and is used to update the entity. The destroy method is called when the entity is destroyed and should clean up the entity (e.g. remove event listeners, physics bodies).

Synchronizable Interface

If the entity is present in the server's game state, it must also implement the Synchronizable interface:

Update Cycle

The update Method of each entity is called on each frame update. All entities that implement the Synchronizable interface have two more update methods which are called at a fixed rate.

The entity manager needs to make sure that the updateClientState method is called before the updateServerState method. In addition, the update method always needs to be called between these two methods. How often the update method is being called in between does not matter.

By having three update methods, it is possible debounce updates:

Imagine we have a storyteller entity that can be triggered by any player. When a player triggers the entity, the storyteller shows the next storyline. The new entity state then needs to be sent to the server. The only problem is, that before the server has received the new entity state, the server might send a new state update.

To prevent this, each method has a specific purpose:

• When updateServerState is called, the entity containing a local change sends a state update to the server.
• When updateClientState is called, the entity checks if the remote state matches the local state. If that's the case, the local changes are resetted and the entity updates itself based on the server's game state. Otherwise, it skips the update and waits until the server has received the new entity state sent by the updateServerState method.
• When update is called, the entity updates itself based on local changes such as local keyboard input or animations.

Gravity Interface

If the entity needs to be notified when the gravity has changed, it must implement the Gravity interface:

Physics Labels

Each entity type that is present in the local physics world must have a physics label. This label is used to identify the entity type on collision events.

Currently, the following physics labels are available:

Entities

The entity's class name must start with the entity's class type followed by the entity's name (e.g. BasePlayer or SharedPressurePlate). This naming convention helps to identify the entity's class type.

Each entity class is built up of multiple components that are responsible for different functionalities. You can find more information about the different components in the components section. The entity class itself is responsible for creating the entity's sprite and physics body. It also shares values between different components and calls the components' update methods.

INFO

The following class diagrams are simplified and only show public properties and methods that are not already defined in any interface.

Player Entity

This entity represents a player in the game. Based on the player's character type, the player entity has a different sprite and has reversed gravity or not.

The base class initialized the player's sprite and physics body. However, the physics body of the local player is a little different from the remote player.

In addition, local players have multiple sensors that are used to detect the ground, walls, and ceiling:

In the image above, the blue reactangles represent the player's sensors. These sensors are used by components to play different animations, sounds, or limit the player's movement (e.g. jumping is only allowed when standing on the ground).

Box Entity

This entity represents a box in the game. It has a physics body that can collide with other entities and the world bounds. It is handled by the client that controls Moot.

Door Entity

Since doors are calculated on the server, there is only a remote door entity. The door's sprite and hitbox are updated based on its open state.

Breakable Floor Entity

Since breakable floors are static entities, there is only a shared breakable floor entity. The breakable floor's sprite and hitbox are updated based on its broken state.

Collectible Entity

Since collectibles are static entities, there is only a shared collectible entity. The collectible's sprite and hitbox are updated based on its collected state. When collected, the collectible shows a particle effect.

Pressure Plate Entity

Since pressure plates are static entities, there is only a shared pressure plate entity. The pressure plate's sprite and hitbox are updated based on its triggered state.

Storyteller Entity

The storyteller entity is a static entity that shows a speech bubble above the entity when triggered. The speech bubble shows the current storyline based on the entity state.