Aquí está la parte impopular: prohibir el truco barato nos costó tiempo y dinero reales, y lo volveríamos a hacer sin dudarlo. La mayoría de los generadores de juegos con IA simulan el 3D —un canvas inclinado, algo de matemática de perspectiva, listo en una tarde. Nosotros también lo probamos, y funcionó exactamente tan bien como suena.
La señal llegó el día que pusimos una simulación en canvas junto a un build renderizado por un motor real. No fue cuestión de gusto ni de acabado. Uno parecía un juego. El otro parecía una hoja de cálculo con aspiraciones. Así que escribimos una regla estricta en las guías del builder: renderizado con motor real o nada. Los juegos web usan una pila integrada de three.js y física. Todo lo que aspire a calidad nativa pasa por el Unity Lab, donde los agentes escriben C# real contra Unity 6 y compilan builds WebGL que puedes jugar en una pestaña del navegador.
La parte de la que nadie te advierte: los assets
Prohibir el renderizador falso fue la mitad fácil. Lo difícil es que un motor real solo renderiza lo que le das, y los agentes de solo código, dejados a su suerte, producen arte de programador —esferas bultosas con buenas intenciones, nada que un jugador quisiera ver. La solución no fue un mejor renderizador. Fue reordenar el pipeline: primero concepto, luego geometría. Un agente pinta arte conceptual antes de tocar una malla. Luego un agente de modelado escribe un script de Blender apuntando a ese concepto, lo renderiza sin interfaz gráfica, y un ciclo de auditoría visual compara el render con el concepto y devuelve el script para revisión hasta que ambos realmente coincidan.
Ese ciclo es lento y consume cómputo discutiendo consigo mismo. También es lo único que nos sacó del arte de programador. Cada página de pieza en el laboratorio publica sus rondas de auditoría, así que puedes ver cómo converge en lugar de solo creernos. Aquí está la pieza más reciente, un coro de órgano, en la ronda uno y la ronda cuatro:
Y una vez que está dentro del motor con la iluminación y los materiales realmente haciendo su trabajo:
El sonido era el mismo argumento en otra clave
El equivalente sonoro de un canvas falso es un simple beep de osciladores, y durante un tiempo nuestros juegos estuvieron llenos de ellos —baratos de generar, instantáneamente reconocibles como baratos. Mismo diagnóstico, misma cura: una regla estricta más herramientas reales. Todo ahora proviene de instrumentos muestreados, 84 de ellos en una biblioteca propia, además de ambientes grabados. Un nivel de puerto tiene agua y gaviotas que suenan a agua y gaviotas. El sonido de éxito de un juego de rompecabezas lo toca algo, no lo calcula algo.
Por qué publicar todo el desorden en línea
Un demo reel muestra tus mejores cinco minutos. Un laboratorio lo muestra todo, incluidas las rondas en las que el modelo se veía mal.
El laboratorio ahora tiene 83 páginas de builds publicadas, y el Blender Studio muestra el lado de los assets en sus propios términos —scripts, renders de tornamesa, el historial completo de auditoría con sus defectos incluidos. Publicamos las rondas fallidas a propósito. Cualquiera puede elegir a dedo una buena captura de pantalla; eso no prueba nada. Mostrar cada iteración, incluida la fea geometría de la primera ronda, es mucho más difícil de falsificar, y ese es todo el sentido de hacerlo así.
Ahora la concesión, porque los críticos de este enfoque no se equivocan sobre el costo. Un canvas falso se puede lanzar en una tarde; nuestro pipeline requiere un ciclo de auditoría, un agente de modelado y tiempo real de compilación del motor antes de que algo sea jugable. Para un prototipo rápido o un juego de jam desechable, ese sobrecosto realmente no vale la pena —el truco del canvas es más rápido y, para cinco minutos de juego que nadie mira de cerca en capturas de pantalla, quizás es suficientemente bueno. No decimos lo contrario. Simplemente no construimos para juegos desechables de cinco minutos, y una vez que la calidad es el producto real, el camino lento es el único que sobrevive al contacto con un jugador de verdad.
