Herramientas usadas en este artículo
La vez pasada, Claude construyó un mundo dentro de Unreal Engine 5.8 a través del nuevo MCP nativo - y el comentario más destacado en ese video fue, por mucho: “De acuerdo, ¿pero puedes hacer esto con una IA local, gratuita y de código abierto?” Es una buena pregunta. Claude es brillante, justo hasta que ves la factura.
Así que esta vez: sin nube, sin API key, sin suscripción. Qwen3.6-27B - 27 mil millones de parámetros, unos diecisiete gigabytes en una sola GPU de consumo - conectado directamente a Unreal Editor en vivo a través del mismo MCP nativo. Diecisiete prompts, y cada uno de ellos es un chat nuevo: el modelo no recuerda nada entre pasos. Thinking mode está desactivado. Y cada tarea en el historial de Cline termina con el mismo número en la esquina: $0.00.

La verdadera pregunta nunca fue “¿puede abrir el editor?”. Era si un modelo local podía sobrevivir a un proyecto real: crear los Blueprints, construir un HUD de 28 widgets, conectar un sistema de entrada y rastrear su propio error en las entrañas del motor - o desmoronarse en la primera llamada a una herramienta. Hasta donde sabemos, nadie había publicado una build exitosa con un LLM local a través del MCP nativo de UE antes de esta; el único intento público que encontramos terminó en fracaso el día del lanzamiento. Aquí está la configuración exacta, lo que construyó y el veredicto sincero.
1. El modelo: Qwen3.6-27B y el hardware que realmente necesita
El elegido es Qwen3.6-27B - un modelo denso de pesos abiertos que actualmente se ubica cerca de la cima en los benchmarks de programación agéntica entre los modelos abiertos, con mejoras en las llamadas a herramientas incorporadas en esta generación. La versión exacta utilizada aquí es la del repositorio GGUF de unsloth con la cuantización UD-Q4_K_XL (UD = Unsloth Dynamic) - aproximadamente 17 GB de pesos.

2. Sírvelo localmente con llama.cpp (los flags lo son todo)
Instala llama.cpp con un solo comando - en Windows eso es winget install llama.cpp - e inicia el servidor. El flag -hf descarga la cuantización exacta directamente desde Hugging Face en la primera ejecución, por lo que no hay un paso de descarga por separado:
winget install llama.cpp # macOS/Linux: curl -LsSf https://llama.app/install.sh | sh
llama serve -hf unsloth/Qwen3.6-27B-GGUF:UD-Q4_K_XL -a Qwen3.6-27B \
--host 127.0.0.1 --port 1235 \
-ngl 99 -fa on -c 40960 \
--cache-type-k q8_0 --cache-type-v q8_0 \
--jinja --reasoning off \
--temp 0.7 --top-p 0.80 --top-k 20 --min-p 0.0 \
--presence-penalty 1.5 --repeat-penalty 1.0Qué hace cada bloque, porque cada uno de ellos se ganó su lugar:
-ngl 99 coloca cada capa en la GPU (99 simplemente significa “todas”). -fa on activa flash attention. -c 40960 es el contexto máximo nativo de Qwen3 - redúcelo si tienes poca VRAM. Los flags de caché K/V q8_0 comprimen la caché de atención a 8 bits: la memoria casi se reduce a la mitad y la calidad apenas cambia.-a Qwen3.6-27B nombra el modelo en la API - la cadena exacta que escribirás en Cline más adelante. --reasoning off desactiva el modo de razonamiento: el bucle de un agente necesita una llamada rápida a una herramienta por turno, no un monólogo - menor latencia, sin tokens desperdiciados.--repeat-penalty 1.0, lo que significa desactivado. llama.cpp lo tiene por defecto en 1.1, y esa penalización de estilo antiguo perjudica a Qwen.--jinja obliga a llama.cpp a usar la plantilla de chat nativa del modelo. Sin él, el servidor no puede analizar las etiquetas que Qwen utiliza para dar formato a las llamadas a herramientas - y Cline nunca verá ni una sola llamada a herramienta. El modelo parece vivo, conversa alegremente y no le hace absolutamente nada a tu editor. Si tu agente local “habla pero nunca actúa”, este flag es lo primero que debes revisar.
3. Configura Cline para usar tu propio servidor
Cline es el harness del agente - una extensión gratuita y de código abierto para VS Code. llama-server expone un endpoint compatible con OpenAI, por lo que Cline se comunica con tu GPU exactamente como si fuera una API en la nube:
API Configuration
Provider OpenAI Compatible; Base URL http://127.0.0.1:1235/v1 (la ruta /v1 es obligatoria); Model Qwen3.6-27B - debe coincidir exactamente con el valor del flag -a; API Key - cualquier cadena no vacía (el servidor nunca la verifica, pero Cline requiere el campo). Context Window 40960, en sincronía con el servidor. Reasoning Effort None, para que coincida con --reasoning off.
Funciones que importan para un agente de Unreal
Native Tool Call ON - usa el formato real de llamadas a herramientas del modelo en lugar de trucos de prompts. Parallel Tool Calling OFF - de todos modos no puedes trabajar en Unreal Editor en paralelo; es una operación a la vez. Auto Compact OFF - aquí un chat es una tarea, por lo que nunca hay un historial largo para comprimir.
Yolo Mode activado (opcional, pero de eso se trata)
Yolo Mode autoaprueba cada llamada a herramienta - el equivalente local de bypass-permissions. Con un agente en la nube, cada «¿proceder?» te cuesta atención y dinero; aquí el modelo es tuyo, así que déjalo correr.

