XNA 1.1 - Refréscate

Tras una intensa espera, el XNA Team liber la primera revisión de XNA.

Se trata de una revisión simple, con unas cuantas funcioncillas añadidas. Por lo visto el renderizado de texto por fin se escuentra como una de ellas. Podéis leer la noticia aquí.

Mono.Xna resurge de sus cenizas

Mono.Xna, el proyecto para desarrollar un framework equivalente al XNA de Microsoft sobre Mono y librerías gráficas de código libre recupera el tiempo perdido.

Desde que en Diciembre del año pasado apareciera en nuestras vidas la versión 1.0 de XNA las cosas se han revuelto mucho. No es simplemente la aparición simultánea de enormes comunidades de desarrolladores (noveles y no noveles) para esta nueva plataforma, sino las grandes posibilidades que la nueva estructura de programación en XNA provee.

Y es que lo verdaderamente interesante es que, al estar construida sobre el .Net Framework, hereda todas las propiedades que este le da a los ensamblados, entre ellas, la posibilidad de funcionar en multiplataforma. La primera aplicación para esto, evidentemente, es la que Microsoft le ha querido dar, permitir compilar ensamblados para Windows PC y para XBox 360, pero hay más.

Evidentemente soportándose en librerías de código libre y no en DirectX, Mono.Xna pretende hacer un set de librerías que funcione igual que XNA pero sobre Mono. Esta aproximación al XNA Framework es todavía más interesante si cabe, puesto que permitirá en el futuro que cualquier juego para XNA funcione inmediatamente sobre una plataforma no-Microsoft sin siquiera tener que volver a generar los ensamblados. Este proyecto, que lleva desde Noviembre funcionando, ahora resurge de sus cenizas.

Debido a algunos cambios en el núcleo mismo del proyecto, el servidor de SVN, el sitio donde se alojaba el wiki, etcétera, el proyecto se paralizó durante unos meses desde principios de Febrero. Otras cosas que se añadieron al problema fueron que algunos (bastantes) de los colaboradores somos estudiantes y en Febrero tenemos exámenes. También se paralizó porque, aunque había mucho código funcionando, puesto que el objetivo era una compatibilidad 100% con XNA, había que generar muchos tests unitarios, cosa que es bastante complicada tratándose de aplicaciones de bucle contínuo.

Así que hasta ayer, el proyecto no había avanzado gran cosa. Pero ayer tras un parche de proporciones descomunales con una amplia batería de tests unitarios que Stuart Carnie envió a los coordinadores del proyecto, parece que Mono.Xna de nuevo recupera la funcionalidad de antaño. Las clases gráficas que soportan todo el renderizado ya están funcionando y vuelve a funcionar el proyecto "Pong" de ejemplo.

Falta la revisión del código por parte de los coordinadores para subir el parche al repositorio pero, a más tardar este fin de semana, me veo jugando al Pong en mi SUSE Linux con Mono y Mono.Xna.

Finalmente, me gustaría recordar que todos aquellos que seáis fans de las tecnologías XNA y queráis apuntaros a ver cómo funcionan por dentro y a trabajar un poquito en su implementación, podéis hacerlo. Muchos de los que trabajan en el proyecto no son expertos en programación gráfica o de videojuegos; de hecho muchos son estudiantes, pero todos tenemos las mismas ganas de multiplataformizar el mundo, especialmente en lo que se refiere a los videojuegos.

Nuevo componente añadido en XNACommunity

Los componentes son la esencia de los juegos XNA y la base de la simplicidad en el desarrollo. Uno muy interesante (en realidad dos) acaban de subir a XNACommunity.

Los componentes en cuestión son GameState y GameStateManager que colaboran en el trabajo de manejar los estados de una aplicación tan compleja como puede llegar a ser un videojuego.

El modelo de programación de XNA nos obliga a generar una enorme cantidad de GameComponents. Por supuesto esto simplifica muchísimo el sistema de programación y reutilización de código ya que encapsula funcionalidades de una manera intuitiva y automática. Lo difícil llega cuando tenemos que gestionar miles de GameComponents a la vez. En proyectos relativamente pequeños, no será difícil tener que gestionar cientos de GameComponents; en proyectos mayores, la cifra puede incrementarse. Saber cuándo hay que activar o desactivar cada GameComponent y, lo que es más, organizar el código para que el videojuego lo haga y sea intuitivo al programador, puede ser imposible.

Para eso existen los GameState, o los estados del juego. Cada estado refleja una situación en la que se encuentra el juego. Puede ser desde un simple "pausa" y "no pausa" a una estructura más elaborada en que cada estado contenga un nivel del juego o una pantalla. Visto así, el GameState se conforma como una clase contenedora de otras clases que debe de encargarse de manejarlas correctamente en el momento apropiado.

Un GameState se encarga, por lo tanto, de registrar sus GameComponents asociados en el objeto Game cuando se activa, y des-registrarlos cuando se desactiva.

Por supuesto, no tiene sentido tener más de un estado de juego activo al mismo tiempo. Por ejemplo, es absurdo tener activos los estados "pausa" y "no pausa" al tiempo, o los niveles 5 y 9 a la vez. Por eso necesitamos un GameStateManager que se encargue de gestionar la activación y desactivación de los GameState.

Para más información sobre el tema, podéis dirigiros a XNACommunity, donde está publicado el componente con su ejemplo de uso. Hay otros ocho componentes adicionales y la comunidad está abierta a más colaboradores con ideas interesantes y, sobre todo, con ganas de aprender. Todos somos novatos alguna vez, y los genios de verdad lo son siempre. Así que no tengáis miedo y apuntaros. Os esperamos.

