Skip to content

Los motores de juegos nativos de IA ya están llegando, y no se parecen en nada a Unity

Por Oleg Sidorkin, CTO de Cinevva

En marzo aparecieron tres motores de juegos cuya arquitectura es diferente de todo lo que existe en el linaje de Unity, Unreal y Godot. No tienen editores visuales. No están optimizados para que una persona navegue por menús haciendo clic. Se han creado desde cero para que los agentes de IA puedan leer, escribir y controlar el estado del juego.

Esto no es «Unity con una pestaña de IA». Es una especie de motor diferente.

La IA ya está cambiando los flujos de trabajo del desarrollo de juegos 3D. La capa del motor es la siguiente.

Los tres motores

nAIVE Engine es de código abierto y está escrito en Rust, con renderizado WebGPU. Recarga en caliente en menos de un segundo: shaders en menos de 200 ms, escenas en menos de 100 ms y scripts en menos de 50 ms. Las escenas, las canalizaciones y los materiales se definen en YAML, lo que permite que los LLM los lean y generen sin tener que analizar formatos binarios. Ofrece una interfaz de comandos MCP que permite a los agentes de IA controlar las funciones del motor mediante JSON-RPC. Incluye compatibilidad nativa con splatting gaussiano y renderizado sin interfaz gráfica para pruebas automatizadas. Toda la arquitectura parte de la premisa de que el usuario principal podría ser un agente de IA, no una persona con un ratón.

Arcane Engine es un motor 2D centrado en el código. Núcleo en Rust y scripting en TypeScript. No tiene ningún editor visual. Su filosofía: «el código es la escena». El estado del juego es una base de datos consultable en lugar de un árbol de escenas. Incluye un protocolo integrado para interactuar con agentes de IA. Tiene licencia Apache 2.0.

Mirror Engine está en fase alfa y prioriza el multijugador mediante un sistema de entidades y componentes. La parte interesante: incluye generación de texto a 3D con IA que produce splats gaussianos a partir de instrucciones de texto en unos 60 segundos. Scripting en TypeScript y un cliente para navegador llamado «Mirror Lite».

Estos tres motores no comparten código ni equipo, pero sí una tesis de diseño: la interfaz principal de un motor de juegos debería ser texto estructurado, no una GUI.

Por qué importa esta arquitectura

Los motores de juegos tradicionales evolucionaron para servir a una persona sentada frente a un escritorio. Tienes una vista de escena. Un panel de jerarquía. Un inspector. Una línea de tiempo. Todo está diseñado para hacer clic, arrastrar y colocar objetos visualmente. Ese flujo de trabajo es potente. También es imposible de usar para un agente de IA.

Cuando tu «usuario» principal es un LLM, necesitas primitivas diferentes. YAML en lugar de formatos binarios de escena. Estado consultable en lugar de árboles de escenas anidados. Comandos basados en protocolos en lugar de clics del ratón. Funcionamiento sin interfaz gráfica en lugar de renderizado en una ventana.

Es el mismo cambio que se produjo en la infraestructura cuando DevOps pasó de los paneles de control con GUI a la infraestructura como código. Lo mismo está sucediendo ahora con los motores de juegos, solo que veinte años después.

La interfaz MCP de nAIVE es el ejemplo más claro. MCP (Model Context Protocol) se está convirtiendo en el estándar para que los agentes de IA se comuniquen con herramientas. Cuando un motor admite MCP de forma nativa, cualquier agente de IA compatible con el protocolo puede manipular escenas, ajustar parámetros, ejecutar pruebas e iterar sobre la jugabilidad sin intervención humana. No es una función añadida a un motor tradicional. Es una relación fundamentalmente diferente entre el motor y su usuario.

Splatting gaussiano en el desarrollo de juegos. Tanto nAIVE como Mirror lo tratan como una primitiva de renderizado nativa.

El panorama general

Estos tres motores no son la única señal. Black Box de Meshy mostró mecánicas de juego generadas por IA en tiempo de ejecución. OpenAI presentó en la GDC un RPG táctico creado con Phaser. La capa de herramientas entre «la IA genera algo» y «ese algo se ejecuta como un juego jugable» se hace más delgada cada mes.

En Cinevva llevamos tiempo construyendo este puente desde la dirección opuesta. Nuestro motor se ocupa del renderizado, la física y la interacción en tiempo real, mientras que la IA se encarga de generar recursos. El enfoque es diferente al de nAIVE o Arcane, pero la apuesta subyacente es la misma: el motor de juegos del futuro debe hablar el lenguaje de la IA de forma nativa, no limitarse a incorporarla como un complemento.

Los fabricantes de motores tradicionales también lo saben. Unity presentó un avance de sus herramientas de creación de juegos con IA en la GDC. Roblox lanzó la creación de modelos 4D con IA. Pero hay una diferencia significativa entre añadir funciones de IA a un motor diseñado para humanos y diseñar un motor cuya interfaz principal sea la IA.

Lo que creo que ocurrirá a continuación

La mayoría de estos motores no sobrevivirá. Es normal en una categoría nueva. Pero los patrones de diseño sí lo harán. Definiciones de escenas basadas en YAML, protocolos MCP para el control mediante agentes, estado del juego consultable y funcionamiento sin interfaz gráfica. Estas ideas se incorporarán a los motores más extendidos en un plazo de dos años.

El motor que gane esta era probablemente aún no exista. Pero su ADN arquitectónico se está escribiendo ahora mismo, en estos tres proyectos y en unos cuantos más. La pregunta no es si los motores de juegos se volverán nativos de IA. Es si la transformación vendrá desde dentro de las empresas establecidas o de nuevos participantes que diseñaron para agentes desde el primer día.


Relacionado: