Release de Space Penguin

Publicado 2 julio, 2010 por rabbitbodom
Categorías: Entregas

Tags: , , , , , , ,

¡Hola a todos!

Después de mucho sudar y poco dormir, estamos muy orgullosos de presentaros la primera release estable de Space Penguin. Esta versión, la 0.1, se publica únicamente para sistemas operativos GNU/Linux (de momento), y contiene dos niveles completos.

Tenemos enemigos, tenemos colisiones, y tenemos items. Le hemos ajustado la dificultad para que, si bien no sea extremadamente difícil, sí suponga un reto a los jugadores habituales del género Run&Gun.

Sin más preámbulos, aquí dejamos el enlace a Space Penguin v0.1

Esperamos que lo probéis y lo disfrutéis, al menos tanto, como hemos disfrutado nosotros desarrollándolo.

El curso acaba aquí, pero puede que el proyecto avance. Si alguien quiere crear sus propios niveles, no tiene más que seguir el manual que publicaremos próximamente.

No queda más que agradecer a todos los compañeros su ayuda, su apoyo, y las charlas de pasillo, cómo no, que más de una buena idea ha salido de ahí. También queremos agradecer a nuestro profesor, Manuel Palomo Duarte, la oportunidad que nos ha brindado con esta asignatura de poder realizar el sueño de todo niño… hacer su propio videojuego. ¡Que éste sea el primer paso de un largo camino, camaradas!

Nada más, cambio y corto. Sed felices 😉

Informe rápido de situación

Publicado 28 junio, 2010 por rabbitbodom
Categorías: General

Tags: , , , ,

¡Buenas a todos los lectores!

Tal y como reza el título, tenemos la presentación final de Space Penguin a tiro de piedra (concretamente, cuatro días), y antes de preparar la documentación final para el gran día, vamos a echar un vistazo rápido sobre las tareas por hacer:

Prioridad alta:

  1. Enemigos (aún no los tenemos, nuestro protagonista se pasea por el escenario pegando tiros a la nada)
  2. Colisiones (porque si los enemigos no se mueren, y no hacen pupita… pues como que la cosa pierde gracia, ¿no?)

Prioridad baja u opcional:

  1. Pantalla de historia antes del inicio de cada nivel.
  2. Contador de puntos
  3. Modificar el sistema gráfico para que acepte cualquier resolución, no sólo las actuales 800×600 (panoramico=”0″) o 1060×600 (panoramico=”1″). Este paso es necesario para realizar posibles ports a PSP (¡gracias David por ese magnífico tutorial!) o a Wii.
  4. Cambiar las canciones de los dos niveles actuales por otras con licencia libre (las que están ahora mismo, insisto, son provisionales). – Hecho.
  5. Terminar el segundo nivel, y añadir alguno más (que si no, nos quedamos en “demo”)

En resumen, que muy pronto estaremos dispuestos a presentar oficialmente Space Penguin. (disponible en todas las pantallas a partir del 2 de julio de 2010).

Alpha 2 del pingüino espacial

Publicado 21 junio, 2010 por rabbitbodom
Categorías: General

Tags: , , , , , , , , , ,

Buenas a todos. Hoy os presentamos la segunda alpha oficial del Space Penguin.

Estamos muy orgullosos de presentar una versión mucho más avanzada del proyecto, bastante cercana a la conclusión, ya que nos gustaría dejar el videojuego más o menos cerrado al finalizar el curso.

La lista de cambios importantes de esta segunda compilación es la siguiente:

  • Menú principal definitivo, a falta de un fondo más currado (de momento, seguimos con el provisional)
  • Juego configurable a través de un archivo XML, que permite modificar algunos parámetros de ejecución como la pantalla completa, el modo de pantalla (4:3 o 16:9) o los fps.
  • Banda sonora (de momento, las pistas de los niveles son provisionales, la del menú es definitiva), y efectos de sonido.
  • Disparos.  ¡Por fin podemos afirmar que estamos haciendo un run and GUN!
  • Arreglados varios bugs relacionados con la gestión de memoria. Confirmamos que ahora no peligra la estabilidad de tu sistema si dejas en ejecución Space Penguin.
  • Por otra parte, confirmamos también los requisitos de memoria y procesador: 32 MB de memoria principal, y un procesador de más de 500 Mhz.

