Anatomía de un motor de juegos con IA: qué hay realmente dentro del prompt

Por Mariana Muntean, CEO de Cinevva

Lo que más suelen decir quienes descubren Cinevva es que se trata de una capa sobre una IA. Llegan a la página de inicio, ven un único cuadro de texto que dice «Describe tu juego» y creen que ya han entendido el producto. Han entendido la puerta de entrada. El producto es todo lo que no ves cuando escribes esa frase y, desde esta semana, también un mundo abierto en el que tus jugadores entran para encontrar tu juego.

Detrás de ese cuadro hay un motor de juegos completo, un orquestador con 26 herramientas tipadas, una flota de modelos generativos, una búsqueda agregada de recursos entre once proveedores, un iframe con el juego en vivo que el agente puede leer y modificar, y un escaparate donde ese mismo agente publica tu juego terminado como un vídeo de gameplay que se puede deslizar. Nada de eso es exótico. Todo es infraestructura. El trabajo interesante consistió en decidir qué conectar con qué.

Este artículo recorre la máquina de arriba abajo. Es la explicación que damos a los inversores técnicos y también a los desarrolladores que están pensando en contribuir. Ambos quieren la misma respuesta.

1. El prompt es la superficie, no el sistema

La primera decisión de diseño fue ocultarlo todo hasta que el usuario ya tuviera algo en juego. La página de inicio tiene una sola función: tomar una frase y convertirla en un proyecto. Dividimos la experiencia en una parte pública (el prompt, las muestras y el feed del escaparate) y otra para creadores (el IDE, las herramientas de recursos y el flujo de publicación), para que quienes solo quieren jugar no tengan que mirar la cabina de mando.

Por eso el texto de ejemplo va alternando entre frases como «Crea un juego de la serpiente con gráficos de neón» y «Shooter de zombis con vista cenital». No son tutoriales. Son una invitación. El usuario entiende que una «idea extraña para un arcade» es una entrada válida.

En cuanto lo envías, ocurren tres cosas. El sistema crea un proyecto de juego nuevo con un ID estable. Inicializa un árbol de archivos vacío (index.html, game.js, style.css, assets/, GDD.md). Y dirige tu frase al orquestador junto con una ventana de contexto del proyecto que apunta a esos archivos vacíos. A partir de ahí, hablas con un agente que tiene manos.

2. Detrás del campo de texto, un IDE completo en el navegador

El espacio de trabajo para creadores es un IDE de tres paneles que se ejecuta por completo en el navegador. El árbol de archivos está a la izquierda, el editor de código en el centro, el iframe con el juego en vivo a la derecha y, en la parte inferior, un campo de chat. Elegimos esta disposición deliberadamente. Quienes ya programan la reconocen al instante. Quienes no, pueden ignorar el panel central y comunicarse únicamente mediante el chat.

El árbol de archivos no es una metáfora. Cada proyecto es realmente un pequeño sitio estático compuesto por HTML, JS, CSS, imágenes generadas, modelos GLB y archivos de audio, servido directamente desde R2 mediante un Cloudflare Worker. No hay ningún paso de compilación. La razón es importante. Significa que el agente puede leer y modificar los archivos que publicarías realmente, y que el mismo artefacto funciona en el iframe, en un teléfono envuelto con Capacitor, en Steam envuelto con Tauri y dentro de Discord como Embedded Activity. Un sistema de archivos, seis destinos de distribución.

Todos los juegos que generamos deben exponer dos funciones en window. getGameState() devuelve un objeto sencillo que describe el juego en ejecución (posición del jugador, puntuación, vidas, enemigos y temporizadores). setGameState(patch) aplica una actualización parcial al juego en vivo. Esa pequeña API es el contrato que permite al agente inspeccionar y modificar un juego en ejecución sin recargarlo. Volveremos al motivo en la sección 6.

3. El orquestador, donde reside el motor propiamente dicho

Lo que no entienden quienes llaman a esto «una capa sobre una IA» es que la IA no escribe código tanto como dirige una pequeña orquesta. El orquestador es un bucle de llamadas a herramientas que se ejecuta sobre un modelo de vanguardia, con un prompt de sistema de unas mil líneas y una interfaz tipada de 26 funciones. Las definiciones de las herramientas son el motor. El modelo es el director.

