El XNA Content Pipeline

Actualmente el contenido gráfico y sonoro es una pieza clave para el desarrollo de videojuegos. Cuando surgieron los primeros juegos de ordenador, el contenido del que disponian era francamente limitado, en parte por que la tecnología no daba más de si, sin embargo, hoy en día, y gracias a los grandes avances que se han realizado en hardware, los juegos muestran un generoso contenido digital, mezclando imagenes 2D, modelos 3D, efectos, sonidos, etc...

Todo este contenido, a parte de ser creado por los diseñadores, debe introducirse en el juego. Esta tarea no es algo que podamos definir como sencilla, y por ello es común que en un equipo de desarrollo exista un grupo especializado únicamente en este área, pues implica una gran carga de trabajo. Hay que realizar exportaciones o programas de exportación de este contenido a un formato legible para el juego, realizar la codificación para cargarlo y en resumen, hacer todo el trabajo necesario para reproducirlo correctamente en el juego.

El Content Pipeline de XNA(desde ahora CPL) hace este trabajo por nosotros. Desde el propio Visual Studio, al igual que añadimos archivos de código al proyecto, podemos añadir contenido(archivos de imagen, sonido, efectos, etc..) a nuestro proyecto de XNA. Esto nos permite organizar todo el juego desde una única solución, indiferentemente del número de proyectos que contenga.

El CPL permite a los desarrolladores incorporar contenidos multimedia a los proyectos XNA. Los diseñadores crean estos archivos(Digital content creation) desde numerosas y variadas herramientas, guardando este contenido multimedia en numerosos tipos de formatos de archivo diferentes , .gif, .jpg, .fbx, .x, wav, mp3, etc... El CPL esta diseñado para ayudar al desarrollador a incluir estos ficheros en el juego de una manera facil y automática, indiferentemente del formato del archivo.

Soporta una amplia gama de formatos de archivos para importar a nuestro proyecto, básicamente se trata de los formatos mas utilizados en la creación de videojuegos. No obstante, podemos encontrarnos con la necesidad de cargar otros formatos de archivos que no son soportados por el CPL, de hecho, y muy comunmente, en la industria de los videojuegos, los desarrolladores utilizan archivos personalizados para sus proyectos. Por ello, el CPL de XNA es extensible, incorpora un marco de trabajo estandarizado que permite facilmente incluir soporte a diferentes tipos de archivo.

Pero ¿que es lo que ocurre internamente cuando importamos un archivo a nuestro proyecto?. ¿Que clase de transformaciones sufre y como se llevan a cabo?, y no menos importante, ¿quien hace estas transformaciones?. De esto hablaremos a continuación.

En el transcurso de construcción de un archivo de contenido digital , el CPL invoca cuatro componentes principales para transformar el archivo original de contenido en un archivo binario para el juego. Veamos esto mediante una imagen que muestra la arquitectura del CPL de XNA para mayor comprensión.

Content Importer

Cuando se añade un contenido, este lo recoge un importador. El importador es el encargado de obtener los datos y normalizarlos. Después de que el importador ha hecho su trabajo , los datos existen en un DOM fuertemente tipado, es decir, se encuentran en un formato conocido.

*DOM(Document Object Model), es el término que se utiliza para indicar una colección de clases o un esquema(por ejemplo un xml).

Este DOM devuelto por el importador será el que utilizará el content processor(Procesador de contenido). En ocasiones, no tiene porque devolver un DOM, sino que podría también retornar un objeto personalizado creado por el desarrollador.

XNA proporciona un número limitado de importadores de contenido estándar para los formatos de archivo comunmente más utilizados en la creación de videojuegos. Para los formatos de archivo que no estén soportados por estos importadores estándar, podemos crear nuestro propio importador personalizado.

Content Processor

El procesador de contenido recibe los datos que el importador ha generado y crea un objeto para su uso en tiempo de ejecución. Este objeto puede ser tan simple como un modelo o mucho más complejo.

