Hub Config#

Hub Config es donde fijas tus preferencias del editor — idioma, tema, layout — y, cuando las necesites, le apuntas a Ignitor a herramientas que instalaste tú. Llegas a él desde el Hub, y sus ajustes se guardan en un pequeño archivo hub-config.json en la raíz de tu workstation.

La mayoría de las veces lo abrirás solo para cambiar idioma o tema. Todo lo demás es opcional: el editor corre y la autoría funciona de fábrica, y solo llenas una ruta de herramienta el día que llegas a una función que la necesita.

Rutas de herramientas (opcionales)#

Un puñado de flujos avanzados se apoyan en herramientas que instalas tú. Cuando lo hacen, Ignitor usa la ruta exacta que pongas aquí — en Windows y macOS no siempre están en el PATH, y un editor empaquetado no puede ver una instalación gestionada por nvm o brew en absoluto. Ninguna hace falta para la autoría del día a día, e Ignitor te avisa cuando una función quiere una que no configuraste, así la agregas en el momento.

Los campos que ves están filtrados según tu setup. Hub Config le pregunta al host qué puede hacer de verdad y oculta las rutas que no aplican, para que la lista sea honesta. La sección de Android es la excepción: se muestra siempre, en cualquier host — Android es el único target cross-host, y la instalación del JDK/SDK ya no espera a que haya un shell de Android descargado (son cosas independientes; desde 1.1.5). Y unas cuantas herramientas de compilar-desde-fuente — Git, Rust/Cargo, el CLI de Tauri, el comando de build y el NDK de Android — ya no se muestran en absoluto: exportar pasa ahora por plantillas precompiladas, así que nada las lee. Así que si un campo de los de abajo no está en tu pantalla, es por eso — tu setup no lo necesita.

Los que sí podrías configurar:

• Python 3.10 (con Pillow + NumPy) — potencia las herramientas de limpieza de sprites/personajes y MusicGen. El arte ya limpio se importa sin él. Exportar el juego para web también necesita un Python, aunque para eso alcanza con uno pelado — sin paquetes extra.
• Instalar Python 3.12… — para la máquina que no tiene ninguno. Descarga un Python autocontenido (~75 MB) dentro de la carpeta de Ignitor, más Pillow y numpy, y te llena el campo. No instala nada en el sistema, no toca tu PATH y no se pelea con Homebrew ni pyenv — desinstalarlo es borrar esa carpeta. Te muestra el tamaño y la versión exacta antes de bajar nada, y verifica la descarga contra un checksum fijado antes de descomprimirla. Usalo si Detect no encuentra nada.
• Node.js — se usa al exportar tu juego (web/escritorio/Mac/iOS). Vacío usa node del PATH; en el editor Mac instalado lo pones aquí, porque una app con GUI no puede ver un node gestionado por nvm/brew.
• Detect Python + Node… escanea tu PATH, las carpetas de instalación típicas y los gestores de versiones (nvm, Homebrew, pyenv) para ambos, y llena los campos que estén vacíos — nunca pisa una ruta que pusiste a mano. Donde más sirve es en el editor instalado en Mac, que es justo donde una app de GUI no puede ver esas instalaciones por su cuenta.
• Rhubarb — para el horneado de lip-sync del Editor de Voces. Si tu instalación trae un Rhubarb integrado se usa automáticamente y el campo muestra esa ruta resuelta; si no, apúntalo al tuyo.
• JDK / SDK de Android — solo para exportar a Android, y normalmente ni los tocas: Ignitor descarga y configura el JDK 17 y el SDK por ti la primera vez que compilas. El diálogo te dice exactamente qué versiones va a bajar (Eclipse Temurin y las herramientas de línea de comandos de Google), y las dos descargas se comprueban contra un SHA-256 conocido antes de descomprimir nada — si no coincide, la instalación se detiene en vez de seguir. No hay campo de NDK: un APK/AAB normal no lo necesita.

La lista completa y siempre al día — con para qué sirve cada campo — está abajo.

Referencia de campos#

Rutas de herramientas#

Apariencia#

Privacidad y telemetría#

