Devlog

Primer playtest de verdad (y todo lo que destapó)

Volvimos después de un buen rato quietos y arrancamos por una revisión completa del proyecto. Lo primero que salió de ahí fue el motor, y en particular cómo maneja el input y el estado cuando las cosas no pasan en el orden ideal. Si cancelabas una caminata con un clic en el piso, el objeto al que ibas reaccionaba igual, como si hubieras llegado. Si el personaje se trababa contra algo, el input quedaba bloqueado para siempre. Un cambio de escena en medio de una cutscene o de un diálogo podía dejar la sala nueva sin responder a clics. Y había más: cutscenes anidadas que se pisaban, ítems que reaparecían al volver a una sala, dos cambios de escena seguidos peleándose los fundidos, y zonas que se disparaban en el punto de aparición al cargar una partida en vez de esperar a que el personaje estuviera donde lo guardaste.

Todo eso quedó arreglado y cubierto por un test nuevo, input_robustness, que con el código viejo fallaba en siete chequeos o más y ahora pasa 14 de 14. De paso blindamos el servidor del Asset Forge: rechaza pedidos que vengan de otras páginas, valida los nombres para que un ../.. no pueda borrar carpetas que no corresponden, y si lo abrís en la red local pide un token. Es local, sí. Igual.

Después jugamos el Capítulo 1 en el build web, hasta donde llega hoy (todavía no tiene final), como lo jugaría alguien de afuera. Lo más evidente: el héroe medía como un nene, unos 75 píxeles al lado de una puerta de 150 y de un Aldric de 110. Lo llevamos a talla adulta sala por sala. Varios hotspots no estaban sobre su dibujo (el barril del viñedo estaba sobre pasto vacío), el personaje podía pararse arriba del mostrador de la choza o adentro del barril, y algunas formas de relleno seguían ahí aunque ya teníamos sprites para reemplazarlas. En la web, además, no hay fuentes del sistema de respaldo, así que varios símbolos del menú salían como cajitas vacías. Y agarrar un ítem no daba ninguna señal visible.

También dejamos asentada una decisión de alcance: el Capítulo 1 sale solo, con un «próximamente» al final.

Quedó andando
• Motor más robusto: caminatas canceladas o trabadas, cargas, cutscenes y transiciones ya no dejan el juego colgado
• Test de regresión nuevo para todo eso (14/14)
• Servidor del Asset Forge blindado (pedidos de otras páginas, rutas, token en red local)
• Capítulo 1: héroe en talla adulta, hotspots sobre su arte y sprites reales en lugar de formas
• UI web sin cajitas vacías, aviso «+ ítem» al agarrar algo y tarjeta «CAPÍTULO UNO»

Un tramo tranquilo: dos ideas y un link

Semanas de poco movimiento en el repo. En julio anotamos dos ideas en el backlog. La primera, la Vista de Vinatero: el protagonista no toma, pero puede «leer» el vino y ver auras ocultas en la escena, reusando un shader de brillo mágico que ya teníamos sin uso jugable. La segunda, darle consecuencia de verdad a ayudar o asustar al rival, que hoy no cambia nada más adelante. Son ideas, no promesas: el backlog no compromete a nada.

En agosto, el devlog y la página de stack pasaron a linkear a javiercaruso.com, y dejamos escrito cómo se publica el sitio y cómo funciona el español/inglés (dos carpetas paralelas, todo se escribe dos veces).

Quedó andando
• Dos ideas nuevas en el backlog: la Vista de Vinatero y el rival con consecuencias
• Link a javiercaruso.com en el devlog y el stack (ES/EN)
• Documentado cómo se deploya el sitio y cómo funcionan los dos idiomas

Una review y el Story Master

Paramos a mirar el proyecto entero. El 1 de julio escribimos una review completa (motor, herramientas, contenido) que terminó en un backlog de cuatro sprints: el Story Master, decisiones de diseño, motor y quick wins. Un ajuste que salió de ahí: el backlog unificado no es un archivo más para mantener a mano, sino una vista que se genera a partir de lo que ya existe.

El Story Master es un compañero de diseño: lee el estado del juego y hasta dónde está construido, propone cómo seguir la historia con lo que costaría en assets, y deja registradas las decisiones. Ese mismo día salió una primera versión usable como comando, /story-master. El 5 de julio cerramos el Sprint A con las herramientas que le faltaban: una línea de comandos para editar los planes del Story Planner, el backlog generado (con su pestaña en la Story Bible), un chequeo que busca callejones sin salida de diseño entre capítulos, la lista de assets huérfanos del Forge y decisiones guardadas con fecha y motivo. En el medio quedó anotado un pendiente sobre un plan de comunidad.

