6 meses, 3 proyectos de juegos, 0 publicados

Quería escribir este post hace unas semanas. Pero creo que estaba esperando que, cuando por fin me sentara a escribirlo, al menos uno de los tres juegos que estaba construyendo estuviera terminado.

Ninguno lo está.

Así que aquí estamos: 684 commits en tres proyectos durante seis meses, y nada que puedas descargar, jugar o enviar a un amigo. Si alguna vez has aprendido algo nuevo fuera de un trabajo de tiempo completo — algo realmente difícil, algo en lo que no eras ya bueno — probablemente sabes exactamente cómo se siente.

Lo escribo de todos modos porque creo que la historia de por qué no salió nada es más útil que un anuncio pulido de algo terminado.

El contexto inicial

Durante 18 años trabajé en publicidad. Es buen trabajo, es desafiante, y sé cómo hacerlo. He lanzado campañas, construido equipos, escrito libros, hablado en escenarios. En ese mundo sé cómo se ve algo "terminado".

Luego, a finales de 2025, decidí que quería aprender desarrollo de videojuegos. No game marketing. No game strategy. Construir juegos de verdad: el código, el arte, los sistemas, la sensación de un personaje moviéndose en pantalla.

No tenía experiencia con game engines. Nunca había hecho rigging de un modelo 3D. No sabía qué era una state machine en el contexto de animación. Llevo algunos años programando, sobre todo web apps y productos de AI, pero los juegos son una disciplina completamente distinta. (Por favor corrígeme si me equivoco en algo de esto; sigo aprendiendo.)

Lo primero que aprendí: publicar un juego es difícil. Lo segundo: no puedes razonar tu camino hacia un buen game loop desde un documento.

Tienes que verlo moverse. Tienes que jugarlo, o al menos llevarlo al runtime de Godot y ver si el personaje, la cámara, los controles y el feedback realmente crean una sensación. Y luego tienes que estar dispuesto a construir, borrar, recortar y reconstruir hasta que aparezca algo interesante.

Esto fue lo que pasó.

---

Proyecto 1: The AI Pet Sanctuary (288 commits)

Diciembre 2025 – Febrero 2026

El primer proyecto empezó con una idea simple: ¿y si pudieras tener una mascota que viviera en tu computadora y hablara contigo usando AI? No un chatbot con avatar de mascota, sino una mascota real con comportamientos, hábitat y personalidad.

Construí una aplicación full-stack. React en el frontend, FastAPI en el backend, Supabase para la base de datos. Usé Gemini para las conversaciones y Cloudflare Stream para video.

La parte ambiciosa era el sistema de animación. Quería 18 tipos de mascotas en seis categorías amplias: perros, gatos, aves, animales pequeños, peces y reptiles. Cada una tenía que moverse, parpadear y sentirse viva.

Empecé con animaciones en Rive. No funcionaban para este caso. Así que las reemplacé con animaciones en CSS y JavaScript. Luego construí una pipeline usando Google Veo 3.1 para generar contenido de animación: generación de video con AI para los movimientos de las mascotas. Funcionaba, pero era frágil. La API fallaba, la iluminación era inconsistente, la escala cambiaba entre generaciones. Pasé más tiempo peleando con la pipeline de generación que diseñando la experiencia real de la mascota.

También construí un sistema de hábitats con entornos inmersivos a pantalla completa: una habitación llamada "The Study" donde vivía la mascota. Care screens. Memory screens. Integración con conversación. Un rediseño completo "Quiet Luxury" a mitad de camino porque la primera versión parecía un prototype. (Porque lo era.)

Luego pivoté.

288 commits después, decidí que la web app era la plataforma equivocada y empecé a planear una versión nativa para iOS. Todavía no sé si fue la decisión correcta o aburrimiento disfrazado de estrategia. Parte de mí cree que una mascota en el móvil es más íntima que una mascota en el navegador. Parte de mí cree que simplemente me cansé de React.

Pero si soy honesto, la verdadera razón por la que nunca lo publiqué fue más simple: era aburrido. Construí todo eso — los hábitats, el sistema de animación, la integración conversacional — y cuando llegó el momento de sentarme e interactuar con la mascota, perdí el interés en dos minutos. No había nada lo suficientemente atractivo para sostener mi atención. Juego desde la secundaria, así que confío en esa primera reacción, aunque todavía no siempre sepa cómo arreglarla. Todavía juego Mobile Legends con mi familia y normalmente subo hasta Mystic. Ese no es un juego que juegas para comodidad pasiva; exige habilidad y atención. Este pet sanctuary no exigía ninguna de las dos.

