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.
La entrega está poco estructurada: No se han respetado los nombres originales de los entregables del presupuesto (se han usado nombres parecidos), tampoco se han utilizado los idetificadores de item. Hay entregables que no se presentan y no hay ningún texto que hable sobre ellos ni indique a qué es debido. No hay explicaciones respecto a los ejecutables que indiquen cómo deben ser usados, dónde han sido probados, etc. No hay explicaciones sobre el código fuente y sus herramientas de compilación. De hecho, no hay explicaciones en general: sólo una lista de enlaces. Debería, al menos, haberse hecho referencia a todos los entregables del presupuesto, indicando cuáles son, sus costes, su estado de desarrollo, sus ZIPs de entrega e instrucciones necesarias.
Las explicaciones de uso de los ejecutables están en archivos de texto incluídos dentro de las carpetas. Esto debería estar mejor estructurado. Si un entregable requiere explicaciones, su estructura lógica serían 2 cosas: un fichero leeme/instrucciones/similar y una carpeta con el entregable. Todo detro de un ZIP. El evaluador no debe estar buscando las cosas: deben ser obvias para evaluar.
Los vídeos demostrativos están incluídos en las carpetas de los ejecutables. Nuevamente, esto no debería ser así. En caso de entregar los vídeos de forma directa, como se ha hecho, deberían estar al mismo nivel que el fichero leeme/instrucciones/similar, fuera de la carpeta que contiene la entrega. Otra opción es poner el vídeo en una plataforma online (como Youtube o Vimeo) y aportar un enlace. Esta última opción es más razonable para no tener que entregar grandes archivos sólo por los vídeos.
Uno de los entregables ha sido llamado "Sistema de Toma de Decisión de los NPC". Esto no cuadra con niguno de los entregables que hay en la hoja de presupuesto. Eso significa que toca deducir qué es lo que el entregable incluye, que tampoco está espeficiado en la entrega. Esto es un error muy grave. No es posible que un evaluador reciba entregas que tiene que deducir lo que son.
Los documentos se entregan en formato privativo DOCX. Esto obliga al evaluador a disponer de MS Word. Una entrega de un documento terminado debería realizarse en un formato que disponga de visores gratuitos como mínimo en cualquier plataforma (PDF, por ejemplo). En su defecto, o en la necesidad de que se entregue en formato editable, deberían usarse estándares abiertos que no requieran de una herramienta privativa específica (ODT o RTF, por ejemplo).

Evaluación de Entregables

Documento de diseño de mecánicas de los NPCs

Los textos del documento no se entienden. Una frase como la siguiente:

El NPC se desplaza siguiendo el nodo del sistema de decisión de Behaivour Trees, donde se desplaza 0.5 en cada iteración. Comprueba el camino más corto hacia la posición final: (posFin – posIn)2. Esta fórmula es la que usaremos siempre que queramos calcular la posición más cercana de algo.

No tiene ningún sentido por sí sola. Además, una mecánica no puede definirse a partir de una técnica de implementación. La mecánica define cómo va a comportarse y eso no debe tener que ver con la implementación. Debe ser una especificación que sirva luego para poder decidir cómo quiere implementarse. La especificación debe ser autocontenida: se tiene que entender sin hacer referencia a otros documentos o técnicas.

No se sabe cuánto es 0.5 (0.5 metros? centímetros? píxeles?), ni cada cuánto sucede una iteración. El camino más corto ¿De dónde a dónde? No se ha hablado de mapa, ni escenario, ni forma de ubicarse, pero hay un camino más corto. Las posiciones posFin y posIn se restan, ¿Son vectores? ¿El camino más corto es siempre una recta?

Esta no es forma de definir mecánicas. La forma adecuada es partir de uno o varios bocetos que permitan hablar de la mecánica, su ubicación comportamiento espacial (si hay), su comportamiento temporal, cuándo se produce, quién la produce, cómo y qué consecuencias tiene. ¿En qué consiste la mecánica? ¿Qué personajes la realizan? ¿Cómo? ¿Dónde se realiza? ¿Cuándo?