Usar una fuente que ya tienes instalada#

Fuente del editor trae algunos presets seguros y además una opción Personalizada: elígela y escribe el nombre de la familia de cualquier fuente instalada en tu máquina — el que muestra tu visor de fuentes o tu procesador de texto, no el del archivo. El chrome del editor la toma al recargar.

Dos cosas que conviene saber:

• No se copia ni se importa nada. Estás guardando un nombre, no un archivo. El ajuste vive en tu hub-config.json local, así que nunca entra a un proyecto ni viaja adentro de un juego exportado. Es a propósito: importar un archivo de fuente pasa por el Font Manager a los assets de tu proyecto, donde sí se distribuye con tu juego — perfecto para una fuente que tienes licencia de distribuir, y un problema para una que sólo tienes instalada. Pintar tu editor y shippear una fuente quedan separados por diseño.
• Un nombre que no coincide con nada es inofensivo. El editor se queda con su fuente por defecto y no se rompe nada. Además Hub Config te avisa, justo debajo del campo, si encuentra esa familia en este sistema.

Cache descargado#

Ignitor se instala chico y baja las partes pesadas sólo cuando un build las necesita de verdad. Esta sección lista lo que descargó después de instalarse, con su tamaño al lado y un botón de Borrar:

• Demo de arranque — la copia descargada del proyecto demo. Tu copia del workspace es otro archivo y acá no se toca nunca.
• Toolchain Android + Python gestionado — JDK 17 y el Android SDK (~874 MB ya instalados), más el Python gestionado si lo pediste. Borrarlo los desinstala; el provisioner los vuelve a poner la próxima vez que los necesites.
• Shells de exportación — los binarios del player por plataforma. Se vuelven a bajar en la próxima exportación que los pida.
• Runtime de lip-sync (Rhubarb) — el modelo de voz para hornear lip-sync, que se baja de nuevo en el próximo horneado.

Borrar cualquiera de estos es seguro, y nunca es tu trabajo. Son caches: Ignitor los descarga otra vez cuando hagan falta. Lo que te cuesta es la misma descarga una segunda vez — por eso la fila de Android sí conviene pensarla en una conexión medida, y las otras no. Tus proyectos viven en otro lado y ningún botón de acá los alcanza.

Una fila que dice no descargado no tiene nada que borrar; una que dice descargando… está ocupada y espera su turno. 🗑 Borrar todo el cache descargado… hace la tanda entera detrás de una confirmación que nombra exactamente qué se va y cuánto libera.

Dónde se guardan los ajustes#

Todo lo de arriba persiste en hub-config.json en la raíz de la workstation. Un archivo típico se ve así:

{
  "pythonPath": "C:\\Users\\tu\\AppData\\Local\\Programs\\Python\\Python310\\python.exe",
  "nodePath": "",
  "gitPath": "",
  "rustPath": "",
  "tauriPath": "",
  "tauriCmd": "npx tauri build",
  "editorTheme": "darker",
  "editorFont": "consolas",
  "editorLang": "en",
  "faderFill": "line",
  "knobStyle": "classic",
  "autoArrangeTools": true
}

(Una clave vieja hubLayout, del layout classic ya jubilado del Hub, puede seguir presente en archivos de configuración antiguos — se lee por compatibilidad hacia atrás y se ignora; ya no es algo que puedas configurar.)

Normalmente nunca lo editas a mano — Hub Config lo escribe por ti — pero es útil saber que existe si estás moviendo una workstation entre máquinas.

Cache descargado#

Ignitor descarga algunos componentes después de instalarse, la primera vez que una función los necesita: el toolchain de Android (JDK 17 + SDK, ~874 MB), los shells de exportación por plataforma, el demo de arranque y el modelo de voz para lip-sync. Viven en una carpeta de cache por usuario — en Windows %LOCALAPPDATA%\Ignitor, en macOS ~/.local/share/Ignitor (oculta en Finder) — no adentro de tus proyectos.

La sección Cache descargado lista cada componente con su tamaño real en disco y te deja borrarlo, por componente o todo junto. Borrar es seguro: todo lo que hay ahí es un cache, Ignitor lo vuelve a descargar la próxima vez que lo necesite — pero eso es la misma descarga otra vez, así que limpiar el toolchain de Android justo antes de exportar un .apk significa volver a bajar ~700 MB. Tus proyectos nunca están en esta carpeta y nunca se tocan.

Dos cosas que conviene saber:

• El Python gestionado (si lo instalaste desde Rutas de herramientas) vive adentro de la entrada de toolchains — borrarla lo desinstala también. El provisioner puede reinstalar cualquiera de los dos cuando quieras.
• En macOS esta sección es la única forma de recuperar ese espacio: no hay desinstalador (la app se arrastra a la papelera), así que sin ella el cache quedaría atrás para siempre. En Windows el desinstalador también ofrece borrar el cache, pero esta sección es la única forma de hacerlo sin desinstalar.

Un componente que se está descargando en este momento aparece como ocupado y no se puede borrar hasta que termine la descarga.

Configuración del proyecto#

Debajo de las preferencias de la workstation, Hub Config también alberga la configuración del proyecto activo — ajustes que viajan con el juego (en su project.json), no con tu editor. Aquí viven las opciones de renderizado y el armado del party / selección de personaje.

Pixelar el juego#

Pixelado rehace la imagen terminada con bloques grandes y de baja resolución — el aspecto de un juego hecho para una pantalla mucho más chica.

No es lo mismo que la casilla pixel-art que está arriba, aunque los nombres se parezcan. Pixel-art decide cómo se dibuja cada sprite (nítido, sin suavizar). Pixelado agarra el cuadro ya terminado y lo rehace. Puedes usar cualquiera de las dos sola, o las dos juntas.

Seis ajustes definen el resultado:

• Alcance — hasta dónde llega el efecto. Sólo el juego se detiene en el borde del mundo: la sala, sus capas, los personajes, los walk-behinds, los FX de sala y las luces se rehacen en bloques, y todo lo que se dibuja encima queda nítido — barra de verbos, línea de frase, inventario, diálogos, GUIs modales, globos de diálogo, texto en pantalla, narrador, avisos de logros y el cursor. Todo, interfaz incluida es el tratamiento CRT completo: los paneles y sus letras reciben los mismos bloques que el arte.

Arranca desde Sólo el juego, que es el valor por defecto. Un bloque lo bastante grande como para leerse como pixel art es lo bastante grande como para destruir una línea de texto de interfaz: la barra de verbos deja de entenderse mucho antes de que la sala deje de verse bien. Ve a Todo cuando la interfaz ilegible sea el efecto que buscas.

Una toma de pantalla completa — una escena cinemática o el beat-'em-up — se pixela entera con cualquiera de los dos valores. El texto de una escena va entre sus sprites en el orden que tú autoraste, así que no hay costura por donde cortar sin darle vuelta a ese orden.

• Bloque px — de qué tamaño es cada cuadrado. Es la perilla principal.
• Niveles/canal — cuántos tonos de rojo, verde y azul sobreviven. Esto es lo que hace que se lea como pixel art y no como una foto borrosa con cuadraditos; si lo dejas alto tienes los bloques pero no la paleta.
• Mezcla — cuánto del efecto se mezcla sobre la imagen sin tocar, desde un toque apenas perceptible hasta el efecto completo.
• Dither — dispersa los saltos de color para que las zonas planas se rompan en un patrón en vez de quedar en bandas. Solo no hace nada: primero hay que bajar los niveles.
• Reducción — Área promedia los píxeles que junta, y da un resultado más suave; Nearest elige uno solo y deja los bordes más duros.

Salvo el alcance, todos describen cómo se ven los bloques; el alcance decide dónde caen.

Un bloque más grande es más barato, no más caro. El efecto trabaja sobre una copia más chica de la imagen, así que cuanto más lo subes, menos hay para hacer — si te preocupa el rendimiento, subir el bloque es la dirección segura.

Si dejas la casilla apagada no se ejecuta nada.