Seguía diciéndome que el problema era la plataforma. Una web app no podía ofrecer la experiencia inmersiva que quería. Quizá iOS sería diferente. Pero en el fondo sabía que el problema no era React: era el diseño. Ningún cambio de plataforma iba a hacer que un game loop poco interesante se sintiera emocionante.

Qué salió mal

Mirando el repo, no creo que la lección correcta sea "288 commits sin release es malo". Si el core loop no es engaging, publicarlo antes solo significa publicar algo aburrido antes.

El verdadero problema fue que seguí cambiando el contenedor antes de probar el loop. El proyecto pasó de mecánicas de merge/order, a pure companion, a hábitats inmersivos, a iOS. Cada pivot tenía una razón. Pero la pregunta que no respondí con suficiente claridad era más simple: ¿querría abrir esto todos los días?

Podría haberlo validado con una mascota, una habitación, una conversación y una interacción de care/play. En lugar de eso construí 18 tipos de mascotas en 6 categorías animales con un sistema completo de hábitats antes de tener una respuesta en runtime a la pregunta más importante: ¿esta mascota es interesante como para volver?

La animación generada con AI es potente pero frágil. Cuando funciona, es increíble. Cuando no, estás debugging prompts y fallos de API en lugar de tu producto. Necesitas una pipeline de fallback, y yo no la construí suficientemente pronto.

Lo que aprendí

El primer trabajo no es recortar scope. El primer trabajo es encontrar la parte interesante. A veces eso significa construir más. A veces significa borrar lo que acabas de construir. El error no fue explorar. El error fue explorar demasiado tiempo sin una prueba jugable que me dijera si la experiencia central tenía vida.

---

Proyecto 2: El zorro que terminó siendo un escalón (35 commits)

17 de abril – 12 de mayo de 2026

Después de que el pet sanctuary pivotara a iOS, empecé un nuevo proyecto en Godot 4.6. Esta vez quería construir un juego desde cero en un game engine real, no una web app fingiendo ser un juego.

El concepto inicial: un Spirit Fox Kit Sanctuary Sim. Un zorrito que vive en una habitación acogedora, y tú lo cuidas. Simple, cálido, contenido.

Configuré el proyecto de Godot. Intenté diseñar un zorro con hidden tense silhouettes, animaciones twitch más rápidas y micro-signals de quietud.

Pero esa frase hace que el prototype suene mucho más legible de lo que era. En pantalla, el zorro no se leía como zorro. Era una pequeña masa redonda. No podía ver una forma usable, mucho menos juzgar el resto de la habitación a su alrededor.

Construí un draft room loop con cobertura de tests GUT. Audio placeholder. Hover cues para interactables. Layout de la room scene. Un cold-start playtest harness para poder jugarlo de verdad.

Y entonces lo jugué.

La verdad honesta es más visual y menos filosófica: el zorro falló en la primera lectura. El prototype de la habitación tenía un camino verificado mecánicamente, y el repo incluso registra un abbreviated solo gate pass para el build con placeholder art. La quietud, el emergence beat, la distinción de touch y el room problem eran aceptables para esa etapa.

Pero aceptable para un pequeño authored beat no es lo mismo que visualmente fuerte para sostener un juego completo. Este proyecto dependía de que el zorro cargara la experiencia. Si no podía ver su forma, postura y appeal, entonces el sanctuary loop todavía no tenía oportunidad.

Así que el 20 de abril — apenas tres días después de empezar — escribí una pivot spec completa. El fox sanctuary sim se convirtió en algo totalmente distinto: un landscape action-adventure con un safehouse cálido y territorio hostil para explorar. Pausé los planes fox-first y empecé a diseñar una nueva dirección.

35 commits. Un beat validado. Un pivot. Nada publicado.

Qué salió mal

El verdadero problema es que traté las señales de animación como si pudieran compensar una forma base ilegible. No podían. Un twitch no importa si el cuerpo debajo no tiene silueta.

