search

villagra-abp / code

[ABP16] Juego con tematica Survival Horror ambientado espacial o futuristica
GNU General Public License v3.0
0 stars 1 forks source link

Entrega Hito 1 #6

Closed hec17x closed 5 years ago

hec17x commented 7 years ago

[PM]

Entregables:

[V1]

Entregables:

PD

Entregables:

RV

Entregables:

Juego sin componentes

Juego sin componentes

DavidBrando commented 7 years ago

Se ha hecho un merge a la rama master con la actualización de la abertura y cierre de las puertas

lronaldo commented 7 years ago

Comentario global

Muy mala entrega, desordenada, sin relación con el presupuesto y sin explicaciones. Muchos documentos y contenidos entregados como enlaces al repositorio: no debería hacerse jamás. Los repositorios son para desarrollo, varían en el tiempo, no son para realizar releases.

Hay muchas cosas y muy importantes que corregir. Todas ellas deben ser corregidas inmediatamente y el trabajo debe focalizarse desde ya mismo en que las cosas estén hechas desde el primer día. Los entregables no pueden prepararse a última hora: deben estar preparados desde el primer momento (YA!) e ir rellenándose conforme se vayan completando las tareas. Alguien debe preocuparse en todo momento que la calidad de la entrega sea la mejor posible, y no que sea lo que salga. Esto no debe repetirse en próximas entregas.

Evaluación de Entregables

Documento de diseño de mecánicas de los NPCs [12h, 1.09p]

No se encuentra el documento. Hay diversos documentos llamados "Mecánicas X", desordenados. Eso no permite saber cuáles están incluídos y cuáles no, dónde empieza y dónde termina el entregable.

Los documentos no tiene estructura resultando tediosos de leer. Se supone que estos documentos deberían ser una referencia de consulta y de diseño constante para el equipo. Ninguno de estos documentos cumple ese criterio. Dudo profundamente que hayan sido consultados más de 1 o 2 veces por los miembros del equipo. Algunos, como "Mecánicas Entidades sin IA" no tienen título, ni introducción, ni explicación de qué son o para qué sirven, más allá del nombre de archivo. En general no se usan negritas, ni tablas, ni títulos, ni secciones, ni tan siquiera espaciados con intros para diferenciar partes y permitir entender la estructura del contenido. La mayor parte son descripciones textuales que, al carecer de estructura, probablemente no hayan sido releidas ni por el propio diseñador.

Los diagramas que aparecen en los documentos de Mecánicas de Aliens están etiquetados como "Casos de Uso", pero no siguen el formato de "Casos de Uso" de UML. Al igual que los documentos, no están apenas estructurados y su comprensión no es inmediata. Requieren ser analizados para entender lo que quieren decir. En su estado actual, su utilidad como referencia de implementación/diseño para el equipo es muy baja.

Documento de diseño de sistemas de toma de decisión [14h, 1.27p]

Hay un documento titulado "Diseño de sistemas de toma de decisiones" en la carpeta de documentos que se asume debe ser este. Se asume porque hay otros documentos titulados "Especificación toma decisiones xxxxxx" que no se corresponden con otros items del presupuesto y podrían tener que ver con este item. Dado el desorden reinante, esto no queda claro.

Este documento tiene un formato muy ligeramente mejor, pero una estructuración y contenido insuficiente. El documento comienza hablando de la "Cría de Alien" y explica decisiones concretas directamente en casos específicos "Con personaje detectado", "Sin detectar al personaje"... Un sistema de toma de decisión debe ser un conjunto de procedimientos para procesar la información y tomar decisiones. Debería quedar claro qué información necesitan los personajes, de dónde la obtienen, cómo la procesan y cómo eso contribuye a la toma de decisiones. Es necesaria una lista estructurada de todas las posibles decisiones que pueden tomar los NPCs, por niveles de profudidad de acción (planificación / acción inmediata). En lugar de esto, el documento contiene textos vagos describiendo ideas intuitivas sobre lo que los personajas deberían hacer en supuestas situaciones no descritas con claridad. Como ejemplo "También puede haber algunos que estén quietos.": ¿Esto quiere decir que a lo mejor se implementa que algunos estén quietos? ¿Cuándo están quietos? ¿Por qué? ¿Cómo lo deciden?

Los diagramas presentados son supuestos diagramas de estados, pero en realidad representan flujo de ejecución. De hecho, se utilizan rombos como cuestiones, exactamente igual que en un diagrama de flujo. Aunque el diagrama aclara algo lo que se pretende describir en el texto, debería ser más claro con lo que pretende representar (flujo o estados). Tampoco puede ser muy claro si todo lo indicado arriba no está claro.