Lo que configuras acá es el aspecto base del juego. Una regla puede llevarlo más lejos por un momento — un flashback, un sueño, una pantalla que falla — con ADJUST:pixelate, y devolverlo con ADJUST:none. El alcance también viaja ahí: ADJUST:pixelate|scope=all se come la interfaz por lo que dure el beat, sin cambiar cómo se ve el juego normalmente.

La plantilla de barra, y su opción en blanco#

Plantilla de barra (legacy) es un fallback: nombra una de las barras de verbos que trae el motor, y sólo importa cuando el proyecto no tiene barra propia en su guis.json. Su primera opción está en blanco — ninguna: manda guis.json — y ese es un valor real, no un placeholder vacío. Un proyecto que el wizard creó con barra automática o con "sin barra — GUI propia" tiene exactamente eso: ninguna plantilla del motor, porque su propio guis.json es el que decide.

La opción en blanco existe para que el campo pueda mostrar ese estado en vez de hacerse pasar por otro. Antes mostraba un proyecto sin plantilla como si hubiera elegido la barra clásica de 9 verbos, y el primer guardado escribía esa suposición en el proyecto — convirtiendo "manda mi GUI propia" en una plantilla explícita del motor. Inofensivo mientras guis.json estaba ahí para ganar la discusión, y para nada inofensivo en un juego deliberadamente sin barra que alguna vez lo perdiera. Las opciones automática y sin barra del wizard no están acá a propósito: pertenecen al vocabulario del wizard para construir una barra, no a este campo, y el motor no las reconoce como nombres de plantilla.

Colocación del party#

Si tu juego deja que el jugador arme un party, el selector Colocación de miembros decide qué pasa con los miembros que no estás controlando en ese momento:

• Compañeros (te siguen) — los miembros no-activos siguen al personaje activo de sala en sala. Son efímeros: adondequiera que vayas, van contigo.
• Roster (agentes independientes) — los miembros quedan parqueados donde los dejaste, viviendo como personajes independientes en el mundo. Esto es lo que hace posible un "mientras tanto, en el otro cuarto…" off-screen tipo Maniac Mansion: un miembro que dejaste atrás está de verdad ahí, no siguiéndote.

El resto del panel de party se auto-gatea para que el formulario se lea honesto. Con la selección de party apagada, los controles de min/max, bloqueo-de-protagonista y pool de personajes quedan deshabilitados. Si bloqueas al protagonista, el pool de personajes debe tener al menos un miembro — si no, guardar se rechaza, porque un protagonista bloqueado tiene que vivir en algún lado.

Tildar a un personaje en el pool no le da automáticamente una forma de ser elegido — eso todavía necesita un botón partyRef en el GUI editor. Si tildas a alguien sin ese botón en ningún lado, Hub Config avisa ahí mismo: quedaría retenido para siempre al arrancar el juego, sin nada que pueda elegirlo jamás.

Eliminar un proyecto#

La sección de proyecto termina en una Zona de peligro con un botón rojo de Eliminar proyecto.

Eliminar un proyecto es permanente y no se puede deshacer — borra del disco la carpeta entera del proyecto (salas, escenas, sprites, audio, voz y todos sus datos) y lo quita del registro de proyectos. Tiene a propósito un doble candado:

1. Pulsas el botón rojo Eliminar proyecto.
2. Un diálogo de confirmación te obliga entonces a teclear el ID del proyecto a mano para confirmar. Pegar está deshabilitado adrede, para que borrar sea siempre una decisión consciente.

Trae varias salvaguardas:

• No puedes eliminar el único proyecto que queda — siempre debe existir al menos uno.
• Si eliminas el proyecto que está activo, Ignitor cambia primero a otro proyecto y luego borra el anterior.
• Las tarjetas de tu tablero de tareas quedan intactas.

Un proyecto borrado deja un respaldo, pero no hay un botón para restaurarlo. Antes de borrar la carpeta, Ignitor escribe un .zip re-importable en .tmp/deleted/<id>-<timestamp>.zip — el mismo conjunto de archivos que produciría un Exportar, así que traerlo de vuelta es un Importar normal, no un flujo especial de recuperación. Si ese respaldo no se puede escribir, el borrado se rechaza en vez de hacerse a medias. Igual no reemplaza hacer commit: .tmp/ no está pensado para durar a largo plazo, y todo lo que esté gitignoreado dentro del proyecto (assets generados de MusicGen, por ejemplo) nunca estuvo en un commit para empezar — ese historial de commits sigue siendo tu red de seguridad real.

