La idea empezó bonita: una muela digital que te manda en aventuras, inspirada en The Amazing Digital Circus. Un 'mascota digital' que genera juegos y pequeñas misiones para mejorar tu productividad, disfrazado de videojuego. Lo que ocurrió es una lección práctica sobre límites de modelos, contextos y expectativas.
Qué intentaron construir
El autor quiso crear una mascota que generara juegos completos en three.js cada día, alimentada por un modelo grande (Nemotron 30b). La intención era que esas aventuras fueran útiles para la productividad, una especie de to-do list hiperengañosa que funciona como juego.
Empezó con prompts largos que describían la lógica del juego y cómo implementarla. Cuando eso falló, añadió skill cards (plantillas de habilidades) sacadas de este repositorio game-engine SKILL.md. Luego intentó destilar esas habilidades con Codex y aplicar RAG para mantener la información disponible al modelo. Al final, el proyecto terminó como un generador simple de HTML - capaz de crear relojes, to-do lists, snake o breakout, pero no juegos más complejos como tetris.
Técnicas usadas y por qué fallaron
-
Context window y límites de memoria: el modelo tenía un
context windowcorto para ahorrar cómputo. Añadir más contexto explotó ese límite de recursos. Muchos fallos vinieron porque el código generado requería más estado y referencias de las que el modelo podía mantener. -
Prompts largos vs. distilación: prompts muy largos son frágiles. Poner todo en un solo prompt suele dar resultados inconsistentes. Intentar comprimir conocimiento en archivos de skills y hacer
RAGfuncionó mejor, pero no lo suficiente para entregar juegos sin bugs. -
Errores comunes en la generación de juegos: pantallas en blanco por errores de runtime, dependencias mal declaradas, coordinación entre assets, y lógicas de física o colisiones incompletas. Un modelo puede esbozar código válido, pero pequeñas inconsistencias rompen el juego entero.
-
Tooling y debugging limitado: generar código automáticamente es útil, pero sin un loop de prueba y depuración automatizado (tests, lint, ejecución de headless browser) el resultado se rompe en producción.
Cosas técnicas que ayudan a entender lo que pasó
-
Nemotron 30b: un modelo grande de base, capaz pero sujeto a los mismos límites de contextos y a la fragilidad de la generación de código complejo. -
RAG(Retrieval-Augmented Generation): mantiene un repositorio externo de conocimiento y lo inyecta al modelo. Reduce la necesidad de prompts kilométricos, pero exige buenas estructuras de búsqueda y chunking de información. -
Codex: usado para destilar y reescribir habilidades; útil para transformar instrucciones en código más consistente. -
three.js: la librería objetivo para los juegos. Requiere coordinar canvas, actualización de estado y assets; errores mínimos producen pantalla vacía.
Estado actual y lecciones prácticas
El proyecto pivotó a un generador HTML-toymaker alojado en Hugging Face Spaces. Puedes probarlo aquí: AmazingDigitalPetDentures.
Lecciones claras:
-
Empieza con módulos pequeños y testados. Mejor tener muchos ejemplos simples que uno complejo y frágil.
-
Automatiza pruebas: headless browser + tests unitarios sobre lógica del juego ayudan a detectar pantallas en blanco antes del despliegue.
-
Usa RAG con chunking y metadatos precisos. No es solo meter todo en un txt; hay que indexarlo y diseñar retrievals coherentes.
-
Limita la ambición del modelo: generación de pequeñas interacciones o templates que el sistema 'ensambla' es más robusto que pedir un juego entero en una sola pasada.
Ideas para pivot y mejoras técnicas
-
Generador de plantillas modulares: en vez de juegos completos, generar componentes
three.js(player, enemy, física) que el usuario combine. Más control, menos fallo. -
Sistema híbrido: plantillas predefinidas + generación de scripts específicos. El modelo produce solo la lógica que cambia entre templates.
-
Pipeline de verificación automática: después de generar código, ejecutarlo en un entorno headless y capturar errores para que el modelo los corrija (loop generate-test-repair).
-
Editor interactivo asistido por IA: que sugiera chunks de código con preview instantáneo. Así el humano acepta o rechaza partes rotas.
-
Microjuegos procedurales: en vez de recrear Tetris, generar variaciones de minijuegos con reglas reducidas. Más creatividad, menos complejidad.
Reflexión final
Fracasar en un hackathon no es fracaso absoluto; es un laboratorio donde se revela qué partes del stack necesitan ingeniería real. Lo que aquí se rompió tiene solución con pipelines, pruebas y diseño modular. ¿Te interesa armar un pequeño pipeline de generate-test-repair para este tipo de proyectos? Podemos bosquejarlo y convertir la muela digital en una fábrica de microjuegos confiable.
Fuente original
https://huggingface.co/blog/build-small-hackathon/amazingdigitaldentures