Cómo usar Cursor AI con Godot (guía paso a paso para 2026)

{/* IMAGE: Hero showing a Godot project open in Cursor on the left with an AI edit mid-stream in a GDScript file, and the Godot editor on the right with the scene tree visible. A dashed line connects them labeled "you wire these two together." 1200x630, illustration. */}

Cursor no tiene un botón para Godot. No hay ninguna integración que instalar, ninguna entrada en un marketplace de plugins que fusione mágicamente ambas herramientas. Lo que ocurre en realidad es más sencillo y un poco más manual: Cursor es un editor de código, un proyecto de Godot es una carpeta de archivos, y apuntas Cursor a esa carpeta y enseñas a las dos herramientas a cooperar. Bien configurado, tienes uno de los mejores entornos de programación con IA disponibles apuntando directamente a tu GDScript. Mal configurado, Cursor escribe con toda la confianza código de Godot 3 en tu proyecto de Godot 4 y adivina nombres de nodos que no existen.

Esta guía es la configuración que funciona, en orden, con los ajustes que importan y el único límite que debes conocer antes de empezar. Nosotros construimos Summer Engine, un motor nativo de IA compatible con Godot 4, así que seremos honestos sobre dónde el enfoque de Cursor es excelente y dónde choca con un techo.

Antes de empezar: qué es realmente esta configuración

Cursor edita los archivos de texto dentro de un proyecto de Godot, y un proyecto de Godot es mayormente texto: scripts .gd, archivos de escena y recursos .tscn y .tres (legibles por humanos), la configuración project.godot y los shaders. Cursor lee y edita todos esos archivos sin problema.

Lo que Cursor no es, en esta configuración, es el motor. No ejecuta tu juego, no controla el árbol de escena como estructura activa, ni ve lo que ocurre en tiempo de ejecución. Mantienes el editor de Godot abierto junto a Cursor: Cursor escribe el código, Godot lo ejecuta. Esa división es todo el modelo mental, y una vez que lo entiendes el resto es directo.

Paso 1: Abrir tu proyecto de Godot en Cursor

Abre Cursor, elige Open Folder y selecciona la raíz de tu proyecto de Godot (la carpeta que contiene project.godot). Cursor ahora ve cada script, escena y archivo de configuración, y puede editar a través de todos ellos.

Un hábito inmediato: mantén ambas aplicaciones abiertas una al lado de la otra, Godot en una mitad con el árbol de escena y el juego en ejecución, Cursor en la otra con tus scripts. Cambiarás constantemente entre "pedirle a Cursor que escriba esto" y "ejecutarlo en Godot para ver si funcionó".

Paso 2: Instalar la extensión godot-tools para GDScript

Este es el paso que la mayoría de la gente se salta, y es el que evita que Cursor escriba tonterías.

Cursor está construido sobre el ecosistema de extensiones de VS Code, por lo que la extensión oficial godot-tools funciona directamente. Abre el panel de Extensions, busca "godot-tools" e instálala. Se conecta al servidor de lenguaje integrado de Godot, lo que te da autocompletado preciso de GDScript, documentación al pasar el cursor, saltar a la definición y, lo más importante, sintaxis que coincide con tu versión real de Godot en lugar de lo que el modelo supuso.

Para que la conexión se active, el editor de Godot debe estar en ejecución con su servidor de lenguaje habilitado (activado por defecto, puerto 6005). Con ambos en marcha, los completados de GDScript de Cursor se obtienen de la API real del motor en lugar de datos genéricos de entrenamiento.

Usuarios de C#: instala la extensión de C# y las herramientas de Godot C# en su lugar. Los modelos manejan Godot C# al menos igual de bien que GDScript porque hay mucho más código público en C#, así que la calidad del lenguaje es alta; las mismas advertencias sobre conciencia del proyecto que se describen a continuación siguen aplicando.

Paso 3: Hacer que Godot abra scripts en Cursor

Ahora mismo, al hacer doble clic en un script en Godot se abre el editor de scripts integrado de Godot. Apúntalo a Cursor para que tu flujo de trabajo sea coherente.

En Godot, ve a Editor Settings, Text Editor, External. Marca Use External Editor. Establece Exec Path con la ruta al ejecutable de Cursor, y ajusta Exec Flags al formato goto de Cursor: {project} --goto {file}:{line}:{col} (ese flag es el argumento de línea de comandos literal de Cursor para saltar a una línea). Ahora al hacer doble clic en cualquier script en el árbol de escena de Godot, se abre en Cursor en la línea exacta, y te quedas en un solo editor para todo el trabajo de código.

Es un detalle pequeño que elimina una fricción constante. Sin él acabas con código escrito a medias en el editor de Godot y a medias en Cursor, que es como terminas con buffers desactualizados y dolores de cabeza con las versiones.

Paso 4: Añadir un servidor MCP de Godot para que Cursor vea tus escenas

Aquí es donde la configuración mejora de forma significativa. Por defecto, Cursor lee un archivo .tscn como texto: ve los datos serializados pero no los interpreta como un árbol de nodos, así que cuando le pides "un script en el jugador que referencie el AnimationPlayer", adivina la ruta del nodo. Las rutas adivinadas son lo que te da $AnimationPlayer cuando el nodo en realidad está en $Visuals/AnimationPlayer.

Un servidor MCP de Godot soluciona esto. MCP (Model Context Protocol) permite que Cursor llame a un pequeño servidor que lee la estructura real de tu escena y la devuelve como contexto, de modo que Cursor usa nombres de nodos que realmente existen.

Para añadir uno, abre la configuración MCP de Cursor en ~/.cursor/mcp.json (global) o .cursor/mcp.json (proyecto), añade una entrada de servidor según las instrucciones de instalación del servidor que elijas, y reinicia Cursor. Una vez registrado, pregunta "qué nodos están bajo la escena Player" y responde a partir de tu proyecto real. Nuestra guía sobre servidores MCP de Godot cubre las opciones y lo que expone cada una.

Omite este paso y Cursor sigue editando scripts bien; simplemente heredas el problema de las suposiciones en todo lo que toca rutas de nodos y señales.

Paso 5: Escribir tu primera edición con IA

Con el proyecto abierto, la extensión instalada y, idealmente, un servidor MCP conectado, estás listo. Los dos flujos que más usarás:

• Edición en línea (Cmd/Ctrl+K): Selecciona un bloque de GDScript, pulsa el atajo, describe el cambio. Ideal para "convertir esto en una máquina de estados" o "añadir un tiempo de enfriamiento a este ataque".
• Composer / chat: Describe una funcionalidad en el chat y deja que Cursor planifique y aplique ediciones en varios archivos. Ideal para "añadir un sistema de recolección de monedas con un contador en el HUD".

Un primer prompt realista: abre tu script del jugador, selecciona el código de movimiento, Cmd+K, y escribe "añadir un doble salto que se reinicia cuando el jugador toca el suelo, sintaxis Godot 4". Cursor propone un diff. Revísalo antes de aceptarlo, porque aquí es donde aparece el problema de Godot 3.

La trampa de Godot 3 (y cómo eliminarla)

La queja más común sobre IA y Godot es que el asistente escribe código de Godot 3: pides movimiento y obtienes KinematicBody2D y move_and_slide(velocity) con la firma antigua, o yield donde necesitas await. Los datos de entrenamiento públicos están sesgados fuertemente hacia Godot 3, así que un modelo sin guía recurre a él.

Tres soluciones, por orden de impacto:

1. La extensión godot-tools (Paso 2) corrige gran parte mediante el servidor de lenguaje, que conoce la superficie real de tu API.
2. Una regla de proyecto. Cursor te permite añadir reglas en la configuración o en un archivo .cursor/rules. Añade: "Este es un proyecto Godot 4.x. Usa await, @export, @onready, CharacterBody2D/CharacterBody3D, la propiedad velocity con move_and_slide() (sin argumento), y la sintaxis de conexión de señales basada en Callable. No uses nunca APIs de Godot 3." Esto orienta cada generación.
3. Un archivo de ejemplo. Pega un script correcto de Godot 4 de tu proyecto como contexto. Los modelos adoptan agresivamente la API del código cercano, así que un buen ejemplo vale más que un párrafo de instrucciones.

Con los tres en su lugar, la filtración de Godot 3 desaparece casi por completo.

El límite que vas a alcanzar: Cursor no puede ejecutar tu juego

Este es el techo honesto, y se aplica a todos los asistentes externos de IDE (Cursor, Copilot, Claude Code), no solo a Cursor.

