«Quería hacer desde el principio algo que sacase el mayor partido posible a las capacidades del CPC». Entrevista a Paul Kooistra "Axelay"

A pesar de su más que demostrada solvencia como máquina, la serie Amstrad CPC sigue a día de hoy arrastrando una serie de leyendas urbanas que, a base de ser repetidas hasta la saciedad por profanos en la plataforma, han calado en el imaginario colectivo incluso entre aficionados del sistema. A pesar de contar ya durante la época comercial con grandes títulos que nos hicieron vislumbrar un ápice del poder contenido en la máquina, es en los últimos lustros cuándo algunos desarrolladores han logrado, a fuerza de darnos geniales títulos haciendo un uso correcto de las capacidades del CPC, demostrar lo infundado de esas leyendas urbanas. Hoy tenemos el honor de charlar con una de las personas que más nos ha dejado con la boca abierta con sus creaciones: Axelay.

ENGLISH INTERVIEW AFTER THE SPANISH TEXT

Antes de nada, permítenos darte las gracias por aceptar esta entrevista. No todos los días tenemos la oportunidad de hablar con uno de los programadores de Amstrad CPC con más talento. Vamos a conocerte un poco más. ¿A qué edad comienza tu interés en la tecnología?

Gracias por tus amables palabras. Supongo que mi interés en la tecnología empezó cuando tuvimos el Amstrad CPC 464.

¿Cuáles fueron las primeras máquinas que entraron en tu hogar? ¿Cuándo y por qué entró el Amstrad CPC en tu vida?

No estoy seguro cuándo, pero la primera máquina fue una consola Hanimax. Mis padres nos compraron el Amstrad CPC 464 a mi y a mi hermano algo más tarde; creo que a comienzos de 1986. Me parece que lo compraron porque habían empezado a ver en los medios cierto debate sobre la importancia de la informática para el futuro.

Si no estoy equivocado, creciste y vives en Australia. ¿Cómo era ser usuario de Amstrad tan lejos de Europa? ¿Tuviste problemas para encontrar juegos, revistas o libros o era quizás tan difícil encontrarlo como para otras máquinas como el C64 o el ZX Spectrum?

Crecí en un pueblo rural dónde había disponibles juegos, revistas, libros y máquinas, aunque podías encontrar un surtido mayor en tiendas más grandes o más especializadas en las ciudades o a través de venta por catálogo. En realidad dónde yo vivía no había mucho material para las otras plataformas de 8 bits, excepto quizás un poco para el C64, aunque en la ciudad la base de usuarios de C64 parecía ser mayor que la de CPC.

La máquina en la que todo el mundo quiere estar

 

Solemos ver habitualmente que los desarrolladores de juegos soléis estar influenciados en  vuestras primeras creaciones por los títulos que jugasteis siendo niños. ¿Cuáles eran tus  favoritos?

Había un par de juegos al principio, con la Hanimax, llamados Laser Attack & Spiders Web. En el CPC no creo que pueda abreviar así que simplemente haré una lista de los que recuerdo haber disfrutado más jugando: Highway Encounter, Star Avenger, Satellite Warrior, Battle of Britain, Codename MAT, Dark Star, Mindshadow, Killapede, Thrust, Kane, Light Force, 5th Axis, Ghosts'n'Goblins, Commando, Barbarian, Renegade, Gryzor, Robocop, The Sentinel, Exolon, Cybernoid, Trantor, Captain Blood, Laser Squad, Dark Fusion, Into the Eagles Nest, ATF, Bloodwych, P-47. Pero esa lista deja fuera algunos títulos que encuentro memorables o que admiraba pero que no pude disfrutar por un motivo u otro; y ya que has mencionado influencias, me extenderé un poco sobre Sorcery+.

Conseguimos una DDI-1 [disquetera externa] para nuestro 464 desde casi el principio y pillamos un par de discos de la serie Amsoft Oro. Uno de ellos era Sorcery+ y, a pesar de que no disfruté tanto de las mecánicas jugables por mucho que lo intentase, me encantaba todo lo demás del juego. El uso del modo 0 era el mejor que había visto hasta la fecha con diferencia; el movimiento era rápido y suave. Pensé que el cambio de modo para el marcador se veía genial, y la manera en la que accedía rápidamente a disco en cada habitación me parecía que tenía mucho potencial para explotar en el futuro.

Así que Sorcery+ se me quedó grabado como un gran ejemplo de juego hecho para el CPC, que parecía casar perfectamente con la plataforma. A pesar de que no me gustan los juegos tipo Sorcery, siempre he aspirado a realizar juegos que se sientan como sentí yo ese juego.

Sorcery+

 

En algún momento decides que no es suficiente con disfrutar jugando y quieres hacer tus propios juegos. ¿Qué te motivó a ello?

Desde el primer momento tuve interés en aprender cómo hacer que el CPC hiciera cosas, y recuerdo que no tuvimos juegos en los primeros días, así que lo primero que hice fue leerme el manual. Era mi primer encuentro con un ordenador doméstico por lo que empezaba desde cero y estuve un tiempo aprendiendo sobre esta nueva tecnología y sobre el BASIC; así que pasó un tiempo antes de que empezase a escribir mis propios programas en vez de aprender de libros y revistas. No recuerdo que tuviera otra meta por entonces más allá de hacer mi propio juego.

Tycon, creado por Axelay con Laser BASIC compilado

 

En aquellas fechas no podíamos contar con Internet para nuestra búsqueda de información *risas*. ¿De qué recursos disponías para aprender a programar una vez decidiste que querías hacer tu propio juego? ¿Cuáles eran tus libros y revistas favoritos para aprender a programar?

Tras acabar con el manual del 464 cambié a libros y revistas. Me gustaba la edición australiana de CWTA por encima del resto de revistas ya que parecía ser la que traía la mayor cantidad de artículos sobre BASIC y listados de juegos de los que podría aprender. 

También recuerdo dos libros de los que aprendí mucho: The Amstrad Users Omnibus, de Martin Fairbanks, y Games and Graphics Programming on the Amstrad Computers CPC 464, 664 and 6128, de Steve Colwill. Me gustaban ya que profundizaban algo más en diseño de videojuegos y dividían las funciones de un juego en tareas en vez de poner simplemente un listado para teclear como los que encontraba en las revistas.

Entonces, al final de mi época con el BASIC, conseguí el Laser BASIC y su compilador e hice mi primer juego. Fue en 1988. Laser BASIC me presentó algunas ideas que acabarían mostrándose útiles para dar el salto a ensamblador, como diferentes enfoques al manejo de sprites y almacenar datos de manera más eficiente. 

Tras eso, aprendí ensamblador con el libro Master Machine Code on your CPC 464 & 664, de Jeff Naylor y Diane Rogers. ¡Posiblemente elegí ese libro porque traía en la portada un 464 con el Sorcery! También usé como referencia el Amstrad Whole Memory Guide y The Ins & Outs of the Amstrad, ambos de Don Thomasson, así como todo lo que pude pillar en ocasionales artículos de revista.

El cuarto modo. Amstrad User, enero de 1986

 