En la misma mecánica de Desplazarse se habla de Andar y Correr, sin haber hablado antes de que ambas cosas son mecánicas posibles. Igualmente se habla de Animaciones, cosa que no tiene sentido cuando hablamos de mecánicas, y nuevamente se hace como si el lector supiera ya que las hay, como son y cómo funcionan. Son cosas independientes. En los cuadros, las velocidades no tienen unidad. No se sabe a cuánto se refieren. Parecen factores de escalado. Si es así, debería indicarse.

Atacar cuerpo a cuerpo: Realizará este ataque cuando compruebe mediante los nodos del Behaviour Tree que la distancia del NPC al jugador es menor que la definida como umbral.

Nuevamente se define la mecánica en función del Behavior Tree. Esto no tienen ningún sentido. Por no decir que el documento no introduce la existencia del Behaviour Tree en ningún momento. La mecánica debería poder definirse como es, por sí sóla. Será un ataque que se produce a una distancia menor que X del rival. No es necesario hablar de la IA.

Dar alarmas: Podrán activarla yendo hasta la posición de la alarma.

Totalmente incompleto. ¿Hay alarmas? ¿Dónde están? ¿Qué efectos producen? ¿A quiénes afectan? ¿Durante cuánto tiempo? ¿Cómo se activan? ¿Quiénes las activan? ¿En qué condiciones?

Una frase como esta es algo inútil para que podáis desarrollar nada. Cuando alguien tenga que implementar esto se lo tendrá que inventar entero, literalmente.

Sin ir más al detalle, todo el documento está lleno de referencias a las técnicas de IA, en lugar de trabajar la concreción de las mecánicas, el qué son, dónde son, cómo son, cuándo se producen, etc. Los bocetos están al final, en lugar de estar en el sitio donde realizáis las definiciones y usarlos para referirse a ellos. Los bocetos deberían ser la base sobre la que se definen las mecánicas. Además, en los bocetos aparece contenido del que no se habla en el texto y no tiene explicación. Por ejemplo, en el boceto "Dar Alarma" pone "Estado" y hay 3 posibles: alerta, combate y asustado. ¿Qué tiene que ver con Dar la alarma?

Muchos bocetos no son bocetos, son listas de ideas. Las listas de ideas están bien para esquematizar lo que uno quiere hacer al principio, pero hay que dibujar las situaciones, las realidades del juego. Hay que recrear los mapas, los personasjes, las circunstancias. Tiene que quedar claro lo que va a pasar, como y dónde.

Los pocos bocetos que tenéis son muy iniciales: no habéis profundizado en ellos. Están bien como comienzo, pero requieren más trabajo para detallar las cosas que importan. Si los enemigos tienen tipos de disparo, hay que dibujarlos y esquematizar las partes importantes: altura, velocidad, tamaño, distancia de alcance, daño que infrigen, frecuencia de disparo, coste... ¿Cómo va el jugador a enfrentarse a estos disparos? ¿Cuándo se producen? Dibujar estas situaciones e imaginar cómo se perciben, esquivan, repelen, etc. Hay que trabajar los detalles de cómo funcionan las cosas y visualizarlos.

Documento de diseño de sistemas de toma de decisión

Está mejor enfocado que el documento de mecánicas, pero muchas cuestiones incluidas siguen siendo vagas, imprecisas y poco estructuradas. Por ejemplo, al hablar del estado Estándar:

Estándar: Es su estado inicial, es podría llamar estado de tranquilidad, las decisiones llevadas a cabo son de autoabastecimiento (comer, bebe y curarse), rutinas (Hablar, Vigilar y Patrullar) y acciones por eventos externos (buscar ruido o responder un aviso).

Se enumeran una lista de acciones, las que identifican claramente distintas mecánicas de distintos niveles de abstracción. Las mecánicas de Vigilar y Patrullar no están definidas en el documento de mecánicas. Todas las acciones posibles de los NPCs deberían estar claramente definidas para poder hacer uso de ellas en la toma de decisión. Cuando se toma una decisión de alto nivel "Ahora toca patrullar", la acción de patrullar debería estar definida bien como una mecánica o bien como un conjunto de mecánicas (un objetivo que agrupará varias acciones a realizar de forma ordenada, usando las mecánicas).