Las 26 herramientas se dividen en cinco familias. Las herramientas del sistema de archivos (list_game_files, read_files, search_game_file, edit_files, write_files, delete_files, rename_files) permiten al agente tratar tu juego como cualquier otro repositorio de código. Las herramientas de proyecto (create_new_game, list_games, open_game, ask_user, game_ready) gestionan el ciclo de vida de un proyecto y la devolución del control a la persona. Las herramientas generativas (generate_image, generate_skybox, generate_music, generate_sfx, rig_model, apply_animation, list_animations, list_skybox_styles) llaman a modelos especializados que veremos a continuación. Las herramientas de conocimiento (search_fonts, list_library_docs, search_library_docs, list_generations) proporcionan al agente fuentes fiables e indexadas, en lugar de API alucinadas. Y las herramientas de ejecución (read_console_logs, execute_js) permiten al agente ver y manipular el juego en vivo.

Un primer turno típico es más o menos así. El usuario escribe «Crea un shooter espacial de neón». El modelo emite una llamada a write_files con un GDD.md que describe el diseño y después vuelve a llamar a write_files con index.html, game.js y style.css. Llama a generate_music con prompt="shooter espacial synthwave, 120 BPM, línea de bajo enérgica", lo que inicia un trabajo en ElevenLabs Music y devuelve una URL de MP3 dentro de R2. Llama a generate_skybox con un estilo del modelo 3 de Blockade Labs para crear el campo estelar. Llama a game_ready(title, message) para cambiar el iframe a la nueva versión y, por último, a read_console_logs para confirmar que el juego se inició sin errores. Si detecta una traza de pila, vuelve a edit_files y la corrige antes de que el usuario tenga que informar de nada.

La propiedad interesante de este diseño es que el prompt del sistema y los esquemas de las herramientas son lo único específico del producto. Si cambias el modelo, todo sigue funcionando. Durante el último año hemos migrado entre tres modelos de vanguardia sin modificar la interfaz, porque la interfaz es nuestra.

4. La parte de los recursos: distribución entre modelos

El agente no genera imágenes, música, sonido ni modelos 3D. Recurre a especialistas. La parte de recursos de Cinevva distribuye el trabajo entre los mejores modelos de su clase, conectados de modo que la salida de uno sea una entrada válida para el siguiente.

Para imágenes y sprites, generate_image llama a Flux Pro 1.1 con una anchura y una altura que siempre son múltiplos de 32, y un formato de salida que cambia a PNG cuando el prompt solicita transparencia. Para canciones completas, el agente llama a ElevenLabs Music con un prompt estilístico y una duración en segundos. Para efectos puntuales, ElevenLabs SFX produce en entre cinco y quince segundos un clip a partir de texto como «disparo de pistola láser, bláster de ciencia ficción». Para entornos de 360 grados, generate_skybox llama a Blockade Labs con uno de unos noventa estilos y utiliza de forma predeterminada Digital Painting del modelo 3. Para personajes 3D, rig_model envía un GLB a Tripo para añadirle esqueleto y rig como criatura bípeda, cuadrúpeda, hexápoda, octópoda, serpentina o acuática; después, apply_animation reproduce cualquiera de los quince preajustes (reposo, caminar, correr, saltar, escalar, bucear, atacar con arma blanca, disparar, recibir daño, caer y girar, además de las marchas para criaturas no bípedas).

Cada una de estas operaciones es un trabajo, no una llamada síncrona. Tardan desde segundos hasta minutos. El orquestador las inicia, devuelve inmediatamente un jobId y un canal independiente incorpora el resultado a la conversación cuando el recurso está listo. Esto cambia por completo la experiencia. El agente puede seguir creando la lógica del juego mientras un modelo 3D termina de prepararse en segundo plano. El usuario nunca tiene que esperar por una única ruta crítica.

