Depuración lógica en Scratch 3: localizar fallos de secuencia, condición y estado

Método conceptual de depuración: de “algo falla” a “sé por qué falla”

Depurar es aplicar un proceso repetible para encontrar la causa de un comportamiento inesperado. En Scratch, los fallos suelen venir de tres fuentes: secuencia (orden de bloques), condición (reglas lógicas que no se cumplen como crees) y estado (valores que cambian o no se inicializan). En lugar de “probar al azar”, usa un ciclo de trabajo: reproducir el fallo, aislar el guion responsable, observar cambios de estado, y validar hipótesis con pequeñas pruebas.

1) Reproducir: crea un caso mínimo que falle siempre

• Define el síntoma en una frase observable: “el sprite atraviesa la pared”, “la puntuación se duplica”, “no empieza el nivel”.
• Hazlo repetible: pulsa bandera verde, repite las mismas acciones y confirma que el fallo aparece de forma consistente.
• Reduce el escenario: si el fallo ocurre tras 2 minutos, intenta provocar el mismo fallo en 10 segundos (por ejemplo, aumentando velocidad, acortando tiempos o empezando más cerca del evento).

2) Aislar: identifica qué guion o sprite lo provoca

• Desactiva guiones temporalmente: arrastra un bloque clave fuera del guion (por ejemplo, el primer bloque dentro de un por siempre) para “romper” la ejecución sin borrar nada. Alternativamente, duplica el sprite y prueba solo con una parte.
• Prueba por eliminación: desactiva un sprite completo (ocultándolo y evitando que reciba mensajes) y observa si el fallo desaparece.
• Divide y vencerás: si un guion es largo, comenta mentalmente por secciones y prueba cada sección por separado (por ejemplo, movimiento, colisiones, puntuación).

3) Observar estado: mira lo que el programa “cree” que pasa

Muchos errores no se ven en pantalla porque ocurren en variables, condiciones o mensajes. Para observarlos, usa instrumentos de inspección.

• Visualizar variables: marca la casilla de la variable para verla en el escenario. Si cambia demasiado rápido, combínalo con esperas breves.
• Insertar esperas breves: añade esperar (0.1) segundos o esperar (0.05) segundos dentro de bucles para “ralentizar” y poder ver transiciones.
• Usar “decir” para inspeccionar valores: coloca decir (unir [x=] (x posición)) por (1) segundos o decir (unir [estado=] (estado)) por (0.5) segundos justo antes de la parte sospechosa.
• Inspeccionar condiciones: muestra el resultado de una condición convirtiéndola en texto: decir (unir [tocando pared? ] <(tocando [pared v]) ?>) por (0.5) segundos. Si no puedes convertirla directamente, muestra las variables que la componen.

4) Validar hipótesis: cambia una cosa y mide el efecto

• Formula una hipótesis concreta: “La variable vida no se reinicia al empezar”, “El mensaje se envía antes de que el receptor empiece a escuchar”.
• Haz un cambio mínimo: añade una inicialización, mueve un bloque, o agrega una espera corta.
• Comprueba el resultado: si el síntoma cambia de forma predecible, vas en buen camino. Si no cambia, deshaz y prueba otra hipótesis.

Técnicas prácticas de depuración en Scratch (kit de herramientas)

Visualización de variables con “panel de control”

Cuando hay varias variables relevantes, crea un pequeño panel de depuración en el escenario. La idea es ver el estado clave sin abrir cada guion.

• Muestra variables como estado, nivel, vida, puntos, modo.
• Si una variable cambia por varios guiones, añade además una variable ultimoCambio para registrar quién la modificó.

al presionar bandera verde
fijar [ultimoCambio v] a [inicio]
mostrar variable [estado v]
mostrar variable [ultimoCambio v]

Luego, cada vez que modifiques estado en un guion, actualiza ultimoCambio con una etiqueta.

fijar [estado v] a [atacando]
fijar [ultimoCambio v] a [enemigo: entra en rango]

“Decir” como trazas (logs) sin saturar la pantalla

Usa mensajes cortos y temporales. Colócalos en puntos de decisión: antes de un si, al entrar/salir de un bucle, al recibir un mensaje.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

si <(puntos) >= (10)> entonces
  decir [Sube de nivel] por (0.3) segundos
  cambiar [nivel v] por (1)
fin

Si se repite demasiado, limita la traza con una condición (por ejemplo, solo cuando cambie un valor).

Esperas breves para detectar carreras y orden de ejecución

Una esperar (0.1) no es “la solución”, es un instrumento para comprobar hipótesis sobre sincronización. Si al añadir una espera el fallo desaparece, probablemente tienes un problema de orden o de coordinación entre guiones.

Desactivar guiones temporalmente sin perder trabajo

• Romper el bucle: saca fuera el bloque por siempre o el bloque que lo inicia, y vuelve a colocarlo cuando termines.
• Encapsular con una bandera: crea una variable debug y rodea secciones con si <(debug) = [1]> entonces para activar/desactivar trazas o comportamientos.

si <(debug) = (1)> entonces
  decir (unir [vida=] (vida)) por (0.2) segundos
fin

Clasificación de errores y cómo reconocerlos rápido

Guía práctica paso a paso: depurar un fallo de secuencia, condición o estado

Paso 1: escribe el contrato esperado

Antes de tocar bloques, define qué debería pasar y cuándo. Ejemplo: “Al tocar pared, el sprite debe retroceder y la velocidad debe ser 0”. Esto te da una referencia para decidir si una variable está bien o mal.

