taller

Taller Crea tu propio juego de Spectrum (capítulo 7b) Churrera 3.99.1

La Churrera se ha actualizado y los amigos de Mojon Twins han tenido a bien hacer un capítulo B del 7 para explicar las novedades que trae. A partir de ahora tendremos más posibilidades (si cabe) para nuestro propio juego de Spectrum. ¡A disfrutar!

La Churrera 3.99.1

Antes que nada, bájate el paquete de la nueva versión de la churrera haciendo click justo aquí debajo:
http://www.mojontwins.com/churrera/mt-churrera-3.99.1.zip

¿Pero qué seto?

Interrumpimos brevemente nuestro tutorial antes de meternos en vereda con el tema del scripting para introduciros una nueva versión de la Churrera. No queremos que estéis desactualizados: como hemos introducido un porrón de cosas nuevas muy interesantes y, lo que es más importante, hemos corregido algunos bugs y optimizado bastante el código existente (para que te quepan más cosas en los güegos), hemos decidido que no íbamos a seguir el tutorial antes de que tuviéseis la versión actual.

En este tutorial, además, vamos a aprender algo que vendrá muy bien para el futuro: a actualizar la versión de la churrera con el güego empezado.

¿Es obligatorio actualizarse? Bueno, tú verás. Si quieres terminar de seguir el tutorial con el Dogmole, la verdad es que no lo necesitas. Pero te recomiendo que, aún así, te actualices.

¿Estás listo? Venga, vamos a empezar diciendo qué hay de nuevo.

Pulsa aquí para ver el capítulo completo.

¿Qué hay de nuevo?

Vamos a ir por partes, porque las novedades se extienden por varios ámbitos. Lo chuli es que ahora tienes medio claro cómo funciona todo, y explicar estas cosas nos va a resultar tela de fácil.

Tiles destructibles

En un principio (por ahora) orientados a los güegos que lleven el motor de disparos, hemos definido un nuevo tipo de tile, el 16. Estos tiles se romperán y desaparecerán (serán sustituidos por el tile número 0) tras ser alcanzados por cierto número (configurable) de disparos. Para incluirlos, además de tener tiles definidos con el tipo 16, tenemos que configurar algunas cosas en config.h:

#define BREAKABLE_WALLS // Breakable walls
#define BREAKABLE_WALLS_LIFE 1 // Amount of hits to break wall

La primera directiva, BREAKABLE_WALLS, activa esta característica e incluye todo el código necesario para que haya tiles destructibles (si no la activas, por mucho que tengas tiles de tipo 16 no pasará nada). La segunda, BREAKABLE_WALLS_LIFE, define el número de disparos que deben recibir los tiles destructibles para romperse. Obviamente, tienes que poner un número mayor de 0. Si pones un 3, el tile se romperá al tercer disparo que reciba.

Tipos de tile combinables

Esto es algo que queríamos haber puesto desde el principio, pero que hemos ido dejando. La planificación de tener tiles con tipos combinables (que fueran a la vez varias cosas) es la verdadera razón por la que la lista de tipos de tile tienen tantos agujeros. Ahora verás por qué.

Básicamente se trata de combinar tipos de tile, para que un tile sea a la vez, por ejemplo, una plataforma que te mata, o un obstáculo que se puede romper. Para combinar tipos de tiles, sólo hay que sumar los tipos que queramos combinar. De ahí que haya “agujeros” en la numeración.

Por ejemplo, para hacer un obstáculo que se pueda romper, tendríamos que hacer que ese tile tuviese tipo obstáculo (8) y tipo destructible (16), o sea, que fuese de tipo 8 + 16 = 24. En el último güego que hemos sacado, el del Sgt. Helmet, hay vallas electrificadas (que matan) que podemos destruir. Si te bajas las fuentes (deberías, ¡ahora eres desarrollador churrero!) y miras la sección de tipos de tile (behaviours) al final de config.h verás como el tile de la valla electrificada tiene tipo 17, o sea, que mata (1) y que es destructible (16): 16 + 1 = 17.

Hay muchas combinaciones estúpidas y que no tienen ningún sentido, como poner un obstáculo que te mata (8 + 1 = 9). De hecho, es una de esas combinaciones estúpidas e imposibles la que hemos usado para los tiles especiales (los bloques que se empujan y los cerrojos), que son de tipo 10 (8 + 2, o sea, un obstáculo que te esconde).

El motor sigue admitiendo tipos sencillos (1, 2, 4 u 8), así que no tienes que cambiar nada en tu Dogmole o en tu propio güego.

