Comentario Global

La forma principal en que habéis hecho las entregas ha sido enlazando a carpetas que se encuentran en el repositorio. Esto no debería hacerse. Las entregas deben ser independientes del contenido del repositorio.
Habéis añadido un enlace de Google Docs con un ZIP con toda la entrega. Esta debiera haber sido la entrega, y no los enlaces al repositorio. El repositorio es para trabajar, no para subir entregables ni para enlazarlos. Cada cosa debe estar en su sitio.
En cuanto a la forma de la entrega, en un único ZIP, no está bien estructurada. Hay 2 formas más adecuadas de hacer esto: 1) Si es en un único ZIP, la estructura interna debiera ser un PDF de explicaciones globales sobre la entrega y dentro un ZIP adicional por cada entregable. 2) La explicación global de la entrega en el Issue de Github y un enlace por cada entregable a su correspondiente ZIP.
Se haga como se haga la entrega, debe haber al menos una hoja explicativa en la que se indiquen los entregables que debían entregarse, los que se han entregado y sus enlaces. El documento explicacion.txt que habéis incluído debería de ser lo primero que uno encuentra, y no debería estar dentro de una carpeta. Por otra parte, un TXT no es la forma oportuna. El contenido de vuestro TXT tampoco es correcto. No hacéis referencia a los nombres exactos de los entregables del presupuesto, ni utilizáis sus números de referencia para evitar la confusión. Todos estos detalles son muy importantes para que una entrega sea profesional.
En el documento explicacion.txt indicáis lo siguiente:

Se hallan tres carpetas, una con cada entregable.

En la Percepcion Sensorial tenemos:

Una carpeta con el proyecto y los fuentes

Una carpeta con todo lo necesario para probar el ejecutable

Un video explicativo

En la carpeta de Logica difusa tenemos los ficheros .h y .cpp que corresponden al entregable.

Lo mismo para las maquinas de estados.

Ninguno de estos entregables se corresponde con los entregables del documento de presupuesto. En caso de que alguno de ellos agrupase a varios, deberíais claramente indicarlo en una forma más fácil de visualizar. Una tabla sería lo oportuno para poner en un lado los entregables acordados y en otro los entregados, con los detalles que queráis hacer constar. Tal como está, no es aceptable. De hecho, lo más directo sería no evaluar la entrega por no corresponderse a lo acordado.
Los documentos entregables están todos en formato ODF excepto uno en formato PDF. ¿A qué se debe esto? La falta de uniformidad es un mal síntoma y no debe transmitirse a una entrega. Lo adecuado es entregar todo los documentos en un formato no-editable que pueda ser visualizado con programas libres en cualquier plataforma, como PDF. Entregar los documentos en formato ODT es aceptable, por ser libre, pero no es apropiado a no ser que se requiera que sean editables por algún motivo.
Los documentos deberían estar enlazados o indicados en la entrega, asociados a los entregables que corresponden. En su defecto, deberían llamarse idéntico al entregable que representan o incluir, al menos, el número de referencia del entregable. No haciéndolo así favorecéis la confusión y la sensación de que es el evaluador el que tiene que hacer el "matching" por aproximación. Esto es contrario a una entrega fácil e intuitiva para el evaluador.

Evaluación de Entregables

Documento de diseño de mecánicas de los NPCs (22h - 2,00)

Al comienzo del documento decís:

Recordemos que los enemigos tienen unas características importantes (grado de sospecha y batería) que varían en el tiempo y determinan algunas de sus acciones.

Esto no es forma de introducir un documento. Si el documento va de mecánicas, habrá que indicar que este documento es de mecánicas y en qué consisten (muy brevemente) y, si es necesario, indicar que otra información debe ser consultada (otros documentos). Si es conveniente resumir las características de los personajes, debería haber un apartado para ello, poniendo todas las características. De todas formas, esto tiene más que ver con la toma de decisión que con las mecánicas. Las mecánicas es lo que pueden hacer, independientemente de cómo decidan hacerlo.