El Basic Demo que trae Ignitor se actualiza con tu consentimiento#

El proyecto Basic Demo que trae Ignitor se siembra en tu workstation una sola vez, en el primer arranque — después es tuyo para abrir y editar libremente, e Ignitor nunca lo pisa a tus espaldas. Pero "nunca más tocarlo" también lo dejaría congelado en la versión que instalaste, para siempre, aunque nuevas versiones del motor traigan un demo más grande y mejor.

Ignitor distingue los dos casos por contenido, no por fecha (una copia simple preserva las fechas de modificación, así que una fecha no puede distinguir "nunca lo abre" de "lo abre cinco minutos después de instalar"): al sembrarlo se deja un manifiesto chico con el hash del árbol, y una discrepancia posterior contra ese hash es la señal de que algo en el demo realmente cambió.

• Nunca lo tocaste — un demo empaquetado más nuevo reemplaza al tuyo en silencio, con un toast confirmando la actualización. Nada que decidir.
• Lo editaste — Ignitor pregunta primero, y solo manda tu versión a la papelera del sistema (nunca un borrado permanente, salvo que el helper de papelera no esté disponible en tu sistema, y el toast lo dice claramente si eso pasa) si confirmas el reemplazo. Si declinas, Ignitor queda callado sobre esa versión empaquetada en particular — solo vuelve a preguntar cuando una versión posterior del motor cambie el demo de nuevo.

En una instalación de antes de que existiera este manifiesto, no hay nada contra qué hashear, así que Ignitor no puede saber en realidad si editaste el demo o simplemente nunca lo abriste — el texto de confirmación dice exactamente eso, en vez de afirmarle "tu copia tiene cambios tuyos" a alguien que puede no haberlo tocado jamás.

Este chequeo corre una vez por arranque, no en cada visita al Hub, porque implica hashear la carpeta entera del demo.

Si el demo no está en tu workstation#

Ignitor vuelve a poner el Basic Demo cuando falta y tú no lo borraste — no tienes que buscarlo ni reinstalar nada. Aparece solo en la lista de proyectos, registrado y listo para abrir, con un toast avisando que se agregó.

Borrarlo, en cambio, es una decisión que Ignitor recuerda: una vez que el demo vivió en una workstation, ni reabrir el editor ni actualizarlo ni reinstalarlo lo traen de vuelta a tus espaldas. Cuando sí lo quieras de vuelta, abre la lista de proyectos del Hub y elige Restaurar el proyecto demo…. Esa fila sólo aparece cuando tu copia de Ignitor trae un demo que tu workstation no tiene, y restaurarlo nunca pisa un demo que ya esté en disco: copia el empaquetado, lo registra y deja intacto todo lo demás.

El demo también se actualiza por su cuenta#

Los párrafos de arriba describen el demo que vino dentro de tu instalador, que sólo cambia cuando instalas un Ignitor más nuevo. El Basic Demo además tiene su propio número de versión y se publica aparte, así que puede mejorar mientras Ignitor se queda quieto — el editor puede pasar semanas en la misma versión y el demo avanzar varias en ese tiempo.

Cuando hay un demo más nuevo publicado, Ignitor lo ofrece como descarga, y el aviso nombra la versión y el tamaño antes de que aceptes — no se baja nada hasta que digas que sí. Todo lo demás funciona igual que arriba: una copia intacta se reemplaza limpiamente, una copia con cambios tuyos pregunta primero y va a la papelera, y rechazar deja a Ignitor callado hasta que aparezca una versión distinta. Si estás sin conexión, o no hay nada más nuevo publicado, no lo vas a ver nunca.

Ignitor no ofrece la descarga cuando el demo que trae tu instalador ya es igual de nuevo — esa copia ya está en tu disco, así que no hay nada que bajar.