Todo esto debería estar definido y estructurado. Hay mecánicas de realización inmediata (moverse 1 hacia la izquierda) y hay otra de acción prolongada en el tiempo (Patrullar, ir hasta la Alarma). Deberían identificarse estos distintos niveles de mecánica y realizar una lista de todas las mecánicas posibles en cada nivel. Con esas mecánicas es con lo que construiréis la forma de actuar de vuestros personajes en base a las decisiones.

En el estado Combate pone: [...]el cual decida pedir ayuda o en el peor de los casos se asuste.. Sin embargo, no queda claro en qué estado se producirá una petición de ayuda, ¿En el propio estado de Combate? No parece lógico. Quizá debería cambiar de estado. O, tal vez, deberíais ponerle otro nombre al estado.

La máquina de estados es muy general, pero puede ser perfectamente válida. Su validez como tal depende de como concretéis todo lo demás que está por concretar.

Las explicaciones del Behaviour Tree y sus nodos son incorrectas y/o inexactas. En particular son:

Incorrectos: Violeta, Rojo.
Difícil de entender: Azul.
No se entiende: Blanco.

Además, el estado "Running" deben poder devolverlo todos, no sólo los nodos Acción (Verdes), ya que los nodos que reciben ese estado deben propagarlo hacia sus padres, o se perdería y no sería útil.

Es totalmente imprescindible aclarar el funcionamiento de los nodos Blancos.

Los árboles tienen buen aspecto. No se analizan en detalle. Se asume que deberán ser modificados conforme avance la implementación y se vean en funcionamiento. Es muy importante que se vaya actualizando el documento con los cambios que se vayan haciendo a lo largo del juego. Mantenerlo actualizado servirá para reflejar en todo momento el estado actual del proyecto.

Los bocetos apenas se ven debido a la resolución y la forma en que se han fotografiado. Para la próxima vez, es mejor que se tomen buenas fotografías y se añadan a un tamaño mayor, aunque suponga tener más hojas. También se recomienda que los bocetos se incluyan en el punto del texto al que hacen referencia, para utilizarlos en el texto.

Documento de diseño técnico de la arquitectura de la IA

El objetivo principal del documento es narrar el comportamiento que tomara la IA como base para el videojuego.

Esta definición es incorrecta. Un diseño técnico tiene que reflejar todo el funcionamiento de la implementación. Tienen que quedar claro los bloques, las estructuras de datos, las reponsabilidades de los módulos y las vías de comunicación entre los mismos. Tiene que quedarle claro a cualquier ingeniero cómo está hecho el sistema. Tiene que ser tan claro, que un ingeniero ajeno al proyecto debería ser capaz de implementar lo mismo a partir de las descripciones técnicas.

Para conseguir esto, evidentemente, los diagramas son el apoyo principal que permite visualizar y entender las estructuras.

En este documento, hay un único diagrama general de arquitectura que muestra los distintos módulos y sus vías de comunicación. Los subsistemas se encuentran descritos en texto uno por uno, pero no hay información técnica respecto a los mismos. El diagrama principal está bien en el sentido de que sí describe lo que se busca en el documento: la arquitectura del sistema. Es criticable en cuanto a las dudas que plantea. Por ejemplo, cuando un NPC modifica los datos de su pizarra, ¿Se pierden las modificaciones al terminar su procesado? Esta duda viene dada porque hay una comunicación entre "NPC data" y "NPC Blackboard" en un sólo sentido.

Por otra parte, no hay referencia a los sistemas sensoriales para la percepción de los datos que provienen del mundo. Esta parte debería estar en el diseño porque es importante y está en presupuesto.

Se pueden plantear muchas dudas como esta última. Entiendo que el documento está inacabado como lo está la implementación y el desarrollo de los sistemas. Por tanto, este documento debería continuar evolucionándose conforme cada sistema sea diseñado, implementado y modificado.

Gestión de estados de la IA con Máquinas de Estados

El entregable no ha sido referenciado en la entrega. De los documentos puede deducirse que debe estar integrado en el ejecutable de toma de decisión. Sin embargo, como no hay referencia, ni explicación, ni detalle del entregable, no se evalúa.

Sistema de toma de decisión con Árboles de Decisión

El entregable no ha sido entregado ni referenciado en la entrega. Tampoco aparece en los documentos. Por tanto, no se evalúa.

