Temario/Un ejemplo de la creación de un videojuego/Diseño

De Tutorial LibSDL

Tabla de contenidos

[editar] Diseño del Sistema

Siguiendo con la metodología del análisis vamos a realizar un diseño orientado a objetos mediante UML. Hasta ahora habíamos especificado y analizado nuestra aplicación con lo que completamos el análisis de requisitos y la especificación del sistema. Ahora vamos a diseñar el sistema que no es más que describir fuera de toda duda razonable qué va a hacer el sistema.

El diseño del sistema es la actividad de aplicar diferentes técnicas y principios con el propósito de definir un sistema con el suficiente detalle para que se pueda implementar. El resultado del diseño es un conjunto de diseños de diferentes partes del software.

Este proceso es mucho más sencillo una vez que hemos especificado qué debe hacer el sistema en los pasos anteriores. El proceso de diseño consiste en especificar el sistema con suficiente detalle para que se pueda implementar. El resultado del proceso de diseño es una arquitectura de software bien definida y los diseños de datos, interfaz y programas que nos permitan llevar a cabo la implementación del sistema software con garantías de éxito.

Para llevar a cabo el diseño vamos a usar patrones de diseño que nos permiten plantear los problemas concretos donde definiremos el contexto del problema, el problema en sí y la solución para dicho problema.

[editar] Arquitectura del sistema software

La arquitectura del sistema software es un esquema de organización estructural para estos sistemas. Con él especificaremos las responsabilidades de cada uno de los subsistemas definidos para organizar las relaciones entre ellos. Utilizaremos el patrón de arquitectura en capas.

El contexto del problema es que necesitamos descomponer nuestra aplicación en grupos de tareas con un mismo nivel de abstracción que sirvan de base a otras tareas más complejas.

El problema existente es que necesitamos que esta jerarquía esté bien definida para desarrollar nuestro software ya que las tareas de alto nivel no se pueden implementar utilizando los servicios de la plataforma ya que aumentaría la dependencia de nuestro sistema por lo que necesitamos servicios intermedios. Hay varias características que son deseables para nuestras aplicaciones. Deben ser:


  • Mantenibles: Un cambio en el código no puede propagarse a todo el sistema.
  • Reusable: Los componentes de nuestra aplicación deben de poder ser utilizados en otras aplicaciones por lo que deberemos de separar interfaz e implementación.
  • Cohesión: Responsabilidades similares deben agruparse para favorecer la mantenebilidad y la compresión del sistema.
  • Portabilidad: Ésta es una característica deseable que no siempre puede satisfacerse.


En nuestro caso utilizamos SDL que nos proporciona un nivel más en la jerarquía de niveles con la que conseguimos la independencia del sistema software del sistema operativo y de cualquier hardware en el que queramos compilar nuestra aplicación.

La solución es estructurar al sistema en un número de capas suficiente para que cumpla todas las características deseables para nuestra aplicación. Los servicios que ofrece la capa n deben basarse en los servicios que ofrece la capa n-1 y la propia n. Los componentes de una capa han de estar al mismo nivel de abstracción.

Para nuestra aplicación SDL vamos a usar una arquitectura en tres capas. La primera de ellas será la capa de presentación que será la encargada de la interacción (interfaz) con el usuario. La segunda capa será la capa de dominio que es la responsable de la implementación de la funcionalidad del sistema. La tercera y última capa será la encargada de interactuar con el sistema para almacenar y obtener la información estática (o almacenada en disco) del sistema a la que llamaremos capa de gestión de datos.

Una vez determinado el patrón arquitectónico, el patrón de diseño nos proporciona una esquema que nos permite refinar los componentes y las relaciones de los subsistemas. Resuelven un problema de diseño general en un contexto determinado. Vamos a utilizar el patrón de diseño de UML.

No necesitamos realizar un diseño de la capa de gestión de datos ya que los únicos datos que vamos a almacenar en el disco es un fichero organizado secuencialmente donde estarán los distintos niveles de la aplicación. De la gestión del acceso a disco se encargará la clase que administrará los niveles consiguiendo una cohesión importante de la clase.

