Ramiro El Vampiro “R”; 20160125

Ramiro el Vampiro Revamp Project

Con las cintas para publicar el juego en camino (color red jelly, eso mowla) me he decidido de una vez por todas a crear versiones remozadas de estos juegos usando MK2. Sencillamente, los Ramiros están entre mis preferidos de todos los que hemos hecho, y creo que ya que los vamos a sacar en cinta lo suyo es que lleven la tecnología más actual. Los originales están geniales, pero están construidos con la versión 4.5 de la Churrera MK1, y eso es de antes de que decidiéramos liberarla y la reseteásemos a la 3.1 sobre la que construimos la 3.99, que fue la que terminó evolucionando hasta convertirse en MK2. O sea, que el código que soporta las andaduras de nuestro vampiro favorito es realmente viejo. Creo que en MK2 el juego se moverá mucho mejor, podremos utilizar una salida de texto más interesante, y se liberará el espacio suficiente para meter música en el menú.

Así, de cabeza, necesitaría:

  • Revisar detenidamente el script original de Ramiro para ver qué cosas faltarían en MK2. Sin pensarlo demasiado, creo que con la potencia actual de msc3 se podría simular toda la mierda custom que había, pero siempre hay algo que falla. En ese caso, habría que evaluar si es necesario ampliar el motor o meterlo como custom (cosas como las que pasan en el segundo juego, que al final todos los enemigos se transforman en murciélagos, estaba hecho en motor y activado desde el script en 4.5, cuando puede hacerse de forma mucho más sencilla con un custom; a fin de cuentas, es algo muy específico).
  • Implementar el comportamiento “roba energía” de los tiles donde te da el sol. Esto no está hecho. Tengo que recordar las características; creo que se mostraba un contador y que el tick de dicho contador era configurable. Lo miraré.
  • Estaba pensando en modificar map2bin para añadir soporte para juegos que utilicen 2 tilesets de 16 que se cambie dependiendo de la pantalla. Creo que puede venir bien para el futuro, aunque tendría que procesar los .map originales para que empléen los tiles reales – meh bleh. Cosas. Vamos, que yo me entiendo.

Ampliación de map2bin:

Al final la idea es que tengamos un tileset de 48 tiles en el formato siguiente:

1111111111111111
EEEEEEEEEEEEEEEE
2222222222222222

y que el conversor map2bin haga lo siguiente:

  • Los tiles “1” y “2”, de las filas primera y tercera, se consideran tilesets de un mapa packed. En el binario generado, habrá una sección al final donde se escriba un 1 o un 2 dependiendo de qué tile se utilice. “¡Mastuerzo!”, dirás, “¡pero si eso lo puedes empaquetar en bits y usar un bit por pantalla!” Lo pensaré, porque a lo mejor el código necesario para desempaquetar los bits ocupa más que lo que se ahorre en los datos. ¿Qué hablamos, de 30 bytes? ¿35? Meh, eso se lo ventila z88dk con dos expresiones. Mejor hacerlo a byte.
  • Los tiles “E” son decoraciones y se tratarán como hasta ahora.

Hacer el mapa de Ramiro fue un poco dolor, porque había que estar cambiando el tileset importado en mappy constantemente. Creo recordar que no había demasiadas decoraciones, pero hubo que ponerlas a mano. Eso es otra cosa que tendré que hacer sobre el mapa original: trasladar las decoraciones desde el script.

“Pero melón”, pensarás, “vas a trabajar para que luego el conversor te convierta automáticamente lo que ya tienes convertido a mano”. Sí, pichurro, pero así podremos usar esto en otros juegos futuros.

~

Lo que más pereza me da es que ahora tengo que actualizar whatsnew.txt con todas las cosas de K2T que había metidas… ¡Y son un montón! Conociéndome, no creo que haya ido actualizándolo a medida que ho hacía. Al menos llevé un diario. Es lo mejor llevar estos putos diarios.

~~

Me cago y mequeda… ¡Sí que lo llevaba actualizado! No sé si 100% al día, pero bastante. Seguro que sí, teniendo en cuenta la fecha del archivo y que las cosas de motor las hice al principio – luego todo fue custom y scripting. Lo miro despacito luego. Voy a ir creando el proyecto de Sublime Edit 2 (dios, como amo este editor de textos, ¿por qué coño no lo conocí antes?) y luego me voy a tomar un desayunito.

~~

Anoto cosas que veo en el script:

  • Uf, no hay apenas comentarios y esto es de cuando no había nombres descriptivos para los flags – nada que un find & replace no pueda resolver.
  • Sección “PLAYER_GETS_COIN”. Ahora por mis muelas que no recuerdo si esto está en msc3. Si no, algo parecido habrá. Si no, añadirlo es una tontería. Se puede usar para lanzar cuando el jugador coja un TILE_GET
  • SHOW_COINS / HIDE_COINS. Si las monedas son decoraciones, esto sobra porque puedo usar DECORATIONS. Lo que tengo que mirar es qué coño hace HIDE_COINS, porque supuestamente las monedas las hemos tenido que coger.
  • Las monedas que se cogen en las pantallas trampa se cuentan sobre el FLAG 1. La comprobación de que se haya cogido las 20 se hace en la sección “PLAYER_GETS_COIN”. En cualquier caso se incrementa en 1 la vida.
  • ENABLE_TYPE_6 y DISABLE_TYPE_6 hacen que los murciélagos empiecen a moverse o se queden paralizados. Esto se puede hacer de forma diferente en MK2, pero creo que no me cuesta nada adaptarlo en msc3. Las directivas ya están, pero generan código viejo. Sólo tengo que adaptar la generación de código y hacer una leve modificación al motor, así que esto lo añado.
  • Casi todos los textos se ponen con TEXT y son de la leche de limitados. Ahora todos irán en cajas de texto. Pensaba usar directamente las cajas de texto de Ninjajar!/etc, pero mola el sonido tipo “adultos de las películas de Peanuts” que aparece con cada linea, así que las cogeré y las modificaré levemente para que suenen así.
  • Creo que MK2 no lleva el mismo set de sonidos. Habrá que ponerlo y adaptar. Tengo que mirar esto también. <- En efecto. Pasa esto. Y además quizá sea el momento de crear constantes para los sonidos y no tener que estar cambiando números por todo el código para cada juego.
  • Que te puedan matar despacito o no se controla con ENABLE_KILL_SLOWLY y DISABLE_KILL_SLOWLY. Esto es fácil de añadir, aunque en realidad podría hacerlo con un extern… Tengo que pensarlo. >> LATER: Siguiendo al convención de muchas otras cosas nuevas que hay en MK2, puedo poner en config.h ENABLE_KILL_SLOWLY_FLAG para controlarlo con una flag. Es lo más fácil y más mejor.
  • Acabo de mirar que HIDE_COINS sólo toca una variable de estado, así que paso de implementar estos. Quito las monedas del mapa, las pongo como decoraciones, y a tomar viento.
  • Tengo que usar LINE_OF_TEXT de todos modos porque se usa para los nombres de las pantallas. O puedo usar el módulo de nombres de pantalla y darle un nombre a cada pantalla, que eso le encanta a Anjuel.
  • El script del juego es realmente arcáico. Creo que tardo menos reescribiéndolo todo con las nuevas características, que son la leche de potentes.
  • No sé si está definido que fanty y lineales quiten diferente vida. En concreto, 12 fanty y 9 los normales.

No me puedo demorar en trasladar las mejoras de msc3nes a msc3. Creo que será lo primerísimo que haga. Luego intentaré generar el mapa completo para el nuevo formato.

~~

Para generar el nuevo mapa, partiré del .map original y haré un pequeño programilla en freeBASIC que me haga las adaptaciones pertinentes. Las apunto aquí:

  • Son 30 pantallas (15×2).
  • En la fila de arriba, tiles1 = tiles0.
  • En la fila de abajo, tiles1 = tiles0 + 32.
  • En cualquier pantalla, si tiles0 = 13, tiles1 = 0, y sacar archivo cruces.spt con las cruces como decoraciones.

Sobre el archivo generado pintaré las decoraciones en mappy según lo que lea en el script. No son demasiadas.

Nah, eso es de mindundis. Voy a meter las decoraciones automáticamente parseando el script. Con dos cojones, como debe ser. Trabajo manual, trabajo manual. Mi ojete moreno.

~~

Hecho. Voy a hacer los cambios necesarios en msc3, a saber (repito lo escrito con pepito y su enorme pito): ENABLE/DISABLE_TYPE_6. Por cierto, PLAYER_GETS_COIN existe, es (MAP_W*MAP_H*2 + 4).

ENABLE/DISABLE_TYPE_6 funcionará si en config.h definimos TYPE_6_NUMBABLE… Qué coño, no, joder, que soy farfolla.

¡Se hace un define TYPE_6_NUMB_ON_FLAG y se controla con un puto flag! Lo que tengo que hacer ahora es meter estas cosas en el motor:

- ENABLE_KILL_SLOWLY 		[X]
- KILL_SLOWLY_ON_FLAG n 	[X]
- KILL_SLOWLY_GAUGE 		[X]
- KILL_SLOWLY_FRAMES		[X]
- PATROLLERS_HIT n 		[ ]
- FANTIES_NUMB_ON_FLAG 		[x]
- FANTIES_HIT n 		[ ]

O sea, 0 cambios en msc3, y esos pequeños cambios en el motor. Vamos al lío, pero ahora voy a comer alguna mierda. En sentido figurado, se entiende.

~~

Cómo funciona lo del KILL_SLOWLY, en palabras: Si se detecta que el centro del jugador está en una zona de las que matan, se decrementa cada X frames un contador. Cada vez que se decremente el contador suena un sonido. Cuando el contador llega a 0, se quita vida. Mientras te quita vida, suena un beep cada 8 frames.

~~

Lo que menos problema parecía que iba a dar es lo que me está quebrando la cabeza: PATROLLERS_HIT / FANTIES_HIT / XXX_HIT. Tengo centralizadas las muertes y las colisiones. A ver cómo me las ingenio para integrar esto.

Voy a dejarlo un rato mientras pienso.

IDEA: Cambiar kill_player (sonido) por kill_player (sonido, amount) y tal. La putada es que eso gasta bytes sí o sí aunque no estemos usando diferentes cantidades :-/

Tengo que pensar algo mejor. Está claro que los juegos con vidas y los juegos con energía son dos bestias diferentes. Llevo años tratándolos igual, pero está claro que cuando las vidas bajan de uno en uno el código siempre es más sencillo.

Mira, ¿sabes qué te digo? Lo pongo estándar. Si algún día me veo apurado y puedo optimizar esto de forma custom, lo haré.

Joder, es que no hay que ser más papista que el papa.

~~

Creo que lo he resuelto. Al final he hecho una detección penca dentro de la rutina de kill_player, que sigue tomando un solo parámetro… Luego habrá que ver si esto funciona o la he peío. Dentro de un rato probaré a configurar y compilar, a ver qué sale.

~

Languidecewwwwwwr. Joer, tengo que dormir más o moriré joven.

~

He estado un rato dándole a la compilación. En el proceso he arreglado varias patazas que metí en los cambios para la 0.90 (key to time). Cuando termine este proyecto haré un merge.

Ahora se queda aún a un paso del éxito. Tengo que revisar cosas. Me dice que no encuentra una variable que defino poco antes.. Me temo que va a haber #ifdefs mal balanceados. Pero es que hoy estoy demasiado cansado para seguir.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s