Depurar juegos generados con IA

Clasifica el fallo antes de pedir una corrección

Identifica el primer paso fallido: descubrimiento del proyecto, importación, análisis o compilación, arranque de la escena, entrada del jugador, estado del gameplay, exportación o lanzamiento objetivo. Los síntomas posteriores pueden ser consecuencias de ese primer fallo. Mantén juntos la versión del motor, la revisión del proyecto, el objetivo y la reproducción exacta.

Por ejemplo, una escena que nunca arranca no puede decirte si funciona su botón de reinicio. Un navegador que no puede obtener el paquete del juego no puede probar el controlador. Lleva el error al límite correcto antes de cambiar el código; así evitas que el ciclo de reparación acumule parches no relacionados mientras el prerrequisito original sigue roto.

Captura el primer error significativo del motor

En Godot, usa el panel del depurador y la salida de ejecución pertinente. En Unity, inspecciona por separado los errores de compilación y de ejecución, y espera a que el editor esté listo antes de interpretar los resultados de la partida. Conserva la pila o ubicación que identifica el script que falla y la operación que lo activó.

Envía al agente un fragmento enfocado junto con el contexto relevante de la escena u objeto. Evita un log gigante e indiferenciado que oculte el primer error, pero conserva localmente el registro completo para inspeccionarlo después. Redacta las credenciales y los datos personales. Un informe útil indica qué hizo el jugador, qué debería ocurrir y qué informó realmente el motor.

Reduce la reproducción sin cambiar el requisito

Empieza desde un estado recuperable del proyecto y aísla la escena o acción más pequeña que todavía muestre el defecto. Mantén implicados el controlador, la regla de colisión o el límite de guardado reales del problema. Eliminar por completo el sistema que falla puede producir una ejecución limpia y perder el comportamiento que necesitabas corregir.

El brief de abajo es una plantilla diagnóstica original. Complétala con detalles observados en lugar de pedir al modelo que suponga una causa. Exige una explicación propuesta y un cambio de alcance estrecho. Cuando termine la prueba, vuelve a unirla al recorrido completo del jugador para que la reparación local no oculte una transición de escena rota.

Project revision: <record actual revision>
Engine and target: <record actual environment>
Steps: launch -> start round -> perform the failing action
Expected state: <specific result>
Observed state: <specific result>
First engine error: <relevant error and location>
Inspect the referenced scene and script before editing.
Propose one cause, make a scoped fix, then repeat these steps.
Preserve the required behavior and report any remaining failure.

Investiga una pantalla en blanco por capas

Primero determina si el motor arrancó y si se cargó la escena prevista. Después inspecciona la selección de cámara, las dimensiones del viewport, la visibilidad de los objetos, sus posiciones y cualquier capa que cubra la escena. Usa el estado del motor junto con una captura real: una imagen por sí sola puede no revelar si la escena está pausada, fuera de cámara o vacía.

Aplica una entrada y observa si cambia el estado aunque no aparezca nada. Si cambia la posición pero no la imagen, céntrate en el renderizado o en las referencias de la escena. Si no cambia ninguna de las dos cosas, investiga el arranque y la entrada antes de ajustar el arte. Vincula cada hipótesis a una observación para que el agente no reescriba ambos sistemas sin necesidad.

Sigue la entrada a través de la transición de gameplay

Sigue la acción desde el foco y el mapeo hasta su manejador y después hasta el estado que debería cambiar. Comprueba el estado de pausa y la interceptación de la interfaz antes de culpar a las matemáticas del movimiento. Un fallo de reinicio puede deberse a un manejador ausente, una referencia de escena obsoleta o un estado que nunca se restableció.

Después de reparar, prueba la acción desde más de un estado pertinente: el primer lanzamiento, después de ganar y después de perder cuando corresponda. Comprueba si hay manejadores duplicados u objetos obsoletos que solo aparecen tras varias rondas. Un miniflujo pequeño y completo puede localizar estos defectos de ciclo de vida con más eficacia que probar repetidamente el botón de forma aislada.

Separa la carga del navegador de la lógica del juego

Para una exportación web de Godot, inspecciona los paneles de red y consola del navegador antes de editar el código de gameplay. Confirma que el HTML, JavaScript, WebAssembly y el paquete del juego exportados se carguen desde la ubicación prevista. Compara la configuración de hosting con la documentación oficial de exportación web, incluidos los requisitos de la configuración de hilos elegida.

Mantén coherentes los nombres de los archivos complementarios exportados y prueba el artefacto en lugar de mezclar archivos antiguos y nuevos. Si aparece el proyecto equivocado, inspecciona la caché del service worker en el navegador de prueba. Después ejercita la entrada y verifica el contenido en movimiento. Un canvas que no está en blanco es una comprobación inicial de renderizado, no una prueba de que funcione el bucle del juego.

Comprueba los fallos específicos de la exportación en el objetivo

Cuando el editor funcione pero falle la compilación distribuida, compara la selección de la escena de inicio, los recursos incluidos, la configuración y los logs del objetivo. Conserva el hash exacto del artefacto para que una nueva exportación posterior no invalide el registro de reproducción. Prueba con un estado inicial limpio antes de confiar en las partidas guardadas o las cachés del editor existentes.

No cambies la mecánica central para resolver un archivo empaquetado ausente. Corrige el límite de empaquetado y repite la misma ruta de aceptación en la compilación objetivo. Para artefactos de escritorio, usa el sistema operativo real; para artefactos de navegador, usa el navegador y la configuración de hosting previstos. Exportar entre plataformas por sí solo no demuestra el comportamiento en el objetivo.

Cierra una reparación con un resultado anterior y posterior

Conserva la reproducción fallida, el diff acotado y la acción repetida que ahora produce el estado esperado. Añade una comprobación de regresión en el límite que causó el defecto y vuelve a reproducir el bucle de juego que lo rodea. Registra las correcciones manuales y las solicitudes consumidas por las reparaciones fallidas.

Los ejemplos de aquí son procedimientos de diagnóstico, no un caso publicado de fallo y corrección. Úsalos para crear un informe concreto de tu proyecto. Cuando el mismo síntoma persista después de varias propuestas, detén el ciclo automático y recopila la observación que falta en lugar de escalar a una reescritura amplia sin evidencia nueva.

Preguntas frecuentes