Desarrollo de juegos con IA en Godot

Define el límite del proyecto antes de editar

Empieza en un directorio de proyecto que controles y con una lista escrita de cambios permitidos. Haz inventario de las escenas, scripts, recursos y plugins existentes para que el agente pueda ampliar la estructura actual en lugar de crear una segunda implementación. Mantén recuperable el estado inicial del proyecto y registra qué binario del motor lo abre.

Elige una parte jugable modesta con transiciones explícitas. Por ejemplo, una pantalla de título que lleve a una sala y vuelva mediante victoria o derrota te da una prueba repetible. Decide quién revisa la composición visual y los controles, porque ni un parser correcto ni el mensaje de finalización de un modelo demuestran que la experiencia sea coherente.

Identifica el ejecutable y los argumentos compatibles

La documentación CLI estable de Godot proporciona los comandos siguientes. GODOT_BIN y PROJECT son variables de shell elegidas para este ejemplo, no ajustes de Godot; sustituye sus rutas de ejemplo por tu ejecutable y proyecto existentes. La ruta del proyecto debe contener project.godot.

Captura la versión y la salida de ayuda antes de automatizar flags adicionales. Así evitas suponer que un comando disponible en la documentación online actual existe en la compilación que tienes instalada. Registra la identidad del binario junto con los resultados de pruebas posteriores y mantenla estable mientras investigas un fallo. Estos comandos ilustrativos usan las formas documentadas de la CLI.

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

Separa la importación, el análisis y la partida real

Una importación sin interfaz comprueba un límite del procesamiento de recursos. Una comprobación de parser examina un script. Un lanzamiento normal llega al juego y puede revelar problemas de conexión entre escenas y fallos de ejecución. Mantén esos resultados separados en el registro de revisión en lugar de resumir los tres como pruebas superadas.

La ruta de script ilustrativa de abajo debe existir ya en tu proyecto. Una comprobación de parser es deliberadamente estrecha: no puede demostrar que funcionen las colisiones, que la entrada responda o que la persistencia sea correcta. Después de una edición, vuelve a reproducir el comportamiento que cambia y la transición inmediatamente anterior y posterior. Esto suele informar más que crear numerosas comprobaciones aisladas para funciones auxiliares generadas.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

Elige de forma deliberada herramientas CLI o MCP

Un agente con acceso al shell puede operar una secuencia CLI revisada. Godot MCP es otra interfaz de herramientas mantenida para el proyecto, cuya configuración se explica en su página específica. En ambos casos, el operador debe saber qué proyecto es el objetivo antes de aprobar una escritura o lanzar un proceso.

Mantén separada la configuración del proveedor de modelos del agente de las herramientas del motor. Una conexión local funcional no demuestra que un modelo concreto esté disponible ni que el agente admita todas las funciones de un gateway compatible. Establece primero la lectura mínima permitida, después un cambio de escena reversible y solo entonces un ciclo completo de gameplay dentro de un experimento autorizado.

Proporciona suficiente contexto de escena para los fallos

Cuando falle una interacción, captura el árbol de escena pertinente, el script, la acción de entrada y el primer error de ejecución significativo. Explica la transición esperada y el estado observado. Un informe que diga que el jugador no puede moverse debe indicar si el juego tiene el foco, si se detecta la entrada y si cambia la posición del jugador.

Exige una corrección pequeña con una explicación vinculada a esa evidencia. Después de aplicarla, repite la misma acción e inspecciona si hay regresiones en el reinicio y las transiciones de escena. No aceptes una reparación solo porque el error desapareció; desactivar la función afectada puede eliminar un error mientras deja incumplido el requisito original.

Prepara explícitamente los prerrequisitos de exportación

Una exportación requiere un preset coincidente y plantillas de exportación instaladas. Revisa export_presets.cfg y la inclusión de recursos antes de compilar. Mantén privadas las credenciales de exportación. El nombre del preset del ejemplo es ilustrativo y debe coincidir con tu proyecto; el directorio de salida debe existir ya.

Trata una plantilla o preset ausente como un problema del entorno, no como evidencia de que la lógica generada del juego sea incorrecta. Conserva los logs de exportación y el hash del artefacto para que los hallazgos de la plataforma objetivo se refieran a una compilación concreta. Una exportación correcta es un punto de control importante, pero no demuestra que el jugador entregado se inicie o complete una ronda.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

Ejecuta un miniflujo de entrega en el objetivo

Lanza el juego exportado en el sistema operativo que pretendas admitir. Prueba el inicio, la entrada, una ronda completa, el reinicio, los ajustes y la persistencia después de volver a abrirlo. Para cada resultado, conserva la identidad del artefacto, el contexto del dispositivo y el resultado observado. Una exportación creada en macOS no verifica por sí sola el comportamiento en Windows.

Para un objetivo web, inspecciona también la carga del navegador y los errores de ejecución, y ejercita el canvas con entradas reales. Verifica que el contenido sea visible y se mueva cuando corresponda. Prueba la configuración de hosting prevista en lugar de suponer que la ejecución local en el editor cubre la carga de recursos del navegador y las restricciones de la plataforma.

Un proyecto fuente y una captura nativa para inspeccionar

El ejemplo local de Switchyard proporciona un rompecabezas de Godot con tres salas, comprobaciones automatizadas de gameplay, comprobaciones de guardado y reapertura, logs sin procesar, un ZIP de código fuente y un PCK de Godot. Sus capturas nativas muestran el proyecto real en ejecución en dos tamaños de viewport. Repetir los comandos documentados es una comprobación más sólida que juzgar el proyecto solo por una captura de pantalla.

El proyecto usó Godot 4.5.1 en una ejecución de Codex cuyo modelo exacto de generación no se verificó. Por tanto, demuestra un flujo de trabajo local del motor, no un benchmark de Astra. La exportación para navegador estaba bloqueada por la falta de plantillas de exportación y el PCK no es un ejecutable independiente de Windows. Esos límites quedan registrados junto al código fuente para que el siguiente desarrollador sepa qué falta probar.

Cierra el ciclo con una entrega revisable

La entrega debe nombrar el alcance jugable, la identidad del código fuente, las versiones del motor y de las plantillas, las instrucciones de compilación, los resultados aceptados y los defectos sin resolver. Incluye capturas auténticas del artefacto probado y la procedencia de los recursos distribuidos. Conserva los intentos de reparación y las intervenciones manuales en lugar de presentar solo un volcado final de código generado.

Cuando se acepte el bucle básico, añade recursos y localización mediante sus propias comprobaciones de importación y gameplay antes de considerar el envío a una plataforma. Este recorrido se basa en la documentación del motor; aplícalo a tu versión instalada y conserva los resultados reales. Mantén una lista breve de problemas pendientes con pasos de reproducción para que la siguiente sesión de desarrollo empiece desde el mismo estado conocido.

Preguntas frecuentes