La Rosquillera Framework es un framework para hacer videojuegos con SDL2 que tiene como objetivo que el usuario pueda hacer juegos como rosquillas (o sea muchos, muy rápido y sin romperse la cabeza).
Crear un videojuego no es sólo cuestión de pintar imágenes y capturar la entrada de teclado. Se necesita hacer uso de muchos sistemas adicionales que no proporciona esta librería. Por eso, la Rosquillera Framework provee de un juego de herramientas que, además de permitir al usuario abstraerse del uso de SDL2, ayuda en esas otras muchas tareas.
En 2015 comencé el desarrollo de un motor de videojuegos al que dí el nombre de “La Rosquillera”. Poco después, decidí que sería un framework por lo que decidí renombrarlo a “La Rosquillera Framework”.
En 2017, llevando un año cursando la carrera de informática, decidí que este proyecto acarreaba muchos problemas de base que no podían arreglarse sin poner patas arriba todo el framework; por lo que decidí volver a implementarlo desde cero.
Esta nueva versión pasó a denominarse “La Rosquillera Framework - Reforged”.
El diseño de este framework busca facilitar al desarrollador muchas tareas engorrosas; como la carga y descarga de assets, la gestión de procesos, etc… Y, como en cualquier otro framework, es importante conocer el diseño del mismo para poder aprovechar al máximo sus capacidades.
Por eso, en esta sección explica los conceptos generales de diseño de La Rosquillera Framework - Reforged.
Todas las herramientas para crear videojuegos proveen de un pipeline que organiza la ejecución de los procesos internos de la aplicación. Cuanto más grande y sofisticada es la herramienta, mayor y más complejo es su pipeline. Este framework no es tan grande ni sofisticado como otras soluciones; no es un motor de videojuegos, tan sólo una capa sobre las librerías base sobre las que crear un motor y, por tanto, el pipeline es más pequeño.
En este framework se proporciona una clase base (RF_Process) que será la clase que se integre con el pipeline, buscando que todas las clases que se desee integrar en él hereden de ella.
El funcionamiento del pipeline es el siguiente:
Para poder llevar a cabo su trabajo, este framework dispone de toda una batería de clases y espacios de nombres que es importante conocer.
Nombre | Tipo | Descripción |
---|---|---|
RF_Asset | Clase | Clase de la que heredan todas las clases para gestionar recursos con el gestor de assets |
RF_AssetList | Clase | Clase que gestiona listas de assets |
RF_AssetManager | Clase | Clase singleton que gestiona todos los assets de la aplicación |
RF_AudioClip | Clase | Asset de música |
RF_Collision | Namespace | Espacio de nombres que contiene las funciones necesarias para calcular las colisiones entre procesos |
RF_DebugCommand | Clase | Estructura para crear comandos de debug |
RF_DebugConsoleListener | Clase | Clase singleton que gestiona el debug |
RF_Engine | Clase | Clase que controla el bucle principal de ejecución |
RF_Font | Clase | Asset de fuente tipográfica |
RF_FXClip | Clase | Asset de efecto sonoro |
RF_Gfx2D | Clase | Asset de imagen 2D |
RF_Input | Clase | Clase singleton que gestiona la entrada por teclado, ratón y mando |
RF_Layer | Clase | Clase para realizar tareas de canvas |
RF_Primitive | Clase | Espacio de nombres que contiene las funciones primitivas de pintado de píxeles |
RF_Process | Clase | Clase base que debe heredar toda clase que quiera integrarse en el pipeline |
RF_SoundManager | Clase | Clase singleton que gestiona el sistema de sonido |
RF_Structs | Namespace | Espacio de nombres que contiene todas las estructuras de datos básicas del framework así como todos los enumerados y definiciones básicas |
RF_TaskManager | Clase | Clase singleton que gestiona el pipeline |
RF_TextManager | Clase | Clase singleton que gestiona la escritura de textos |
RF_Time | Clase | Clase para el control del tiempo |
RF_Window | Clase | Clase que contiene la lógica necesaria para hacer uso de las ventanas |