4. Conéctalo con Unreal Engine 5.8
En Unreal usamos el mismo servidor MCP nativo que vimos en el capítulo anterior - habilita el plugin, activa Auto Start Server y el editor escucha en http://127.0.0.1:8000/mcp. (El plugin de MCP todavía está marcado como Experimental, y a veces se nota - más sobre eso más adelante.) Lo único nuevo es indicárselo a Cline en cline_mcp_settings.json:
{
"mcpServers": {
"unreal-mcp": {
"type": "streamableHttp",
"url": "http://127.0.0.1:8000/mcp"
}
}
}Primera tarea, en un chat nuevo: “verificar la conexión MCP con Unreal Engine.” La primera llamada a execute_python_code falló con un AttributeError: una llamada errónea a la API de Python. Y este fue el primer momento realmente alentador: el modelo leyó el traceback, concluyó por su cuenta que la conexión estaba bien y que solo su código era erróneo, y reintentó con el código corregido. Ocho milisegundos después: “MCP connection to Unreal Engine: SUCCESSFUL.”

Un modelo local sin memoria entre tareas depende por completo de su archivo de reglas. Este en particular - BurgerTower_SystemPrompt.md - contiene las convenciones del proyecto, las notas sobre la API del editor, la disciplina de compilación y las trampas del motor que, de otro modo, consumirían un prompt cada una (los floats deben declararse como tipo real o se convertirán en ints sin ninguna advertencia; un sistema por llamada a herramienta; compilar dos veces para eliminar la advertencia de valor por defecto). Colócalo en tu proyecto y adáptalo.
5. La prueba de estrés: un juego completo en 17 prompts
El proyecto es BurgerTower - un juego arcade de apilar con un solo botón. Una pieza de comida se balancea sobre una torre creciente; toca para soltarla. Un aterrizaje limpio otorga un bonus y una salpicadura de jugo de carne; una torre inclinada se derrumba y termina la partida. Con cada piso la cámara sube más alto - ciudad, nubes, estratosfera, espacio. El proyecto incluye solo arte: ocho mallas de comida, una textura de panorama y un mapa de estudio vacío. Al modelo le corresponde crear cada Blueprint, grafo, widget, asset de entrada, material y efecto en vivo, en el editor, mediante Python.