Los procesadores estan diseñados para que sean faciles de escribir, compartir y reutilizar. Los transformadores tiran de los datos del contenido DOM. Es decir, el procesador funciona con independencia del formato del archivo original, debido a que todos sus datos están almacenados en un formato conocido. Además existen métodos de ayuda que permiten manipular y generar nuevos datos de contenido DOM.

El CPL de XNA incluye algunos procesadores, por ejemplo, Model (para objetos simples con texturas), Texture2D(para sprites o combinaciones con modelos), Effect (para manejar los materiales de los modelos), etc... Pero puede que queramos mas flexibilidad todavía para nuestro contenido, quizás el mundo de nuestro juego no puede ser construido únicamente con modelos simples, podríamos desarrollar un procesador que dados múltiples objetos, generará uno que los englobara a todos (si, como el anillo del señor oscuro :D) .Por ejemplo:

Si estuvieramos haciendo un juego de coches. Tendremos varios archivos de contenido que forman la pista. En la pista podemos tener todo tipo de datos. Puntos de inicio y final, sitios de control cuando pasa el coche, etc... Entonces, en lugar de tener la pista en cientos de trozos, podemos simplemente escribir un procesador que consumirá todos esos datos y hacer que directamente devolviera un objeto pista. Claro, luego nuestro motor de juego deberá comprender ese objeto pista para saber que hace con él, pero eso ya es otra cosa.

Content Type Writer

El content Type Writer es el responsable de recoger el objeto generado por el procesador y grabarlo físicamente en disco. Este archivo binario se guardará en un formato especifico de XNA con la extensión .xnb

Content Type Reader

El content Type Reader es el encargado de almacenar el objeto en memoria cuando queramos acceder al contenido, dicho de otra manera, deserializa el archivo creado por el writer y lo almacena en un objeto en memoria para su uso. El reader es llamado por xna mediante el componente Content Manager.

_____________________________________________________

Hasta aquí, la construcción de un objeto desde un archivo de contenido importado a XNA. Los cuatro componentes que he citado pueden programarse, pero no hace falta implementarlos todos, es decir, en ocasiones puede que únicamente nos interese crear un importador y un procesador, o sólo un procesador, etc..

Por último, indicar que tanto el importador como el procesador de contenido y el writer, se ejecutan en tiempo de compilación, generando en el paso final el archivo .xnb. Por otra parte, el Content reader es invocado siempre en tiempo de ejecución, cuando el juego ya está ejecutándose. Lo que sigue a continuación puede aclarar ciertas cosas.

- Las partes contenidas en la zona amarilla de la imagen, siempre se ejecutan en windows y por consiguiente, en el ordenador en el que se está desarrollando, o mejor dicho, compilando el juego.

- Las partes contenidas en la zona lila de la imagen, se ejecutan en windows, XBox o Zune, pues es donde se ejecuta el juego.

- La zona amarilla utiliza clases contenidas en el ensamblado Microsoft.Xna.Framework.Content.Pipeline

-Las partes de la zona roja no tienen la referencia al ensamblado de la CPL.

-Cuando se distribuye un juego hecho en XNA, todas las partes de la zona roja deben incluirse, mientras que las partes de la zona amarilla no son necesarias en la distribución.

Despues de esto, la pregunta que podemos hacernos es: ¿como accedemos a ese contenido desde nuestro juego?. Pues como adelantaba anteriormente, lo haremos con el Content Manager.

Content Manager

El content Manager es un componente diseñado para cargar los archivos de contenido rápida y facilmente. Maneja todos los pequeños detalles, como velar para que todos los activos asociados esten cargados al mismo tiempo.

Ejemplo de código.

Texture2D miTextura = Content.Load<Texture2D>("MiImagen");

En esta linea de código se carga un archivo que previamente hemos importado a XNA. El content Manager localizará el archivo asignado al nombre "MiImagen", para luego invocar al Content Type Reader que nos devolverá un objeto del tipo Texture2D.

En otro artículo veremos un ejemplo de como implementar lo expuesto en esta entrada.

Referencias:

- Xna Team Blog: The XNA Framework Content Pipeline
http://blogs.msdn.com/xna/archive/2006/08/29/730168.aspx

-MSDN : Content Pipeline Architecture
http://msdn.microsoft.com/en-us/library/bb447745.aspx

-Shawn Hargreaves Blog: Content Pipeline assemblies
http://blogs.msdn.com/shawnhar/archive/2008/11/24/content-pipeline-assemblies.aspx

- Ideas de un conejo: El XNA Content Pipeline
http://juank.black-byte.com/xna-content-pipeline/

[Leer artículo completo]

El framework XNA

El Framework XNA es un conjunto de librerías diseñadas y destinadas especificamente para el desarrollo de videojuegos. Para explicarlo mejor, veamos una imagen que nos indique donde está situado este framework dentro del modelo de capas de XNA.

Como se observa en la imagen, el framework XNA se ejecuta bajo .net. Se puede apreciar, que según en la plataforma donde esté en ejecución, el framework .net no será el mismo, pues XBox 360 y Zune a diferencia de Windows, utilizan el compact Framework, que además, no es el mismo compact framework de windows mobile. De esta manera sabemos que xna funcionará tanto en PC con windows(xp o vista), XBox 360 o Zune, pero no por el momento en windows mobile.

El Framework XNA tiene dos objetivos principales.

Uno de los objetivos es facilitar el desarrollo de videojuegos para las tres plataformas(Windows, Xbox 360 y Zune). Es decir, podemos crear un juego para windows y luego crear su versión para XBox rápida y facilmente sin mayores quebraderos de cabeza. Esto es posible gracias a las API que proporciona el framework XNA, que en su mayoría sirven para todas las plataformas. Evidentemente encontraremos funcionalidades que únicamente podremos utilizar para determinada plataforma, pero en general, muchos juegos son 100% compatibles entre las diversas plataformas.

El otro objetivo del framework XNA esta enfocado en la misma dirección que el anterior, facilitar el desarrollo de videojuegos. Hacer un juego no es fácil, no lo es para los profesionales que se dedican a ello, menos lo va a ser para la gente que empieza. Hay un montón de código que picar, pruebas a realizar y errores que tratar antes incluso de dibujar un punto en la pantalla. Gracias al framework XNA, no vamos a tener estos problemas.

No vamos a tener que preocuparnos de crear la ventana del juego, ni capturar los mensajes de windows, ni comprobar los eventos de inactividad, etc... Tampoco nos preocuparemos de enumerar los adaptadores gráficos o modos de pantalla, ni crear disposivos de Direct3d y gestionar cuando minimizamos el juego, o cambiamos el tamaño de la pantalla. Todo esto y más cosas, las hará el Framework XNA por nosotros.

A continuación, vamos a ver el modelo de capas que componen el Framwork XNA, para de esta manera, conocerlo mejor.

Como vemos, el framework XNA esta compuesto por 4 grandes capas: Plataforma, Nucleo del Framework, Framework extendido o extensible y juegos.

Plataforma

Es la capa mas baja, contiene las API nativas enmascaradas por XNA que son utilizadas mas arriba, en otro nivel, por las clases administradas. Algunas de las API que incluye esta capa son Direct3D 9, XACT, XINPUT, XCONTENT.

Núcleo del framework:

El núcleo, en realidad, es la primera capa del framework XNA. Proporciona las funcionalidades básicas sobre las que las otras capas trabajan. Si se quisiera proporcionar funcionalidad adicional gestionando con DirectX, se construiría en esta capa. Las areas agrupadas en el nucleo son las siguientes:

