Comentario Global

Las entregas se han realizado enlazando a archivos que se encuentran en el repositorio. Esto no debería hacerse. Las entregas deben ser independientes del contenido del repositorio. El repositorio es para trabajar y los archivos contenidos podrían cambiar. Se deben entregar ficheros ZIP específicos de entrega, limpios de todo lo que sobre del repositorio. Esto es especialmente relevante cuando los enlaces apuntan a carpetas.
Nota: Aunque algunos enlaces se han dado a ficheros ZIP, estos no deberían estar en el repositorio. Deberían ser adjuntos al issue de github, como primera opción. Si eso es inviable, deberían ser enlaces a algún sitio fuera del repositorio donde los entregables estén alojados, con sus .ZIP. En última instancia, y sólo si no hay más opciones, los ZIPs pueden estar en el repositorio, pero cada enlace debe ser a un ZIP con todo lo que se quiere entregar. Nada que se quiera entregar debe estar fuera del ZIP del entregable, a excepción, en su caso, de los vídeos demostrativos. Estos pueden estar enlazados dentro del entregable a Youtube o Vimeo, por aquello de ser archivos potencialmente muy grande y cumplir una función meramente demostrativa.
La entrega es muy poco profesional: aunque se han incluído ordenadamente enlaces a todos los items entregables en el issue, algunos no quedan claros y hay uno que falta y no está indicado. Debería incorporarse el presupuesto del hito 1 a la entrega, enumerando por un lado todos los entregables acordados en prespuesto de forma clara, y aportando los links a todo lo acordado (o indicando la falta, en su caso). El presupuesto es el contrato, y es la base sobre la que se realiza la entrega. No estando presente, podría no considerarse la entrega siquiera. Así mismo, si los entregables tienen un número identificador o referencia (como así es en V1), sería muy conveniente usarlo para referirse a ellos sin posibilidad de duda.
Los documentos han sido entregados correctamente en PDF. Es conveniente siempre usar formatos legibles en cualquier plataforma con lectores libres o, en su defecto, gratuítos. En caso de necesitar entregar documentos editables por algún motivo (algo poco común) siempre deberían preferirse formatos libres (ODT o RTF) para no obligar al uso de software privativo.
Los ficheros no se llaman exactamente igual que los entregables del presupuesto y tampoco incluyen en el nombre la referencia al entregable que corresponden. Esto resulta confuso ya que el evaluador tiene que ir suponiendo que algunos documentos son algunos entregables por el parecido del nombre. Estos detalles son muy relevantes si se quiere hacer una entrega profesional. Eso sí, por lo menos el issue de la entrega es más específico con los enlaces de los entregables, y sus nombres son exactos. Igualmente, sería apropiado usar, también, el número de referencia del entregable.

Evaluación de Entregables

Documento de diseño de mecánicas de los NPCs (24h - 2.18)

El documento resume las mecánicas para varios tipos de NPCs, pero sin una estructuración clara de los tipos de NPCs y la asignación de mecánicas. Sería más apropiado comenzar con una lista de los NPCs existentes y sus definiciones, una lista de las mecácnicas existentes y sus definiciones y una tabla que relacione NPCs con mecánicas. Presentar la información estructurada permite entenderla mejor y es muy importante en estos documentos.
Las mecánicas deberían estar identificadas individualmente en lugar de simplemente enunciadas. Pueden identificarse por palabra clave, por referencia o por ambas. Por ejemplo, una mecánica podría ser "Oír" o "M01 - Oír" para poder referirse a ella. Después, se puede añadir la definición de la mecánica para que quede asociada a su referencia.
La definición de una mecánica debería limitarse a su funcionamiento, y no a las reacciones que puede provocar en los NPCs, ya que esto es toma de decisión. Ejemplo:

El rango menor les permite oír al jugador incluso cuando se desplaza en sigilo, tiene un radio menor. Aunque te acerques por la espalda en sigilo, si entras en este radio, el enemigo se girará y te atacará.

La mecánica consiste en oír. Debería indicarse (que no lo pone) que los "rangos" se refieren a esferas de radio R alrededor del NPC que puede escuchar. Entonces podría indicarse que todo ruído producido dentro de esas esferas es oído, o que los ruídos A, B y C se oyen pero D y E no, o que los ruidos mayores de X se oyen. Después, sería conveniente en otro apartado definir los tipos de ruido y, aparte, definir una nueva mecánica de producción de sonido. Finalmente, lo de que "Aunque te acerques por la espalda en sigilo, si entras en este radio, el enemigo se girará y te atacará." sobra, ya que no es la mecánica, sino una reacción de un NPC.

Poseen un campo visual amplio, lo que les permitirá detectar al jugador si éste se cruza sobre él incluso en sigilo.