El documento parece hecho por varias personas de forma no coordinada. Hay descritos 3 personajes. Los 2 primeros con descripciones vagas basadas en items y un diagrama cada uno, mientras que el tercero "Alien Jefe" tiene una descripción textual compacta con introducción y texto descriptivo. No tiene ningún sentido que un documento de diseño presente estas diferencias conceptuales. Las descripciones de este estilo deberían ser muy concisas. La estructura de un sistema debe estar centrada en sus elementos e interacciones.

Como resumen, este documento no describe ningún sistema. Define un conjunto de intenciones de implementación del equipo de diseño, vagas, no estructuradas y no demasiado trabajadas.

Documento de diseño técnico de la arquitectura de la IA [20h, 1.82p]

No aparece ningún documento con este título entre los entregados. Se estima que los documentos titulados "IA xxxxx" deben ser partes de este documento, pero nada indica tampodo que esto pueda ser así.

Los documentos parecen hechos por 2 personas distintas, 2 a 2. Todos son listas de items, completamente en texto, en unos documentos con negrita en los puntos y en otro no. Esto no tiene nada que ver con un diseño técnico de Arquitectura de IA. El diseño técnico de Arquitectura de IA debería tomar el diseño del sistema de toma de decisión y diseñar con él una arquitectura de componentes/objetos para ser implementada. Como mínimo debería haber un diagrama de clases, pero estaría bien que hubieran diagramas de secuencia y diagramas de bloques para explicar los distintos módulos, sus funcionalidades y su interacción en tiempo de ejecución. Cuando hablamos de estos componentes/módulos/objetos, nos referimos a partes conceptuales del programa que va a ser implementado. Por eso es un diseño técnico.

No hay nada que evaluar en estos documentos, al carecer del contenido esperado.

Diseño de requerimientos y funciones de red [15h, 1.36p]

En esta ocasión, si se encuentra un documento con este título. Sin embargo, el documento cuenta con una única hoja, 65% título, en la que hay 2 apartados "Requerimientos" y "Funciones" con 4 y 3 items respectivamente. Sin duda, nada que ver con las 15h presupuestadas para la realización de este entregable.

Las funciones descritas son tremendamente obvias y vagas: "Comunicarse con el servidor", "Subir las puntuaciones de cada jugador", "Subir los logros de cada jugador". Esto es totalmente insuficiente como funciones, y ni tan siquiera como requerimientos. Este contenido resulta completamente inútil. Un contenido útil requeriría analizar en detalle los requerimientos del juego y convertirlos en funciones más concretas con una descripción apropiada. Este contenido debería servir de base para diseñar la arquitectura técnica del motor de red, estructurando las funciones indicadas para cubrir los requerimientos.

Diseño técnico de funcionamiento del motor de red [20h, 1.82p]

Se encuentra un documento titulado "Diseño tecnico del motor de red" que se asume debe corresponder a este item. Sin embargo, el contenido es de 1 párrafo escrito en total, escrito en condicional. Básicamente un "ya lo haremos" que nunca se hizo. Lo único que indica es que se usará cURL.

La única nota posible para un documento así es un 0, ya que no hay trabajo ninguno.

Gestión de estados de la IA con Máquinas de Estados [10h, 0.91p]

No hay un entregable concreto para este item. Se entrega uno titulado "Máquina Estados de la IA y Behaviour Tree" que se asume agrupa en su interior el contenido esperado.

El contenido es exclusivamente un proyecto compilado y ejecutable para Windows. No se entrega el código fuente específico de niguno de los dos puntos que nombra el entregable. Debería estar incluído como ZIP. De no estarlo, se supone que el entregable no contiene código fuente y, por tanto, no debe ser evaluado.

El ejecutable no funciona en un Windows 7 limpio, necesitando la librería libgcc_s_dw2-1.dll. Al no poder ser ejecutado, no puede ser tampoco evaluado.

Sistema de toma de decisión con Lógica Difusa [30h, 2.73p]

No se encuentra entregable alguno para este punto. Algo totalmente incomprensible por tratarse de uno de los puntos más valiosos del Hito.

Sistema de toma de decisión con Behaviour Trees [35h, 3.18p]

Se entrega un único proyecto ejecutable conjunto para este item titulado "Máquina Estados de la IA y Behaviour Tree". El ejecutable, como se ha comprobado anteriormente, no funciona en un Windows 7 limpio, necesitando libgcc_s_dw2-1.dll. Al no poder ejecutar el juego y no disponer del código fuente en la entrega, no es posible evaluar el item.

Pathfinding básico con rejilla (A*/Dijkstra) [30h, 2.73p]

No se encuentra entregable alguno para este punto. Nuevamente, algo totalmente incomprensible. 60 horas de trabajo no cubiertas y 5.46 puntos perdidos por no realizar ni una entrega y por no planificar las tareas con mayor coste e incertidumbre primero.