JavaScript de Cero a Experto / Proyectos + retos

Proyecto: juego de trivia con timer y máquina de estados

Proyecto180 min150 XP

Estado local, datos remotos… falta el tercer tipo de app: la interactiva con tiempo. Un juego de trivia junta todo: una máquina de estados que orquesta las pantallas (módulo 13), un temporizador que presiona, puntaje en vivo y eventos por delegación. La misma lógica que sostiene un quiz, un Wordle o cualquier juego por turnos.

Reto

Trivia contra el reloj

Difícil180 min150 XP(×2 sin mirar la solución)

Qué debes construir

Un juego de preguntas con temporizador, sobre un banco de preguntas local (un array —sin API). La app tiene TRES pantallas gobernadas por una máquina de estados:

menu: título y botón "Empezar".
jugando: la pregunta actual (N de total), sus opciones, el puntaje y un temporizador que corre; si se acaba el tiempo, la pregunta cuenta como perdida y avanza sola.
fin: puntaje final y botón "Jugar de nuevo".

Requisitos concretos:

Banco de datos: un array PREGUNTAS, cada una { pregunta, opciones: [...], correcta: <índice> }.
Máquina de estados: una variable estado con valores "menu", "jugando", "fin", y una función que hace las transiciones. Un solo render() pinta la pantalla según el estado.
Temporizador por pregunta (p. ej. 10 s) con setInterval; al llegar a 0, avanza como si fallara. Al responder O cambiar de pantalla, LIMPIA el intervalo (módulo 9: un setInterval sin clearInterval es una fuga).
Puntaje: +1 por acierto; se muestra durante el juego y al final.
Reinicio limpio: "Jugar de nuevo" vuelve al menú con puntaje e índice en cero, sin temporizadores zombis corriendo.

Reglas

El estado es la fuente de verdad de QUÉ pantalla se ve; render() lo refleja. Nunca muestres/ocultes pantallas "a mano".
Un solo temporizador vivo a la vez: cada vez que arranca uno, el anterior debe estar muerto.
Delegación de eventos (módulo 8) para los botones que nacen y mueren con cada pantalla.
Guard iniciar() con DOMContentLoaded.

180:00

Cuando estés listo, arranca el reloj.

Las tres ideas de diseño de juego que este proyecto ensaya:

La máquina de estados domina la complejidad. Con tres pantallas y un reloj, es fácil terminar con banderas booleanas contradictorias (jugando && !terminado && ...). Un único estado con transiciones explícitas hace imposibles los estados imposibles (módulo 13): o estás en menú, o jugando, o en el fin —nunca en un limbo.
Un temporizador, una vida. El bug clásico de todo juego: temporizadores zombis que siguen corriendo de la partida anterior y descuentan tiempo de la nueva. La disciplina pararReloj() antes de cada arranque lo previene. Un setInterval es un recurso: se abre y se CIERRA (módulos 9 y 15).
Un solo camino de avance. Que el clic y el timeout llamen a la MISMA responder() elimina la duplicación y los desajustes: la lógica de puntuar y avanzar existe una vez, y da igual quién la dispare.

Autoevaluación: juega una partida entera —¿el reloj presiona y, si lo dejas correr, la pregunta avanza sola? ¿El puntaje solo sube con la opción correcta? Y la prueba anti-zombi, la más importante: juega, pierde a propósito dejando correr el tiempo, vuelve al menú y vuelve a jugar —¿el reloj de la nueva partida corre limpio a 10, sin saltos ni descuentos de la anterior? Si es así, domas el recurso más traicionero de los juegos: el tiempo. Reemplaza el banco de preguntas por uno tuyo y ya tienes un juego para tu portafolio.

Qué sigue

Tres proyectos, tres tipos de app: estado local, datos remotos e interacción con tiempo. Ya construyes cosas completas. Lo que queda es afilar el otro músculo que evalúa la industria: los retos cortos de entrevista. Diez katas, de FizzBuzz al debounce que acabas de usar —resueltos con tests que corren en vivo. La preparación que te abre la puerta.