Making OFF: T-UFO

Making OFF: T-UFO


Presentado en la Compo 2015, T-UFO es el primer juego que hago con SEUCK que ve la luz.
Con música de Richard Bayliss en la pantalla de carga, todo un lujo y un honor.

Al poco de empezar a utilizar el SEUCK una de las primeras cosas que se me pasaron por la cabeza fue que tipo de juegos podría desarrollar teniendo en cuenta las opciones de las que dispone el programa.
Este es el resultado de mis pruebas para ver si se podría hacer un juego de tiros tipo Space Invaders con SEUCK. Inicialmente este juego lo empecé a diseñar para la GP32. La idea era sencilla: un camión lanza misiles contra platillos volantes en diversos escenarios del mundo. Parece sencillo de hacer pero no lo es.

Delimitando las limitaciones


El principal problema surge del hecho de que el programa no parece estar pensado para crear este tipo de juegos.
Los niveles disponen de un estado estático (STILL) que podemos prolongar en el tiempo entre 0 y 99 segundos. Eso debería bastar para hacer un juego de este tipo, pero no.

El problema no deriva de los niveles sino de los sprites. Los sprites aguantan en pantalla entre 6 y 8 segundos de media. La solución pasa por concatenar varios niveles con un fondo en común para prolongar así la escena.
Eso si, sin olvidar que solo disponemos de 22 niveles para asignar al juego.

Pero claro, ocurre una cosa que no es tan obvia. El paso de un nivel a otro requiere de una transición. Haciendo memoria no recuerdo ningún juego de pantalla estática que no utilice el recurso de transición para pasar de una pantalla a otra excepto aquellos que usan el scroll para desplazarse de una pantalla a otra. Un mensaje de texto, algo, lo que sea, debe servirnos de intermedio entre cada escenario. Es un recurso narrativo manido pero práctico. Permite tomar aire tanto al jugador como al juego. La transición crea la expectativa de lo que vendrá después y ese avance es la motivación principal de estos juegos.

Solucionado este problema surgieron otros dos.

El diseño de la pantalla de juego, con un borde redondeado en las esquinas, es algo que me encantó cuando lo vi por primera vez en e-motion. Pero cuando lo traté de plasmar me encontré con una sorpresa. La pantalla se constituye de 5x8 bloques. Pero los bloques de la primera linea están cubiertos por una línea, un carácter negro que ocupa la parte superior de la pantalla y que seguramente será un delimitador de posición del propio programa. Con lo que en vez de de mostrar la totalidad del bloque (5x5 caracteres de 8x8 pixels) lo muestran parcialmente (4x5 caracteres).

Tras una ligera modificación quedaba el asunto del movimiento.

Si tratamos que nuestro sprite se mueva por un raíl nos percatamos que el recuadro del área de juego más estrecha que podemos seleccionar no cumple su cometido. He visto varios juegos SEUCK que presentan este problema. El sprite tiene cierta holgura y no sirve a nuestros propósitos. No queda más remedio que echar mano de la función de colisión de caracteres. En Player Limitations podremos activar la colisión de caracteres. Mediante el uso de caracteres podemos llegar a crear un camino lo suficientemente estrecho como para que el sprite quede constreñido a ese área. Delimitando el área del jugador y añadiendo dos barreras en los bloques del mapa he conseguido que el camión no se salga del sitio.

Pero también paso algo al poco de empezar a pensar en las limitaciones del SEUCK... Se podría utilizar el sonido generado por el propio juego como banda sonora?
La solución es sencilla. Basta con asignar un sprite enemigo invisible cuya cadencia de disparo (invisible también) genere un sonido rítmico. He de decir que Alf Yngve ya llegó a la misma conclusión bastante antes que yo, lo que pasa es que yo me he enterado tarde de sus consejos.