Objetivo del proyecto: Construir con propósitos pedagógicos una aplicación web que permita jugar de forma distribuida una adaptación del juego de mesa Hoot Owl Hoot!.

Adaptaciones

Cada equipo debe construir una adaptación del juego, y no el juego original. Las siguientes adaptaciones son obligatorias:

  1. El progreso y condición de victoria debe estar más en función del mérito de los jugadores que del azar.

Cada equipo debe sugerir al menos dos adaptaciones adicionales a las obligatorias. Las siguientes son ideas de ejemplo.

  1. Preguntas. Para posicionarse sobre una celda, el jugador (o el equipo) debe contestar una pregunta. Si la acierta se mantiene en la celda, de lo contrario, se mantiene en su posición actual. Cada vez que falla el sol se movería una casilla.

  2. Modo competitivo. Los jugadores pueden competir por llegar primero al nido. Al final del juego se mostraría la tabla de posiciones.

  3. Memoria. Las celdas están ocultas y en ellas no se pueden posar los jugadores. En cada turno, el jugador tiene derecho a voltear dos celdas, si forman pareja éstas pueden ser usadas en el juego y puede revelar más mientras forme parejas. Si no forma pareja, el sol se moverá una posición.

Cronograma de entregables

# Fecha Avance / Peso Peso

1

15-abr

prj_analysis

5

2

13-may

prj_site_structure

5

3

13-may

prj_design_wireframes

25

4

27-may

prj_xhtml_images

10

5

27-may

prj_css

25

6

10-jun

prj_client_js

35

7

10-jun

prj_message_passing_design

15

8

17-jun

prj_server_js

30

9

24-jun

prj_game1

15

10

24-jun

prj_session

35

11

01-jul

prj_game2

15

12

08-jul

prj_presentation

30

prj_analysis

  1. Repositorio y README.md

  2. Descripción del problema

  3. Adaptaciones

  4. Miembros del equipo

prj_site_structure

  1. Mapa del sitio

  2. Diseño individual en papel

  3. Discusión de grupo

  4. Acuerdos en diagramas digitales

  5. Exportar wireframes a formato SVG en carpeta design/.

prj_design_wireframes

  1. Página principal

  2. Sala de espera de anfitrión e invitado

  3. Página de juego/tablero

  4. Páginas secundarias: créditos, ayuda, leaderboard

  5. Explicación en archivo design/design.md.

prj_xhtml_images

  1. Contenido de todas las páginas de los wireframes en XHTML5

  2. Páginas válidas (usar validador de W3C)

  3. Web semántico (no div/span)

  4. Redundancia de código permitida o usar SSI.

  5. Favicon en todas las páginas

  6. Página de juego/tablero con sus contenidos sin posicionar

  7. Sitio navegable por todas las páginas.

  8. Dar crédito a los autores de las imágenes/recursos (página de créditos).

prj_css

  1. Aplicar y ajustar estilos si se reutiliza el diseño hecho en el diagramador (ej: Figma)

  2. Usar una paleta de colores generada por un programa (usar variables CSS).

  3. Estilos deben ser válidos ante el Unicorn validator de W3C y un linter (stylelint)

  4. Diseño adaptativo en todas las páginas (responsive design)

  5. Estilos uniformes a lo largo del sitio

  6. Reutilizar archivos de estilo a lo largo del sitio (ej.: common.css)

  7. Modularización: estilos propios de cada página, ej: board.css, @import url('common.css')

  8. Diagramación (layout) con FlexBox.

  9. Buenas prácticas (ej.: variables, comentarios, no usar vendor prefixes como -webkit-)

  10. Efectos en imágenes: encontradas, en búsqueda, con adaptaciones del juego (dependiente de cada equipo)…​

  11. Transiciones/animaciones básicas.

prj_client_js

Aplica sólo a la página de juego/tablero.

  1. Permite un juego local en modo solitario.

  2. Modo de juego infinito, una carta a la vez.

  3. Tamaño de tablero fijo, pero almacenado en una constante en el código.

  4. Realimentación en caso de éxito/error (ej.: sonido/animación al marcar objeto incorrecto).

  5. Puntaje, cambio de carta en caso de éxito

  6. Implementar adaptaciones propias escogidas por el equipo que tengan sentido.

  7. Todo el comportamiento está en archivos externos.

  8. Buenas prácticas: <scripts> al final de documento, asíncrono, addEventListener.

  9. Establece los manejadores de eventos (setup game).

  10. Consistencia de paradigmas de programación (funcional, procedimental, orientado a objetos).

  11. Modularización (archivos .js importan otros archivos .js, subrutinas NO son extensas).

  12. Documentación de subrutinas y tipos de datos propios.

  13. Buenas prácticas: identificadores significativos, let/const, indentación…​

  14. Reutilización de código: no hay redundancia entre subrutinas ni archivos

  15. Válido ante un linting (ESLint)

prj_message_passing_design

  1. Diseño del protocolo del paso de mensajes en XML/JSON.

  2. Simular una sesión de juego entre los integrantes cambiando roles (servidor, jugadores) con un chat.

  3. Repetir hasta obtener una sesión exitosa de juego con pocos objetos.

  4. Usar los mensajes en formato XML/JSON y registrar la sesión del chat.

  5. Diseñar una máquina de estados (autómata) que explique el manejo de eventos.

  6. Exportar la máquina de estados a SVG, incrustarla en el design/design.md.

  7. Diseñar los algoritmos de las transiciones de la máquina de estados en design/design.md.

prj_server_js

Aplica sólo a la página de juego/tablero.

  1. Permite a dos o más personas jugar en la pantalla de juego/tablero con una configuración fija.

  2. Implementar un servidor delimitado para el juego con tecnología a escoger (ej.: Node.js).

  3. Implementar el protocolo de paso de mensajes para la página de juego/tablero.

  4. Comunicación a través de WebSockets (u otra tecnología, ej.: persistencia en la nube).

  5. Buenas prácticas de programación (ver puntos de prj_client_js).

prj_game1

  1. Adaptaciones de cada equipo (a coordinar con el profesor).

  2. Modo de juego con varias cartas.

  3. Manejo de rondas en la pantalla de juego/tablero.

  4. Persistencia de algunos datos del juego (archivos/bases de datos).

prj_session

  1. Implementar sesiones de juego.

  2. Página principal permite crear o unirse a sesiones.

  3. Sala de espera de anfitrión permite configurar sesiones y ver invitados.

  4. Sala de espera de invitado permite ver invitados.

  5. Anfitrión puede iniciar la sesión y todos los jugadores comienzan a jugar.

  6. Pantalla de juego aplica configuración del anfitrión.

  7. Manejo de partidas: retorno a la pantalla de sesión/sala de espera.

  8. Almacenar y recuperar los valores ingresados por usuarios en el localStorage.

prj_game2

  1. Adaptaciones de cada equipo (a coordinar con el profesor).

  2. Manejo de rondas, partidas, sesiones.

  3. Reconfiguración de la sesión/partida: el anfitrión puede cambiar parámetros entre partidas.

  4. Reporte de ganadores, mejores marcadores…​

  5. Salirse de la partida/sesión.

  6. Instrucciones en el README.md para configurar y correr la aplicación web.

prj_presentation

  1. Presentación del producto final al resto de la clase.

  2. Un día jueves a convenir, 50 min por equipo.

  3. Manual de uso mientras los integrantes muestran cómo jugar (10 min).

  4. Espacio para que la clase pueda jugar (30 min).

  5. Espacio de preguntas y retroalimentación (10 min).