Entonces ya tenía la forja, no obstante aún no era el momento de lanzarse a codificar como un poseso, quizás este ha sido uno de los primeros proyectos en los que me he embarcado en el que me he tomado un tiempo considerable para planificar y diseñar el sistema. No es que mi proceso de desarrollo haya sido sacado directamente de un estándar de Ingeniería del Software pero al menos no ha sido un completo desastre.
Según pude aprender en el libro de SDL que mencioné en el artículo anterior eran necesarias o al menos muy convenientes una serie de clases que abstrajeran lo tediosa que es la librería y aprovecharan la orientación a objetos. Clases que manejaran recursos como imágenes, efectos de sonido, la BSO, texto o la entrada a través del teclado. El resto del sistema se apoyaría en esas clases para funcionar correctamente. He de decir que me apoyé bastante en el modelo que ofrece dicho libro y podéis ver el resultado en la forja del proyecto.
No obstante el modelo que propone el libro tiene muchas cosas que no me gustaban. Utiliza una clase Galería que gestionaba todos los recursos, los cacheaba para no tener que cargar dos veces en memoria el mismo recurso aunque se estuviera utilizando para varias cosas a la vez. Simplemente le pedías un recurso utilizando una clave y a través de un diccionario te devolvía un puntero a dicho recurso. El problema residía en que los recursos que se iban a utilizar no se leían desde fichero sino que estaban en el propio código, además la clase se utilizaba desde una clase superior por lo que no era fácilmente accesible.
La idea era buena pero la ejecución no era la mejor, la solución llegó cuando leí unos artículos del Game Programming Gems número 1. El primero de esos artículos hablaba de la importancia de dejar todos los parámetros de los campos externos a la programación en ficheros. De esta manera cualquier diseñador podría modificar parámetros como velocidad o ataque de un personaje o recursos gráficos sin tener que recompilar el código y sin necesidad de tener conocimientos de programación. Se abrió una vía que tuve que investigar, un sistema para cargar información desde ficheros que no fueran planos, que tuvieran una estructura y fueran cómodos de manejar.
El otro artículo hablaba del patrón de diseño Singleton el cual era recomendable utilizar cuando necesitabas una clase que fuera accesible desde muchos sitios pero de la que únicamente necesitas una instancia. Era exactamente lo que necesitaba para mi “Galeria”, la clase que cachearía todos los recursos multimedia del juego. Podría acceder a ella libremente desde cualquier sitio y no tendría que estar malgastando memoria por cada sitio que la usara.
Por ahora tenía claro que necesitaba clases que gestionaran recursos multimedia (audio, texto, imágenes) y otra que los cacheara y pusiera a disposición del resto del sistema. Todo el diseño debía permanecer todo lo alejado del código que fuera posible por lo que un sistema para leer y escribir en ficheros de manera estructurada estaría de lujo. Las clases de más bajo nivel estaban más o menos claras, poco a poco fui definiendo papel y lápiz en mano detalladamente qué quería que hiciera cada una de ellas. Finalmente me quedaron las siguientes clases en las cuales podéis hacer click para ver su documentación:
De la clase Parser hablaré más adelante ya que tiene mucha importancia. Es la encargada de leer y escribir en ficheros XML, el formato más idóneo que encontré para las necesidades que tenía. Se trata de un wrapper de la librería TinyXML y pude dar con esta solución gracias a la ayuda de un compañero y participante también en el IV CUSL, su proyecto es IdiginBPEL.
Es cierto que se me ha pedido que coloque diagramas de clases para tener una idea más global del sistema y lo haré próximamente, sé que ayudaría mucho a su comprensión.
Escrito por David Saltares 
! Al fin y al cabo esta es una de las metas del CUSL, aprender cosas, conocer gente y hacer comunidad.