Esto no define para nada una mecánica. Esto es una frase vaga que indica que algunos NPCs poseen un rango visual amplio. Habría que definir la mecánica "Ver", explicar cómo funciona y luego, en la tabla, asignar a los NPCs que pueden ver la mecánica y, en su caso, los parámetros que la definan (distancia, amplitud, etc).
Estas mismas críticas están presentes en todo el resto del documento. Los textos son demasiado escuetos, vagos e imprecisos. Las mecánicas deberían estar individualizadas y definidas. No es necesario que las mecánicas tengan mil párrafos definiéndolas: puede haberlas más cortas y más largas, pero lo importante es que la definición sea precisa.
En todas las definiciones sería más fácil añadir bocetos esquemáticos sobre los que apoyarse para definir el funcionamiento y los parámetros de cada mecánica. No habiendo estos bocetos, será difícil interpretar lo que significan los textos habitualmente.
El documento es muy preliminar y mejorable. Se evalúa, pero se espera una versión actualizada en próximas entregas.

Documento de diseño de sistemas de toma de decisión (26h - 2.36p)

Desconozco el motivo para que este documento tenga un formato distintos al estándar del grupo (no tiene portada, nombres, ni los mismos colores ni apartados), siendo mucho más simple y plano. Esto causa muy mala impresión en una entrega profesional. Es imprescindible que cuidéis estos detalles siempre.
El documento no es lo que se esperaba. Cuando hablamos de diseñar sistemas hablamos de crear bocetos, esquemas y diagramas que modelicen los diseños. En el caso de los sistemas de toma de decisión, además, hablamos de varios sistemas (todos los que vais a implementar) con entidad propia cada uno y que tienen que coordinarse (comunicándose) para actuar como un único motor de IA. Es imprescindible definir estructuradamente los todos datos de entrada que van a utilizar estos sistemas (de forma detallada, minuciosa y completa), diseñar cómo van a procesarlos, al menos a nivel de grandes bloques, y definir qué salidas va a producir cada sistema. Algunas salidas de algunos sistemas pueden ser entrada de otros. Por ejemplo, los sistemas de percepción visual y auditiva normalmente serán entrada para el resto de sistemas, por ejemplo.
En lugar diseños de sistemas, se aportan descripciones en texto. En lugar de sistemas de toma de decisión, se habla de NPCs concretos y tipos de decisiones generales que toman en algunas situaciones. Los sistemas tienen que ser bloques informáticos que procesen la información y deben ser genéricos: no es lógico crear un sistema por NPC. Los NPCs usarán y personalizarán los sistemas, en su caso.
Las descripciones y contenido incorporado quizá sean útiles en otros documentos como el de mecánicas de los NPC. También pueden ser interesantes como ejemplos en este propio documento, pero una vez estén los sistemas diseñados.
Al no ser el tipo de documento solicitado, queda como "No evaluado", a la espera de una nueva entrega en futuros hitos.

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

La crítica es idéntica a los anteriores documentos. Este documento no contiene ningún diseño de aquitectura de la IA. Contiene descripciones en texto de distintos sistemas o algoritmos que formarán parte de la IA. No hay diagramas, ni esquemas, ni tan siquiera bocetos. Un diseño técnico de arquitectura no puede hacerse en texto. ¿Os imagináis a los ingenieros de intel implementando un nuevo procesador utilizando un libros de texto con descripciones de cuántos transistores tiene, cómo se agrupan o dónde van?
La arquitectura de la IA se diferencia de los sistemas en que es armazón principal donde se enmarcan todos ellos. La arquitectura tiene que definir de forma técnica los detalles de cómo funciona vuestro motor de IA al completo: por donde entran los datos, cómo se almacenan, como son comunicados a los distintos sistemas, en qué forma salen, etc.
Para que una arquitectura esté terminada, debería poder ser implementada a partir del diseño que hubiera en este documento, de forma que 2 personas distintas la implementasen igual si siguieran el documento. Así pues, los diagramas son de vital importancia y deben reflejar la implementación directamente. Tiene que quedar claro los datos concretos que hay, los métodos que se usan, los objetos, las clases y sus relaciones. Toda la implementación al completo.
Al no ser lo que se esperaba, nuevamente, el documento queda como "No evaluado", en espera de futuras reentregas.

Diseño de requerimientos y funciones de red 1 1 2.00 15.00 27.00 27.00 2.45