Paso 2: coloca puntos de inspección

Elige 2 o 3 puntos del guion donde el comportamiento cambia (antes del si, dentro del si, después). Añade trazas con decir y muestra variables clave.

Paso 3: ralentiza si hay demasiados cambios

Si el fallo ocurre en milisegundos (colisiones, rebotes, contadores), añade esperar (0.05) dentro del bucle para observar. Si al ralentizar aparece un patrón (por ejemplo, alterna entre dos estados), ya tienes una pista.

Paso 4: prueba hipótesis con cambios mínimos

Ejemplos de cambios mínimos: mover una inicialización al inicio, invertir una comparación, añadir una actualización faltante dentro del bucle, o reordenar dos bloques.

Paso 5: confirma con una prueba de regresión

Repite el caso mínimo varias veces. Si el fallo desaparece pero aparece otro síntoma, vuelve a aislar: a veces arreglar el orden revela una condición mal formulada.

Casos de estudio cortos: síntomas y diagnóstico

Caso 1: Orden incorrecto (inicialización después de usar)

Síntoma: al iniciar, la puntuación aparece con un valor raro durante un instante, o el juego sube de nivel inmediatamente.

Observación: la variable puntos se usa en una condición antes de fijarse.

Diagnóstico: el bloque fijar [puntos] a 0 está después de un bloque que evalúa si <(puntos) >= (10)>.

Prueba: añade decir (unir [puntos al inicio=] (puntos)) por (0.5) justo al comenzar.

Arreglo típico: mover la inicialización al principio del guion de arranque (antes de cualquier condición o mensaje relacionado).

Caso 2: Condición mal formulada (uso incorrecto de “y” / “o”)

Síntoma: un enemigo ataca aunque estés lejos, o nunca ataca.

Observación: la condición combina distancia y estado, pero la lógica no coincide con la intención.

Diagnóstico: se usó o cuando se necesitaba y (o viceversa). Ejemplo: “ataca si está cerca y el jugador está visible”, pero el guion dice “cerca o visible”.

Prueba: muestra ambos componentes por separado con decir (distancia y estado) y comprueba cuándo se activa.

Arreglo típico: reescribir la condición en partes pequeñas y verificar con valores extremos (muy cerca/muy lejos; visible/no visible).

Caso 3: Bucle sin salida (condición de salida nunca cambia)

Síntoma: el sprite se queda “pensando” y no continúa; no se ejecutan bloques después de un repetir hasta.

Observación: el bucle depende de una variable que no se actualiza dentro del bucle.

Diagnóstico: la condición de salida usa, por ejemplo, repetir hasta <(tiempo) > (5)>, pero tiempo nunca aumenta en ese bucle.

Prueba: dentro del bucle, añade decir (unir [tiempo=] (tiempo)) por (0.2) y esperar (0.1). Si el valor no cambia, ya está localizado.

Arreglo típico: actualizar la variable dentro del bucle o cambiar la condición para depender de algo que sí cambie (por ejemplo, un temporizador o un evento real).

Caso 4: Variable no inicializada (estado “arrastrado” entre partidas)

Síntoma: al volver a jugar, el personaje empieza con vida baja, o el nivel no vuelve a 1.

Observación: el proyecto funciona bien la primera vez, pero falla tras reiniciar con bandera verde.

Diagnóstico: faltan bloques de inicialización para variables de estado (vida, nivel, modo, inventario).

Prueba: al presionar bandera verde, muestra en pantalla las variables clave durante 1 segundo con decir o con monitores visibles.

Arreglo típico: crear una sección clara de “reset” al inicio: fijar variables, ocultar/mostrar sprites, y establecer estados coherentes.

Caso 5: Mensaje no recibido (coordinación y momento de escucha)

Síntoma: un sprite no reacciona a “empezar nivel” o “game over”, pero otras partes sí.

Observación: hay un enviar [X], pero el receptor parece no ejecutar al recibir [X].

Diagnóstico: el receptor está en un bucle que no cede control (sin esperas) o está en un estado donde su guion de recepción no llega a ejecutarse como esperas; también puede ocurrir que el mensaje se envíe antes de que el sprite esté listo (por ejemplo, antes de mostrarlo o antes de fijar un estado que su recepción requiere).

Prueba: añade trazas: en el emisor decir [Envío X] por (0.2) justo antes de enviar; en el receptor decir [Recibo X] por (0.2) al recibir. Si ves el envío pero no la recepción, aísla el receptor desactivando otros guiones y añade una esperar (0.01) dentro de bucles intensivos para permitir que otros guiones se ejecuten.

Arreglo típico: asegurar que los bucles largos incluyan pequeñas esperas cuando corresponda, y que el orden de preparación (estado listo) ocurra antes de enviar el mensaje que depende de ese estado.

Mini-checklist de depuración (para pegar al lado del proyecto)

• ¿Puedo reproducir el fallo en menos de 15 segundos?
• ¿Qué variable o estado debería cambiar y no cambia (o cambia de más)?
• ¿Qué condición decide el comportamiento y con qué valores se evalúa?
• ¿Hay un bucle que podría estar bloqueando el resto?
• ¿Se inicializan las variables al empezar?
• ¿Veo “envié” y “recibí” para los mensajes críticos?
• ¿Puedo desactivar la mitad de los guiones y ver si el fallo sigue?