Cursor edita archivos. No puede pulsar play, leer la salida en vivo del depurador de Godot ni observar la escena en ejecución. Así que el bucle es: Cursor escribe código, cambias a Godot, pulsas play, obtienes un error de referencia nula porque una ruta @onready era incorrecta, copias el stack trace, lo pegas de vuelta, Cursor propone una corrección, vuelves a ejecutar. Tú eres el canal de retroalimentación en tiempo de ejecución. Para un desarrollador rápido esto es un coste menor; para un principiante, cada error en tiempo de ejecución es un cambio de contexto y una suposición sobre qué línea del trace importa.

Esto duele más en Godot que en la mayoría de los stacks porque muchos bugs de Godot solo aparecen en tiempo de ejecución: un nodo que es null porque se renombró, una señal que nunca se conectó, una discrepancia en la capa de física que silenciosamente impide la colisión. Ninguno de esos aparece en el texto del archivo. Aparecen cuando el juego se ejecuta.

Dónde encaja Summer Engine

Nosotros hacemos Summer Engine, un motor nativo de IA compatible con Godot 4, y existe precisamente para ese techo. En lugar de un asistente que edita archivos junto al motor, el agente de IA corre dentro del motor. Ve el árbol de escena activo, pulsa play, lee los diagnósticos y errores del depurador mientras el juego se ejecuta, y corrige su propio GDScript a partir del error real en tiempo de ejecución en lugar de tu stack trace pegado. Ese bucle de escribir, reproducir y leer es la capacidad que un editor externo estructuralmente no puede tener, porque el editor no es el programa que ejecuta el juego.

Dos puntos honestos para que esto siga siendo una guía y no una propuesta de venta:

• Si eres un desarrollador de Godot con experiencia que vive en un IDE, adora la edición con teclado y ya tiene un pipeline de assets y una rutina de depuración, Cursor con la configuración anterior es genuinamente excelente y puede que no necesites nada más. Preferiríamos que usaras Cursor antes que cambiar sin razón.
• No tienes que elegir. Summer Engine incluye un servidor MCP, así que puedes mantener Cursor para la edición de código en profundidad y dejar que impulse el motor en ejecución de Summer para lo que Cursor no puede hacer (ejecutar escenas, generar assets, leer errores en vivo). Apunta mcp.json de Cursor al endpoint de Summer y obtienes edición de primer nivel más un motor que puede ejecutar y autocorregirse.

Para un análisis completo de dónde gana cada herramienta, lee nuestra comparación de Cursor más Godot frente a Summer Engine. El ranking de los mejores asistentes de codificación con IA para Godot cubre Copilot, Claude Code y las opciones dentro del motor en paralelo.

Lista de verificación de la configuración

Paso	Qué haces	Por qué importa
1. Abrir el proyecto	Abre la carpeta con project.godot en Cursor	Cursor puede editar cada script y escena
2. Extensión godot-tools	Instálala en Cursor, ejecuta Godot a la vez	Completado preciso de Godot 4, elimina casi toda la filtración de Godot 3
3. Editor externo	Apunta Godot a Cursor en Editor Settings	Un solo editor para todo el código, sin buffers desactualizados
4. Servidor MCP de Godot	Añade a .cursor/mcp.json, reinicia	Cursor ve el árbol de escena real, deja de adivinar rutas de nodos
5. Regla de proyecto	Añade una regla de Godot 4.x en la configuración de Cursor	Fuerza la API actual, await, @export, CharacterBody
El límite	Cursor no puede ejecutar el juego	Tú sigues siendo el depurador en tiempo de ejecución; la IA nativa del motor elimina esto

La versión corta

Usar Cursor con Godot son cuatro pasos más una regla: abre la carpeta del proyecto, instala godot-tools, establece Cursor como editor externo de Godot, añade un servidor MCP de Godot para la conciencia de escena, y añade una regla de proyecto para Godot 4 para que deje de escribir código de Godot 3. Con eso, Cursor es un editor de código con IA de primer nivel apuntado a tu GDScript.

El límite concreto es el tiempo de ejecución. Cursor edita archivos; tú ejecutas el juego y le devuelves los errores. Si quieres que la IA cierre ese bucle ella sola (ejecutar la escena, leer el error en vivo, corregir su propio código), ahí es donde un motor nativo de IA toma el relevo. Cursor y Summer Engine no están en competencia; muchos desarrolladores usan ambos, Cursor para el código y el MCP de Summer para las operaciones del motor que un editor de texto no puede alcanzar.

Para la vía nativa del motor, descarga Summer Engine (gratuito para empezar, con crédito mensual gratuito en la generación de assets) o empieza desde una plantilla y describe lo que quieres construir.