Live Data Overview #

The Player Data service contains classes and interfaces for templating a player data feature’s live data. In the service, live data is stored as an Entity, and Entities allow you to customize your own data model from a list of user-defined Components. This formula allows the developer to fully contextualize their live data models for a player data feature within the Player Data service, rather than fit their player data feature to an already existing live data model.

An Entity is created and assigned to players in an Operation function, including its structure and list of Components. The Components utilized in an Entity must be defined first before they can be authored in an Operation. Operations are also in charge of modifying and deleting Entities and their lists of Components when they’re live for a player.

An Entity and its list of Components are all defined in Kotlin. However, a Component can utilize data from a predefined Content Schema class and JSON catalog if desired.

Live data in the form of an Entity are useful for various different parts of a player data feature, and there are many different ways of solving how to model your data with Entities and Components.

Continue reading for more information about the important classes associated with live data.

Component Class #

Components are data classes for storing user-defined player data. A Component must belong to an Entity in order to be utilized by the player or game client. Every Component class implements the Component interface, which is an empty interface with no properties that the Player Data service can utilize.

Learn how to implement this class in the Define a Component class task.

Hidden Component Class #

Hidden Components are data classes for storing user-defined player data that will not be sent to the PLAYER gateway and the game client. Instead of inheriting the Component interface, a hidden Component class implements HiddenComponent, which contains logic for the Player Data service to recognize that the data should reside solely in the backend and database. In other words, all other backend gateways (SERVICE, PARTNER, and OPERATOR) will still get an unfiltered view of HiddenComponent data.

To implement this class, go to the Define a Component class for hidden data task.

Component Ordering Function #

ComponentOrdering is an annotation for a function that outlines all of your components to a unique integer. These integers will be used by the Player Data service and the engine layer to generate the Components.

Whenever you create another Component, you must add that Component to this function and give it an integer that is not already in use.

Go to the Define a Component class task for more implementation details.

Entity Class #

An Entity is a data class wrapper for containing player data in the form of Components. They contain a list of Components via a ComponentContainer and are authored with Components in an Operation function’s business logic. The Operation function is also in charge of assigning the Entity to players, modifying its Components in a live scenario, and any deletion processes.

An Entity must be created using functions from the context.snapshot object for and to add instances of custom Components to an Entity. There is no limit to how many Components you can attach to an Entity.

See the Author an Entity containing a list of Components task for implemntation details and the Snapshot reference section for class information.

Component Container Class #

ComponentContainer is a data class wrapper for containing a singular Component utilized by an Entity. It’s used by the engine layer to help with data persistence.

Learn more about this class in the Component Container Class reference section.