Todos los artefactos terminan en el mismo lugar: R2, detrás de cdn.cinevva.com, accesibles mediante URL normales. Esto significa que la siguiente llamada del agente a write_files puede limitarse a insertar <audio src="https://cdn.cinevva.com/audio/abc.mp3"> y el juego funciona sin más. Sin SDK, sin empaquetador de recursos y sin manifiesto.

5. Búsqueda de recursos entre once proveedores

La generación es excelente cuando necesitas algo específico. La búsqueda es más rápida cuando ya existe lo que necesitas. La Biblioteca de recursos es una búsqueda federada entre once proveedores de recursos gratuitos y con licencia, cuyos resultados se presentan en un único feed ordenado por relevancia.

El registro de proveedores reside en el worker y ejecuta cada consulta en paralelo en PolyHaven, Sketchfab, Freesound, Kenney, AmbientCG, Quaternius, OpenGameArt, la colección 3D del Smithsonian, TurboSquid, Synty y Jamendo. Cada proveedor implementa una interfaz común (search, getMetadata, isBrowsable, getSupportedTypes), por lo que añadir uno nuevo solo requiere un archivo TypeScript. La capa de agregación gestiona la paginación mediante cursores entre proveedores que paginan de forma distinta, elimina licencias duplicadas, normaliza los tipos de recursos en una taxonomía común (modelo, textura, audio, HDRI y sprite) y etiqueta cada recurso con su licencia para que el agente nunca elija algo que no pueda redistribuir.

Cuando ChatGPT recomendó esta herramienta el trimestre pasado como uno de los mejores buscadores gratuitos de recursos para desarrolladores de juegos, fuimos a leer la recomendación. Acertaba en lo importante. La cuestión no es que tengamos una barra de búsqueda para una única biblioteca. La cuestión es que un desarrollador independiente que busca «textura de muro de piedra» obtiene, con una sola consulta y metadatos de licencia coherentes, resultados de PolyHaven y AmbientCG junto a la versión estilizada de Kenney y una opción de fotogrametría del Smithsonian. El agente puede consultar el mismo endpoint y elegir recursos del mismo modo que lo haría una persona.

Esta es la parte del motor que suele infravalorarse. La mayoría de las demostraciones de IA para juegos lo generan todo desde cero y terminan con un aspecto uniforme, brillante y ligeramente inquietante. Los juegos interesantes de Cinevva combinan recursos generados con fotogrametría CC0 real del Smithsonian y un árbol low poly hecho a mano por Quaternius. El orquestador puede hacerlo en un solo turno.

6. El agente juega al juego

Esta es la parte que más sorprende a la mayoría de los ingenieros cuando se la mostramos. El agente no se limita a escribir código en archivos. Ejecuta el juego en un iframe aislado, lee su consola, toma capturas de pantalla por capas para distinguir la interfaz de usuario de la escena 3D y ejecuta JavaScript dentro del entorno en vivo para inspeccionar o modificar el estado. read_console_logs devuelve las últimas cincuenta líneas de console.log, console.warn, console.error y las excepciones no capturadas del iframe. Después de cada llamada a game_ready, el prompt del sistema exige que el agente llame a read_console_logs y corrija cualquier error antes de entregar el resultado al usuario. Esa única regla elimina la mayoría de los fallos del tipo «la IA dijo que había terminado, pero la pantalla está en negro» que sufren otras herramientas.

execute_js es la herramienta más potente. Ejecuta JavaScript arbitrario dentro del ámbito global del juego. Como todos los juegos deben implementar getGameState y setGameState, el agente puede ejecutar JSON.stringify(getGameState()) para leer el estado completo del juego en ejecución y después usar setGameState({player: {x: 500, y: 100}}) para teletransportar al jugador, setGameState({lives: 99}) para concederle invencibilidad o setGameState({level: 3}) para saltar a un nivel posterior. También puede inspeccionar capas de más bajo nivel, por ejemplo con scene.children.map(c => c.type) para examinar el grafo de escena de Three.js o con document.querySelectorAll('canvas').length para confirmar que el renderizador se ha montado.

Es fácil ver por qué esto importa. Cuando un usuario dice «el jugador se queda atascado en la pared del segundo nivel», el agente no tiene que adivinar. Abre el segundo nivel, ejecuta getGameState(), examina los datos de colisión, aplica un parche con execute_js para probar una solución y solo entonces escribe la corrección en el disco. Depura como lo harías tú. Tratamos el iframe como un igual, no como un objetivo.