Hay un único documento llamado "Diseño de motor de red.pdf" que ha sido enlazado en la entrega como "Diseño de requerimientos y funciones de red". Se evalúa como este item, por tanto, aún resultando muy confuso.
El documento presenta una descripción muy escueta de algunos métodos y objetos implementados usando Raknet. Toda la descripción está en texto. Esto no son requerimientos ni funciones del motor de red. Los requerimientos deberían ser una lista pormenorizada de todas las acciones que deben poderse llevar a cabo a través del motor de red, como por ejemplo conectar a un jugador, desconectarlo, calcular el lag de un jugador, actualizar su posición, aplicarle un impulso, etc. Los requisitos deben ser agrupados en funciones del motor que permitan cubrir esos requisitos. Las funciones serían aproximadamente equivalentes al API que deben tener servidor y cliente para poder cubrir los requerimientos identificados. Esta API irá asociada a un conjunto de tipos de mensajes que se pueden recibir por la red para lanzar las distintas funciones. Debería estar descrito todo lo que es necesario para que el juego funcione a nivel de red. Todo esto, evidentemente, no es lo que contiene este documento.
Dado que el contenido actual no es el esperado, el documento queda como No evaluado" a la espera de otra entrega en futuros hitos.

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

El único documento de diseño de red se ha evaluado como el documento anterior, por lo que éste queda como "No evaluado" al no estar entregado.
Notas importantes: Un diseño técnico debe aportar los esquemas y diagramas de todos los puntos de la implementación. Un diseño bien hecho debería permitir a cualquier otro ingeniero implementar un motor idéntico al existente. Para eso, los digramas deben reflejar tanto la estructura global de módulos y partes del código como su estructura interna, a nivel de clase y objeto, detallados. Así mismo, un motor de red requiere de comunicación entre partes, lo que necesariamente debe ser diseñado mediante diagramas de secuencia en los que se vean los mensajes del protocolo, sus respuestas y su órden.

Gestión de estados de la IA con Máquinas de Estados (28h - 2.55p)

El ejecutable demostrativo de la máquina de estados se ejecuta y funciona. Es una aplicación de consola que muestra mensajes de distintos agentes. La aplicación no permite seguir el flujo de ejecución ni da tiempo a entender lo que los personajes hacen ni porqué lo hacen. No hay ninguna explicación al respecto, salvo un Readme.txt que indica que los personajes "van cambiando de estado". Este tipo de entrega es muy poco profesional. No queda claro que el entregable hace lo que se esperaba que hiciera. Más aún, teniendo en cuenta que las mecánicas deberían estar completas a estas alturas, entregar un ejecutable en consola es algo que resta muchos puntos desde el punto de vista de un evaluador que espera cosas funcionando en vuestro juego. Es importante que esto mejore en próximas entregas.
Para la máquina de estados utilizáis el modelo de Mat Buckland casi al dedillo. Este modelo está bien, pero deberíais adaptarlo convenientemente a vuestras necesidades. En particular, los estados que tenéis actualmente no hacen nada práctico, ni obtienen información del entorno, ni de sensores, ni hacen que los distintos personajes puedan interactuar entre ellos e intercambiar información convenientemente. Todo lo que sucede en los estados de los personajes, sucede exclusivamente en el interior de sus métodos, con variables locales. Esto no es operativo. Sirve como demostración simple, pero no es una máquina de estados en uso. Deberíais demostrar que la máquina de estados está funcionando para vuestro juego en concreto.
En cuanto a recomendación de código, no deberíais poner todos los estados de un personaje juntos en un CPP. Los estados, además, son singletons porque están diseñados para ser utilizados por distintos personajes o agentes en caso de que se pueda. Sería recomendable que cada estado, al ser una clase, tenga su propio CPP. Si queréis que esto esté límpio, os sugiero estructurarlo en carpetas, en lugar de agrupar en un único CPP.
Para esta entrega tenéis una evaluación parcial, que espero pueda ser nota completa cuando vea vuestra máquina de estados funcionando en vuestro juego. Las bases son buenas, pero falta el trabajo importante: el de integrarlo en el juego.

Sistema de toma de decisión con Behaviour Trees 1 (59h - 5.36p)

