M OTORES DE V IDEOJUEGOS Y F RAMEWORKS
3.3 Motor escogido
A la hora de escoger el motor se ha tenido en cuenta el tipo de juego a desarrollar.
El videojuego completo se explica más adelante, pero a continuación se enumeran algunas de las cosas que son relevantes a la hora de escoger un motor:
1. Vista 2D.
2. Movimiento en forma de cuadrícula.
3. Generación procedimental de mapas.
LaGPCno viene incluida en ninguna clase de motor de videojuegos porque es diferente para cada juego, por lo que no existe una implementación que le pudiera servir a varios. Por ese motivo utilizar un motor de código abierto o un framework es la mejor opción.
Debido a esto, en lugar de escoger un motor completo se ha escogido el framework LibGDX. Esto se debe a que la vista 2D y la generación procedimental de mapas de Unity y Unreal Engine no son suficientemente buenas. Además, los motores que permiten desarrollar fácilmente videojuegos de este estilo, como GameMaker o Corona2D, son de pago. Las razones por la que se ha escogido LibGDX en lugar de Monogame son las siguientes:
• Mayor facilidad de desarrollo para Android.
• Mayor y mejor documentación.
• Mayor conocimiento del lenguaje de programación Java.
Sin embargo esto significa que será necesario crear un motor.
C
APÍTULO4
E L V IDEOJUEGO
A partir del framework LibGDX se ha creado un videojuego. El trabajo realizado incluye el diseño del videojuego, la creación de un motor que soporte el juego y la implemen-tación de varios algoritmos deGPC. En este capítulo se detallarán las dos primeras partes.
4.1 El Diseño
La idea principal del juego es intentar traer la jugabilidad de los juegos Roguelike de los años 80 exactamente como se recuerda, mejorando los aspectos deficientes y mejorando la interacción para que el usuario pueda jugar en cualquier momento en su smartphone sin necesidad de ser un experto.
4.1.1 Objetivo
El jugador es un héroe de fantasía que ha decidido su destino e intentará salvar al mundo de los villanos que lo pueblan. En la taberna escogerá un adversario adecuado para su nivel y embarcará en una misión por las mazmorras para eliminarle.
Una vez haya alcanzado la máxima reputación, el héroe se retirará y será recordado en las leyendas.
4.1.2 Jugabilidad
El juego está basado en el combate y la resolución de rompecabezas. Para ayudar en la tarea el jugador tiene acceso a un máximo de 4 armas. Dichas armas se pueden comprar en la tienda, a la cual se puede acceder desde la taberna. El dinero necesario para comprar las armas se consigue eliminando a los enemigos en las mazmorras.
4. ELVIDEOJUEGO
Estructura de la Mazmorra
Las mazmorras consisten de una serie de habitaciones que el jugador debe atravesar. El número de habitaciones depende de la dificultad de la misión. La mazmorra está dise-ñada de tal manera que para pasársela sea necesario atravesar todas las habitaciones.
Cada una de las habitaciones contiene obstáculos y enemigos. Para poder continuar el jugador debe eliminar a todos los enemigos de la habitación. Los obstáculos pueden ser destruidos con el arma adecuada, y están diseñados para que nunca impidan el progreso del jugador por la mazmorra.
Existen los siguientes tipos de habitación:
• Habitación inical: Es la habitación en la que comienza el jugador. No tiene obs-táculos ni enemigos.
• Habitación del jefe: Es la habitación en la que se encuentra el jefe final. La puerta de acceso a la habitación está cerrada con una cerradura especial que solo se puede abrir con una llave especial que se consigue al recorrer toda la mazmorra.
• Habitación normal: Componen la mayoría de las habitaciones y contienen tanto obstáculos como enemigos. Las puertas de la habitación que estén cerradas y no tengan candado se abrirán al eliminar todos los enemigos de la habitación.
• Habitacion con rompecabezas: Las habitaciones que no tengan salida tienen un rompecabezas. Al completar el rompecabezas se descubre un cofre con una llave que permite abrir una puerta cerrada con cerrojo. La última llave de la mazmorra es la llave de la habitación del jefe.
Combate
El combate ocupa la mayor parte del tiempo, siendo por tanto la parte más importante del juego. Cada habitación normal contiene uno o más enemigos, que pueden ser de diferentes tipos. Puesto que esto se trata de un videojuego de ejemplo sólo se ha implementado un tipo de enemigo, puesto que el diseño no debe ocupar demasiado tiempo.
El enemigo implementado se va moviendo lentamente en la dirección del jugador, y si se encuentra suficientemente cerca, cargará un ataque que dañará al jugador en el próximo turno a no ser que este se mueva. Tiene 2 puntos de vida, lo que significa que debe recibir dos ataques del jugador para ser eliminado. Su ataque hace 2 puntos de daño.
El jefe funciona de la misma manera, aunque tiene 10 puntos de vida y sus ataques causan 5 puntos de daño.
El jugador tiene 5 puntos de vida, lo que significa que es capaz de resistir 3 ataques de los enemigos básicos o 1 del jefe. Si el jugador pierde todos sus puntos de vida, el juego acaba. El jugador puede entonces decidir si empezar una nueva aventura o parar por el momento.
4.1. El Diseño
Figura 4.1: Ejemplo de una habitación normal con obstáculos y enemigos.
4. ELVIDEOJUEGO
Figura 4.2: Imágen del videojuego Soko-Ban. [17]
Rompecabezas
Los rompecabezas son pequeños desafíos para el jugador que debe superar para conti-nuar. Se encuentran en habitaciones que no tienen más que una puerta y ofrecen una llave como recompensa por solucionarse.
Como se trata de un videojuego de ejemplo solo se ha incluido un tipo de rompeca-bezas. El tipo de rompecabezas escogido es Sokoban, ya que sus sencillas reglas y la dificultad que puede llegar a alcanzar son perfectos para intentar generar niveles de manera procedimental.
Sokoban fue inventado por Hiroyuki Imabayashi en el año 1981, y el primer juego fue publicado por Thinking Rabbit en el año 1982. [27] A partir de este se han realizado innumerables clones y secuelas.
Las reglas de Sokoban son muy sencillas:
• El jugador se encuentra en un tablero de casillas cuadradas y se puede mover en 4 direcciones: arriba, abajo, a la izquierda y a la derecha.
• El tablero contiene paredes y cajas. Las paredes no se pueden mover, mientras que las cajas se pueden empujar si existe una casilla libre en el lado contrario desde el que se intenta empujar. No se puede estirar de ellas.
• Algunas de las casillas son casillas meta. Las casillas meta no impiden ni al jugador ni a las cajas moverse. Para completar el rompecabezas todas las cajas deben situarse encima de casillas meta.
4.2. El Motor
Ya que el juego se juega en una cuadrícula adecuar este tipo de rompecabezas es trivial, puesto que basta con incluir un control sobre las casillas meta que nos permita saber si se ha resuelto.
4.1.3 Controles
Al empezar una partida, el jugador será llevado directamente a la taberna. En la taberna podrá entrar en la primera misión o bien ir a la tienda, donde podrá comprar nuevas armas.
Puesto que el juego ha sido pensado para dispositivos móviles, los controles deben de ser muy simples. De hecho solamente existen dos acciones posibles dentro de una mazmorra:
• Movimiento: deslizar el dedo en la dirección deseada (arriba, abajo, izquierda o derecha)
• Atacar: seleccionar un arma de la barra inferior y deslizar el dedo en la dirección deseada.
Para cambiar de habitación basta con moverse a la puerta adecuada y el jugador será trasladado a la habitación adyacente. Para abrir puertas cerradas con llave basta con moverse hacia ellas.
4.2 El Motor
El motor se ha diseñado para facilitar la creación de un videojuego por turnos y permitir la creación de contenido medianteGPC. En lugar de utilizar el patrón Entidad Compo-nente Sistema (ECS) como es común en los motores de videojuegos se ha optado por el patrón Modelo Vista Controlador (MVC) modificado para permitir mayor interacción entre control y modelo. Aunque esto hace que el código sea más difícil de mantener, permite desarrollar videojuegos con mayor velocidad.
4.2.1 Modelo
El modelo de datos está basado en una jerarquía de objetos profunda que tiene su raíz en la clase entidad. A partir de la clase entidad se derivan todos los objetos del juego, como enemigos, puertas, paredes y el propio jugador. Estas entidades van asociadas a una única habitación, que a su vez están asociadas a una mazmorra.
Las entidades se subdividen en los siguientes tipos básicos:
• Ítems (llaves, armas, etc.)
• Efectos (disparos, partículas, etc.)
• Obstáculos y seres (cajas, enemigos, el jugador, etc.)
• Terreno (puertas, paredes, metas, etc.)
4. ELVIDEOJUEGO
Figura 4.3: Diagrama de clases del modelo de datos del videojuego.
Las habitaciones disponen las entidades en una cuadrícula. Es posible que haya varias entidades en la misma casilla, pero no todas las entidades pueden compartir casilla. Además de la entidades las habitaciones también tienen conexiones con otras habitaciones.
Las conexiones son objetos que conectan 2 habitaciones y actúan como aristas de un grafo, mientras que las habitaciones actúan como vértices. La mazmorra tiene acceso a ambos para poder realizar cómputos sobre el grafo comprendido por estos objetos.
4.2.2 Vista
La vista se separa en múltiples pantallas. Cada pantalla está pensada para ofrecer interacción con el jugador con un objetivo específico. Las pantallas son las siguientes:
• Pantalla de carga: Se encarga de ofrecer al usuario una forma de saber como va el proceso de carga de recursos mediante una barra de progreso. Una vez ha cargado pasa al menú principal.
• Menú principal: En el menú principal el jugador puede escoger entre crear una nueva partida o continuar con la partida anterior.
• Taberna: Al empezar una nueva partida o si al continuar no se estaba en una mazmorra se accede directamente a la pantalla de la taberna, donde el jugador ha de escoger la misión que quiere realizar.
• Pantalla de juego: Una vez escogida la misión se accederá directamente a la maz-morra. La pantalla de juego se encarga de ofrecer al usuario toda la información necesaria para jugar, como su vida, sus armas y la cuadrícula de la habitación en
4.2. El Motor
Figura 4.4: Diagrama de actividad de las pantallas del juego.
la que se encuentra. Para evitar un exceso de interfaces, esta parte se ha conecta-do directamente con el modelo de datos, de manera que cada entidad se encarga de dibujarse a si misma.
4.2.3 Control
El control está separado en múltiples clases:
• Control del juego
• Control de la generación de mazmorras
4. ELVIDEOJUEGO
• Control de serialización y guardado de datos
La clase de control del juego se encarga de controlar los turnos y distribuir el control entre las diferentes entidades de la habitación actual. También se encarga de distribuir el control a la generación de mazmorras y guardado de datos cuando es necesario. Para evitar una clase monolítica con el control de los turnos de todas las entidades del juego, la parte del control correspondiente a las acciones que ha de realizar cada entidad se ha delegado a las entidades. Esto hace que el modelo y el control se encuentren entrelazados, pero permite un desarrollo más rápido y mayor facilidad a la hora de leer el código, a costa de posibles problemas de coordinación entre las entidades.
La clase de generación de mazmorras incluye todos los algoritmos deGPC, los cuales se explicarán en el próximo capítulo, y se encarga de controlar la generación desde principio a fin. El control del juego se encarga de pasarle el control cuando el jugador se dispone a entrar en una nueva mazmorra.
La clase de serialización y guardado de datos se encarga de serializar el estado actual del juego y guardarlo en un archivo cada vez que sea necesario. Los algoritmos se han desarrollado intentando que sean invisibles para el jugador, es decir, que no se pause el juego a la hora de guardar. Para conseguir esto el guardado se realiza cuando el jugador pulsa el botón atrás o sale de la partida. Para que no se guarden estados a medias (por ejemplo a mitad de un movimiento) se utiliza un buffer en memoria para guardar el estado al principio de cada turno. Este buffer está pensado para que solo haga falta rehacer la serialización de la habitación actual (única en la que puede pasar algo), reduciendo así la cantidad de datos a serializar en cada turno.