Quedó andando
• Review completa del proyecto con backlog en cuatro sprints
• /story-master v0, y /start como punto de entrada
• Planes del Story Planner editables por línea de comandos, con validación
• Backlog generado + pestaña en la Story Bible
• Detector de callejones sin salida entre capítulos

El arte nuevo entra al Capítulo 1

Día de arte. Generamos los fondos de la versión de la historia que venimos trabajando (la «B1», un arco de cinco capítulos) y curamos diez íconos de ítems: siete del Capítulo 1 (uvas, corcho tallado, vino de mesa, harina mohosa, un susurro, levadura espectral y un barril de mosto) y tres del 3. Nano Banana quedó como el camino oficial para los fondos.

Y lo enchufamos al juego. El flashback ahora tiene su fondo real en lugar de formas decorativas, y el joven Aldric dejó de ser catorce polígonos para ser un sprite. Lo cambiamos dos veces en el día: el primero pisaba el estante, el segundo es más angosto y entra. La torre de la panadería nigromante tiene su lámina, con la luz verde del caldero ahora iluminando el arte de verdad, y cuatro ítems pasaron a mostrar su ícono. Al regenerar la Story Bible aparecieron dos ítems que se consiguen y nunca se usan. Mejor que lo diga la herramienta y no un jugador.

Para los fondos cuyos capítulos todavía no existen armamos seis escenas de vista previa: cargan la lámina y te dejan caminarla, así se puede recorrer el arte dentro del motor. La torre sumó además su checkpoint en el menú de debug.

Quedó andando
• Fondos de la historia B1 + diez íconos de ítems curados
• Flashback y torre con sus láminas reales en el juego
• Sprite del joven Aldric en el flashback
• Seis escenas para caminar los fondos de capítulos sin construir

Cerrando la lista de pendientes de las herramientas

Agarramos la lista de pendientes del día anterior y la cerramos. El Story Planner y la Story Bible pasaron a vivir en un mismo servidor: el planner sirve la Bible en /bible, siempre actualizada, y el launcher la abre ahí cuando está corriendo.

En el planner, las flags (las banderitas que dicen qué ya pasó en la historia) son ahora nodos propios, con forma de rombo. Sumamos una vista lado a lado que compara el capítulo escrito con lo que propone el plan, sin tocar nada, y un asistente que, para cada nodo suelto, sugiere el ítem o personaje real del juego que mejor le coincide. En el Asset Forge, al aprobar una imagen que corresponde a un pedido pendiente, ahora te ofrece marcarlo como hecho. Te lo ofrece: no lo hace solo.

También dejamos anotado que los videos y las redes viven en un repo hermano, aparte de este, y sumamos al backlog la idea de logros de Steam.

Quedó andando
• Story Bible servida en vivo desde el Story Planner (/bible)
• Flags como nodos en el planner
• Comparación capítulo vs. plan, y asistente para ligar nodos a entidades reales
• Forge: aprobar un asset ofrece cerrar el pedido correspondiente

Caminar esquivando cosas (y PixelLab en el Forge)

Lo grande fue el piso. Hasta ahora el personaje caminaba en línea recta dentro de un rectángulo; desde acá una sala puede declarar un área caminable con forma (una L, una T, con columnas o muebles en el medio) y el personaje busca solo el camino, bordeando obstáculos. Si hacés clic fuera del piso, va al punto caminable más cercano. Las salas que no declaran nada siguen caminando como antes. Lo probamos con un barril en una sala de pruebas nueva y armamos una vista que dibuja el área caminable encima de la escena para ajustarla.

En la interfaz, pasar el mouse sobre algo muestra su nombre. Se puede apagar desde la pausa, y en modo difícil viene apagado sí o sí.

El Asset Forge sumó PixelLab, un servicio pago en la nube: primero un panel que muestra el saldo, después la generación en sí, con un aviso de que gasta crédito. La clave queda en cada máquina, nunca en el repo. También un segundo botón para aprobar una imagen «para otro uso», que significa «la quiero, pero preguntame antes de usarla». Ese día aprobamos, de PixelLab, un retrato del joven Aldric para los diálogos: sin el parche y con la barba oscura. Del lado de la web: verificación en Bing, link al autor en los pies de página y, el 28, Google Analytics con un aviso chico de cookies.

