Page type, addon, wizard, Remote Config — o vocabulário que se repete em toda a doc.
Conceitos chave#
Cinco palavras voltam o tempo todo nesta documentação. Entender bem cada uma economiza horas depois.
1. Projeto#
A unidade de trabalho de mais alto nível. Um projeto representa um jogo.
Tudo o que você cria (páginas, addons, exports) vive dentro de um projeto. Você pode ter quantos projetos quiser na conta — um por jogo, um por experimento, um por cliente.
2. Página (Section)#
Uma página é um conceito do seu jogo. Ex.: "Espada de Ferro", "Mago Sombrio", "Economia Principal", "Receita de Poção".
Páginas se organizam em árvore — toda página pode ter sub-páginas. Tipicamente um GDD tem 5 grupos no topo (Visão Geral, Design, Conteúdo, Apresentação, Produção) e dezenas/centenas de filhas.
3. Page Type#
O tipo da página decide quais blocos ela traz pré-configurados quando nasce.
Hoje existem 10 tipos de página, cada um com um wizard próprio quando aplicável:
| Page Type | Quando usar | O que vem dentro |
|---|---|---|
📖 Narrativa | Texto rico (lore, lore, descrições) | Bloco rico de documento |
🎯 Atributos | Lista de stats (HP, ATK, DEF) | Tabela de atributos |
🪙 Economia | Uma moeda do jogo (ouro, gema) | Moeda configurável |
📈 Progressão | Curva de XP por nível | Tabela de progressão |
👤 Personagens | Personagem com atributos + nível | Perfil + XP + progressão |
🎒 Itens | Item simples (madeira, fruta) | Inventário + economia |
⚔️ Itens com efeito | Equipamento que muda atributos | Inventário + economia + efeitos |
📜 Receita | Receita de craft (2 mad → 1 tábua) | Addon de produção |
🛠️ Mesa de produção | Estação que agrega receitas | Mesa de craft + receitas |
⚡ Habilidades | Habilidades ativas/passivas | Skills + modificadores |
Você ainda pode criar uma página em branco (sem tipo) e adicionar addons manualmente — mas as page types tipadas economizam muito tempo na configuração inicial.
4. Addon#
Um addon é um bloco semântico dentro de uma página. Cada addon tem um schema próprio, painel de edição, modo somente-leitura, e contribui pro JSON exportado.
Hoje são 16 tipos de addons. Eles se agrupam por finalidade:
Atributos
attributeDefinitions, attributeProfile, attributeModifiers, skills
Progressão
xpBalance, progressionTable
Economia
currency, currencyExchange, economyLink
Itens & Produção
inventory, production, craftTable
Dados & Variáveis
dataSchema, globalVariable, fieldLibrary
Conteúdo & Export
richDoc, exportSchema
A grande maioria é singleton: você só pode ter um addon do mesmo tipo por página. As exceções são richDoc e exportSchema (os dois fazem sentido em múltiplas instâncias).
5. Wizard#
Quando uma page type tem dependências semânticas, o wizard pergunta como resolver antes de criar a página.
Exemplo concreto: você cria uma página ⚔️ Itens com efeito. Esse tipo precisa de:
- Uma página de Moeda (pra ter preço)
- Uma página de Atributos (pra saber quais stats o efeito modifica)
O wizard abre um diálogo e pergunta, pra cada dependência:
- Vincular a uma página existente — escolha do dropdown
- Criar nova página — o wizard cria junto com a sua, já vinculada
- Continuar sem vincular — sua página nasce sem ref; você pode vincular depois
Tudo isso evita você criar uma página de Item, descobrir que falta a moeda, criar a moeda, voltar pra editar o item, e refazer o vínculo manualmente.
6. Remote Config#
A camada de exportação. Define o formato exato do JSON que o motor de jogo recebe.
Você desenha uma árvore de propriedades — pode ser um objeto, array, ou valor — e cada folha bind a um campo real do projeto:
{
"id": "DATA_FIRE_BALL",
"Skill": [{
"name": "Fireball",
"cooldown": 1,
"effect": [
{
"attr_id": "DATA_BASIC_ATTR",
"attr_key": "hp",
"attr_value": -10
}
]
}]
}
O Remote Config é poderoso o suficiente pra:
- Iterar arrays (todas as skills, todas as receitas, todos os efeitos)
- Seguir refs cross-section (efeito → modifier → seção pai → dataId)
- Suportar 4 formatos diferentes (row-major, column-major, keyed-by-level, matrix)
- Importar de volta o JSON exportado (round-trip)
7. DataID#
Um DataID é o identificador estável e humano que o motor usa pra reconhecer uma página, independente do UUID interno do app.
Por que importa#
O app gera UUIDs internos (a8f3e9d2-7c1b-...) pra cada página, mas eles:
- mudam toda vez que você duplica/importa um projeto
- são ilegíveis no JSON exportado
- não dão pra um programador "memorizar" qual página é qual
O DataID resolve isso: você decide DATA_FIRE_BALL, DATA_BASIC_ATTR, DATA_GOLD, e o Remote Config exporta esses nomes em vez dos UUIDs. Refs entre addons (cost vai pra moeda, efeito vai pro modifier, modifier vai pros atributos) também resolvem pros DataIDs.
Resultado: o JSON do motor fica com chaves humanas e estáveis. Você pode renomear, mover ou reorganizar a página no GDD que o JSON continua usando o mesmo DATA_FIRE_BALL.
Como definir#
- Abra qualquer página
- Logo abaixo do título tem um campo discreto:
- Quando vazio: aparece "+ DataID" em cinza
- Quando preenchido: aparece "ID: DATA_..." num pill clicável
- Clique no campo
- O app sugere automaticamente algo baseado no título — ex.: título "Espada de Ferro" → sugestão
DATA_ESPADA_DE_FERRO - Aceite ou edite (recomendo padronizar, ex.: tudo em inglês:
DATA_IRON_SWORD) - O app valida duplicatas dentro do projeto
Quando usar#
Defina DataID em todas as páginas que vão pro Remote Config. Isso normalmente inclui:
- Atributos, perfis, modifiers
- Moedas
- Itens (inventory, equipment)
- Habilidades
- Receitas e mesas de produção
- Variáveis globais
Páginas puramente narrativas (lore, briefing, design notes) não precisam — elas não exportam dados pro motor.
Próximos passos#
Agora que o vocabulário tá claro: