Una aplicación interactiva no es una página con un botón. Es un programa que, varias veces por segundo, mira el estado, incorpora lo que ha hecho la persona y vuelve a pintar. Ese ciclo es el bucle de juego. En el avisador serio, loop hacía leer el sensor, comparar y escribir el pin. Aquí loop hace mover la lectura, mirar la cesta y sumar si toca. El propósito es lúdico, que es lo que pide el criterio 3.1, y por debajo sigue estando el si de siempre.
El estado es lo que el programa necesita recordar entre un fotograma y el siguiente: posición de la lectura, posición de la cesta, puntos, intentos, umbral. Si un dato no está en el estado y hace falta para la regla, el juego lo está inventando en el dibujo y no podrás trazarlo. La meta y la velocidad viven en el editor para que cambiar la dificultad sea cambiar un número, no reescribir el canvas.
Las flechas y los botones mueven la cesta. Eso es una entrada, como el pulsador. No es el sensor de luz: la luz de la partida es ficticia y depende de la posición, para que haya valores por encima y por debajo del umbral sin un LDR. Conviene decirlo en la memoria para no vender el juego como un medidor del patio. Es un simulador con regla verdadera y dato inventado.
La regla: si la cesta atrapa el punto y la luz de ese punto es menor que el umbral, el marcador sube. El LED dibujado se enciende cuando la luz actual está bajo el umbral, aunque no la atrapes: es el avisador, dentro del juego. El marcador es otra salida, lúdica. Mezclarlas («solo se ve el LED si además sumas punto») hace el ensayo imposible, porque no sabes si falló la condición o la cesta.
El canvas se pinta muchas veces. No se «avanza» con un para de cuatro vueltas: se pide el siguiente fotograma y se vuelve a entrar. Es un mientras que termina cuando llegas a la meta o se acaban los intentos. El corte está escrito. Un juego sin fin posible no es más divertido: es el bucle sordo de la lección 26 con mejor color.
En una UNO, la cesta sería un potenciómetro o dos botones en otros pines, y la luz volvería a ser analogRead(A0). digitalWrite(13, HIGH) sustituiría al círculo rojo. La puntuación podría ir por el puerto serie al ordenador, que aquí no abrimos. En la Pi, la cesta sería un par de GPIO de entrada y el LED el 18. El bucle sería while True con una pausa corta, y el riesgo de bloqueo es el mismo de siempre. Esta página no da ese salto: te deja comprobar que la regla es jugable antes de pedir la placa.
No es una web de un motor externo, ni un iframe de otra unidad, ni una puntuación publicada. El criterio se demuestra con la interactividad de aquí: cambias el umbral, juegas, y el comportamiento cambia. Si la meta es 5 y no hay manera de sumar, la regla está rota aunque el punto se mueva. El movimiento sin regla es un salvapantallas.
Prueba primero con velocidad baja y umbral 500. Cuenta cuántos aciertos son de verdad «luz baja» y no solo «he tocado el punto». Esa frase en el cuaderno vale más que una captura del marcador a 5, porque enseña que has mirado la condición y no solo el reflejo.
Bucle de juego. Repetir: actualizar, decidir, dibujar, hasta la meta o el fallo.
Estado. Lo que se recuerda entre fotogramas.
Entrada. El gesto de la persona. Aquí, la cesta.
Regla. La condición que cambia puntos o pin. Si se quita, no queda programa.
Vista. El canvas. Obedece al estado y no es la única copia de los datos.
Meta. Condición de fin lúdica. Sin ella, el mientras no está justificado.
Dato ficticio. La luz que depende de la posición. Se declara, no se hace pasar por el patio.
Paralelo de placa. D13 o GPIO 18 harían de LED; otros pines, de cesta. No están conectados.
Se otorga acierto en cada captura, sin mirar el umbral. El juego es más fácil y ya no demuestra el si. Se vuelve a exigir luz < umbral.
let velocidad = "3". El movimiento deja de ser numérico. Se quitan las comillas.
El grupo quita la condición de fin para «practicar más». No hay manera de terminar ni de saber si la regla basta. Se deja una meta pequeña, por ejemplo 5.
Cada caso es una entrega del avisador del patio del IES Duero (Aranda de Duero). Lee la situación antes de la decisión.
Situación. El punto rebota y no hay marcador ni umbral.
No conviene. Porque se mueve y eso ya es interactivo.
Decisión. Dejar la condición del umbral unida al acierto y un fin de partida.
Por qué: Que el punto rebote no basta: moverse es la vista. El criterio pide una regla que la persona pueda cambiar y notar, con umbral y marcador. Sin esa condición, el fotograma es un adorno en bucle.
Situación. Enviar la puntuación a un formulario.
No conviene. Para que el grupo compita de verdad.
Decisión. Anotar el récord en el cuaderno o en una variable de la página, que se pierde al cerrar y no pasa nada.
Por qué: Enviar la puntuación a un formulario abre cuenta, red y datos personales que no son el tema, y el curso es local. El récord se anota en el cuaderno o se queda en la página. Un récord remoto no hace más interactiva la regla.
Situación. El círculo se enciende al llegar a la meta, no cuando la luz es baja.
No conviene. Porque el final queda más claro.
Decisión. Encender el LED del canvas con la comparación, y usar el marcador para la meta.
Por qué: Encender el círculo al llegar a la meta, y no cuando la luz es baja, cambia el significado del LED. Si significa «he ganado», ya no se puede comparar con el GPIO del avisador. Son dos salidas, y las dos caben si no se pisan.
Situación. Intentar que el navegador abra el USB de la UNO.
No conviene. Porque así la partida sería real.
Decisión. Dejar escrito el paralelo (D13, GPIO 18) y no abrir ningún puerto desde la página.
Por qué: El navegador no es el IDE. Intentar que abra el USB de la UNO pide drivers y permisos, y se sale de este módulo. Se deja escrito el paralelo (D13, GPIO 18) y no se abre ningún puerto desde la página.
El problema no cambia: si la luz del patio del IES Duero baja de 500, hay que avisar. Cambia quién ejecuta. El pseudocódigo lo ejecuta el laboratorio de esta página. El sketch lo compilaría el IDE de Arduino hacia la UNO. El fragmento de Python lo ejecutaría una Raspberry Pi con gpiozero, si hubiera placa. Aquí no hay placa.
Son el estado inicial de la dificultad. El bucle de juego las lee al pulsar Jugar.
let umbral = 500
let velocidad = 3
let meta = 5
Misma comparación. La puntuación no existe en la placa salvo que la envíes a algún sitio, y aquí no se envía.
void loop() {
int luz = analogRead(A0);
digitalWrite(13, luz < umbral ? HIGH : LOW);
// la cesta serían dos botones en otros pines
}
Dos si, no uno solo: puntos y LED no son la misma salida.
# dentro de un bucle con fin
if luz < umbral and cesta_bajo_el_punto:
puntos += 1
if luz < umbral:
led.on() # GPIO 18
else:
led.off()
| Dato | ¿Estado? | Si se quita |
|---|---|---|
| umbral | sí | el acierto ya no tiene regla |
| velocidad | sí | el ensayo se vuelve injugable o trivial |
| meta | sí | la partida no sabe terminar |
| color del fondo | no, es vista | la regla sigue intacta |
| luz ficticia | sí, y se declara | nadie puede trazar el si |
Si un dato está solo en el color, no es estado. El fondo puede cambiar sin tocar el programa del avisador. El umbral, no.
Juega una partida con umbral 200 y otra con 800. Con 200 casi no hay aciertos, porque pocas lecturas ficticias quedan tan bajas; con 800 casi todo vale. Esa diferencia es la demostración de que la condición manda. Anótala.
Para la cesta a media pantalla y deja que fallen los intentos. Tiene que poder acabar la partida. Si no acaba, la meta o las vidas no están en el ciclo y el mientras es el de la lección 26, el que no queríamos.
Escribe en cuatro líneas el bucle de juego con las palabras estado, entrada, regla y vista, y marca cuál de ellas cambiarías si el LED fuera de verdad el pin 13. Solo debería cambiar la salida física, no la regla del umbral.
| Criterio | Aún no | En proceso | Conseguido | Notable |
|---|---|---|---|---|
| Ciclo | Una imagen fija | Se mueve solo | Hay entrada, regla y fin | Se explica el fotograma |
| Regla | Suma siempre | Umbral decorativo | El acierto exige luz baja | LED y puntos no se confunden |
| Editor | Números mágicos en la cabeza | Se cambian a ciegas | umbral, velocidad y meta | Una frase dice qué pasa al cambiarlos |
| Fin | Interminable | Se cierra la pestaña | Meta o intentos | Se puede repetir la partida |
| Hardware | Promete la UNO | No lo nombra | D13 y GPIO 18 como paralelo | La luz del juego se declara ficticia |
El juego es el avisador con cesta, fotogramas y una meta. La regla sigue siendo la comparación. El canvas no sustituye al umbral.
Abre cada pregunta, responde en el cuaderno y después mira la solución. El párrafo «Por qué» es la parte que se estudia.
Respuesta. Porque no hay una regla que una la entrada de la persona con una decisión. Solo hay una vista.
Por qué: El criterio 3.1 pide un programa interactivo. La interactividad sin alternativa (siempre pasa lo mismo cuando tocas o no tocas) no usa las estructuras de control. El umbral es lo que convierte el reflejo en un si.
Respuesta. Que es ficticia y depende del movimiento, no de un LDR conectado.
Por qué: Si no se dice, el juego parece un medidor y la evaluación se sostiene en un dato que no existe. El paralelo con analogRead se explica aparte, como lo que habría que cambiar para salir de la simulación.
Respuesta. No necesariamente. Son dos salidas distintas: la regla de la luz ficticia y la mano.
Por qué: Mal estaría si no pudieras decir cuál de las dos estás mirando. Depurar aquí es señalar la variable o la regla, no dar por rota la página porque el dibujo y el interruptor no van a la vez.
En la vida real
Escribes y dibujas aquí mismo: no hay salto a otro módulo. La misma herramienta, a pantalla completa, está en l30-aplicacion-interactiva-ludica.html y en el marco (útil si el navegador permite file:// en iframes).
Ajusta umbral, velocidad y meta, juega al menos una partida completa y anota el resultado junto con el umbral usado. Explica un acierto que no debas contar si la luz del punto estaba por encima. En el cuaderno, di qué pin sería el LED en la UNO y cuál en la Pi, y que desde esta página no se ha abierto. Una buena entrega puede repetir la partida sin red.
reto_id: bach1-tic-L30