El estado honesto de hacer juegos con IA en 2026

Un repaso sin bombo: lo que hacer juegos con IA hace bien de verdad en 2026, lo que todavía no puede hacer y lo que solo parece haber cambiado.

Publicado el 2026-08-18 · Game design

Read this page in English

Separa la demo del día a día

Este ensayo trata de lo que pueden hacer las herramientas. Para cifras medidas sobre lo que la gente construye de verdad con ellas, del primer mensaje al primer playtest, lee El estado de la creación de juegos con IA.

Casi todas las impresiones fuertes sobre hacer juegos con IA vienen de un clip: cuarenta segundos, una instrucción, algo aparece y se mueve. Los clips no mienten. Son un registro real del mejor caso, grabado en la tanda en que funcionó.

El problema es que un juego no es un mejor caso. Un juego son cuatrocientas horas en las que casi todo el trabajo es pequeño, concreto y poco vistoso, y las herramientas tienen que aguantar los días aburridos además del día de la demo. Un repaso que merezca la pena leer va de los días aburridos.

Así que esto es un repaso de la categoría sin el marketing. Reparte el campo en tres montones: lo que funciona de verdad ahora, lo que no, y lo que tiene apariencia de progreso sin mucho debajo. Nada de previsiones presentadas como hechos. Nada de cifras de adopción, porque las honestas son difíciles de comprobar y las comprobables suelen ser la nota de prensa de alguien.

Todo lo que sigue trata de capacidades, no de una herramienta concreta. Las capacidades cambian despacio y son fáciles de probar por tu cuenta. Las promesas de producto cambian rápido y no lo son.

Una regla más. Cuando una afirmación de abajo se puede comprobar en una hora, vale más que una que no, así que el artículo se apoya en las que puedes reproducir. Abre una herramienta, pide el mismo sprite dos veces y mira los dos resultados uno al lado del otro. Eso lleva cuatro minutos y zanja más discusiones que cualquier cantidad de lectura.

Escribir código dentro de un proyecto real es lo que de verdad avanzó

Si hay una cosa que ha cambiado de verdad en dos años, es que un modelo escriba código de juego dentro de un proyecto existente. No pseudocódigo en una ventana de chat. Archivos de script reales que compilan, están en la carpeta correcta y algo los llama.

Se le da bien la fontanería. La gestión de la entrada, las máquinas de estados, guardar y cargar, los temporizadores, la contabilidad del inventario, las señales entre objetos, la aparición de enemigos, las matemáticas quisquillosas de una cámara que sigue al personaje, la tercera refactorización de una función de daño. Ese trabajo es sobre todo patrón, y los patrones son de lo que están hechos estos sistemas.

También se le da bien algo concreto que es fácil de infravalorar: leer un código que no escribió y responder una pregunta sobre él. Dónde se fija la velocidad del jugador. Qué escucha ya este evento. Por qué el enemigo se para en el borde. Para alguien que no escribe código, esa es la diferencia entre un proyecto que parece una caja cerrada y uno por el que se puede navegar.

Lo que se le da mal es saber qué debería ser el juego. Pide un salto y te da un salto, bien hecho. Pide un salto que se sienta como un juego concreto que adoras y te da una suposición razonable. Luego otra suposición razonable. El ciclo solo se cierra cuando una persona lo juega y dice más corto, más pesado, más rápido al despegar.

La consecuencia práctica está en cómo le das las instrucciones. Las peticiones vagas reciben implementaciones genéricas, porque lo genérico es la respuesta más segura a una pregunta poco concreta. Las peticiones concretas sobre comportamiento, números y qué debe pasar en los casos límite se acercan mucho más a lo que querías, y esa concreción tiene que venir de alguien que ha decidido qué es el juego.

El blockout es la victoria silenciosa que nadie anuncia

La ganancia real más útil de los últimos dos años no es nada terminado. Es la velocidad a la que tienes delante una versión fea, jugable y más o menos correcta de un espacio.

El 3D generado en 2026 crea un modelo con textura a partir de una descripción. La topología es densa e irregular, los UV los hace la máquina, no hay niveles de detalle, y el rigging o la retopología siguen siendo trabajo de una persona. Lee esa lista como veredicto sobre los modelos protagonistas y es demoledora. Léela como veredicto sobre un objeto gris que existe para que juzgues el tamaño de una puerta, y es irrelevante.

Esa es la posición honesta de la geometría generada: excelente para hacer el blockout de una escena, pobre para cualquier cosa en la que se detenga la cámara. Una plaza de mercado con cuarenta puestos toscos te enseña sobre líneas de visión, distancias a pie y si el espacio aburre, y te lo enseña la primera tarde y no la tercera semana.

La trampa es el momento en que el blockout empieza a parecer aceptable. La geometría aceptable tiende a sobrevivir hasta producción, porque sustituirla da sensación de retroceder. Decide pronto qué objetos son andamio, y está dispuesto a tirar el andamio.

