GDE: Estructura del proyecto

Comenzamos a diseñar la estructura de nuestro proyecto: el Game Dev Engine, a partir de ahora me referiré a él como GDE para simplificar. En este primer artículo veremos la estructura general del proyecto así como las directrices que vamos a seguir en e código.

Objetivos del proyecto

Antes que nada quiero aclarar una vez más que esto es un proyecto de aprendizaje, no esperamos encontrar en nuestro Engine una revolución tecnológica ni las más avanzadas features de los engines actuales. Del mismo modo haremos las cosas de una manera sencilla siempre que se pueda favoreciendo lo simple sobre otras formas más complejas que podamos entender que son mejores.

Ya hemos creado los objetivos de la Milestone 0.1 que son los que comentamos en el artículo anterior.

En esta primera versión queremos algo funcional y simple por lo que nuestros objetivos son los siguientes.

• Poder crear un juego de manera sencilla con un arranque y parada de aplicación eficiente.

• Poder gestionar eficientemente los recursos evitando cargar recursos duplicados y liberándolos cuando no son necesarios.

• Gestionar escenas/estados de manera fácil para cambiar entre pantallas y organizar correctamente el código de nuestra aplicación.

Los objetivos que proponemos para esta primera versión son sencillos y asumibles con no muchas clases tendremos algo funcional que mejorará la creación de videojuegos con C++ y SFML.

A diferencia de otros engines nosotros no vamos a encapsular SFML debajo de nuestro engine, sino que lo vamos a complementar. Lo hacemos así por dos cosas principalmente.

Si encapsulamos el código de SFML debemos crear clases para configurar y tener acceso a modificar todo lo que aporta SFML. Del mismo si lo hacemos como complemento de SFML el usuario de nuestro Engine podrá optar por hacer las cosas a través del engine o si en un momento dado lo necesita, hacer las cosas directamente interactuando con SFML.

Estructura del proyecto

Nuestro engine al ser una colección de clases para facilitar la creación de una aplicación final está claro que debe ser una biblioteca (librerías) que usemos luego en una aplicación.

Como esto es un proyecto de aprendizaje y con el fin de tener un sitio donde probar nuestro engine, además de el Engine tendremos un proyecto de un ejecutable que hace uso de la librería.

Aprovechándonos de que los IDEs de hoy en día todos gestionan Frameworks donde podemos tener varios proyectos, tendremos un Framework con un proyecto de librería llamado GDE que será nuestro Engine y tendremos otro que será un ejecutable llamado Test que hará uso de GDE para las diferentes pruebas.

Librerías estáticas o dinámicas

Esto es una cuestión que deberíamos decidir, si nuestra biblioteca será estática o dinámica.

Para el que no maneje estos conceptos a grandes rasgos las bibliotecas estáticas se integran en el ejecutable después de la compilación haciendo que el ejecutable sea algo más grande, pero que no necesitemos archivos externos. Son las llamadas .lib para entornos Windows y las llamadas .a para Unix.

Por otro lado las dinámicas son aquellas que solo se dicen al ejecutable donde se encuentran, pero no se integran en el ejecutable, sino que quedan en un archivo independiente que se carga bajo demanda. Las llamadas .dll en Windows y .so en Unix.

La ventaja de las estáticas es que necesitamos distribuir menos archivos con nuestro proyecto final, solamente el ejecutable y los recursos necesarios, pero si, por ejemplo, hacemos una modificación en la biblioteca o en el ejecutable y necesitamos hacer una actualización ya habrá que descargar todo de nuevo, sin embargo, si usamos bibliotecas dinámicas solo debemos distribuir en la actualización aquello que cambia sea la biblioteca o el ejecutable.

La verdad es que el uso de uno u otro tipo dependerá en gran medida del tipo de proyecto que realicemos. Como SFML viene preparado para las dos formas de trabajo nosotros haremos lo mismo y prepararemos nuestro proyecto para que sea compilable como biblioteca estática y dinámica.

Puede que en un principio solo tengamos un formato u otro según la facilidad del Sistema Operativo y el IDE. Por ejemplo, en linux es mucho más fácil trabajar con las bibliotecas dinámicas una vez instaladas en el sistema y en Windows con Visual Studio suele ser más sencillo trabajar con librerías estáticas, pero como ya digo al final tendremos el proyecto para todos los sistemas en ambas versiones.

IDEs, Sistemas Operativos y soporte multiplataforma

Como hemos dicho la idea es tener un proyecto que sea multiplataforma que abarque Windows, Linux y OSX. Lo mismo con las arquitectura debe ser compatible tanto con 32 bits (x86) como con 64 bits (x64).

En cuanto al IDE o gestión de proyecto que vamos a usar daremos soporte a varios. Se ha planteado el uso de Cmake para tener un proyecto que cree soluciones para algunos IDEs y genere un makefile en entornos Unix.

Mi idea es no cerrar ninguna puerta y pedir ayuda a la comunidad que se genere entorno al proyecto. Es evidente que que una persona sola no puede tener acceso a todos los sistemas, arquitecturas e IDEs que hay y sus posibles combinaciones. Es por eso que se pedirá encarecidamente la contribución de la comunidad para mantener soluciones y proyectos.