La estructura del documento es mejorable. La estructura debe servir para esquematizar y permitir visualizar rápidamente los contenidos. Si hay distintos tipos de NPCs, debería haber un índice inicial, o tal vez una tabla con las principales características o diferencias. Lo mismo para las distintas mecánicas de cada enemigo. Hay muchas formas de estructurar esto (en forma de árbol, en forma de tabla de doble entrada enemigos/mecánicas, etc.). Lo importante es mostrar esa estructura e información visualmente. Con un documento lleno de texto como este, su utilidad se reduce.
No hay clasificación ni distinción entre las mecánicas por nivel de realización. Todo son mecánicas de alto nivel. No hay mecánicas de movimiento básico, ni de acciones simples e inmediatas (coger, dejar, disparar, golpear, etc). Las mecánicas como patrullar o vigilar son mecánicas compuestas que deberían utilizar mecánicas más simples. De hecho, se trata de comportamientos que bien podrían ser diseñados sobre las mecánicas básicas.
Los bocetos no deberían estar al final. Los bocetos deben estar en el punto del texto en el que el lector los requiera para entender las mecánicas. De hecho, los bocetos deberían ser la base para mostrar cada una de las mecánicas de forma esquemática, visual y clara, no el texto.
En muchos casos, no estáis definiendo las mecánicas, sino que especuláis respecto a la forma hipotética en que los NPCs deberían decidir cómo llevarlas a cabo. Por ejemplo, en Patrullar ponéis:

Habrá varias rutas predefinidas básicas en cada parcela de terreno (entre una y tres por enemigo dependiendo del escenario y de la cantidad de enemigos en la parcela), el enemigo empezará aleatoriamente en una de ellas y escogerá al final de cada una dependiendo de la cercanía de las mismas y de la posición de sus compañeros. Las rutas estarán diseñadas de manera que haya puntos de conexión entre ellas.

Esto habla de rutas en el terreno, forma de elegirlas y forma en que estarán diseñadas. Esto no tiene nada que ver con lo que deberíais poner. Se supone que tenéis que definir la mecánica Patrullar. Es decir, tenéis que decir en qué consiste patrullar, de qué acciones se compone, cómo se lleva a cabo. No tiene nada que ver con cómo se decide. Por ejemplo, tendríais que decir que patrullar consiste en seleccionar una ruta y seguirla punto a punto. O bien, que consiste en seleccionar un área y recorrer su perímetro en sentido horario. O seleccionar un área e ir moviéndose por ella seleccionando puntos aleatorios cada cierto tiempo y cambiando de lugar. Eso es la definicioń de en qué consiste la mecánica de patrullar. Después, habría que analizar de qué otras mecánicas/acciones de más bajo nivel se compone, puesto que es una mecánica de alto nivel.

Si una mecánica requiere de rutas, habrá que definir también qué son las rutas y de qué estan compuestas. Esto es un concepto aparte, por lo que no debería estar definido en texto dentro de una mecánica. Si es un concepto, debería haber un apartado de conceptos de apoyo, donde estos conceptos estén bien definidos. Después, si la definición de Patrullar usa este concepto, no tiene que estar explicándolo, complicando innecesariamente su definición.
En general, no definís las mecánicas. Habláis de cómo se usan, quienes las usan o cómo deciden. Nada de eso define lo que son las mecánicas y cómo se realizan. Por ejemplo, en la mecánica Vigilar, comenzáis diciendo:

Ciertos enemigos permanecerán en este modo por defecto, para potenciar alguna característica del escenario.

¿Y la definición de qué es Vigilar? ¿Se da por supuesto? Entonces, ¿Cómo la diseñamos luego? ¿Se lo inventa quien lo vaya a diseñar?

