Diario de desarrollo (SeventhEngine): el tiempo apremia

41G0l2eBPNL

A partir de esta misma semana empiezo a darle caña de nuevo al desarrollo de mi motor gráfico. Tras 2 semanas de viaje por Europa y otra de “descanso” toca de nuevo ponerse a trabajar (por supuesto), pero también a estudiar (ya ha dado comienzo el curso en la UNED), y por supuesto, a programar. La primera tarea que surge es reorganizar todo el trabajo en torno a SeventhEngine. Dejé el proyecto a mediados de septiembre con buena parte de los subsistemas definidos, y montones de hojas con bocetos y diseños de los sistemas nuevos a desarrollar. Por ahora lo más importante es acabar el DisplayEngine, es decir, el subsistema que controla todo lo relacionado con los gráficos (texturas, animaciones, cámaras, efectos, etc.). Además, como ya comenté en entradas anteriores, es vital dejar claras las relaciones con los demás subsistemas, puesto que de aquí tiran todos los demás.

El objetivo antes de año nuevo es crear un juego de prueba, que será el clásico Pong, más o menos funcional, que mostrará más o menos todas las partes del motor, a saber:

  • Gráficos: carga dinámica de texturas con gestor de recursos; implementación sobre el doble buffer de SDL.
  • Cámaras: diseño e implementación de las 2 cámaras genéricas; estática, y que siga a una entidad en concreto (apunte: hay que propagar la posición a todos los gráficos a mostrar cuando una cámara dinámica se mueve)
  • Entidades: implementación del modelo básico de entidad, que será ampliable y genérico. Habrá un uso intensivo de patrones de diseño (puesto que las entidades son un quebradero de cabeza, ya que se comunican con prácticamente todos los subsistemas del motor) y de herencia (incluida la peligrosa múltiple herencia).
  • Sonidos: música de un juego y efectos sonoros, autoexplicativo.
  • Eventos: otra parte esencial, clase genérica para soportar teclados; buena respuesta a la entrada del usuario; implementación también de una clase para detectar combinaciones de teclas.
  • Motor de IA: esto en principio se dejará como trabajo para el programador del videojuego, puesto que tengo mis dudas respecto a cómo habría que implementar las herramientas básicas de una IA (decision trees, state machines, pathfinding, etc.). No obstante, el motor si que debería de disponer de la posbilidad de definir respuestas a los eventos básicos.
  • Motor físico: esto es más una idea que otra cosa, pero es interesante disponer de un mini motor físico para gráficos en 2D, que controle cosas como aceleraciones cuando hay caidas, cálculo de fuerzas básicas (¿alguien dijo un coche derrapando?), etc. Lo dejo por ahora como una idea.
  • Niveles de juegos y estados: implementar el gameplay en sí, genérico y ampliable. Cuando digo gameplay, me refiero a las transiciones que hay un pantalla a otra, de un nivel a otro, etc. El programador podrá definir en primer lugar niveles de juego, y dentro de cada nivel una serie de estados, que irá enlazando según ocurran los eventos programados. Esto hará un uso intensivo de contenedores y de memoria dinámica.
  • Mapas y sprites: el elemento esencial, gracias a que tengo un editor de mapas ya hecho (Tiled: http://www.mapeditor.org/), puedo usar el formato que exporta para el motor gráfico. Tengo como objetivo programar clases básicas de compilación de mapas (parsear un XML cada vez tarda demasiado), y además permitir que el usuario especifique sus propias clases de mapas y que se integren en el motor. Tengo una idea básica de como haré esto, pero por ahora lo dejaré en el tintero.
  • Texto: gracias a la librería SDL_ttf podré permitir que el usuario imprima texto en su videojuego.
  • Debug & profiling: por último, voy a desarrollar herramientas basiquísimas de debugging y profiling, simplemente para ayudar al programador en tiempo de ejecución por un lado (la mítica consola que todos los motores llevan); y por otro lado a la hora de compilar y obtener mensajes por pantalla (usando asserts, traces y demás parafernalias).

Y seguro que me dejo alguna cosa en el tintero. Volveré para editar la entrada si me acuerdo.

tiled-qt-screenshot-3

Documentación

Otra cosa importantísima a tener en cuenta es la documentación de todo esto. Por ahora sólo me estoy dedicando a comentar el código fuente. A lo largo de las distintas releases generaré los respectivos documentos html del javadoc, e intentaré ampliarlos en la medida de lo posible. Sólo cuando tenga en motor en fase beta empezaré a hacer una documentación como dios manda (con su buscador y sus ejemplos y demás). Además, estoy haciendo multitud de esquemas y explicaciones “a boli” que espero poder usar en el futuro para esta tarea. He pensado que también sería interesante publicar aquí escaneos de estos bocetos, por aquello de que es muy romántico, pero mejor voy a esperar unos 5 o 10 años :)

Eso es todo por hoy. Estoy a la espera de que me den de alta en la Forja de RedIris para poder subir la primera base de código y empezar a hacer commits. Aún no he decidido si conservaré una copia en Github, lo cual seguramente será así (aunque tengo serías dudas de que Github y SVN se lleven bien en el mismo directorio; creo que tocará hacer un script para hacer svn export y luego push)

PD: No quería despedirme sin recordar a Dennis Ritchie, co-creador del lenguaje de programación C y UNIX, que ha fallecido recientemente a la edad de 70 años. Nos queda su extenso legado como padre de sistemas muy usados hoy en día; la mejor manera de honrarle es seguir usándolos y colaborando para hacer de la comunidad un lugar mejor.

Post Navigation