- Ver método de entrega
- Aclaración: deberán implementar como mínimo 5 excepciones personalizadas a lo largo de su código.
- Añadidas sprites para uso de todos, en dado caso no quieran crear las propias. No es evaluado si las crean o no
- El manual técnico cambia entre los grupos de tres y cuatro personas, leer sección de documentación
- Entrega primer avance - sábado 13 de junio (sin ponderación)
- Entrega final - lunes 22 de junio
- Elementos que obligatoriamente deben ser cargados desde código: todo lo que tenga que ver con el UserControl/Form del juego. Cosas como el menú o el top pueden ser trabajadas con el designer.
Definición formal
Menú principal
Jugabilidad
Requerimientos técnicos
Conexión a BD
Paradigma orientado a objetos
Implementación del MVC
Buenas prácticas
Repositorio de GitHub
Requerimientos metodológicos
Herramientas
Problemas en flujo de trabajo
Documentación
Método de entrega
El proyecto final de la materia consistirá en la recreación de un juego clásico, Arkanoid. Para las personas que nunca lo han jugado o escuchado, acá un breve video.
Se pretende que el juego sea totalmente funcional, y que conste de un único nivel a su creatividad. El programa como tal deberá contener los siguientes aspectos:
Deberá contener las siguientes opciones:
Jugar
Deberá solicitar un nombre de jugador a través de una pequeña ventana o cambio de panel dentro de la principal. El nombre del jugador deberá ir a buscar su existencia en una BD, en caso no exista deberá agregarse.
Puntajes
Se mostrará una ventana externa conteniendo un Top 10 mejores puntajes, mostrando el nombre del jugador/usuario y el puntaje obtenido.
La jugabilidad es esencial, y deberá ser fluida. Queda a disposición de los programadores la manera de desplazar la nave, los sprites a utilizar, la disposición de los cuadros en pantalla, la movilidad si será con las direccionales, el WASD o el mouse, entre otros aspectos.
Los aspectos que son obligatorios en la jugabilidad serán:
- Un sistema de vidas
Que el jugador inicie con una cantidad n y a medida falle disminuyan hasta perder el juego. - Un sistema de puntaje
No podrán haber una disposición de bloques donde todos sean del mismo color. Dependiendo del color del bloque así será el puntaje. - Diferenciación de destrucción de bloques
Como mínimo, deben haber dos niveles de destrucción. A lo que esto refiere es la cantidad de veces que la bola/proyectil debe tocar el bloque para destruirlo. Pueden ser que bloques requieran 1 toque, mientras que otros necesiten 3.
Para los requerimientos técnicos, deberán implementar los siguientes elementos:
Su programa deberá conectarse a una BD que deberá ser creada por su grupo de trabajo, en PostgreSQL.
A lo largo de su código deberá verse reflejado el aprendizaje de la materia, aplicando definiciones de clase e instanciaciones de objetos, conceptos como polimorfismo, clases estáticas, etc.
La organización de su código fuente en su solución debe aplicar la normativa del Modelo Vista-Controlador.
Su código fuente debe ser legible y estar comentado en las partes importantes. El 80% de su código debe estar en inglés (nombres de funciones, variables, clases, atributos, etc. Los comentarios no, esos pueden ir en español).
La utilización del sistema de control de versiones Git será obligatoria. Su repositorio será público y nombrado de la siguiente manera:
NombreGrupo_Arkanoid
No se permitirá que hayan commits de un único contribuyente, todos los miembros del grupo deberán aportar.
En cuanto a requerimientos metodológicos, es necesaria la buena comunicación y organización de su equipo de trabajo.
Se evaluará la utilización de herramientas de planificación, como tableros u organigramas. La herramientra propuesta para la materia es Trello.
Trello consiste en la implemetación de un tablero, que contiene listas, y a su vez estas listas contienen tarjetas con información escrita por los miembros.
Se pretende que las listas estén categorizadas, por importancia, tipo de actividad, etc.
Las tarjetas dentro de las listas corresponden a actividades, y pueden ser personalizadas, agregando fechas límites, marcarlas con etiquetas, agregar miembros a la actividad, checklists, etc.
Su grupo de trabajo deberá crear un tablero y enlazarlo a GitHub.
Si se dan problemas en el flujo de trabajo, por ejemplo, si un miembro no aporta, si hay desacuerdos, etc. estos deberán ser reportados en una lista de Trello. Esta lista se llamará Issues y deberá existir una tarjeta dentro de ella por cada problema presentado.
Estos problemas no deberán ser reportados a su instructor/catedrático. En la revisión de su proyecto, se visualizarán los problemas que existan y se evaluará la nota de los miembros que no participen según esta información. También se tomará en consideración si se reportan otros errores para no afectar la nota grupal.
No se permitirá un tablero que no tenga esta lista, y que en esta lista no existan tarjetas.
Deberán entregar un manual técnico acerca de lo implementado en su proyecto. Este documento contendrá los siguientes elementos:
- Aspectos generales
Contendrá la información del objetivo del documento, una descripción general del proyecto y el Software utilizado para la creación del mismo. - UML
Un diagrama de clases basado en su proyecto. - Diagrama Entidad Relación Extendido
Referente a la base de datos - Diagrama Relacional
- Conceptos técnicos y distintos tipos de error
Lista de clases implementadas y breve descripción. No se consideran los eventos y excepciones. - Nomenclaturas
Abreviaciones de nombres de variables utilizadas y su referencia. - Eventos y excepciones. Lista de eventos y excepciones con breve descripción.
En la sección de UML del Manual Técnico deberá agregar un UML de diagrama de casos de uso.
Para tener derecho a calificación deberá seguir al pie de la letra las siguientes indicaciones:
-
Deberá tener dentro de su repositorio los siguientes elementos:
- Una carpeta llamada SourceCode que contenga el código fuente de su proyecto
- Una carpeta llamada Documentación, que deberá contener el manual técnico, el script utilizado de la base de datos, y dos archivos en formato PNG que corresponderán al diagrama relacional normalizado de su base de datos, y el diagrama de clases. Para grupos de más de cuatro integrantes, recordar anexar también el manual de usuario
- Un archivo README.md con la estructura mencionada acá
- Crear un release en GitHub. Esto lo puede hacer en la pestaña releases de la barra de su repositorio, seleccionará Create new Release, en la ventana que cargue:
- En Tag Version deberá colocar v1.0.0
- En @master (justo a la par del Tag Version), deberá dar clic y seleccionar commits, luego el commit más reciente realizado
- En Release Title Arkanoid Project Release
- Y finalmente en la parte donde dice "Describe this release" debe colocar cinco aspectos importantes del proyecto. Ojo: este proceso debe ser realizado únicamente por una persona del grupo
Ver ejemplo de release
El archivo README que colocará en su repositorio deberá estar escrito en MarkDown, y su extensión debe ser README.md, esto puede crearse propiamente desde GitHub, editores de código como Atom, VSCode, o incluso desde IDEs como Rider.
El README deberá contener:
- Como título el nombre de su grupo
- Como subtítulo o título 2 la palabra "Integrantes", y luego una lista con los nombres y carnets de cada uno de los integrantes de su equipo
- Como subtítulo o título 2, la palabra "IDE", y luego el IDE utilizado. Si por alguna razón utilizaron más de uno, especificar
- Como subtítulo o título 2, la palabra "FAQ's" que hace referencia a "Frequently Asked Questions", en la cuál deberá colocar mínimo 5 preguntas (con su respuesta) que un usuario pueda hacerle a usted como desarrollador acerca del funcionamiento, ojo, no son preguntas respecto al código, ni como hicieron tal cosa, sino preguntas como:
- ¿Cómo iniciar el juego?
- ¿Cómo salir del juego?
- ¿Qué pasa si encuentro un error?
- ¿Dónde puedo ver mi puntaje?
- Mi nombre aparece en la lista de Top Jugadores, ¿que significa esto?
- Como subtítulo o título 2, la palabra "Trello", y el link correspondiente a su tablero
PD: Cuidar su ortografía