• Gráficos:
  Como hemos visto anteriormente, la API gráfica(Graphics) que utiliza XNA es Direct3D 9. Un dato importante a tener en cuenta , es que a diferencia de DirectX9, XNA no tiene soporte para la pipeline de función fija(Fixed-Function Pipeline o FFP), al igual que DX10 y XBox. Esto lo explicaré mas detenidamente en otro post sobre la pipeline de renderizado. De todos modos, saber que en XNA puedes programar tus propios Shaders y efectos, y que para programar los juegos sin tener que desarrollar los shaders, existen clases que encapsulan shaders, como BasicEffect para definir el detalle final del renderizado de la escena y modelos 3D, o SpriteBatch para el muestreo de sprites en 2d.



• Audio:
  XNA admite los siguientes formatos de archivos de sonido: .xap, .wav, .wma y .mp3.
  
  El sonido en XNA, antes de la version 3.0 sólo se reproducia a través de XACT (Cross-platform Audio Creation Tool), que es una librería de alto nivel para audio. Fue realizada por microsoft como parte de las sdk de directX y originalmente fue diseñada para XBox como API para el procesamiento óptimo de la señal digital. Posteriormente fue modificada para su funcionamiento en windows.
  
  Dentro de las herramientas que proporciona el XNA Game Studio, encontraremos una aplicación para crear los proyectos de audio necesarios para la API XACT. La aplicación se llama exactamente igual: Microsoft Cross-platform Audio Creation Tool (XACT), es un editor donde podremos empaquetar/agrupar nuestra música(en archivos .wav), configurando opciones como el volumen, las repeticiones mediante bucles, la mezcla de canales(incluye 5.1), etc... Esta herramienta guarda los proyectos en archivos .XAP que importar mas tarde a nuestro proyecto XNA.
  
  En el "pack" de herramientas suministradas por XNA también encontraremos XACT Auditioning Utilility, que es el servidor que reproducirá el sonido. Todo esto ya lo explicaré a modo de tutorial en otro artículo.
  
  Nota: No confundir XACT, con xACT de mac, no tiene nada que ver.
  
  A partir de la version 3.0, además de importar archivos .xap, también podremos añadir directamente ficheros .mp3, .wav y wma.



• Entradas:
  La API de entradas(Input) del usuario, es XINPUT de directX. Es de acceso inmediato, no requiere ningún tipo de inicialización previa ni nada por el estilo, es más, no hay que preocuparse de asignar o liberar el dispositivo de entrada. Lo unico que hay que hacer es llamar al método GetState sobre el controlador adecuado y ya está :D. Hay clases para los controladores necesarios: el teclado(Keyboard), el ratón(Mouse) y por supuesto el mando de la XBox(GamePad). Hasta se pueden controlar los motores de vibración del mando de una forma sencillísima.



• Matemáticas:
  La API de matemáticas(Maths), nos proporciona una gran colección de clases y métodos para el cálculo matemático. Por ejemplo, incluye los tipos de datos que comunmente se usan en la programación de videojuegos, tales como Vector2, Vector3, Vector4, Matrix, etc.. Además tambien incluye tipos de volumenes como BoundingBox, BoundingSphere y BoundingFrustum, que poseen métodos para la detección de colisiones.
  
  Las matemáticas en XNA a diferencia de DirectX(mano izquierda), usan por defecto el sistema de coordenadas basadas en la regla de la mano derecha(right-hand coordenate system). No obstante se podría utilizar la regla de la mano izquierda(left-hand coordenate System), en dicho caso, muchos cálculos matemáticos se deberían realizar por cuenta propia.



• Almacenamiento:
  La API de almacenamiento(Storage), proporciona formas para leer y escribir los datos de los juegos, como por ejemplo, las partidas guardadas, puntuaciones o lo que se nos pueda ocurrir. En windows sería fácil, utilizariamos las clases del namespace System.IO, pero en XBox, es algo diferente, tendríamos que asignar un perfil para dispositivo de almacenamiento y controlar el estado del juego. La API de almacenamiento, "emula" que estamos en una única plataforma, por lo que utilizaremos el mismo código para guardar datos, indistintamente estemos en XBox, Windows o Zune.

Framework extendido, extensible o de extensión

El objetivo principal de esta capa es facilitar el desarrollo al programador.

Existen dos elementos principales en esta capa:

• Modelo de aplicación:
  El proposito del modelo de aplicación(Application model) es el de apartar al programador de los problemas con la plataforma en la que se ejecuta el videojuego. No tendremos que preocuparnos, de crear una ventana para el juego o controlar los eventos del SO si estamos en windows. Tampoco nos preocuparemos de la creación de contadores de tiempo, bucle del juego, etc..
  
  También proporciona la clase GraphicsDevice, que se encarga de la creación y gestión de los dispositivos gráficos, y una GraphicsComponent que utilizaremos para el renderizado de las escenas, y que a su vez gestionar dicha GraphicsDevice.
  
  Además, en esta parte también se proporciona un modelo de componentes, que permite crear GameComponent para incluirlos a nuestros proyectos, ya esten hechos por nosotros mismos o por otras personas. Esto permite, si lo deseamos, crear nuestra librería de componentes y reutilizarlos en diferentes proyectos, asi como compartirlos con la comunidad.
  
  
• Administrador de contenido (Content Pipeline):
  La Content Pipeline(en adelante CPL) permite a los desarrolladores incorporar contenidos multimedia a los proyectos de XNA, tales como imagenes, sonido, modelos 3d, efectos, etc... Facilita el acceso a estos archivos y nos proporciona una interfaz unificada sin una excesiva complejidad.
  
  Permite una amplia gama de formatos de archivos diferentes, que básicamente son los más utilizados en la creación de videojuegos. No obstante, es un número limitado, no soporta todos los formatos actuales, además de que muy comunmente, en la industria de los videojuegos, los desarrolladores utilizan archivos personalizados para sus proyectos, por lo que el CPL es extensible. Incorpora un marco de trabajo que permite facilmente incluir soporte a diferentes tipos de archivo.
  
  No me extenderé más en este punto, pues crearé un extenso artículo en referencia a la CPL de XNA.

Juegos

La capa mas alta del XNA. Aquí se encuentra el código del propio juego, incluyendo los componentes, los kits de inicio etc..

• Kits de inicio: Hay multitud de kits de inicio para crear videojuegos, no se tiene que programar el juego desde el principio. Se pueden utilizar estos kits como punto de partida o simplemente para ojearlos, ver como están escritos y aprender de ellos.

• Código: Sencilla y llanamente el código del juego.

• Contenido: Archivos de imagen, sonido, etc...
  
  
• Componentes: Los componentes creados por ti mismo o por otras personas.

[Leer artículo completo]

Planificación de un videojuego

El desarrollo de un videojuego siempre comienza antes de la fase de codificación. Debemos tener una buena planificación sobre nuestro juego. No basta con tener una idea sino que hay que ordenarla.

Seguramente ésta parte es la más infravalorada para la gente que, como yo, no hace juegos profesionales. Al leer documentos sobre planificación de videojuegos me he dicho en más de una ocasión: "va, para que voy a hacer ésto, menuda pérdida de tiempo", pero realmente ayuda y mucho. Te permite aclarar y pulir tus propias ideas y muchas veces al volver a leerlos se te ocurren más cosas que introducir o cambiar. Al final todo depende de que queremos hacer con nuestro juego y para que y quien/es fue creado.

Lo primero que tenemos que tener claro es a que destino del mercado vamos a dirigirnos. El destino de un videojuego siempre son sus jugadores. En el mercado actualmente existen dos grandes categorías de jugadores.

• Jugadores infrecuentes: Más comunmente llamados "Casual gamers" (jugadores ocasionales), buscan juegos donde la mecánica del mismo sea fácil de entender y que en general requiera de poco esfuerzo avanzar en él. Juegan poco y cuando lo hacen no buscan una excesiva complejidad.
  
