Código y Fortuna: El Casino de la Lógica
Justificación
Esta situación de aprendizaje sumerge al alumnado de 3º de ESO en el mundo de la probabilidad y el pensamiento computacional a través del diseño de sistemas de azar digitales. En una sociedad donde los algoritmos de decisión y el juego digital están presentes, es vital que el alumnado comprenda la lógica subyacente y la programación que los sustenta. Siguiendo la LOMLOE y el Decreto 102/2023 de Andalucía, se busca desarrollar la competencia digital y el sentido crítico, transformando al estudiante de consumidor pasivo a creador de tecnología mediante el diseño de un simulador de juegos de azar basado en lógica matemática.
Fundamentación Curricular
La propuesta se fundamenta en los criterios de evaluación 5.1, enfocado en el diseño de algoritmos y diagramas de flujo para resolver problemas; 5.2, centrado en la programación de aplicaciones sencillas; y 6.2, relativo a la creación y difusión de contenidos digitales. Estos criterios se vinculan con los saberes básicos del bloque C (Pensamiento computacional, programación y robótica), específicamente TYD.3.C.1 sobre aplicaciones informáticas y TYD.3.C.3 sobre la depuración de errores, así como el bloque D (Digitalización), integrando la creación de contenidos responsables (TYD.3.D.2).
Metodología
Se emplea el Aprendizaje Basado en Proyectos (ABP) combinado con el Pensamiento Computacional. El alumnado trabajará en parejas para desarrollar un prototipo funcional. Se utilizará el andamiaje cognitivo para pasar del lenguaje natural al diagrama de flujo y, finalmente, al código bloque. Se fomentará el aprendizaje por descubrimiento guiado durante la fase de depuración (debugging), utilizando la técnica de 'programación por parejas' (pair programming) para potenciar la colaboración y el intercambio de roles entre conductor y navegante.
Atención a la Diversidad
Se aplican principios DUA para garantizar la inclusión. Para la representación, se ofrecen tutoriales en vídeo, guías visuales y ejemplos de código comentados. Para la acción y expresión, el alumnado puede elegir entre diferentes entornos de programación (Scratch, MakeCode o Python básico) y diversos tipos de juegos (dados, ruleta, cartas). Para la implicación, se proponen retos de distinta complejidad (niveles de dificultad en el juego) y se permite la personalización estética del producto final, asegurando que todo el alumnado alcance los criterios mínimos mediante tareas multinivel.
Instrumentos de Evaluación
La evaluación es procesual y competencial, centrada en la rúbrica como instrumento integrador. Se realizará una observación sistemática del trabajo en el aula para evaluar la capacidad de resolución de problemas y la lógica algorítmica. El producto final (el simulador) y su documentación técnica se evaluarán mediante los niveles de logro definidos en la rúbrica, que desglosa los criterios de programación, diseño de interfaz y coherencia lógica. Se incluye la coevaluación entre pares durante la fase de pruebas para fomentar el espíritu crítico y la mejora continua.
Recursos y Materiales
Dispositivos digitales (Chromebooks o portátiles), conexión a internet, entorno de programación por bloques (Scratch o similar), herramientas de diseño gráfico (Canva o Genially) para la interfaz, pizarra digital interactiva para modelado de diagramas, y cuadernos de equipo para el diseño previo de algoritmos.
Conexiones Interdisciplinares
La SDA conecta directamente con Matemáticas (3º ESO) en el bloque de Probabilidad y Estadística, al calcular las posibilidades de éxito en los juegos diseñados. También se vincula con Educación Plástica, Visual y Audiovisual en lo referente al diseño de interfaces y experiencia de usuario (UX), y con Lengua Castellana y Literatura mediante la redacción de las instrucciones y la documentación técnica del proyecto.
Recursos de Gamificación
- Scratch: El Motor del Azar (herramienta_digital) - Scratch: Plataforma principal para programar la lógica de los juegos y generar números aleatorios.
- Diagrams.net para Lógica (recurso_web) - App.diagrams.net: Herramienta para crear los diagramas de flujo previos a la programación de los juegos.
- Kahoot de Lógica Proposicional (juego) - Kahoot: Cuestionario inicial para repasar conceptos de condicionales (Si... entonces) y bucles.
Rúbrica General
| Criterio | Insuficiente | Suficiente | Notable | Sobresaliente |
|---|---|---|---|---|
| Diseño de algoritmos y diagramas de flujo (Criterio 5.1) | No logra representar la secuencia lógica del juego o el diagrama de flujo es incoherente con el funcionamiento esperado. | Diseña diagramas de flujo básicos que representan la lógica del azar, aunque presentan errores menores en la simbología o pasos secundarios. | Crea diagramas de flujo claros y estructurados que resuelven eficazmente la lógica del juego, incluyendo condicionales correctamente planteados. | Diseña algoritmos optimizados y diagramas de flujo profesionales que contemplan todas las variables y excepciones del juego de azar. |
| Programación y control de aplicaciones (Criterio 5.2) | El código no funciona o no integra correctamente la generación de números aleatorios para el azar. | Programa una aplicación funcional donde el azar actúa correctamente, aunque el código es redundante o poco organizado. | Desarrolla un programa eficiente con una estructura de bloques clara, utilizando variables y operadores lógicos de forma adecuada. | Programa una aplicación compleja con una lógica impecable, incluyendo niveles, contadores de puntos y una gestión avanzada de eventos. |
| Creación de contenidos y difusión (Criterio 6.2) | La interfaz del juego es confusa y no incluye instrucciones de uso ni documentación técnica básica. | Crea una interfaz funcional y presenta la documentación técnica con los elementos mínimos requeridos por el docente. | Diseña una interfaz atractiva y elabora documentación técnica detallada utilizando herramientas digitales de forma eficaz. | Produce un contenido digital de alta calidad estética y técnica, con instrucciones claras y una presentación creativa del proyecto. |
Sesión 1: La Arquitectura del Azar
Duración: 50 minutos
Objetivos
Analizar juegos de azar comunes y diseñar el diagrama de flujo que rige su funcionamiento lógico.
Actividades de Inicio (~10 min)
La sesión comienza con la proyección de un breve vídeo sobre la evolución de las máquinas de azar, desde las mecánicas hasta las digitales. Tras el vídeo, se realiza una lluvia de ideas dirigida mediante la pregunta: ¿Qué decide realmente si ganas o pierdes en un juego digital? El profesor introduce el concepto de algoritmo como la 'arquitectura invisible' del casino. Se presentan los objetivos de la sesión: desglosar un juego en pasos lógicos y representarlo visualmente mediante un diagrama de flujo, preparando el terreno para la futura programación.
Actividades de Desarrollo (~35 min)
Los alumnos, organizados en parejas bajo la metodología de 'programación por parejas' (roles de conductor y navegante), eligen un juego de azar sencillo de una lista propuesta (Dados, Cara o Cruz, o El Número Secreto). La actividad se divide en tres fases de andamiaje: 1. Descomposición: Redactar las reglas del juego en lenguaje natural (paso a paso). 2. Identificación: Señalar dónde interviene el azar (entrada de datos) y dónde se toma una decisión (condicionales). 3. Modelado: Dibujar el diagrama de flujo del juego utilizando simbología estándar (óvalos para inicio/fin, rectángulos para procesos y rombos para decisiones). El navegante supervisa la lógica global mientras el conductor dibuja el esquema, intercambiando roles a mitad de la actividad.
Actividades de Cierre (~10 min)
Se realiza una 'galería de algoritmos' donde cada pareja muestra su diagrama de flujo al resto de la clase. Se dedica un tiempo a la reflexión sobre los 'bucles' o caminos infinitos que podrían romper el juego. Los alumnos completan una breve diana de autoevaluación digital sobre su capacidad para identificar condiciones lógicas. Finalmente, el profesor anticipa que en la próxima sesión esos diamantes de decisión se convertirán en bloques de código real.
Recursos
Pizarra digital interactiva, dispositivos portátiles o tablets, software de diagramación en línea (como Draw.io o Lucidchart), fichas de apoyo con la simbología de diagramas de flujo y ejemplos de estructuras condicionales simples.
Atención a la Diversidad (DUA)
Para la representación, se proporcionan tarjetas físicas con los símbolos de los diagramas para alumnos que requieran apoyo táctil y visual. Para la acción y expresión, se permite el diseño del diagrama tanto en formato digital como en papel de gran formato. Para la implicación, se ofrece autonomía en la elección del juego a analizar, permitiendo que los alumnos conecten con sus propios intereses lúdicos.
Competencia Digital
Se integra mediante el uso de herramientas de creación de contenidos digitales (CD2.1) para elaborar el diagrama de flujo y la búsqueda de información técnica sobre reglas de juegos (CD1.1). Se fomenta la comunicación y colaboración mediante el uso de entornos virtuales compartidos (CD3.1).
Rúbrica de la Sesión
| Criterio | Insuficiente | Suficiente | Notable | Sobresaliente |
|---|---|---|---|---|
| Análisis de la lógica del azar | No identifica correctamente los puntos de decisión ni dónde interviene el azar en el juego elegido. | Identifica los elementos básicos del juego pero confunde procesos con decisiones lógicas. | Analiza con precisión la secuencia del juego, diferenciando claramente entre azar, entrada de datos y resultados. | Realiza un análisis exhaustivo, previendo situaciones de error o casos excepcionales en la lógica del juego. |
| Construcción del diagrama de flujo | El diagrama es confuso, no utiliza la simbología estándar o carece de una secuencia lógica coherente. | Utiliza la simbología básica de forma correcta, aunque el flujo presenta algunas lagunas o saltos ilógicos. | Construye un diagrama fluido y bien estructurado que representa fielmente las reglas del juego propuesto. | Elabora un diagrama profesional, optimizado, con uso impecable de la simbología y una estructura lógica impecable. |
| Colaboración y roles (Pair Programming) | No se observa intercambio de roles ni colaboración efectiva; un miembro asume todo el trabajo. | Reparten las tareas pero no intercambian los roles de conductor y navegante de manera fluida. | Colaboran activamente, respetando los turnos y aportando soluciones conjuntas a los problemas lógicos. | Demuestran una sincronía total en el trabajo por parejas, enriqueciendo el diseño final mediante el diálogo constante. |
Sesión 2: Forjando la Suerte
Duración: 50 minutos
Objetivos
Implementar la lógica de aleatoriedad y variables en el entorno de programación seleccionado.
Actividades de Inicio (~10 min)
Iniciamos con el reto 'El Dado Invisible'. El docente lanza un dado físico y pide a la clase que prediga el resultado. Tras esto, se plantea la pregunta: ¿Cómo podemos hacer que una máquina, que es puramente lógica, tome una decisión al azar? Se recuperan los esquemas de la sesión anterior para identificar dónde encajaría el generador de números. Se presentan los objetivos: crear una variable 'suerte' y asignarle un valor aleatorio entre 1 y 6, simulando el azar del casino.
Actividades de Desarrollo (~35 min)
Los alumnos, organizados por parejas de 'programación por pares' (conductor y navegante), acceden al entorno de programación (Scratch o MakeCode). 1. Creación de variables: Deben definir la variable 'puntos' y 'resultado_dado'. 2. Lógica de aleatoriedad: Utilizando el bloque de operadores 'elegir número al azar', deben programar que al pulsar un objeto o tecla, la variable cambie su valor. 3. Feedback visual: Programarán que el personaje diga el resultado o cambie de disfraz según el número obtenido. El docente realiza andamiaje mediante la técnica de 'pausa de depuración', donde se detiene la clase para resolver un error común detectado en la lógica de los bloques.
Actividades de Cierre (~10 min)
Sesión de 'Debugging Compartido': Una pareja voluntaria proyecta su código y explica un problema que hayan tenido con la variable y cómo lo solucionaron. Se realiza una breve autoevaluación mediante un formulario digital rápido (Mentimeter o Google Forms) sobre la función de las variables. Se anticipa que en la siguiente sesión usaremos estos números para decidir si el jugador gana o pierde (condicionales).
Recursos
Ordenadores con conexión a internet, entorno de programación por bloques (Scratch/MakeCode), proyector interactivo, tarjetas de rol para Pair Programming (Conductor/Navegante), guía visual de bloques de variables y operadores.
Atención a la Diversidad (DUA)
Múltiples medios de representación: Se entrega una 'hoja de ruta' visual con capturas de los bloques necesarios. Múltiples medios de acción: El alumnado puede elegir entre programar un dado, una ruleta o una moneda. Múltiples medios de implicación: Se permite la personalización estética de los objetos del casino para aumentar el interés personal.
Competencia Digital
Se trabaja la CD2.2 (Creación de contenidos: programación) al desarrollar el algoritmo, y la CD5.2 (Resolución de problemas) mediante la identificación y corrección de errores en la asignación de valores a las variables en el entorno digital.
Rúbrica de la Sesión
| Criterio | Insuficiente | Suficiente | Notable | Sobresaliente |
|---|---|---|---|---|
| Uso de Variables | No logra crear ni nombrar variables de forma coherente con el proyecto. | Crea la variable necesaria pero presenta dificultades para asignarle valores correctamente. | Crea y utiliza variables adecuadamente, integrándolas en el flujo del programa. | Gestiona múltiples variables con nombres precisos y las inicializa correctamente al empezar el programa. |
| Implementación de Aleatoriedad | No utiliza bloques de azar o los usa de forma que no afectan al resultado del programa. | Utiliza el bloque de número aleatorio pero con rangos incorrectos o sin asignarlo a una variable. | Implementa la lógica de aleatoriedad correctamente dentro del rango solicitado (1-6). | Aplica la aleatoriedad de forma creativa para generar diferentes eventos o respuestas en el programa. |
| Colaboración (Pair Programming) | No respeta los turnos de conductor/navegante o uno de los miembros no participa. | Trabajan juntos pero les cuesta intercambiar roles o comunicarse de forma efectiva. | Intercambian roles de forma fluida y colaboran en la resolución de errores lógicos. | Demuestran una coordinación perfecta, apoyándose mutuamente en el debugging y compartiendo estrategias. |
Sesión 3: Interfaz y Experiencia
Duración: 50 minutos
Objetivos
Diseñar los elementos visuales del juego y realizar pruebas de depuración (debugging) del código.
Actividades de Inicio (~10 min)
Presentación de capturas de pantalla de interfaces de juegos clásicos y modernos para analizar la jerarquía visual y la usabilidad. Se realiza un diálogo dirigido mediante preguntas potentes: ¿Cómo sabe un jugador que ha ganado sin leer texto? ¿Qué colores asociamos al peligro o al éxito? El objetivo es activar conocimientos previos sobre diseño de interfaces (UI) y experiencia de usuario (UX), vinculándolos con la lógica de programación establecida en la sesión anterior.
Actividades de Desarrollo (~35 min)
Los estudiantes trabajan en parejas utilizando la técnica de 'pair programming', rotando los roles de conductor y navegante cada 15 minutos. Primero, diseñan los elementos visuales del casino: el tapete, los botones de apuesta y las animaciones de los resultados (sprites). Segundo, ejecutan la fase de 'Caza del Error' (Debugging): el docente proporciona una lista de verificación de errores comunes y las parejas deben testear su código sistemáticamente para identificar fallos en las condiciones lógicas o en la visualización de variables, corrigiéndolos en tiempo real mediante el análisis del flujo de datos.
Actividades de Cierre (~10 min)
Sesión de 'Ticket de Salida' digital donde cada pareja debe describir el error (bug) más complejo que han encontrado y cómo lo han solucionado. Se realiza una breve puesta en común sobre la importancia de la persistencia en la depuración y se anticipa que en la próxima sesión se realizará la gran apertura del casino para el resto de la clase.
Recursos
Entorno de programación por bloques (Scratch o MakeCode), tabletas o portátiles, proyector interactivo, guía visual de principios de diseño UX/UI, plantillas de registro de depuración (bug logs).
Atención a la Diversidad (DUA)
Representación: Proporcionar tutoriales en vídeo con subtítulos sobre cómo diseñar sprites y guías visuales de depuración. Acción y Expresión: Permitir el uso de editores de imagen externos o herramientas de dibujo integradas según la preferencia del alumno. Implicación: Fomentar la colaboración mediante roles claros en la programación por parejas para reducir la frustración ante el error.
Competencia Digital
Se integra mediante el uso de entornos virtuales de programación para la creación de contenidos digitales (CD3) y la resolución de problemas técnicos mediante el pensamiento computacional y la depuración de algoritmos (CD5).
Rúbrica de la Sesión
| Criterio | Insuficiente | Suficiente | Notable | Sobresaliente |
|---|---|---|---|---|
| Diseño de Interfaz y Experiencia de Usuario (UX/UI) | El diseño es confuso, no hay feedback visual ante las acciones del usuario y los elementos dificultan el juego. | El diseño es funcional y permite jugar, aunque la estética es básica y el feedback visual es escaso. | La interfaz es clara, atractiva y utiliza colores y formas que ayudan al usuario a entender el estado del juego. | Interfaz profesional con animaciones fluidas, feedback inmediato y una estética coherente que mejora significativamente la experiencia. |
| Eficacia en la Depuración (Debugging) | No identifica los errores en el código o es incapaz de corregirlos sin ayuda constante del docente. | Identifica errores evidentes y los corrige tras varios intentos, necesitando guías de apoyo. | Localiza errores lógicos y visuales de forma autónoma utilizando estrategias de prueba y error sistemáticas. | Demuestra un dominio experto en la depuración, anticipando posibles fallos y resolviendo errores complejos de forma eficiente. |
Sesión 4: El Gran Torneo Lógico
Duración: 50 minutos
Objetivos
Presentar los simuladores finales, realizar una coevaluación entre equipos y analizar las probabilidades reales de victoria.
Actividades de Inicio (~10 min)
Se inicia la sesión con la dinámica '¿La casa siempre gana?', donde se proyectan tres simuladores de juegos de azar distintos creados en sesiones anteriores. Los alumnos deben predecir, basándose en el código observado, cuál tiene mayor probabilidad de éxito para el jugador. Se activan conocimientos previos sobre estructuras de control y variables de puntuación, vinculándolos con el concepto matemático de probabilidad y azar.
Actividades de Desarrollo (~35 min)
Fase de Exposición y Coevaluación: Cada pareja presenta su simulador final de casino utilizando la técnica de 'Feria de Muestras'. Mientras un miembro del equipo (el 'crupier') explica el funcionamiento lógico y el código a los visitantes, el otro (el 'jugador') visita otros proyectos. Los visitantes deben completar una breve ficha de coevaluación digital analizando la complejidad del algoritmo y la interfaz de usuario. Posteriormente, se realiza un análisis de datos en tiempo real: cada equipo ejecuta su programa 50 veces seguidas para registrar el número de victorias y derrotas, comparando los resultados empíricos con la lógica programada para determinar si el juego es equilibrado o está sesgado.
Actividades de Cierre (~10 min)
Reflexión final mediante un 'Ticket de Salida' digital donde el alumnado debe responder: '¿Cómo influye la programación en la percepción del azar?'. Se realiza una breve puesta en común sobre la importancia de la ética en el diseño de algoritmos de juegos y se anuncia el equipo cuyo simulador ha demostrado ser el más robusto y equilibrado según las métricas recogidas.
Recursos
Ordenadores con conexión a internet, entorno de programación por bloques (Scratch o MakeCode), proyector interactivo, formulario digital de coevaluación (Google Forms o Microsoft Forms), hoja de cálculo compartida para el registro de victorias/derrotas.
Atención a la Diversidad (DUA)
Representación: Se proporcionan guías visuales con los criterios de evaluación iconizados. Acción y Expresión: Los alumnos pueden elegir presentar su proyecto de forma oral, mediante un vídeo pregrabado o a través de una demostración puramente técnica. Implicación: Se fomenta el aprendizaje cooperativo y se permite el uso de herramientas de lectura inmersiva para los formularios de coevaluación.
Competencia Digital
Se integra mediante el uso de entornos de programación para la ejecución de prototipos (CD3), la gestión de datos y hojas de cálculo para el análisis de probabilidades (CD2) y el uso de herramientas de comunicación y evaluación en línea para la coevaluación (CD1).
Rúbrica de la Sesión
| Criterio | Insuficiente | Suficiente | Notable | Sobresaliente |
|---|---|---|---|---|
| Presentación y Comunicación del Proyecto | No logra explicar el funcionamiento del simulador ni la lógica subyacente de forma clara. | Explica el funcionamiento general del juego pero tiene dificultades para justificar las decisiones de programación. | Describe con claridad la relación entre el código y el comportamiento del juego, usando terminología técnica adecuada. | Comunica con fluidez la lógica del algoritmo, responde a preguntas complejas y demuestra un dominio total del prototipo. |
| Análisis de Probabilidad y Azar | No identifica la relación entre el código y los resultados de victoria/derrota observados. | Registra los datos de las partidas pero realiza un análisis superficial sobre la probabilidad real del juego. | Compara correctamente los resultados empíricos con la lógica programada, identificando si el juego es justo. | Realiza un análisis crítico profundo sobre el sesgo del algoritmo y propone mejoras precisas para ajustar la probabilidad. |
| Coevaluación y Sentido Crítico | Completa las evaluaciones de sus pares de forma incompleta o sin criterios objetivos. | Evalúa a sus compañeros siguiendo la rúbrica, aunque sus comentarios son genéricos y poco constructivos. | Proporciona retroalimentación constructiva y objetiva basada en los criterios técnicos establecidos. | Analiza críticamente los proyectos ajenos aportando sugerencias de optimización de código de alto valor. |