Sistema de toma de decisión con Behaviour Trees

El sistema de toma de decisión se construye entero en el constructor de una clase llamada Estados. Se sobreentiende que se trata de un modelo similar a una máquina de estados. Este constructor crea todos los árboles de comportamiento (4 en total).

Esta forma de proceder es muy ad-hoc, extremadamente débil y poco práctica. Los errores son difíciles de detectar y tediosos de depurar. Cualquier cambio requiere leer un código muy largo y analizarlo entero para saber dónde tocar. Lo ideal sería que la construcción de árboles de comportamiento estuviera especializada. Debería haber un subsistema que siguiera el patrón de fábrica abstracta o, en su defecto, método de fábrica que se encargase de construir distintos tipos de nodo y/o subárbol. Después, debería haber un subsistema que leyera un fichero de datos (tipo json o xml) y fuera construyendo el árbol a partir de lo que pone en el fichero de datos. De esta forma, con una única llamada a un subsistema, se leería y construiría un árbol a partir de su definición en un fichero de datos. Cualquier cambio se podría hacer fácil y rápidamente con sólo cambiar el fichero de datos.

En cuanto a la "máquina de estados", se reduce a un SWITCH y 4 métodos. Esto no puede ser evaluable como máquina de estados, ya que no tiene estructura orientada a objetos que le dé ningún tipo de versatilidad. Se recomienda leer el libro de Mat Buckland donde está explicado muy bien cómo hacer estructuras de máquinas de estados decentes.

Respecto al Behaviour Tree, todos los tipos de nodos creados están incluídos en 2 archivos: Nodos.hpp y Nodos.cpp. Esto no es la forma correcta de proceder, ya que es una estructura muy difícil de manejar, poco práctica y nada útil para el trabajo en equipo. Lo apropiado sería crear una carpeta para Behaviour Trees con las clases del sistema y una carpeta interior de nodos donde hubieran 2 ficheros por cada tipo de nodo (.cpp y .hpp). Si cada nodo está en sus propios ficheros y la estructura de ficheros es clara, resulta más fácil y rápido de navegar, editar y expandir.

La estructura de los Nodos del Behaviour Tree creada, junto con el sistema de Blackboard para comunicación se ven decentes y funcionales. Requeriría estar más organizado, limpio y comentado, pero su diseño y funcionamiento son suficientes. Se observa, eso sí, que muchos nodos están pendientes de implementar. Sería mejor no crear nodos vacíos a no ser que se estén testeando por algún motivo, e ir creándolos conforme vayan siendo usados.

Gran parte de la IA reside en lo que los propios nodos hagan, por lo que todavía falta mucho por hacer para considerar esta parte terminada. Deberá actualizarse en próximas entregas.

Sistema de percepción sensorial (vista, oído, olfato, canales…)

No hay un diseño técnico del sistema de percepción sensorial en los documentos. No está claro qué sensores deberían tener ni qué, cómo o cuándo deberían percibir información del entorno los NPC. Al no haber una especificación/diseño de esta parte, no hay forma de saber cuáles son los objetivos en este sentido para este proyecto, lo que os lleva también a no tener nada implementado.

El sistema de percepción actual es un bucle for incluido en el update de los NPC que comprueba una lista de objetos uno a uno. Para cada uno de ellos, calcula su distancia al personaje y, si es menor de 10, muestra esa distancia.

Esto no es ningún tipo de sistema de percepción sensorial y no puede ser evaluado como tal. Un sistema de percepción sensorial tiene que tener diseñados cuáles son los sensores a utilizar y debe proporcionar la información a los NPC con una frecuencia especificada por diseño, muchas veces a través de un sistema de eventos. Algunas partes pueden requerir ser llamadas mediante polling en el Update, pero deberían ser partes diseñadas de forma independiente y llamadas desde ahí, no un simple bucle de comprobación todos contra todos incrustado en el Update.

Así pues, esta tarea queda como No evaluada, exactamente igual que si no hubiera sido entregada. Será evaluada en futuras entregas si hay un diseño claro de lo que deben percibir los NPC, tanto a nivel de especificación como de diseño técnico.

srivanov / Vesper

Entrega Hito 1 #11