• Grandes jugadores :También denominados "Hardcore gamers". Invierten varias horas en jugar, usualmente buscan juegos largos con una buena historia y buenos detalles gráficos, con controles de jugador avanzados y complejos, diversas opciones de dificultad que les supongan retos para poner a prueba su habilidad, etc..

Dentro de estos dos grandes grupos existen subgrupos, como podrían ser los jugadores de consola, dispositivos portatiles, etc..

Una vez sabemos a que tipo de jugadores va a estar destinado nuestro juego, debemos elegir un género para él : estrategia, shooter, aventura, acción, deportes, conducción, lucha, juego de rol, naves, etc...

Cuando tengamos el destino y el género para nuestro videojuego, debemos planificarlo para que se convierta en un buen juego y no algo abstracto que vamos creando mientras lo desarrollamos.

Toda planificación de un juego debería tener, en la medida de lo posible, los siguientes puntos claves:

Breve descripción:
Una pequeña descripción del juego en unas 25 o 30 palabras. Por ejemplo: "un juego de estrategia espacial con diferentes razas (humanos y extraterrestes) donde las batallas trancurrirán en diversos planetas luchando por la conquista.". o "un juego de futbol con diversos campeonados donde los jugadores serán animales" y cosas por el estilo, no hace falta ser un lumbreras.

Objetivo:
Todo juego debe tener un objetivo, ya sea el de salvar el mundo de los extraterrestres, derrotar al demonio, ganar la copa de europa, etc... El objetivo del juego define un principio del cual partir para crear la historia, por lo que será la guía para crearla.

La historia:
Esta ligada claramente al objetivo del juego, explicando y justificando el objetivo del mismo. Es crucial para mantener al jugador inmerso en él. Podemos crear historias no lineales dentro de la misma historia con el objetivo de que el jugador crea o tenga la sensación de contribuir en ella.
Además debemos fijar todos los detalles que la afectan o la arruinaremos. Por ejemplo, no vamos a introducir una música de Metalcore plagada de adrenalina en una escena romántica o triste, o colocar un ferrari, si nuestro juego relata las aventuras en el año 920 DC. La historia es una parte muy importante en los juegos y no queremos que pequeños detalles nos la arruinen.

Criterios de finalización y otros estados:
El juego debe tener unos criterios de finalización, los de finalización de juego probablemente serán el propio objetivo del videojuego, pero hay que definir también muchos otros. Criterios de no victoria, por ejemplo, cuando el jugador muere, pongamos por caso definiendo que es cuando su vida llega a 0, o cuando no ha cumplido los objetivos de la fase(destruir 4 bombas nucleares), etc... Además, cuando el personaje muere ¿que influira en ello?, ¿no habrá penalización?, ¿reaparecerá con la vida al 50%? o ¿existirá otro tipo de penalización?, ¿tal vez el número de proyectiles que tenga en su poder?

Dentro de los diferentes tipos de criterios de finalización hay que definir también y es algo vital, como el jugador volverá al juego, puntos donde se permitirá guardar y luego volver a ese punto(o cercano) al comenzar nuevamente. Tambien están los criterios de final de nivel, etc.

Existen otros criterios que abordar a parte de los de finalización, ¿Que tiene que hacer el jugador para curar a su personaje?, y ¿cuanto le curará esa acción? o no menos importante, ¿cuando sube de nivel?, ¿o cuando consigue mejores armas o municiones?, etc.. Hay muchísimos criterios que deben ser definidos para el correcto funcionamiento de nuestro juego.

Jugabilidad:
Definiéndola vulgarmente sería lo divertido que puede llegar a ser jugar a nuestro juego. En unos 20 o 30 minutos de juego debemos demostrarlo, de lo contrario ese tiempo puede marcar que un jugador no vuelva a probar nuestro querido videojuego.

La jugabilidad está relacionada con el tipo de jugadores que anteriormente seleccionamos. No es lo mismo una jugabilidad para un casual gamer que para un hardcore. La jugabilidad nada tiene que ver con la calidad gráfica que posea el juego.