El pivot no fue prueba de que el primer trabajo estuviera desperdiciado. Lo convirtió en una base. Lo que todavía no tenía era evidencia de que la dirección más grande de Hearthkeeper funcionaría, o de que podría hacer que su personaje central fuera lo bastante legible como para importar.

Lo que aprendí

El playtesting temprano revela qué está probando realmente un prototype. El room prototype probó tono, ritmo y un relationship beat. No probó un juego completo, y expuso de inmediato el problema de legibilidad visual. Esa información es útil, pero apunta a otro siguiente paso: resolver la lectura del personaje y construir el loop mínimo safehouse -> run -> return antes de volver a pulir el zorro.

Game 1 me enseñó que un loop técnicamente completo todavía puede ser aburrido. Game 2 me enseñó que un concepto de personaje documentado y testeado puede fallar visualmente en segundos. Esos dos fallos son parte de por qué Game 3 ha avanzado de forma más real: estoy prestando mucha más atención a readability, motion, weapon feel y a si el playable slice funciona en pantalla.

Pivotar desde evidencia no es lo mismo que ir a la deriva. El zorro no se leía en runtime, así que cambiar de dirección no era automáticamente falta de disciplina. Lo que necesito mejorar es el feedback loop: llevar la pregunta visual o jugable más riesgosa a la pantalla más rápido, y decidir con evidencia en lugar de quedarme en concept mode.

---

Proyecto 3: El que empezó a tener una pipeline que funciona (361 commits)

21 de abril – 13 de mayo de 2026

Este es el proyecto en el que sigo trabajando. También es el proyecto donde lo aprendido en los dos primeros finalmente empezó a acumularse.

Es un juego de mech tactics. Controlas un escuadrón de mechs en combate, y después de cada batalla un LLM analiza lo que pasó y te da un debrief. Piensa en análisis post-partido, pero escrito por una AI que tiene acceso a todo el game state.

El repo tiene tres tracks, pero ya no son iguales:

Track A — The LLM Debrief System: Fue el track temprano de validación AI. Me ayudó a probar structured debriefs, pero ya no es el camino principal del producto.

Track B — The 2D Phone Prototype: Aquí fue donde por fin encontré una pipeline workable para una experiencia 2D relativamente inmersiva en móvil. El runtime real de Godot tiene lane-match combat loop, touch joystick, shop/modules, hero XP, ability cooldowns, motivos VFX legibles en teléfono, enemy punish zones, un neutral relay objective, HUD feedback y flujo de iOS export/testing. La art pipeline también empezó a funcionar: Nano Banana 2 (Gemini 3.1 Flash Image) generó imágenes iniciales usables de héroes y personajes, y luego un workflow de pixel cleanup basado en MCP junto con Aseprite convirtió candidatos curados en sprites limpios, animation frames y sheets listos para Godot. No es un juego terminado, y la aceptación en teléfono sigue pendiente, pero está mucho más cerca de "esto se siente como un juego" que los dos primeros proyectos.

Track C — The Campaign and 3D Path: Esta es la dirección actual del producto. Mantiene las lecciones útiles de Track B, añade un campaign memory loop y mueve el production combat hacia 3D/2.5D. Es un problema mucho más difícil que la pipeline 2D. En 2D puedo controlar la legibilidad con sprite sheets, ajuste de HUD, VFX procedural y capturas de teléfono. En 3D, cada decisión toca modeling, rigging, animation, camera, lighting, GLB export, weapon sockets, hit anchors, action timing y runtime performance.

También integré Blender para custom rigging work, incorporé datos de mocap de Rokoko para locomotion y construí el personaje hero mech con full rig, animation tree y weapon socket integration.

361 commits en tres semanas. Una pipeline 2D real. Un experimento 3D mucho más difícil. Todavía en territorio de prototype.

Qué salió mal

Esto es lo que tengo que admitir: la pipeline 2D empieza a funcionar, pero la pipeline 3D puede tragarse todo el proyecto si la dejo.

Para Track B, el trabajo de pipeline no fue progreso falso. El workflow Nano Banana 2 -> Aseprite, touch controls, HUD, ability motifs legibles, module feedback, phone captures y export loop hicieron que el producto fuera más jugable. Ese trabajo me enseñó qué necesita ver y sentir un jugador momento a momento.

El riesgo ahora es distinto. En Track C, 3D requiere mucha pipeline antes de sentirse como algo: model import, rig quality, animation names, weapon attachment, muzzle position, hit center, camera angle, lighting, movement, jump timing, attack timing, VFX y runtime inspection. Esos no son detalles opcionales. Si el personaje no se lee, toda la escena falla en segundos.

Pero el playable encounter todavía tiene que liderar. Si no, puedo pasar semanas mejorando el weapon fit del hero mech, jump compression, left-hand IK y mocap cleanup sin responder la pregunta simple del jugador: ¿es divertido de controlar?

Lo que aprendí

El trabajo de pipeline solo sirve cuando sigue sirviendo al playable slice. Track B me enseñó que la pipeline correcta puede crear una experiencia 2D más inmersiva. Track C me está enseñando que 3D aumenta el coste de cada mejora. Tengo que mantener el acceptance gate concreto: ¿puede el jugador leer al hero mech, moverlo, apuntar, disparar, entender el hit y querer hacerlo otra vez?

Los tracks necesitan gates. Track A hizo su trabajo. Track B produjo lecciones reutilizables sobre 2D game feel y presentación. Track C es la apuesta actual. El problema no es que explorara varios caminos. El problema es reabrirlos sin una pregunta de runtime clara y una regla de decisión clara.

El desarrollo 3D es un skill gap enorme. Rigging, animation, mocap data, asset budgets, weapon sockets, camera framing y readable motion son disciplinas en las que tengo cero experiencia profesional. Las estoy aprendiendo mientras también aprendo Godot, game design y campaign architecture. La curva de aprendizaje no es empinada; es vertical. Creo que eso es lo que más me sorprendió. En web development puedo construir algo funcional en un día. En 3D game dev pasé una noche entera intentando que el brazo de un personaje se doblara bien. (Esta es una frase que no habría entendido hace seis meses.)

---

Qué tienen en común estos tres proyectos

Si soy honesto conmigo mismo — y este post solo funciona si lo soy — el patrón no es "scope creep". Eso es demasiado fácil, y en este caso creo que es incorrecto.

No creo que los juegos funcionen como business decks; al menos eso me enseñaron estos tres proyectos. No sabes si una idea funciona porque la premisa suena bien. Lo sabes cuando puedes jugarla, o al menos verla corriendo en el engine y sentir si el personaje, la cámara, la interacción y el feedback están haciendo algo.

1. El runtime dice la verdad

El pet sanctuary sonaba bien hasta que interactué con la mascota y me aburrí. El zorro sonaba bien hasta que lo vi en Godot y no pude leer la forma. Track B empezó a funcionar porque el loop llegó a un runtime parecido a teléfono: touch controls, HUD, VFX, shop, XP, motivos legibles y capture feedback.

Ese es el patrón real. La verdad útil solo llegó cuando la idea se volvió visible y jugable.

2. La exploración es necesaria, pero necesita evidencia

No creo que la lección correcta sea "deja de añadir cosas". Game development necesita exploración. Construyes, pruebas, borras, recortas, reconstruyes y vuelves a probar porque estás buscando la parte interesante.

La parte que necesita disciplina no es la cantidad de trabajo. Es el evidence loop. Cada pieza de trabajo debería responder una pregunta: ¿esto hace el juego más legible, más engaging, más controlable, más digno de repetirse?

3. Las pipelines son buenas cuando hacen el juego más jugable

El workflow Nano Banana 2 -> MCP cleanup -> Aseprite no fue una distracción. Me ayudó a meter mejores personajes 2D y animación en el juego. El trabajo de HUD y VFX en Track B tampoco fue progreso falso. Hizo el runtime más claro.

El riesgo aparece cuando la pipeline deja de responder una pregunta de cara al jugador. En Track C, el tooling 3D es necesario, pero tiene que volver siempre a una cosa: ¿puede el jugador leer al hero mech, moverlo, disparar el arma, entender el hit y querer hacerlo otra vez?

4. La brecha no es coding skill. Es playable judgment.

Puedo construir una aplicación full-stack con Supabase, FastAPI y React. Puedo riggear un modelo 3D, escribir tests GUT y construir custom debugging tools. Lo que todavía estoy aprendiendo es juzgar si algo es realmente interesante como juego. Track B me acercó en 2D. Track C me está mostrando cuánto más difícil se vuelve cuando motion, camera, lighting, weapons y animation tienen que funcionar juntos.

