El problema es la carencia de ocio, una vivencia en la que el sujeto percibe la ausencia de situaciones libres, satisfactorias y gratuitas. En otras palabras, la percepción de un tiempo vacío, lleno de aburrimiento.

2.- Un pequeño análisis del problema

La falta de ocio puede terminar en problemas graves, tanto mentales como físicos, tomando en cuenta que el ocio está formando parte de nuestras vidas combinado con que los dispositivos electrónicos son los utilizados en estos tiempos de ocio se decide diseñar y programar un juego de plataformas, este consiste en un personaje que se puede mover y saltar a través de plataformas, pudiendo recoger monedas y evitando las llamas. Con la clase LevelData, se crea la información del nivel respectivo a través de un arreglo, JuegoPlataforma se encarga de mostrar todos los elementos mencionados anteriormente.

3.- Definición de requerimientos

Tres usos de casos para nuestro juego :

Usuario	Juego
1) Entra al ejecutable
	2) Despliega el menú
3) Navega por el menú, selecciona”Iniciar Juego”
	4) Despliega el nivel

Tabla 1 : Uso de Caso 1, entrar en un nivel.

Usuario	Juego
1) Usar las flechas del teclado una vez en el nivel.
	2) Mover el personaje y la vista del personaje en el entorno.
3) Ir sobre una llama.
	4) Mostrar el mensaje de Game Over.

Tabla 2 : Uso de Caso 2 : Perder una partida.

Usuario	Juego
1) Usar las flechas del teclado una vez en el nivel.
	2) Mover el personaje y la vista del personaje en el entorno.
3) Ir sobre una moneda.
	4) Colectar la moneda e incrementar el número de monedas colectadas.

Tabla 3 : Uso de Caso 3 : Recolectar monedas

4.- Diseño

Decidimos usar el modelo MVC (Modelo, Vista, Controlador) que es un patrón de diseño masivamente usado para hacer interfaz gráfica incluyendo juegos. Eso facilita el desarrollo, por ejemplo si se tiene que hacer un cambio en la vista, no hay que cambiar todo el código, del modelo y del controlador, para realizarlo. La vista y el modelo trabajan de manera independiente.

Para esto se separa el código en varias clases que pertenecen al modelo, a la vista o al controlador. Las clases que tienen la palabra View son de la vista y solamente manejan los elementos visibles como las imágenes. La clase JuegoPlataforma es la clase para el controlador. Las otras clases son clases del modelo. Eso entrega el siguiente diagrama UML en la Figura 1.

Figura 1 : Diagrama UML de nuestro juego

Se observa también en la Figura 1 que hay unas clases que pertenecen a JavaFX. Eso permite entender mejor la herencia entre las clases y saber cómo implementar las clases cuando se escriben. Se observa rápidamente que los elementos de la vista extienden de Group en con JavaFX.

Este era el diseño que queríamos implementar pero al final no fue posible por falta de tiempo, empezamos a escribir el código sin separación de clases, complejizando más y más el código hasta que no nos fue posible la separación. Esta parecía la manera más fácil para empezar a escribir código rápidamente y desde la nada, para luego terminar separándolo en la estructura que mostramos en el diagrama UML pero el programa Main llegó a ser tan complejo que frenó el avance e implementación de nuevas funciones y terminó no resultando la separación . Concluimos que es recomendable primero pensar y elegir un buen diseño antes de empezar a escribir el código, usamos mucha energía para evaluar en un diseño correcto y necesitamos modificar muchas cosas.

5.- Pruebas

Figura 2 : El usuario entra al ejecutable y se despliega el menú

Figura 3 : Luego de presionar el botón “iniciar juego” se despliega el nivel

Figura 4 : El usuario está por tocar una llama

Figura 5 : El usuario toca la llama y se despliega el mensaje de “game over”

Figura 6 : El usuario mueve al personaje y está por recolectar una moneda

Figura 7 : El usuario recolecta una moneda

La lista de todas las pruebas arriba, muestra todas la funcionalidades de nuestro juego : coleccion de monedas, inicio de una partida, muerte por llamas, etc.

6.- Dificultades

Detección de colisiones: Definir los bordes o hitbox de los objetos, y luego hacer la comparación con el objeto, además, que dependiendo de con qué objeto colisione ocurran distintas acciones, como la colisión con la plataforma detiene el movimiento del personaje, la colisión con la moneda la hace desaparecer y la colisión con el fuego despliega “game over”.

Centrar “cámara” en el personaje: El mapa es más extenso que la pantalla, por lo cual fue difícil lograr que la cámara o la escena siguiera al personaje dependiendo de qué parte de la pantalla estaba, se calcula la mitad del mapa y la mitad de la pantalla, y a través de condicionales cada vez que el personaje pasara la mitad de la pantalla la escena lo siguiera.

DESCARGAR