Un juego con una buena jugabilidad será aquel que muestra una interactividad óptima para el tipo de juego que es y el tipo de jugadores para el cual fue creado.

El diseñador del juego debe crear una serie de reglas que serán las que marquen la interactividad del jugador con lo que ocurre en su pantalla. Para ello, debe plantear una serie de decisiones equilibradas, ni demasiado fáciles ni demasiado dificiles, que muestren que abordar según que retos es difícil, al mismo tiempo debe hacer ver que no son imposibles, creando de esta manera una satisfacción al superarlo.

Hay muchísimas cosas que influyen en la jugabilidad y para todas ellas debemos crear esas pequeñas reglas. Un control intuitivo del personaje, una interaccion fluida de las acciones que toma el jugador respecto a la historia o el mundo en el juego, etc, El conjunto de estas reglas definirán la mecánica de tu videojuego.

No basta con que tengamos una jugabilidad apabullante en el inicio, sino que debemos mantenerla, un juego repetitivo está abocado al aburrimiento y al fracaso.

Programación:
Como no, la programación. Debemos planear estados, tanto de personajes como de objetos, tipos de colisiones y que impacto tendrán en el juego, las clases base, las propiedades e incluso si crearemos o utilizaremos frameworks o motores externos. Aqui puede ir todo lo que se te ocurra y que necesite ser escrito.

Otros:
Además de estos puntos existen muchos otros, aunque varios de estos seguramente pueden ser introducidos en la jugabilidad del juego. Pero por ejemplo podemos pensar en tener una comunidad online, con foros y artículos, o podemos tener en mente grabar un registro de records online que pueda ser consultado para ver las puntuaciones frente a otros jugadores, incluso subir capturas de pantalla o videos desde el propio juego a la comunidad, etc. También y no menos importante, planear algo para que el jugador vuelva a querer jugar a nuestro juego, esto podría ser desbloqueando niveles de dificultad, o añadiendo algun que otro cambio. Y no hay que olvidar los premios, debemos definirlos. ¿Que conseguirán los jugadores por pasar los retos a los que les hemos puesto a prueba?.

Nota: Yo tengo la creencia que un juego hecho con ganas e ilusión por parte de los desarrolladores se nota más tarde al jugarlo. No empieces algo que no te gusta, porque seguramente afectará al resultado final. Además nunca te pongas como objetivo realizar juegos que superen tus conocimientos, jamás los terminarás, creeme, lo sé por propia experiencia. :D

Hay cosas que uno comprende que no las sabe hacer, pero tiene la convicción que aprenderlas no será muy dificil, de éstas no hablo. Pero intentar hacer un MMO sin haber realizado ningún juego o haber hecho 1 o 2 pequeños, no entra en algo que definamos como fácil.

Es más importante acabar un juego que tener uno enorme pero incompleto. Haz juegos fáciles y pequeños al principio y luego ya irás subiendo de nivel.

[Leer artículo completo]

¿Qué es XNA?

XNA es un juego de palabras. Quiere decir "XNA's Not an Acronym". Los productos y tecnologías de Microsoft tienen tantos acrónimos que decidieron crear un nombre que se viera como un acrónimo pero que en la realidad no lo fuera. Por lo tanto no hay que buscar más en esas tres letras, única y exclusivamente es su nombre.

