Comentario Global

Las entregas se han realizado enlazando a carpetas 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. Si se quiere, estos ZIPs pueden ser enlazados, aunque es mejor que fueran adjuntos. Si no se puede, siempre es mejor que los ZIPs no estén alojados en el repositorio: tiene que haber una clara separación entre entrega y desarrollo. En última instancia, si no se tiene otra posibilidad, se pueden entregar enlaces a ZIPs del repositorio, pero no enlaces a carpetas. Todo debería estar siempre en un único fichero. Si se quieren carpetas, esa estructura debería estar dentro del ZIP.
Debería haber un documento principal de la entrega donde esté presente la tabla con los entregables acordados y los entregados, sus enlaces, detalles y cuestiones que sean relevantes para el evaluador. Este documento podría ser el propio Issue, pero igualmente debería estar bien estructurado para que toda esta información sea muy clara.
Pese a que la entrega contiene todos los entregables especificados y un enlace a cada uno de ellos, resulta muy poco profesional: no hay una referencia clara y ordenada al presupuesto. Debería incorporarse el presupuesto del hito 1 a la entrega para poder ir enumerando los entregables y haciendo referencia al presupuesto. 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. De hecho, 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 en formato PDF visible en cualquier sistema operativo con visores libres o, como mínimo, gratuítos. Esto es oportuno. Mantenedlo así.
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 puede resultar confuso ya para el evaluador. Estos detalles son muy relevantes si se quiere hacer una entrega profesional. Sed escrupulosos con estos detalles en próximas entregas.

Evaluación de Entregables

Documento de diseño de sistemas de toma de decisión (8h - 0.73p)

El documento se llama TomaDeDecision.pdf. Sería conveniente que se llamara como el entregable y, a ser posible, que incluyera el número de referencia de entregable.
Se esperaba un documento de diseño. Los diseños deben estar hechos en base a bocetos, esquemas y diagramas, no en texto. El texto descriptivo puede ser útil para matizar partes del diseño, pero a un documento que es todo texto no se le puede llamar propiamente "diseño". Además, este documento estaba pensado para ser referente a los SISTEMAS de toma de decisión, es decir, los algoritmos, las estructuras y los métodos que se van a desarrollar para tomar decisiones, no a las mecánicas. El documento debería mostrar diseños de los distintos sistemas a utilizar, datos de entrada que requieren, comunicación entre ellos, métodos de proceso de cada sistema y datos de salida. Nada de eso está presente en este documento. Este documento sería más acorde si fuera definido como mecánicas de los NPC, y tampoco sería 100% acorde.
La mayoría del texto está redactado en tiempo futuro, lineas hipotéticas y condicionales. Quiere decir, que es un documento plenamente especulativo. Todo lo contrario a lo esperado: un diseño concreto de lo que se hace.
Los textos son vagos, imprecisos y generales. Es un contenido muy informal y nada ingenieril. Un diseño tiene que ser concreto, minucioso, estricto y detallado.
Dado que el contenido no es el esperado, el documento queda como "No evaluado", a la espera de una nueva entrega.

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

El documento incluye diagramas de clase de los distintos sistemas de la IA. Estos sistemas deberían haber estado presentes en el documento de "Diseño de sistemas de toma de decisión". Ahí debería haberse diseñado datos de entrada y salida y capacidades de procesado, además de comunicación entre sistemas.
No hay una arquitectura global de la IA. Sólo hay diagramas de clases de los distintos sistemas. Parte de los contenidos que deberían mostrarse en diagramas de arquitectura general están perdidos entre los textos que acompañan a los diagramas.

Toda la lógica se realizará en la clase MachineState, el enemigo tendrá un objeto MachineState que ejecutará los diferentes estados y los cambios entre los mismos.

Esto debería estar diseñado en lugar de explicado en texto. De hecho, en el diagrama aparece una clase Enemy que tiene una asociación con MachineState en lugar de una agregación o composición, como el texto indica. Lo mismo es aplicable a los estados Anterior y Actual. Esto deberían ser agregaciones.