[editar] Diseño de la capa de dominio

En los siguientes apartados vamos a realizar el diseño de la capa de dominio, o lo que es lo mismo, la capa encargada de la implementación de la funcionalidad del sistema.

Una vez realizado los diagramas de las clases de diseño que describen las clases del software y sus operaciones debemos de realizar los contratos de cada una de las operaciones y los diagramas de secuencia de la respuesta a eventos externos. En muchas de las clases sustituiremos esta explicación formal por una más intuitiva e informal para no perder el rumbo didáctico de este temario.

[editar] Diagrama de clases de diseño

Este diagrama, como verás, es diferente al diagrama de clases conceptual ya que se especificarán todos los detalles necesarios para la implementación del sistema mediante SDL y C++.

En este diagrama aparecen:

  • Clases: Que participan en las interacciones.
  • Relaciones: Entre las clases y nuevas clases que proporcionan la relaciones entre clases.
  • Atributos: Aparecen todos los atributos necesarios para la implementación de la aplicación.
  • Operaciones: Métodos y funciones necesarias para el desarrollo de la aplicación.

Para presentar estos diagramas vamos a seguir el mismo orden que utilizamos en cuando mostramos los diagramas en la fase de análisis.


El primer subdiagrama que presentamos incluye a las clases que gestionarán los elementos multimedia de la aplicación. Podemos decir que la clase principal de este grupo es la clase Galería que estará compuesta de las clases que están asociadas a ella. El diagrama es el de la figura.


Diagrama de clases (diseño): Componentes multimedia
Diagrama de clases (diseño): Componentes multimedia

En este diagrama se muestran siete clases. Como hemos comentado Galería es la clase que las relaciona a todas. Como puedes observar hemos añadido todo lo necesario para la implementación de las clases. Será en dicho apartado donde estudiaremos todas las nuevas características de las clases. En este momento es importante que observes cómo han evolucionado las relaciones entre las clases y las propias clases frente a las del análisis.

El segundo diagrama que presentamos relaciona a las clases que nos permiten crear y modificar niveles en la aplicación. En este caso la clase que permite relacionar a las demás componentes del diagrama es la clase Universo aunque la que contendrá toda la lógica para realizar esta tarea es la clase Editor.

Diagrama de clases (diseño): Editando niveles
Diagrama de clases (diseño): Editando niveles

Como puedes observar hemos añadido todo lo necesario para la implementación de las clases. Será en dicho apartado donde estudiaremos todas las nuevas características de las clases. En este momento es importante que observes como han evolucionado las relaciones entre las clases y las propias clases frente a las del análisis.

El tercer diagrama que vamos a estudiar engloba las clases que están asociadas directamente con la clase Participante que recoge todos los elementos activos que participan en los niveles del juego.

Diagrama de clases (diseño): Participantes
Diagrama de clases (diseño): Participantes

Como puedes observar hemos añadido todo lo necesario para la implementación de las clases. Será en dicho apartado donde estudiaremos todas las nuevas características de las clases. En este momento es importante que observes como han evolucionado las relaciones entre las clases y las propias clases frente a las del análisis.

Ahora vamos a estudiar uno de los diagramas de clases más importantes del análisis. Se trata de la clase Universo encargada de relacionar las clases del videojuego, los elementos de control y los elementos multimedia que representa a cada una de estas partes.


Imagen:DcDUNIVERSO.png
Diagrama de clases (diseño): Universo

Como puedes observar hemos añadido todo lo necesario para la implementación de las clases. Será en dicho apartado donde estudiaremos todas las nuevas características de las clases. En este momento es importante que observes como han evolucionado las relaciones entre las clases y las propias clases frente a las del análisis.

Con esta información puedes obtener como es el diagrama general de todas las clases. No se incluye en este temario por problemas de espacio pero puedes encontrarlo en el material del curso.

[editar] Diagrama de secuencia

Estos diagramas van a definir la interacción entre las distintas clases. Vamos a dividir la presentación de estos diagramas por funcionalidad. Debemos de añadir un contrato por cada una de las operaciones que aparecen en los diagramas. Vamos omitir este paso ya que vamos a detallar minuciosamente los detalles del contrato en el apartado anterior.