Mover un proyecto entre workstations#

Todo proyecto se puede importar a una workstation o exportar de vuelta como .zip, así que puedes moverlo entre máquinas, pasárselo a un colaborador o guardar una copia offline.

Para traer un proyecto, abre la lista de proyectos en el Hub y elige Importar proyecto…. Apúntalo a una carpeta de proyecto o a un .zip. Lo que pasa después depende de dónde lo apuntaste:

• Se copia — el caso normal, para una carpeta o un archivo en cualquier otro lugar del disco. El original nunca se toca.
• Se registra donde está — cuando la carpeta que elegiste ya vive en la carpeta de proyectos de tu workstation, porque la clonaste ahí con git o la dejaste a mano. No se copia nada y no aparece un segundo ID: la carpeta se queda exactamente donde está, conservando todo lo que una copia habría dejado afuera — el .git sobre todo, así que sigue siendo el clon al que le puedes hacer pull.
• Se copia con un ID nuevo — solo cuando el ID choca con otro proyecto que ya está en tu workstation. Este es el único caso que se detiene a preguntar antes, porque esa copia sería un proyecto aparte, sin el .git del original.

Una importación grande muestra el progreso mientras copia; un proyecto de varios cientos de megas tarda minutos, y el silencio ahí se lee como que falló.

Un proyecto hecho con un Ignitor más nuevo no entra — y es a propósito. Mover un proyecto hacia atrás, a una workstation con una versión anterior, es la única dirección que no puede funcionar: esta versión leería lo que reconoce, ignoraría en silencio todo lo demás, y lo borraría entero la primera vez que guardaras. No hay error que te avise ni forma de deshacerlo. Así que Ignitor se niega, te dice qué formato pide el proyecto y cuál habla él, y deja los archivos intactos. Actualiza Ignitor y abre normalmente. El mismo control cubre simplemente cambiar a ese proyecto, no sólo importarlo.

Si registras una carpeta cuyo nombre y projectId no coinciden, manda el nombre de la carpeta y se corrige project.json para que cuadre — el proyecto ya está en esa ruta, y renombrar la carpeta rompería el remote de git desde el que lo clonaste. Conviene saberlo si la carpeta está bajo control de versiones: ese archivo te va a aparecer modificado.

Un proyecto que clonaste o copiaste tú mismo se queda invisible hasta que está registrado — el Hub arma su lista desde el registro, no escaneando el disco. Ahora esos aparecen en la lista de proyectos marcados como ⚠ sin registrar, y al elegir uno te ofrece Registrarlo en el sitio.

Para enviar de vuelta el proyecto activo, ven aquí a Hub Config y pulsa Descargar proyecto (.zip), en la misma sección de proyecto que Eliminar proyecto. Empaqueta el proyecto entero — salas, arte, audio, todo — en un único .zip que puedes archivar, compartir o importar en otra workstation más adelante. El archivo que produce es exactamente lo que espera Importar proyecto…, así que las dos funciones son un viaje de ida y vuelta completo.

Si el proyecto vino de algún lado — lo copiaste de una carpeta compartida o de un archivo — junto a Descargar aparece un segundo botón, ⬆ Re-exportar al origen, que escribe tu trabajo directo de vuelta a donde estaba, en vez de bajar una copia nueva que tendrías que colocar ahí tú mismo. Te pide confirmar la ruta de destino antes de escribir, y solo aparece cuando Ignitor todavía encuentra ese origen en disco, así que nunca hay un botón que fallaría si lo pulsaras — un origen movido o borrado hace que desaparezca y caes de vuelta a la Descarga normal. Mandar de vuelta a una carpeta la sobrescribe pero conserva las entradas que querrías conservar (.git, sobre todo) y deja antes un respaldo rotativo — .ignitor-bak — junto al original; mandar de vuelta a un .zip reemplaza el archivo atómicamente.

Un proyecto registrado en el sitio no tiene origen, así que nunca recibe ese botón — y eso es justamente el punto. Su origen sería él mismo, y re-exportar aparta el contenido del original al respaldo antes de escribir, o sea que destriparía el proyecto en el que estás trabajando.

