La nueva forja es:

https://forja.rediris.es/projects/cusl4-afp/

Espero que cuando terminen los exámenes pueda darle un pequeño impulso al juego, algo que, sin duda, necesita urgentemente.

Por fin vuelvo a retomar el blog del proyecto tras un considerable parón, esta vez no voy a hablar de temas demasiado técnicos, esa es una vía que retomaré en futuros artículos. A lo largo de este texto comentaré un poco la experiencia que he tenido hasta ahora en el ámbito del diseño gráfico si le podemos llamar de esta manera.

Ante todo decir que no soy ningún experto en la materia, es más, he tenido que hacer los gráficos del juego por obligación, no porque me desagrade sino porque no tenía a nadie más disponible. De pequeño siempre he hecho dibujos y pamplinas en papel pero nunca me he metido a manejar a fondo un programa de dibujo y gracias al desarrollo de Air Force Pilot he aprendido lo básico.

Estaba claro que necesitaba crear varios diseños de aviones por lo que necesitaba referencias y algo de inspiración. ¿Qué mejor que los aviones reales? Busqué algunos aviones de combate por internet e hice algunos bocetos con los que cree el protagonista de la aventura, un caza basado en varios modelos y en ninguno al mismo tiempo. Lo realmente interesante vino con el II Festival Aéreo que tuvo lugar en mi ciudad, Cádiz el día 13 de septiembre. Varios modelos de aviones de combate y acrobáticos se exhibieron en un espectacular ejercicio de habilidad y me sirvieron de una gran fuente de inspiración. De este festival saqué los modelos de varios enemigos: el Harrier matador, la Patrulla Águila y el Eurofighter Typhoon. Esto demuestra la utilidad de beber de la realidad para crear un mundo alternativo y, aunque los resultados no son en absoluto excepcionales, tampoco son ninguna abominación.

Los escenarios también eran importantes, quería utilizar un método simple por lo que opté por escenarios basados en tiles. Un tile es un cuadrado que se repite para ser aprovechado, de esta manera tendría tiles de bosque, hierba, arena, mar y las correspondientes transiciones entre ellos. Muchos recordaréis el clásico RPG Maker por lo que sabréis de lo que hablo. Mi escenarios están basados en varias capas para superponer elementos (terreno, objetos, personajes y nubes) aunque hablaré en profundidad del tema en otro artículo.

No tenía ni idea de hacer tiles ni de pixel art por lo que me dispuse a tomar ideas de otros tileset y de varios tutoriales. Tras estar algún tiempo en ello y echar varias tardes haciendo pamplinas con The Gimp me salió el tileset básico que podéis ver.

Poco a poco iba teniendo los cimientos del motor de juego y algún que otro diseño para ir tirando. En próximos artículos trataré los temas de: composición del escenario, clase Parser para leer XML etc.

Hoy toca un pequeño interludio en el que dejaré a un lado Air Force Pilot para comentar la reunión que tuvo lugar ayer en la UCA. Los participantes del IV CUSL que pudimos acudimos a la facultad a conocernos nosotros y nuestros proyectos.

Estuvo genial ya que recibimos consejos de ganadores de años anteriores (XMLEye, Libgann y AVBot) y pude ver lo buenos que eran algunos proyectos presentados en nuestra universidad, ¡que tengan cuidado participantes de otras ciudades porque aquí hay nivel ! Al fin y al cabo esta es una de las metas del CUSL, aprender cosas, conocer gente y hacer comunidad.

Una buena experiencia que espero, se repita, no dentro de demasiado tiempo.

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:

• Fuente
• Imagen
• Musica
• Sonido
• Galería
• Parser

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.

Una vez tuve claro lo que quería hacer acudí a pedir una forja a Red Iris (mucho antes de pensar siquiera en el CUSL) y, aunque tardan un par de días en concederla me ha gustado mucho lo que ofrece, incluso más que otros servicios similares como Google Code. Las estadísticas, el reducido número de proyectos y su organización, la claridad, la rapidez y el buen posicionamiento en buscadores dicen mucho de Red Iris. Supongo que a más de uno le habrá dado problemas pero hablo desde mi experiencia personal.