El documento en general tiene un exceso enorme de texto que no viene al caso. Muy pocas frases del documento se refieren de verdad a lo que de verdad importa aquí, que es definir las mecánicas conceptualmente.
Los bocetos tienen que ayudar a ejemplificar qué son las mecánicas y cómo se realizan, que es el cometido de este documento.
Faltan muchas mecánicas por definir, ya que sólo os habéis centrado en describir comportamientos de alto nivel. No hay mecánica de moverse, de ver o de oír, por ejemplo.
Los bocetos se limitan a describir pasos de una situación concreta de detección del personaje e inspeccionamiento de una zona. Pese a que estos bocetos y situaciones son útiles, puesto que describen lo que debe suceder en ese caso, se echan de menos bocetos individuales descriptivos de cada mecánica en los que se apoye su definición para tener una imagen visual de lo que estamos hablando, qué es y cómo funciona.
Por otra parte, las mecánicas no deben agruparse. Pueden estructurarse y clasificarse, pero cada tipo de ataque es una mecánica concreta. No puede ponerse una única mecánica "Atacar" y definir dentro, en texto, que hay distintos ataques. Cada tipo de ataque es una mecánica.

Este documento, al no contener lo que debería, queda como "No evaluado", en espera de una nueva entrega.

Documento de diseño de sistemas de toma de decisión (24h - 2,18p)

Este documento tiene un formato casi nulo, y distinto del documento anterior. No es lógico que un mismo equipo produzca documentos con formatos distintos.
El documento no se llama igual que el item entregable asociado, ni usa su referencia.
El documento debería contener un diseño de los sistemas de toma de decisión. Por diseño, en ingeniería, se entiende una descripción esquemática de los sistemas, su estructura e interacción. Estamos hablando de diagramas y definiciones de datos de entrada, procesamiento y datos de salida. Evidentemente, esto no puede hacerse en 1 única página de texto descriptivo, que es lo que se ha entregado.
Como información visual se aporta únicamente un boceto manual de definición de variables y reglas para la lógica difusa. Aunque esta información es relevante cara al diseño, es completamente insuficiente. ¿Cómo funciona el sistema de lógica difusa? ¿Qué datos de entrada usa y cuál es su salida? ¿Con qué otros sistemas interactúa? ¿De qué partes se compone? Todo esto debería mostrarse visualmente, en forma de diagramas esquemáticos. En forma de diseño.
El texto divaga sobre situaciones semigenéricas y decisiones potenciales a tomar. Todo esto forma parte de lo que debería ser el análisis de la toma de decisión, pero no del diseño. El diseño es la forma que se le da al sistema: qué datos obtiene, cómo los procesa, en qué órden, con qué prioridad, y qué salidas dá. Además, se habla de sistemas, porque se entiende que habrán varios, con su interacción. Ese diseño debe ser visual, esquemático, mediante diagramas. El texto puede servir de apoyo a la explicación de algunas partes. También es posible incluir los análisis como una parte del documento, pero falta lo principal, que es el diseño.

Al no ser lo que se pedía, el documento queda como "No evaluado", a la espera de otra nueva entrega.

Documento de diseño técnico de la arquitectura de la IA (20h - 1,82p)

Al igual que los anteriores documentos, el texto está escrito mayoritariamente en futuro. Esto indica claramente que no se ha hecho lo que se pedía, sino que se tiene intención de hacerlo en el futuro. Sólo por esto, el documento no puede ser evaluado, porque el trabajo no está hecho.
El único diagrama que se adjunta es una especie de diagrama de clases, difícil de entender y, aparentemente, con iconografía no estándar. El diagrama tampoco tiene mucho sentido, lo que identifica que escásamente se le ha dedicado tiempo, que no se ha implementado ningún prototipo y que no se ha trabajado en él. El resultado, evidentemente, es un intento de cubrir el expediente del documento que se pide como entregable. No parece que haya intención real de definir la arquitectura para ser útil para el grupo.
En este documento deberían estar los diagramas que describan la implementación de toda la IA al detalle. Es decir, si alguien recibiera estos diagramas, debería ser capaz de implementar el mismo sistema que vosotros hayáis implementado.
Al contrario de lo que se suele decir, este documento no debéis producirlo antes de programar, sino en paralelo. Deberíais ir haciendo prototipos e ir construyendo a la par sus diseños y su implementación. Esto os ayudaría a razonar mejor sobre los diseños y sobre el propio código que implementáis. Ambas cosas, implementación y diseño, deben tenerse siempre presentes y mutuamente actualizadas. De esta forma, cada uno de ellos sirve para razonar sobre el otro y ambos para entender la globalidad. En ese estado es cuando los diagramas tienen utilidad y pueden comunicar fielmente lo que se está diseñando/implementando. Si no se hace así, los documentos no tienen valor ninguno y no sirven al propósito previsto.

