Las 3 Librerías para programar videojuegos ( I ): SFML 2.0

Tres son las librerías principales que usaremos para programar videojuegos. Estas tres librería cubrirán todos los aspectos de programación que necesitemos para crear desde un juegos ASCII hasta un juegos 3d con conexión a red.

Las librerías son:

SFML 2.0 como núcleo principal, de la que hablaremos a continuación en este post,
Box2D como sistema de colisiones y de simulación física
TMXParser como librería para leer los archivos de Tiled.

 

¿Qué es SFML 2.0?

 

SFML 2.0 es el acrónimo de simply and fast multimedia library, una librería que nos da toda una serie de clases que nos permitirán crear cualquier aplicación multimedia. Es una creación de Laurent Gomila y que pone su trabajo a la disposición de todos bajo la licencia zlib/png, que básicamente viene a decir, “haz lo que quieras con las aplicaciones creadas con esto”, es decir podremos crear aplicaciones comerciales con código cerrado si queremos.

Actualmente hay dos versiones a disposición de los internautas, la versión 1.6 es la versión definitiva de la versión 1 de la librería, es antigua y ya no se van a mejorar. Yo utilizo la versión 2.0 que todavía es RC(release candidate) pero que esta totalmente operativa y tiene mucha mejor estructura interna que la versión 1.6, además es la que actualmente esta en desarrollo.

Empezar a usar la librería es muy sencillo, simplemente hay que seguir los pasos del tutorial para el compilador que queramos usar. En Windows hay una pequeña diferencia con la configuración en otros SO, para que la aplicación no abra una consola de DOS, hay que crear una aplicación de ventana y usar una librería especial para Windows llamada sfml-main.lib, esta nos permitirá usar la función main estándar de C/C++ para crear nuestras aplicaciones en vez de la función WinMain de los sistemas Windows, haciendo nuestro código mas portable.

Componentes de SFML 2.0

 

Las librería de SFML se dividen en 5 módulos principales que contienen una seria de clases que nos ayudad en algún aspecto de las aplicaciones multimedia. Estos módulos son:

Window Module: Aquí se encuentra todo lo relacionado con la creación básica de aplicaciones en el sistema operativo que corresponda. Por ejemplo sf::Window es la clase encargada de crear la ventana de la aplicación en el SO en el que se trabaje (Windows, MacOS, Linux ), también tiene las clases que nos permiten recibir eventos del SO, como redimensionado de la ventana, o minimizado, y el control de las entradas de teclado, ratón y joystick.

System module: Este modulo contiene utilidades relacionadas con el sistema operativo, pero que no son propias del sistema de ventanas, como los Threads (Hilos de programación paralela), el sistema de temporización, etc.

Graphics module: Este tiene todo lo necesario para realizar dibujados en 2D de cualquier cosa, también tiene las clases correspondiente a la carga de imágenes desde el disco, rende rizado de sprites (partes de texturas), etc. Aunque todo se haga en openGL por debajo estas utilidades nos vendrán muy bien a la hora de crear videojuegos en 2D, si queremos hacer videojuegos en 3D, tendremos que crear nosotros el sistema en openGL para renderizar

Audio module: Este contiene todo lo necesario para cargar sonidos y música desde el disco y reproducirlo tanto de forma simple, o como sonido en 3D gracias al sistema de posicionado que tiene.

Network module: Este modulo nos ayuda a crear aplicaciones multijugador, o a realizar operaciones en red, como descargas de contenido etc. Tiene desde el simple socket (forma mas simple de conexión a red) hasta conexión http y ftp (la misma que usa el navegador para leer las paginas web).

 

Las cosas que faltan en SFML 2.0

Al ser una librería generalista, hay algunas cosas que todavía no tiene o que por ser demasiado especificas de los videojuegos no va a tener nunca y tendremos que encargarnos de suplirlas nosotros, es decir tendremos que ampliar las funcionalidades de SFML 2.0 para hacer mejores juegos.

Lo primero que nos falta es un sistema de archivos, este es una clases o clases que nos permitan listar los archivos de un directorio, crear directorios, movernos entre ellos, borrar archivos y directorios, etc. Lo que normalmente se puede hacer con el explorador de Windows o con los comandos de sistema de DOS/Linux. Para esto o bien exploraremos que librerías libreas hay que nos ayuden o crearemos una nosotros.

También falta un sistema de carga, este nos permite tener una única copia de cada archivo que se lea desde el disco duro. Por ejemplo imaginemos que hacemos un RTS, y tenemos una decena de unidades del mismo tipo cuya representación grafica esta en el archivo tanque.png. Si no tuviéramos un sistema de carga, podríamos acabar con decenas de copias de la misma textura en memoria, saturando nuestro sistema de forma inútil. Un sistema de carga nos garantiza que solo hay una copia de un archivo en memoria, e incluso que solo están los archivos que se necesitan en un momento dado, como por ejemplo solo las texturas para el primer mundo de nuestro juego, pero no para el segundo o el tercero hasta que no sean necesarios. Esto se denomina sistema de carga dinámico.

Otro cosa que falta es la clase para atlas de texturas, los atlas de textura con imagines grandes que contienen muchas imágenes pequeñas dentro, esto sirve para acelerar el dibujado en general. En los sistemas modernos cada vez que dibujas algo de una textura diferente se tienen que realizar una serie de operaciones en la tarjeta grafica que consumen tiempo de ejecución, y en aplicaciones muy criticas es siempre conveniente reducir al máximo el tiempo que consume el cambio de textura, así si tenemos una única textura grande con muchas texturas pequeñas dentro, resulta mocho mas eficiente.

Otra cosa que falta es el control de tileset y spritesheet, sin embargo estos con casos particulares del altas de textura así que no será necesario crear una nueva clase para ellos.

También necesitaremos un sistema de mapas de tiles, para poder representar las mapas que creemos en Tiled, los mapas pueden ser isométricos, diamantes o rectangulares, como los tipos que puede representar Tiled.

También faltan un sistemas de sprites animados, o mas bien un sistema que cargue definiciones de animaciones (basadas en un spritesheet) y otra clase que mantenga los sprites actualizados según el tiempo, es decir anime la imagen del sprite cuando lo necesite.

Bueno, creo que hasta aquí es bastante, seguramente la lista de lo que necesitemos programar aumente, pro no nos preocupemos, SFML ya ha hecho la mayor y pero parte por nosotros.

En los siguiente post hablare de Box2d y de TMXParser. Hasta entonces gracias por vuestra atención y un saludo.