Y una regla que convierte esto en un benchmark real y no en una demo: cada prompt es una tarea completamente nueva de Cline con un contexto limpio. El modelo no recuerda nada entre pasos - los prompts mismos mantienen la continuidad, como encargos entregados a un contratista que despierta con amnesia cada mañana. Diecisiete encargos en total.
Prompts 1-6: todo el esqueleto, sin presionar Play ni una sola vez
Los primeros seis prompts construyen cada parte por separado y la verifican solo mediante compilación: el actor de la pieza que cae con su perfil de física y su pool de mallas (la malla DEBE ser el componente raíz - la física simula la raíz, y una malla que cuelga debajo de una raíz vacía se desprende en cuanto se activa la simulación de física); su grafo de eventos, donde un evento Hit con triple filtro convierte un contacto físico en una sola señal de «aterricé»; un burst de Niagara duplicado a partir de una plantilla del motor; el pawn de la cámara con 19 variables de estado; y el HUD.

El HUD merece su propia frase: 28 widgets - tarjeta de puntuación, una pastilla dorada de BEST, avisos de PERFECT!/COMBO, un indicador de altitud con marcas para CITY/CLOUDS/STRATOSPHERE/SPACE y una pantalla de muerte completa con un botón RETRY - organizados, anclados, coloreados y estilizados completamente en código, en dos llamadas a herramientas, sin un solo clic en el diseñador de UMG. La segunda llamada fue un bloque de código continuo que el modelo local transmitió durante unos dos minutos y medio. Compiló sin errores.
Prompts 7-13: conectando todo, primer Play, primer game over
El episodio dos conecta las partes en orden de dependencia: primero el receptor de aterrizaje en el pawn, luego el ciclo de Tick (el balanceo senoidal, la subida suave de la cámara, las actualizaciones del HUD cuadro por cuadro y una verificación de fallo basada en la física), los assets de Enhanced Input, el bootstrap de BeginPlay y el game mode - incluida la sutil trampa de que, tras configurar el pawn por defecto, el game mode debe ser recompilado, o de lo contrario Play seguirá generando el pawn genérico del motor. El modelo recompiló y volvió a leer el valor para verificarlo. El primer Play de toda la serie ocurre recién después del prompt 11: el pawn aparece, el HUD se muestra en cero y una pieza se balancea sobre el pan base.

El prompt 12 es el botón de soltar -evaluar el perfect en el momento de presionar, activar la física de la pieza, subir la cámara, generar la siguiente pieza- y el bloque de código más grande de la serie: cerca de tres minutos de streaming, luego tres minutos y medio del motor compilando el grafo. A mitad de la tarea, el endpoint de MCP perdió la sesión; Cline reenvió exactamente la misma llamada por su cuenta y la construcción continuó. Fallas de entrega como esta ocurrieron tres veces a lo largo del proyecto, y el agente se recuperó por sí solo de cada una en cámara. Luego: Play, primera caída, una racha de “PERFECT! x4”, una torre inclinada, un derrumbe a los 5,316 metros, GAME OVER, RETRY - todo el game loop funciona. El prompt 13 es la clásica pasada de ajuste de sensaciones: ampliar el balanceo, acelerarlo y abrir el FOV de 70 a 80.

Prompts 14-15: un shader construido a partir de una fórmula, luego el pase de lanzamiento
El prompt 14 es para lucirse: construir el material de fondo en código -unos 18 nodos de material mediante MaterialEditingLibrary-, mapeando una textura panorámica alta en espacio de pantalla, con la ventana visible deslizándose hacia arriba en sincronía con la subida de la cámara. Pura matemática de shaders, dictada como una fórmula en el prompt y transcrita en conexiones de nodos por el modelo. Esta tarea también generó el único contratiempo real de la serie: una respuesta se perdió en tránsito, el reintento chocó con el asset que la primera llamada ya había creado y Unreal mostró cuadros de diálogo de sobrescritura. El modelo no entró en bucle: concluyó que el material existía y pasó a la parte dos. El prompt 15 es el pase de lanzamiento: conectar el único cable de ejecución que se había dejado deliberadamente desconectado desde el prompt 7 (el estallido de acierto perfecto, esperando detrás de su compuerta), cambiar el color del efecto al marrón del jugo de carne y pasar lista -ocho assets, todos compilando sin errores-.

