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 de encontrar objetos en una manta. Dos versiones de este juego son Lince de la empresa española Educa Borras, y Hey! Yo lo vi primero de la empresa colombiana Ronda S.A.

Imagen oficial del Lince
Imagen oficial de Hey! Yo lo vi primero

Sobre el juego original

El juego de mesa original consiste de una manta estampada con objetos visuales. En la versión de "Hey! Yo lo vi primero", ambos lados de la manta están estampados. El lado de fondo amarillo tiene mayor cantidad de objetos que el lado celeste lo que permite escoger el nivel de dificultad. La manta es un rompecabezas, de tal forma que al ensamblarse durante cada juego, permite que los objetos puedan quedar en posiciones distintas.

El juego incluye tantas tarjetas cuadradas como objetos hay dibujados en la manta, con sus correspondientes figuras idénticas. Además se incluyen grupos de fichas circulares que representan puntos, cada grupo tiene su propio color para distinguir a cada jugador. Pueden definirse varios modos de juego como los siguientes ejemplos:

  1. Cada jugador toma un grupo de cartas al azar sin revelar su figura. Normalmente los grupos son de una, dos, o tres cartas. A una señal de inicio convenida, por ejemplo, a la cuenta de tres, cada jugador revela su grupo de cartas. Cada jugador busca el o los objetos de su grupo de cartas en la manta. Cuando encuentra un objeto coloca una ficha de su color sobre el objeto. El primero que encuentra todos los objetos de su grupo, grita "alto" y los demás jugadores se detienen. Los jugadores muestran sus coincidencias a los demás, conservan las cartas, y retiran las fichas circulares. Las cartas que no lograron encontrar regresan a la caja donde son mezcladas. Los jugadores toman otro grupo de cartas e inicia otra ronda. Quien llegue primero a un número de cartas, por ejemplo 25, o encuentre más objetos en un tiempo definido o se acaben las cartas, será el ganador.

  2. Un jugador toma una ficha sin revelar. A la señal de inicio convenida la revela y todos los jugadores la buscan. El primero en encontrar el objeto en el tablero lo cubre con su ficha redonda y como premio obtiene la carta. Ese jugador escoge la siguiente ficha e inicia otra ronda. Gana quien logre llegar primero a una cantidad predefinida de cartas, por ejemplo 15, o quien logre acumular más cartas en un tiempo dado.

  3. Cada jugador toma 10 fichas de un mismo color. Se revela un grupo de cartas a todos los jugadores. Normalmente los grupos son de una, dos, o tres cartas. Los jugadores compiten por encontrar los objetos de las cartas en la manta. Cuando un jugador encuentra un objeto, lo cubre con una ficha de su color, y la carta es reemplazada por otra (idealmente con la colaboración de un moderador del juego). Gana el jugador que se quede primero sin fichas.

Adaptaciones obligatorias

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

  1. Los jugadores pueden escoger la cantidad de objetos en la manta antes de iniciar la partida. La cantidad debe ser mínimo la cantidad de jugadores y máximo la cantidad de objetos que los miembros del equipo logre recabar. Nota: en la versión del Lince son 401 objetos.

  2. Los jugadores pueden escoger si los símbolos en la manta y en las cartas tienen la misma o distinta forma, con el fin de ajustar el nivel de dificultad. Si tienen distinta forma, deben poder asociarse de forma única. Por ejemplo, si la manta consta de imágenes, las cartas podrían contener palabras (en el mismo u otro idioma), textos (adivinanzas, oraciones), sonidos (efectos o palabras grabadas). Otro ejemplo: la manta podría tener números y las cartas operaciones matemáticas.

  3. La manta no debe ser circular, sino que debe ser adaptativa a la pantalla del dispositivo. Por ejemplo, en un dispositivo móvil pueda que el jugador deba hacer desplazamiento (scroll) vertical para encontrar objetos, pero no desplazamiento horizontal.

  4. En el juego de mesa original la posición de los objetos en cada pieza de rompecabezas es estática, es decir, los jugadores pueden memorizar los objetos que contiene cada pieza. La aplicación web debe aleatorizar la posición de los objetos cada vez que se crea una sesión, o cada vez que se cambia de partida.