Enlace (sólo versión Gnu/Linux):   Space Penguin – Alpha 2

Detallamos a continuación la, cada vez menor, lista de cosas por hacer:

  • Implementaciones críticas:
  1. Enemigos
  2. Colisiones (después de los enemigos)
  3. Documentación de la entrega final (especialmente, manual de usuario, y manual de creación de niveles)
  • Cambios menores:
  1. Fondo de pantalla definitivo para el menú principal
  2. Segundo nivel (imagen de fondo y plataformas)
  3. Menú de pausa
  4. Reparar un bug conocido en el rectángulo de colisiones del jugador, relacionado con la orientación del personaje
  5. Reparar un bug relacionado con las balas: se deben eliminar de la memoria cuando salen de la pantalla
  6. Mostrar el código de acceso en la pantalla de inicio de nivel
  7. Cambiar algún sonido por otro más adecuado (opcional)
  8. Mostrar pantallas de historia antes del comienzo de cada nivel (opcional)

De momento, y a falta de continuar sacando cosas por pulir (que siempre las habrá, lo reconocemos), esperamos que esta segunda versión de prueba suponga el empujón que le iba haciendo falta al proyecto.

Un saludo a todos, y permaneced atentos.

Códigos de nivel y cadencia de disparos

Publicado 10 junio, 2010 por rabbitbodom
Categorías: General

Tags: , , , , , , ,

Informar que, a día de hoy, tenemos el menú principal totalmente operativo, con el inicio de partida desde el primer nivel, y con el acceso a niveles posteriores mediante códigos de nivel de cuatro dígitos.

Por otro lado, se han regularizado las pulsaciones de teclas en el menú, de tal manera que sólo se reconoce una pulsación cada vez, en lugar de una por cada frame si se deja la tecla correspondiente pulsada.

Respecto a los disparos, hemos introducido una limitación parecida: Cuando se tenga equipada la pistola, sólo se disparará una bala cada 1,5 segundos, pero cuando consigamos munición, con el fusil dispararemos 3 veces por segundo.

Tareas por hacer:

  • Fondo de pantalla decente para el menú de la aplicación
  • Abstraer el menú y el gestor de niveles en una única clase Aplicación, que gestione las transiciones entre niveles (vamos, que cuando acabes la primera fase, empiece la segunda.)
  • Crear el segundo nivel (y si da tiempo, más)
  • Añadir enemigos
  • Añadir disparos
  • Añadir efectos de sonido y música (probablemente, el siguiente paso)

Ya estamos cerquita de acabar el proyecto Space Penguin… Seguiremos echando horas, y por supuesto, informando por aquí. Cambio y corto.

Menú Principal y abstracción

Publicado 7 junio, 2010 por rabbitbodom
Categorías: General

Tags: , , , , , , , ,

No nos hemos olvidado del Space Penguin, seguimos currando, sólo que hemos tenido que salvar algunos obstáculos llamados Programación Orientada a Objetos, y Análisis de Algoritmos II (obstáculos quiere decir “parciales y prácticas”), entre otros.

Hoy queremos informar de que hemos encapsulado en la clase Juego la gestión de la ejecución de un nivel del juego. Es decir, la clase Juego se compone de un objeto Escenario (que cargará él solito el nivel que se le indique, fondo y plataformas), un objeto Jugador (que recibirá como parámetro, para dar una continuidad entre fases al estado del personaje), y ciertas variables más relativas a un nivel jugable en general.

También tenemos la primera versión del menú principal, que es otra clase (Menu), que se encarga de mostrar un fondo de pantalla y tres opciones al usuario, gestionar el movimiento del cursor de selección, y ejecutar la opción escogida por el jugador. De momento, sólo carga la primera fase.

Tareas por hacer a partir de hoy:

  • Fondo de pantalla en condiciones para el menú principal
  • Opción de cargar un nivel mediante su código de acceso (esto dentro de menú)
  • Gestor de aplicación: Clase que reciba la opción devuelta por el menú principal, y se encargue de ejecutarla; encargándose también de enlazar un nivel terminado con el siguiente, o bien de informar al jugador de que ha perdido todas sus vidas (regresando al menú principal en este caso).
  • Hacer, al menos, un nivel más (que con uno solo vamos cojos)
  • Añadir música y efectos de sonido (esto después de acabar el menú y el gestor de aplicación).
  • Añadir las balas cuando se dispara (se sigue suponiendo que Space Penguin es un juego de disparos, jeje).
  • Añadir enemigos.
  • Condiciones de fin de nivel: refinarlas (esto iría en Gestor de Aplicación)
  • Colocar timers para controlar el número de pulsaciones en el caso de los disparos (la idea de metralleta no es disparar 15 veces la pistola por segundo), y en el caso del menú principal (ahora mismo es complicado atinar en la opción de enmedio).

Y hasta ahí podemos leer. Más novedades pronto. Gracias por leer.

Tercera entrega – 12 de mayo

Publicado 11 mayo, 2010 por rabbitbodom
Categorías: Entregas

Tags: , , , , , , , , , , ,

Agarraos los cinturones, porque aquí viene un post bastante largo. Se trata de la tercera entrega para la asignatura Diseño de Videojuegos, y como tenemos que recuperar cierto terreno, allá vamos (por partes, como diría Jack el Destripador):

  • Actualización de la planificación:

En la carpeta “doc” de la Forja del proyecto, está nuestro archivo de Planner, debidamente actualizado con las tareas que hemos ido desempeñando a lo largo de estos meses. Cabe decir que las fechas del archivo son erróneas (he rehecho el archivo de nuevo) y los plazos no están ajustados, pero la lista de tareas es más o menos completa. Aquí un extracto:

  • Cambios en el proyecto y justificación:

– Las plataformas pasaron a considerarse únicamente como una línea sobre la que pueden caminar los actores. Esto se decidió por la falta de tiempo, ya que el hecho de ahorrarnos los cálculos de colisiones con el escenario en el movimiento horizontal fue una decisión crucial para ahorrar tiempo.

– Decidimos utilizar el sistema de animaciones (clases Animacion, Control_Animacion e Imagen) que se muestra en la wiki de la Osluca sobre libSDL, ya que, tras comprender su funcionamiento, y adaptarlo a nuestras necesidades, ahorramos nuevamente una cantidad de tiempo que, de otra manera, no podríamos haber dedicado al proyecto.

– Otra decisión fue la de ponernos las pilas con la documentación, tanto a nivel de código (Doxygen) como la que se muestra en este artículo. Lo estábamos dejando muy descuidado, y se notó en la presentación anterior.

– Un cambio positivo: en lugar de considerar un vector de plataformas, hemos creado una clase Escenario para que gestione todo lo relativo al escenario de un nivel, desde la carga de las plataformas desde el archivo XML con los datos, hasta el propio fondo del nivel en una superficie SDL. Esto no ha hecho más que facilitarnos increíblemente la labor de trabajar las colisiones con el escenario.

– Otro más, el uso de TinyXML (de agradecer, y mucho, a los consejos de los compañeros del grupo de la ADVUCA). Gracias a esta pequeña librería podemos trabajar cómodamente con nuestros datos, y más aún, nos va a facilitar mucho el trabajo a la hora de hacer el manual de ampliación del videojuego (creador de niveles, por ejemplo).

– Hay más cambios, pero son relativos, principalmente, a la implementación. Los conceptos se siguen manteniendo.

  • Modelado del mundo del juego

Jugador

El jugador estará representado lógicamente por un rectángulo que cubre toda la imagen, que tendrá unas coordenadas x e y con su ancho y alto. Además tendrá un estado interno por el cual se sabrá en todo momento el estado del personaje, como corriendo, saltando, agachado etc… Un vector guardara todas las animaciones del personaje. Tendrá una variable que indicara la munición que contendrá en cada momento de la arma especial y el arma que lleva. Por último tendrá un indicador de orientación para saber cuando está mirando a la izquierda o la derecha.

Los métodos que tiene el jugador son de movimiento ya sea correr o saltar y también para modificación de la munición, el arma equipada y las colisiones con el escenario.

Enemigo

El enemigo al igual que el jugador estará representado por un rectángulo que cubre toda la imagen y unas coordenadas x e y de su posición, así como el ancho y el alto de la imagen.

Un vector guardara todas las animaciones del enemigo. Ya que este personaje lo mueve el sistema automáticamente tendrá solo un estado interno llamado activo que indicara si el personaje esta dentro del rango de la pantalla.

También tendrá una variable que indicara el tipo de enemigo que es, donde según el tipo tendrá una animación u otra.

Los métodos se ejecutaran en función del tipo de enemigo que es, donde tendrá un método que detectara la colisión con los escenarios, un método que disparara el enemigo, para el enemigo disparador, y una función que detecta el final de la plataforma, en el caso del enemigo no disparador.

Plataforma

Tendrá solamente 3 variables internas donde estarán determinado la coordenada x e y del inicio de la plataforma y el ancho de la misma para saber su longitud. Esta plataforma leerá desde un XML los datos respectivos y creara un vector de plataformas donde estarán todas aquellas que pertenezcan al nivel que se encuentra actualmente el personaje. Este vector se leerá a través del jugador o los enemigos para interactuar con ellos.

Bala

Una bala será una clase que contendrá unas coordenadas x e y de su posición en cada momento para ir actualizando según esta avanza por la pantalla además de un ancho y un alto para la colisión con otros objetos.

Las balas también tendrán una variable que distinguirá las balas enemigas de las amigas para que no se puedan matar los enemigos entre sí o el propio jugador con su propia bala.
Toda bala que se cree se introducirá en un vector que se recorrerá constantemente para determinar el estado de las balas durante el juego.

Una vez una bala salga del rango de la pantalla se destruirá.

Ítem

Estos objetos corresponden a los ítems que se encontrara el personaje tirados por el suelo que saldrán aleatoriamente de los enemigos con una probabilidad. Como variables internas tendrá unas coordenadas x e y donde aparece el objeto, será la misma coordenada donde se encontraba el enemigo que lo tenía, y un ancho y alto para realizar la colisión con él.
Además tendrá una variable que indicara el tipo de ítem que es el objeto, ya que según el tipo tendrá un efecto u otro. Estos efectos pueden ser de curación, munición o vidas extras, que estarán enlazados a una variable porcentaje de cada tipo porque no tiene la misma probabilidad de salir la munición, a una vida extra. Una vez que el objeto sale del rango de la pantalla, pasa un tiempo determinado o el personaje lo recoge se destruirá.

  • Ingeniería del proyecto

Mostramos primero el Modelo Conceptual de Datos del sistema, partiendo del Modelado del mundo del videojuego:

En este diagrama, además, se han incluido las clases que se han ido añadiendo a la implementación.

Por otro lado, los casos de Uso, pueden encontrarse en la carpeta “doc” de la Forja. Dejamos aquí un extracto con uno de ellos:

Caso de uso: Mover personaje
– Actor principal: Jugador
– Precondición: no tiene
– Postcondiciones: Modificara la posición del sprite del personaje según la tecla
presionada.
– Personal involucrado e intereses: El jugador quiere mover el personaje a una posición deseada.
Escenario principal
1. El jugador desea mover el personaje.
2. El jugador pulsa la tecla correspondiente a mover el personaje a algún sitio.
3. El sistema actualiza el estado interno del jugador (por ejemplo “corriendo”) a true.
4. El sistema realiza los cálculos según el estado interno del personaje.
5. El sistema dibuja por pantalla el cambio de localización del personaje respecto
al escenario.
Escenario Alternativo
5a. La posición del personaje sobrepasa el valor de la coordenada x de la pantalla.
1. El scroll del mapa avanza tanto como avanza el jugador.
5b. La posición del personaje provoca una colisión con una plataforma.
1. El personaje no sigue descendiendo y se queda en la coordenada y de la
plataforma.

  • Algoritmo general

Esta es la descripción de nuestro main-loop:

Como todo juego que se precie debe tener un bucle principal que se encarga, desde la ejecución del juego hasta que finaliza de mantener activo el juego y atender a las peticiones del usuario en todo momento, asi como ejecutar todas las acciones que se van realizando, ya sea por parte del usuario o del sistema.

El bucle principal consta de una serie de pasos que se realizan al inicial el juego y se mantienen hasta que este termina, estos pasos podemos resumirlo de la siguiente manera:

1. Inicio del contador de frames: Inicialización del contador de frames que transcurren en un segundo, para determinar los fps que correrá el juego.

2. Actualizar el teclado: Por cada vuelta del bucle actualiza el estado del teclado, donde actualiza los valores de este con las teclas que se han pulsado en el instante en que se ejecuta la función, esto es para ejecutar las acciones pertinentes al pulsar la tecla leída.

3. Modificar estado interno del personaje: Según la tecla pulsada, cogida con el actualizar del teclado, si es una de las teclas de movimiento, ya sea derecha, izquierda, salto… se ejecutara la función que realiza tal acción en el personaje. También habrá otras opciones como son el menú de pausa o salir del juego.

4. Cálculos sobre el jugador: En este apartado se realizaran todas las operaciones que el jugador vaya requiriendo según avanza en el juego. Uno de los puntos a tratar son las colisiones del jugador respecto a las plataformas que se encuentran en ese momento en la pantalla. También se realizaran los cálculos para el disparo del personaje donde cada disparo se guardara en su susodicho vector para su posterior análisis.

5. Calculo sobre los enemigos: Ya que los enemigos tendrán su inteligencia artificial respecto a los movimientos del personaje, este apartado se ocupara de calcular las colisiones del mismo, asi como su movimiento y la generar los disparos de aquellos enemigos que disparen. Los enemigos que simplemente andar por una superficie, simplemente se calculara la colisión sobre la plataforma que se encuentra.

6. Calculo del movimiento de las balas: Ya que cada bala será independiente una de ellas, se calculara el movimiento (velocidad y dirección) de cada una dependiendo de quién lo lance, ya sea enemigo o el personaje, y la posición de la pantalla que se encuentra en ese momento. Estas balas desaparecerán una vez traspase el límite de la pantalla o colisione con algún obstáculo.

7. Calculo de las colisiones: En este apartado se trataran todas las colisiones entre sprites diferentes. Ya sea el personaje con un objeto, un enemigo o una bala o el enemigo con el personaje, se ejecutara la acción correspondiente a esta colisión.

8. Dibujar sprites: Una vez detectado todas las pulsaciones en el momento, calculado respecto a las pulsaciones y ejecutado lo correspondiente a las colisiones, se dibuja por pantalla todos los cambios una vez por frame para que se vea un movimiento fluido de los objetos que se muestran por pantalla. Aquí también se tendrá en cuenta el movimiento del personaje para mover el fondo (scroll) según avanza por el escenario.

9. Calcular el retraso: Para mantener unos fps constantes en cualquier sistema, se calcula el retraso que tiene éste y se actualiza los frames correspondiente al sistema.

Por supuesto, el documento completo, en la carpeta “doc”

  • Autómatas para la I.A. de los enemigos (comportamiento)

– Enemigos disparadores: Estos enemigos, una vez activados, se moverán en línea recta desde su posición inicial hasta que salgan de la pantalla. Durante el transcurso de su recorrido, cada cierto tiempo disparara una bala en línea recta desde su frontal, que tendrá una velocidad mayor a la del enemigo, para abatir a nuestro protagonista. Estas balas no afectaran a otros enemigos, así que solo afectara al protagonista.

– Enemigos de patrulla: tienen un comportamiento algo diferente al anterior. Estos simplemente estarán asignados a una plataforma de la cual no podrán bajarse, esto quiere decir que este enemigo dará vueltas y vueltas sobre la misma plataforma una vez que entra en el rango de la pantalla hasta que sale de la misma. Esto hace que el enemigo detecte siempre el final de ambos extremos de la plataforma para dar la vuelta completamente y dirigirse al lado contrario.

  • StatSVN

Las estadísticas de nuestro servidor SVN pueden observarse en este gráfico:

Decir que este gráfico es de la revisión 25, y vamos ya por la 35, diez más. Desde entonces hemos avanzado a pasos de gigante.

Cabe comentar que nuestras revisiones son menores en número, pero cad vez que hacemos un commit reflejamos una versión estable del videojuego, con multitud de cambios nuevos. Es por ello que se explica la diferencia del número de aportaciones a la Forja respecto a los proyectos de otros compañeros.

