---
# System prepended metadata

title: 'Idea de proyecto: *Cantonada*'

---

Idea de proyecto: *Cantonada*
=============================

> Autor: **Paul Hodgetts**, alumno 738701

En este documento trato de explicar mi propuesta de proyecto para la asignatura **Sistemas y tecnologías web** (2019-2020). Para ver el repositorio clickar [aquí](https://github.com/Jujuyeh/cantonada).

La idea se centra un juego web con elementos geográficos. La idea de juego no se expone a desarrollar una lógica complicada, si no a enfrentar un reto a un usuario o **grupo de usuarios** para que adquieran mayor conociemiento de su entorno. Es por ello por lo que le he dado el nombre "Cantonada", _esquina_ en fabla aragonesa.

El reto consiste en lo siguiente: De un radio determinado, la web muestra un punto de interés - desde monumentos hasta estaciones Bizi, todo lo que se pueda aprovechar de la fuente. El jugador debe encontrar dicho punto en el radio marcado. Una vez lo ha encontrado, ha de enviar su ubicación para validar que efectivamente se encuentra junto al punto de interés.

Para añadirle algo de interés, se establece la lógica de salas cooperativas o competitivas. Esto es, a un grupo de usuarios se les presenta el mismo reto en el mismo area y deben trabajar juntos para encontrar la meta (en cooperativo) o se establece un ránking por rondas con un máximo ganador (competitivo).

Fuentes abiertas
----------------

Existe una fuente de [datos abiertos del Ayuntamiento de Zaragoza](https://www.zaragoza.es/docs-api_sede/#/). Esta API REST ofrece varias operaciones que nos permiten conocer lugares que podríamos considerar como "metas" de juego.

Adicionalmente, se querrá mostrar al jugador el resultado en un mapa cuando se haya completado el reto (útil caundo un miembro del equipo se ha adelantado al resto); y también, a la hora de seleccionar un radio en el que configurar la partida. Por esto, se requerrirá de un proveedor de datos geográficos abierto como es [OpenStreetMap](https://www.openstreetmap.org/).


Requisitos del sistema
----------------------

Sin descomponer en pequeñas actividades, se presentan los siguientes requisitos:

nº RF/RNF | Peso (estim.) | Descripción
:--------:|:----:|:-------------------------------------------
   RF1    | 10%  | El usuario debe de poder autenticarse en el sistema.
   RF2    | 20%  | El usuario debe poder crear/unirse a sala (competitiva o cooperativa).
   RF3    | 5%   | El usuario debe poder escoger un número de rondas (sucesivos retos, que forman una partida).
   RF4    | 10%  | El usuario debe poder escoger un área de juego sobre un mapa.
   RF5    | 15%  | El sistema mostrará al usuario dónde se encontraba la meta al terminar la ronda.
   RF6    | 20%  | El usuario debe de poder compartir su ubación en una partida y validarla (en base a las reglas de juego).
   RF7    | 10%  | El sistema debe presentar un sistema de ránking en partidas competitivas.
   RF8    | 10%  | Un usuario **administrador** deberá poder visualizar en un mapa las partidas en curso (mapa) y obtener estadísticas de uso (CSV).
   RNF1    |  -  | Uso de fuentes de datos abiertos.
   RNF2    |  -  | Cumplimiento de la política definida según el [GDPR](https://gdpr-info.eu/).
   

Tecnologías planteadas
----------------------

Se exige de antemano usar Express + Node.js, y MongoDB - no hay discusión aquí. Por otra parte, en *front-end* se ha decidido emplear el framework Vue.js, apoyandose con las tecnologías adyacentes que logran la funcionalidad descrita: 

- [leaflet](https://leafletjs.com/) para los mapas
- [Vuex](https://vuex.vuejs.org/) para el almacenamiento en navegador
- [Axios](https://github.com/axios/axios) como cliente HTTP
   
   
En defensa de las decisiones tomadas
------------------------------------

La idea del proyecto surge a raíz de la experiencia de diversos proyectos anteriores. Conocía con anterioriedad la existencia de la fuente de datos abiertos del Ayuntamiento de Zaragoza y OpenStreetMap, como colaborador de este último.

Adicionalmente, considero que el proyecto tiene el potencial de crecer en funcionalidad, que mi parecer es un factor positivo. Ideas que se salen fuera de plazo pero podrían perfectamente incorporase si se continuara el desarrollo; ejemplos son:

- Reportar información errónea o inconsistente al Ayuntamiento de Zaragoza por parte de los jugadores.
- Contribución al elemento greográfico en OpenStreetMap (como edición atribuida al usuario).
- Un sistema global de puntuaje de usuarios y demás elementos comunes en la *gamificación*.

En cuanto al poder de decisión en las tecnologías, he escogido aquello que ya conozco y que crea familiar lo suficientemente para acelerar el proceso de desarrollo.

> **Nota:** No comento grupo objetivo ya que al tratarse de un juego basado en retos simples, no se está imponiendo ninguna cota en el público más que aquel que disponga de la tecnología necesaria para accederlo.


<style tyle="text/css">
p {
text-align: justify;
}
</style>