Hay un segundo beneficio, más discreto. Una escena tosca es algo a lo que reaccionar, y reaccionar es más fácil que inventar. Estar de pie en un pasillo mal proporcionado te dice cuál es la proporción correcta mucho mejor que mirar una cuadrícula vacía intentando imaginarla.

El arte provisional es rápido y sigue siendo provisional

El texto a imagen es rápido y útil de verdad, y falla de formas completamente previsibles en cuanto las has apuntado.

Dos llamadas con la misma descripción no coinciden. Las dimensiones exactas en píxeles no son fiables. No hay un borde alfa limpio a menos que alguien lo recorte. Un conjunto de objetos no comparte paleta. No hay coherencia de hoja de sprites, ni rig, ni garantía de que el segundo fotograma de un ciclo de andar se parezca al primero. Nada de eso es un fallo que se arregle el próximo trimestre; se deriva de cómo se produce el resultado.

Así que lo honesto es decir que el arte generado es un buen provisional y un mal recurso final. Como provisional está cerca de lo ideal, porque todo el trabajo de un provisional es que dejes de adivinar cómo se sentirá la pantalla, y lo hace en segundos y a coste cero.

Como recurso final falla en la coherencia, y la coherencia es casi todo lo que significa dirección de arte. Un juego en el que cada objeto es precioso por separado y ninguno concuerda con los demás se ve peor que uno dibujado en un solo estilo plano por una persona en una tarde.

Hay un camino que funciona: usar la generación para la composición y la idea de un recurso, y que luego una persona unifique el conjunto: una paleta, un grosor de línea, una dirección de luz. Es mucho menos trabajo que dibujar desde cero, y es el paso que la gente se salta cuando espera que el resultado venga terminado.

Efectos de sonido, un clip corto cada vez

Los efectos de sonido generados funcionan a un tamaño concreto: unos segundos, uno cada vez, a partir de una descripción. Impactos, pasos, pitidos de interfaz, una puerta, el tintineo de recoger algo. Para un prototipo que lleva una semana en silencio, es una mejora real en cinco minutos.

Lo que no es es un sistema de audio. No hay mezcla por capas, ni comportamiento adaptativo que siga el estado de quien juega, ni un conjunto de variaciones que suenen como una familia, ni ducking, ni reverberación que dé sensación de sala. Esos son problemas del motor y de la mezcla, y siguen siendo tuyos.

La generación de música no forma parte de este flujo de trabajo en absoluto, y merece la pena decirlo sin rodeos en lugar de dejar que la palabra "audio" cargue con una implicación que no se ha ganado.

El valor práctico es el mismo que con el arte. Un prototipo con sonido tosco se juzga con más precisión que uno mudo, porque buena parte de si una acción se siente bien vive en la respuesta. El sonido tosco te lleva a un veredicto justo. No te lleva a una banda sonora.

Una advertencia sobre la cantidad. Como los clips son baratos, es fácil acabar con sesenta y sin idea de cuáles están de verdad en la build. Ponles nombre sobre la marcha y borra los que descartaste, o la carpeta se convierte en un pequeño impuesto sobre cada decisión futura.

La velocidad de iteración es el cambio infravalorado

El cambio más valioso no es ningún resultado concreto. Es que la distancia entre "me pregunto si" y "puedo verlo" se ha acortado mucho, y se ha acortado en varias cosas a la vez: código, arte tosco, un espacio en blockout, un ruido provisional.

Eso importa porque casi todo el diseño de juegos es un problema de búsqueda. No llegas razonando a un buen arco de salto. Pruebas once y te quedas con uno. Todo lo que aumenta el número de intentos que te puedes permitir aumenta la calidad de lo que te quedas, y lo hace sin volver a nadie más listo.

También cambia qué merece la pena prototipar. Ideas que antes no valían los dos días que costaba probarlas ahora valen los veinte minutos. Algunas resultan ser las buenas, y antes eran invisibles porque nadie iba a gastar dos días en una corazonada.

El riesgo del otro lado es real. Los intentos baratos hacen fácil seguir generando en lugar de decidir, y una carpeta con cuarenta variaciones no es progreso. La velocidad solo es una ganancia si algo se elige.

Una disciplina útil es decidir la pregunta antes de empezar a generar. Si sabes que estás probando si el dash debería cancelar el ataque, reconocerás la respuesta cuando la veas. Si generas para ver qué sale, seguirás mucho rato y acabarás el día sin nada decidido.

Lo que todavía no funciona: lo terminado

Todos los fallos de arriba apuntan en la misma dirección. Estos sistemas producen un buen primer borrador de una pieza aislada y les cuesta todo lo que tiene que concordar con todo lo demás.

Un recurso 2D final tiene que encajar en una paleta, mantener la silueta al tamaño al que se muestra de verdad y coincidir con sus propios fotogramas de animación. Un recurso 3D final necesita una topología limpia, UV sensatos, niveles de detalle y un rig que un animador pueda usar. Una base de audio final tiene que responder a lo que hace quien juega. Nada de eso sale de una sola vez; son resultados más una persona que los integra.

