The Gurkito StyleCon toda la ración del muslo

En el anterior mensaje justo al final os dije que además de ese esquema de funcionamiento hacía falta al definición de las clases y que estas parecían imitar a una receta. Os voy a explicar como se hace una.

Normalmente estas clases definen elementos de la vida real que se van a plasmar en código. Para empezar, en este juego quien creéis que va a tener fijo, una definición en forma de Clase. Ese sería el héroe o protagonista del juego. Ya tenemos la base, ahora hay que expandirlo indicando sus características y funcionalidades.

Las característica ser refieren a los atributos de la clase, algo así como los indicadores de lo que posee. Estos indicadores por costumbre se colocan en estado de privados. Al estar en privado conseguimos que nadie externo al héroe sepa que posee. Imaginaos la tarta del ejemplo anterior. Si cogéis una tarta, sabéis que tiene ciertos ingredientes, pero no sabéis cuales ni su cantidad. Para saber que tiene meteréis el dedo y lo chupareis, pero eso lo vamos a representar de otra forma.

Para poder tratar con el héroe, éste necesita tener ciertas funcionalidades. Tienen que ser mínimas y las necesarias ya que no sirve de nada permitirle hacer algo que luego no va a hacerlo. También hay que decidir si esas funcionalidades serán públicas o privadas. Una vez mas vuelvo al ejemplo de la tarta. Para poder hacerla necesitamos una funcionalidad que sea mezclar los ingredientes, que será algo publico ya que será algo que nosotros haremos. Pero por ejemplo, reposar para que la levadura haga efecto, eso es algo que la propia tarta hará de por si. Este reposo será algo que se hará internamente y nadie de fuera debería saber que es lo que es.

Volvamos al héroe, empezaremos con sus atributos. Recordemos, que privados. Pensad vosotros también que debería tener a partir de la descripción del juego que os día anteriormente.

Jugador:
– nombre:String
– nivel:int
– experiencie:int
– vida:int
– fuerza:int
– defensa:int
– agilidad:int

He puesto estos pocos, seguro que se os han ocurrido bastantes mas. Estos serán los atributos que definan al héroe. ¿Que es eso de int que viene después? Lo que aparece al final del atributo indica que tipo de información almacenará. Si es un int, indica que guardará un número natural (Los números que usamos para contar, sin decimales) negativo o positivo. Puede ser un String (Con la S mayúscula) que sirve para almacenar una serie de caracteres, como puede ser una frase o en este caso, el nombre. Existen otros cuantos, como el float para guardar ya con los decimales o el booleano, que solamente guarda los estados de Verdadero o Falso.

Los guiones no los he puesto para que la lista quede bonita, ese guion indica que los atributos serán privados y que nadie mas que el podrá trabajar con ellos. Si por alguna extraña razón se necesita que sea público, se indicará con un plus «+» en vez del guion, eso lo vamos a ver ahora con las operaciones.

En las operaciones tenemos que indicar que acciones queremos que nuestro héroe sea capaz de hacer. Según la descripción del juego, podemos deducir que el jugador debe ser capaz de moverse, luchar y ganar experiencia. Así pues, vamos a indicarlos en la descripción de la clase;

Jugador:
– nombre:String
– nivel:int
– experiencie:int
– vida:int
– fuerza:int
– defensa:int
– agilidad:int
——————-
+desplazarse():void
+recibirExperiencia(vExperiencia:int):void
+luchar(vEnemigo:Enemigo):boolean

El primero es sencillo, el jugador se podrá de desplazar. Lo que haya dentro ya se discutirá mas adelante, por ahora, la estructura. Los paréntesis son una forma de distinguir de que esto es una operación. Si entre estas paréntesis aparece algún atributo, significa que la operación tendrá que trabajar con ese datos de alguna forma. Si después de estas operaciones, el programa necesita devolver algún valor al programa, después de los dos puntos se indica que tipo de valor devolverá. Si pone void, es que no devolverá nada. Si miráis el segundo y tercero, veréis que ambos reciben un dato, pero solo uno de ellos devuelve otro. Sin saber programar, seguro que sois capaces de deducir que harán estas dos operaciones mas o menos. La tercera como recibe un Enemigo y devuelve un booleano, se podría pensar de que tras combatir el booleano nos devolverá un Verdadero si ha ganado o un Falso si ha perdido.

Otro detalle, estos son métodos públicos, por lo que el programa será capaz de acceder a estas funcionalidades. Como poder hacerlo os lo explicaré mas adelante. Ahora os pondré las fotos de como están quedando el diagrama de secuencia y el diagrama de clases. Os recuerdo que no es definitivo y aun tenemos que discutir con la profesora ciertos detalles.

En el próximo tema os hablaré del Pseudo-codigo, que es explicar con lenguaje humanoide cotidiano como funcionará el programa. Es muy sencillo y aunque posiblemente ni yo lo este haciendo bien sirve para saber que operaciones se pueden necesitar en el programa. En realidad no es una parte de la asignatura, pero me ha servido para saber como hacer el resto de cosas. Cada uno que se tiene que buscar la vida como puede, supongo.

Finalmente si os habéis fijado habrá una clase que defina al enemigo, pero no habrá solo uno evidentemente, así que si queréis participar de alguna forma en el juego podéis sugerirnos si os apetece que enemigos deberían salir. Incluso podéis hacer algún borratajo del bicho y decir que tipo de ataque se podría tener. Los ataques del juego no son muy complicados, así que posiblemente las adaptaremos. ¡Tenéis la oportunidad de aparecer en los créditos de un juego!

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.

No se si debería ponerlo sin consultarlo con los compañeros del grupo de trabajo, pero ahí va y espero que salga algo bonito de esto.

En la asignatura de Ingeniera del Software se nos ha dado como trabajo de laboratorio preparar un juego. Para diseñar este juego necesitamos aplicar una «Arquitectura de Software», así antes de nada tenemos que preparar una «Lógica de Negocio». Aun no tengo muy claro que es esto, pero parece ser que es como una descripción de las funciones que realizarán las clases y como interactuarán entre ellas. Esto quiere decir, que sin una linea de código se debería ser capaz de crear un especie de esqueleto o esquema del que después basarse para crear el código y mas adelante si se necesita o se requiere, una interfaz gráfica.

Es posible que algún lector sepa de que este hablando y con esta lectura se eche las manos a la cabeza o se pegue un par de carcajadas por posibles perlas que pueda soltar. ¡Que cada uno lo disfrute como pueda!

Antes de hablar sobre el proyecto, un poco de historia. Read the rest of this entry »