Prompt 16: el verdadero bug -y el momento que responde al título-
Después del pase de lanzamiento, el splash del acierto perfecto todavía se renderizaba blanco en el juego, a pesar de que los reportes de las herramientas estaban en verde y se había comprobado que los valores de color estaban en el asset. El Prompt 16 le plantea el misterio al modelo: averiguar por qué el color nunca llegó a la pantalla. El diagnóstico que produjo es el momento más brillante de todo el proyecto: Niagara compila sistemas en segundo plano, y el juego había estado reproduciendo la copia compilada anterior del efecto todo el tiempo. Su solución: volver a configurar el color en los tres emisores, guardar y forzar una recompilación abriendo el sistema en el editor. En la siguiente ejecución: dos aciertos perfectos, con salpicaduras marrón oscuro y chispas. Eso no es simplemente reconocer patrones de un tutorial: es razonar sobre el pipeline de assets del motor.
El Prompt 17 es el postre: importar un nuevo panorama -una cabeza gigante masticando sobre una ciudad de hamburguesas- y redirigir el sampler del material hacia él. Una importación, una redirección; los cálculos del paneo están en parámetros escalares que nunca afectan la textura, por lo que el fondo cambió en vivo en el viewport, a mitad de sesión.

6. El veredicto honesto
- Sobrevivió a un proyecto real. Diecisiete prompts con contexto limpio, cada sistema compilando sin errores, un bug auténtico a nivel de motor diagnosticado y solucionado. El esqueleto del juego se construyó sin presionar Play ni una sola vez.
- Es más lento que un modelo frontier en la nube. Los bloques de código grandes se generan durante dos o tres minutos en una sola GPU de consumo, y el grafo más pesado tomó otros ~3.4 minutos de compilación en el motor. Reserva una noche tranquila, no la hora del almuerzo.
- El harness hace un trabajo real. Cline reenvió llamadas MCP que se habían perdido en tres ocasiones; el modelo se recuperó de su propia llamada errónea a la API y de un reintento que provocó una colisión de assets. Es de esperar que el endpoint de MCP, todavía en fase Experimental, tenga tropiezos y que el bucle los resuelva.
- Los prompts aportan la inteligencia por la que no estás pagando. Instrucciones precisas, para un sistema a la vez, junto con un archivo de reglas son lo que hace que un modelo local sin memoria actúe como un experto. Los prompts vagos no resistirán la prueba en la práctica.
- ¿Reemplaza a Claude? Para una construcción estructurada como esta -sinceramente, con $0.00 en costos de API-, hizo el trabajo. Para un trabajo desordenado y abierto, un modelo frontier todavía te da un margen que un modelo local de 27B no tiene. Elige por proyecto, no por ideología.

Y sí, la numerología encaja: 17 prompts, un modelo de ~17 GB y una torre final de 17.7 kilómetros de altura, más allá del límite del espacio, dentro de la boca abierta de un gigante y con una pantalla de game over como corresponde. Cada paso costó $0.00.
Lo que realmente obtienes
Ese es todo el pipeline: un comando de llama.cpp, una página de configuración de Cline, una entrada de MCP y un modelo local controlando el mismo editor que manejan los agentes en la nube. Las herramientas de generación que alimentan proyectos como este siguen cambiando; cuando salen nuevas, van directo a la Arena para que puedas compararlas a ciegas antes de decidirte por una. Para los capítulos anteriores de esta historia, consulta Unreal Engine 5.8 Native MCP + Claude y Claude Code + Unreal Engine 5.
Mira cómo se creó el juego completo
Toda la configuración y los 17 prompts, de principio a fin, en YouTube.