¿Aprendiste algún truco de programación en esa época pre-Internet que todavía utilices a día de hoy?

Leí en una revista sobre cadenas LDI, que siempre son útiles, y también había un montón de artículos o listados con información sobre los diferentes registros del CRTC. 

Había también un artículo en la ACU, El cuarto modo, por Chris Wood, sobre lo que él llamaba el modo 3, describiendo como el doble buffer del Tank Busters utilizaba cuidadosamente la selección de color. Eso me hizo entender como funcionaban los gráficos de juegos como el Ghosts'n'Goblins, y desde entonces siempre he tenido en mente pensar en lo que podría potencialmente hacer con diferentes variantes de esa idea, y de hecho algunos de mis juegos lo usan de una forma u otra.

Star Sabre Zero

 

Cuéntanos un poco sobre Star Sabre Zero. ¿Cuál es la historia detrás? ¿Cómo fue su desarrollo? ¿Qué recuerdas sobre el diseño del juego?

Quería hacer un arcade y me gustaban los shooters; la mayoría de ejemplos del género que pude encontrar en el CPC finales de los ochenta se quedaban cortos respecto a cómo se jugaban. 

No hubo mucho diseño en él; fue el resultado de coger todas las ideas que me gustaban de otros juegos como me fue posible. El desarrollo fue lento porque solo podía tocar el CPC durante las vacaciones entre semestres. Mi principal objetivo era hacerlo correr a lo que yo consideraba un framerate aceptable para ese tipo de juegos, así que apunté a los 25 fps.

¿Cual era tu equipo de desarrollo por entonces?

Ya teníamos la DDI-1, así que cuando abandoné el Laser BASIC compré una expansión de memoria de 64K para poder usar el Advance Art Studio para los gráficos. Usaba una versión en disco del Maxam [Ensamblador] para programar.

Fable: shooter plataformero previo a Star Sabre Zero

Star Sabre Zero es el juego más antiguo con el que te asociamos, pero parece demasiado bueno para ser tu primer intento en la programación de videojuegos. ¿Empezaste otros proyectos antes que ese?

Hice un intento en ensamblador previo a Star Sabre 0: una especie de shooter plataformero. Estaba escrito usando inicialmente un scroll software, seguido de una breve prueba pantalla a pantalla, pero lo abandoné ya que el scroll bajaba de 17 fps con solo la rutina de scroll y el sprite del personaje. Yo quería hacer desde el principio algo que sacase el mayor partido posible a las capacidades del CPC, así que me di cuenta que tenía que darle una vuelta y me di cuenta que no estaba lo suficientemente motivado como para invertir más tiempo en algo cuyos cimientos no eran sólidos.

Ese juego de plataformas no pasó más allá de un menú y tabla de récords junto al código para mostrar el fondo y el sprite del personaje así que, en ese sentido, Star Sabre 0 fue mi primer intento en ensamblador que desarrollé que tenía algún tipo de funcionalidad o lógica detrás, aunque me traje ahí un par de lecciones que aprendí en ese primer proyecto.

Aparte de eso, estaba solo mi primer y único juego hecho en BASIC, que no era más que un juego de laberintos y recoger objetos pantalla a pantalla creado con Laser BASIC compilado, y en algún momento trabajé muy brevemente en otra idea para un shooter horizontal. Este usaba el registro 3 del CRTC para scrollear la pantalla, pero solo tenía el scroll R3, un panel estático y algunas estrellas parallax, así que no era mucho más que una demo técnica, y no recuerdo exactamente cuando trabajé en ella respecto al resto de proyectos.

Cataclysm: demo técnica de scroll R3

 

Por desgracia, la máquina muere comercialmente antes de que pudieras publicarlo. ¿Cómo fueron esos tiempos en los que veías que tu querida máquina estaba llegando a su final? ¿Qué hiciste entre esta muerte comercial y el redescubrimiento del CPC?

Para mí, el CPC tuvo una muerte lenta mucho antes de que los juegos dejasen de aparecer, así que su muerte definitiva fue más bien como una nota a pie de página. Me dí cuenta rápido que los juegos son una forma de artesanía y lo que yo quería ver en ellos era que me trasmitieran la sensación de que los que lo habían desarrollado también lo entendían como un arte y tenían respeto por los compradores. Pero la mayoría de juegos que conseguía con origen de Reino Unido cada vez me llamaban menos la atención y en menor numero incluso a finales de los 80. 

Para cuando el CPC murió comercialmente, el Amiga ya estaba ahí, así que elegí el camino de las consolas como máquina de juegos, ya que no existía un equivalente de bajo coste al Amiga.

Vuelves al CPC relativamente pronto comparado con otra gente que hace juegos a día de hoy. ¿Qué te hizo volver al CPC?

Había unas cuantas cosas diferentes que me hicieron pensar sobre ello a comienzos de los 2000 que al final me acabaron llevando. Los juegos comerciales para las plataformas actuales en ese momento fueron tomando una dirección diferente a lo que a mi me interesaba. Descubrí que había una pequeña comunidad de usuarios de CPC activa online que me hizo pensar en mi shooter para CPC inacabado. Después leí en Retrogamer sobre editores retro que estaban empezando a aparecer y que lanzaban versiones físicas de nuevos juegos para 8 bits, lo que me pareció una idea interesante.

Star Sabre

 

Unos 15 años después de comenzar a trabajar en Star Sabre Zero, retomas el proyecto para hacer la versión definitiva. Tengo mucha curiosidad: ¿te fue difícil volver a trabajar con tu viejo código?

Me di cuenta que volver a programar en Z80 no era difícil; tras un poco de práctica todo se volvió muy familiar y conocido. Aunque serían más bien 10 años desde que usé por última vez un ensamblador, ya que era 2004 cuando volví a empezar a trabajar en ello.

Aunque no tenía disponible el código fuente en disco en ese momento, todavía tenía mi libreta con el código que había escrito, y todavía me acordaba de un montón de elementos de diseño e inspiraciones y algunos de los límites de diseño en los que había trabajado.

Diez años es un montón de tiempo. Hemos visto nacer nuevas tecnologías y nuevas formas de comunicación. Si se me permite la pregunta: ¿qué aprendiste sobre programación en estos 10 años que pasaron entre Star Sabre Zero y Star Sabre CPC?  

¡Cuando empecé a trabajar en Star Sabre, la única "programación" que había hecho en casa desde la última vez que había usado el CPC fue en el juego de PlayStation, Carnage Heart! :) Así que, básicamente, seguí con la programación de CPC por dónde lo había dejado. Una vez empecé con Star Sabre, mi foco inicial fue simplemente desarrollar las mejores rutinas que se me ocurriesen para cada tarea, tomándome bastantes descansos durante el desarrollo del proyecto. Volví a trabajar y reescribí varias de las rutinas principales unas cuantas veces.

Creo que lo único que tomé de Internet durante su desarrollo y que acabase en el juego fue una rutina de split raster de Kevin Thacker que lidera el efecto de scroll raster durante el juego, y pregunté sobre deshabilitar el firmware en CPCzone cerca del final del proyecto, cuando me quedé sin memoria y aún necesitaba más espacio.

Maxam Assembler

 

Por supuesto, ahora tenías a mano nuevos y más potentes recursos. ¿Pudiste importar fácilmente tu proyecto desde tu antiguo sistema a un entorno de desarrollo nuevo y más moderno?

Apenas usé herramientas modernas para la versión inicial de 64k, por decirlo de alguna manera. Sólo usé un editor de niveles que programé en Visual Basic. No tenía acceso a un CPC real en ese momento, así que lo desarrollé en un PC, sí, pero usé Maxam ejecutado en un CPC emulado con Caprice. No obstante, me di el lujo esta vez de usar la versión ROM del Maxam.

Mi PC no era capaz de ejecutar el Caprice más rápido que a velocidad 100% normal del CPC así que, a medida que el proyecto fue creciendo, tenía ensamblado "a tiempo real" que tomaba más de 5 minutos al final. Si Caprice tenía alguna función para desarrolladores, yo no las conocía, así que hacía el debugging tal y como lo hacía en un CPC real, lo que implicaba cosas como escribir valores de memoria en el marcador de puntos.

Los gráficos los hice también en Advanced Art Studio y usé herramientas hechas en BASIC para prepararlos para usar en el juego. Para objetos más grandes usaría papel milimetrado en primer lugar para trabajar las proporciones, y después hice un sistema de compresión simple para los carácteres grandes del logo y los comprimí manualmente en papel tras hacer que el BASIC imprimiera la columna de bytes.

Quizás suena extraño o ineficiente, pero era simplemente un ejercicio de nostalgia.

Fue solo tras el lanzamiento de la versión de 64K, cuando Targhan se ofreció a hacerme la música y sugirió que usase WinAPE para desarrollar, que pasé a algo moderno.

Edición física de Psytronik

Star Sabre fue publicado por Psytronik. De hecho, publicarían en el futuro más trabajos tuyos. ¿Qué historia hay tras esta colaboración?

Simplemente me gustaba la idea de tener versiones físicas de mis juegos, como me imaginaba que sería si hubiese podido en su momento cuando empecé por primera vez a hacerlos.

Eres muy conocido por tus shooters. De hecho, tu nick (Axelay) debería darnos una pista sobre tus intereses en videojuegos :-) Los shooters son, de hecho, algunos de los juegos más complejos de diseñar debido a todos los componentes que están envueltos normalmente (oleadas de enemigos, power ups, etc). ¿Cuál es el secreto detrás de tus habilidades de diseño de videojuegos?

No creo que la mayoría de juegos que he hecho sean complejos. Si acaso, desde Star Sabre he intentado mantener el diseño de los juegos simple para hacer que sean más fáciles de calibrar o ajustar la jugabilidad a mi gusto. Es algo que siento que no hice bien en Star Sabre, así que he intentado enfocarme más en ese campo en los siguientes juegos. También, el diseño ha sido un proceso colaborativo desde que trabajo con Rexbeng.

Dead on Time

 

En Dead on Time encontramos una interesante vuelta de tuerca a las típicas mecánicas jugables de un juego de naves. ¿Cómo se te ocurrió la idea?

Tomé prestado de unas cuantas fuentes mientras pensaba como sería el juego y me lo pasé bien mezclando diferentes ideas, así que lo siento si la respuesta es un poco larga.

En primer lugar, en proyectos previos había puesto sprites pequeños, como balas y pequeños objetos, integrados como código para tener más velocidad, y empecé a pensar lo que se podría lograr en un juego que tuviera todos los sprites almacenados de esa manera.

Entonces, justo cuando estaba acabando de trabajar en Star Sabre 128K, Colin Hogg apareció por CPCWiki para saludar y mencionó que, entre otras cosas, había trabajado en un juego llamado Bio Spheres, que no conocía de antes. Era un juego de CPC razonablemente rápido, con un montón de sprites pequeños en pantalla, así que empecé a pensar en hacer algo similar.

Ya que sabía que los sprites iban a ocupar un montón de memoria, llegué a la conclusión que debería diseñar algo sin fondos. Por entonces había estado jugando recientemente a Geometry Wars, así que ese se convirtió en mi concepto de inicio en sentido amplio.

Quería evitar jefes para reducir en lógica y en frames de animación, y había jugado un montón a Sanvein en la Playstation, así que tomé de ahí la idea de usar el tiempo para generarle presión al jugador.

Entonces, pensando en el limitado número de sprites que entrarían, recordé el uso del color en Ikagura. Eso parecía algo que podría funcionar bien con los sprites compilados, con partes de los sprites pudiendo cambiar de color cambiando simplemente los valores de unos pocos registros precargados, así que me puse a pensar como integrar la parte de los colores en las mecánicas de juego.

Finalmente, unos años antes me había encantado la longitud de las puntuaciones obtenidas en Mars Matrix, y pensé que sería divertido inventar un sistema de puntuación para Dead on Time que soportara puntuaciones tan grandes.

Sub Hunter

 

Eres muy conocido por emplear buenas técnicas de programación en el Amstrad. En Sub Hunter encontramos un nuevo ejemplo de juego que no solo es divertido, sino que además muestra un muy buen nivel técnico. ¿Qué trucos de programación usaste en este?

Este empezó cuando Kevin Thacker mencionó una técnica usando la pila para producir un scroll de bloques repetidos, que creo que fue usado en el scroll del suelo en Operation Wolf. Pensé que podría trastear con esa idea y ver si podía hacer algo interesante con ella.

No mucho antes de eso, mientras debatíamos la publicación de Star Sabre y Dead on Time con Psytronik, Kenz me había preguntado si estaría interesado en convertir alguno de sus juegos de C64. Sub Hunter era uno de los sugeridos y tras experimentar un poco con ese tipo de scroll, pensé que podía ser un buen candidato para ese juego.

Respecto a otras técnicas empleadas, incluye doble buffer por hardware, deshabilitar las interrupciones permitiendo al puntero de la pila ser usado para procesar listas y tablas, tablas de datos alineadas a la página de memoria, tablas de máscaras de sprites y ahorra memoria y ciclos de procesador usando código para generar sprites prerrotados y tiles de fondo en un buffer temporal antes de cada nivel.

Super Edge Grinder

 

Cada trabajo parece mostrar una buena progresión tanto en diseño como en programación. Edge Grinder y Super Edge Grinder son buenos ejemplos de ello. Por cierto, para los despistados: ¿qué diferencias hay entre ambos juegos?

Super Edge Grinder añade un jefe al final de la pantalla y tiene gráficos de Rexbeng. Hay otras pequeñas diferencias técnicas, pero esas dos son las principales.

Tengo que añadir, no obstante, que tanto Edge Grinder como Sub Hunter eran conversiones de juegos existentes de C64, así que no estuve involucrado en el diseño.

Ya habías desarrollado unos cuantos buenos shooters, pero aún quedaba margen para la sorpresa con Relentless. ¿Qué nos puedes contar sobre este desarrollo? ¿Qué decisiones de diseño tomaste para poder lograr un juego tan impresionante?

Con Relentless quería lograr un juego que hiciera algunas cosas que no pude hacer en Star Sabre, así que quería que corriese a 50 fps, usase una pantalla lo más cercana en tamaño al estándar, fondo de scroll continuo y 1 píxel y sprites que se pudieran mover sobre los fondos.

Inicialmente lo estaba desarrollando siguiendo las lineas comunes de un shooter con niveles, jefes y enemigos específicos de cada pantalla, pero tuve que dejarlo a un lado para centrarme en Corsair. No obstante, llegó la competición de juegos en ROM de CPCWiki y Rexbeng sugirió que usásemos el prototipo de Relentless, así que cambié el diseño a algo más sencillo para que entrase en una ROM de 16KB. Para ello usé una selección de oleadas aleatorias con algo de escala respecto a su dificultad, y fondos hechos con caracteres, tiles y meta-tiles para reducir el tamaño de datos requerido para las zonas.

Relentless

 

Para nosotros, simples mortales, el scroll de ese juego es magia negra. ¿Qué secretos hay detrás de ese increíble scroll?

Usa el registro 3 del CRTC para hacer scroll por hardware, el cual mueve la pantalla medio carácter, o dos píxeles en modo 0, para dar el efecto de scroll horizontal, y lo combino con un doble buffer por hardware, el cual tiene uno de los buffers desplazado un píxel para generar el scroll al píxel.

Relentless es usado frecuentemente como ejemplo del verdadero potencial del Amstrad CPC. Antes de Relentless, la mayoría de nosotros usaríamos posiblemente una demo de Vanity o del Batman Group para mostrar las verdaderas capacidades del CPC. Tras Relentless, la gente puede usar un juego propiamente dicho, con mecánicas jugables, enemigos, interacción, etc. Por supuesto, en una demo no tienes que tener en cuenta cosas como la entrada de teclado, detección de colisiones, etc. ¿Nos puedes explicar con que limitaciones te encuentras al hacer un juego comparado con una demo?

En realidad no estoy en posición de comparar con el desarrollo de una demo. A mi me atrae más hacer juegos por que encuentro muy interesante equilibrar todos los factores en consideración como la interacción del personaje, manejo de objetos, actualizaciones visuales, etc, mientras a la vez intento mantener una tasa de frames predeterminada.

Megablasters - Escape from Castle in the Clouds

 

Colaboras con el legendario Rexbeng. ¿Cómo comenzó esa colaboración? 

Empezó cuando Rexbeng me preguntó sobre poner algunos gráficos nuevos que había hecho para Edge Grinder y yo me ofrecí para ayudarle.

Rexbeng lleva mucho tiempo con nosotros en la escena. Probablemente obtuvo su fama gracias a sus maravillosos gráficos para Megablasters, un juego que mantiene un nivel legendario entre los fans. Por supuesto, es natural rendirle homenaje por su 20 aniversario. ¿Cómo fue el desarrollo de Megablasters: Escape from the Castle in the Clouds?

Al principio un poco preocupante debido a la reputación que tiene como uno de los últimos grandes juegos para el CPC, y hasta ese momento yo no había hecho nada parecido. Pero a medida que el desarrrollo progresó, fui convenciendome de que se ejecutaba y se jugaba lo suficientemente bien como para ser un homenaje decente a su 20 aniversario, así que me tranquilicé por esa parte.

Respecto al diseño del juego, fue cosa de Rexbeng. Ya que era el aniversario de un juego en el que Rexbeng trabajó originalmente, intenté implementar lo que él propuso al máximo posible. No recuerdo que hubiera muchas cosas que fuesen problemas técnicos y les impidiese acabar dentro del juego, más allá de tardar más de lo esperado.

Dragon Attack

 

En 2016 hiciste mi juego tuyo favorito: Dragon Attack. Recuerdo un hilo en CPCWiki dónde la gente estaba debatiendo cuántos sprites podrían ser manejados simultáneamente en el Amstrad, y tu llevaste el reto mucho más allá, desarrollando un juego increíble y adictivo. ¿Qué nos puedes contar sobre su desarrollo y los trucos de programación que usaste?

Todo empezó con algunos comentarios en CPCWiki en varios hilos, incluyendo uno de una persona que preguntaba si sería posible hacer un bullet hell para el CPC al que otra persona le dijo que eso era imposible :) Así que nació al experimentar con algo de código que moviese un montón de balas para ver si era posible hacer algo así que mantuviese una tasa de frames decente.

Ya había pensado en el pasado que se podrían actualizar sprites bajo interrupciones a una frecuencia mayor que la pantalla principal, para dar al jugador un control que responda mejor de lo que lo haría en un simple refresco de pantalla. Esta parecía una buena oportunidad para utilizar esa idea ya que la mayor parte de lo que se necesita mover en pantalla no tiene que hacerlo en cada refresco de pantalla, ya que haría que esos elementos fuesen demasiado rápido.

Pensé que la típica caja de colisiones que solía usar no sería de gran ayuda con tantos sprites, así que usé la propia pantalla como una especie de mapas de colisiones, haciendo que 1 de los 4 bits por píxel muestre una capa de colisiones y muestra de balas enemigas y dejando 3 bits para la capa de gráficos puros.

Corsair trainer Loading Screen

Tras dejar claro que el scroll horizontal suave no tiene secretos para ti, empiezas a trabajar en un shooter vertical. ¿Cómo se te ocurrió la idea de Corsair?

Cuando trabajaba en Star Sabre no tenía planes para hacer nada más; estaba pensado para ser un ejercicio único de nostalgia por diversión. Sin embargo, encontré el proceso mucho más divertido que jugar a juegos. Simplemente parecía absurdamente divertido el crear un pequeño mundo interactivo en Z80 :)

Mi primer pensamiento al acabar la versión 128K de Star Sabre fue completar el set y hacer un shooter estilo Dead on Time, y también un shooter vertical que por desgracia está todavía en proceso de convertirse en Corsair más de una década después, pero que es el tercer juego que comencé a hacer tras mi vuelta al CPC.

Corsair, en términos de diseño, toma como punto de inicio que tiene que ir a 50 fps, ya que no quería dar un paso atrás de lo que ya había logrado décadas antes Mission Genocide. Fue difícil fijar un diseño por qué quería tener sprites moviéndose en espacios abiertos entre elementos de fondo para maximizar la velocidad, y muchos shooters verticales usan paisajes sobre los que vuelas, así que tenía muy pocas referencias.

No obstante, en algún momento jugué un montón al Truxton, quién al menos tenía visualmente partes de espacio abierto o islas en sus fondos, así que ese fue más o menos mi punto de inicio. Los objetos que recoges en Corsair comenzaron como power ups más o menos en el estilo del Truxton, pero abandoné la idea de los power ups ya que sentía que el juego no iba a suponer un reto suficiente como para garantizar la inclusión de estas mejoras.

Corsair

 

¿Es muy diferente conseguir un scroll vertical suave comparado con el horizontal?

Hay diferentes maneras de hacer ambos y no diré que las conozco todas, pero con respecto a mis conocimientos, los scrolles verticales requieren de una mejor comprensión sobre cómo trabaja la pantalla para mantenerla estable de lo que requiere el scroll horizontal, pero más allá de eso proporciona un scroll con el que se puede trabajar directamente.

La asistencia del CRTC en el scroll horizontal es un poco más limitada, así que necesitas añadir otras técnicas para obtener el scroll suave. Hay un montón de formas diferentes  de solucionarlo, y creo que es más importante considerar que tipo de juegos quieres hacer cuando eliges tu enfoque a la hora de hacer un scroll horizontal ya que posiblemente te encontrarás algunas limitaciones o tendrá que hacer algún tipo de compromiso.

¿Qué nos puedes contar sobre el diseño de juegos? ¿Cuales son tus secretos para hacer juegos de naves que son desafiantes pero a la vez generosos según vas practicando?

No estoy seguro de tener una respuesta. Juego, hago mis teorías sobre por qué algunas cosas parecen funcionar y otras no, e intento aplicar eso a mis propios juegos. Entonces simplemente juego un montón de veces al que esté desarrollando en ese momento y voy realizando cambios en las cosas que creo que no funcionan.

¿En qué trabajas ahora mismo?

Cuando me enviaste la pregunta, Hypernoid Zero :)

Hypernoid Zero

 

De hecho nos sorprendiste con el increíble Hypernoid Zero, dónde vuelves a mostrar como hacer un juego de CPC en condiciones. ¿Qué nos puedes contar sobre su desarrollo?

Desde que volví a programar para el CPC son varias las veces que he pensado en hacer un juego de estilo Cybernoid, y así se lo hice saber un par de veces a Rexbeng. En una de esas veces, cogió un screenshot de Cybernoid e hizo un mockup de como podría ser. Un par de años después de ese mockup, yo andaba con problemas para hacer funcionar un par de cosas en Corsair, así que, a modo de pausa, cogí esos gráficos del mockup y monté una pequeña demo técnica con el jugador moviéndose por la pantalla, con disparos y un satélite orbitando alrededor del personaje.

Lo compartí con Rexbeng y empezamos a hablar de cómo podríamos hacerlo interesante para seguir desarrollándolo. Tras debatir un poco, Rexbeng sugirió que podíamos montarlo como un juego de nivel único, más o menos como un clon de Cybernoid, para un evento que iba a haber alrededor de la semana santa de 2020, a modo de pequeña pausa de Corsair. En ese momento faltaban 3 o 4 meses, si no me falla la memoria, así que la fecha límite para un motor de estilo Cybernoid completamente funcional era algo ajustada. Al final no logré tener el código a tiempo para esa fecha; tenía el bucle principal del juego con todos los elementos del entorno, pero no tenía enemigos voladores.

Una vez pasada la fecha límite, ya no teníamos presión, así que podíamos permitirnos lanzar ideas al aire y evolucionar el juego más allá del plan inicial. Con los sistemas ya en posición, era sencillo ir añadiendo otros peligros y características; se modificó la progresión del juego para permitir backtracking y habitaciones secretas, y pensamos que parecía un poco arbitrario lo de recoger tesoros para obtener un bonus, y sin sentido en el contexto de un juego de nivel único, así que añadimos una armería dónde pudieras gastar en mejoras y recargas de munición esos créditos obtenidos. Por desgracias, diferentes acontencimientos conspiraron en los últimos cuatro años para hacer muy difícil poder trabajar en el juego, así que ¡al final no fue un proyecto paralelo rápido tal y como debería haber sido!

El mockup estilo Cybernoid

 

¿De cuál de tus trabajos te sientes más orgulloso?

Diría que de Dead on Time, Relentless y Dragon Attack. En esos juegos, el jugador tiene el control a 50 fps, así que en teoría se juegan como cualquier otra cosa que podrías jugar en otra plataforma. También son juegos de 64K que son tan buenos como siento que podría haber hecho, más allá de un par de bytes desperdiciados y algún microsegundo de tiempo de CPU aquí y allá.

¿Cuál ha sido tu mayor decepción?

No creo que nada de lo que he hecho se pueda considerar una decepción. Mi enfoque es intentar y pensar cosas que muestren lo que el CPC puede hacer, que funciona con sus puntos fuertes en vez de ir contra la corriente, y entonces ver si puedo hacer que esas ideas funcionen como juego.

¿Qué retos le quedan por conquistar a una persona con un gran nivel técnico como tú?

Tengo una pequeña lista de ideas que me gustaría probar e implementar en juegos o como juego en sí. De algunas tengo ya algún primer prototipo de pruebas, pero no pretendo profundizar en ellas antes de tiempo. Sería guay acabar Corsair de una vez. 

Permítenos darte las gracias de nuevo por tu tiempo y tu paciencia. ¿Hay algo que te gustaría añadir para nuestros lectores?

De nada. Gracias por vuestro interés.

ENGLISH INTERVIEW

First of all we would like to thank you very much for accepting this interview. One doesn ́t talk everyday with one of the most talented programmers for the Amstrad CPC. Let us know a little bit about you. At what age did your interest in technology start?

Thank you for your kind words. I guess my interest started when we got the Amstrad CPC464.

Which were the first machines that entered your home? And when and why did the Amstrad CPC enter your life?

I am not sure when but the first machine was a Hanimax console. My parents bought the Amstrad CPC 464 for my brother & I later, I think in early 1986. I believe they purchased it because there hadstarted being a bit of discussion in the media about the importance of computer literacy in the future.

If I am not mistaken, you grew up and live in Australia. How was being an Amstrad user so far away from Europe? Did you have trouble finding games, magazines, books, etc., or was it just as difficult getting stuff for the other machines like the C64 or the ZX Spectrum?

I grew up in a country town where games, magazines, books and the hardware were all readily availablefor the CPC, though a greater range could be bought from bigger or more specialized city based shopsand through mail order. There was not really much for any other 8 bit platform where I lived, except alittle for the C64, although in the city the C64 appeared to have a bigger presence than the CPC.

Where everybody wants to be

 

We usually find later in the career of a programmer or a game designer that their first works are usually very influenced by the games they used to play. Which were your favorite games as a kid?

At the start on the Hanimax, it was a couple of games called Laser Attack & Spiders Web. On the CPC, I don't think I can narrow it down so I'll just list the games I remember playing and enjoying the most over the CPC's life: Highway Encounter, Star Avenger, Satellite Warrior, Battle of Britain, Codename MAT, Dark Star, Mindshadow, Killapede, Thrust, Kane, Light Force, 5th Axis, Ghosts'n'Goblins, Commando, Barbarian, Renegade, Gryzor, Robocop, The Sentinel, Exolon, Cybernoid, Trantor, Captain Blood, Laser Squad, Dark Fusion, Into the Eagles Nest, ATF, Bloodwych, P-47. But that does leave out some games I found memorable or admired but didn't enjoy so much for one reason or another, and because you mentioned influence I will say a bit about Sorcery+.

We got a DDI-1 for our 464 fairly early on and we got a couple of the Amsoft Gold disk games with it. One of those was Sorcery+, and although I didn't enjoy the game play as much as I'd like for all that I tried, I really loved everything else about the game. The use of mode 0 was the best I'd seen by a large margin, the movement fast and smooth, I thought the mode change for the status area looked great and the way it would quickly access the disk every room seemed like something that would offer so much potential in the future.

So Sorcery+ always stuck with me as a great example of a game made for the CPC, that felt at home on the platform. Even though I don't make games like Sorcery, I've always aspired to make games that feel like that game did to me.

Sorcery+

 

At one point you decide that just enjoying games is not enough for you and you want to do your own games. What moved you to do that?

From the moment we got the CPC I was interested in working out how to 'make it do things', and I recall that we didn't have any games for at least a few days so the first thing I did was start working through the manual's foundation chapters. It was my first real encounter with a home computer so I was starting from scratch and spent a while learning about the new technology and BASIC, so it was some time before I started to write my own programs rather than learning from books and magazines. But I don't recall that there was any other goal to it at the time than to eventually write my own game.

Tycon, developed by Axelay with compiled Laser BASIC

 

Back in the day we couldn't rely on the internet to our researches *laughs* Once you decided that you wanted to make your own games: What resources did you have to learn programming?  Which were your favorite books or magazines to learn how to code?

After working through the 464 manual I shifted to books and magazines. I liked the Australian reprint of CWTA the most of the mags that were available to me because it seemed to have the most BASIC articles and game type-ins I could learn from at that point. 

There were also two books I recall getting a lot from, “The Amstrad Users Omnibus” by Martin Fairbanks and “Games And Graphics Programming On the Amstrad Computers CPC 464, 664 and 6128” by Steve Colwill. I liked these as they went a bit deeper in to game design and going about breaking game functions down in to tasks rather than just presenting a type-in like I typically found in magazines.

Then towards the end of my time working with BASIC, I got the Laser BASIC & Compiler packages by Oasis and made my first game. That was in 1988. Laser BASIC introduced to me some ideas that would prove useful for moving to assembly, like different approaches to sprite handling and storing data more efficiently. 

After that I started learning assembly with the book “Master Machine Code on your CPC 464 & 664” by Jeff Naylor & Diane Rogers. I probably chose that book because it had a 464 running Sorcery on the cover! I also used for reference the “Amstrad Whole Memory Guide” & “The Ins & Outs of the Amstrad“ both by Don Thomasson, along with whatever I could pick up in occasional articles from various magazines.

4th mode. Amstrad User, january 1986

 

Did you learn any programming tricks in the pre-internet era that you still use today?

I did read about using LDI strings from a magazine which is always useful and there were plenty of articles or type-ins with little bits of information on various CRTC registers. 

There was also an article in ACU, 'The Fourth Mode' by Chris Wood about what he called mode 3 in describing the double buffering in Tank Busters using careful colour selection. That made it click for me what was going on with the graphics in games like Ghosts'n'Goblins, and since then I've always had in the back of my mind to think of what you could potentially do with variations of that idea, and a few of my games have made use of that in some way.

Star Sabre Zero

 

Tell us a little bit about Star Sabre Zero. What's the story behind it? How was the development of it? What do you remember about the process of designing the game?

I wanted to make an arcade game and I liked shoot'em'ups, and most examples of the genre that I had been able to find on the CPC in the late 80's were well short of the mark in terms of how they played.

There was not much to the 'design', it amounted to taking as many ideas that I liked from other games as possible. Development was slow because I could only access the CPC during semester breaks at that point. My main goal was to make it run at what I considered an acceptable frame rate for that kind of game, so I targeted 25fps.

What was your developer setup back in the day? 

We already had the DDI-1, so when I moved on from Laser BASIC I purchased a 64k RAM expansion for the CPC464 so that I could use the Advanced Art Studio to work on graphics. For programming I used a disc version of Maxam.

Fable: platform shooter pre Star Sabre Zero

Star Sabre Zero is the oldest game that is associated with you, but it looks too good to be the very first try at game programming. Did you start any other games/programs before it?

I had one attempt at an assembly game project prior to Star Sabre 0, a sort of platform shooter. It was written to use a software scroll initially, followed by a brief trial with flick screen, but I abandoned that project as the scroll had dropped below 17fps with just the scroll and player sprite. Right from the beginning I wanted to make something that made the most of the CPCs capabilities, so I realized I had some rethinking to do and found I just wasn't motivated to put more time in to something where the foundation was not sound.

That abandoned platform game didn't progress beyond a menu and high score table front end with code to display a scrolled background and the lone player sprite, so in that sense, Star Sabre 0 was my first attempt at a game in assembly that I developed that had any functionality or logic behind it, though I did have a couple of lessons to bring in to it from that first project.

Other than that, there was just the first and only game that I wrote in BASIC which was created with the Laser BASIC & Compiler combination and was a simple flick screen maze & collection game, and at some point I briefly worked on another horizontal shooter idea. That used CRTC R3 to scroll the screen, but it was just the R3 scroll, a static panel and some parallax stars, so no more than a tech test, and I don't recall when I worked on it relative to those other projects.

Cataclysm: R3 scroll tech demo

Unfortunately, the machine died commercially before you could even publish it. How were those times of seeing your beloved machine reaching an end? What did you do between this commercial end and the rediscovery of the CPC?

To me the CPC died a slow death well before games stopped coming out for it, so the eventual end was more of a footnote. I had quickly come to regard games as a craft and what I wanted to see from a game was some sense that the people who made them also regarded making games as a craft and had respect for the people buying them. But with most of the games I was able to get hold of originating from the UK, the games that appealed to me became few and far between even in the late 80's. 

By the time that the CPC was finished up commercially, the Amiga was also clearly on the way out here, so I ended up going the console route from there to play games as for me there was no cost effective replacement available for the Amiga.

You actually came back to the CPC relatively early compared to other guys who are today doing games for us. What made you come back to the CPC?

There were a few different things that just had me thinking about it over time in the early 2000's that all built up to it eventually. Commercially released games on the platforms of the day continued to move further away from what I was interested in playing. I discovered there was a small active CPC community online which had me thinking about the 'unfinished business' with my CPC shooter game that I'd never quite completed. Then I read in Retro Gamer about retro publishers popping up and releasing physical versions of new games for 8 bits which sounded like an interesting idea.

Star Sabre

About 15 years after starting with Star Sabre Zero, you work once again on the definitive version of the game. I am very curious: Was it difficult for you to start working again with your old code?

I found going back to Z80 coding was not difficult, after a little brushing up it all started to feel pretty familiar again. Though it was probably closer to 10 years since I'd last used an assembler as it was during 2004 that I began working on it.

Although I didn't have the source on disks available to me at the time, I still had the notebook with some of the code I had written, and I could still remember a lot of the design elements and inspirations and some of the design limits I had worked to.

10 years is a lot of time. We saw the light for new technologies and new ways of communication. If I may ask: What did you learn in these 10 years between Star Sabre Zero and Star Sabre CPC programming speaking?

When I first started on Star Sabre, the only 'programming' I had done at home since I last used the CPC was in the Playstation game Carnage Heart! :) So I basically picked up where I left off on CPC coding. Once I started on Star Sabre, my initial focus was just to develop the best routines I could think of for each task, taking plenty of time off from the project throughout it's development, and I came back and reworked and rewrote many of the core routines a number of times.

I think the only things I picked up from the internet during it's development that went in to the game were a split raster example by Kevin Thacker leading to the in-game raster scroll effects, and I asked about disabling the firmware on CPCzone near the end of the project when I ran out of memory and still needed more space.

Maxam Assembler

Of course you had a lot of new and more powerful resources at your hand. Were you able to move your project easily from your old set up to a new, more modern development environment?

For the initial 64k version of the game, I mostly didn't use modern tools, in a manner of speaking. Only a level editor I wrote in VB. I didn't have access to the CPC at the time so development was on PC, but I used Maxam running on a CPC emulated using Caprice. Although I did treat myself to the Maxam ROM version this time.

My PC was not able to run Caprice any faster than 100% normal CPC speed, so as the project progressed I had 'real time' assembly on a CPC taking more than 5 minutes towards the end. If Caprice had any developer features I wasn't aware of them so I went about debugging just as I had on the actual CPC, which included things like writing memory values to the score line.

The graphics were also produced on Advanced Art Studio and I used tools written in BASIC to grab them for use in the game. For larger objects I would plot them out on a paper grid first to work out the proportions, and I came up with a simple compression system for the large title logo characters and compressed them manually on paper after having BASIC print out the byte columns.

Perhaps that sounds strange or needlessly inefficient but it was very much a nostalgic exercise.

It was only after the 64K version released and Targhan offered to provide some music and suggested try using WinAPE for development that I moved to something modern.

Buy it from Psytronik

Star Sabre was published by Psytronik. They would actually publish more of your works in the future. What's the story behind that collaboration?

I just liked the idea of there being a physical version of my games, like I imagined there perhaps could have been back when I first started trying to make them.

You are well known for your shooter games. Actually, your nickname (Axelay) should give us a hint about your gaming preferences :-) Shooter games are actually some of the most complex to design because of all the components that are usually involved (waves of enemies, power ups, etc). What's the secret behind your game design skills?

I don't really think of most of the games I have made as complex. If anything, since Star Sabre I have tried to keep the designs simple to make them easier to tune or balance the game play to my liking. It's something I felt I didn't do very well in Star Sabre, so I have tried to focus more on that in subsequent games. Also, since I have been working on games with rexbeng the designing has been a very collaborative process.

Dead on Time

In Dead on Time we see an interesting twist regarding game mechanics. How did you come to the idea?

I drew a little bit from quite a few sources as I thought about what that game would be and enjoyed trying to mesh together all the different ideas, so apologies if this answer goes on a bit!

Firstly I had previously put small sprites like bullets and small pickups embedded in code for speed in my previous projects, and started thinking about what could be achieved with a game that had all it's sprites stored that way.

Then just as I finished working on the Star Sabre 128k project, Colin Hogg had dropped in to say hello on the CPCWiki where he mentioned among others that he'd worked on a game called Bio Spheres that I hadn't encountered before. It was a CPC game which was reasonably fast with quite a lot of small sprites on screen. So I started thinking about making something like that.

Because I knew the sprites would take up a lot of memory, I eventually concluded I would design something without backgrounds at all, and at the time I had recently been playing a fair bit of Geometry Wars, so that became my revised starting concept in a broad sense.

I wanted to avoid bosses to cut down on logic and sprite frames as well, and had been playing a lot of Sanvein on the Playstation, so from that I adopted the idea of using time to generate pressure on the player.

Then thinking more on the limited number of sprite frames that would fit, I recalled how colour was used in Ikaruga. That seemed like something that would work well with the compiled sprites with parts of the sprites being able to be different colours just by changing the values in a few preloaded registers, so I set to thinking about how to make colour part of the game play.

Then finally I had been a little amused by the length of the scores in Mars Matrix a few years earlier, and thought it would be fun to come up with a scoring system for Dead on Time that would support such a long score.

Sub Hunter

You are well known for using good techniques on the Amstrad. In Sub Hunter we have another example of a game that's actually fun to play but also shows a very good technical level. What kind of tricks did you use on that one?

This started when Kevin Thacker mentioned a technique using the stack to produce a scroll of repeating blocks, that I believe was used to scroll the ground in Operation Wolf. I thought I'd play around with the idea and see what I could do with it that could be interesting.

Not long before that, during discussions about publishing Star Sabre & Dead on Time through Psytronik, Kenz had asked me if I'd be interested in converting any of their C64 releases. Sub Hunter was one of his suggestions and after some experimenting with that scroll I thought it would be a good fit for that game.

In terms of other techniques used, they included a hardware double buffer, disabled interrupts allowing the stack pointer to be used to process lists and tables, page aligned data tables, lookup tables for sprite masking, and saving memory & cpu time by using code to generate preshifted sprites and background tiles to a temporary buffer before each stage.

Super Edge Grinder

Every work seems to show a good progression in both design and programming. Edge Grinder and Super Edge Grinder are good examples of that. By the way, for the people that are still confused: Which are the differences between both games?

Super Edge Grinder adds a boss to the end of the stage and has graphics by rexbeng. There are some other minor technical differences, but those are the two significant differences.

But I should add that both Edge Grinder and Sub Hunter were ports of existing C64 games, so I had no involvement in the design of those.

You had already produced several good shooter games, but people still had room for surprises with Relentless. What can you tell us about this development? How did you come to the general idea of the game? What design decisions did you made in order to produce such an impressive game?

For Relentless I wanted to make a game that did some things I hadn't done in Star Sabre, so I wanted it to run at 50fps, use close to a full standard screen display for the play area, continuous scrolling background, scroll in 1 pixel step and have sprites moving over backgrounds.

Initially I was developing it along the 'usual' lines of a shooter with stages, bosses and stage specific enemies. but I had put it aside to focus on Corsair. However, the wiki ROM competition came up and rexbeng suggested using the Relentless prototype for that, so I changed the design to something simpler to fit in to a 16kb ROM. For that reason it used a selection of randomized waves with some 'scaling' on how tough they are and backgrounds made of characters, tiles and meta-tiles to reduce the data required for the zones.

Relentless

For us mortals, the scroll on that game looks like black magic. What's the secret behind that awesome scroll?

It uses CRTC register 3 for the scrolling at the hardware level, which shifts the screen a half character or two mode 0 pixel steps to give the effect of a horizontal scroll, and it combines that with a hardware double buffer where one of the buffers is offset by 1 pixel to produce the 1 pixel scroll step.

Relentless is often used to show the true potential of the Amstrad CPC. Before Relentless came to light, most of the people who wanted to impress someone with the CPCs capabilities would probably use a demo from Vanity or Batman Group. After Relentless, people could actually show a proper game with game mechanics, enemies, interaction, etc. Of course, in a demo you don't need to take in consideration things like keyboard input, collisions, etc. Could you explain to us what are the handicaps that you encounter when doing a game compared to a tech demo?

I am not really in a position to compare to developing a demo. Writing games is more appealing to me though because trying to balance all the considerations of player interactions, object handling, visual updates and so on while attempting to maintain a target frame rate is something I find interesting to puzzle out.

You collaborated with the legendary Rexbeng. How did that collaboration start?

It started when rexbeng asked me about putting some new graphics he'd done in to Edge Grinder and I offered to help do that.

Megablasters - Escape from Castle in the Clouds

Rexbeng is long with us in the Amstrad scene. He became probably most notorious for the awesome graphics for Megablasters, a game that keeps a legendary status among fans. It was natural than to produce an homage for the 20th anniversary of the game. How was the development of Megablasters Escape from the Castle in the Clouds?

A bit concerning at first because of the reputation it has as one of the CPCs last big games, and to that point I had not made anything like it. But as development progressed I became more confident that it was running and playing well enough to hopefully be a creditable celebration of the 20th anniversary so I became more relaxed about that side of it.

For the design of the game, it was a rexbeng led project. As it was the anniversary of a game rexbeng originally worked on, I tried as much as possible to implement what he proposed. I don't recall that there was too much that was a technical issue and couldn't be included, mainly just running over time with it.

Dragon Attack

In 2016 you produced my favorite game of yours: Dragon Attack. I remember the CPCWiki thread were people were discussing how many sprites could one handle simultaneously on the Amstrad, and you took the challenge even more far away, producing an incredible and addictive game. What can you tell us about the development of this one and which tricks did you use here?

This started with a few comments on the wiki over several discussions, including one of someone asking if bullet hell style games would be possible on CPC, and someone else expressing relief that it was surely impossible! :) So it just came about from experimenting with some code to move a lot of bullets to see if something was possible at a useful frame rate.

I had in the past thought about doing updates of sprites under interrupt at a higher frequency than the main display so that you could provide more responsive player controls in a game that was doing more than could be achieved in a single screen refresh. This seemed like a good opportunity to use that idea because the vast bulk of what needed to move on screen did not need to move every screen refresh as that would have made those elements too fast.

I thought about how the bounding box style collision I typically used would be very impractical with so many sprites, so I used the display itself as a sort of collision map, effectively making 1 bit of the 4 bit per pixel display an 'enemy bullet display & collision layer' and 3 bits a pure graphic layer. 

Corsair Trainer Loading Screen

 

After making clear the point that a smooth horizontal scroll has no secrets for you, you start working on a vertical shooter. How did you come to the idea of Corsair?

When I was working on Star Sabre I had no plan to work on anything further, it was intended to be a one off for a bit of fun & nostalgia. But I actually found the process more enjoyable than playing games. It just seemed like absurd fun to make a tiny little interactive world in z80! :)

So my first thought after completing the 128k Star Sabre was to 'complete the set', and make an arena style shooter, which became Dead on Time, and a vertical shooter, which is unfortunately still in the process of becoming Corsair more than a decade later, but is actually the third game I started making since I got back in to CPC coding.

In terms of the design for Corsair, the basic starting point was it had to be 50fps, because I didn't want to make something that was a step backwards from what Mission Genocide had done decades earlier.  The design was harder to settle on because to maximize speed I wanted the game to have sprites moving in open space between background elements, and many vertical shooters use landscapes you fly over, so references were a bit limited.

But I did play a lot of the Truxton arcade at one point which at least visually had sections of open space or 'islands' in its' backgrounds so that was my very loose starting point. The loot you collect in Corsair actually started as a power up system that worked a bit like the one in Truxton, but I dropped the power up function eventually as it didn't feel like the game was going to present enough challenge to warrant the inclusion.

Corsair

Is it much different to produce a smooth vertical scroll instead of a horizontal one?

There are multiple ways of doing either and I wouldn't claim to be familiar with all of them, but with respect to those I am aware of, the vertical methods require a bit better understanding of how the  display works to keep the screen stable than you need for horizontal scrolling, but otherwise they provide a scroll that is straight forward to deal with.

For a horizontal scroll the CRTC assistance is a bit limited so you need to use other techniques in addition to get a smoother scroll. There's a lot of different ways you can tackle that, and I think it becomes more important to consider the kind of game you are trying to make when selecting your approach with a horizontal scroll because some sort of limitation or compromise is likely.

How about game design? What are your secrets to produce an entertaining vertical shooter game that is challenging as well as generous the more you practice?

I'm not sure I have an answer for that. I play games, come up with theories on why I think some things seem to work and others don't, and try to apply that to my own games. Then just play what I am working on a lot and adjust where I feel things aren't working.

What are you working for nowadays?

Well, when you asked that question I was working on Hypernoid Zero. :)

Hypernoid Zero

You actually surprised us with the awesome Hypernoid Zero, where you show again how a proper cpc game should be done. What can you tell us about the development of this one? 

Since I got back to coding on the CPC I have occasionally thought about making a Cybernoid style game, and I had mentioned that to rexbeng a couple of times as well. On one occasion he took a screen shot from Cybernoid and did a mockup of how it could look. A few years after that mockup, I was having trouble with getting some things to work on a stage of Corsair so for a break from that I took the graphics from that Cybernoid mockup and put together a little tech demo of the player moving around the screen, with player firing and a satellite circling the player.

I shared that with rexbeng and we got to talking about what we could do to make it interesting to develop further. After some discussion of that rexbeng then suggested we could try and make a one stage game of it as a more or less straight Cybernoid clone for an event that was to be held I think at around easter in 2020, as what was supposed to be a short break from Corsair. At the time that was only about 3-4 months away from memory, so it was a bit of a tight time line to make a fully functioning cybernoid engine. In the end I didn't quite manage all the code by that deadline, I had the game loop with all the environmental elements in, just no flying enemies.

When the deadline passed we no longer had the pressure of time so we could afford to throw ideas around and evolve the game from the original plan a little. With the systems in place already it was simple to add in some other hazards and features, the game progression was changed so backtracking and secret rooms were possible, and we thought that collecting treasure for a bonus at the end seemed a little arbitrary, and meaningless in the context of a one level game, so the armoury was added so you could spend the credits on upgrades or ammo refills. Unfortunately various events in the last 4 years conspired to make it very difficult to work on the game at all for much of that time, so it wasn't quite the quick side project it was meant to be!

The Cybernoid Mockup

What of your works are you more proud of?

I would say Dead on Time, Relentless & Dragon Attack. The player has control response at 50fps in those so they theoretically play like something you could perhaps be playing on any platform. They're also 64k games that are about as good as I feel I could have made them, aside from a few wasted bytes and microseconds of cpu time here and there.

What has been your biggest deception?

I don't think of anything I have done as deception. My approach is to try and think about things that might show what the CPC *can* do, what works with its strengths rather than working 'against the grain', and then to find out if I can make those ideas work as a game.

For a guy with a very good technical level like yourself: what challenges would you still like to conquer?

I have a small list of ideas I would like to try and implement in or as games some day, with some having an early test or prototype, but I don't intend to go in to them ahead of time. To finish Corsair at some point would be nice.

Once again, let us thank you for your time and your patience. Is there anything that you would like to add for our readers?

You're welcome. Thank you for your interest.