Arquitectura de proyectos en Scratch 3: escenarios, sprites, roles y guiones legibles

Organizar un proyecto por responsabilidades

En Scratch, la claridad no depende solo de que el programa “funcione”, sino de que puedas encontrar rápidamente dónde vive cada comportamiento. Una arquitectura simple y consistente te permite: modificar sin romper, reutilizar guiones y entender el proyecto semanas después.

Qué corresponde al Escenario (Stage)

• Control global: inicio del juego, reinicios, cambio de “modo” (menú, jugando, pausa), reglas que afectan a todos.
• Fondos: selección y cambio de backdrop según el estado global.
• Música y audio ambiente: reproducción continua, volumen general, transiciones.
• Marcadores globales: variables que representan el estado del sistema (por ejemplo, nivel, tiempo, estado del juego) y que no pertenecen a un solo sprite.

Qué corresponde a cada Sprite

• Movimiento: cómo se desplaza, límites, velocidad, física simple.
• Interacción: respuesta a colisiones, clics, teclas (si son propias del sprite), y a mensajes.
• Animación: cambio de disfraces, efectos visuales, orientación.
• Sonidos locales: efectos del sprite (pasos, golpes, disparos).

Regla práctica: si un comportamiento describe “el mundo” o coordina a varios sprites, va en el Escenario; si describe “cómo actúa este personaje/objeto”, va en el sprite.

Estructura por capas: Entrada → Lógica → Salida

Para que los guiones sean legibles, organiza cada comportamiento en tres capas. No es una función formal, sino una forma de escribir guiones que se entienden.

Objetivo: que al mirar un guion puedas señalar con el dedo “qué lo activa”, “qué decide” y “qué hace”.

Plantilla de guion legible (para un sprite)

[Entrada]  cuando reciba (X) / cuando presione (tecla) / al hacer clic en este objeto
[Lógica]   decidir estado, actualizar variables, validar límites
[Salida]   mover/cambiar disfraz/sonido/mostrar u ocultar

Si la lógica crece, divide en varios guiones coordinados por mensajes o por una variable de estado (sin duplicar reglas).

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

Convenciones de nombres (para leer sin abrir cada guion)

Nombres de sprites

• Usa nombres por rol, no por “Sprite1”.
• Formato recomendado: Jugador, Enemigo_Bat, UI_Marcador, Item_Llave, FX_Chispas.
• Prefijos útiles: UI_ (interfaz), FX_ (efectos), NPC_ (personajes no controlados), Item_ (coleccionables).

Nombres de variables

• Variables globales (del proyecto): usa prefijo g_ para reconocerlas rápido: g_estadoJuego, g_nivel, g_puntos.
• Variables locales (solo del sprite): prefijo l_: l_velocidad, l_estado, l_vida.
• Evita nombres ambiguos como contador si no indican qué cuentan. Mejor: g_tiempoRestante o l_cooldownDisparo.

Nombres de mensajes

• Usa verbos y un objeto claro: Juego/Iniciar, Juego/Reiniciar, Jugador/Morir, UI/Actualizar, Nivel/Cargar.
• Si un mensaje es “orden” global, que lo emita el Escenario. Si es “evento local” (por ejemplo, el jugador recogió algo), puede emitirlo el sprite correspondiente.

Convención recomendada: separa categorías con / para agrupar mentalmente y facilitar búsqueda.

Agrupación de guiones: “bloques” visuales dentro del sprite

Scratch no tiene carpetas de guiones, pero puedes simular orden con una disposición consistente en el área de scripts.

Distribución sugerida en cada sprite

• Columna izquierda: Inicialización (todo lo que prepara el sprite).
• Centro: Comportamientos principales (movimiento, interacción, IA).
• Derecha: Efectos/animación/sonido (salida visual y audio).

Deja espacio entre grupos y alinea guiones relacionados. La legibilidad también es “diseño de pantalla”.

Separadores con comentarios

Usa comentarios como rótulos: INICIO, MOVIMIENTO, COLISIONES, ANIMACION, SONIDO. Esto reduce el tiempo de búsqueda y evita que mezcles responsabilidades.

Disfraces como estados visuales (y cómo mantener coherencia)

Un disfraz no es solo “cómo se ve”, puede representar un estado: quieto, caminando, saltando, herido, apagado/encendido, seleccionado/no seleccionado.

Regla de oro: un estado lógico debe mapear a un estado visual

• Define una variable de estado local: l_estado (por ejemplo: quieto, caminar, saltar).
• Centraliza el cambio de disfraz en un solo guion “render” o “animación”, para no cambiar disfraces desde muchos lugares.

Ejemplo de patrón (sprite Jugador)

[Entrada]  por siempre
[Lógica]   decidir l_estado según velocidad, si está en el suelo, etc.
[Salida]   si l_estado = caminar → siguiente disfraz (con ritmo)
           si l_estado = quieto → disfraz (quieto)
           si l_estado = saltar → disfraz (saltar)