Las aclaraciones sobre el funcionamiento de la ejecución deberían mostrarse mediante diagramas de secuencia. Esto dejaría más claro la interacción entre los objetos y la secuencia temporal de llamadas.
El diagrama de la Lógica Difusa está obtenido de Mat Buckland directamente. Como sabéis, se prefiere diseños propios aunque no sean buenos.
Si la Lógica Difusa va a ser usada para selección de arma, no tiene sentido que pertenezca a un objeto arma. Lo lógico es que la Lógica Difusa perteneciera al Bot para que éste tomase las decisiones de qué arma escoger. Además, tal como está el diagrama de clases, todas las armas van a heredar un FuzzyModule, lo usen o no, lo que tampoco tiene sentido. Lo lógico es que el Bot pueda tener un componente de Lógica Difusa añadido mediante agregación. Eso sería más razonable. En el peor caso, una simple Agregación sobre la clase EnemyBot sería lo más básico y suficiente.
El pathfinding no está definido. Esto no deberíais hacerlo nunca. Poner un apartado de un sistema importante sin definir (1 línea nada más!) es peor que no ponerlo.
El diseño del sistema de percepción no tiene sentido. Se supone que el robot debe percibir y, para eso, le hace falta disponer de sentidos. La memoria no puede funcionar por sí sola si no recibe información a partir de los sentidos. El diagrama de clases de este sistema es una expansión de los diagramas anteriores al que se ha añadido un sistema de mensajes inconexo y una clase "SensoryMemory" integrada por composición en Enemy que no parece tener ningún sentido ni cometido. No parece haber ningún tipo de diseño real tras este apartado. Falta trabajarlo más. Por otra parte, el diagrama está cambiado, ya que el FuzzyModule aparece compuesto directamente sobre la clase especializada Granada y no sobre la clase Weapon que había en el diagrama anterior (que ahora no existe). Este diagrama no está revisado, actualizado ni supervisado. Contiene demasiados fallos.

El bot enemigo tendrá un sistema de memoria que irá almacenando cuando ha visto a un enemigo, o cuando escuchó un sonido.

Estas son las cosas a las que no atiende el diagrama. ¿Cómo perciben los sonidos? ¿Cómo ven? No hay diseño para los sensores.

Además el bot enemigo dispondrá de un sistema de selección de objetivo.

Nuevamente, hablar de cosas que no se han diseñado, en genérico, en un documento de arquitectura, no tiene ningún sentido. Los documentos de arquitectura deben ser un reflejo directo de lo que se implementa. La implementación y este documento deben ser ambos reflejos de lo mismo. Alguien que obtenga estos diagramas debe ser capaz de implementar un sistema idéntico al vuestro. Esto aún no está a la altura.

Aún así, dada la baja cantidad en horas que habíais asignado a este item, considero que es válido como tal y será evaluado. Aún así, es extremadamente recomendable que mantengáis los diagramas vivos y los vayáis actualizando conforme implementáis. Los diagramas actualizados son una fuente muy útil de reflexión para diseño y añadido de características nuevas, así como para entender mejor cómo funciona todo y poder incluso depurar.

Diseño de requerimientos y funciones de red (5h - 0.45p)

En el documento de requerimientos se han especificado sólo unos pocos requerimientos de alto nivel, no especificando requerimientos y funciones necesarios para construir los requerimientos especificados. Por ejemplo, es necesario poder conectar a un cliente para poder conectar varios. Debería poder detectar desconexiones, imagino, desconectar clientes, detectar el lag, etc. Respecto al juego, es de esperar que permita peticiones de cambio de posición o de movimiento, de disparo, de respawn, etc. Todos estos requerimientos son necesarios y deben ser contemplados y analizados. Si no se contemplan, ¿Cómo se van a implementar? La respuesta es obvia, los estáis implementando directamente, pero no reflexionáis sobre ellos más que mientras implementáis.
Para que este documento esté correctamente actualizado deberíais mantenerlo conforme avanzáis en el desarrollo de vuestro motor, teniendo en cuenta todos los requisitos reales y todas las funciones pormenorizadas.
Está bien que hayáis incluído los diagramas de secuencia, cosa que también debería estar presente en el diseño técnico. De hecho, los diagramas de secuencia son más parte del diseño técnico que de este documento, ya que aquí sólo hay que definir los requisitos y funciones, no cómo se implementan.
Tenéis algunas funciones descritas con demasiado detalle y mal generalizadas. Ejemplo:

Visualizar de balas en el cliente que se está ejecutando tanto de las que dispare el propio player como de las que disparen los diferentes enemigos.