Quedó andando
• Áreas caminables con forma y búsqueda de camino alrededor de obstáculos
• Nombre del objeto al pasar el mouse (desactivable, apagado en difícil)
• PixelLab en el Asset Forge: saldo y generación
• Retrato del joven Aldric para diálogos
• Analytics + aviso de cookies en el sitio

Efectos Visuales (FX) y Pipeline de Playtest

Dedicamos el día a pulir la capa visual y a aceitar nuestra experiencia de desarrollo. Implementamos y validamos un sistema de FX en el Test Chamber 4: ahora tenemos shaders dedicados (como magic_glow, wine_ripple y heat_haze) trabajando en sincronía perfecta con luces dinámicas (FlickeringLight).

Por otro lado, reparamos el pipeline de compilación para Windows. Ajustamos la resolución de rutas de Godot y ahora nuestro Launcher compila y ejecuta automáticamente la última build exportada (playtest) en lugar del código fuente. Quedó a un click de probar la versión final.

Quedó andando
• Sistema de FX visuales interactivos (luces parpadeantes y shaders mágicos)
• Pipeline de exportación de Playtest reparado y automatizado
• El Launcher en Windows ya apunta directo a la build compilada

Motor Dual-Core de IA y Prototipado

La bomba del día fue montar nuestro nuevo motor Dual-Core de Inteligencia Artificial. Armamos una estructura en .agents/ para que Google Antigravity (Gemini) y Claude Opus convivan en paz en el mismo repositorio, compartiendo el contexto de CLAUDE.md.

Dividimos las "wallets": delegamos el contexto gigante y las tareas diarias a Gemini 3.1 Pro y Sonnet 4.6, reservando el valioso cupo de Opus 4.8 solo para cirugía fina de arquitectura.

Además, sumamos a Gemini como nuestro Concept Artist oficial con la habilidad prototype-artist, generando Background Plates y Sprites nativamente en el editor sin gastar tokens de Claude. Eficiencia brutal.

Quedó andando
• Motor "Dual-Core": Gemini y Claude Opus corriendo en paralelo sin pisarse
• Prototipado rápido nativo con la habilidad prototype-artist
• División estratégica de "wallets" para optimizar cuotas

El Story Planner y el Pipeline de Autoría

Día de madurar fuerte las herramientas internas. La v0.26.5 del Story Planner fue una revolución absoluta: ahora soporta múltiples versiones de la historia enteras para probar ideas en paralelo. Le sumamos diffs visuales (anillos de colores para nodos nuevos o cambiados), la opción de vincular nodos "borrador" a ítems reales del motor para no duplicar datos, y arrastrar puertos para conectar nodos súper rápido.

Con todo ese poder, cerramos el pipeline de autoría definitivo: Story Planner → chapter-smith → asset-generator → Story Bible. Todo fluye en una sola dirección y agregamos una pestaña de "Flujo" a la Story Bible para que el proceso nunca más dependa de la memoria humana.

Quedó andando
• Versiones de la historia en paralelo en el Story Planner + Diffs visuales
• Enlace de nodos borrador a entidades reales del motor
• UI de drag-to-connect y fan-out de relaciones múltiples
• Pipeline de autoría formalizado en la Story Bible

Pulido, deploy firmado y el Asset Forge

Día de herramientas. Del lado de macOS armamos el deploy de un .app firmado con Developer ID y notarizado (con todas sus mañas anotadas para no volver a sufrirlas). Pulimos UI: íconos de inventario un 25% más grandes y la lupa de examinar arreglada para los ítems que usan sprite.

Entró toda una capa de edición de imágenes local: una guía, una herramienta para editar "por instrucción" (FLUX Kontext) y otra para borrar cosas del fondo y rellenarlas (IOPaint/LaMa). Con eso limpiamos a mano la lámina de la choza vacía.

Y lo grande del día: el Asset Forge, una herramienta self-serve para generar assets sin depender de Claude — interfaz web de tres columnas, cola asíncrona, parámetros por motor, curación fina y varios engines (SD Forge retro por defecto, Flux, Kontext). Salió la v1 a la mañana y la fuimos puliendo hasta la v0.26.10 en el mismo día. Continuará…

Quedó andando
• Deploy de macOS firmado + notarizado
• Íconos de inventario más grandes + fix de la lupa
• Edición de imágenes local (editar por instrucción + borrar/rellenar)
• El Asset Forge: generador de assets self-serve con UI web y cola

Que se juegue en cualquier lado (y que suene)