Comuniicate con Wiimote

Desde que Wii salió al mercado (en realidad muchiisimo tiempo antes) las expectativas que la consola y en particular la nueva apuesta por revolucionar la jugabilidad empezaron a ilusionar a todos los jugones. Wiimote, el mando estándar de Wii ha roto moldes indudablemente, pero puede hacer mucho más.

El nombre en código de Wii fue Revolution y, aunque mucho misterio envolvía a esta consola hasta su presentación en sociedad el año pasado, todos los jugones (y fans de Nintendo, entre los que me cuento) estaban desesperando por ver, tocar y jugar con la nueva maravilla de la imaginación de la gran N.

Además de fan de Nintendo, sin embargo, soy fan de .Net (no necesariamente de Microsoft) y la idea de utilizar las ventajas de Wiimote en mi PC via .Net siempre es una maravillosa noticia. Ya oí hace unos meses de un friki que, nada más conseguir su Wiimote lo conectó con su Mac, pero la frikada de hoy bien merece un estudio eshaustivo.

Ziggyware.com ha publicado un vídeo en YouTube donde se muestra cómo un Wiimote puede controlar un videojuego hecho con XNA sobre .Net. Aquí os lo dejo.

Lo interesante en realidad, al menos para tiralíneas de código como yo, no es que el ordenador responda a un Wiimote conectado por bluetooth. En realidad, eso es relativamente simple... siempre y cuando tengamos una API para recibir los datos del Wiimote y poder trabajar con ellos. ¿Os gustaría tenerla? Pues en ziggiware.com lo tienen. Aquí os dejo el link para su descarga. A ver qué hacéis con vuestras Wii.

Nuclex.Fonts - Renderizando fuentes con XNA

Si hay alguna funcionalidad necesaria para la programación de videojuegos que XNA no facilita ésa es la del renderizado de caracteres (o fuentes). Nuclex intenta solucionar el problema usando el modelo de programación de .net y XNA de manera sencilla.

Creo que todos coincidimos en que el renderizado de fuentes por pantalla es una función imprescindible de los videojuegos. Sin embargo, por desgracia, XNA, a pesar de su enorme versatilidad y su API sencilla y amigable, falla enormemente en este aspecto no proporcionando un sistema de rederizado de fuentes.

Sin embargo, lo que sí proporciona XNA es un modelo de programación fácilmente extensible. Por eso, una vez registrada la necesidad de funcionalidad, es fácil preparar un parche que nos cubra la necesidad. Yo ya he visto varios por la red, pero uno de los más sencillos (si no el que más) es la librería de componentes de Nuclex.

La gran ventaja de Nuclex es que está completamente integrado con el modelo de programación de XNA, basado en componentes. En realidad, la dll que nos proporciona nos ofrece un componente llamado TextManager, que podemos incluír en nuestro juego como haríamos con cualquier otro componente. Los métodos Update y Draw ya están definidos y el único problema se plantea a la hora de cargar la fuente que queremos utilizar en pantalla.

Nuclex.Fonts nos soluciona ese problema, porque además de proporcionarnos el componente para renderizar fuentes, nos proporciona la extensión del Content Pipeline para cargarlas en nuestro juego como cargaríamos cualquier tipo de contenido. Para saber qué hay que hacer y cómo, podéis ver el tutorial (en inglés).

Los resultados son verdaderamente sorprendentes. Cualquier fuente TrueType puede ser renderizada en pantalla con muchísima facilidad. Una simple llamada a la función DrawString nos permitirá renderizar lo que queramos por pantalla. Estoy deseando empezar a usarlo en mi proyecto de Juegos y Realidad Virtual. ¿Y vosotros? Si queréis os podéis bajar el código fuente de la solución aquí.

Xna Community

La comunidad de codeplex dedicada a la generación de una librería de componentes para XNA llega a sus 1000 visitas.

A aquellos a los que nos gusta XNA nos gusta conocer gente a quien también le gusta XNA. Por ellos se han creado tantísimas comunidades en Internet desde el lanzamiento de esta plataforma-tecnología. Una de ellas, dirigida a entusuastas españoles, es XNACommunity alojada en el servidor CodePlex.

XNACommunity libera su código de manera similar a como lo hacen la mayoría de los proyectos Open Source. Utiliza, como (posiblemente) todos los proyectos de CodePlex, la licencia de Software Libre made by Microsoft (Microsoft Community License). En esencia, permite a cualquier persona reutilizar, modificar y redistribuir el código protegido bajo la licencia, de manera similar a otras licencias de código abierto.

El proyecto está abierto a cualquier persona, pero está especialmente dirigido a estudiantes entusiastas de los videojuegos y a miembros de los DotNetClubs de España. No obstante, como digo, cualquiera puede colaborar.

Hasta el momento, la comunidad ha creado y publicado ocho componentes (un marcador, un cubo, una cámara que sigue a un objeto, una cámara que realiza una ruta, un recorrido sobre texturas 2D, un componente que mueve una imagen por la pantalla, un scroll de pantalla y una bola que rebota). Por supuesto, si estás experimentando con XNA y quieres hacer público tu trabajo, eres bienvenido a la comunidad.

Además de la comunidad, donde puedes encontrar un wiki actualizado con las noticias y los últimos componentes actualizados entre otros, puedes acceder al foro de la comunidad, alojado con el resto de foros de los DotNetClubs, donde puedes preguntar y recibir respuesta a tus dudas sobre XNA o compartir lo que sabes con otros usuarios.