Skip to main content

Schema Object Reference

This page explains the core schema concepts used in PlayServ Backoffice.

Use it when you need a clear definition of a schema object, field type, or field setting and want to understand how it fits into the overall data model. It is meant to answer direct questions such as what an Entity is, how a Reference differs from a Type, or what happens when an object is marked as a Singleton.

Schema overview in the PlayServ Backoffice

Game Schema and Game Data​

At the highest level, the schema and the data serve different roles.

Game Schema is the formal definition of a project's data structure. It describes which objects exist in the project, which fields they contain, which values those fields are allowed to store, and how those objects relate to one another.

Game Schema view in the Backoffice

Game Data is the actual set of records created from that structure. If the schema defines the shape of the data, the data view contains the real values entered according to that shape.

Game Data view in the Backoffice

A simple distinction helps here: schema defines what can exist, while data contains what already exists.

Entity, Entity Part, and Enum​

The schema is built from three core object types: Entity, Entity Part, and Enum.

An Entity is a top-level schema object that defines a complete standalone structure. Use it for primary objects that should exist as their own records in the project.

An Entity Part is a reusable schema object that defines a portion of structure intended to be used inside other schema objects. It is useful when the same group of fields needs to appear in more than one place, or when a larger object should be assembled from smaller parts instead of being defined all at once.

An Enum is a type that defines a fixed set of allowed values. Use it when a field should accept one value from a controlled list rather than free-form input.

The easiest way to distinguish these three is by role:

  • an Entity defines a complete object
  • an Entity Part defines a reusable piece of structure
  • an Enum defines a controlled list of values

Entity, Entity Part, and Enum in the schema editor

Fields and primitive values​

Every Entity and Entity Part is built from fields.

A Field is a single property inside an object. Each field represents one unit of data, such as a name, a status, a numeric value, or a link to another object.

One of the simplest field types is Primitive. A Primitive field stores a direct value such as string, int, boolean, or float. Use a Primitive when the field should hold a value directly instead of referring to another schema object.

Primitive field type in the schema editor

Type and Reference​

Two of the most important field types in the schema are Type and Reference.

A Type field embeds an Entity Part directly inside the current object. Use it when the nested structure should exist as part of the object itself rather than as a separate record. In practice, Type is used for composition: it lets you build larger objects from reusable structural parts such as configuration blocks, stat groups, or other nested fragments of data.

Type field pointing to an Entity Part

A Reference field points to another Entity instead of embedding it. Use it when the current object should link to a separate standalone record rather than contain its full structure inside it. In practice, Reference is used for relationships between records, where one object needs to point to another object that exists independently in the project.

Reference field pointing to a standalone Entity

This means the distinction is not only conceptual, but also structural:

  • Type is used for composition through Entity Parts
  • Reference is used for linking to standalone Entities

In the editor, this difference is reflected directly in the selection flow. When you choose Type, the target is selected from the list of Entity Parts. When you choose Reference, the target is selected from the list of Entities. This makes the intended use of each field type explicit in the UI.

Field settings​

In addition to its type, a field can also be configured with additional settings that affect how it behaves in the schema and how it is presented in the interface.

The Array setting changes the field from a single value to a list of values of the same type. This is useful when the object should store multiple entries instead of one.

The Required setting makes the field mandatory. Use it when the object depends on that field having a value.

The Show in table setting controls whether the field is displayed in table-based views. This is useful for deciding which values should appear in record lists and overview screens.

Array, Required, and Show in table field settings

Parent Type and inheritance​

Schema objects can also use Parent Type, which enables inheritance.

A Parent Type is the base object from which another object inherits fields and structure. The child object then extends that base instead of redefining everything from scratch.

Inheritance is the mechanism behind that relationship. It allows one object to reuse the structure of another and then add its own fields on top.

Parent Type selection in the schema editor

This is useful when several objects share the same base shape but should still differ in specific ways. Instead of duplicating the same fields across multiple objects, you define the shared structure once and extend it where needed.

Inheritance structure showing a child object extending a parent

Singleton​

A Singleton is a schema object for which only one data record can exist.

This is useful for global configuration objects or unique project-wide settings that should not appear as a list of many records.

The distinction is simple:

  • a regular object can have multiple data records
  • a singleton object can have only one

Singleton setting on a schema object

Constraints and field settings​

In addition to field types, the editor also supports settings that control how a field behaves.

Constraints are rules that limit what values a field can accept. Depending on the field type, this can include rules such as minimum value, maximum value, minimum length, maximum length, or limits on the number of items in an array.

The Required setting makes a field mandatory. It does not change the field type, but it means the object depends on that field having a value.

Show in table controls whether the field appears in table-based views. This affects how records are displayed in the interface, especially in list and table layouts.

Constraints and field settings panel

How these concepts work together​

These concepts are easiest to understand when seen as parts of one system.

The schema starts with core objects such as Entities, Entity Parts, and Enums. Those objects are built from fields. Fields can store direct values through Primitive types, use controlled values through Enums, embed structure through Type, or link to other objects through Reference. Arrays allow repetition, inheritance reduces duplication, and Singleton is used when only one record should ever exist.

Together, these concepts define the structure that the project's data will follow.

Next step​

To move from definitions to hands-on setup, continue with Building a Game Schema.