La coherencia a largo plazo es el mismo problema estirado en el tiempo. Un modelo te escribirá encantado cincuenta descripciones de misiones. Hacia la duodécima, el mismo pueblo tiene dos nombres, un personaje que murió está repartiendo encargos y el tono ha pasado de irónico a solemne sin que nadie lo decidiera. Cada una por separado se lee bien. Como conjunto de contenido no se sostienen.

La solución no es una instrucción mejor. Es estructura: una pequeña fuente de verdad sobre el mundo, escrita a mano, contra la que hay que comprobar todo lo generado, y una persona que haga la comprobación. Eso es trabajo de verdad, y fingir lo contrario es donde empieza casi toda la decepción.

Lo mismo vale para los sistemas, no solo para el texto. Diez comportamientos de enemigo producidos por separado no forman un elenco, porque un elenco se define por cómo se diferencian sus miembros entre sí. La coherencia es una propiedad del conjunto, y estos sistemas producen miembros.

Nada de esto puede decirte si el juego es divertido

Este es el techo plano de toda la categoría, y no se mueve. Un modelo puede decirte que tu diseño se parece a otros diseños. No puede decirte si tu juego es divertido, porque la diversión es un hecho sobre una persona que juega, y el modelo no está jugando.

Pregúntale si tu combate se siente bien y obtendrás una respuesta fluida y bien organizada, montada con cosas que la gente ha escrito sobre combate. Sonará a opinión. No es una opinión, porque no se ha vivido nada. Lo peligroso es que suena lo bastante segura como para sustituir la prueba con jugadores que no hiciste.

Aquí el instrumento eres tú. No necesitas escribir el código para juzgar el resultado, y nadie tiene que protegerte del veredicto. Lo juegas, notas que la segunda sala aburre, y darte cuenta de eso es la aportación más valiosa de todo el proceso.

Trata el ciclo en consecuencia. Genera para tener algo jugable, juégalo tú, di con palabras sencillas qué está mal y devuelve eso como la siguiente instrucción. El juicio se queda contigo no como una limitación, sino porque es el único sitio donde puede vivir.

También significa que probar con otras personas no ha perdido nada de valor. Tu juicio es fiable sobre si algo está mal y mucho menos fiable sobre si un desconocido lo entenderá, y ninguna cantidad de contenido generado cambia esa cuenta.

Lo que solo parece haber cambiado

Tres cosas se presentan como progreso y son sobre todo presentación.

La primera es la fluidez. Los resultados están mejor escritos, mejor iluminados, mejor compuestos y se parecen más a lo que imitan. Es real, pero es una mejora en el primer borrador, no en la integración, y la integración es donde se iban las horas desde el principio. Un recurso más bonito con el mismo problema de borde alfa cuesta lo mismo de arreglar.

La segunda es el juego de una sola instrucción. Entra una descripción, sale algo jugable, y es impresionante de verdad mientras no intentes cambiarlo. La prueba no es si produjo algo. La prueba es qué pasa con la cuarta petición de cambio, cuando tu modificación tiene que sobrevivir al contacto con todo lo que ya había.

La tercera es el vocabulario. Palabras como agente, pipeline y de principio a fin se han ampliado para cubrir flujos de trabajo que siguen teniendo los mismos pasos manuales, solo descritos desde más altura. Cuando leas una afirmación, tradúcela hacia abajo: qué archivo concreto produce esto y quién lo arregla cuando está mal.

Ninguna de las tres es una estafa. Son entusiasmo de producto normal, y los resultados que hay detrás son de verdad mejores que antes. La distorsión está en la conclusión implícita, que es que el trabajo que queda es pequeño. No lo es, y saberlo de antemano es la diferencia entre un proyecto que sobrevive al contacto con la realidad y uno que se atasca en el segundo mes.

Una forma sensata de trabajar en 2026

Pon la generación donde es fuerte. Úsala para llegar rápido a algo jugable, para escribir la fontanería, para llenar una escena de objetos cuyo trabajo es tener el tamaño correcto y para hacer ruido donde había silencio. Cada una de esas cosas es un provisional con una función.

Guarda la autoría donde escasea. Las reglas de tu mundo, el tono, de qué va de verdad el juego, la decisión de qué hace quien juega con las manos durante los primeros noventa segundos. Eso son decisiones, no resultados, y ningún volumen de material generado sustituye el haberlas tomado.

Juega constantemente y pronto. Toda la ganancia de iterar más rápido se pierde en cuanto dejas de mirar el resultado, porque entonces solo estás acumulando material que nadie ha revisado. Una build que has jugado vale más que una carpeta que no has abierto.

Y mantén una línea clara en la cabeza entre borrador y final. Casi todo lo que hace bien la categoría es hacer borradores. Hacer borradores rápido vale muchísimo. Simplemente no es la misma afirmación que terminar, y la distancia entre esas dos palabras es donde se fabrica casi toda la decepción de este campo.

Descarga Flockbay

El material generado te lleva rápido a algo jugable. Decidir si es bueno sigue siendo trabajo de una persona con un mando.

Lee más notas de diseño de juegos