Día de abrir el juego al mundo. Sumamos soporte táctil / iPad: modo touch, examinar con lupa tocando cada ícono, botón para soltar ítems y un cursor tipo mira configurable. Y la localización (i18n): base en español más inglés, con el Capítulo 1 ya traducido entero.

También entró el audio, todo generado localmente por pipeline: efectos vía Stable Audio Open y música de fondo vía ACE-Step, cada uno con su autoload y sus buses. Quedó como regla dura del proyecto: nunca generar arte ni audio "a mano", siempre por el pipeline, que ya tiene todos los tropiezos resueltos.

La estrella del día fue la Story Bible: una herramienta que genera un HTML navegable con el guión, los personajes, los ítems, los prompts de arte, las banderas rojas y el mapa de escenas. La iteramos un montón (de v1 a v2.6). Y, en el plano más narrativo, fijamos la política de contenido: el protagonista hace y vende vino, pero no toma — en el tutorial le pasa la copa a Aldric. Cerramos con deploy a dispositivo iOS.

Quedó andando
• Soporte táctil / iPad (modo touch, lupa, soltar ítems, cursor mira)
• Localización ES + EN, con el Capítulo 1 traducido
• Audio local: SFX (Stable Audio) y música (ACE-Step) con sus buses
• La Story Bible (guión + personajes + arte + mapa navegable)
• Política de contenido + deploy a iOS

De "juego" a "motor"

El tema del día fue dejar de hardcodear contenido y empezar a tratar esto como un motor donde el contenido es data. Los objetos pasaron a ser declarativos, las líneas de diálogo se condicionan por flags, y arrancamos a escribir los capítulos como markdown que después se reconcilia con la escena de Godot. Para no romper nada en el camino, montamos un robot de QA headless y CI que corre los escenarios en cada push.

Le metimos un montón de calidad de vida: menú de pausa con slots de guardado, opciones (pantalla completa, volumen, velocidad de texto), cursor que cambia al pasar por encima, "usar ítem sobre objetivo", combinar, autosave y hasta una consola de desarrollo. Y un sprint de features de aventura "profesional": diálogo con efecto máquina de escribir, comentarios flotantes, modo cine con letterbox, escala por perspectiva, examinar ítems en primer plano, screen shake, árboles de diálogo ramificados, tinte de ambiente por sala y cámara con paneo.

Del lado del contenido entraron el puzzle del rival, la escena del viñedo y el de las uvas, más el fondo real de la encrucijada y FX ambientales (un shader de viento y partículas de luciérnagas). Y nació el sitio web esta página vive acá: la landing, la estructura del /demo y la guía de deploy.

Quedó andando
• Objetos declarativos + capítulos como markdown reconciliable
• QA headless + CI en cada push
• Pausa, slots de guardado, opciones, combinar, autosave, consola dev
• Diálogo typewriter, modo cine, árboles de diálogo, cámara y tintes
• El sitio web y la estructura de la demo

Nace el repo (y elegimos motor)

Arrancó todo. La idea sobre la mesa: una aventura gráfica retro point-and-click, en la onda Monkey Island, pero sobre vino y magia. Lo primero fue la decisión grande: el motor. Probamos un rato y nos quedamos con Godot 4 (build estándar, GDScript — nada de C#, porque el export a web no lo banca y la web es el escaparate principal). De paso fijamos la resolución base en 480×270, el punto justo de pixel art que escala redondo a 1080p y 4K.

Con eso decidido, en el mismo día armamos el esqueleto del "motor": caminar hacia donde hacés clic, objetos interactuables, salas y caja de diálogo. Y encima escribimos el gag de intro del Capítulo 1, con sus secuencias de diálogo, la tarjeta de título ("CHAPTER ONE"), transiciones con fundido y un flashback de la primera memoria.

También entró el sistema de guardado y carga (con quick save/load para debug) y salas gobernadas por flags para que el estado del juego persista de verdad. Sumamos el menú de intro, el inventario con íconos y la encrucijada. Y arrancó el arte: guía de estilo, pipeline de importación de imágenes y los primeros fondos pixel-art reales, con el héroe ya caminando animado en cuatro direcciones y la escena del Troll Sommelier con su primer puzzle de vino falso.

Quedó andando
• Motor base point-and-click: walk-to-click, interactuables, salas, diálogos
• Intro del Capítulo 1: gag, flashback, tarjeta de título y transiciones
• Guardado/carga + estado por flags
• Pipeline de arte + primeros fondos, héroe animado y el Troll con su puzzle