Warrior Quest – Descripción

Filed Under (Ocupación) by Gurk on 26-03-2012

Tags:

Hoy me gustaría comentaros como va a ser el nuevo proyecto de juego que tenemos pensado hacer. Por supuesto, dudo que alcance una calidad aceptable siendo algo que estamos haciendo para aprender, hay tiempo limitado y es de suponer que hay que aplicar materia que aun no hemos dado en clase.

El juego será una clara imitación al primer Dragon Quest. Nuestro héroe caminará por uno o varios mapas y a cada paso tendrá la desgracia de que exista la posibilidad de encontrarse con un enemigo contra el que luchar.

Según va luchando ganará puntos de experiencia si vence al enemigo, pudiendo así subir de nivel. Estos niveles le permitirán la héroe no solo mejorar su estadísticas, sino también aprender nuevas habilidades. No habrá Items, al menos por ahora.

Los combates serán por turnos y durarán hasta que uno de los dos combatientes caiga derrotado al perder toda su vida. El primero en atacar en cada turno lo decidirá la agilidad, el que tenga mayor esta variable atacará primero. Los ataques podrán ser físicos, mágicos o de talento. Estos dos últimos consumirán SP y TP respectivamente. Durante el combate existirá la posibilidad de que las variables de fuerza, fuerza mágica, defensa, defensa mágica y agilidad se vean modificadas, para mejor o para peor. Tras la pelea, estos atributos volverán a tomar el valor que tenían antes del combate.

Para recuperarse habilitaremos uno o varios puntos en el mapa que restauraran la vida, el SP y el TP. También existirá la opción de guardar partida al colocarse en el lugar correcto en el mapa. Esto nos permitirá continuar la partida en cualquier momento ya dejemos de jugar o nos maten.

El objetivo del juego es poder entrenar lo suficiente como para ser capaces de vencer a un Boss Final. Para llegar a el, el personaje se desplazará por un mapeado en 2D de perspectiva isométrica en cuatro direcciones; Arriba, abajo, derecha e izquierda.

A partir de esta descripción, tenemos que crear la lógica de negocio. ¿Pero que es la lógica de negocio? Trata de ser capaces de crear un sistema que gestione el juego independientemente de como se trabaje con el usuario que lo utilice. Es decir, es la parte que explica como interactúa el programa consigo mismo para tratar y procesar los datos que recibe. Parece ser que la idea del ejercicio es encontrar esa funcionalidad y que después, si nos da la gana, ser capaces de implementar una interfaz gráfica de forma que apenas interfiera en el programa base que hemos hecho.

Por ello, nuestro primero objetivo es crear un Diagrama de Secuencia y un Diagrama de Clases para saber que partes del juego van a participar en el desarrollo de la aventura. Esto que os dejo aquí es un primer boceto no muy bien detallado de lo que planteamos hacer.

Es normal que no entendáis que leches es eso, así que ahora mismo os lo explico. El Diagrama de Secuencia es como un esquema que explica como va trabajando el programa. Se interpreta comenzando a leerlo desde la esquina superior izquierda, donde esta el monigote con visera.

Si veis una flecha que sale de el, indica que este individuo le interesa ejecutar un procedimiento que existe en el programa principal del juego (ejecutarJuego). Este procedimiento internamente tendrá una serie de sentencias para trabajar, pero eso en este momento no nos interesa lo mas mínimo. Lo que interesa es que hace al interactuar con el resto de programas o consigo mismo.

Como el juego tiene la opción de salvar y cargar partida, podéis ver que el Main se envía a si mismo una flecha tanto para hacer una acción como para la otra. Justo después, no muy bien indicado, el Main avisa al Jugador y al Mapa que tienen que cargar su información. Aún no sabemos que cargaran, y por ahora no debería importarnos, solamente, que tendrán que cargar.

Después hay un bloque que en su parte exterior pone loop while. Esto quiere decir que lo que hay dentro de ese bloque se ejecutará indefinidamente hasta cumplir la condición o condiciones indicadas, en este caso, hasta que el héroe muera. Si no está muerto se podrá desplazar, como veis en el esquema. El jugador a su vez le avisa al mapa hacia donde se quiere mover.

El mapa, tras recibir esta información tiene que tratarlo en consecuencia. Aún no esta decidido 100% como será pero os dejo aquí la idea. El mapa será una matriz con casillas en plan tablero de mesa. En cada casilla pueden ocurrir distintas cosas que aun no hemos decidido exactamente cuales (salvar y curarse por ejemplo son fijos). Una de estas casilla, será la de enemigo. Con un aleatorio decidiremos si toca o no luchar y si es así, se cargará el algoritmo relacionado con el combate.

Si intentáis comprender como funciona el combate, veréis que lo único representado es el tema de la agilidad para saber de quien es el turno, puesto esto decide como se ejecutará el algoritmo. Como sea el combate realmente no aparece y se supone que aquí no debería aparecer, ya que eso es algo interno que mas adelante se programará.

No quiero explicaros todo, porque seguramente haya mucha cosa mal puesta, mal interpretada o directamente, esta mal hecho. Junto a esto, debería venir acompañado el diagrama de clases. Cosa que aún no hemos hecho. Lo dejaré para el siguiente post, pero os dejo una breve explicación de lo que es.

Una clase, es como una definición de un objeto existente en la vida real. Tomaré el ejemplo de una tarta. Para crear una tarta necesitamos dos cosas. Por un lado los ingredientes y por otro las instrucciones para poder hacerlo. En un diagrama de clases, vendrán indicadas estas dos cosas pero sin explicar nada. Es decir:

TARTA
=====
Ingredientes:
-Azúcar
-Pocholate
Proceso:
-Mezclar()
-Ornear()
-Chuparse los dedos()

Pero tiempo al tiempo, os iré explicando cada cosa a su tiempo y si hace falta escribiré mas post especificando mas. Ah, el juego será con orientación a objetos. Por si os interesaba saberlo.

Post a comment

Terranigma
The Gurkito Style Rss