Construindo um Schema de jogo
Última atualização: 16 de julho de 2026
Com os conceitos centrais de Schema já claros, o próximo passo é começar a montar a estrutura em si.
A visão Schema é onde todos os objetos vivem — Entities, Parts e Enums aparecem listados na barra lateral. Selecionar qualquer objeto abre os campos e a configuração dele no painel principal.
Comece pela estrutura, não pelos Records
Antes de adicionar qualquer dado, defina primeiro o formato do modelo. Uma ordem de construção bem escolhida deixa o processo mais suave — objetos criados depois costumam depender dos anteriores, e um campo não pode referenciar nem embutir algo que ainda não existe.
Crie os Enums primeiro
Enums definem os conjuntos fixos de valores que os seus campos vão referenciar. Monte-os antes de tudo, para que já estejam disponíveis quando você começar a adicionar campos a Entities e Parts.
Exemplos: TankStatus, WeaponType, ArenaSize.
Defina as Entity Parts
Entity Parts são fragmentos reutilizáveis de estrutura. Defina-os antes das Entities que vão incluí-los, para que os campos Inclusion possam apontar para eles de imediato.
Exemplos: TankConf, BattleConf, ConnectionConf.
Crie as Entities
Entities são os objetos autônomos de nível superior, com Records próprios. A esta altura os Enums e as Parts já estão no lugar, então os campos podem referenciá-los e incluí-los na hora.
Exemplos: Tanks, Leaderboards, ActiveGames.
Adicione campos e conecte os objetos
Com todos os objetos criados, adicione campos às Entities e Parts. Use campos Relationship para ligar Entities a outras Entities, e campos Inclusion para embutir Entity Parts.
Aplique as restrições
Quando a estrutura estiver estável, aperte-a com restrições — Required, Unique, valores mínimos e máximos, contagem de itens. Aplique-as quando refletirem regras reais, não só para preencher opções.
Revise na visão Data
Abra a visão Data e crie um Record de teste. Se o formulário ficar confuso ou a estrutura parecer estranha, o problema normalmente está no Schema — conserte antes de inserir dados de verdade.
Mantenha a primeira versão simples. Costuma ser mais fácil estender depois um Schema limpo do que simplificar um Schema superprojetado.
Criar uma Entity
Use uma Entity quando precisar de um objeto autônomo completo, com Records próprios.
Para criar uma, clique em + New na visão Schema e selecione Entity. Preencha:
- Name — o nome do objeto, usado em todo o Schema e na visão Data
- Description — opcional, ajuda outras pessoas do time a entender para que serve o objeto
Uma Entity representa um conceito real do seu jogo — um perfil de Player, uma configuração de arma, o registro de uma partida ou um objeto de configurações globais. Se o objeto deve existir como Record próprio na visão Data, ele é uma Entity, e não uma Entity Part.
Criar uma Entity Part
Use uma Entity Part quando quiser definir um fragmento reutilizável de estrutura que pertence a outros objetos.
Clique em + New e selecione Part. Preencha:
- Name — o nome da part
- Description — opcional
Entity Parts são úteis quando o mesmo grupo de campos deve aparecer em várias Entities, ou quando uma Entity grande deve ser montada a partir de pedaços menores e nomeados. Uma part TankConf com configurações de arma e blindagem pode ser incluída em Tanks e reaproveitada em qualquer outro lugar que precise da mesma estrutura.
Se o objeto deve viver dentro de outro objeto em vez de existir por conta própria, ele é uma Entity Part.
Criar um Enum
Use um Enum quando um campo deve aceitar apenas um valor de uma lista predefinida.
Clique em + New e selecione Enum. Preencha:
- Name — o nome do enum
- Values — a lista de opções permitidas
Enums funcionam melhor para opções controladas — valores de status, categorias, tipos. Um enum TankStatus com Active, Destroyed e Respawning garante que nenhum valor inesperado possa ser armazenado naquele campo.
Use Enum quando o valor deve vir de uma lista fixa. Use Primitive quando o valor deve ser digitado diretamente.
Adicionar campos a um objeto
Depois que uma Entity ou Entity Part existe, defina os campos dela. Clique em + Add field dentro do painel do objeto.
Cada campo exige:
- Name — letras, dígitos e underscores; precisa começar com uma letra
- Kind — o que o campo guarda e como ele se conecta aos outros objetos
Escolhendo o kind certo
- Primitive
- Enum reference
- Relationship → entity
- Inclusion ↩ part
Guarda um valor escalar direto. Use na maioria dos campos que contêm um valor diretamente — um nome, uma velocidade, uma flag, um timestamp.
Guarda um valor escalar direto. Use na maioria dos campos que contêm um valor diretamente — um nome, uma velocidade, uma flag, um timestamp.
| Tipo | Guarda |
|---|---|
| Text | String curta |
| Long text | String de várias linhas |
| Integer | Número inteiro |
| Number | Float / decimal |
| Decimal | Precisão fixa |
| Boolean | true / false |
| Date & time | Timestamp ISO |
| Date | YYYY-MM-DD |
| UUID | Identificador único |
| JSON | Objeto estruturado |
| E-mail validado | |
| URL | Link |
Restringe o campo a um valor de um Enum predefinido. Use para status, categoria, ou qualquer campo com um conjunto fixo de opções.
Depois de escolher este kind, selecione qual Enum o campo referencia. O campo só vai aceitar valores definidos naquele Enum.
Cria uma chave estrangeira para outra Entity. Use quando o objeto atual deve apontar para um Record separado, de existência independente.
Selecione a Entity de destino e a cardinalidade: 1-to-1 para um único link, 1-to-many para vários. Diferente da Inclusion, a Relationship não embute a estrutura do destino — ela guarda apenas uma referência a ele.
Embute uma Entity Part diretamente no objeto atual. Use quando a estrutura aninhada pertence ao pai e não deve existir de forma independente.
Selecione a Entity Part de destino e a cardinalidade: 1-to-1 para uma única instância embutida, 1-to-many para uma lista. Diferente da Relationship, a Inclusion insere os campos da part diretamente na estrutura do pai.
Use Inclusion quando a estrutura pertence ao objeto. Use Relationship quando o objeto deve apontar para algo que existe de forma independente.
Para a referência completa de todos os tipos e restrições, veja Schema Object Reference.
Use Singleton para Records únicos
Se um objeto deve ter apenas um Record, marque-o como Singleton ao criar ou editar a Entity.
Use Singleton para objetos de configuração global ou ajustes únicos válidos para todo o Project. Uma Entity GameConfig que guarda parâmetros de todo o servidor deve existir exatamente uma vez — não como uma lista de muitos Records.
Uma Entity comum pode ter muitos Records. Uma Entity Singleton pode ter exatamente um. A visão Data reflete isso — em vez de uma lista de Records, ela mostra um único formulário editável.
Diagrama ER
A aba ER diagram na visão Schema mostra um mapa visual ao vivo de todos os objetos e suas conexões. Ele é derivado diretamente do Schema e se atualiza automaticamente conforme você adiciona ou altera objetos e campos — sem desenho manual.
Use o diagrama ER para revisar a estrutura geral de relance, notar conexões faltando entre objetos, conferir se a cardinalidade está correta, ou compartilhar o modelo com colegas que querem entender o desenho dos dados sem navegar objeto por objeto.
Tipos de objeto
O diagrama representa os três tipos de objeto de Schema como nós com cores próprias:
Objeto autônomo
Objetos de nível superior, com Records próprios na visão Data. Referenciados ou incluídos por outros objetos.
Fragmento reutilizável
Fragmentos de estrutura embutidos dentro de Entities através de campos Inclusion. Sem Records independentes.
Conjunto controlado de valores
Listas fixas de valores permitidos. Ligados a campos através de Enum reference por todo o Schema.
Tipos de conexão
As arestas entre os nós mostram como os objetos estão conectados. O diagrama usa três estilos de linha, iguais aos da legenda no canto superior direito da aba ER diagram:
| Aresta | Estilo da linha | Conecta |
|---|---|---|
| relationship | contínua | Entity → Entity através de um campo Relationship |
| inclusion | tracejada | Entity → Part através de um campo Inclusion |
| enum | pontilhada | campo → Enum através de um campo Enum reference |
As arestas trazem a cardinalidade como rótulo quando aplicável — 1-to-many aparece nas conexões Relationship e Inclusion que usam essa configuração.
Erros comuns de modelagem
Usar Relationship quando Inclusion é a escolha certa — se a estrutura aninhada pertence ao pai e não tem ciclo de vida independente, embuta-a com Inclusion em vez de ligá-la com Relationship.
Usar Inclusion quando Relationship é a escolha certa — se o objeto vinculado existe de forma independente e pode ser referenciado de vários lugares, use Relationship em vez de embutir uma cópia.
Definir Entities grandes e planas em vez de compor a partir de Parts — quando várias Entities compartilham o mesmo grupo de campos, extraia esse grupo para uma Entity Part e inclua-a, em vez de duplicar os campos na mão.
Não adicione complexidade só porque o editor permite. Relationship, Inclusion e Entity Parts só são úteis quando refletem a estrutura real do Project.
Próximos passos
- Working with Game Data — trabalhe com os Records criados a partir do Schema
- Backoffice MCP Integration — construa ou estenda o Schema através de um assistente de IA, ou gere um Schema completo a partir de um Game Design Document de uma só vez