Creo que esto es lo más importante que he aprendido. El código es la parte en la que soy bueno. Lo difícil es decidir qué es realmente el juego, hacerlo interesante y luego tener la disciplina de volver una y otra vez a la evidencia del runtime hasta que valga la pena publicarlo.

---

Lo que aprendí en conjunto

Si intento destilar seis meses en algo útil — para mí o para cualquiera que esté en la misma posición — esto es lo que creo saber ahora que no sabía en diciembre:

1. La primera versión debería responder la pregunta más riesgosa en runtime. Mi pet sanctuary necesitaba una interacción con la mascota que me hiciera querer volver. Mi juego del zorro necesitaba una silueta legible en una habitación vacía antes de preocuparme por micro-signals. Mi juego de mechs se acercó más gracias a Track B porque podía ver y sentir el loop en pantalla.

2. Playtesting no es opcional, y runtime review también cuenta. En el momento en que vi al zorro como una masa sin forma, supe que el proyecto todavía no funcionaba. Esos fueron los 30 minutos más valiosos de todo el proyecto. Debería haber llegado antes a esa verdad visual.

3. Aprender es un resultado válido, aunque no sea el que planeaste. Me propuse construir juegos. No publiqué juegos. Pero aprendí Godot, LLM prompt engineering, Nano Banana 2 para character ideation, Aseprite animation cleanup, 2D phone readability, HUD and VFX feedback, animation pipelines, 3D rigging, mocap data, game feel, camera systems, visual readability y la diferencia entre construir herramientas y construir productos. Eso no es nada. También es por eso que Game 3 es mejor que Game 1 y Game 2, aunque todavía no haya salido.

4. Todavía necesito definir una finish line honesta. Parte de mí quiere llevar este proyecto hasta el final para poder decir que publiqué un juego. Parte de mí cree que el aprendizaje fue el producto y debería aceptarlo. Ambas son respuestas honestas. Creo que la verdad está en medio: publicar un slice enfocado que respete lo aprendido, en lugar de empezar otra vez desde cero.

Qué sigue

Sigo trabajando en el proyecto de mech tactics. El concepto de LLM debrief es interesante, y creo que hay algo genuinamente novedoso en la idea de análisis post-partido con AI para un tactics game.

Pero estoy intentando cambiar mi enfoque: runtime proof primero, polish después, publicar solo cuando el playable slice tenga una razón para existir. Los dos primeros proyectos no fueron desperdicio. Cambiaron lo que miro en Game 3: si el personaje se lee, si el movimiento se siente bien, si el arma se siente correcta, y si alguien puede entender el encounter sin que yo explique la arquitectura.

Si empezara un juego nuevo hoy, no empezaría con un gran architecture plan. Empezaría con la prueba de runtime más rápida que pueda responder la pregunta que de verdad me importa. Para Game 3 ahora, la misma disciplina tiene que pasar dentro del proyecto: un personaje, un arma, un encounter, un acceptance test claro.

Todavía no sé si empujaré uno de estos proyectos hasta completarlo o aceptaré que el aprendizaje fue el producto. Puede que me equivoque con el timeline, pero creo que el patrón importa más que cualquier proyecto individual.

Una pregunta para ti

Quiero preguntarlo de verdad, no retóricamente: ¿has estado aquí? (Sospecho que más builders han pasado por esto de lo que solemos admitir.)

¿Has pasado meses construyendo algo que nunca salió? ¿Lo terminaste al final, o te fuiste? Y si te fuiste, ¿fue la decisión correcta, o todavía piensas en ello?

He lanzado cosas en mi carrera. Campañas, plataformas, productos. Pero estaban en un dominio donde tenía 18 años de experiencia. Game development es nuevo para mí, y la distancia entre "puedo construir esto técnicamente" y "esto es un buen juego" es mucho más grande de lo que esperaba.

Si has cruzado esa brecha, me encantaría saber qué evitó que pivotaras de nuevo. Puedes responder en LinkedIn o escribirme directamente; tengo curiosidad de verdad.

---

Eso es todo por mi parte. Me encantaría escuchar tus ideas, especialmente si has pasado por algo parecido. Puedes contactarme en LinkedIn o escribirme directamente.

Un abrazo,

Chandler