Crea tus Juegos con 8BP

8BP: Juegos de pantallas, layout o “tilemap”

4.8
(9)

¡¡¡Hola amigo de 8 Bits de poder!!! A menudo querrás que tus juegos consistan en un conjunto de pantallas, donde el personaje deba recoger tesoros o esquivar enemigos en un laberinto. Esto lo vamos a lograr mediante el uso de un layout o «tilemap «.

rutas avanzadas

Pero espera… ¿Es posible que no sepas nada de 8 Bits de Poder? Puedes leer el primer artículo del curso de programación en Amstrad CPC de 8BP.

Definición y uso del layout

En esos casos se hace indispensable el uso de una matriz donde definas los bloques constituyentes de cada “laberinto”, también llamado “layout”, de la pantalla. A veces a este concepto también se le llama “mapa de tiles” (un “tile” es la palabra en inglés para decir “azulejo”)

En la librería 8BP tienes un mecanismo sencillo para hacerlo, además de proporcionar una función de colisión para que compruebes si tu personaje se ha desplazado a una zona ocupada por un “ladrillo”. Este mecanismo se denomina “layout”.

8BP: Juegos de pantallas, layout o “tilemap” 2

En 8BP un layout se define con una matriz de 20×25 “bloques” de 8×8 píxeles, los cuales pueden estar ocupados o no. Es decir, hay tantos bloques como tiene la pantalla de caracteres en mode 0.

Para imprimir un layout en la pantalla dispones del comando:

|LAYOUT, <y>, <x>, @string$

Esta rutina imprime una fila de sprites para construir el layout o «laberinto» de cada pantalla. La matriz o “mapa del layout” se almacena en una zona de la memoria que maneja 8BP, de modo que cuando imprimes bloques en realidad, no solo estás imprimiendo en la pantalla, sino que también estas rellenando el área de memoria que ocupa el layout (20×25 bytes) donde cada byte representa un bloque.

Las coordenadas y, x se pasan en formato caracteres, es decir

y toma valores [0,24]

x toma valores [0,19]

Los bloques que imprime la función |LAYOUT se construyen con cadenas de caracteres, y cada carácter se corresponde con un sprite que debe existir. De este modo el bloque “Z” se corresponde con la imagen que tenga asignada el sprite 31, el bloque “Y” se corresponde con la imagen que tenga asignada el sprite 30, y así sucesivamente.

Los sprites a imprimir se definen con un string, cuyos caracteres (treinta y dos posibles) representan a uno de los sprites siguiendo esta sencilla regla, donde la única excepción es el espacio en blanco que representa la ausencia de sprite.

Carácter Sprite id Codigo ASCII
“ “ NINGUNO 32
“;” 0 59
“<” 1 60
“=” 2 61
“>” 3 62
“?” 4 63
“@” 5 64
“A” 6 65
“B” 7 66
“C” 8 67
“D” 9 68
“E” 10 69
“F” 11 70
“G” 12 71
“H” 13 72
“I” 14 73
“J” 15 74
“K” 16 75
“L” 17 76
“M” 18 77
“N” 19 78
“O” 20 79
“P” 21 80
“Q” 22 81
“R” 23 82
“S” 24 83
“T” 25 84
“U” 26 85
“V” 27 86
“W” 28 87
“X” 29 88
“Y” 30 89
“Z” 31 90

Correspondencia entre caracteres y sprites para el comando |LAYOUT

El @string es una variable de tipo cadena. No puedes pasar directamente la cadena. Es decir, sería ilegal algo como:

|LAYOUT, 1, 0, ”ZZZ YYY”

Lo correcto es:

Cadena$ = ”ZZZ YYY”

|LAYOUT, 1, 0, @cadena$

Ten cuidado de que la cadena no esté vacía, de lo contrario puede bloquearse el ordenador. Además, debes anteponer el símbolo “@” en la variable de tipo string para que la librería pueda ir a la dirección de memoria donde se almacena la cadena, y así poder recorrerla imprimiendo uno a uno los sprites correspondientes.

8BP: Juegos de pantallas, layout o “tilemap” 3

Debes tener en cuenta que los espacios en blanco significan ausencia de sprite, es decir, en las posiciones correspondientes a los espacios no se imprime nada. Si había previamente algo en esa posición, no se borrará. Si deseas borrar necesitas definirte un sprite de borrado de 8×8, donde todo sean ceros.

Aunque usas los sprites para imprimir el layout, justo después de imprimirlo puedes redefinir los sprites con |SETUPSP y asignarles imágenes de soldados, monstruos o lo que quieras, es decir, el layout se “apoya” en el mecanismo de sprites para imprimir, pero no te limita el número de sprites, pues dispones de los treinta y dos para que sean lo que tú quieras, justo después de imprimir el layout

Para detectar colisiones con el layout dispones de la función COLAY, que se puede usar con un número de parámetros variable.

|COLAY,<umbral ASCII>, @colision , <sprite number>

|COLAY, @colision , <sprite number>

|COLAY, <sprite number>

|COLAY

Dado un sprite y dependiendo de sus coordenadas y de su tamaño, esta función averiguará si está colisionando con el layout, y te avisará a través de la variable colision, la cual debe estar previamente definida.

El parámetro <umbral ASCII> es opcional y sirve para que el comando no considere colisión a aquellos códigos ASCII inferiores a dicho umbral. Por defecto es 32 (que es el correspondiente al espacio en blanco). Para entender esto, hay que tener en cuenta la correspondencia entre valores ASCII y Sprites que se ha mostrado en la tabla anterior. Por ejemplo, si ponemos como umbral el 69 (código de la “E”, sprite 10), entonces los sprites 9, 8, 7, 6, 5, 4, 3, 2,1, y 0 no serán “colisionables”, de modo que si nuestro personaje pasa por encima, simplemente no será detectada la colisión.

8BP: Juegos de pantallas, layout o “tilemap” 4

Tan solo hace falta invocar a COLAY con el parámetro de umbral una vez, ya que las sucesivas invocaciones tienen ya en cuenta dicho umbral.

Ejemplo de uso:

col%=0

|COLAY, @col%, 20: REM este es un ejemplo con spriteID=20

Si invocas al comando COLAY sin parámetros, considerará los últimos que usó. De ese modo te puedes ahorrar el paso de parámetros y acelerar el comando 0.5 ms.

Si no hay colisión, la variable tomará el valor cero. Si hay colisión, tomará el valor 1. Hay colisión si el sprite choca con algún elemento del layout diferente del espacio en blanco (“ “), cuyo código ASCII es 32. En caso de usar el umbral, habría colisión si el elemento del layout tiene un ASCII superior al umbral que se defina.

Vamos a ver un ejemplo de creación de un layout y de movimiento de un personaje dentro del layout, corrigiendo su posición si ha colisionado. Dos ultimas consideraciones sobre el comando COLAY:

  • Al comando COLAY, no le afecta el ajuste de la sensibilidad de colisión entre sprites (configurable con COLSP,34, dy, dx). El ajuste de sensibilidad de colisión solo afecta a los comandos COLSP y COLSPALL
  • El comando COLAY no tiene en cuenta el tamaño real de las imágenes usadas como “Tiles” o “bloques” del layout; considera que todos los bloques especificados en el comando LAYOUT miden 8×8 píxeles de mode 0 (4 bytes x 8 líneas), aunque tu pongas imágenes más grandes.

Te dejamos un vídeo del Profesor Retroman donde puedes ver como se crea un tilemap con el uso de Gimp y Tiled.

Por favor, acepta las cookies de YouTube para poder ver este video. Aceptando, accederás al contenido de YouTube, un servicio externo y gestionado por terceros.

Leer la privacidad de Youtube.

Aceptando este aviso, tu selección será guardara y la página se refrescará.

En la próxima entrega del curso 8BP, veremos un ejemplo de uso del comando layout.

Hasta aquí hemos llegado por hoy con el curso de programación en Amstrad CPC de 8 bits de poder Si tienes alguna duda puedes escribir en comentarios y te contestaré lo antes posible.

Todos los recursos, como manuales, ejemplos y juegos compilados de este curso los puedes encontrar en el repositorio Github de 8BP.

Hasta la semana que viene amigos 😄

¿Te ha Resultado útil este artículo?

Ayúdanos a mejorar y danos tu opinión:

Mostrar más

2 comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Publicaciones relacionadas

Mira también
Cerrar
Botón volver arriba