Ghost & Goblins para MSX; la última maravilla que nos faltaba por ver

Disfruta con las capturas exclusivas del juego

Que en su tiempo Ghost & Goblins no llegara al MSX fue una decepción tremenda entre los aficionados del estándar japonés, máxime cuando sí que fue publicado en otros microordenadores como Spectrum o MSX, aunque el resultado fuera algo irregular. Más adelante, Amusement Factory realizó una conversión no oficial a partir del juego para Spectrum que no contentó del todo a los fans de las andanzas de Sir Arthur, pero parece que el trabajo de Assembler y su equipo va a romper la maldición ofreciendo la mejor versión posible del clásico arcadiano en un micro de 8 bits.

La gesta es imponente, y por ende no es extraño que Antonio J. Estrada, más conocido en el mundillo como Assembler, lleve con la manta liada en la cabeza unos años. Pero la cosa parece que está a puntito de caramelo, y tras el anuncio del diseñador en su cuenta oficial de Twitter y la aparición  junto a la KrakenGraph de MSXCalamar en la pasada RU MSX celebrada en Sevilla de su juego, el G&G definitivo está a puntito de asomar la patita, y nada mejor que ponerse a derrotar fantasmas a las puertas de Halloween...

En la RU Sevillana de este pasado fin de semana se pudo ver nuestra KrakenGraph en funcionamiento junto al juego G&G. https://t.co/Y4PKDdLwnT— MSXCalamar (@MSXCalamar) 16 de octubre de 2018

El propio Antonio nos cuenta, de su puño y letra, como ha conseguido obtener este pequeño gran prodigio de la técnica, apoyado en un principio por la versión superior de los MSX y la expansora V9990, pero también con el objetivo de lograr un producto que corra en un ordenador Z80 normal.
¿Cómo surgió el proyecto?
Acababa de terminar la versión de cartucho de M-Tanks y me puse a hacer pruebas de scroll multidireccional. Para ello, cogí el mapa la primera fase del Turrican II de Spectrum y monté una pequeña demo que mostraba el scroll a saltos en un MSX1, y con scroll suave en MSX2 y superiores, como podemos ver en juegos como el Space Mambow.
Con esa base me planteé hacer alguna conversión de recreativa y pensé en Ghost & Goblins, y Guantxip, que me ya me echó una mano con algunos gráficos del M-Tanks, preparó los gráficos de todas las fases para screen 2 (modo MSX1 y compatible con screen 4 en MSX2 y superiores).
Ahí fue cuando surgió la idea de utilizar el la GFX9000, que por aquel entonces era la única tarjeta con el chip V9990 (todavía no habían salido a la venta clones como la Powergraph o la KrakenGraph). Inicialmente la idea fue hacer un solo juego que se adaptara a la máquina, pero al poco tiempo comprobé que aunque imposible no era, sí que era bastante complicado hacerlo, porque debido a las limitaciones de los chips estándar de los MSX respecto al V9990, habría que cortar gráficos y poses, lo que complicaba la lógica de cada personaje, así que nos centramos en una versión única para MSX-TurboR con V9990.

Ya que nos centramos en esa opción, Guantxip me dijo que tenía preparados los gráficos para un juego con esa misma configuración, y como en esas fechas disponía de bastante tiempo libre, me lancé a por ellos, simultáneamente. El motor era compartido, y solo se diferenciaban los datos y el código.
El problema de ese otro juego, LoSabenAkel, es en realidad siete juegos diferentes en uno. Cada fase se basa en otra fase de otros juegos, con una historia que las une entre ellas. Tendremos fases de juegos muy conocidos como Knightmare, Kiki KaiKai, un juego de naves... Eso complicaba mucho el desarrollo porque había que empezar cada fase de cero. Ghost & Goblins es grande, pero una vez desarrollado un enemigo, ya está hecho para cada fase en la que salga.
Llegó un momento, una vez que nacieron mis hijos en el que vi que no podía acabar los dos, al menos de golpe, así que decidimos decantarnos por "el sencillo". Y me centré en el Ghost & Goblins, dejando aparcado LoSabenAkel. Esperamos retomarlo más adelante, cuando ya esté completamente superado el desarrollo del primero, y dejando un periodo de descanso por medio.

Ghost 'n Goblins funcionando en un z80 con turbo. Imagen: Assembler

¿Cuál ha sido tu forma de trabajar?
Los gráficos están sacados de capturas de la máquina, de vgmaps.com, y los sprites, de spriters-resource.com. Esa es la base, pero luego tiene mucho trabajo detrás para adaptarlos a las "limitaciones" del V9990: Los mapas originales usan unos 64 colores, así que reduje manualmente los colores y separé las imágenes en dos partes, una con 16 colores y otra con 15, una para cada plano. Al mover los planos a la vez tenemos los 31 colores.

Todos los sprites de los enemigos usan una misma paleta, aunque en algunos puntos se modifica en tiempo real porque 16 colores para todos los enemigos dejaba algunos demasiado planos. Por ejemplo los orcos de la parte de los edificios de la fase 2 tienen muchos tonos de marrón. Tengo que utilizar los verdes de la planta que ya no aparece en ese punto para los marrones que me faltan. Y luego Sir Arthur usa la cuarta paleta para todas sus poses (con armadura, en calzoncillos, muerto y convertido en rana).
La fase 3 va dividida en 2 porque el mapa de esa pantalla es enorme, y temía al principio que el juego ocupara mucho y aunque al final no ha hecho falta , ya se quedó así distribuido. Por eso esta versión tiene 8 fases en lugar de 7.

Esa es la distribución de los sprites para la fase 6 (5 del juego original). Quise empaquetar todos los enemigos para utilizar solo 256 sprites, pero las poses del diablo rojo ya me hicieron ver que no iba a ser posible. Así que finalmente los sprites de los enemigos complejos se van copiando, a un hueco específico cada vez que cambia la pose.

Una parte complicada del juego es el comportamiento de los enemigos, algunos de ellos son realmente complejos como el Diablo Rojo, que fue el que más costó de implementar. Tuve que tirar de vídeos, partidas mías, comentarios de jugadores expertos y documentos en Internet para conocer la lógica del bicho
Inicialmente jugaba mientras grababa en vídeo la partida para intentar interpretar cada movimiento. Poco después descubrí la opción de cheats del MAME y ahí fue cuando pude sacar tranquilamente todos los movimientos. Algunos están copiados al píxel, frame a frame.

Todo el trabajo lo hago en el PC: retoque gráfico, edición y ensamblado y la mayoría de las pruebas. Para convertir los datos de los sprites y mapas he programado un par de herramientas.  Una sirve para identificar los tiles del mapa que sirven para acciones especiales como suelos, escaleras, paredes, y además genera los gráficos de los tiles y la estructura de los mapas. La otra herramienta sirve para indicar la distribución de los sprites en cada fase, y empaquetar todos los bloques de datos en la ROM.

En la imagen se puede ver uno de los planos de la fase 2, con los tiles marcados por tipos de bloque: los azules son paredes y suelo y los naranjas las escaleras. Los tiles blancos y verdes son para el fondo. Están marcados con color porque se han pasado de los 512 tiles de los dos primeros bloques.

Otra herramienta que utilizo es el emulador OpenMSX y su depurador por la posibilidad de retroceder la emulación para poder localizar un fallo antes de que se produzca, y porque, actualmente es el único que emula el V9990.
Ya implementados casi todos los enemigos, y en una de las RU de Sevilla a la que fui me comentaron que los enemigos aunque lo parece, no aparecen de forma aleatoria, sino que siguen un patrón. Luego Fernando García, de BitVision me lo confirmó durante la fase de betatesting. Por ejemplo, las brujas del bosque de la fase 1 aparecen según una secuencia en tres bloques: al principio aparecen cuatro brujas siempre desde la derecha, con un orden. Cuando avanzas aparecen también desde la derecha, pero hay más puntos de salida, y al final ya salen tanto desde el fondo, como desde atrás. La gente que ha jugado mucho al juego se saben las secuencias lo que simplifica (un poco) el juego.

TurboR y Z80
En el inicio le dimos muchas vueltas tanto al soporte como al chip de sonido que usaríamos. Íbamos a sacarlo en formato disco cuando no teníamos claro el chip, pero al decantarnos por el SCC (gracias al Trilotracker), pasamos al formato cartucho porque ya que íbamos a pillar un slot para el SCC, era una tontería tener el juego en disco. Al hacer el cambio me di cuenta de algo curioso, que ya comentó ARTRAG en el MRC mientras desarrollaba una demo tipo Wolfenstein para TurboR: el TurboR leyendo de ROM no aprovecha la velocidad del TurboR, siendo incluso más lento que el Z80. Así que tuve que modificar toda la lógica del juego para copiar tanto los datos como el código para ejecutarse desde RAM. Por eso la versión de TurboR necesita 256KB mínimo para funcionar, aunque esté trabajando en una ROM de 8MB.

En agosto de 2018 acabé la versión para TurboR, y empecé a optimizar para intentar hacer una versión que fuera correctamente en un Z80 a 3.58Mhz. Ya lo intenté anteriormente, pero solo ahora, con la versión para R800 (y Z80 con turbo) acabada, me voy a atrever a hacer una versión del juego separada, con la misma base para el Z80 original, total, hay sitio de sobra en la ROM. Esta versión de Z80 correrá a 30 fps porque, aunque he conseguido optimizar bastante el código y en muchas partes se consigue ejecutar a 60 fps, en otros sitios con muchos enemigos se ralentiza. Como es más importante la fluidez del juego, voy a bajar la velocidad, adaptando los movimientos para que la experiencia sea óptima.
Ahora ya controlo bastante el funcionamiento del chip, pero al principio andaba muy perdido: preguntaba en el MRC y poca gente contestaba, hasta que encontré el canal de IRC #msxdev. Allí GuyveR800 y Bifi me resolvieron muchas dudas. Entre su ayuda y la librería del TeamBomba saqué la información necesaria para empezar a ver gráficos moviéndose alegremente por la pantalla.
La idea final es sacarlo en formato cartucho con SCC con las dos versiones integradas (R800/Z80), seleccionable en el arranque, y quizás mas adelante sacar la versión digital, o en el mismo momento, o no sacarlo, no lo tengo claro aún.