Balas que se acaban

Ahora puedes decidir que las balas se acaben. Además, puedes colocar recargas de munición en el güego. Para ello, lo primero es tocar config.h para activar y configurar esta capacidad:

#define MAX_AMMO 99 // If defined, ammo is not infinite!
#define AMMO_REFILL 50 // type 3 hotspots refill amo, using tile 20
//#define INITIAL_AMMO 0 // If defined, ammo = X when entering game.

La primera directiva, MAX_AMMO, si está definida, hace que las balas se acaben y que su valor máximo sea el que se especifica. Si quieres balas infinitas, simplemente comenta esta definición. La siguiente, AMMO_REFILL, indica cuántas balas pillamos cuando cogemos una recarga de munición. La tercera, INITIAL_AMMO, si está definida, hace que al principio del güego tengamos el número de balas especificado. Si no se define, el número de balas al empezar será el maximo, o sea, el que dice en MAX_AMMO.

Tal y como sale ahí (es la configuración del Sgt. Helmet), el máximo de balas es 99, en las recargas cogeremos 50 cada vez, y empezaremos con el máximo, o sea, 99.

Para colocar las recargas lo haremos con el colocador, y usando los hotspots. Hasta ahora habíamos usado hotspots de tipo 1 para los objetos y de tipo 2 para las llaves. Para colocar recargas, necesitaremos hotspots de tipo 4. Además, en nuestro tileset, el tile número 20 debe ser el correspondiente a la recarga. Este es el tileset del Sgt. Helmet. Fíjate como el tile número 20 es una recarga de munición:

Mejoras a los enemigos de tipo 7

Hemos metido un par de cosillas para los enemigos de tipo 7. Hasta ahora, los enemigos de tipo 7 salían del sitio que tú definías en el colocador y se liaban a perseguirte. El gráfico asociado era elegido al azar entre los cuatro enemigos del spriteset. Ahora permitimos que seas tú el que decida qué gráfico lleva, y que sea este siempre. Además, estos enemigos avanzaban pero se veían detenidos por los tiles de tipo obstáculo (tipo 8). Ahora podemos configurar que cualquier tipo de tile que no sea traspasable (tipo 0) los detenga. Esto se hizo para que, en el Sgt. Helmet, se detuviesen también en las vallas electrificadas (que no son de tipo 8). Todo esto se consigue con dos directivas nuevas en config.h:

#define TYPE_7_FIXED_SPRITE 4 // If defined, type 7 enemies are always #
#define EVERYTHING_IS_A_WALL // If defined, any tile <> type 0 is a wall.

La primera es para fijar un número de gráfico de enemigo para los enemigos de tipo 7. La segunda es para que los enemigos te persigan solo por los tiles de tipo 0. Si comentas esta última, el comportamiento será el mismo que hasta ahora: te perseguirán por cualquier tile y se detendrán solo con los de tipo 8.

Cosas del motor de scripting

Sí, hemos metido muchas cosas nuevas aquí. Pero ya nos esperamos al capítulo donde empezaremos a explicar el motor de scripting.

Correcciones y optimizaciones

Además, hemos rescrito completamente la parte del motor que gestionaba los disparos, de forma que ahora la colisión es más precisa y ocupa menos espacio. Hemos arreglado algunos bugs también, y hemos cambiado algunos trozos del código optimizando todavía más. Antes de las optimizaciones, el güego del Sgt. Helmet no hubiese cabido en la memoria ni de coña. Mola.

¿Cómo me actualizo?

No es ni complicado ni coñazo pero, de todos modos, coge la carpeta tal y como la tienes y hazte un ZIP de copia de seguridad, como quien no quiere la cosa, por si acaso. Cuando estés, sigue estos sencillos pasos:

1. Cámbiale el nombre a la carpeta de tu güego. No sé, ponle “-viejo” al final.

2. Prepara el nuevo paquete tal y como hiciste con el anterior, o sea, descomprímelo, cambiale el nombre a la carpeta del güego, cámbiale el nombre a /dev/churromain.c y script/churromain.spt por el nombre de tu güego, y edita make.bat cambiando %1 por el nombre de tu güego. Como ya hemos hecho.

3. Copia los gráficos, mapas, y archivos de enemigos desde tu carpeta antigua a la nueva, o sea, todo lo que haya en gfx/, en /map y en /enems.

4. Vuelve a editar config.h – Tienes que abrir el /dev/config.h nuevo y el tuyo antiguo y poner el nuevo tal y como tenías el tuyo antiguo. Fíjate bien en las nuevas características: comenta las que no quieras, o prueba a usarlas, o lo que más te pete.

5. Vuelve a copiar los archivos propios de tu güego desde la carpeta /dev antigua a la nueva. A saber: tileset.h, spriteset.h, title.bin, marco.bin (si usas), ending.bin, mapa.h y enems.h

Ya está. Ahora sólo tienes que comprobar que lo has hecho todo bien abriendo tu ventana de linea de comandos y ejecutando make.bat… Si no, revisa todos los pasos.

Y, para la próxima, ahora sí, el temido scripting. Mientras tanto, ¡a jugar al Sgt. Helmet!

AVISO

Gracias a Fabio Didone, que está siguiendo el tutorial y haciendo su propio güego, nos hemos dado cuenta que en la última versión de la churrera se nos ha colado un pequeño bug que rompe el comportamiento de ONLY_ONE_OBJECT. Hemos actualizado el paquete de la 3.99.1 con el error subsanado. Podéis descargarlo de nuevo en la dirección de siempre:

http://www.mojontwins.com/churrera/mt-churrera-3.99.1.zip

Si habéis empezado vuestro güego, no tenéis que volver a montarlo todo. Solo basta con que sobrescribáis mainloop.h por la nueva versión incluida en el paquete.

Más información:The Mojon Twins

El Mundo del Spectrum

El Mundo del Spectrum es un medio digital dedicado al Sinclair ZX Spectrum, a los 80 y al Retro en general. Nació como homenaje a Microhobby en 1996 en formato revista mensual evolucionando hasta esta cuarta época. Como medio audiovisual se publica regularmente el Podcast llamado El Mundo del Spectrum Podcast y material en vídeo en el canal de Youtube. Publicados dos libros de gran éxito editorial. Si te gusta el Retro y el Spectrum en particular, esta es tu web. Bienvenido/a.

Publicaciones relacionadas

13 comentarios

  1. Muy buenos añadidos en esta nueva versión.

    Como siga creciendo así la churrera la podremos usar también para lanzar misiles atómicos!. Espera… o esa era la Playstation 2? XD

    Muchas gracias. Ahora, a esperar el tan ansiado capítulo del scripting, que me tiene en vilo. 😛

  2. Ale, actualizado el juego a la nueva versión de la churrera y funcionando sin problemas.

    El archivo .tap resultante es de

    40,9 KB (41.945 bytes)

    Espero que hasta la 48kb tenga espacio suficiente para añadir más gráficos (extra tile) al escenario mediante script, la nueva pantalla de carga y modificar la musiquilla 😀

  3. El tamaño del archivo .tap no te dice lo que el juego ocupa en memoria. Sin modificar los cargadores (de eso hablaremos en un futuro capítulo), tienes espacio desde 25000 hasta 60655 para las cosas de tu güego. Eso significa que el binario de tu güego puede ocupar 35655 bytes. Para saber cuanto ocupa, abre el .tap en el emulador y mira cuanto ocupa el último bloque. En el Spectaculator, por ejemplo, se puede ver en la ventana del "cassette recorder" (Dale al icono de la cintita para que salga)

  4. @na_th_an: Anda que ya me vale! eso me pasa por noob y no pararme a pensar las cosas.

    Tienes más razón que un santo compañero, el tamaño del archivo puede ser del tamaño que sea, siempre que las cargas en memoria sean por bloques como los juegos multi carga. XD

    Pues he mirado en el Spectaculator y me sale esto:

    Normal Data Block (34889 bytes)

    Por lo que me deja libre 766 bytes. :S

    No se si con eso podré hacer mucho.

  5. Que llenes más o menos el tileset no importa: ocupará igual, porque se guardan todos los tiles aunque estén vacíos. Sí que sería posible "recortar" si todos los tilesets vacíos están al final del tileset, modificando un poco el código.

    Si lo único que te queda por meter es el script, creo que con eso tienes suficiente. Además, aún podemos ganar 800 bytes más si compilamos más abajo. Hemos comprobado que se puede compilar hasta 24200 en vez de 25000…

    De hecho, ahora que lo pienso, creo que la 3.99.1 la he empaquetado sin modificar eso, y ya compila "de fábrica" en 24200… Así que te quedan 800+766 = 1566 bytes. Con eso creo que no vas a tener ningún problema 😀

Deja una respuesta



Traductor jurado inglés Zaragoza
Traducción jurada de documentos en inglés
Páginas web Zaragoza
Páginas web de calidad Zaragoza
Camiseta España balonmano
Camiseta de la Selección Española de balonmano para adulto
Botón volver arriba