domingo, 19 de junio de 2011

GameEngine: Capitulo 0 . Esquema del game engine

Hola a todos...

Antes que nada, el titulo está bien, pone un 0, y no, no me he vuelto loco (al menos no por esto). Sencillamente este post lo deberia haber hecho al principio, pero ni tenia las ideas al 100% claras ni estaba seguro que fuera una manera buena de empezar el curso..

Siento decepcionaros pero este capítulo no va de código, al menos, no directamente. Va de la organización de un game engine. Aquí expondré todo lo que he explicado hasta el momento de una forma ordenada (y ojalá que también clara). Este post se irá manteniendo a medida que el proyecto avanze a fin de tener siempre un indice de las capacidades y características del LPEngine.


Muchos pensareis que un game engine (o un proyecto de software cualquiera más o menos grande) es "solamente" una immensa cantidad de código que cumple una función, y si, es cierto, hay una parte del game engine que se podria describir así, pero lo que hace que realmente un proyecto de software pueda llevarse a cabo, y posteriormente se pueda usar y mantener es la organización del código. Sin una buena organización de código, NADIE puede acabar un proyecto grande y mucho menos mantenerlo a posteriori.

En la organización de un game engine se han de tener claros dos conceptos:
  1. El game engine va a estar compilado aparte del juego, es decir, se va a suministrar como una libreria estática o dinámica y un conjunto de funciones para comunicar aplicación con motor de juego. Quien tenga un poco de experiencia en programación sabrá que compilar según que códigos puede llevar MUCHO tiempo.
  2. El game engine, por construcción, es un proyecto enorme, con infinidad de funcionalidades diferentes, muchas de ellas que se han de incorporar en versiones posteriores a la inicial, es decir, la mantenibilidad del código y la facilidad para incoporar nuevas capacidades es esencial.

Dicho esto, mi propuesta de estructura es la siguiente:

  1. Core: http://lordpakus.blogspot.com/2011/05/gameengine-capitulo-1.html Es una clase que nos servirá de nexo de comunicación entre la apliación y el game engine. Se encarga de contener el resto de clases del motor. Principalmente contendrá los tres modulos imprescindibles para hacer un videojuego: gráficos, sonido e interacción.
    1. Graphics Manager: http://lordpakus.blogspot.com/2011/05/gameengine-capitulo-2.html . Esta parte del game engine es la que se encarga de pintar por pantalla. Como es comprensible es la que contiene el renderizado de escenas 3D y el pintado de gráficos 2D, cada uno de ellos en clases separadas.Adicionalmente también contiene la gestión de las texturas ya que se usarán en igual medida tanto en la parte de 2D como en la de 3D.
      1. Graphics 2D Manager: http://lordpakus.blogspot.com/2011/06/gameengine-capitulo-9-graphics2dmanager.html Esta clase es la que se encarga de mostrar imagenes y gráficos 2D por pantalla, tales como HUD's, fuentes , sprites. Es por ello que contiene innumerable cantidad de submodulos que le permiten desarrollar su trabajo. Por ahora en el LPEngine solo se ha incluido el módulo de fuentes:
      2. Graphics 3D Manager: http://lordpakus.blogspot.com/2011/06/gameengine-capitulo-3.html Esta clase es la que se encarga de realizar el renderizado 3D de elementos tales como terrenos, modelos, nieblas , efectos ,etc.. Logicamente debe contener innumerables clases de apoyo que le permitan realizar su cometido. Por ahora en el LPEngine solo tenemos un submodulo de modelos 3D.
      3. Texture Manager: http://lordpakus.blogspot.com/2011/06/gameengine-capitulo-6.html Este módulo es el que se encarga de cargar texturas para que los modulos de 2D y 3D puedan pintarlas por pantalla. Dependiendo de la libreria que se use para cargar las imagenes (a menos que se utilice una propia) la estructura interna y el funcionamiento de este modulo puede variar.
    1. Sound Manager: http://lordpakus.blogspot.com/2011/06/gameengine-capitulo-4.html Este módulo se encarga de cargar sonidos y hacerlos sonar. En el LPEngine se usa OpenAL+Alut, pero hay otras librerias como FMOD que tambíen funcionan bien.
    2. Input Manager:http://lordpakus.blogspot.com/2011/06/gameengine-capitulo-10-inputmanager.html Este módulo se encarga de recoger los datos de entrada que suministra el usuario (teclado y ratón principalmente) a fin de que puedan ser interpretados por el juego. En LPEngine se ha usado glut, pero se puede usar la API del sistema operativo para el que se programe o usar librerias de alto nivel como OIS. En función de como se implemente sus características variarán.

Aparte de esta estructura hay clases que no pueden clasificars en ningún grupo por que no pertencen a ninguno y pertenecen a todos a la vez. Un ejemplo de este caso es el filemanager.
      1. File manager: http://lordpakus.blogspot.com/2011/06/hola-todos-bienvenidos-una-nueva.html Esta clase es la que abstrae el sistema de archivos y permite que el manejo de ficheros sea lo más fácil y clara posible para el game engine. Así se reduce tiempo de producción y se aumenta en matenibilidad.

No me queda más que decir que esta estructura no es una orden divina, solamente un ejemplo de lo que he podido aprender al desarrollar mi game engine. Si alguien considera que estoy equivocado o que se puede mejorar le insto a que me lo comente para que podemos seguir mejorando el esquema.

Espero que os ayude a tener las ideas más claras sobre la creación de game engines.

Nos vemos.

LordPakusBlog

EDIT: Si quereis seguir el desarrollo del proyecto podeis ver el canal de youtube y la zona de descargas donde hay ejemplos , código y ejecutables.

1 comentario :

Related Posts Plugin for WordPress, Blogger...