Al igual que los anteriores documentos, queda sin evaluar, pendiente de una nueva entrega.

Diseño de requerimientos y funciones de red (25h - 2,27p)

Al igual que en anteriores documentos, los requerimentos y funciones de red se presentan en un texto especulativo sin estructura. No es posible aceptar un documento sin estructura cuando se pretende presentar un trabajo profesional en el que es de vital importancia aportar una información clara, concisa, útil y, por supuesto, estructurada.
No hay una lista de requerimientos ni de funciones, que son las dos cosas principales que debería contener el documento.

Nuestro juego no se va a caracterizar por una gran jugabilidad en red o un sistema sofisticado en red.

Hablar de lo que no va a tener un juego es muy mala idea en un documento profesional. Es una prejustificación. Causa mala impresión. Encima es lo primero del documento, precondicionando negativamente al lector. NUNCA hagáis esto. Si no va a tener algo, no se habla de ello. No tiene sentido.

Por una parte, tendremos el sistema de clasificaciones, el cual será bastante simple, ya que registrará el tiempo en el que te pasas el nivel y, si estás conectado a la red, lo mandará al servidor y se guardará.

Esto debería estructurarse y esquematizarse. Si se requiere una información y van a haber items que agrupen campos, hay que describirlo estructuradamente. Para esto se puede usar un esquema, un árbol, una tabla, etc. Lo que se considere visualmente más apropiado para transmitir esa estructura y contenido de forma más clara y concisa posible.

Incluso la lista de logros (que sólo contiene 4 logros, por cierto) está puesta sin formato, con caracteres de guión delante puestos a mano. Esto es muy poco profesional y resta utilidad al documento. La estructura visual de un documento transmite información de forma rápida y concisa, sin requerir al lector que lea todo para saber donde está lo que busca.
Nuevamente, el documento queda "No evaluado". Pendiente de volver a ser entregado.

Diseño técnico de funcionamiento del motor de red (20h - 1,82p)

No se entrega como documento independiente ni se hace referencia a él. En su lugar, se incluye un subapartado dentro del documento de requisitos y funcionalidades en el que se incluye un único párrafo de 2 líneas:

El diseño técnico pensado y planteado es muy simple, y consiste en el envío de paquetes obj con la librería de programación cUrl, la cual nos gestionará todo el sistema de guardado y envío de estos paquetes.

¿Cómo que pensado y planteado? Aquí ni se ha pensado ni planteado nada. Tenéis 20 horas de trabajo asignadas a este item, y ¿Sólo presentáis esto? Esto es totalmente inaceptable en una entrega, además de destructivo para vuestra imagen y prestigio. Es preferible no entregar documento a entregar esto, que es una declaración jurada de no haber trabajado nada en el tema.

Arriba tenéis explicado qué se entiende por diseño técnico. Eso es lo que debe ser este documento la próxima vez que lo entreguéis. Por el momento, queda como "no evaluado", pero si entregáis algo más con este aspecto, la evaluación será directamente 0. Tened en cuenta que esto, por sí sólo, fuera de aquí es un suicidio. No puede ser menos aquí.

Gestión de estados de la IA con Máquinas de Estados (25h - 2,27p)