XNA Game Studio es un entorno de desarrollo para la creación de videojuegos en Xbox 360, Microsoft Windows y Zune. Contiene, un conjunto de herramientas para Visual Studio(c#), herramientas externas para la introducción de gráficos y sonidos en los juegos, documentación, ejemplos y el framework XNA.

El framework(o marco de trabajo) XNA es una biblioteca de clases de código administrado(Managed Code) diseñadas y destinadas especificamente para el desarrollo de videojuegos. Se basa en el Framework .Net, por lo que a la hora de crear los juegos utilizaremos XNA para las tareas especificas de éste y el Framework .Net para las tareas de programación más generales.

El objetivo de XNA es hacer el desarrollo de juegos mas fácil para el programador. Evitando que éste se enfrente a problemas de integración con la plataforma, los dispositivos gráficos, etc. De esta manera el desarrollador únicamente se centra en escribir el código.

El Framework XNA trabaja en una capa abstracta por encima de las DirectX llamando a sus funciones nativas. Anteriormente a XNA existían las denominadas Managed DirectX (MDX), que al igual que XNA, permitían desde .Net llamar a las funciones de DirectX. Básicamente eran las mismas funciones DirectX pero para .Net, un puente por decirlo de alguna manera. Los mismos nombre(o parecidos), la misma funcionalidad, etc, lo que se suele denominar un "wrapper".

XNA es mucho más que eso, no son simples funciones de mapeo sino que es todo un marco de trabajo especializado para la creación de videojuegos, claramente más intuitivo que MDX y por supuesto más sencillo que las DirectX.

XNA substituye a MDX por lo que no encontrarás más versiones de esta última. Lo que no hará nunca es substituir a DirectX ya que como anteriormente he comentado, XNA llama a sus funciones nativas. Por lo tanto irá adaptandose conforme vayan surgiendo nuevas versiones de DirectX.

XNA Game Studio funciona con todas las versiones de Visual studio 2008, incluida la versión gratuita(express). Esta pensado para trabajar con el lenguaje c#. Al ser una biblioteca de ensamblados(dll), nada impide que puedas referenciar estas dll en proyectos con otros lenguajes .Net, como por ejemplo Visual Basic .Net. No tendras las plantillas y otras herramientas(Aunque ya hay gente que las ha hecho).

De todos modos el desarrollo para XBox 360 únicamente soporta el lenguaje c# ya que el Compact Framework que corre en XBox 360 y Zune(que nada tiene q ver con el compact framework de windows mobile), no soporta el ensamblado Microsoft.VisualBasic.dll. Está claro que tu decides si quieres incluir ese ensamblado o no a tu proyecto, pero hay consecuencias entorno a la velocidad y uso de la memoria al no usarlo. Eso sí, podrás desarrollar juegos para windows sin ningún tipo de problema con Visual Basic.

XNA Game studio es gratuito, puedes bajarte el kit de desarrollo en la página de Microsoft. Está basado para desarrollar sobre Visual Studio. Lo sé, no te preocupes, XNA como dije antes también funciona con las versiones gratuitas de Visual Studio, por lo que basta con bajarse Visual Studio c# express.

Links de descarga

• Visual c# 2008 Express edition (http://www.microsoft.com/express/download/)
• XNA Game Studio 3.0 (http://www.microsoft.com/downloads/details.aspx?FamilyId=7D70D6ED-1EDD-4852-9883-9A33C0AD8FEE&displaylang=en)

Por si es de interés, os comento que es posible vender juegos hechos en XNA en XBox live, aunque para ello debe pasar los controles de calidad y ser seleccionado por la comunidad. Además al contrario que el desarrollo para Windows o Zune, crear un juego para XBox no es gratuito, pues se necesita una suscripción especial a Creators Club. El precio no es muy caro, 99 euros anuales. Más información aquí: http://creators.xna.com/es-ES/faq

Web Oficial de Creators Club. http://creators.xna.com/

Los requerimientos para ejecutar un juego hecho en XNA para windows son los siguientes:

(Más que nada por si le quieres pasar tu juego a un colega :D)

• Tarjeta gráfica que soporte Shader Model 1.1 y DirectX 9.0 (Recomendado Shader Model 2.0)
• Tarjeta grafica que soporte Shader Model 2.0
• Microsoft® Windows® XP(Service Pack 3) o Windows Vista™ (Service Pack 1)
• DirectX 9.0c. Redistribuible
• XNA framework 3.0 redistribuible
• .Net framework 2.0 redistribuible o superior.

[Leer artículo completo]