Por otra parte, las estadísticas por desarrollador son engañosas. RabbitBodom (Ezequiel) llevaba aportadas más de dos mil líneas de código en la revisión 25 (hoy en día, probablemente muchas más), y Helkadil sin embargo (Agustín), casi 100. Esto no significa que Helkadil no esté trabajando, ni mucho menos. Se está currando toda la parte de diseño gráfico del proyecto (ahí es “ná”), de ahí sus pocas aportaciones en cuanto a código nos referimos. Por otra parte, y para compensar, cuando Rabbit termine de pulir la clase Jugador, se intercambiarán los papeles, de ta manera que se proporcione correctamente el número de aportaciones. (Helkadil va a dedicarse a implementar las dos clases de enemigos, y quizá la clase Item).

  • Doxygen

En esta sección sólo comentar que todo lo que llevamos hasta el momento está completamente documentado con Doxygen, hasta la última función pública. Se aportan un par de ejemplos de uso en las clases Jugador y Escenario.

  • Bibliografía

Nombrar por supuesto, la wiki sobre libSDL de la Osluca, y la documentación de TinyXML en su página oficial. Con estos dos manuales hemos podido dar pasos de gigante, de tal manera que ya tenemos una “beta estable”, sobre la cual hablamos ahora.

  • Presentación “beta” alpha

Última sección de este repaso a Space Penguin. En la revisión 35, la actual, podemos afirmar que tenemos totalmente operativa una alpha sin enemigos, pero en la cual se pueden observar todos los movimientos del personaje principal, y la carga de un nivel completo. Sólo necesitamos pulir las colisiones con las plataformas para afirmar que el motor está fino.

Aquí está el enlace a la alpha1 de Space Penguin, para sistemas GNU/Linux: http://forja.rediris.es/frs/download.php/1844/space_penguin-beta1.tar.gz

Y bueno, hasta aquí podemos contar. Próximamente, el menú principal, la estructura por niveles, y las colisiones con el escenario refinadas.

Sistema de niveles

Publicado 7 mayo, 2010 por rabbitbodom
Categorías: General

Tags: , , , , , , , , , , , ,

Presentamos el último avance de Space Penguin: El sistema de niveles.

Consta, básicamente, de una imagen de fondo en formato bmp, y un archivo XML en el cual se almacenan las características de las plataformas que componen el nivel.

Las imágenes de fondo, necesariamente, deben medir 600 píxeles de alto, ya que la resolución de nuestro juego es de 800×600, y se almacenan en la carpeta “imagenes” con el nombre Fase_n.bmp, donde la n es el número de nivel del cual es el fondo.

Por otro lado, el archivo “datos/plataformas.xml” almacena la información de las plataformas de todas las fases del juego, con un formato muy sencillo.

El único inconveniente de este sistema es que, para crear un nivel, hay que incluir manualmente las coordenadas de comienzo de cada plataforma, y su anchura. Si tuviéramos tiempo de aquí a fin de curso, intentaremos crear un editor de niveles muy simple, pero que sea efectivo.

Por otra parte, la lista de tareas por hacer a corto plazo, a partir de la revisión 29 de Space Penguin es la siguiente:

  • Refinar las colisiones del personaje con las plataformas, que aún están un poco verdes.
  • Implementar el scroll, para que el escenario avance junto con el personaje. (Hecho)
  • Abstraer el sistema de carga de un nivel en una sola función (para que así sea más cómodo, y depender de únicamente una función), así como crear las variables necesarias para el control de la fase actual. (Hecho)
  • Al cargar un nivel, presentar una pantalla de inicio de fase, de tal manera que el jugador tenga unos segundos para acomodarse.
  • Realizar la documentación y postearla aquí (fecha límite: el miércoles 12).
  • Implementar la condición de victoria (llegar al final de la fase).

De momento, y con gran satisfacción, tenemos el placer de mostrar el segundo vídeo de Space Penguin:

Puede apreciarse en el vídeo la interacción del personaje con las plataformas (que como hemos dicho, están aún muy verdes), y algunos movimientos del jugador. Dentro de poco lo tendremos con scroll, y más pulido, no os lo perdáis.

Actualización a 8 de mayo, 23:00 horas: Ya está implementado el scroll del escenario, y está más fino el sistema de carga de niveles.