Sólo se incluye un .cpp y un .h en una carpeta. Hay otra carpeta donde hay un ejecutable llamado "ejecutable_difusa_y_estados" que el evaluador necesita interpretar para saber que es parte del entregable previsto con el título de este apartado. Esto es un desastre de entrega. En caso de haber un único entregable para 2 cosas, debería estar especificado en la documentación explicativa de la entrega, tal como se ha comentado más arriba. La explicación que se ha incluido en explicacion.txt resulta confusa en principio hasta que se ven las carpetas. Esto no debería suceder. Seguid las indicaciones más arriba para mejorar las entregas.
El ejecutable muestra enemigos que cambian de estado y el vídeo que acompaña al ejecutable tiene una explicación interesante y adecuada. Habéis hecho bien de comentar los vídeos grabados, pues esa información que se aporta en comentarios resulta relevante para entender lo que sucede. El ejecutable se prueba y funciona correctamente, igual que en el vídeo.
El código resulta muy básico e insuficiente. No tiene sentido presentar un código que no tiene estructuración orientada a objetos en 4º de carrera. Esto es más grave teniendo en cuenta que ya implementáis máquinas de estados más elaboradas para los estados del juego (menú, juego, etc) en Fundamentos. Esto no es aceptable. Puede entenderse válido como primer prototipo, tal como he comentado en clase, realizado en el proceso de aprendizaje. No es aceptable como entrega final, pues indica que no se ha trabajado en los pasos 2 y 3, que ya conocéis.
Se recomienda encarecidamente que vayáis de inmediato a la bibliografía. En concreto, al "Programming Game AI by Example". Ahí tenéis documentación práctica adecuada para implementar una máquina de estados en condiciones.

Sistema de toma de decisión con Lógica Difusa (50h - 4,55p)

La entrega es igual que la máquina de estados: una carpeta con 2 ficheros .cpp y .h, y el "ejecutable_difusa_y_estados". Sin embargo, hay una diferencia. Ni en el vídeo, ni en el ejecutable se aprecia ni se explica en ningún momento la función de la Lógica Difusa. Así como la función de la máquina de estados resulta clara, la de la Lógica Difusa está ausente y no se precibe. Esto implica directamente una evaluación negativa, pues los entregables deben ser funcionales.
Respecto al código, el comentario es idéntico también al de la máquina de estados. Lo aportado no tiene estructura orientada a objetos y no sería ni aceptable como práctica de 2º en ninguna asignatura de programación orientada a objetos. Como ingenieros, no podéis hacer implementaciones de sistemas de toma de decisión como si fueran scripts de shell. Tenéis que mostrar un trabajo más elaborado. Evidentemente, estamos en el mismo caso de arriba: estáis entregando la primera y única implementación hecha. Al no haber ciclos de rediseño y mejora, lo que se entrega es básico. Esto requiere más trabajo y volver a entregar.
De igual forma, la documentación adecuada para implementar Lógica Difusa la tenéis en "Programming Game AI by Example". Así pues, leedlo detenidamente y rediseñad lo que habéis entregado. Por otra parte, aseguráos demostrarlo y comentarlo en vídeo igual que habéis hecho con la máquina de estados. El vídeo es un buen punto a favor, no lo perdáis.

Sistema de gestión de eventos (Trigger System/Event Manager) (55h - 5p)

No realizado. Queda como "No entregado", a la espera de ser entregado en siguientes hitos.

Sistema de percepción sensorial (vista, oído, olfato, canales…) (32h - 2,91p)

El sistema de percepción sensorial es básico, pero se percibe operativo y funcional. Eso sí, la implementación es inaceptable. No es posible tener implementados los sensores directamente en una función en el main e integrado en el código del programa principal. Esto sirve como primera prueba para ver cómo van las cosas, pero no como entrega. No insistiré más en este punto, porque está claro después del análisis de los otros ejecutables.
Evidentemente, se entiende que el juego principal carezca de esta implementación de sensores de vista y oído, ya que no es un sistema independiente que pueda ser utilizado por el juego, sino una implementación ad-hoc que no puede ser utilizada fuera de este entregable.
El vídeo está muy bien realizado y muestra el funcionamiento correctamente. La ejecución funciona igual que el vídeo. Sin embargo, en la ejecución se observan problemas cuando el personaje pasa por detrás del enemigo. Parece ser que tenéis algún problema con los ángulos o con la comprobación.
Al igual que los demás entregables, este necesita mejora y debería ser mejorado y vuelto a entregar en futuros hitos.

villagra-abp / Iki

Entregables V1 Hito 1 - Ikigai #8