Los zips exportados dejan fuera tu caché local de generación de voz y el archivo de sesión del editor — ninguno de los dos es parte del juego en sí, así que se regeneran solos cuando hacen falta.

Licencia#

Pega acá una llave de licencia Pro para desbloquear el export de escritorio, quitar el branding de Ignitor y habilitar el uso comercial. La versión gratuita tampoco caduca nunca — es un demo perpetuo (export web, branding de Ignitor), no una prueba con límite de tiempo, así que no corre ningún reloj en tu contra mientras decides.

Quitar el branding es lo que pasa por defecto una vez que eres Pro, pero no es forzoso: el checkbox Marca Ignitor de la pestaña Proyecto deja que un proyecto Pro siga mostrando "Made with Ignitor" al arrancar de todas formas — a algunos autores les gusta acreditar la herramienta. Solo puede agregar la marca; en un proyecto gratuito el mismo checkbox aparece marcado y deshabilitado, porque la marca todavía no es una decisión del autor.

La respuesta se hornea al compilar, no se lee mientras el juego corre — un juego publicado no tiene forma de preguntar con qué tier lo hicieron, y eso es justamente lo que mantiene honesta a la marca. Así que una corrida directa desde el editor siempre muestra el splash, diga lo que diga el checkbox. Exporta el juego para ver la respuesta real; para previsualizar de las dos formas sin exportar, agrégale ?branding=pro (ocultar) o ?branding=free (mostrar) a la URL de cualquier build que no sea de producción.

Decidir tu tier es offline: la llave se chequea contra una firma embebida en el editor, ahí mismo en tu máquina, y nunca se le pregunta a un servidor qué puedes usar. Dos momentos sí necesitan red, y los dos son breves. Activar registra esta computadora en nuestro servidor de licencias — una llave Pro es node-locked y cubre hasta 3 máquinas — y baja un permiso firmado que vale 14 días. Después el editor renueva ese permiso en segundo plano, más o menos una vez por semana mientras tengas red: nunca al arrancar, nunca bloqueando, y si el intento falla no cambia nada (el permiso que ya tienes sigue mandando hasta que venza de verdad). Trabaja sin conexión todo lo que quieras dentro de esos 14 días; si te pasas sin reconectar, Pro se pausa hasta que lo hagas, sin perder nada y sin volver a comprar. Activate guarda la llave y re-deriva tu tier al instante; Deactivate (aparece una vez que hay una llave activa) la borra y libera ese puesto para otra computadora — necesita conexión, porque el puesto vive en el servidor.

Una llave Pro es perpetua — una vez activa nunca deja de funcionar — pero solo baja builds nuevos del motor durante un año desde la compra. Pasado ese año el editor conserva cada feature que ya tenía (sin watermark, sin bloqueo de export, nada retrocede); lo único que cambia es el comportamiento del actualizador, que ofrece renovar en vez de instalar directamente. El panel de estado muestra las dos fechas por separado para que nunca se confundan: Licencia válida hasta (o Perpetua — esta es la que de verdad gatea features) y Actualizaciones nuevas hasta (o un aviso de que la llave no trae fecha de compra desde la cual calcularla).

Una llave de prueba con límite de tiempo (en vez de una paga y perpetua) es un caso completamente distinto: su expiresAt gatea el tier en sí, así que el panel te avisa a medida que se acerca (y una vez más pasado el vencimiento) — ese aviso es específico de las pruebas y nunca dispara con una llave perpetua.

¿Todavía sin llave? Obtén una licencia Pro enlaza a la tienda.

Cuándo lo abrirás de verdad#

• El primer día — normalmente solo para elegir el idioma y tema del editor, y recargar. Nada más hace falta para empezar a construir.
• Después, sobre la marcha — pon una ruta de herramienta solo cuando Ignitor te avise de que una función la necesita (limpieza de arte, MusicGen, lip-sync, o exportar tu juego). Llenas ese campo, guardas, y sigues.
• Cuando cambias de máquina o respaldas un proyecto — descarga un .zip aquí, y luego impórtalo donde vayas a retomar el proyecto.