Building a Game Schema
Once the core schema concepts are clear, the next step is to start building the structure itself.
In PlayServ Backoffice, schema design usually begins with the objects that define the model: Enums, Entity Parts, and Entities. As the model grows, these objects are connected through fields, arrays, references, and inheritance.
This guide explains how to create schema objects, how to choose the right field types, and how to build a structure that stays clear and reusable as the project expands.
Start with the structure, not the records
Before working with actual data, define the shape of the model first.
In practice, schema design usually starts in this order:
- create the basic Enums
- define reusable Entity Parts
- create Entities that use those parts
- add relationships between objects
- apply inheritance where needed
This order makes the setup easier because later objects often depend on earlier ones. A field cannot reference or embed an object that does not exist yet.
For example, an Entity may need to reference another Entity, or embed an Entity Part as a nested type. Building the structure in a logical order helps avoid rework later.
Create an Entity
Use an Entity when you need a complete standalone object.
To create one, open the schema view and choose to add a new Entity. The creation flow allows you to define:
- the object name
- an optional parent type
- an optional description
If the object should inherit from another Entity, select its parent during creation or assign it later through the editor.
An Entity usually represents something that should exist as its own record in the project, such as a player profile, a shop item, a match configuration, or a global system object.
If the object is meant to exist as a full record in the Data view, it usually belongs in Entity rather than Entity Part.
Create an Entity Part
Use an Entity Part when you want to define a reusable portion of structure.
Entity Parts are useful when the same group of fields should appear in multiple places, or when a larger object should be assembled from smaller pieces instead of being defined all at once.
The creation flow is similar to an Entity and includes:
- the object name
- an optional parent type
- an optional description
A good use case for an Entity Part is a block of stats, inventory structure, configuration settings, or another fragment that belongs inside larger objects.
If the object should usually live inside another object, it is often a better fit for Entity Part.
Use Parent Type for inheritance
When two objects share the same base structure, inheritance can help reduce duplication.
To do this, assign a Parent Type to the child object. The child then inherits the parent's fields and extends that structure with its own fields.
Use inheritance when:
- several objects share the same base shape
- the child should extend the parent rather than repeat it
- the shared structure should stay consistent across multiple related objects
Use inheritance for true parent-child relationships. If the goal is simply to assemble one object from reusable parts, composition through Type is usually the better choice.
Create an Enum
Use an Enum when a field should allow only one value from a predefined list.
To create an Enum, define:
- the enum name
- an optional description
- the list of allowed values
Enums are best used for controlled options such as state, category, type, or status values. They help keep records consistent and prevent free-form values from drifting over time.
Use Enum when the value should come from a fixed list. Use Primitive when the value should be entered directly.
Add fields to an object
Once an Entity or Entity Part has been created, the next step is to define its fields.
Each field represents one piece of data inside that object. In the editor, a field can include:
- a name
- a type
- an optional description
- optional constraints
- a default value, where supported
- Array, Required, and Show in table settings
Good field design starts with a simple question: what exactly should this object store?
From there, the next decision is the field type.
Choose the right field type
The editor supports four main field types: Primitive, Enum, Type, and Reference.
Use Primitive for direct values
Choose Primitive when the field should store a direct value such as text or a number.
Typical examples: name, amount, radius, speed, description.
Use Enum for controlled values
Choose Enum when the field should accept one value from a fixed list.
This is the right choice for values such as category, state, battle type, or color.
Use Type for composition
Choose Type when another schema object should exist inside the current object as part of its structure.
This is the right choice when the nested object belongs inside the current object and should not be treated as a separate standalone record.
Use Reference for linking
Choose Reference when the current object should point to another standalone object instead of embedding it.
This is the right choice when the current object needs a link to an existing Entity.
Use Type when the nested structure is part of the object. Use Reference when the object should point to something separate.
Use arrays for repeated values
If a field should store multiple values instead of one, enable Array.
This is useful for:
- lists of embedded objects
- lists of references
- repeated primitive values
- grouped configuration entries
Use arrays when the model naturally contains a collection rather than a single value.
Array changes the shape of the field. A non-array field stores one value, while an array field stores a list of values of the same type.
Apply constraints and field settings
Field settings help make the model more consistent and reduce invalid data.
Depending on the field type, the editor can support:
- default values
- minimum and maximum values
- minimum and maximum length
- minimum and maximum item count
- Required
- Show in table
Use constraints when the field should follow clear limits. For example, a numeric amount should not fall below zero, or a list should not exceed a certain size.
Use Required when the field should always be present.
Use Show in table when the field should be visible in table-based record lists.
Constraints are most useful when they reflect real business rules, not just technical preferences.
Use Singleton for unique records
If an object should have only one data record, mark it as Singleton.
This is useful for global settings, unique configuration objects, or other project-wide records that should exist only once.
A Singleton changes how the object behaves in the Data view, because the model is no longer treated as a repeatable collection of many records.
A regular object can have multiple records. A Singleton can have only one.
Build the model gradually
A good schema usually does not appear fully formed on the first pass.
A practical approach is:
- define the smallest useful objects first
- connect them through Type and Reference fields
- introduce inheritance only where it clearly reduces duplication
- apply constraints once the structure is stable
- review the Data view to make sure the resulting records are easy to work with
Keep the first version simple. It is usually easier to extend a clean schema later than to simplify an overdesigned one.
Common design mistakes
A few mistakes tend to cause confusion early on.
Using Reference when the structure should actually be embedded can make the model harder to follow.
Using Type when the object should really be separate can lead to unnecessary duplication.
Creating too many large objects before defining reusable parts can make the schema harder to maintain.
Adding inheritance too early can also complicate the model if the relationship between objects is not truly parent and child.
Do not add complexity just because the editor allows it. Arrays, inheritance, references, and reusable parts are useful only when they reflect the real structure of the project.
In general, it helps to keep the first version simple and only add extra structure when the need is clear.
Next step
Once the schema structure is in place, the next step is to work with the records created from it.
That flow is covered in Working with Game Data.