Práctica 4
Resumen
En la práctica cuatro presentamos un tablero compuesto por cincuenta casillas en una matriz de 10x5. Colocamos el refugio en una casilla aleatoria. Damos la opción al jugador de colocar el héroe en una casilla. Después puede colocar aliados (5 como mucho) y zombis (20 como mucho). Si hay un aliado en una casilla y clicamos, será sustituido por un zombi. Si ocurre esta situación con el zombi, la casilla quedará vacía después de ser clicada.
Problemas a resolver
Teoría de la Decisión
Tenemos que hacer que el héroe (decision maker) identifique la mejor decisión que pueda ser tomada en cada turno. Como se encuentra en un entorno de completa información (conoce el número de aliados activos, el número de zombis y si es de día o de noche) debe calcular con precisión y de una manera "racional".
Razonamiento probabilístico
Hemos seguido el razonamiento del enunciado de la práctica. Tenemos el grafo dirigido a la utilidad, sin ciclos y que hacen una serie de distribuciones dependiendo del camino que se siga.
La probabilidad de cada nodo depende directamente de la de su padre.
Métodos de resolución
Red de Decisión
Tenemos la red de decisión del enunciado. Compuesta por los nodos de azar:
- Zombis: Como máximo abrá 20 en la escena.
Para facilitarnos el trabajo hay tres distribuciones( ningún zombi, menos de 5 o más de 5 zombis).
- Aliados: Seguimos la misma distribución que la de los zombis, abrá como máximo 5 aliados. Las distribuciones son más simples (ninguno, uno o más de uno)
- Luz: Con el clic derecho cambiamos la iluminación de la escena y además las probabilidades de supervivencia del héroe y aliados. La luz se puede cambiar mientras se ejecuta la partida.
Vamos a explicar el siguiente nivel del grafo:
- Situación: Depende directamente de la situación de los nodos anteriores (zombis y aliados). Según el número de actores se darán situaciones favorables, desfavorables o neutrales para el héroe
- Destreza: Depende directamente de la luz y del número de aliados. Este nodo funciona de una manera natural y real. Tenemos más destreza con condiciones favorables (aliados ayudando y con luz en este caso).
- Acción: Solo hay tres acciones posibles para el héroe (Avanzar, retroceder, esperar).
En el último nivel del grafo, dependiente de todos los anteriores, se forma una tabla completa con las probabilidades de todas las configuraciones. De esta tabla en cada turno se escogerá la mejor opción para el héroe.
Herramientas utilizadas
Implementación
- GameManager: Componente que controla todos los aspectos visuales y sobre el tablero.
- PersonajeCasilla: Lo utilizamos para saber qué hay en cada casilla. En el caso de los zombis, también los contabilizamos.
- CreaTablero(): Es muy parecido al de la práctica anterior.
- PonComisaria(): Le ocurre lo mismo que a CreaTablero. La diferencia es que se crea en la parte izquierda. Por la dirección de los sprites de los actores.
- TurnoZombis(): Cada vez que damos al botón Comenzar en la escena, comienza el turno de los zombis
- OnButton****Click(): Administran las funciones de los botones de la escena.
- OnClick(): Primero colocamos el héroe. Después según las indicaciones del enunciado, creamos aliados o zombis en las casillas.
- MoveZombi: componente que controla el turno de los Zombis
- Se encarga del movimiento del zombi como de las batallas con los otros personajes. Gracias a un número aleatorio, a la luz y al número de aliados en el campo de batalla.
- MoveHeroe: componente que controla el turno del héroe
- Se comporta de una manera prácticamente igual a la de los zombis lo único que lo hace en el turno del héroe y sólo sobre un gameObject, el héroe.
Resultados obtenidos
- Objetivos completados
- Objetivos incompletados
- Dificultades
Las funciones visuales de la práctica van a la perfección, lo mantenemos respecto a la práctica anterior. El movimiento y la muerte de los Zombis funciona correctamente y de la forma que esperamos. En situaciones típicas no hay resultados que nos hayan sorprendido.
No hemos realizado la red Bayesiana, nos ha resultado muy complicado la interpretación del ejemplo del asset store, con sus archivos. Hemos decidido hacer la práctica de una forma más sencilla para llegar al resultado que esperabamos
Hemos tenido muchas dificultades intentando optimizar la práctica, con esto nos referimos a no usar GameManager.instance, o GameObject.Find, que son operaciones muy costosas. En algunos casos lo hemos resuelto con creces, pero en otros nos hemos visto obligados a usar estos recursos de Unity.
Relación bibliográfica
https://es.wikipedia.org/wiki/Red_bayesiana