Se entrega un ejecutable con su código fuente y un README indicando lo que es. El ejecutable funciona y es una aplicación de consola que va mostrando mensajes de estado de un supuesto NPC con un delay. No queda del todo claro lo que está sucediendo, aunque sea más claro que el ejecutable de máquina de estados. Debería haber una explicación que indicase qué es el personaje, como es el entorno, que factores considera. Al menos, un diseño del árbol de comportamiento que está ejecutando ayudaría a entender lo que está pasando y cómo funciona. Tal cual está, la entrega resulta difícil de percibir en ejecución y más aún de evaluar.
La implementación del behaviour tree es básica pero decentemente bien estructurada.
Hay algunos problemas potenciales con la reserva y liberación de memoria: es poco elaborada y muy tendente al error. Sería conveniente usar patrones fábrica y RAII.
La implementación del estado "Running" en los nodos secuencia y selector es bastante ineficiente. No debería preguntarse uno a uno a todos los nodos para saber si alguno está "Running". Cuando un nodo nos devuelva "Running", deberíamos apuntárnoslo para llamarlo directamente la siguiente vez que nos toque ejecutar, en lugar de olviarlo y luego estar buscándolo linealmente.
Se hace necesario disponer pronto de la implementación del Blackboard, ya que los nodos funcionan de forma aislada y sin posibilidad de obtener información de estado de los personajes y del entorno, cosa que deberían poder compartir los distintos nodos de un árbol a través de un Blackboard.
Por otra parte, los nodos del árbol están diseñados para servir a un único NPC. Esto significa que no se podrán reutilizar distintas ramas de árbol para distintos NPCs, requiriendo crear árboles para cada uno de ellos. Sería más conveniente que un árbol fuera independiente y recibiera el NPC para el que procesa cuando va a procesar. De esa forma, el mismo árbol podría ser utilizado por varios NPCs. Eso permitiría crear subárboles y reutilizarlos en otros árboles, permitiendo una mejor modularidad para la IA.
En cualquier caso, las bases están bien sentadas en este entregable y falta, como en todos los demás, el paso principal: integrarlo en el juego y demostrar su funcionamiento en entorno real, sea el juego funcionando o el prototipo.
Se evalúa con nota parcial y se espera una entrega posterior funcionando sobre el juego para poder dar la nota completa al entregable.

Sistema de búsqueda de caminos y control (Pathplanning/following) (50h - 4.55p)

Se entrega un CPP, un ejecutable y un README. En ejecutable muestra una aplicación en consola de seguimiento de un camino en una matriz 12x12 por distancia manhattan.
El entregable parece una práctica de primero de programación. Todo está implementado en un único fichero CPP, sin estructura orientada a objetos, sin generalidad ninguna, sin arquitectura, sin uso ni validez para ningún sistema de videojuego que se quiera implementar. Esto no es aceptable como entregable de pathplanning del videojuego, ya que no tiene utilidad real ninguna.
Este entregable quedará como "No evaluado" a la espera de nuevas entregas en hitos posteriores.

Comunicación simulada básica entre NPCs (Blackboard) (53h - 4.82p)

Tan sólo un Readme.txt indicando lo que es y que no está hecho.
No evaluado.

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

El entregable contiene un único fichero README cuyo contenido indica que hay un código fuente en una carpeta del repositorio. Esto es totalmente inaceptable como entrega. No se puede entregar un TXT que le diga al evaluador que vaya a buscar a una ruta de desarrollo una entrega. El repositorio es para estar desarrollando constantemente, y debe estar cambiando. Un evaluador NUNCA debería ser enviado al repositorio.
Tanto si se quiere entregar código fuente como ejecutables, debe comprimirse todo en un archivo aislado, fuera del repositorio. Todo lo que el evaluador tenga que evaluar debe estar dentro de ese entregable. No debe ser enviado a ningún otro sitio.
Pese a no tener obligación, por el formato de entrega, se obtienen las 3 clases del código fuente mencionadas en el README. Las 3 clases son esqueletos con casi ninguna línea de código que haga algo en su interior. Exactamente, hay 9 líneas de código aparte de las definiciones de los métodos, divididas en 3 llamadas a un método un if y un else. Evidentemente, esto es mejor no evaluarlo, pues vuestra nota sería bastante mala.
El README sólo indica 3 clases en código fuente en una carpeta. No habla de ejecutables ni nada parecido. Aunque se quisiera, no se podría ejecutar nada, ya que la entrega no lo especifica.
Puesto que la entrega no incluye el contenido a evaluar, queda como "No evaluado" hasta que sea vuelto a entregar.

Sistema de percepción sensorial (vista, oído, olfato, canales…) (36h - 3.27p)

La entrega incluye un README y un vídeo en formato Webm como demostración. El comentario al README es idéntico al entregable anterior. No se debe, en modo alguno, hacer una entrega como esta.
El vídeo muestra el juego en funcionamiento, aparentemente con 1 personaje y 2 NPCs. No queda claro que es lo que el vídeo quiere mostrar, ya que no hay carteles ni iconos indicativos, ni tampoco hay narración que explique lo que está sucediendo. Sería muy importante que los próximos vídeos-demostración incluyan, al menos, comentarios verbales explicando lo que sucede para que se pueda entender bien.
Pese a no tener que hacerlo, se obtiene el fichero Perception_.zip, se descomprime y ejecuta. El ejecutable no funciona por la falta de librerías (libgcc_s_dw2-1.dll y libstdc++-6.dll). Esto tampoco debería pasar en una entrega. Los ejecutables deberían haber sido verificados en máquinas limpias.
Al no haber tampoco código fuente, éste no puede ser evaluado.
Nuevamente, al estar la entrega en una forma no apropiada, el entregable queda como "No evaluado" y se espera sea entregado convenientemente en próximos hitos.

AaronColston / lab21

Entrega Hito 1 #11