Justo cuando la idea de crear Air Force Pilot comenzaba a fraguarse en mi mente asistí a un taller en mi Universidad sobre el trabajo en una forja de código abierto, el uso de Subversion y cómo documentar el código con Doxygen. Finalmente todos los consejos y conocimientos recibidos han demostrado resultar increíblemente útiles.

Me ha permitido no tener demasiados problemas con la forja e ir documentando todo lo que hacía conforme lo iba creando. De hecho, una de las cosas que me está aportando el desarrollo de este pequeño juego es darme cuenta de los beneficios que aporta usar una forja y la importancia de documentar el código. Aquellos que, hasta ahora, le han echado un vistazo a la documentación (la cual se obtiene al descargar la revisión del proyecto desde la forja) me han comentado que se entiende muy bien y que queda todo muy claro.

Este es uno de mis objetivos, la claridad, comenzar con la programación de videojuegos es complicado, es como estamparse con un muro y si en algún momento a alguien le sirve mi código y su documentación quedaré ampliamente satisfecho.

Como comencé con la idea y el desarrollo de Air Force Pilot a comienzos de verano ya llevo algunas cosas adelantadas, me gustaría relatar la experiencia completa por lo que las primeras entradas de este blog serán a modo flashback.

Mi experiencia con los videojuegos es peligrosamente reducida y comenzó el primer año de Ingeniería Técnica en Informática de Gestión con un curso de iniciación a la programación en Nintendo DS al que asistí. En dicho taller se nos enseñaron los conceptos básicos de la programación de videojuegos y se mostró una pequeña introducción al uso de unas librerías gratuitas para desarrollar en dicha consola, las Palibs. No son nada del otro mundo y sus posibilidades distan mucho de otras librerías pero es muy sencilla de usar y servía para sumergirse.

Conforme fui avanzando en la carrera traté de aprender un poco el uso de SDL, una librería de código abierto para C y C++ (aunque existen wrappers para otros lenguajes como Python y pygame). Los comienzos fueron duros pero finalmente decidí leer una especie de guía didáctica que formaba parte de un proyecto fin de carrera de un estudiante de mi Universidad. Es una guía extensa pero que recomiendo a todo el mundo ya que no sólo sirve para conocer a fondo SDL sino que te introduce en el diseño y programación de videojuegos de una manera progresiva y bastante decente. Por si fuera poco el contenido está resumido en una excelente wiki.

En el momento que finalicé de leer dicha guía fue cuando surgió la idea de Air Force Pilot. Quería poner a prueba lo aprendido y seguir evolucionando por lo que me propuse crear un juego pequeño, sin demasiadas pretensiones. Debía ser algo arcade, directo, sin complicaciones y recordé aquellos juegos de consolas arcaicas en los que te ponías a los mandos de un avión y machacando botones tratabas de sobrevivir (sin demasiado éxito en mi caso) en misiones imposibles.

La cosa fue creciendo y lo que empezó como una tontería ha adquirido algo de forma, lo cual es realmente satisfactorio pero eso lo iré desgranando en posteriores artículos que este ya cuenta con una buena cantidad de palabras.

Bienvenidos al blog de Air Force Pilot, mi proyecto para el IV Concurso Universitario de Software Libre. Hace poco que he sido aceptado y me he dispuesto a crear este espacio en el que publicaré el proceso de desarrollo, apreciaciones, dificultades y soluciones de esta pequeña empresa.

Air Force Pilot es un videojuego arcade 2D para PC multiplataforma en el que controlamos a un avión a lo largo de varias misiones. La mecánica es sencilla, tenemos una visión cenital del entorno y debemos disparar a aquello cuanto se mueva. Trata de hacer honor a los clásicos del género que han tenido enganchados a más de uno hace más de una década. Está programado en C++ y hace uso de la librería gráfica SDL y sus auxiliares (mixer y ttf).

No me presento a este concurso con ansias de ganar, de hecho, Air Force Pilot no es más que una idea que surgió a principios de verano, algo pequeño para aprender lo básico de programación de videojuegos. A día de hoy ya es jugable pero necesita retoques y sobre todo mucho contenido: niveles, enemigos adicionales, ítems etc.

A lo largo de la breve vida de mi proyecto le he hecho un seguimiento en mi blog personal, así mismo podéis acceder al sitio de Air Force Pilot en la Forja Red Iris. Desde allí podéis obtener la versión de desarrollo a través del sistema de gestión de versiones Subversion.