El diseño del videojuego va tomando consistencia. Pronto codificaremos y entenderás mejor todo este proceso.

Diagrama de secuencia (diseño): Universo
Diagrama de secuencia (diseño): Universo


En este diagrama mostramos las interacciones que deben darse entre las principales clases del sistema.

Diagrama de secuencia (diseño): Editor
Diagrama de secuencia (diseño): Editor


En este diagrama presentamos las relaciones que mantiene el Editor con las demás clases del sistema.

Diagrama de secuencia (diseño): Galeria
Diagrama de secuencia (diseño): Galeria


En este diagrama presentamos las relaciones que mantiene la Galería con las demás clases del sistema.

Diagrama de secuencia (diseño): Juego
Diagrama de secuencia (diseño): Juego


En este diagrama presentamos las relaciones que mantiene el Juego con las demás clases del sistema.

Diagrama de secuencia (diseño): Menu
Diagrama de secuencia (diseño): Menu


En este diagrama presentamos las relaciones que mantiene el Menú con las demás clases del sistema.


[editar] Diseño de los personajes

En la etapa de codificación, junto a los aspectos más importantes de la misma, presentaremos el diseño lógico de los personajes como justificación a dicha codificación. Hay otra etapa que no hemos presentado todavía en esta memoria del proyecto fin de carrera. Se trata del diseño gráfico que tenemos que aplicar a todas las creaciones y ejemplos que hemos realizado en el tutorial. En este apartado vamos a presentar las más importantes.

El trabajo de creación de estas librerías gráficas es importante. Hay que invertir mucho tiempo para crear un personaje completo que sea válido para que sea utilizado en una animación. Estos personajes han sido creados con The Gimp. Ésta es una herramienta de edición de gráficos raster por lo que las modificaciones las realizamos píxel a píxel.

Vamos a presentar el diseño de los gráficos más relevantes que hemos creado en exclusividad para este tutorial:


Diseño gráfico: Personaje Principal
Diseño gráfico: Personaje Principal

El gráfico de la figura personaje principal contiene todas los fotogramas que componen la animación del personaje principal de nuestro videojuego final. Puedes comprobar el gran esfuerzo que hay que realizar para crear un personaje con todos estos cuadros. La fluidez de muchas de las animaciones del videojuego dependen de un diseño gráfico correcto.

Diseño gráfico: Enemigo polvo
Diseño gráfico: Enemigo polvo

El gráfico de la figura enemigo polvo contiene los fotogramas que componen la animación de uno de los enemigos. Como puedes comprobar esta animación es mucho más simple ya que no influye tanto como la anterior en el desarrollo del videojuego.

Diseño gráfico: Enemigo rata
Diseño gráfico: Enemigo rata

El gráfico de la figura enemigo rata contiene los fotogramas que componen la animación de uno de los enemigos. Estamos en el mismo caso que el enemigo polvo por las mismas razones.

Diseño gráfico: Tiles o bloques
Diseño gráfico: Tiles o bloques

El gráfico de la figura bloques es uno de los más importantes en la creación del videojuego. Contiene todos los elementos que nos permitirá configurar nuestros niveles y las posiciones de todos los elementos del juego.

En las figuras item destornillador y ítem alicate tenemos dos casos análogos. Se tratan de objetos que nos encontraremos en los niveles del tutorial y su recopilación será uno de los objetivos del mismo.

Diseño gráfico: Ítem destornillador
Diseño gráfico: Ítem destornillador
Diseño gráfico: Ítem alicate
Diseño gráfico: Ítem alicate

Hay otros aspectos como el diseño de niveles que no se ha seguido una metodología establecida por su no existencia. Uno de los objetivos del juego desarrollado es que esa un borrador libre donde poder probar cosas más que sea un videojuego completo del mismo. El editor de niveles nos permite esta capacidad. No tiene razón de ser un esfuerzo relevante en el diseño de estos niveles ya que debe ser una capacidad que tiene que trabajar el estudiante desde su posibilidades de creación.

Herramientas personales