Variables en Scratch 3: estado del sistema y reglas de actualización

Variable = memoria del proyecto (estado del sistema)

En Scratch, una variable es un espacio de memoria que guarda un valor (número o texto) para representar el estado de tu juego o animación: puntos, tiempo restante, vidas, nivel, energía, monedas, etc. Pensarla como “memoria” te ayuda a responder tres preguntas clave:

• ¿Qué representa? (significado)
• ¿Cuándo cambia? (reglas de actualización)
• ¿Quién la modifica? (qué sprite o parte del proyecto la escribe)

Una variable bien diseñada tiene un significado claro y reglas de actualización consistentes. Si no, aparecen errores típicos: valores que no se reinician, contadores que suben de más o estados que cambian desde el sprite equivocado.

Variables globales vs variables “solo para este sprite”

Globales (para todos los sprites)

Se usan cuando el valor representa el estado del proyecto completo o debe ser compartido por varios sprites. Ejemplos típicos:

• Puntuación (la ven y la modifican varios sprites: jugador, enemigos, objetos)
• Nivel (cambia al completar objetivos y afecta a todo)
• Tiempo o temporizador (condiciona el final de la partida)

Por sprite (solo para este sprite)

Se usan cuando el valor describe el estado interno de un personaje u objeto y no tiene sentido que otros lo modifiquen directamente. Ejemplos:

• Energía o vida de un enemigo concreto
• Munición del jugador (si solo el jugador la cambia)
• Estado de un sprite: “atacando”, “invulnerable”, “cargando” (a menudo se guarda como texto o número)

Cómo elegir según el significado

Regla práctica: si te molesta que “cualquier sprite” pueda cambiarla, probablemente debe ser “solo para este sprite”. Si varios sprites necesitan leerla y tiene sentido que la actualicen, probablemente es global.

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

Patrones esenciales: inicializar, actualizar, leer

1) Inicialización al comenzar (reinicio del estado)

La inicialización define el valor “correcto” al empezar una partida o escena. Si no inicializas, el proyecto puede “recordar” valores de ejecuciones anteriores.

Checklist de inicialización:

• ¿Qué variables deben empezar en 0? (puntos, monedas)
• ¿Qué variables deben empezar en un valor fijo? (vidas = 3, nivel = 1)
• ¿Qué variables dependen de la dificultad? (tiempo = 60 o 30)

Ejemplo de bloque (conceptual):

al presionar bandera verde  set [puntos v] a (0)  set [vidas v] a (3)  set [nivel v] a (1)

2) Actualización en eventos (reglas de cambio)

Actualizar una variable significa cambiarla con una regla clara: “cuando ocurre X, entonces cambia Y”. No se trata de “subir puntos en cualquier parte”, sino de elegir un lugar lógico para cada actualización.

Reglas típicas:

• Colisión con objeto → sumar puntos
• Recibir daño → restar energía/vidas
• Completar objetivo → subir nivel
• Cada segundo → disminuir tiempo

3) Lectura en condicionales (decidir según el estado)

Leer una variable es usar su valor para tomar decisiones: “si vidas = 0, termina”; “si puntos ≥ 100, sube de nivel”. La lectura no cambia la variable; solo consulta el estado.

Ejemplos de lecturas típicas:

• si <(vidas) = (0)> entonces …
• si <(puntos) >= (100)> entonces …
• si <(tiempo) <= (0)> entonces …

Ejemplo 1: Contador de puntos (global)

Objetivo

Sumar 10 puntos cuando el jugador recoge una moneda y evitar sumar varias veces por la misma moneda.

Paso a paso

• Crear variable global: puntos.
• Inicializar al comenzar: set [puntos v] a (0).
• Actualizar en el sprite “Moneda” cuando el jugador la toca.

Guía de bloques (en el sprite Moneda):

al presionar bandera verde  mostrar  por siempre    si <tocando [Jugador v]?> entonces      cambiar [puntos v] por (10)      esconder      esperar (0.2) segundos    end  end

Idea clave: la moneda es quien “sabe” que fue recogida, por eso es un buen lugar para sumar puntos. El esperar ayuda a evitar dobles sumas por contacto continuo (otra opción es esconder inmediatamente y ya no puede volver a tocarse).

Errores típicos y cómo pensarlos

• Los puntos suben sin parar: la condición se cumple muchas veces porque la moneda sigue visible o el bloque se ejecuta repetidamente sin “consumir” la moneda.
• Los puntos no se reinician: falta inicialización al comenzar.

Ejemplo 2: Temporizador (global) como “tiempo restante”

Objetivo

Empezar con 30 segundos y restar 1 cada segundo hasta llegar a 0.

Paso a paso

• Crear variable global: tiempo.
• Inicializar: set [tiempo v] a (30).
• Actualizar con una regla temporal: cada 1 segundo, restar 1.
• Leer para decidir fin de partida: si tiempo = 0, detener o cambiar escena.

al presionar bandera verde  set [tiempo v] a (30)  repetir hasta que <(tiempo) = (0)>    esperar (1) segundos    cambiar [tiempo v] por (-1)  end

Regla de diseño: si tu variable representa “tiempo restante”, su actualización debe ser regular y predecible. Evita restarla en varios sprites a la vez (haría que baje demasiado rápido).

Ejemplo 3: Vidas (global) + daño por colisión

Objetivo

El jugador empieza con 3 vidas. Si toca a un enemigo, pierde 1 vida y se reposiciona. Si vidas llega a 0, se termina la partida.

Paso a paso

• Crear variable global: vidas.
• Inicializar: set [vidas v] a (3).
• Actualizar en el sprite Jugador cuando toca al enemigo (el jugador “recibe” el daño).
• Leer para decidir el final.

al presionar bandera verde  set [vidas v] a (3)  por siempre    si <tocando [Enemigo v]?> entonces      cambiar [vidas v] por (-1)      ir a x:(0) y:(0)      esperar (0.5) segundos    end    si <(vidas) <= (0)> entonces      detener [todo v]    end  end

Nota de lógica: el esperar funciona como “tiempo de invulnerabilidad” simple para evitar perder varias vidas en un solo contacto continuo.

Ejemplo 4: Nivel (global) como regla de progreso

Objetivo

Subir de nivel cuando los puntos alcanzan un umbral y ajustar la dificultad.

Paso a paso

• Crear variable global: nivel.
• Inicializar: set [nivel v] a (1).
• Leer puntos para decidir si sube el nivel.
• Actualizar nivel una sola vez por umbral (evitar subir muchos niveles en un instante).

Patrón recomendado: usar umbrales por nivel.

al presionar bandera verde  set [nivel v] a (1)  por siempre    si <(puntos) >= (100)> entonces      set [nivel v] a (2)    end    si <(puntos) >= (200)> entonces      set [nivel v] a (3)    end  end

Si además quieres que el nivel “se dispare” una sola vez con un mensaje, puedes separar: (1) detectar cambio de nivel, (2) anunciarlo. Por ejemplo, guardar nivelAnterior y comparar, para no repetir acciones cada ciclo.

Reglas de actualización: “un dueño” y “un lugar”

Muchos bugs de variables aparecen porque varios scripts modifican la misma variable sin coordinación. Dos reglas prácticas:

• Un dueño: decide qué sprite o script es responsable de escribir la variable.
• Un lugar: intenta que cada variable se actualice en un único punto lógico (o en pocos puntos muy controlados).

Ejemplo: puntos puede ser global, pero solo se incrementa en los objetos que se recogen o en el sistema de “recompensas”, no en cualquier parte.

Guía práctica: diseñar una variable desde cero

Paso 1: definir el significado con una frase

Completa: “La variable X representa ________”.

• puntos representa el total acumulado por acciones del jugador.
• energia representa la resistencia actual del personaje.

Paso 2: decidir el alcance (global o por sprite)

Pregunta: “¿Debe ser compartida por varios sprites?” Si sí, global. Si no, por sprite.

Paso 3: escribir la regla de inicialización

Completa: “Al comenzar, X vale ________”.

Paso 4: escribir 1–3 reglas de actualización

Completa: “Cuando ocurre ________, entonces X cambia a ________”.

• Cuando recojo moneda, puntos cambia por +10.
• Cuando me golpean, vidas cambia por −1.
• Cada segundo, tiempo cambia por −1.

Paso 5: decidir reglas de lectura (condiciones)

Completa: “Si X cumple ________, entonces pasa ________”.

• Si vidas ≤ 0, termina la partida.
• Si puntos ≥ 200, nivel = 3.

Actividades de depuración conceptual (errores de estado)

Actividad 1: “No se reinicia”

Situación: ejecutas el proyecto, consigues 50 puntos, paras y vuelves a iniciar, y los puntos siguen en 50.

Diagnóstico: falta una inicialización clara al comenzar.

Tarea: localiza dónde debería estar el reinicio de puntos y añade el bloque de inicialización. Luego verifica que no exista otro script que vuelva a cambiar puntos inmediatamente.

Actividad 2: “Se actualiza en el lugar incorrecto”

Situación: el enemigo resta vidas al jugador, pero también el jugador resta vidas en otro script, y a veces pierdes 2 vidas por un solo golpe.

Diagnóstico: dos dueños modifican vidas.

Tarea: elige un único dueño (por ejemplo, el Jugador) para restar vidas. En el otro sprite, reemplaza la resta directa por una señal (por ejemplo, un aviso) y deja que el Jugador haga la actualización.

Actividad 3: “Se incrementa demasiadas veces”

Situación: al tocar una moneda, los puntos suben 10, 20, 30… muy rápido.

Diagnóstico: la condición de toque se evalúa repetidamente mientras el sprite sigue tocando.

Tarea: aplica una de estas correcciones: (1) esconder la moneda tras sumar, (2) añadir un pequeño tiempo de espera, (3) mover la moneda a otra posición tras sumar.

Actividad 4: “El nivel no coincide con los puntos”

Situación: llegas a 200 puntos pero el nivel sigue en 1.

Diagnóstico: la lectura de puntos para actualizar nivel no se ejecuta, o se ejecuta en un sprite que no está activo, o el umbral está mal escrito.

Tarea: coloca temporalmente el monitor de variables en pantalla (mostrar variable) y revisa: (1) si puntos realmente llega a 200, (2) si el script que ajusta nivel está corriendo, (3) si la condición usa >= y no =.