Ideas de adaptaciones adicionales

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

  1. En el modo de juego 1, cada jugador ve su propio juego de fichas, pero no puede ver las fichas de los demás. La aplicación web reparte las fichas pero puede haber intersecciones al azar, de tal forma que dos o más jugadores pueden estar buscando el mismo objeto sin saberlo. El primer jugador que lo encuentre obtendrá el objeto, y los demás verán que su carta cambiar por otra escogida al azar.

  2. No hay intersección entre los objetos en la manta del juego de mesa original. En la versión web se puede permitir cierto grado de intersección de tal forma que algunos objetos pueden cubrir parcialmente a otros. Esto ahorra espacio y puede dificultar encontrar los objetos parcialmente cubiertos. El grado de traslape puede incrementar entre partidas.

  3. En el juego de mesa original los objetos en la manta siempre son los mismos. La aplicación web puede escogerlos al azar en cada sesión o en cada partida, de acuerdo al número de objetos que los jugadores soliciten.

  4. La aplicación puede cambiar deliberadamente la posición de objetos durante el juego. Por ejemplo, puede intercambiar dos objetos en cada ronda, cada cierto tiempo, o con un tiempo aleatorio. Este comportamiento puede incrementar entre más rondas se jueguen en una misma sesión.

  5. Cuando un objeto es encontrado por un jugador, en lugar de ser marcado con una ficha, la aplicación podría reemplazarlo por otro objeto escogido al azar que no estaba en la manta.

  6. Cuando un objeto es encontrado por un jugador, otro objeto que no estaba antes, es agregado a la manta, de tal forma, que la manta va creciendo de tamaño durante la partida. Este comportamiento puede mantenerse entre rondas de una misma partida, lo que incrementa la dificultad.

  7. Hacer equipos de jugadores, de tal forma que dos o más personas en un mismo equipo comparten las fichas del mismo color y colaboran por encontrar los objetos lo más rápido posible que otros equipos.

  8. Proveer un número limitado de poderes escogidos al azar a cada jugador. Por ejemplo, un poder podría animar el objeto que el jugador lleva más tiempo buscando, o podría cambiar este objeto por uno nuevo, o podría cambiarle una carta a cada contrincante. Los jugadores escogen cuándo aplicar los poderes.

  9. Jugar contrarreloj. Los jugadores definen el tiempo de la partida y gana quien logre mejor desempeño antes de que se acabe el tiempo. Si se implementan poderes, pueden haber algunos que incrementen el tiempo del jugador o lo disminuyan para los contrincantes.

  10. Modo de juego indefinido (carrera sin fin). Los jugadores compiten encontrando objetos hasta que decidan dejar de jugar. Gana quien logre mayor número de objetos encontrados.

  11. Modo de juego alternado. Un jugador tiene el turno y trata contrarreloj de encontrar el objeto en la o las cartas que son visibles a todos los jugadores. Los demás jugadores pueden dificultar encontrar al objeto, por ejemplo, moviendo objetos, o cambiarlos por objetos nuevos, lo que distrae al jugador en turno.

  12. Un jugador (quien tiene el turno) escoge los objetos que deben buscar los otros jugadores.

  13. Familias de objetos. Por ejemplo, en una familia de bolas deportivas puede estar representada por bolas de tenis, fútbol, basquetbol…​ Si se busca una carta que diga "bola", todos los objetos mencionados son válidos, y por tanto el jugador podría cubrir uno o varios de ellos.

Es ideal que las adaptaciones puedan ser configuradas por los jugadores antes de iniciar las partidas.

Cronograma de entregables

# Fecha Avance / Peso Peso

1

8/20

prj_analysis

5

2

9/3

prj_design_wireframes

25

3

9/10

prj_xhtml_images

20

4

9/17

prj_css

25

5

9/24

prj_client_js

35

6

10/1

prj_message_passing_design

15

7

10/8

prj_server_js

30

8

10/15

prj_game1

20

9

10/22

prj_session

35

10

10/29

prj_game2

20

11

11/5+

prj_presentation

30

prj_analysis

  1. Repositorio y README.md

  2. Descripción del problema

  3. Adaptaciones

  4. Miembros del equipo

prj_design_wireframes

  1. Diseño individual en papel

  2. Discusión de grupo

  3. Acuerdos en diagramas digitales

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

  5. Página principal

  6. Sala de espera de anfitrión e invitado

  7. Página de juego/tablero

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

  9. 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 suficientes imágenes estáticas que requiera scroll

  7. Al menos 20 imágenes de objetos por integrante con un nombre de archivo equivalente a identificador.

  8. Sitio navegable por todas las páginas.

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

prj_css

  1. Al menos 10 imágenes de objetos por integrante (se repite cada semana).

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

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

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

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

  6. Estilos uniformes a lo largo del sitio

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

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

  9. Diagramación (layout) con FlexBox.

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

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

  12. 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).