Game Components

Hola a todos, el siguiente artículo voy a intentar explicaros de una forma sencilla qué es y para que sirven los game components que XNA tiene definidos, así que vamos allá.

¿Qué es un game component?

Un game component podría entenderse como una abstracción lógica de ciertas funcionalidades de nuestro juego. ¿Qué quiero decir con abstracción lógica? Pues simplemente es dividir nuestro juego en componentes lógicos de alto nivel, ya que la principal idea que hay detrás de un game component es la de la reusabilidad, un problema clásico en la ingeniería del software. Es por eso que los game components nacen con la idea de poder ser piezas totalmente intercambiables de un juego a otro, sin que el programador tenga que codificar nada, simplemente un par de lineas para indicar que vamos a utilizar ese componente.

Veamos todo esto con un ejemplo, que seguro que se entiende mejor. Imaginad que estáis realizando un juego en XNA y que ya lo habéis terminado. A continuación comenzamos con el desarrollo de otro nuevo juego y tenemos que volver a codificar las funciones para mostrar el menú, funciones para controlar el mando, funciones para permitir el juego a través de internet… etc. ¿No sería mejor utilizar algo en este nuevo juego de lo que ya teníamos hecho en el anterior? Si en nuestro primer juego que ya está terminado hubiésemos definido un game component para los menús, ahora aquí sólo tendríamos que escribir dos líneas de código para integrarlo, y lo mejor de todo, sabemos que funciona porque ya ha sido probado anteriormente!

La pregunta que nos haríamos ahora es, genial, si esto es así, ¿por qué no hacemos todo con game components? ¿Se os ocurre algo para que esto no fuese así? Lo veremos en el siguiente punto

Cuando es conveniente realizar un game component

Vamos a situarnos, acabamos de decir que los game components son una gran técnica para intercambiar componentes entre varias aplicaciones sin tener que modificarlos, incluso podríamos tener una librería en internet de game components y descargarnos las piezas necesarias para hacer nuestro juego, imaginadlo por un momento, ¿no sería maravilloso descargarnos un componente menú, un componente que manejara el teclado y otro que nos creara un juego de plataformas? Así podríamos sacar juegos como churros sin despeinarnos! ¡Qué maravilla!

Pero lamentablemente la realidad no es esta, ¿cómo es posible que esta idea tan genial no funcione en la vida real? La respuesta a esta pregunta es fácil de encontrar, pongamos un ejemplo con algo más convencional. Si sois programadores habituales de C/C++, Java o C# os hago la siguiente pregunta, ¿cuántas veces habéis implementado una función buscar, que busca un elemento en una colección de datos (arrays, listas, etc.) y luego nos lo devuelve? Seguro que más de una vez verdad, ¿y no sería genial tener una función buscar genérica que nos sirviese siempre para lo mismo? Lamentablemente la respuesta a esto es, depende de los datos, ya que la estructura donde tenemos que buscar no va a ser siempre la misma, ni los datos almacenados, y al final siempre tenemos que volver a codificar la función buscar para cada caso concreto. Pues bien, con la idea de los game components ocurre lo mismo, hay ciertas cosas tan específicas de cada juego, que no se puede abstraer un método genérico para cualquier clase de juego y es por eso que no todo puede ser creado como un game component. La norma general para crear un game component es “si vas a poder reutilizarlo después, créalo como un game component, si no, no te tomes la molestia”

¿Cómo se crean y cómo se utilizan?

Para empezar, deberemos decir que existen dos tipos de game components, aquellos que sólo necesitan actualizar cosas pero no pintar nada por pantalla (es decir, tendrán método update pero no draw) y aquellos que si necesitarán pintar por pantalla. La diferencia entre ambos es que uno hereda de la clase GameComponent y el otro de la clase DrawableGameComponent. Veamos un ejemplo:

Para crear un game component hacemos click derecho (con un proyecto abierto) en el nombre de nuestra solución y elegimos agregar nuevo elemento:

A continuación elegimos Game component

Y se nos habrá creado esta clase:

  public class GameComponent1 : Microsoft.Xna.Framework.GameComponent

Por defecto tenemos un game component que no dibuja nada por pantalla, si queremos que tenga método draw tendremos que indicar que herede de DrawableGameComponent y no de GameComponent, además habrá que añadir el método Draw:

public override void Draw(GameTime gameTime)
{
     base.Draw(gameTime);
}

Ahora ya tenemos nuestro componente creado, ¿cómo lo conectamos con nuestra clase de juego principal? Simplemente creamos una nueva instancia de esa clase y la añadimos a la lista de componentes que tiene XNA, lo haremos así:

GameComponent1 miComponente = new GameComponent(this);
Components.Add(miComponente);

Y con eso acaba todo! Ya tenemos nuestro componente conectado con nuestro juego  listo para usar! ¿Fácil ehh? Pues esto ha sido todo en este artículo, espero que os quede todo algo más claro si no lo teníais ya🙂

Como siempre si tenéis dudas, espero vuestros comentarios, hasta la próxima!

9 pensamientos en “Game Components

  1. Pingback: Curso gratuito de Android | Serious Games

  2. Mi pregunta es la siguiente: si yo programo una dll que luego quiero usar en un juego de XNA como hago para referenciarla pero que se copie en otro directorio, es decir, cuando uno referencia y copia la dll, se copia en la raíz de Content, yo lo que quiero es que se copie en Content\Archivos.. Como se hace?
    Gracias

    • Si he entendido bien tu pregunta, puedes copiar la dll en la jerarquía de carpetas que tu quieras, luego solo tienes que buscar la ubicación de la dll desde el explorador del visual studio, espero que sirva.

  3. entiendo la diferencia entre el game component y la dll…
    es muy similar .. pero en caso de nosotros crear nuestra dll y tener el codigo fuente de la dll.. no sería mejor utilizar esta dll ( pudiendo modificar la fuente en algún ) ??
    pregunto por los tiempos de respuesta y optimización.. o es basicamente el mismo?

    • Realmente no puedo darte una respuesta al 100% segura, pero si tienes el codigo fuente y el compilador lo compila por tí, no será siempre esto más rápido que invocar una dll externa?

    • La gran ventaja de un game component es que tu, como programador, tienes el código fuente y puedes modificarlo a tu gusto o adaptarlo si hiciera falta, no es algo cerrado como una dll, que ofrece una funcionalidad y no puede ser modificada (entendiendo siempre que nosotros no somos los autores de dicho game component o dll)

  4. Pingback: Nuevo artículo, game components « Aprendiendo XNA

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s