7. Documentación de bibliotecas: la aburrida fuente de la verdad

Indexamos la documentación oficial de las bibliotecas que realmente usan los juegos (Three.js, Tone.js, Cannon y cada vez más) en un repositorio JSON estructurado y con función de búsqueda. El agente recurre a search_library_docs("threejs", "Mesh") antes de acudir a la web abierta. Es más rápido, está versionado y nunca se inventa un método cuyo nombre cambió hace dos versiones menores.

No es algo espectacular. Es la diferencia entre una IA que produce código funcional y una IA que produce código de apariencia convincente que falla en la línea cuarenta. Gran parte de la calidad visible de los juegos creados con Cinevva procede de esta única decisión.

8. De jugable a descubrible: reels y escaparate

Un juego al que nadie juega es un pasatiempo privado. El problema más difícil aún sin resolver del desarrollo independiente ya no es crear juegos. Es distribuirlos. Por eso el motor no se detiene en «jugable». Se detiene en «delante de los jugadores».

Cada proyecto de Cinevva tiene una URL estable para compartir, como play.cinevva.com/{game-id}, que abre la última versión del juego en un iframe a página completa con una pequeña superposición para indicar «Me gusta» y compartir. Cuando el agente llama a game_ready, no se limita a activar la vista previa del IDE. También ofrece publicar un reel de 15 segundos de la partida en el escaparate de Cinevva. El reel es una grabación real del juego en acción, capturada directamente desde el iframe (incluimos un pequeño script de grabación que el agente inyecta en el entorno de ejecución del juego), de modo que lo que el espectador ve al desplazarse es una partida real, no un montaje de marketing.

Eso cambia el ciclo en el que vive un desarrollador. El ciclo anterior era programar, compilar, empaquetar, subir, escribir una página de Steam, pelearse con un algoritmo y mirar un contador de listas de deseos. El nuevo ciclo consiste en escribir una frase, ver cómo el agente construye el juego, pulsar «Publicar» y ver cómo aparece en el mismo feed vertical junto a todos los demás. El descubrimiento ocurre en el mismo producto en el que ocurre la creación, con la misma URL y el mismo inicio de sesión.

Para quienes forman parte de la comunidad de desarrollo, esta es la parte que conviene examinar. La distribución siempre ha sido la ventaja competitiva que los motores de juego no incluían. Unity proporciona un editor; tú publicas el juego en Steam. Unreal proporciona un editor; tú publicas en Epic Store. Cinevva ofrece ambas mitades. El motor y el escaparate se comunican mediante el mismo orquestador que creó el juego.

9. Mejores juegos: el volante de inercia del descubrimiento

El feed de reels es una mitad del volante de inercia. La clasificación de mejores juegos es la otra. Clasifica los juegos por tendencias, novedades y mejores de todos los tiempos, ponderados según la tasa de finalización (si el jugador terminó una sesión) en lugar de por los clics brutos. La finalización es más difícil de manipular que las instalaciones. Un juego que mantiene la atención durante sesenta segundos supera a uno que se abre y se cierra de inmediato.

Cada señal vuelve a alimentar el siguiente turno del orquestador. Cuando el agente dice «añadamos un potenciador», no está recurriendo a una biblioteca fija de patrones. Recurre a un modelo que ha observado qué mecánicas están consiguiendo retener jugadores en Cinevva este mes. El volante de inercia no es una gráfica al final de la página. Es la señal de entrenamiento de todo el motor.

Para los inversores, este es el foso de datos. No solo tenemos juegos generados. Tenemos juegos generados con métricas reales de interacción en cada sesión, vinculadas a los prompts que los produjeron, a los recursos que eligió el agente y a los jugadores a quienes les gustaron. Cada ciclo refuerza el siguiente.

10. El motor se convierte en un juego

Esta es la parte que llevo meses insinuando en redes sociales. Todo lo descrito en las secciones 1 a 9 corresponde a un sistema que crea juegos. Lo más difícil de explicar, hasta que se ve, es lo que ocurre cuando el propio sistema se convierte en un lugar.