Yo por mi parte daré soporte y mantendré actualizado proyectos para Codelite en Windows y Linux, así como de Visual Studio 2013 para Windows. Intentaré también dar soporte a OSX por medio de Codelite o XCode.

Si alguien quiere aportar y se compromete a mantener el proyecto para otros entornos, los incluiremos. Ye sea Cmake, Qmake, QTCreator, etc.

Todos los tipos de soluciones que creemos irán en una carpeta llamada builds ordenadas por entorno y ahí deben estar todos los archivos de configuración de un determinado IDE o Cmake.

Estructura de directorios

La estructura de directorios del proyecto será la siguiente:

|- builds/
   | - codelite/
   | - vc2013/
   | - .../ (otros)
|- lib/
   | - GDE-d.lib / .dll / .a / .so
   | - GDE.lib / .dll / .a / .so
|- bin/
   | - Test (ejecutable)
   | - Test-d (ejecutable)
   | - Data/
   | - window.cfg
|- src/
   | - GDE/
       | - Core/
           | - App.cpp
           | - *.cpp (Todos los cpp)
   | - Test/
       | - main.cpp
       | - SceneMain.cpp
       | - ScenaMain.hpp
       | - ...
| - include/
   | - GDE/
       | - config.hpp
       | - Core.hpp
       | - Core/
           | - App.hpp
           | - *.hpp (Todos los hpp)
| - extlibs/
    | - headers/
        | SFML/ (includes)
    | - libs-vc2012
    | - libs-mingw
    | - libs-xcode
    | - ...
| - doc/ (documentación generada con doxygen)
| - README
| - LICENSE

Como vemos el código fuente de la biblioteca irá a la carpeta src/GDE/Core y sus archivos de cabecera a include/GDE/Core. El uso de la carpeta Core es con vistas al futuro y la modularidad, ya que lo que haremos será crear un módulo Core principal, pero luego será posible añadir nuevos módulos al proyecto para mejorarlo y dar otras funcionalidades.

Las bibliotecas generada irán a la carpeta lib y los ejecutables a la carpeta bin. Esta será la carpeta donde se cree nuestro proyecto de prueba por tanto aquí meteremos recursos y demás archivos necesarios de la aplicación Test en sí.

Es importante ver que tanto los archivos de cabecera como los de código van en la carpeta src/Test estos no los separamos pues una vez compilado no necesitamos los archivos de cabecera como sucede en la biblioteca.

Las librerías auxiliares que necesitemos (en un principio SFML) irán a la carpeta extlibs donde por un lado tendremos los heades y por otro los libs-xxx necesarios de cada sistema o IDE.

En la carpeta builds irán todos los archivos de configuración de los diferentes entornos. En la carpeta doc se generará la documentación del proyecto.

Idioma y documentación

Se ha sugerido que hagamos el proyecto, por ser software libre, completamente en inglés. Como es un proyecto de aprendizaje de Genbeta Dev y la misión es enseñar y tener un ejemplo práctico para los diferentes artículos, creo que lo mejor es tener la documentación del proyecto en español. Por documentación nos referimos a: artículos sobre el proyecto en este Blog, Artículos complementarios en la Wiki del proyecto, Issues en Github, Comentarios y documentación en el código fuente.

Por otra parte si me gustaría proponer que los nombres de clases, variables y demás elementos del código si estén en inglés. Principalmente porque los programadores ya nos manejamos mejor con estos términos que sus equivalente en español y es más fácil conseguir nombres cortos y descriptivos en inglés que en español. Algunos términos incluso no tienen una traducción en español.

En cuanto a la documentación del código usaremos Doxygen, para tener la API documentada y poder entender el código. Para ello seguiremos una guía de estilo de documentación que pronto estará disponible en la wiki del proyecto.

Guía de estilo del código

No vamos a elaborar una guía de estilo completa, pero si a establecer unas directrices:

• Las llaves van en líneas independiente tanto cierre como apertura

• Se hace uso de camelCase para el nombrado de elementos

• Las clases comienzan en mayúsculas y los métodos en minúsculas

• Las variables de clase llevan el prefijo m. mVariableNueva

• using namespace esta totalmente prohibido

Si es necesario iremos elaborando una guía de estilo en la wiki añadiendo nuevas cosas a tener en cuenta.

Espacio de nombre GDE

Todo los elementos de nuestra biblioteca están dentro del espacio de nombre (namespace) GDE. Esto nos permitirá saber que elementos pertenecen a la biblioteca fácilmente y evitar posibles conflictos de nombres con otras bibliotecas.

Conclusión

Esta será la estructura general del proyecto, en los próximos días estaremos subiendo al repositorio las configuraciones de los diferentes entornos, sería bueno ir viendo quien se ofrece a configurar el proyecto para determinados entornos.

Estamos usando la sección issues para comunicarnos, recordad usar los tags necesarios para un orden adecuado.

Más información | Repositorio Github En Genbeta Dev | GDE