Beneficio: si mañana cambias los disfraces, solo ajustas el guion de animación, no todo el proyecto.

Guía práctica paso a paso: re-arquitectura de un proyecto existente

Si ya tienes un proyecto “mezclado” (lógica repartida sin orden), usa este proceso para reorganizar sin reescribir desde cero.

Paso 1: Define el “mapa de roles”

• Lista los sprites y escribe en una frase su responsabilidad: “Jugador: se mueve y recoge”, “Enemigo_Bat: patrulla y daña”, “UI_Marcador: muestra puntos”.
• Decide qué reglas son globales y muévelas al Escenario (por ejemplo, inicio/reinicio, música, cambio de nivel).

Paso 2: Identifica entradas principales

• En el Escenario: localiza los guiones que inician el sistema y los que cambian de modo.
• En cada sprite: localiza guiones que reaccionan a mensajes o acciones del usuario.
• Renombra mensajes para que describan intención (por ejemplo, cambia mensaje1 por Juego/Iniciar).

Paso 3: Separa lógica de salida

• Busca guiones donde se mezclen decisiones con acciones visuales (por ejemplo, “si pasa X entonces cambiar disfraz y mover y sumar puntos”).
• Extrae la parte visual a un guion dedicado (animación/efectos) que lea el estado (variables) y actúe.
• Deja en el guion principal la actualización de variables y el envío de mensajes.

Paso 4: Centraliza estados

• Para cada sprite, define 1 variable de estado principal (l_estado) si tiene comportamientos distintos.
• Para el proyecto, define 1 variable de modo global (g_estadoJuego) si hay pantallas o fases.
• Evita tener “muchas banderas” que se contradicen (por ejemplo, saltando y enSuelo mal sincronizadas). Si existen, decide cuál manda y elimina duplicados.

Paso 5: Reduce duplicación con guiones reutilizables

• Si varios sprites hacen lo mismo (por ejemplo, “aparecer al iniciar” o “resetear posición”), considera un mensaje global Juego/Reiniciar y que cada sprite responda con su propio reset.
• Si un mismo sprite repite bloques idénticos en varios guiones, crea un bloque personalizado (si lo estás usando en tu curso) o reestructura para que un solo guion sea el responsable.

Paso 6: Ordena físicamente los guiones

• Agrupa por secciones con comentarios.
• Coloca arriba lo que “enciende” al sprite (inicialización), al centro lo que “piensa” (lógica), y a la derecha lo que “muestra” (salida).

Patrones de arquitectura recomendados (Stage + sprites)

Patrón A: El Escenario como “director”

• El Escenario emite Juego/Iniciar, Juego/Pausa, Juego/Reiniciar.
• Cada sprite implementa su respuesta: reset, mostrar/ocultar, detener movimiento, etc.
• Ventaja: un solo lugar para entender el flujo global.

Patrón B: UI desacoplada

• Sprites de UI (por ejemplo UI_Marcador) no calculan puntos: solo leen g_puntos y muestran.
• El cálculo de puntos ocurre donde sucede la acción (jugador/enemigo/escenario), actualizando la variable global.

Patrón C: Animación como “render loop” local

• Un guion por siempre decide el disfraz según l_estado.
• Otros guiones solo cambian l_estado, no disfraces directamente.

Lista de verificación de claridad (auditoría rápida)

• Ausencia de duplicación: ¿hay bloques idénticos copiados en varios lugares? Si sí, ¿pueden centralizarse con un mensaje, un guion único o una variable de estado?
• Responsabilidades claras: ¿el Escenario solo hace control global y no “maneja” movimiento de sprites específicos? ¿cada sprite controla su propio movimiento e interacción?
• Coherencia de estados: ¿existe una fuente de verdad para el modo global (g_estadoJuego) y para el estado del sprite (l_estado)? ¿evitas banderas contradictorias?
• Trazabilidad: para cada comportamiento visible (por ejemplo “el jugador salta”, “aparece un enemigo”, “cambia el fondo”), ¿puedes responder rápido: qué lo dispara (entrada), qué regla decide (lógica) y qué acción ocurre (salida)?
• Mensajes con intención: ¿los nombres de mensajes describen acciones y no números? ¿se entiende quién debería emitirlos?
• Nombres autoexplicativos: ¿sprites, variables y mensajes se entienden sin abrir guiones? ¿evitas Sprite2, var1, mensaje1?
• Guiones agrupados: ¿hay secciones con comentarios y espacio visual? ¿puedes localizar “inicio”, “movimiento”, “animación” en segundos?
• Disfraces como estados: ¿los cambios de disfraz están centralizados y dependen de un estado lógico, en lugar de estar repartidos por todo el sprite?