Crear juegos es un trabajo difícil, incluso con todo lo que hemos desarrollado. Si nunca has creado uno, de repente eres responsable de la trama, los personajes, el mundo, las mecánicas, quién hace qué y cuándo, el comportamiento de la luz, la superposición de los efectos especiales, la música, los efectos de sonido y los movimientos de cámara. Es mucho. Y, además, quieres que el resultado parezca tuyo, no una plantilla escupida por la herramienta de otra persona. El prompt y el orquestador se encargan de la mayor parte del trabajo mecánico. Lo que no pueden hacer por sí solos es ofrecer a tu creación terminada un escenario en el que mostrarse mientras otras personas la contemplan.

Así que construimos el escenario. Durante la mayor parte de este año, Oleg y el equipo del motor han ido publicando su trabajo en una serie de 14 partes sobre cómo llevar un mundo abierto al navegador. Terreno esculpido que puedes modificar en tiempo real. Biomas que se pintan automáticamente con roca o hierba según la pendiente y la altitud. 80 000 briznas de hierba que se mecen con el viento sobre terreno generado mediante cómputo. Un personaje que camina, corre, salta y planea tanto sobre terreno de mapas de altura como sobre terreno volumétrico con el mismo sistema de movimiento. Nada de esto era una demostración técnica hecha porque sí. Era la base de todo esto.

Hoy, el mundo abierto ya está disponible en una versión preliminar. Eliges un avatar y entras. Tus juegos publicados aparecen a tu alrededor como espacios que puedes visitar, igual que ahora aparecen en los reels del escaparate y en la clasificación de mejores juegos, salvo que llegas caminando en vez de deslizando el dedo. Puedes entrar en el juego de un desconocido desde el mundo sin salir de él. Puedes colocarte junto a la persona que creó lo que acabas de jugar y contarle qué añadirías a continuación. Puedes esculpir un fragmento de terreno con alguien a quien acabas de conocer y convertirlo en la semilla de un nuevo proyecto. El descubrimiento deja de ser un feed. Se convierte en un paseo.

Nuestro motor siempre ha sido un motor de juego en el sentido técnico. Hoy también se convierte en uno en el sentido literal. Lo que crea tu juego ahora es un juego en sí mismo, y el mismo orquestador de la sección 3, los mismos canales de recursos de la sección 4, el mismo contrato getGameState de la sección 6, los mismos reels de la sección 8 y la misma clasificación de la sección 9 se integran en el único lugar por el que caminan tus jugadores. La frontera entre crear y jugar siempre fue artificial. Ahora ha desaparecido.

Lo que creemos haber hecho bien

Lo primero que hicimos bien fue tratar el prompt como un recurso de interfaz en lugar de como un producto. El producto es el orquestador, el conjunto de herramientas, los canales de recursos y el escaparate. El prompt es la forma más sencilla posible de introducir a un usuario en el sistema.

Lo segundo fue insistir en un sistema de archivos plano y nativo del navegador, sin ningún paso de compilación. Por eso un juego de Cinevva puede distribuirse en móviles, ordenadores, Steam y Discord desde una única fuente de verdad. Por eso el agente puede leer lo que ha escrito.

Lo tercero fue el contrato por el que todos los juegos generados implementan getGameState y setGameState. Esa única línea del prompt del sistema es lo que hace que el agente parezca un colaborador en lugar de un generador de código. El agente puede jugar, y un sistema que puede jugar también puede depurar.

Lo cuarto fue integrar el escaparate en el mismo ciclo que el motor. No vamos a ganar por la calidad bruta del modelo. Llevar dos meses de ventaja a un generador de pesos abiertos no constituye ninguna ventaja defendible. Ganamos cuando el mismo agente que crea tu juego también lo publica, lo mide y aprende de cómo lo jugaron desconocidos.

Si quieres ver toda la máquina en movimiento, el prompt de la página de inicio sigue siendo la puerta de entrada. Escribe una frase. Observa lo que ocurre detrás. Después vuelve aquí y dinos sobre qué parte del motor deberíamos escribir a continuación.