Esto sería más lógico indicarlo en un item global como "funciones de información estadística" en el que definierais todos los datos concretos estadísticos que deben compartir servidor y clientes. Una lista bien estructurada y pormenorizada de datos, junto con sus necesidades de actualización, sería muy adecuada en este caso. Ahí agruparíais balas, rockets y granadas, por ejemplo, en datos de personajes, que podríais fácilmente estructurar. Así terminaríais requiriendo estructuras de datos que deben compartirse y mantenerse sincronizadas, por ejemplo. Eso os deja una funcionalidad de sincronización de estructuras de datos (u objetos) y una lista de requerimientos de sincronizador de distintas entidades, junto con los datos que deben ser sincronizados y sus necesidades particulares.

Aplicar un impulso a los enemigos que reciben el impacto de un rocket.

Igual que antes, la función debería ser "Aplicar impulsos a personajes" y podríais agrupar requisitos de tipos de impulsos y situaciones en las que son aplicados.

Este documento es muy mejorable. Se evalúa teniendo en cuenta las pocas horas asignadas, pero debería rehacerse con un contenido más apropiado.

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

No es aceptable describir en texto un diseño técnico de funcionamiento. Menos aún en un texto que no llega ni a ocupar una página, es genérico, habla de 3 o 4 cosas sueltas y las describe sin ningún atisbo de seriedad ingenieril, ni de detalle técnico, ni precisión, ni análisis. Esto es un texto para cubrir el expediente. Además, me parece muy mal que tengáis esto teniendo implementado el motor de red. Aquí debería estar un reflejo fiel y detallado de cómo está actualmente implementado. Debería estar el protocolo, los objetos de red, la implementación de las distintas funciones y su propagación por los sistemas cliente y servidor. No hay nada de todo eso.
El diagrama, además, no aclara nada ni tiene utilidad. La parte importante, la comunicación, se resuelve con un "Envían paquetes" que no significa nada. Es como si un arquitecto resuelve la base de una casa poniendo "Aquí van cimientos", sin cálculo, sin estructuras, sin contenido. No es admisible.
Es necesario definir el protocolo de comunicación en global, con todos los mensajes implicados y sus secuencias. También sería importante incorporar diagramas de secuencia de las distintas acciones de alto nivel compuestas por varios mensajes. Es importante definir todas las estructuras de datos y objetos que son enviados a través de la red en los distintos mensajes. Al igual que antes, para que un diseño técnico sea un buen diseño, debe dar toda la información necesaria para implementar el mismo motor de red. Si no se puede a partir del diseño, no es un buen diseño.

Este entregable quedará como "No evaluado" a la espera de una nueva entrega.

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

Se entrega una carpeta con el ejectuable comprimido, unas instrucciones y un vídeo demostrativo.
El vídeo demostrativo está bien y muestra lo principal que es el funcionamiento de eventos provocados por triggering directo. Se podría haber ampliado con otros tipos de eventos y con alguna visualización adicional esquemática del funcionamiento del gestor de eventos, pero en general está bien.
El ejecutable se ha probado y funciona.
Queda una duda al ver la ejecución respecto a por qué determinados objetos vuelven a aparecer tras un segundo trigger que no tiene que ver con esos objetos.
No puede hacerse una evaluación profunda al no haber entregado el código fuente. No se acepta una indicación de ir a ver el proyecto al repositorio. Debería haber una entrega del código fuente siguiendo las instrucciones de entrega que se han mencionado aquí. No estando esa entrega, no se valora el código fuente. Por este motivo, la nota tendrá una indicación de revisión a la espera de que entreguéis el código fuente como es debido en próximas entregas.

Multijugador en tiempo real (110h - 10p)

Al igual que la anterior entrega, un ejecutable comprimido, instrucciones y vídeo.
El vídeo, al igual que el anterior, es bastante completo. Los comentarios verbales son muy apropiados para entender lo que sucede. Tan sólo se echa de menos poder comparar varias pantallas de distintos clientes para ver los funcionamientos. Podríais grabar vídeos simultáneamente en varias máquinas y después componerlos con un programa de edición. Sería bastante ilustrativo y mucho más interesante para el evaluador que individualmente no puede hacer los mismos experimentos que varias personas a la vez sí pueden.
Los ejecutables se prueban y funcionan.
Al igual que antes, la falta del código fuente impide la evaluación profunda, por lo que el entregable estará evaluado con una indicación de revisión en la próxima entrega.

emf31 / LastBullet

Entrega Hito 1 #4

Postproducción Digital

Proyectos Multimedia

Realidad Virtual

Videojuegos I

Videojuegos II