Condicionales en Scratch 3: decisiones con reglas claras (si, si no)

Verdadero o falso: la base de los condicionales

Un condicional en Scratch toma una pregunta que solo puede tener dos resultados: verdadero o falso. Esa pregunta se construye con bloques de la categoría Operadores (comparadores y lógica) y, muchas veces, con datos que vienen de Sensores (teclado, ratón, color, distancia, etc.).

En Scratch, las condiciones suelen verse como un bloque con forma de hexágono (por ejemplo, <, =, >, tocando [objeto]?). Ese bloque encaja en si <condición> entonces o en si <condición> entonces / si no.

Comparadores: construir condiciones simples y legibles

Los comparadores responden verdadero/falso comparando números o textos. Los más usados son:

• < menor que
• = igual a
• > mayor que

Ejemplos de condiciones simples

• Límite de pantalla: (x posición) > 230

• Puntuación mínima: (puntos) >= 10 (en Scratch no existe >= como bloque directo; se construye con o o con negación, ver más abajo)

  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

• Estado de juego: (estado) = [jugando]

Consejo de legibilidad: escribe condiciones que se puedan leer como una frase. Por ejemplo: “si puntos es mayor que 9” en vez de “si no es menor que 10”.

Operadores lógicos: y, o, no (condiciones compuestas)

Cuando una sola comparación no alcanza, se combinan condiciones con lógica booleana:

• y: ambas condiciones deben ser verdaderas.
• o: al menos una condición debe ser verdadera.
• no: invierte el resultado (verdadero pasa a falso y viceversa).

De simple a compuesto: patrón recomendado

1) Escribe primero una condición simple que funcione. 2) Prueba. 3) Luego combínala con otra usando y u o. 4) Vuelve a probar.

Ejemplo: rango (evitar ambigüedades con límites)

Un rango típico es “x entre -200 y 200”. Eso no se escribe con un solo comparador, sino con y:

<(x posición) > -200> y <(x posición) < 200>

Errores comunes:

• Usar o en un rango: x > -200 o x < 200 casi siempre será verdadero, porque casi cualquier número cumple al menos una de las dos.

• Olvidar la igualdad en el borde: si quieres incluir el límite exacto (por ejemplo, permitir x = 200), necesitas contemplarlo. Como Scratch no tiene <= o >=, puedes construirlo así:

  <(x posición) < 200> o <(x posición) = 200>

Ejemplo: “puntuación mínima” (simular >=)

Para “puntos al menos 10”, construye:

<(puntos) > 10> o <(puntos) = 10>

Si necesitas “puntos menor o igual que 10”, invierte la idea:

no <(puntos) > 10>

Nota: esta última forma incluye el 10 y todo lo menor, porque “no (puntos > 10)” equivale a “puntos ≤ 10”.

Sensores comunes para condiciones útiles

Las condiciones suelen depender de lo que el sprite “percibe”. Sensores típicos:

• Teclado: ¿tecla [espacio] presionada?

• Ratón: ¿ratón presionado?, puntero del ratón

• Colisiones: ¿tocando [SpriteX]?, ¿tocando color [ ]?, ¿color [ ] tocando [ ]?

• Distancia: distancia a [SpriteX] (se compara con < o >)

• Posición: x posición, y posición (útiles para límites de pantalla)

Guía práctica: escribir reglas claras con si y si no

Paso a paso para una regla “sin sorpresas”

• Paso 1: define la intención en una frase. Ejemplo: “Si el jugador toca un enemigo, pierde una vida; si no, sigue jugando”.

• Paso 2: elige el sensor o dato. Aquí: ¿tocando [Enemigo]?.

• Paso 3: escribe primero la condición simple y colócala en un si.

• Paso 4: añade si no solo si hay una alternativa real. Si el “si no” queda vacío o repite lo mismo, probablemente no lo necesitas.

• Paso 5: prueba casos (tocando / no tocando) y observa si el comportamiento coincide con la frase del Paso 1.

Casos típicos con ejemplos listos para armar

1) Colisiones: enemigo, moneda, obstáculo

Colisión con enemigo (vida):

si <tocando [Enemigo v]?> entonces  cambiar [vidas v] por (-1)  ir a [punto seguro v]

Colisión con moneda (puntos):

si <tocando [Moneda v]?> entonces  cambiar [puntos v] por (1)  esconder

Evitar doble conteo: si la moneda no desaparece, el condicional puede sumar muchas veces mientras siga tocando. Soluciones típicas: esconder la moneda, moverla, o usar una variable “ya cobrada”.

2) Límites de pantalla: rebotar o impedir salir

Impedir salir por la derecha (límite aproximado 240):

si <(x posición) > 230> entonces  fijar x a (230)

Rebotar en bordes (si usas el bloque de movimiento):

si <tocando borde?> entonces  rebotar si toca un borde

Ambigüedad típica: si solo corriges x pero no la dirección, el sprite puede “pegarse” al borde. Para un rebote real, además cambia dirección o usa el bloque de rebote.

3) Puntuación mínima: desbloquear puerta

Regla: “Si puntos ≥ 10 y el jugador toca la puerta, pasar de nivel”.

si < <(puntos) > 10> o <(puntos) = 10> > entonces  si <tocando [Puerta v]?> entonces  enviar [siguiente nivel v]

Mejora de legibilidad: crea una variable booleana (0/1) o un bloque personalizado “tienePuntosSuficientes” y úsalo en la condición, para no repetir comparaciones.

4) Estados de juego: menú, jugando, pausa, fin

Una forma clara de evitar acciones cuando no corresponde es condicionar por estado:

si <(estado) = [jugando]> entonces  (acciones del juego)

Ejemplo compuesto: mover solo si estás jugando y no estás tocando un obstáculo:

si < <(estado) = [jugando]> y <no <tocando [Muro v]?>> > entonces  mover (5) pasos

Tablas de verdad pequeñas para verificar tu lógica

Las tablas de verdad ayudan a comprobar si y, o y no hacen lo que esperas. Usa V (verdadero) y F (falso).

Tabla de verdad de y

Tabla de verdad de o

Tabla de verdad de no

Pruebas de casos: checklist para que el condicional responda bien

Antes de dar por terminada una regla, prueba casos concretos (como si fueran “mini tests”). Aquí tienes plantillas de pruebas típicas:

Pruebas para un rango de x

Condición: (x > -200) y (x < 200)

Pruebas para “puntos ≥ 10”

Condición: (puntos > 10) o (puntos = 10)

Pruebas para colisión + estado

Condición: (estado = jugando) y (tocando Enemigo)

Cómo evitar condiciones confusas (reglas de oro)

• Preferir positivo antes que doble negación: mejor tocando [Muro]? que no (no tocando [Muro]?).

• Nombrar variables como estados claros: estado = jugando es más legible que modo = 2.

• Separar “regla” de “acción”: primero construye y verifica la condición; luego agrega lo que sucede dentro del si.

• Tratar bordes explícitamente: decide si el límite se incluye o no y escríbelo (con = si hace falta).

• Evitar condiciones que siempre dan verdadero: si usas o, revisa si una parte ya cubre casi todos los casos.