Una web que reparte y explica
El proyecto adapta un recorrido de predicciones con cartas a una pantalla. La web se encarga de mezclar, revelar y mantener la posición, para que los jugadores no tengan que gestionar manualmente esos pasos. Las páginas informativas explican la misma implementación que utiliza la partida.
El repositorio público es seryio2004/peaje. Las incidencias de funcionamiento pueden comunicarse desde contacto. Esta página describe el código actual, sin atribuir una historia personal o fechas de origen que el proyecto no documenta.
Frontend y exportación estática
La aplicación usa Next.js con App Router, React y TypeScript. Las guías son componentes de servidor que se ejecutan durante la construcción: su texto queda dentro de los archivos HTML, disponible para lectura sin JavaScript. El juego es un componente de cliente, porque responder y avanzar necesitan estado e interacción.
El build exporta el sitio al directorio out/. Wrangler está configurado para servir estos recursos con Cloudflare Workers Assets y el dominio elpejae.com. No hace falta un proceso de Next.js para resolver cada visita ni una base de datos de partidas.
La baraja como datos
Cada carta tiene un identificador que combina palo y valor. createDeck() genera las 52 combinaciones; shuffleDeck() mezcla una copia mediante Fisher–Yates. La primera carta es la referencia inicial y el resto forma un mazo del que se extrae una carta por respuesta.
Las comparaciones usan valores numéricos del 2 al 14. El dibujo no decide el resultado: corazones y diamantes son rojos; corazones y tréboles se consideran redondos. Cambiar el estilo visual de la baraja no altera estas reglas. Los peajes no consumen cartas.
Estados explícitos para una partida
El motor separa cinco fases: jugando, validando, fallo, peaje y final. En dos jugadores con respuesta verbal, revelar pasa a validación y el preguntador confirma el resultado. En automático, una predicción se comprueba contra la carta extraída.
Un fallo conserva la carta visible y guarda el destino del retroceso. Si ese retroceso atraviesa un peaje, hay que confirmar el cruce antes de llegar a la pregunta anterior. Esta separación evita que una sola pulsación salte de la revelación a una pregunta sin resolver el peaje.
Turnos rápidos mantiene dos estados independientes con sus propias barajas y cambia el jugador activo al fallar. La patata comparte un estado y selecciona una lista oculta de cartas de pase al empezar. El estado vive en memoria: recargar descarta la partida.
Adaptarse a una pantalla pequeña
La interfaz utiliza CSS con reglas por tamaño y orientación para ajustar cartas, tablero y controles. Las guías conservan la tipografía y la identidad de carretera del juego. La tabla de probabilidades puede desplazarse horizontalmente sin ensanchar la página.
La navegación y los enlaces son elementos HTML; el contenido editorial no depende de una animación para aparecer. Las preferencias de movimiento reducido desactivan efectos según la configuración del dispositivo. En el juego, los controles siguen siendo botones con texto y las cartas incluyen su valor y palo.
Construir, comprobar y publicar
El proyecto ejecuta pruebas del motor y de consentimiento con el runner de Node. Después del build, una verificación inspecciona metadatos, rutas, enlaces, sitemap y política de seguridad del export. La auditoría del sitio añade comprobaciones HTTP cuando se le indica una URL base.
Producción permite indexación; staging genera noindex para evitar que una copia de pruebas compita con el dominio público. La publicidad está separada del juego y no se carga un SDK publicitario. Los cálculos de probabilidades comparten la función de creación de baraja con el motor para reducir discrepancias entre guía y partida.