Page type, addon, wizard, Remote Config — el vocabulario que aparece en toda la documentación.

Conceptos clave#

Cinco palabras aparecen una y otra vez en esta documentación. Entender bien cada una ahorra horas más adelante.

1. Proyecto#

La unidad de trabajo de mayor nivel. Un proyecto representa un juego.

Todo lo que creas (páginas, addons, exports) vive dentro de un proyecto. Puedes tener tantos proyectos como quieras en tu cuenta — uno por juego, uno por experimento, uno por cliente.

2. Página (Section)#

Una página es un concepto de tu juego. Ej.: "Espada de Hierro", "Mago Sombra", "Economía Principal", "Receta de Poción".

Las páginas se organizan en árbol — toda página puede tener sub-páginas. Típicamente un GDD tiene 5 grupos en la cima (Visión General, Diseño, Contenido, Presentación, Producción) y decenas o cientos de hijos.

3. Page Type#

El tipo de una página decide qué bloques trae preconfigurados cuando nace.

Hoy existen 10 tipos de página, cada uno con su propio wizard cuando corresponde:

Page TypeCuándo usarloQué viene dentro
📖 NarrativaTexto rico (lore, descripciones)Bloque de documento rico
🎯 AtributosLista de stats (HP, ATK, DEF)Tabla de atributos
🪙 EconomíaUna moneda del juego (oro, gema)Moneda configurable
📈 ProgresiónCurva de XP por nivelTabla de progresión
👤 PersonajesPersonaje con atributos + nivelPerfil + XP + progresión
🎒 ÍtemsÍtem simple (madera, fruta)Inventario + economía
⚔️ Ítems con efectoEquipamiento que cambia atributosInventario + economía + efectos
📜 RecetaReceta de craft (2 mad → 1 tabla)Addon de producción
🛠️ Estación de producciónEstación que agrupa recetasMesa de craft + recetas
⚡ HabilidadesHabilidades activas/pasivasSkills + modificadores

También puedes crear una página en blanco (sin tipo) y agregar addons manualmente — pero los page types tipados ahorran mucho tiempo en la configuración inicial.

4. Addon#

Un addon es un bloque semántico dentro de una página. Cada addon tiene su propio schema, panel de edición, modo solo lectura, y contribuye al JSON exportado.

Hoy hay 16 tipos de addons. Se agrupan por propósito:

La gran mayoría son singleton: solo puedes tener un addon del mismo tipo por página. Las excepciones son richDoc y exportSchema (ambos tienen sentido en múltiples instancias).

5. Wizard#

Cuando un page type tiene dependencias semánticas, el wizard pregunta cómo resolverlas antes de crear la página.

Ejemplo concreto: creas una página ⚔️ Ítems con efecto. Este tipo necesita:

  • Una página de Moneda (para tener precio)
  • Una página de Atributos (para saber qué stats modifica el efecto)

El wizard abre un diálogo y pregunta, para cada dependencia:

  1. Vincular a una página existente — elige del desplegable
  2. Crear nueva página — el wizard la crea junto a la tuya, ya vinculada
  3. Continuar sin vincular — tu página nace sin referencia; puedes vincularla después

Todo esto evita que crees una página de Ítem, descubras que falta la moneda, crees la moneda, vuelvas a editar el ítem y rehagas el vínculo manualmente.

6. Remote Config#

La capa de exportación. Define el formato exacto del JSON que recibe el motor de juego.

Diseñas un árbol de propiedades — puede ser un objeto, array o valor — y cada hoja se enlaza a un campo real del proyecto:

{
  "id": "DATA_FIRE_BALL",
  "Skill": [{
    "name": "Fireball",
    "cooldown": 1,
    "effect": [
      {
        "attr_id": "DATA_BASIC_ATTR",
        "attr_key": "hp",
        "attr_value": -10
      }
    ]
  }]
}

Remote Config es suficientemente potente para:

  • Iterar arrays (todas las skills, todas las recetas, todos los efectos)
  • Seguir referencias cross-section (efecto → modificador → sección padre → dataId)
  • Soportar 4 formatos diferentes (row-major, column-major, keyed-by-level, matrix)
  • Importar de vuelta el JSON exportado (round-trip)

7. DataID#

Un DataID es el identificador estable y legible que el motor usa para reconocer una página, independientemente del UUID interno de la app.

Por qué importa#

La app genera UUIDs internos (a8f3e9d2-7c1b-...) para cada página, pero:

  • cambian cada vez que duplicas o importas un proyecto
  • son ilegibles en el JSON exportado
  • un programador no puede "memorizar" cuál página es cuál

El DataID resuelve esto: tú decides DATA_FIRE_BALL, DATA_BASIC_ATTR, DATA_GOLD, y Remote Config exporta esos nombres en vez de los UUIDs. Las referencias entre addons (costo va a moneda, efecto va a modificador, modificador va a atributos) también se resuelven a DataIDs.

Resultado: el JSON del motor tiene claves legibles y estables. Puedes renombrar, mover o reorganizar la página en el GDD y el JSON sigue usando el mismo DATA_FIRE_BALL.

Cómo definirlo#

  1. Abre cualquier página
  2. Justo debajo del título hay un campo discreto:
    • Cuando está vacío: muestra "+ DataID" en gris
    • Cuando está lleno: muestra "ID: DATA_..." en una píldora clicable
  3. Haz clic en el campo
  4. La app sugiere automáticamente algo basado en el título — ej.: título "Espada de Hierro" → sugerencia DATA_ESPADA_DE_HIERRO
  5. Acepta o edita (recomiendo estandarizar, ej.: todo en inglés: DATA_IRON_SWORD)
  6. La app valida duplicados dentro del proyecto

Cuándo usarlo#

Define un DataID en todas las páginas que irán al Remote Config. Esto normalmente incluye:

  • Atributos, perfiles, modificadores
  • Monedas
  • Ítems (inventario, equipamiento)
  • Habilidades
  • Recetas y estaciones de producción
  • Variables globales

Las páginas puramente narrativas (lore, briefing, notas de diseño) no lo necesitan — no exportan datos al motor.

Próximos pasos#

Ahora que el vocabulario está claro: