RetroManiac

¿Os imagináis controlar vuestro propio Jetpac mediante movimientos de cabeza? ¿Os imagináis ahora controlar así un juego de Amstrad y Spectrum a mediados de los años ochenta? Si bien para muchos de nosotros controlar un juego mediante gestos nos parecía una utopía hace cuatro décadas, mentes creativas ya trabajaban en soluciones viables mucho antes de que la Wii tomara el mercado por asalto. Hoy os traemos la historia de Vidy Vody, un juego desarrollado por Damian Scattergood, cuya versión para Amstrad CPC acaba de ser preservada.

Norman McMillan en ResearchGate

Para entender como era posible ese caldo de cultivo idóneo para el nacimiento de nuevos conceptos atrevidos, tenemos que remontarnos a la fundación de New Concepts en la Irlanda de mediados de la década de 1980. La informática está lejos de llegar al nivel que conocemos ahora, pero es todavía una disciplina relativamente nueva, cargada de esperanzas de futuro y de esa inocencia que aplica el axioma "al no saber que era imposible, lo lograron". En un ambiente académico, y aplicando esa nueva esperanza de introducir la informática en más facetas de la vida cotidiana, surge la idea de realizar un simulador realista —dentro de lo que permite las tecnologías de la época— de surf. La idea corre a cargo del doctor Norman McMillan, profesor de física e informática además de surfero quien, junto a su compañero en el Carlow Regional Technical College, John Frayne y la astrofísica Susan McKenna-Lawlor, aportan 20.000 libras de capital para fundar New Concepts y desarrollar el juego Surf Champ.

Edición física de Surf Champ. Fuente: Reddit

La principal novedad incluida en el juego Surf Champ era un ingenioso método de control mediante el uso de una tabla de surf a escala que se acoplaba al teclado del ZX Spectrum y que permitía pulsar determinadas teclas a la vez simulando el movimiento real de una tabla de surf, idea de mister McMillan. Tras lograr un pedido en firme de 200.000 unidades para la campaña de Navidad, la empresa busca desesperadamente financiación y se pone en contacto con el Instituto de Crédito Oficial del gobierno irlandés, quien no solo no entiende el producto sino que tampoco tiene experiencia en el campo de la informática. Tras unos cuantos tiras y aflojas, la empresa logra una ridícula cantidad a cambio de ciertas concesiones entre las que se incluye que el juego debe ser convertido a Commodore 64.

Dándole duro a la tecla en 1987. Foto cortesía de Damian Scattergood

Menú de inicio de la versión Amstrad CPC

En Vidy Vody nos ponemos a los mandos de un basurero espacial en una misión cuasi suicida en la que tenemos que limpiar la pantalla de basura mientras esquivamos peligrosos meteoritos. Con gráficos a cargo de su hermano Paul y el propio Damian al código, desarrollan esta mecánica clásica de arcade de pantalla fija en la que hay que recoger todos los objetos antes de pasar al siguiente nivel, con Amstrad como máquina principal, siendo convertido posteriormente al ZX Spectrum. Lo que no será tan clásico ni tan típico es el concepto que desarrollará New Concepts para la comercialización del juego.

 

Sprite en papel. Escáneo cortesía de Damian Scattergood

Cuando Damian presenta la idea en New Concepts, al señor McMillan se le enciende una bombilla: «¿Y si replicamos la experiencia de manejar un JetPac» Podríamos usar un botón a modo de propulsor, y un control en la cabeza que nos permitiese cambiar de dirección con un gesto... Una semana más tarde, McMillan aparece con el primer prototipo de lo que haría llamar HUCI —Heads Up Controller Interface—. La idea es, sencillamente, genial a la vez que peligrosa: usar interruptores basculantes de mercurio como sustitutos del joystick tradicional. 

El prototipo del casco con un Amstrad CPC al fondo con el juego en marcha

¿Cómo funciona este HUCI? Básicamente, el señor McMillan coge el casco de su hijo y le añade dos interruptores de mercurio. Dichos interruptores utilizan el mercurio para permitir o interrumpir una señal eléctrica dentro de un circuito según el grado de inclinación. Es decir, tenemos dos contactos dentro de un cuerpo sellado que contiene mercurio, y en determinada posición y por efecto de la gravedad, el mercurio se desplaza enlazando con ambos contactos o bien se aparta y deja de conectar ambos contactos. Estas señales se conectan al típico conector de joystick estándar, le añadimos un botón que al pulsar actúe como propulsor, y ya tenemos un rudimentario periférico capaz de realizar giros a izquierda y derecha según inclinemos la cabeza, además de contar con propulsión. ¿Qué más necesita un JetPac?

Interruptor de mercurio. Fuente: De Qurren - Trabajo propio, CC BY-SA 3.0

La respuesta correcta es: financiación. Y será precisamente la quiebra de New Concepts la que condenará a Vidy Vody al sueño de los justos durante más de 30 años. New Concepts nunca se recuperó del fiasco del instituto de crédito oficial, perdió la posición de ventaja que tenía cuando lanzaron Surf Champ, y acabó ahogada en las deudas, arrastrando tras de si otros proyectos como Ski Champ o este innovador Vidy Vody que incluso tenía planes de expansión internacional. Vidy Vody fue traducido al alemán por el propio Damian Scattergood en lo que sería su primer trabajo de traducción, tarea que lleva realizando de manera profesional varias décadas. 

Vidy Vody para Amstrad CPC recuperado tras 40 años de espera

Si bien había algo de información en Internet, es el propio Damian Scattergood quien muestra la versión completamente acaba de Vidy Vody para ZX Spectrum en su canal personal de YouTube hace poco más de tres años. El juego ha sido siempre tratado como MIA —missing in action; un juego perdido en combate—, de ZX Spectrum, pero lo que no era tan de dominio público es que Vidy Vody fue desarrollado originalmente para Amstrad CPC y posteriormente convertido para ZX Spectrum, como nos confirmó el propio Damian en la entrevista que le realizamos. Será precisamente a partir de esta entrevista cuando a Damian le pica el gusanillo y decide rescatar la versión de Amstrad CPC, prácticamente desconocida hasta la fecha, digitalizando la única cinta existente que conserva el juego a pesar de sus cuarenta años de antigüedad.

 

Con un estilo gráfico sencillo en modo 1, que recuerda mucho a los títulos de comienzo de la plataforma, Vidy Vody es uno de esos juegos en los que «una partida más» se convierte en un buen rato delante del ordenador. Podemos desplazarnos a izquierda o derecha pulsando en la correspondiente dirección y apretando el disparo para propulsarnos. Contamos con medidor de tiempo y de combustible, lo que nos hace tener un ojo en el depósito para no caer por falta de propulsión a la vez que nos damos algo de prisa por alcanzar los objetivos para no perecer por falta de aire. 

En Vidy Vody no podemos desplazarnos activamente en el eje vertical; si queremos recuperar altura tendremos que ponernos encima de una especie de globos que nos ascenderán, mientras que tendremos que dejar de pulsar la propulsión si queremos descender en el nivel. Suena sencillo, pero una constante tormenta de asteroides nos lo pondrá prácticamente imposible. Una vez recogidos todos los objetos, pasamos al siguiente nivel.

Según nos cuenta Damian, tiene previsto publicar ambas versiones del juego en los próximos días. Por suerte no necesitaremos construirnos nuestro propio HUCI; el juego se puede controlar tanto con teclado como con un joystick normal, pero si te animas a construirte tu propio casco con sensor de movimiento, haznos llegar fotos. El juego estará disponible muy posiblemente en la web de Itchio de Scattergood Studios. Os informaremos en cuanto ambos títulos estén disponibles para su descarga.

Código en papel. Escáneo cortesía de Damian Scattergood.

Muchísimas gracias a Damian Scattergood por la labor de preservación y por su contribución a este artículo.

Moons of Darsalon es un arcade de acción/plataformas bidimensional creado por Dr. Kucho! Games, que ya estaba disponible para PC y Mac en Steam, desde mediados de 2023, y que ha sido lanzado recientemente en consolas PlayStation, Xbox y Nintendo Switch. Esta última es la versión que hemos podido probar, en concreto la número 2025.02.10.14.46.

La historia del juego nos sitúa en el momento en que un grupo de “darsanautas” se ha perdido en diferentes lunas del planeta Darsalon. El protagonista tendrá que intentar encontrar la mayor cantidad posible de estos darsanautas y "llevarlos" a la base cercana. Argumentalmente, poco más se puede añadir. Para superar cada escenario, no será necesario que los encontremos a todos, aunque cabe la posibilidad de que en algunos niveles se nos exija una cantidad mínima.

Pantalla de título

En el párrafo anterior hemos entrecomillado el verbo “llevarlos”, porque no se trata de tomarlos de la mano, como hacía Ico con Yorda en el clásico de Fumito Ueda, ni de cargar con ellos, como un Sam Porter Bridges cualquiera. Una vez que encontremos a los compañeros perdidos, nos seguirán. Pero no sólo eso: podremos darles órdenes como que nos esperen en un lugar determinado, o que se muevan en una u otra dirección, de forma más o menos autónoma. 

Homenaje a las pantallas de carga de los ordenadores de 8 bits

Otra de las claves de la jugabilidad será los diversos objetos que encontraremos (más o menos) desperdigados por cada nivel, cada uno con su propia utilidad. Una linterna, para alumbrar los lugares más oscuros, por los que nuestros adorables compañeros se negarán a transitar. Una pistola láser, para repeler a los alienígenas que tratarán por todos los medios de acabar con nosotros. Un jetpack, que nos permitirá alcanzar lugares inaccesibles de otro modo. Y, quizás el objeto más representativo del juego, la pistola Ground Maker, que nos permite crear suelo sólido donde antes no lo había, eso sí, siempre comenzando a construir a partir de otro emplazamiento previamente sólido.

Eso significa que el terreno, como tal, es dinámico, y su composición puede ser alterada, tanto de manera creativa como destructiva (con la pistola láser). En ese sentido, recuerda muchísimo a títulos como Worms. Esta característica añade bastante dificultad, desde el punto de vista técnico, a la hora de desarrollar el juego, ya que no se cuenta con una distribución predefinida, sino que puede verse modificada por el jugador y el resto de eventos que ocurren durante la partida en tiempo real. De hecho, alguna vez (pocas, a decir verdad) nos hemos quedado atascados porque el sistema de colisiones nos ha permitido colarnos por algún lugar del que luego no hemos podido salir, teniendo que reiniciar el nivel.

El prota y sus compañeros están constantemente rompiendo la cuarta pared

Como comentábamos, tendremos que conseguir que cierto número de darsanautas lleguen a la base para pasar de pantalla. Pero, además, cada nivel presenta tres desafíos diferentes. Obtendremos una estrella si superamos cada uno de ellos, más una cuarta si superamos todos a la vez.

Según avanzamos en las diferentes fases, llegaremos también a poder conducir vehículos en los que transportar a los compañeros perdidos. Pero, ¡ojo!, que la orografía del terreno puede jugarnos malas pasadas.

El primer nivel es un tutorial para ir pillándole el aire a los peculiares controles

El primer nivel hace las veces de tutorial, para mostrarnos los controles, que son un poco especiales. Usaremos los gatillos ZR para disparar y ZL para saltar (y agarrarnos a una cornisa cuando proceda). Esto es así porque emplearemos la cruceta (o la no-cruceta, si estamos jugando con los Joycons), para dar órdenes a los compañeros, mientras que los botones habituales (A, B, X, Y) se emplean para seleccionar los distintos objetos que portaremos en cada momento. El stick izquierdo sirve para mover al personaje, y el derecho para apuntar.

Si nos gustan los paseos plácidos, este no es nuestro juego

En la esquina inferior derecha dispondremos de un minimapa, por si en algún momento nos sentimos perdidos en la inmensidad de las lunas de Darsalon. Puede que nos ayude a orientarnos. Al final, la premisa principal del juego consiste en eso: localizar a los compañeros perdidos, ingeniárselas para llegar hasta ellos (o ellos hasta nosotros) y conducirlos sanos y salvos hasta la base. Por tanto, es imperativo explorar cada nivel para localizar cada uno de los elementos de interés y trazar rutas para movernos entre ellos.

Uno de los vehículos que podemos usar para rescatar a nuestros colegas

Nuestro personaje dispone de una barra de energía que irá mermando si nos caemos desde demasiada altura, o si nos alcanzan los disparos de los enemigos. Sólo le falta ir consumiéndose según pasara el tiempo. Si nos quedamos sin energía, tendremos que volver a empezar el nivel. Nada de puntos de control ni gaitas modernas de esas. Las munición de las armas también se agota. Los compañeros también se pueden hacer daño al caer (aunque si la altura es elevada, rehusarán tirarse), y pueden morir a causa de los disparos (propios y enemigos). Como veis, este juego no es sólo retro en apariencia.

Los compañeros harán todo lo posible por seguirnos. Pero no son tan ágiles como nosotros

Gráficamente, el juego presenta una estética que quizás trata de recordar al Commodore 64, con una gama de colores característica, pero sin llegar a implementar todas sus limitaciones (la opción por defecto muestra 128 colores). Además, en algunos niveles encontraremos ítems que nos permitirán activar nuevas opciones de filtrado gráfico. Nosotros somos tan mancos que todavía no hemos conseguido ninguna, pero todo se andará.

Por fin conseguimos llegar a la base

Quizás podemos ponerle un pero, y es que algunas zonas de los niveles están tan recargadas visualmente, que es difícil distinguir qué es una plataforma en la que nos podemos apoyar de lo que es el fondo. En algunos casos, será cuestión de ensayo y error hasta que memoricemos los elementos de cada nivel.

Este nivel se nos dio bien. Conseguimos todas las estrellas

En cuanto al apartado sonoro, combina unas melodías de buena factura, interpretadas por el SID del Commodore 64 (o una emulación del mismo) y unos efectos de audio que nos retrotraen sin atisbo de duda a los años 80. 

Podemos usar las herramientas de forma creativa. A falta de linterna...

En resumen, un título que combina dosis de acción, plataformeo y puzle, con un nivel de dificultad bastante elevado, y al que tendremos que dedicarle muchísimas horas si queremos sacarle todo el jugo. Su propuesta estética, tanto visual como sonora, tiene personalidad propia y se nota muy trabajada. Aunque podría estar un poco más pulida en los aspectos que hemos comentado, tiene muchísimo mérito siendo obra de una única persona.

Hasta aquí hemos llegado. Nos quedan todavía 19 niveles por superar

Estas primeras impresiones han sido redactadas tras haber probado el juego durante algo más de tres horas, en las que hemos podido avanzar hasta el duodécimo nivel, gracias a un código de descarga digital de la versión para Nintendo Switch que gentilmente nos ha proporcionado Jesús Fabre. Es posible que, por tanto, hayamos obviado algún detalle que aparezca en niveles posteriores. Pero no es la intención de este artículo, en cualquier caso, destripar todos los secretos del juego.

Para completar estas impresiones, hemos tenido la oportunidad de hablar con Daniel Manzano, desarrollador del juego (bajo el mencionado nombre de Dr. Kucho Games) que, amablemente, ha respondido a nuestras preguntas.

La guarida del Dr. Kucho!

Vemos en la estética de Moons of Darsalon claras referencias al Commodore 64. ¿Fue ese tu primer ordenador? ¿Cómo viviste la época de los 8 bits? ¿Lo usabas para estudiar, como decíamos todos, para jugar o también hacías tus pinitos programando?

El primero fue el Spectrum Plus. Mis padres lo eligieron en lugar del 48K porque tenía un aspecto más serio y parecía que se podía usar para algo más que jugar, aunque ya conocemos todos esta película. Y lo fue por mucho tiempo. Solo tuve un Commodore después, gracias a que un compañero de clase se pasó al Amiga 500 y me vendió su C64, así que te puedes imaginar que el C64 ya estaba en su última etapa comercial.

Aun así, había experimentado con Amstrad y Commodore en casa de algunos amigos, y la verdad es que el C64 siempre me fascinó por su sonido y por sus colores realistas. No como los del Spectrum, que no solo sufrían color clash, sino que además eran todos muy saturados. Era mucho más difícil imaginarse la realidad.

De cualquier modo, sí que usé el Spectrum para aprender. Con el manual de BASIC que venía incluido y unas clases especiales que recibí en mi colegio, aprendí algo de BASIC que puse a prueba en mi Spectrum. Siempre estuve interesado en mover gráficos píxel a píxel, en lugar de carácter a carácter, que era lo único que se podía hacer en BASIC. Me preguntaba cuál era la magia negra que usaban los juegos comerciales para conseguirlo.

Más tarde conocí a un amigo en el instituto que tenía un Amstrad y sabía programar en ensamblador. Él me enseñó los principios de la programación en Z80, y después aprendí ensamblador del 6510. Junto con algunos libros que explicaban el manejo de los sprites integrados del Commodore, hacía mis experimentos programáticos. Nada serio, siempre soñando con hacer juegos, pero nunca llegando a estar ni remotamente cerca de conseguirlo.

La tecnología avanzaba más rápido que mi conocimiento. Luego llegó un Amiga y aprendí algo de 68000 y del chipset del Amiga, pero entonces descubrí los trackers para hacer música y todo cambió. Hacer música era igual de divertido, pero menos problemático: si hacías algo mal, el ordenador no se colgaba como pasaba en ensamblador.

Para superar la polifonía de cuatro notas del Amiga 500, desarrollé un software para esclavizar a un Amiga 500 controlado por otro Amiga maestro vía MIDI. El maestro corría un tracker con MIDI (OctaMED), usaba sus cuatro canales internos y, por MIDI, podía disparar algún teclado y/o caja de ritmos que adquirí, además de un segundo Amiga esclavo corriendo mi programa. Este escuchaba los comandos MIDI y disparaba los samples que cargabas desde el disco. Este fue el único software terminado y útil que hice, fruto de tantos años de enredar con ensamblador de Z80, 6510 y, finalmente, 68000. Era rudimentario, con una interfaz horrible, pero funcionaba, y bastante bien.

Jugando a Moons of Darsalon se percibe con claridad el legado de clásicos como Lemmings o Worms. Pero seguro que hay otros títulos que te han inspirado en mayor o menor medida. ¿Podrías citar algunos de ellos?

Oddworld: Abe’s Oddysee para PS1, y luego todos los juegos de disparos y/o acción que machaqué en distintas máquinas: desde Jet Pac en Spectrum hasta Super Contra en arcade… incluso Ghosts’n Goblins. De hecho, el sonido de salto en Moons of Darsalon intenta recordar al de Ghosts’n Goblins. Es curioso cómo, con el tiempo, el sonido de salto se ha ido dejando en desuso. Pero antes se usaba mucho.

Ocho años de desarrollo es muchísimo tiempo. Creemos que la mayoría de la gente se habría rendido antes. ¿Cómo lograste mantener la motivación para llevar el proyecto a buen puerto?

Los primeros cuatro años fueron de felicidad por poder cumplir el sueño que tenía de niño, pero a partir de ahí empecé a sufrir etapas cada vez más intensas de depresión. Me sentía en una misión imposible, interminable e incierta.

Si no me rendí, fue porque abandonar, con todo el trabajo que tenía a mis espaldas, habría sido aún más devastador. Así que no me quedaba otra que seguir adelante, aun sin saber cuándo iba a acabar la pesadilla.

Soy muy persistente, eso lo sé desde mucho antes de esta aventura. En mis tiempos de DJ y productor musical, en una entrevista en Argentina me preguntaron cuál era mi mejor virtud y dije: “Soy persistente”. ¿Y tu mayor defecto? Lo pensé unos segundos y dije: “Soy persistente”. Es un don y una maldición al mismo tiempo, depende de la situación o de cómo te lo tomes.

El kit de prensa es de los más completos a los que hemos podido acceder, teniendo en cuenta que solemos reseñar juegos de desarrolladores indies (independientes, pero muchas veces individuales). ¿Cómo de importante crees que es el marketing a la hora de vender un videojuego hoy en día?

No lo sé. Todo el mundo dice que es muy importante. En algunos cursos de marketing que he hecho, dicen que el marketing es un multiplicador. Cuando empecé a producir música, no era muy importante. Yo, de hecho, hacía poquísimo marketing: solo sacaba discos, los ponía en el mercado y el disco funcionaba o no, dependiendo principalmente de su calidad y de su nivel de estar a la moda. Pero eran otros tiempos, otro mercado.

La saturación cada vez peor de los videojuegos hace que el marketing sea mucho más importante que antes, eso está claro. ¿Pero hasta qué punto? No sé. Yo creo que es mucho más importante hacer un juego que encaje con las tendencias actuales. Si aciertas en eso, puedes salir sin apenas marketing y te irá bien.

Mi press kit está muy completo por varias razones. Yo trato de perfeccionar todo lo que hago, considere que sea importante o no, no puedo evitarlo. A veces pierdo mucho tiempo en perfeccionar gilipolleces, pero si no lo hago, me siento mal.

Por otro lado, el press kit ha tenido tiempo de ir mejorando desde que lo preparé para la salida del juego en PC hasta que salió en consolas.

Hemos estado leyendo el GDD (documento de diseño del juego) y haces referencia a algunos detalles técnicos que parecen bastante sofisticados. ¿Has seguido algún tipo de formación reglada o eres totalmente autodidacta? Sabemos que has usado Unity, pero “tuneando” algunos aspectos del motor. ¿Podrías darnos algún detalle?

Todo ha sido experimentación, prueba, error, depuración e incluso eliminación de features que no funcionaban o no aportaban al juego algo divertido. Por ejemplo, hice una pistola que disparaba agua, pero tuve que sacarla del juego porque no vi una forma clara de darle utilidad o sentido. La idea era que pudieras no solo disparar agua, sino recogerla también, para crear charcas o moverlas de un sitio a otro. Pero ¿con qué utilidad real? No supe responder a esa pregunta, así que se quedó como un gadget curioso en el cajón.

Las físicas de líquidos son un añadido a Unity, ya que preguntas. Funcionan gracias a una librería de Google llamada LiquidFun, que se basa en otra librería de físicas 2D: Box2D, que es la que usa todo el mundo, incluso Unity para sus físicas 2D. Unity tenía planeado incorporarla, pero nunca lo hizo. Quizás porque tiene algunos bugs peligrosos que pueden crashear el ordenador.

Tuve que hacer que corriera en paralelo al motor de físicas de Unity, lo que fue una pesadilla. Así que hay dos motores de físicas corriendo sincronizados: el de Unity y la adaptación de LiquidFun, la cual tuve que hacer correr en hilos de procesos paralelos. Si no, los cálculos eran demasiado pesados y perjudicaban el rendimiento. Esto fue una pesadilla independiente dentro de la pesadilla principal de crear el juego.

Normalmente, los programadores solemos ser bastante malos diseñando, y viceversa. Es algo normal, ya que alcanzar la excelencia en dos disciplinas tan dispares está solo al alcance de unos pocos privilegiados. No parece ser tu caso. Ya hemos hablado de lo técnico, pero el apartado gráfico también logra un aspecto notable. ¿Qué herramientas has usado en el proceso de diseño y creación de los gráficos?

Esto podría considerarse otra “modificación” de Unity: el sistema de renderizado. Se puede hacer con los componentes de Unity, pero utilizándolos de una forma para la que no creo que fueran pensados. La gente usa las formas de renderizado medianamente estándar que Unity te proporciona, pero estas no son óptimas para pixel art retro. Crean píxeles de distintos tamaños que incluso mutan a medida que los sprites se mueven, no hay control sobre la paleta… En fin, es todo un desastre que la gente ha aceptado, ya sea porque se ha olvidado de cómo se veían los juegos retro o porque son tan jóvenes que nunca los han visto realmente.

Las máquinas antiguas tenían limitaciones que definieron lo que hoy conocemos como pixel art: cantidad de colores, tamaño de píxel, rejilla inamovible, etc. Las máquinas modernas no tienen estas limitaciones y, cuando algunos desarrolladores hicieron los primeros juegos neo-retro, diseñaron el pixel art basándose en su recuerdo de los gráficos antiguos. Por eso no veían problema en usar colores ilimitados o en que el tamaño de los píxeles no fuera consistente.

Yo tomé otro camino. Al ser muy consciente de que estas limitaciones eran la razón por la cual el pixel art es como es, decidí no intentar replicarlas en los sprites usando Photoshop con píxeles grandes y pocos colores para luego representarlos en el sistema de renderizado estándar de Unity. En su lugar, creé un sistema de renderizado que replicara esas limitaciones dentro de Unity. Así, todo lo que intentes renderizar estará limitado, es decir, pixelizado.

Por eso en Moons of Darsalon hay modelos 3D pixelados, por ejemplo. Son modelos 3D reales, pero están renderizados por un sistema que los pixeliza. Explico esto y muchas otras cosas en la serie de vídeos de mi canal de YouTube.

Estas limitaciones, sean innatas en una máquina retro o forzadas por un sistema así en una máquina moderna, no solo te retrotraen a la época de los juegos antiguos, sino que también ayudan a dar coherencia visual y estilo al juego. Cuantos menos colores tengas, más coherente es todo. No es sinónimo de calidad, pero ayuda a conseguirla. Aun así, tienes que poner mucho de tu parte para lograr buenos resultados. Son unos raíles que ayudan a no dispersarse.

Siendo productor musical, la verdad es que el apartado sonoro es el que menos nos ha sorprendido, pero no por ello deja de estar a un gran nivel. Las melodías tienen un regusto al chip SID del Commodore 64, pero obviamente trascienden sus limitaciones. ¿Nos puedes contar algo más sobre el proceso de creación musical y qué herramientas has empleado para lograr un resultado tan interesante?

Todo está hecho en Logic Audio usando tres emuladores de SID: el ya descatalogado y difícil de hacer correr QuadraSID de Re-FX (solo funciona en 32 bits), el Chipsynth de Plogue y el Insidious de Impact Soundworks. Cada uno se aproxima al SID de manera diferente, por lo que no suenan exactamente igual, pero todos son una aproximación bastante buena.

No me refiero solo a la calidad de sonido o a la fidelidad con la que replican el timbre de las formas de onda y los filtros del SID, sino a las modificaciones que se pueden hacer en tiempo real. La grandeza del sonido del C64 no solo se debe a las capacidades de su chip de sonido, sino a cómo los programadores diseñaron formas de modificar los parámetros del SID mientras estaba sonando. Esto permitía efectos como los acordes rotos o arpegios, y otros efectos especiales, cambiando en tiempo real parámetros como la frecuencia de corte del filtro o el ancho de pulso de la onda cuadrada.

Los plugins que menciono pueden hacer esto para emular cómo sonaban las canciones famosas del C64, pero ninguno lo hace exactamente igual y ninguno incorpora todas las funciones de un reproductor real de Commodore 64, como por ejemplo SIDWizard. Sería complicado explicar qué funciones echaba en falta, pero un ejemplo claro es que intenté replicar el sonido de guitarra en estilo tremolo picking de la canción Misirlou, que popularizó Dick Dale y más tarde Tarantino al incluirla en Pulp Fiction. Yo tenía muy claro cómo quería replicar ese sonido, pero no pude con ninguno de los emuladores.

Por eso usé una versión modificada de SIDWizard en un C64 real (un proyecto personal que tengo inacabado) para programar el sonido en SIDWizard y sincronizarlo con el resto de sonidos emulados en Logic Audio.

¿Qué opinión tienes sobre el uso de IA en el desarrollo de videojuegos, en especial en el caso de grupos de desarrollo pequeños o, como en tu caso, unipersonales?

Este tema es demasiado sensible y complejo como para explicarlo aquí sin que me gane más enemigos, pero supongo que, de perdidos al río, voy a intentarlo.

No creo que el tamaño del equipo de desarrollo sea un factor que deba tenerse en cuenta para evaluar la moralidad de usar o no usar IA. Como toda herramienta tecnológica, la va a usar todo aquel que le interese para facilitarle la vida, sean estudios grandes o pequeños.

¿Acaso exigimos a los estudios grandes que se creen su propio motor? ¿Nos parece mal que usen Unity o Unreal? Para eso se crean las herramientas y las nuevas tecnologías: para facilitarnos el trabajo, y gracias a ellas, nuestra sociedad avanza. En el camino, muchas profesiones sufren, es cierto, pero siempre ha sido así.

¿Queremos dejar de usar el e-mail para devolverle el trabajo a los miles de carteros que lo perdieron? ¿O dejar de usar Internet para recuperar la honorable profesión de los bibliotecarios?

— "Perdone, tengo que hacer un trabajo para la escuela. ¿Dónde está la sección de libros históricos?"
— "Oh, vaya, los dos ejemplares de Historia de Roma disponibles están en préstamo. Me toca esperar a que los devuelvan..."

¿Dejamos de usar Photoshop para retoque fotográfico? Antes, los fotógrafos tenían que cuidar las condiciones de luz de la escena antes de disparar una foto, probablemente elegir la película adecuada para cada ocasión... quién sabe, seguro que mil detalles más. ¿Queremos volver a eso?

Los calculistas eran personas capaces de hacer cálculos complejos de forma rápida. Eran contratados habitualmente por científicos, pero alguien inventó la calculadora. ¿Dejamos de usarlas? Los calculistas se quedaron sin trabajo...

La ropa que llevas puesta antes la hacían artesanos a mano o en telares que requerían de todo tipo de habilidades, pero alguien inventó la máquina de coser y muchos costureros se quedaron sin empleo. Así es el progreso: siempre llega de forma disruptiva para algunos, pero en general nos beneficia.

Perdona por este diálogo ficticio, es una representación de la discusión típica sobre este tema que he tenido yo mismo varias veces e incluso escuchado a otros discutir, es un tema que me interesa.

— “¡No! Pero no podemos permitir que las maquinas hagan lo que hacen los humanos”.

¿Por qué no? Es lo que hemos hecho siempre.

— “¡No! Pero esto es diferente, porque se trata de arte”.

¿Y por qué el arte es diferente?

— “Porque tiene alma”.

Realmente no sabemos si los seres humanos tienen alma, y me estas diciendo que un dibujo si la tiene?

— “¡No! Pero me refiero a que el arte hecho por un humano tiene los sentimientos del artista”.

El arte no tiene sentimientos, el humano cuando los crea suele tenerlos, pero eso no quiere decir que queden impresos en lo que crea o que las personas que consumen ese arte vayan a recibirlos. Por ejemplo, no creo que Bad Bunny quiera transmitir con sus canciones ganas de vomitar, pero eso es exactamente lo que yo siento cuando las escucho. Dicho de otro modo: lo que tu sientes cuando consumes arte esta generado por la forma en la que tu interpretas esa obra. No por lo que el artista quería transmitir. Es cierto que muchas veces coinciden ambos, pero eso no significa que los sentimientos queden impresos en la obra sino que ambas personas, el artista y el consumidor, tienen una cultura similar que les lleva a entender esa obra de la misma forma. 

Ademas, comúnmente se acepta que el proceso de crear una obra se divide en dos fases, la fase de ideación y la de ejecución, en la primera uno toma decisiones y en la segunda las ejecuta, la primera puede considerarse la mas pura en cuestión de creatividad, donde nace la idea y se define la identidad de la obra y la segunda puede considerarse mas técnica, que requiere de ciertas habilidades pero mas técnicas y con un énfasis en la precisión y el dominio de las herramientas que en lo que es la creación pura. En dibujo, la fase de ideación seria decidir la composición, posturas, elementos, estilo gráfico, paleta de colores, lo que quieres transmitir con tu dibujo, y luego la fase de ejecución empieza cuando coges los lápices. Cuando usas una IA para crear arte escribes un prompt, esta es la parte de ideación, la mas creativa, y la haces tú. La IA toma tu prompt y hace la parte de ejecución, ella lleva a cabo la parte técnica de hacer los trazos etc. En esta parte también habría arte que la IA hace por ti pero no nos olvidemos que tu has elegido qué quieres que haga la IA.

—“¡No! Pero si no le pones prompt o si no eres muy preciso con el prompt la IA se inventa cosas ella sola”.

¿Sabes cómo se creó el Acid House? Fue gracias a un secuenciador de línea de bajo (que lo podías forzar a sonar ácido): el TB-303 de Roland . Tenia dos particularidades importantes: el secuenciador era muy difícil de programar y la segunda es que si lo desconectabas de la corriente la memoria se llenaba de datos aleatorios (al igual que el C64). Lo curioso es que, si reproducías los patrones del secuenciador, podías escuchar secuencias cíclicas aleatorias con cierto carácter caótico, las cuales muchas veces eran aprovechadas por los productores para crear un tema entero alrededor de ellas…”…and (acid) house music was born!…” El productor seguramente tuvo que repetir este proceso de apagar y encender varias veces y escuchar las secuencias aleatorias para elegir una que le gustase. A nadie le pareció mal esto entonces, ¿por qué hacer uso de algo aleatorio ha de estar mal si viene de una IA?

— “¡No! Pero no es que esté mal es que no es arte”.

Vale, pues llámalo dibujo no artístico, realmente ahí si que te doy la razón, porque según el diccionario para ser considerado arte ha de ser creado por un humano, así que si le pones un prompt vacío a una IA, supongo que no es arte, es un dibujo a secas o podemos inventarnos una palabra. Problema resuelto.

—“¡No! Pero lo que importa es el esfuerzo que pone el artista al dibujar cada trazo a mano”.

¿Entonces nos compramos todos un Apple I? Steve Wozniak soldaba todos los componentes de la placa base a mano en su garaje, ¡eso sí que es un buen ordenador hecho con esfuerzo humano!

— “¡No! Pero la IA es diferente porque roba el arte de los artistas”.

Esto es lo que muchos repiten, pero no es cierto. Las IAs aprenden de la misma forma que un humano: observando patrones en obras preexistentes. Si eso es robar, todos los artistas roban.

Sigo muy de cerca las demandas que hay contra las compañías de IA: OpenAI, MidJourney, Suno, Udio... Me apasiona este tema y la única forma en la que veo que los demandantes puedan ganar algún caso sería basándose en un tecnicismo relativo a la forma en la que las IAs se entrenan, no en el concepto de entrenarlas con obras preexistentes. La cuestión legal es demasiado extensa para explicarla aquí, pero me encantaría hacerlo en otra ocasión porque, como digo, me apasiona el tema.

Ha transcurrido casi un año entre la versión de PC y las de consola. ¿Nos podrías comentar algún detalle sobre el proceso? ¿Lo has hecho tú mismo o has tenido ayuda de algún tercero?

Conté con ayuda para las versiones de PS4, PS5 y Xbox. La de Switch la hice solo, y fue la más compleja por problemas de rendimiento. Tuve que inventar sistemas de optimización para que no se perdieran frames en la pequeña consola portátil. Algunos de ellos me han dado dolores de cabeza porque generaron nuevos bugs, así que fue un reto interesante.

Pero, como te puedes imaginar, después de ocho años y tres meses de desarrollo, ya estaba un poco harto y me habría encantado no tener que hacerlo. Aun así, la idea de perder frames y que el juego no fuese fluido era inaceptable.

Por ejemplo, el cálculo de colisiones en los niveles grandes llevaba demasiado tiempo, por lo que tuve que implementar un sistema que apagaba partes del mundo para reducir los cálculos. Sin embargo, en Moons of Darsalon, todo el nivel está vivo, no solo la parte que ves en pantalla. En otras partes del mundo puede haber personajes disparándose entre si por lo que solo puedo apagar las partes donde no haya personajes interactuando, lo cual complicó bastante la cosa.

Por último, ¿puedes comentarnos algo de tu próximo proyecto, si es que existe? ¿Seguirás con la serie de Darsalon o planeas un cambio de tercio?

En esta voy a ser breve y misterioso: el tiempo dirá, jajaja.

Estamos muy agradecidos tanto a Jesús Fabre que nos haya proporcionado un código de descarga con el que hemos podido probar el juego, como a Daniel por atendernos.

Jaime Domínguez es el fundador de Kaleido Games y creador de Slam And Roll. Tras probar el juego, nos pusimos en contacto con él y, muy amablemente, ha respondido a algunas preguntas.

Jaime Domínguez, fundador de Kaleido Games y creador de Slam And Roll

¿Cuánto tiempo te ha llevado el desarrollo del juego?

El desarrollo de Slam And Roll me llevó cuatro años desde cero. Anteriormente, mis proyectos también habían requerido tiempos similares, pero trabajaba con tecnologías como Flash, Adobe AIR o Haxe. Eran lenguajes de programación tipada y carecía de herramientas como editores dedicados, lo que me obligó a crear mis propios recursos. Aunque esos juegos estaban muy pulidos, no eran tan complejos como este.

Slam And Roll es mucho más ambicioso: cuenta con más de 120 niveles diseñados individualmente y duplicados con variaciones especulares, lo que implica revisar cada pantalla para asegurar que funcione correctamente en todas las versiones. Además, tuve que trabajar en detalles como afinar las mecánicas del salto y otras características propias de los juegos de plataformas, género en el que no tenía experiencia previa. Este nivel de complejidad explica los cuatro años de desarrollo.

¿Cómo fue el proceso creativo? ¿Tenías claros todos los elementos desde el principio, o partiste de una versión mínima y fuiste añadiendo elementos progresivamente?

El origen de Slam And Roll se remonta a los años 90, cuando intenté crear un clon de Snow Bros. para MSX junto a un amigo, Néstor. En aquel entonces, tenía apenas 10 o 11 años, y trabajábamos con recursos muy limitados: sin Internet ni tutoriales, nos las ingeniábamos con papel milimetrado para diseñar los gráficos. Aunque el proyecto quedó en el olvido, en 2015 retomé la idea cuando me propusieron hacer un juego inspirado en Snow Bros.. Sin embargo, quería que tuviera más elementos de otros clásicos como Bubble Bobble o Tumble Pop.

Finalmente, decidí crear un juego con una temática muy personal, influenciada por mi vida en los años 80. El nombre "Slam" proviene de mi apodo como grafitero, y "Roll" refleja mi pasión por el patinaje. Incluso los nombres de los personajes están inspirados en personas cercanas. Inicialmente, el gameplay era muy retro y fiel al estilo de Bubble Bobble, Snow Bros. o Nightmare in the Dark, pero poco a poco evolucionó gracias a las pruebas realizadas en eventos como Retro Parla y los comentarios de los jugadores. Añadí mecánicas como el doble salto, disparos variados y otras innovaciones que transformaron el juego en algo único.

Los juegos que habías publicado hasta ahora estaban desarrollados en otro lenguaje. ¿Por qué elegiste Unity para Slam And Roll? ¿Fue tu primer proyecto con este motor?

La decisión de usar Unity fue esencialmente pragmática. En ese momento trabajaba con Haxe y OpenFL, pero me encontré con problemas para lanzar juegos en Xbox debido a la incompatibilidad con las librerías WinRT. Evalué diferentes motores, como Godot, GameMaker, Unreal y Construct, pero finalmente me decanté por Unity porque ofrecía el mejor soporte y una comunidad muy activa.

Antes de Slam And Roll, hice un remake de H.E.R.O. de Activision en Unreal Engine, pero el proceso resultó demasiado lento y pesado. Unity, en cambio, era más eficiente y accesible. Gracias a esta elección, he podido convertir el juego a Nintendo Switch, Xbox y Steam, algo que no habría sido posible con mis herramientas anteriores. Aunque requiere dedicación, esta decisión ha sido clave para el éxito del proyecto.

Después de todo este tiempo de desarrollo, y con lo que sabes ahora, ¿volverías a escoger Unity?

Definitivamente, sí. Unity ha demostrado ser una herramienta eficiente y versátil. Aunque ahora utilizo una licencia profesional de pago, considero que la inversión vale la pena por las facilidades que ofrece en el desarrollo. La eficiencia de trabajar con Unity supera con creces la de programar todo desde cero, así que no tengo dudas de que repetiría esta elección.

¿Te has encargado entonces tú mismo de las conversiones de consola, o has delegado esta tarea?

He realizado todos las conversiones personalmente, gracias a mi contacto directo con Nintendo y Microsoft. Aunque ya había trabajado en ports para Nintendo Switch con mi propio motor, hacerlo en Unity resulta mucho más sencillo una vez que tienes un motor bien estructurado. El proceso ha llevado entre tres y cuatro meses, pero prefiero encargarme yo mismo para garantizar que todo funcione de manera óptima. Además, es más rentable y práctico a largo plazo.

¿Tienes intención de seguir mejorando el juego y dotándolo de más contenido, o prefieres centrarte en tu próximo proyecto? ¿Puedes adelantarnos algo?

Desde su lanzamiento en noviembre, Slam And Roll ha recibido actualizaciones constantes para ajustar la dificultad y mejorar el motor. Aunque mi plan era detener el desarrollo en 2025, he seguido haciendo pequeños cambios, como añadir un auto-disparo para adaptarlo mejor a los gamepads. Sin embargo, mi intención es centrarme en un nuevo proyecto a partir de mediados de enero. Aún no puedo adelantar detalles, pero estoy emocionado por lo que viene.

Jaime con el mueble arcade de Slam And Roll

Jaime, te damos las gracias por atendernos y esperamos que triunfes con este juego y los que estén por venir. 

En una época de potencia computacional tendente a lo ilimitado, echar la vista atrás a sprites pixelados y ciclos de reloj contados puede suponer una experiencia introspectiva interesante. Parte de los productos tecnológicos más avanzados cuentan en sus equipos de desarrollo con veteranos de una industria que comenzaron programando en papel y ensamblando de cabeza. En el caso que os traemos hoy buceamos ademas en los inicios de la industria del videojuego de Alemania con dos protagonistas de lujo: el Amstrad CPC y Rolf Lakaemper.

ENGLISH INTERVIEW AFTER THE SPANISH TEXT 

Antes de nada, permíteme darte las gracias por tu amabilidad al aceptar esta entrevista. Empecemos por el principio: ¿cuándo se despierta tu interés en la tecnología?

Gracias a ti por la oportunidad para hablar de esos tiempos. Espero ser capaz de transmitir como fueron los comienzos de la programación de videojuegos en Alemania.

Respecto a mi interés en la tecnología y los ordenadores: en mi caso ambos vinieron de manera fortuita, lo que creo que también explica un poco cómo eran esos tiempos. Estamos a finales de los años setenta, principios de los ochenta.

Cuando tenía 12 años quería comprarme a toca costa un skateboard, que por entonces era la última moda. Tras mucho tiempo ahorrando dinero fui a una tienda, pero no le quedaban skateboards. El listo del vendedor me ofreció en su lugar, y esto fue totalmente aleatorio; un kit de electrónica —construye tu propia radio, etc.—. «Cuesta lo mismo: 120 DM» (Nota del traductor: 120 marcos alemanes son aproximadamente 60 euros). Era mucho dinero para un niño, y aún no teniendo ni idea de que era un kit de electrónica, lo compré. Entonces mi interés por el skate dio paso al montaje de luces, radios y otros proyectos típicos de principiantes. 

No obstante, estos proyectos eran limitados y lo que yo quería era ver mi nombre en un televisor. No verme en la señal de televisión para hacerme famoso, sino simplemente ver mi nombre escrito en la pantalla. Entonces, otra vez de casualidad, vi un anuncio de una pequeña caja negra que se conectaba al televisor. Era el ZX81 —así que ya estamos en los años ochenta—. De nuevo no tenía ni idea de que era un «ordenador», pero la publicidad prometía que una caja como esa podría poner algo en el televisor. Se mencionaba también las palabras «programación» y «BASIC» y había un libro que coincidía con esas palabras, que también compré por si acaso pudiera ser útil.

Encargué el ZX81 y mientras esperaba a que llegase leí sobre programación en el libro 101 BASIC Computer Games, que traía listados con juegos ya explicados. No hace mucho, aprendí en YouTube que este libro enseñó programación a millones de principiantes. Leyendo este libro aprendí principios de programación y BASIC y, escribí en papel un juego sencillo de blackjack. Cuando por fin llegó el ZX81, imprimí mi nombre —¡muchas veces!— en la pantalla del televisor, teclee el juego de blackjack y funcionó. Uno de los poquísimos programas que he hecho en mi vida que funcionó a la primera. Eso fue todo. Estaba totalmente dentro. Tenía una máquina con la que podía interactuar. ¡Increíble! 

101 fantásticos juegos en BASIC

¿Cuáles fueron las primeras máquinas que entraron en tu vida?

La primera fue aquel ZX81 en 1981. El ZX81 es una obra maestra de la ingeniería, con componentes baratos —básicamente una CPU, algo de memoria y un chip personalizado— juntados de manera creativa para obtener el primer ordenador doméstico realmente asequible. Inmediatamente después vino un ZX Spectrum. Ya había empezado a aprender ensamblador de Z80, así que sentía una conexión con máquinas con dicho procesador. El siguiente paso lógico fue el Amstrad CPC; ¡un ordenador con teclado de verdad y monitor! Tan pronto como las máquinas de 16 bits llegaron al mercado me sentí atraído por el 68000, que es muy similar al Z80. Por ello, a finales de los ochenta entraron un Commodore Amiga y un Atari ST.

Todavía conservo las máquinas de Sinclair. Decoran la pared como piezas de arte tecnológico, ahora conectadas a Internet a través de un ESP32, mostrando fotos y noticias de los años ochenta.

ZX81, ESP32 y pantalla TFT. Foto cortesía de Rolf.

Normalmente solemos ver que los desarrolladores de videojuegos están muy influenciados al comienzo de sus carreras por esos juegos que solían jugar. ¿Cuáles eran tus favoritos? Según tengo entendido, las máquinas arcade no eran tan populares en Alemania debido a leyes más restrictivas...

Manic Miner para ZX Spectrum

La República Federal Alemana era un conocido bastión del C64. El ordenador llegó incluso a fabricarse allí durante un tiempo. No obstante, tu empiezas tu carrera haciendo juegos para el (Amstrad) Schneider CPC. ¿Cómo entra la serie CPC en tu vida?

Tal y como comentaba antes, adoraba el Z80 incluido en los ordenadores de Sinclair así como en el Amstrad. El CPC entra en mi vida ya en tiempos de Rainbow Arts. Creo que me lo dieron los fundadores de Rainbow Arts, Marc Ulrich y Thomas Meiertoberens, a quienes conocí en mi etapa escolar en mi pueblo natal Guetersloh. Si no recuerdo mal, empecé inmediatamente a programar Nibbler, que junto a mis juegos Mr. Pingo y Money Molch, así como Time, de Marcus Pley, fueron los primeros juegos de Rainbow Arts.

Ya había otros chicos programando en C64 y yo era todavía lo suficientemente joven como para ver el duelo Z80 vs 6502 casi como un pique talibanístico, comparable a gustarte Genesis VS Madonna. Entonces deposité mi fe en el Z80... y en Genesis.

Publicidad con los cuatro primeros títulos de Lakaemper

¿Qué te gustó del Amstrad? ¿Qué no?

El CPC era el paraíso: ¡tenía teclado y monitor en color! Empecé con un CPC464, la versión con cassette. Aún así, el salto desde el Spectrum a ese ordenador se sintió como inmensamente profesional. Ahora se escuchaba un sonido al teclear. Finalmente me sentía como un programador.

Qué no me gustaba: los masivos 16K de memoria gráfica. Es fantástico para imágenes estáticas a color, pero lograr animaciones con 16K en un Z80 a 4MHz, sin modo especial de carácter, sin sprites [hardware], era un reto enorme. El CPC, en comparación con una máquina diseñada para juegos como el C64, con su SID, sprites hardware, registro de interrupciones horizontales y modo basado en caracteres, parecía diseñada para hacer software serio, editores de texto y cosas por el estilo, no para hacer juegos y animaciones.

En cualquier caso, la paleta de colores era tan atractiva que tenía que hacer juegos para ella.

40 años de historia y subiendo. Fuente: Wikipedia

¿Cómo era tener un Schneider CPC en Alemania comparado con un C64? ¿Tenías problemas para encontrar libros, revistas o juegos?

Era difícil encontrar documentación o soporte, pero eso también era cierto para los usuarios de C64. Por suerte, teníamos los libros de Data Becker. Data Becker publicó libros que explicaban en detalle del hardware de ciertos ordenadores, entre ellos el CPC. Así que con esos libros fui capaz de encontrar todas las funcionalidades de los registros y los chips del Amstrad; eso era todo lo que necesitaba. Las revistas también eran útiles a veces, solían tener algunos trucos y consejos. No obstante, en general, era muy difícil conseguir documentación a partir de cierto nivel. No se cuantas veces he reinventado la rueda, hablando de algoritmos, y muchas veces, incluso en juegos, se programaban las cosas muy lejos de una manera optima. En una fase posterior de mi vida fui profesor de Informática y enseñé estructuras de datos y algoritmos en la Temple University de Philadelphia, Estados Unidos. Podría haber usado todos y cada unos de los temas tratados en dicha asignatura durante mi carrera como programador de videojuegos pero, bueno, no había libros, ni Ciencias de la Computación en las escuelas, nada.

Uno de los magníficos libros de Data Becker. Fotografía propia.

A la mayoría de nosotros nos bastaba con jugar. ¿Qué te llevó a querer hacer tus propios juegos?

Debo admitir que era —¿o sigo siendo?— un poco friki. Me interesa la tecnología y el arte, principalmente lo referente a crear y reproducir cosas. Pensaba, y todavía lo pienso, que consumir por el mero hecho de entretenerte es un poco aburrido, y una oportunidad perdida de profundizar en los temas y secretos de este maravilloso mundo en el que vivimos. El ordenador nos ofrece un campo para experiencias virtuales como nunca antes se había visto; tiene la capacidad de simular aspectos específicos de nuestro mundo, y es una herramienta perfecta para manifestar modelos de pensamiento. 

En mi caso, desarrollar juegos era a menudo una prueba de mi propio pensamiento, un espejo que refleja mi propio entendimiento. Después de todo, podía decirles a los ordenadores exactamente qué quería que hicieran, y si fallaba el resultado, eso implicaba un error en la lógica y no un error de sintaxis. Por lo tanto mis ideas y pensamientos estaban obviamente equivocados. He aprendido algo. ¡Maravilloso! Aún a día de hoy estoy contento con errores —lógicos— en mis programas —los cuales ahora tratan más con vida artificial y robótica—, por lo tanto cuestiono mi propia comprensión del mundo a veces de manera bastante fundamental.

Código de Mr. Pingo. Foto cortesía de Rolf.

Una cosa es pensar «¡quiero hacer un juego!» y otra muy diferente es ser capaz de hacerlo. ¿Qué recursos tenías disponibles para aprender a programar y como diseñar tus propios juegos? ¿Cuáles de ellos —libros, revistas, etc.— eran tus favoritos?

Es una buena pregunta. Déjame que aquí interprete recursos de dos maneras diferentes: qué tipo de recursos interiores —o personalidad— eran necesarios, y qué tipo de recursos externos —libros, etc.— había disponibles.

Echando la vista atrás a hace cuarenta años, viendo las herramientas de las que disponíamos, me pregunto seriamente de donde saque/sacábamos la paciencia, el entusiasmo y la perseverancia. Esto es válido para todos y cada uno de esos chicos que se sentaron a programar en ensamblador; esperando durante los intentos erróneos de carga del cassette; probando cosas sin debugger; programando sin compilador, muchas veces solo con papel y lápiz. Es muy difícil pensar en tener una paciencia así hoy día. Mission Elevator, así como los programas anteriores Nibbler, Mr. Pingo y Money Molch, fueron programados en ensamblador en papel y después compilados; convertidos a código máquina a mano —todavía recuerdo unos cuantos opcodes del Z80—. El código hexadecimal resultante se escribía después en el ordenador, guardabas el resultado en cinta, entonces ejecutabas y observabas si hacía lo que debería hacer. 

Así que programaba los juegos en el propio CPC, nada de sistemas profesionales de ensamblaje cruzado. Los gráficos se creaban en papel cuadriculado y entonces se transferían a la máquina usando herramientas de creación propia. Así era la forma de trabajar en el principio; era tan poco profesional como era creativo, y honestamente tampoco sabía entonces que existían en el mundo profesional compiladores de ensamblador, compiladores cruzados, debuggers, etc. No podíamos saberlo, ya que entonces el desarrollo de videojuegos era todavía un negocio muy aislado, realizado por adolescentes que habían aprendido por si mismos.

Respecto a los recursos externos:

Había solo unos pocos libros que iban apareciendo por las tiendas, pero eran extremadamente útiles, ya que cubrían los temas de computación a bajo nivel: hardware, comandos de la CPU, listados de la BIOS/OS. De donde aprendí programación de Z80 fue de un libro con el desensamblado comentario de la ROM completa del ZX Spectrum, incluyendo BIOS, sistema operativo y BASIC. 16KB de ensamblador en oro puro. Leí el código entero, apoyándome en otro libro que listaba en detalle todos los comandos del Z80. Imagínate eso hoy día —un libro con el desensamblado del sistema operativo incluyendo un lenguaje de alto nivel—. Tengo que decir que los programadores de mi generación fueron bendecidos en el sentido de que entonces era todavía posible entender a los ordenadores desde el hardware. Era más o menos fácil entender código Z80 o M68000. El hardware que rodeaba a la CPU —por ejemplo, los chips gráfico y de sonido del CPC—, eran muy básicos, e incluso podías llegar a entenderlos parcialmente a base de ensayo y error. Así que sí, teníamos pocos recursos, pero el campo de conocimiento requerido era mucho menor que hoy en día.

Respecto a que libros o revistas eran mis favoritos. Libros: tengo que mencionar de nuevo a 101 Games in BASIC. Es un libro fantástico, con programas para principiantes sencillos pero a la vez interesantes, todo en, bueno, BASIC. En cuanto a revistas: empezando con Elrad y Elektor, revistas dedicadas a la electrónica. Creo que todavía existen a día de hoy —¿cuántas versiones de un LED parpadeante han debido publicar hasta hoy?—. Luego, para juegos, estaba la Happy Computer, la cual empezó mi carrera profesional —leer más abajo—, y después fue nuestro principal medio para anunciar nuestros juegos, además de una revista posterior, la ASM. Una mezcla de gente que trabajó en estas revistas todavía emplea su conocimiento en una revista actual sobre videojuego clásico: Retro games.

McWash: listado publicado en Happy Computer

¿Cuándo te diste cuenta de que tu código era lo suficientemente bueno como para venderlo? ¿Qué opciones tenías entonces para intentar vender tu primer juego?

El primer juego que hice fue McWash goes Bathing, para ZX Spectrum. Es un juego hecho en Z80 envuelto en BASIC. El jugador debe mover un pequeño personaje, McWash, a través de un laberinto para recoger cubos de agua con los que llenar una bañera, mientras es perseguido por esponjas. No preguntes... En esa época podías enviar juegos en forma de listado BASIC y código hexadecimal a la revista Happy Computer. Si lo publicaban, pondrían el listado en hexadecimal y la gente tendría que teclear esas filas interminables de números hasta tener el juego. Obviamente alguien tecleó McWash, y así cogió su camino hasta llegar a día de hoy hasta YouTube. Fascinante. 

Que te publicasen implicaba que te pagasen —creo que eran unos 100 marcos; o sea, más o menos el precio de un skateboard—, lo cual era una buena motivación. Pero, aún mejor, era también una forma de obtener contactos; Marc Ulrich y Thomas Meiertoberens, por entonces chicos de 16 años que presentían que había negocio en ese mercado emergente de los ordenadores, y que también vivían en Guetersloh como yo, contactaron conmigo. Me sugirieron que hiciera juegos para el CPC, ordenador que habían usado para publicar algún editor de texto y algún programa parecido al Excel, con éxito local. Programé los primeros tres juegos —Nibbler, Mr. Pingo y Money Molch— como autónomo para Rainbow Arts. Ariolasoft publicó estos juegos. Hay que mencionar que Guetersloh, un pueblo de unos 80.000 habitantes por entonces, es la sede de Bertelsmann, una de las empresas de medios más grandes del mundo. Bertelsmann posee BMG/Ariola, una gran empresa de la industria musical. A principios de los 80, estas empresas pusieron su mira en el mercado de los juegos de ordenador, ya que el medio de transmisión de datos, las cintas de cassette, y el cliente tipo, eran muy similares a los de su estructura existente. Ya que, de todas formas, estaban en Guetersloh, Marc, Thomas y yo les ofrecimos Nibbler, Mr. Pingo y Money Molch, y ellos comenzaron pruebas con estos programas, fabricando unas 500 unidades de cada uno, mostrándolos en negocios locales alrededor de Guetersloh. Fue un éxito, y así es como comenzaron tanto Ariolasoft como Rainbow Arts. 

Mission Elevator es un caso diferente. Lo hice entero de manera independiente, al principio sólo. Después me ayudó Bettina Wiedner, quien hizo los maravillosos gráficos del juego, elemento que es coresponsable de su éxito internacional. Por suerte Bettina, mi novia por aquel entonces, se había fijado en mis pobres gráficos de mis juegos anteriores y, siendo una artista como es, se puso inmediatamente a trabajar con papel milimetrado y lápices de colores hasta pixelar los maravillosos gráficos en 16 colores de la versión de CPC de Mission Elevator. Aun conservo los primeros bocetos y todavía admiro el talento en abstraer y simplificar, transformando las posibilidades gráficas de los 8 bits en una forma de arte. Uno de los mejores ejemplos es la Mona Lisa en Mission Elevator; 12x16 píxeles, unos pocos colores y encantadoramente reconocible. Pero también la animación de Trevor, el protagonista. 

Cuando Mission Elevator estaba en marcha, presentía que este juego estaba en una liga totalmente diferente, y tenía en mente un precio mayor para él. Ya que conocía de mis juegos anteriores a la dirección de AriolaSoft, y de todas formas la empresa estaba de camino a mi instituto, les llamé para enseñarles como iba el juego y para escuchar su oferta. Por suerte, me llevé a esa cita como asesor a Thomas Meiertoberens. Yo sabía que no se me daba bien negociar las condiciones. Tras ver la demo —con los gráficos avanzados de Bettina— el manager para Europa, Willie Carminke, cometió un pequeño error: su oferta era muchísimo más alta de lo que yo esperaba. No obstante Thomas, kudos para él por ser tan valiente con tan solo 17 años, rechazó la oferta. Por supuesto, quería matarle en ese momento, pero él me argumentó que si el valor que yo tenía en mente estaba tan lejos de la realidad, deberíamos repensarlo un poco. En ese momento actuamos un poco más profesionalmente y buscamos a la competencia de AriolaSoft, Rushware, localizada en Duesseldorf. Usamos su oferta como palanca y finalmente vendimos Mission Elevator a Rushware por un precio 25 veces superior a mi idea inicial. Parte de ese dinero se empleó en fundar Magic Bytes junto a Thomas y Bettina.

Un jovencísimo Rolf Lakaemper.

Es un poco confuso, ya que fue algo tumultuoso desde el principio. Intentaré aclararlo, pero lo hago de memoria, así que no puedo garantizar que lo que diga sea completamente correcto.

Así pues, Magic Bytes y Rainbow Arts fueron el comienzo de un montón de cosas del mundo de los videojuegos alemanes.

El juego de la discordia. Fotografía propia.

Permíteme que me detenga un momento en Rainbow Arts. La empresa fue fundada en 1984, y aunque hoy en día es muy conocida por juegos como Turrican o Katakis, los primeros juegos que publicaron eran todos para el Schneider CPC: Money Molch, Nibbler y Mr. Pingo por tu parte, además de Time y Der blaue Kristall. ¿Puedes decirnos el motivo que llevó a la compañía a apostar por el Schneider CPC cuando decidieron empezar a vender juegos?

Supongo que el pensamiento inicial sería: mejor hardware, más unidades vendidas, más juegos vendidos. El CPC era una gran mejora con respecto por ejemplo el ZX Spectrum. Se apostó también por el CPC, que por desgracia nunca llegó a alcanzar en ventas al C64, también en parte por que yo me sentía atraído a él y yo era el principal desarrollador de la empresa. Cuando nuestras empresas crecieron para convertirse en negocios serios, quedaba claro que necesitábamos convertir los juegos a múltiples plataformas. No obstante, en ese momento teníamos herramientas para empezar los gráficos en el CPC y a partir de ahí convertir al resto de sistemas. Por lo tanto, siempre había una versión de CPC.

Parte del código de Nibbler. Escaneo cortesía de Rolf.

 

¿Hiciste algún trabajo previo a los tres juegos mencionados arriba?

Sólo McWash para el Spectrum, publicado como listado en la revista Happy Computer.

¿Cómo era tu equipo de desarrollo entonces?

Mi equipo de desarrollo era tan simple como era posible: un CPC464. Hacía código y gráficos en papel. Más tarde tuve al menos un editor/compilador de Z80 muy simple. Y lo peor de todo: todo iba en cinta. Probar los programas implicaban un montón de cuelges de la máquina, y por tanto volver a cargar todo... hacía falta mucha paciencia. Mission Elevator llevó un año entero programarlo —como proyecto secundario, ya que aún iba al instituto. Con las herramientas que tenemos hoy día, llevaría una semana o dos.

Money Molch en acción.

 

Ya que no estoy seguro de en que orden salieron tus tres primeros juegos, empezaré con Money Molch. ¿Qué nos puedes contar sobre el desarrollo de este juego? ¿Cómo fue el proceso creativo?

El orden fue Nibbler, Mr. Pingo, Money Molch. Nibbler y Mr. Pingo estaban, digamos, inspirados en juegos arcade, con algunas pequeñas mejoras.

Money Molch estaba influenciado inicialmente por un juego de ZX Spectrum: Scuba Dive. Me gustaba esa sensación de estar debajo del agua, que está ampliada en Money Molch; no hay superficie del agua y todo el entorno te lleva a una atmósfera aún más de buceo. No obstante, no es muy normal tener a un submarinista saliendo directamente de un submarino.

Diseño de sprites de Nibbler. Escaneo cortesía de Rolf.

 

Misma pregunta con Nibbler, aunque aquí podemos ver un poco de inspiración de cierta máquina recreativa, *risas*.

¡Por supuesto! Llamémoslo plagio respetuoso. Es importante decir que los videojuegos eran una cosa tan nueva y, bueno, inmaculada, que no había una verdadera sensación de hacer malas acciones, sino más bien un absoluto respeto a la hora de copiar juegos arcade. No había un verdadero interés monetario a la hora de hacer videojuegos, al menos desde el punto de vista de los programadores. Posiblemente es muy diferente hoy día. Hacer juegos era un proceso por puro interés en la ingeniería y el arte, para probar este nuevo medio y sus posibilidades.

Sprites de Mr. Pingo. Escaneo cortesía de Rolf.

Mr. Pingo es uno de mis favoritos y diría que es un poco más complejo que los mencionados anteriormente. ¿Qué nos puedes contar sobre él? ¿Cuáles fueron tus mayores retos a la hora de hacerlo y como los solventaste?

Mr. Pingo es más complejo que Nibbler, desde luego. Creo que tuve dos meses para hacerlo —el interés de AriolaSoft de probar a editar juegos venía con una fecha límite de la mano— lo cual era más tiempo del que tuve para los otros dos. Money Molch fue desarrollado especialmente deprisa, según recuerdo. Mr. Pingo también estaba inspirado en un arcade: un juego de Sega llamando Pengo. Mr. Pingo no es más complicado debido a sus mecánicas, pero subió un punto la complejidad. Enemigos animados, mover bloques de hielo, partes que se mueven... no era irresoluble pero sí que definitivamente era más trabajo que la cabeza y cola que se movía en Nibbler. Además, los niveles se generaban aleatoriamente y el programa se tenía que asegurar de que tuvieran solución. Creo que Mr. Pingo está entero en código máquina, mientras que Nibbler usaba BASIC para el sonido tras cada movimiento. Así que sí, fue un avance.

Mission Elevator para Amstrad CPC.

 Estamos en 1986 y en tu siguiente juego se percibe un enorme salto de calidad. Hablo de Mission Elevator, otro juego inspirado en un arcade con una vuelta de tuerca. ¿Cómo fue el proceso creativo de este juego?

Sí, de hecho Mission Elevator fue un salto enorme —para mi, no tanto para la humanidad. Es gracioso, pero este título no estaba inspirado en Elevator Action, aunque es claramente un pariente. Empezó como un proyecto más serio, para simular/optimizar los controles de los ascensores de un rascacielos. Eso lo hice solo por divertirme, pero como programador de vieojuegos, le añadí scroll, etc., para visualizar la simulación. El siguiente paso lo dio Bettina Wiedner quien, al ver el proyecto, le añadió una decoración fabulosa, lo que derivó en esos gráficos espectaculares. 

En ese punto estaba claro que había que crear una historia y hacer un juego alrededor de ella. Antes que nada yo deseaba traer a la vida los elementos del fondo, para apreciar esos gráficos dándoles al menos unos cuantos elementos de funcionalidad. La manguera de incendios, la mesa, la silla, el bar, el reloj, el enchufe, etc., tenían elementos funcionales que no necesariamente ayudarían en la jugabilidad, pero eran divertidos de tener. Entonces el juego necesitaba de enemigos, y Bettina les dio a todos un toque de malo de James Bond estilo aleman de los años 60. Conocía la recreativa, así que claramente me acabó influenciando, cuando añadimos al final las mecánicas jugables, pero lo que diferencia a Mission Elevator son esos gráficos intrincados y todos los pequeños detalles.

Boceto original de Bettina Wiedner. Escaneo cortesía de Rolf.

¿Cuales fueron los mayores retos a los que te enfrentaste?

Mission Elevator es un juego bastante complejo para ese tiempo. Por ejemplo: controlas tu personaje, pero también hay un sistema de transporte —los ascensores. Los enemigos deben ser capaces también de usarlos. Pequeños detalles como ese añaden complejidad al sistema, especialmente si tenemos en cuenta que todo esto está programado en ensamblador en papel, no en un lenguaje de alto nivel orientado a objetos con debuggers de paso simple. Es muy difícil depurar un programa como este, debido a que todas las interacciones entre el héroe, los ascensores, los enemigos, las balas y el otro lado pueden crear unas cuantas combinaciones no previstas que deriven en un cuelgue del sistema que solo ocurra si estás en el piso tercero y hay dos enemigos etc. Muy difícil de depurar mirando a tu código en papel :-)

Y como añadido, el hotel es bastante grande, las animaciones también consumen memoria. Lograr que todo entrase en la memoria del CPC fue el principal reto.

Boceto original. Escaneo cortesía de Rolf.

 Si no estoy equivocado, aquí usas algunos trucos chulos como el efecto temblor de pantalla. ¿Cómo aprendiste esos trucos específicos del CPC como el uso del CRTC, etc.?

¡Oh, sí! Me alegro de que lo menciones. Me encantaba jugar con los registros del CRTC. Por desgracia,  no pude meter en los juegos todos los que encontré, porque algunos solo funcionaban en mi máquina. El efecto de temblor era el que parecía más estable, probado quizás en 3 máquinas... Había una manera muy divertida de ver que podía hacer el CRTC sin ningún esfuerzo: podías llamar simplemente a direcciones aleatorias de la ROM desde BASIC —«call xxxxx»— y a veces estos códigos semialeatorios afectaban al CRTC. Normalmente parecía que tu monitor fuese a explotar pronto. Viendo que esas cosas eran posibles, simplemente examiné los registros del chip de video y necesité buscar esos valores que causaban estados irregulares. Si recuerdo correctamente, la combinación de «call 17, call 20» hacía un efecto como de estar debajo de agua maravilloso. ¡Hazme saber si tienes un CPC para probar eso!

Mission Elevator para ZX Spectrum.

 

Parece ser que este es el primero de tus juegos que también fue convertido a otras máquinas. ¿Fue diseñado Mission Elevator con una máquina en mente y más tarde portado al resto de sistemas o fueron varias versiones programadas al mismo tiempo. Si tenía una máquina objetivo: ¿cuál?

La máquina objetivo fue el CPC al principio, ya que todo giraba alrededor de los gráficos. Cuando debatimos el tema de las ventas, quedó claro que tendría que convertirse al menos al C64. Entonces lo convirtió al C64 Thorsten Deuter. Debido a su gran éxito, también fue llevado al Spectrum —Holger Ahrens y Volker Marohn—, al Amiga —Holger Gerhman de reLine y por mi mismo— y mi versión favorita, Atari ST —Gisbert Siegmund—.

Mission Elevator para Commodore 64.

 ¿Tuviste algo que ver en las versiones de ZX Spectrum, C64 o Amiga? En algunas webs apareces acreditado como programador de la versión de Amiga, en otros como programador de la versión de C64, y en otros solo como diseñador del juego.

No estuve involucrado en la programación salvo en la versión de Amiga, pero por supuesto que colaboraba, explicando las lógicas del juego original, etc. En ese momento yo era director técnico en Magic Bytes, que era el maravilloso grupo de artistas y programadores que crearon las conversiones del juego así como otros grandes juegos originales. Quiero acreditar al equipo, por que las conversiones ya eran un trabajo de equipo. Magic Bytes eran: Bettina Wieder y Hartwig Niedergassel —gráficos—, Joerg Prenzing (C64), Gisbert Siegmund (Atari ST), Holger Ahrens y Volker Marohn (Spectrum y PC) y yo (CPC y Amiga).

Anuncio de Mission Elevator.

Otro dato curioso para nuestros lectores que no conocen tan bien la industria temprana del videojuego alemán; Mission Elevator lo publica Eurogold, que era una empresa subsidiaria de Rushware, con licencia de Micro Partner. Micro Parter era también propietaria de Rainbow Arts hasta 1986, pero tú y el señor Meiertoberens os separasteis de Marc Ulrich, dejándole a él con la marca Rainbow Arts y fundando vosotros Magic Bytes poco después. ¿Cómo te sentías en esos tiempos tumultuosos? Posiblemente sería duro para ti ver que tenías entre manos tu mejor juego hasta la fecha pero tenías que buscar otra manera de publicarlo...

Yo dejé ese grupo y dije adiós al desarrollo de videojuegos en 1989, tras programar Grand Monster Slam.

«Cómo se hizo», Data Welt 9/86. Escaneo cortesía de cpcmaniaco

De hecho, el juego tuvo una gran acogida. ¡Fue posiblemente uno de los primeros juegos alemanes de gozar de cierto éxito fuera de sus fronteras! ¿Qué tal fue el feedback? ¿Cómo te sentiste cuando empezaron a llegar las reseñas?

¡Oh, me sentí en la gloria! Ciertamente Mission Elevator fue un éxito en Europa, partes de Oriente Medio y Australia. Enmarqué en mi oficina la reseña de la Happy Computer, que no fue estelar pero sí muy buena (86/100). Pero ocurre más a menudo ahora que antes lo de recibir reconocimiento por el juego —por ejemplo, esta misma entrevista. En los últimos 15 años he conocido a gente por todo el mundo que recuerda el juego de su infancia. Ver que mi juego llevó un poco de alegría a tantos confines del mundo es una experiencia maravillosa. 

Análisis de la revista Happy Computer

Si se me permite la pregunta: ¿Se podía ganar uno bien la vida con las ganancias de Mission Elevator?

Mission Elevator fue un pelotazo para un estudiante de instituto. No estamos hablando de millones, pero si de seis cifras en divisa alemana. [Nota del traductor: 100.000 DM son unos 50.000 € al cambio]. Por desgracia, ninguno de los otros juegos llegó a ese nivel. No obstante, Mission Elevator me pagó la universidad por completo —estudié Matemáticas aplicadas tras dejar de hacer juegos—, lo que me dio libertad para hacer otras cosas que me gustaban —principalmente, componer música. También me dio la libertad de permanecer en la universidad como estudiante por mucho tiempo. Hice un doctorado en Matemáticas Aplicadas, después cocreé una startup de voz sobre IP, después volví al mundo académico como profesor de Ciencias de la Computación así como investigador en Philadelphia, Estados Unidos, y volví a Alemania en 2015 para trabajar en diferentes startups tecnológicas —vida artificial, visión artificial. Ahora mismo trabajo para una empresa relacionada con los videojuegos, aunque no como programador de juegos, sino haciendo investigación sobre vida artificial. Oiréis hablar de ello pronto, en algún momento. :-)

Reseña en la revista Amtix

 

Ya hemos hablado sobre la fundación de Magic Bytes. Uno de los primeros juegos de la compañía fue Western Games. «Games» era un tema popular gracias a juegos como Winter Games, Summer Games o California Games. Parece que quisisteis subir a ese carro. ¿Qué nos puedes contar sobre el desarrollo de este juego?

Sí, con Western Games y Circus Attractions queríamos participar del éxito de los juegos «Games». Estos juegos eran fáciles de programar en comparación, ya que son principalmente una colección de minijuegos, así que el trabajo se puede distribuir entre diferentes programadores en paralelo, quitando complejidad a la tarea. Western Games se hizo a medida del CPC, tenía gráficos grandes y bonitos con pequeños detalles de animación, así que sacó un buen partido a las capacidades gráficas de la máquina. De nuevo Bettina hizo unos gráficos de comic maravillosos. El proceso consistió en dibujarlos en papel, copiarlos a papel transparente, poner este papel en la pantalla y copiarlo píxel a píxel.

Pero Western Games es uno de los malos ejemplos, dónde hay una buena idea, gráficos geniales, pero falla la jugabilidad —de lo cual tengo yo la culpa. Diseñé el juego demasiado difícil, de hecho es casi injugable. Y, al contrario que Rainbow Arts, no teníamos probadores profesionales, algo que Marc sí introdujo en su empresa.

Western Games para Amstrad CPC.

¿Cómo fue el proceso creativo? Estoy convencido de que os lo pasasteis genial imaginando como sería una olimpiada del Oeste *risas*

Nos lo pasamos genial, de hecho. Recuerdo que recibimos quejas de las oficinas vecinas, que «nos reíamos demasiado en nuestra zona»; no bromeo. En especial, durante el desarrollo de Grand Monster Slam, y debido al artista gráfico Hartwig Niedergassel, quien trajo a la vida a los personajes del juego con sus gráficos y los hilarantes trasfondos de sus historias, quien era una fuente inagotable de diversión. Pero sí, Western Games también se construyó a partir de ideas divertidas del equipo de Magic Bytes.

En realidad, Western Games tenía al CPC como objetivo, para mostrar sus capacidades gráficas. Todavía empezábamos ahí, convirtiéndolo después a las máquinas de 16 bits.

Boceto original de Bettina Wiedner. Escaneo cortesía de Rolf.

¿Fue Western Games el último juego que programaste para una máquina de 8 bits?

Así es. Tras él, migré al Commodore Amiga y el Atari ST. Para el Amiga programé el Grand Monster Slam. El código fuente está disponible en Internet y es interesante de leer. Reemplacé la BIOS entera del Amiga; el juego tiene sus propias rutinas hardware —por ejemplo, carga de disco— y, además, está toda la lógica del juego. Hay una pregunta sin contestar respecto a ese juego: ¿Puede el enano llegar vivo hasta la final? Encontrarás la respuesta en el código fuente.

Boceto original de Bettina Wiedner. Escaneo cortesía de Rolf.

Después de Western Games hiciste un montón de trabajo de diseño y producción para otros títulos de Magic Bytes y algo de programación y sonido de 16 bits. ¿Qué tal fue adaptarse a esos monstruos en comparación con las más limitadas máquinas de 8 bits?

El nuevo hardware era interesante y un desafío, sobre todo el Amiga con sus chips especiales. Todavía se podía manejar, y ofrecía un avance de lo que estaba por venir. El blitter era un chip de apoyo gráfico primigenio y el chip de sonido podía reproducir samples. ¡Tremendo paso adelante! No obstante, con esas capacidades gráficas y con todos los programadores buscando el realismo —hay un término de esa época, la envidia del cine, que encuentro que encaja aquí—, la creación de videojuegos tomó un camino menos encantador. 

Dando vida a un juego. Cortesía de Rolf.

¿Aprendiste algún truco durante tu época como programador de 8 bits que te haya ayudado más tarde en tu carrera? ¿La constante lucha por memoria y ciclos de procesador te ayudó más adelante a hacer mejores juegos en máquinas más potentes?

Respecto a mi carrera programando máquinas de 16 bits: sí. En estas máquinas por supuesto que también ibamos al límite de memoria y ciclos de reloj; el enfoque seguía siendo el mismo: optimizar el código para el hardware allá donde fueses. Pero había una diferencia. Con mejores máquinas llegaron también juegos de empresas de la competencia —principalmente de EEUU y Reino Unido— que requerían un conocimiento diferente: juegos en 3D real. Estos juegos precisan de matemáticas y de un enfoque que en ese momento me quedaban grandes.

Más adelante, en mi carrera científica dentro de los campos de visión/vida artificial: el conocer profundamente los ordenadores y su arquitectura tenía utilidad a veces, respecto a la optimización de estructuras de datos, etc. De lo contrario, pensar en bits estaba ya obsoleto en los años 90. No obstante, me sigue gustando programar microcontroladores, y con estas pequeñas máquinas (ESP/Arduino, etc.) sí que es útil mi experiencia de los 80.

Rolf Lakaemper en la actualidad. Foto cortesía de Rolf.

 

¿Cómo era tu equipo de desarrollo en Magic Bytes? ¿Desarrollaste tus propias herramientas o ya eras feliz con software hecho por otros?

Como decía más arriba, las máquinas de 8 bits todavía se programaban en sí mismas. Eso cambió con los 16 bits; escribí mi propio compilador/debugger en un Atari ST que estaba conectado al Amiga por puerto paralelo. Editaba código en el Atari ST y lo ejecutaba remotamente en el Amiga.

¿De cual de tus juegos en general y del Schneider CPC en particular estás más orgulloso?

Mission Elevator en el CPC. Un juego escrito sin tener en mente ningún interés  comercial, y que a pesar de ello fue el inicio de muchas cosas. Así como mi último juego: Grand Monster Slam en el Amiga. Darle vida a los gráficos de Hartwigs fue un proceso emocionante, y además es el más jugable de mis juegos —aunque sigue siendo muy difícil. ¡Lo siento!—.

Reseña en la Amstrad Computer User

¿Harías algo diferente sabiendo lo que sabes hoy día?

Todos hemos cometido el mismo error: reinventar la rueda mil veces. Había disponible un montón de soluciones para muchos de los problemas con los que lo pasamos mal, pero eso es fácil de decir ahora. Entonces no había información, ni comunidad, ni medios para intercambiar ideas. Así pues, ¿cómo podíamos saber que ya existía un montón de conocimiento informático desde hacía décadas, por supuesto principalmente en ambientes académicos? Podría haber mirado por encima que tipo de herramientas, soporte y algoritmos ya había dipsonible antes de lanzarme a la piscina con un proyecto nuevo.

Además habría puesto más empeño en la jugabilidad. El proceso de publicar un juego de 8 bits habitualmente era: terminarlo mucho más tarde de lo planeado, probar las funciones básicas, publicarlo. Eso cambió años más tarde; por ejemplo, Rainbow Arts había visto la necesidad de contar con probadores de juegos, que durante el desarrollo del juego pudiesen ayudar a mejorar la jugabilidad. Hoy día, los juegos viven por supuesto de su historia, atmósfera y jugabilidad, no tanto de sus trucos tecnológicos. Con los juegos antiguos muchas veces pasaba lo contrario, con excepción de algunos como Prince Of Persia, cuyo desarrollo estuvo más movido por la historia y la atmósfera.

Reseña de Mission Elevator en la revista Amstar 2, 10/86

¿Conservas todavía tus viejos equipos de desarrollo, discos, código, etc.? ¡Si todavía los conservas, deberían estar en un museo! 

Sí, todavía conservo la mayoría de mi código, notas, gráficos, etc. Y, sí, posiblemente un museo sería mejor lugar para ello que mi estantería. 

¿Llegaste a publicar todos tus juegos o quedó alguno en el tintero? 

¡Por desgracia no hay ninguna joya oculta esperando a ser descubierta! 

Pantalla de carga en monitor CRT. Fotografía propia.

¿Oyes la llamada del ensamblador? ¿Veremos en el futuro otro buen y divertido juego de Rolf Lakaemper para los 8 bits?

Desde luego que me siento tentado. No tanto el programar las viejas máquinas como hacer juegos para microcontroladores con sus diferentes tipos de entradas y salidas.

No obstante, desarrollo profesionalmente en la actualidad para visión y vida artificial. Por favor, nada de ensamblador ahí...

¿Qué opinas de este retro revival? ¿Sigues las nuevas creaciones para máquinas clásicas?

He empezado a hacerlo hace poco, tan pronto conocí ese mundillo. Me fascina lo que son capaces de hacer los programadores con las máquinas antiguas y me encanta esa vuelta a esos personajes de 8 bits con encanto.  

Mission Elevator en monitor CRT

 

Permíteme nuevamente darte las gracias por tu amabilidad. ¿Hay algo que te gustaría añadir para nuestros lectores?

Gracias a vosotros por esta oportunidad de hablar de los buenos tiempos. Como añadido para los lectores; en tiempos de progresos abrumadores en el campo de la informática y recursos aparentemente ilimitados, volver a pensar en los comienzos simples, y especialmente volver a ponerme en un mindset reducido, puede ser meditativo y una experiencia de realización humilde. 

Así pues, para esos creadores, diseñadores gráficos, programadores, músicos, artistas e ingenieros que nos estén leyendo, intentad, si es que no lo habéis hecho ya, el experimento de tratar y trabajar con lo simple. Encuentra la belleza en mover un simple píxel —como ejercicio: mira la animación de Lemmings en su versión amiga durante una hora— y resiste la llamada de la envidia del cine. :-) 

ENGLISH INTERVIEW

First of all, let me thank you for your kindness in accepting this interview. Let's start from the very beginning: when did your interest in technology start?

Thank you for the opportunity to talk about these times, I hope I can convey a feeling of the beginnings of (game) programming in Germany.

About the start of interest in technology and computers: both were pretty random in my case which I think also tells a bit about the times then. We are in the late 70s, early 80s here:

At the age of 12 I was eager to buy myself a skateboard, which was the newest hype at that time. After a good while of saving money, I went to a store, but skateboards were sold out. The clever sales person in the store offered me, and that's really quite random, an electronics kit instead (build your own radio etc.), "it's the same price, 120 DM" (a lot of money for a kid), and I, not even knowing what an electronic kit was, bought it. The interest in skate boards was exchanged then for building blinking lights, radios and other typical starter projects. But these projects were limited, and I somehow had the dream to see my name on a TV screen. Not being broadcast for fame, just having the name on a screen. I then saw, again by chance, an advertisement for a little black box that was connected to a TV. It was the ZX81 (so now we are in the 80s). Again, I had no idea what a "computer" was, but the advertisement promised that such a box could get something onto a TV screen. It also mentioned the words "programming" and "basic", and there was a book that matched those words, which I also bought, just in case it would be helpful.

I ordered the ZX81, and during the waiting time I read about programming, in the book "101 BASIC Computer Games", which had games explained and listed (I recently learned on YouTube, that this book had taught millions of beginners BASIC programming). Reading this book, I learned programming principles and BASIC, and, on paper, I wrote a simple black jack game. When the ZX81 finally arrived, and I had printed my name (many times!) on the TV screen, I typed in the black jack game, and it worked. One of the very few programs in my life that worked immediately. That was it. I was sold. I had a machine I could interact with, amazing! 

101 fantastic games in BASIC

Which were the first machines that entered your life?

The first was the ZX81, in 1981. The ZX81 is an engineering masterpiece, with very creatively put together cheap hardware (basically a CPU, a custom array, and some memory) to establish the first really affordable home computer. It was then immediately followed by the ZX Spectrum. I had started to learn Z80 assembly by then, so I felt connected to machines with that processor. The next logical extension was the Amstrad CPC, a computer with a real keyboard and monitor! As soon as the 16bit machines started, I was drawn to the CPU68000, which is very similar to the Z80. Hence Commodore Amiga and Atari ST followed in the late 80s.

I still have the Sinclair machines, they decorate my wall as a piece of technical artwork, now connected to the internet through an ESP32, displaying photos and news from the 80s. 

ZX81, ESP32 and TFT screen. Photo courtesy of Rolf.

We usually find that game developers are heavily influenced in their beginnings by the games they used to play. Which ones were your favourites? If i am not mistaken, Arcade Machines were not so popular in Germany due to more restrictive laws...

Oh, we did have arcade machines! Probably the restrictions held more for WWII-games and fighting games, but the top stars of the starter scene, Space-Invaders, Pac Man, Galaga, Pheenix, Donkey Kong etc. were all heavily played, usually with a few friends as an alternative to Latin lessons in school. I did play arcade games, but also I looked at many games on home computers in local stores. However, I was never solely interested in the game play, but more in the creative use of technology. How is it possible to get dozens of levels into 48k (manic miner)? How can they merge a playfigure with a background? How does collision work? I took the games as a technological challenge, and tried to come up with my own routines to solve such problems. 

Manic Miner for the ZX Spectrum

West Germany was a well known stronghold for the C64. It was even produced there at a certain point. However, you started your career doing games for the (Amstrad) Schneider CPC. How did the CPC series enter your life?

As I mentioned above, I liked the Z80 CPU, which drives the Sinclair computers, as well as the Amstrad. The CPC entered my life already in Rainbow Arts times. I think it was given to me by the Rainbow Arts founders Marc Ulrich and Thomas Meiertoberens, which I had met at school in my hometown, Guetersloh. If I remember correctly, I immediately started programming "Nibbler" on the CPC, which, together with my games "Mr. Pingo" and "Money Molch", as well as “Time” by Marcus Pley were the first games of Rainbow Arts.

The C64 programming was already taken by some other kids, and I was still young enough to see the Z80 vs 6502 programming question as a quasi religious competition (comparable to listening to Genesis vs Madonna). I placed my faith on the Z80 then. And Genesis. 

Ad with the 4 first games

What did you like about it? What did you dislike?

The CPC was heaven: it had a keyboard and a (color) monitor! I started with the CPC464, the cassette tape version. Nevertheless, the step from the spectrum to such a computer felt immensely professional. Now there was a clicking sound when I typed - I finally felt like a programmer.

Dislike: the CPC had a massive 16k graphics memory. This is fantastic for colorful still images, but to get animation rolling on 16k with a 4MHz Z80, no special character mode, no sprites, was a huge challenge. The CPC, in comparison to the game-tailored C64 with its SID sound chip, sprites, horizontal interrupt registers and character based background mode, seemed to be designed for “serious” programs, text editors and alike, not for games and animation.

Nevertheless, the color palette was so charming that I had to bring games to it. 

40 years keeping strong. Fuente: Wikipedia

How was having a Schneider CPC in Germany compared to C64 owners? Did you have problems finding books, magazines or games?

Finding any support and documentation was hard. But that was true for C64 owners as well. Luckily, there were the "Data Becker" handbooks in Germany. "Data Becker" had published books that explained the hardware of certain computers in all detail, among them the CPC. So with these books, I was able to find all the functionalities of registers and chips in the Amstrad, that's all I needed. Magazines were also somewhat helpful sometimes, there were a few tips and tricks in there. But in general, it was very hard to get any documentation above a certain level. I don't know how often I have reinvented the wheel, when it comes to algorithms, and quite often, even in games, things were programmed in a far away from optimal manner. In a later part of my life I was a professor for computer science, and taught data structures and algorithms (at Temple University, Philadelphia, PA, USA). Every single topic of that lecture I could have used during my game programming career, but, well, there were no books, no computer science courses at school, nothing.

This was similar for all computers, when programming on a higher than hobbyist level. The C64 was of course more supported by magazines, but the (German) C64 game programmers at that time were also mostly on their own. 

One of the great Data Becker books.

For most of us, just playing games was fine. What motivated you to do your own games?

I must admit, I was (am?) a geek. I am interested in technology and arts, mainly in creating and (re) producing things. I found, and I still do, consuming for entertainment purposes only pretty boring, and a bit of a waste of chances to dive deeper into the topics and secrets of this amazing world we live in. The computer offers a never seen before playground for virtual experiences, it is able to simulate specific aspects of our world, and it is a perfect instrument to manifest thought-models. For me, writing games was often a check of my own thinking, a mirror to reflect my own understanding. After all, I could tell the computer exactly what to do, and if the result failed, and there was a logic error, not a syntax error behind it, my ideas and thoughts were obviously wrong— I had learned something, wonderful! It is still that I am happy about (logical) errors in my programs, which now deal more with Al and robotics, and therefore question my own understanding of the world sometimes quite fundamentally. 

Part of Mr. Pingo´s Code. Scan by Rolf.

One thing is to think "I want to make a game!" and another one is being able to do it. What resources did you have at hand to learn how to code and how to design your own games? Which ones (books, magazines) were your favourites?

That's a great question, please let me interpret "resources" here in 2 different ways: what kind of inner resources, or personality, was needed, and what kind of outer resources, books etc., were available.

Looking back at myself and other game programmers 40 years ago, looking at the tools we had at hand, I seriously wonder where I/we took the patience, enthusiasm and perseverance from. This holds for each kid that sat down coding in assembly, waiting for the erroneous program attempts from cassette tape to reload, testing without debugger, coding without compiler, often just with paper and pencil - it's hard to imagine such patience today. Mission Elevator, as well as the programs before, Nibbler, Pingo, Money Molch, were coded on paper in assembly, then "compiled", i.e. transferred to machine code by hand (I still remember a few Z80 machine opcodes). The resulting hex code was then typed into the computer, the result saved to tape, then called, and examined if it seemed to do what it should. So the CPC games were programmed on the CPC itself, not in a more professional cross assembly environment. Graphics were created on box paper, then brought into the machine using self made tools. It was the way all programmers worked in the beginning; it was as unprofessional as it was creative, and honestly: I didn't even know that assembly-compilers, cross compilers, debuggers etc. existed in the professional world. We couldn't know, since the game programming trade was still a very isolated business, performed by self taught teenagers.

To the outer resources:

There were only a few books that popped up in book stores, but they were extremely helpful, since they covered the low level computation topics: hardware, CPU commands, BIOS/OS listings. What I learned Z80 programming from was a book with the commented disassembly of the entire ZX Spectrum ROM (which included BIOS, OS and BASIC). 16kB of sheer assembly gold. I read the entire code, supported by another book that listed all Z80 commands in detail. Imagine that today - a book with a disassembled operating system incl. a higher language. Unfathomable. I have to say that the programmers of my generation were blessed in the sense that it was still possible to understand computers from the hardware up. It was relatively easy to understand a Z80 or M68000 code. The CPU-surrounding hardware, e.g. the sound chip or the video chip in the CPC, was very basic, and even try-and-error approaches to understand these chips were partially successful. So, yes, the resources were few, but the field of knowledge required was also much smaller than today.

Which books/magazines were my favourites: books, I need to mention the "101 Games in BASIC" again. It's a fantastic book, with simple yet interesting beginner's programs, all in, well, BASIC. Magazines: starting with "elrad" and "elektor", which were magazines dedicated to electronics. I think they still exist (how many versions of a blinking LED might they have published?). Then, for games, there was the "Happy Computer", which started my professional career (see below), and later was our main outlet to advertise our games, plus a later one, the "ASM". A mixed set of the publishers of these magazines still devote their knowledge to a current magazine of nostalgia games, "retro games". 

McWash: listing published by Happy Computer

When did you realize your code was good enough to try to sell it? What options did you have to try to sell your first game?

The very first game I made was "McWash goes Bathing", on the Sinclair ZX Spectrum. It's a Z80 game with BASIC wrapper. The player must move a little character, McWash, through a maze to collect buckets of water to fill a bath tub, while being chased by sponges. Don't ask me... At that time, you could send games, in the form of BASIC and hex code, to the "Happy Computer" magazine. If published, it would be printed as hex listing, and people would type these vast arrays of numbers to get the game. Obviously someone did type in McWash, and so it took its way to YouTube today. Fascinating. Getting published meant getting paid (I think it was about 100DM, so, about the price of a skateboard), which was motivating. But even more so, it was a way to connect: Marc Ulrich and Thomas Meiertoberens, being 16 at the time and sensing a business in the newly emerging computer market, both living in Guetersloh, my home town, contacted me. They suggested programming games for the CPC, which they had utilized to publish some text editor and excel style programs before, with local success. I programmed the first three games, Nibbler, Pingo, Money-Molch, as a freelancer for Rainbow Arts. These games were published by AriolaSoft. It has to be mentioned that Guetersloh, a village of 80.000 at that time, is the home of Bertelsmann, one of the largest media companies in the world. Bertelsmann owns BMG/Ariola, a large music publishing and recording company. In the early 80s, such companies eyed the computer games market, since the data carriers, cassette tapes, and the average customers were a close fit to their existing publishing infrastructure. Since they were in Guetersloh anyway, Marc, Thomas and I offered Nibbler, Pingo, MoneyMolch to them, and they started tests with these programs, producing about 500 each, displaying them in local stores around Guetersloh. It was a success, and that's what started AriolaSoft as well as RainbowArts.

Mission Elevator for CPC was a different case. I developed it entirely independently, just by myself at first. I was then supported by Bettina Wiedner, who created the amazing graphics of the game, a feature that is co-responsible for its (international) success. Luckily, Bettina, my girlfriend at that time, had seen my insufficient graphic attempts of the other games, and, being an artist, immediately sat down with box paper and color pencils to pixelize the fantastic artwork of the CPC 16 color version of Mission Elevator. I still have the first drafts, and I still admire the talent of abstraction and simplification, transforming the 8bit graphic possibilities to an art form. One of the best examples is the Mona Lisa in Mission Elevator, 12x16 pixels, a few colors, and charmingly recognizable; but also the animation of Trevor, the main character. With Mission Elevator in progress, I sensed that this game is in a different league, and I had a higher price for it in mind. Since I knew the management of AriolaSoft from the previous games, and the company was on my way to school anyways, I just called them to show the game in progress and to hear their offer. Luckily, for that appointment, I took Thomas Meiertoberens with me, as financial consultant - I knew I was bad when it came to financial discussions. After my game-in-progress demo (with Bettina's advanced graphics), the manager for Europe, Willie Carminke, made a little mistake: his offer was way higher than what I had expected. However, Thomas, kudos to him for being that bold at age 17, denied the offer. Of course I wanted to kill him at that point, but he reasoned that if I was that off with my idea of value, then we need to rethink. At that moment, we grew a bit more professional, and checked for competitors of AriolaSoft, which we found in Rushware, sitting in Duesseldorf. We used their mutual offerings as leverage and I finally sold Mission Elevator to Rushware for a price about 25 times as high as my initial idea. Part of that money was used to found MagicBytes together with Thomas and Bettina. 

A very young Rolf Lakaemper.

How did you end up working for Rainbow Arts? To tell you the truth, I am a bit confused with Micro-Partner and Rainbow Arts..

It is confusing, since the beginning was a bit tumultuous. I'll try to clarify, but it's from my memory, so I don't guarantee I am entirely correct.

Micro-partner and Rainbow Arts were existing at the same time, the first one being the brand for business software, the latter one for games. The founders (a big word: there was no legal body to it which was "founded"), were Thomas and Marc, me being the main programmer. The three of us then together planned to continue as Rainbow Arts, but Marc and Thomas parted over the approach leading a business. I assume that's natural if a business of 3 features 2 managers but only 1 person responsible for the products. We split up over a cartoon license game, "Werner". Bettina and I decided to join Thomas, to create "Magic Bytes", while Marc continued Rainbow Arts. Both companies resided in Guetersloh, the gaming center of the world, it seemed. By the way, later (1988) Guetersloh was also home of Thalion software, co-founded by Holger Floettman, who had previously programmed the sound for the C64 version of Mission Elevator. So, Magic Bytes and Rainbow Arts started a lot in the German game scene. 

The game that made both companies part ways.

Let me stop for a second here with Rainbow Arts. The company was founded in 1984 and, although nowadays is well known thanks to games like Turrican or Katakis, they actually started as a company producing "serious" (boring) software for the C64. But the very first games they published were all of them for the Schneider CPC: Money Molch, Nibbler and Mr. Pingo were done by yourself, plus Time and Der blaue Kristall. Can you enlighten us why the company did bet on the Schneider CPC at the very beginning when they decided to start selling games?

I assume initially the thinking was: better hardware, more units sold, more games sold. The CPC was a vast improvement over, e.g. the ZX Spectrum. To bet on the CPC, which then unfortunately never caught up with sales numbers of the C64, was probably also because I was drawn to it, and I was the main game developer. When our companies grew to a serious business, it was clear that we needed to convert our games to multiple platforms. However, at that time we had tools established to start with graphics on the CPC and convert from there. So, there was always a CPC version. 

Part of Nibbler´s code. Scan courtesy of Rolf.

Did you do any previous (unreleased) game before the three mentioned above?

Only the spectrum "McWash" game I talked about before, published as a listing in the "Happy Computer". 

How was your coding setup back then? (hardware, software...)

Coding setup: as simple as it could get: exactly one machine, the CPC464. Coding and graphics on paper. Later I had at least a Z80 editor/compiler, very simple. And the worst: all was still on cassette tape, testing programs involved a lot of crashes, and hence reloading...a lot of patience. Mission Elevator took an entire year to program (on the side, as a school student). With tools today it would take a week or two. 

Money Molch in action.

Since I am not very sure in which order your 3 games were produced, I'll start with Money Molch. What can you tell us about the development of this game? How was the creative process (z.B. how did you decide the look of the game, the game mechanics, etc)...

The order was Nibbler, Pingo, Money Molch. Nibbler and Pingo are, let's call it "arcade inspired", with some little embellishments...

Money Molch was initially influenced by a game on the ZX Spectrum, "Scuba Dive". I liked the underwater feel of it, which is more extended in Money Molch—there's no water surface anymore, and the entire setup draws you more into a scuba-atmosphere. It's probably a bit unusual to have a diver exiting a submarine though. 

Nibbler´s sprites. Scan courtesy of Rolf.

Same with Nibbler, although here one can see a bit of an "inspiration" on certain arcade machine *laughs*

Oh well, of course! Let's call it “respectful plagiarism”. It's important to say here, that video gaming was so new and, well, immaculate, that there was no real sense of wrongdoing, but more of respect in copying arcade machines. Making games was not a process with financial interest in mind at all, at least from the programmers' side, probably different from today. Making games was a process of interest in engineering and art, to test the new medium and possibilities. 

Sprites de Mr. Pingo. Scan cortesía de Rolf.

Mr. Pingo is actually one of my favourites and I would say a little bit more complex than the two mentioned before. What can you tell us about it? Which ones were your biggest challenges with this game? How did you solve them?

Mr Pingo is indeed more complex than Nibbler. I think I had about two months to write it (the interest of the publisher AriolaSoft to test games came with a deadline), which was a bit more than for the other two (Money Molch was especially written in a hurry, as I remember). Mr. Pingo was also arcade-inspired — a SEGA game called "Pengo". Mr. Pingo is not more complicated by its mechanics (e.g., collisions), but it turned the complexity a notch up. Animated enemies, moving ice blocks, moving diamond parts, not unsolvable, but definitely a bit more work than nibbler's moving head and tail. Also, the levels were randomly generated, and the program had to make sure there's a solution for the generated configuration. I think Mr. Pingo runs entirely in machine code, while Nibbler still returned to BASIC after each move for the sound. So, yes, progress.

Mission Elevator for the Amstrad CPC.

We're in 1986 and your next game has a huge leap in quality. I am talking about Mission Elevator, another arcade inspired game with a small twist. How was the creative process for this game?

Yes, Mission Elevator was in fact a huge leap (for me, probably not so much for mankind). Funnily, this one was not originally inspired by the arcade game "Elevator Action", although it is clearly a cousin. It started with a more serious project, to simulate/optimize elevator controls in a high riser building. That was just for private fun, but, as a game programmer, I added scrolling etc. to visualize the simulation. The next step was that Bettina Wiedner, seeing that project, added some fantastic interior design, which led to the amazing graphics. At that point it was clear that there should be a story and a game made around it. First of all I was eager to bring the background elements to life, to appreciate the graphics by giving at least a few elements some functionality. The fire hose, the table, the chair, the bar, the clock, the socket etc., the little functional details did not necessarily support the gameplay, but were just fun to have. The game needed a few enemies then, and Bettina added a touch of German 60s Bond-style bad-guy look to it all. I did know the arcade game, so it clearly influenced me at the end, when the final gameplay was added, but what sets Mission Elevator apart from its relative are the intricate graphics and all the little details. 

Original sketch by Bettina Wiedner. Scan courtesy of  Rolf.

What were the biggest challenges that you found doing it?

Mission Elevator is quite complex for a game of that time. For example: you control your player, but there's also a transportation system in control (the elevators). The enemies must be able to use that control system as well. Little things like that add up to a complex system, especially having in mind that this is programmed in assembly language on paper, not with an object oriented high language with single-step debugger. It is very hard to debug a program like that, because all the mutual interactions between the hero, the elevators, the enemies, the bullets and the other side figures can create a few unforeseen combinations that lead to a crash which only occurs if you are in level 3 and there are two enemies etc. etc. complex to debug by looking at your code on paper :-)

And in addition, the hotel is rather big, the animations also take some memory: to get everything into the CPC's memory was the main challenge. 

Boceto original. Scan cortesía de Rolf.

If I am not mistaken, there are some cool tricks used in this game, like the trembling effect on the screen. How did you learn those CPC specific tricks like using the CRTC, etc?

Oh yes! Nice that you mention it. I loved to play with the CRTC registers. Unfortunately I couldn't bring all the results into games, because some of them wouldn't work on other machines than mine. The trembling effect was one that seemed more robust, tested on probably 3 machines... There was one fun way to see what the CRTC could do without any effort: you could just call some ROM address from BASIC ("call xxxxx"), and sometimes these quasi random codes would affect the CRTC. It usually looked like your monitor would explode soon. Seeing that such things are possible, I just examined the video chip registers and needed to find those values causing irregular states (if I recall correctly, the combination of "call 17, call 20❞ made a wonderful blurry underwater effect. Let me know if you have a CPC464 machine to test that!).

Mission Elevator para ZX Spectrum.

It looks like this is the very first of your games that was produced for other machines as well. Was Mission Elevator designed with one machine as target and later ported to the other systems or were done for more than one system at the same time? If it had a target machine at the beginning: which one?

Since it was driven by graphics, the target was the CPC only, at first. When I started the sales discussions later, it was clear that it had to be ported to at least the C64 (it was then converted to C64 by Thorsten Deuter). Due to its large success, it was also ported to Sinclair Spectrum (Holger Ahrens and Volker Marohn), Amiga (reLine's Holger Gehrman and me), and, my favourite version, Atari ST (Gisbert Siegmund). 

Mission Elevator for the Commodore 64.

Were you involved in the programming of the ZX Spectrum, C64 or Amiga versions? Some websites listed you as coder for the Amiga version, others listed you as coder for the C64 version, but others just credit you with the design of the game.

I was not involved as a coder (except for the Amiga version), but of course it was always a cooperation, explaining the original game logics etc. At that time, I was the Development Director of Magic Bytes, which was the wonderful group of graphic artists and programmers that created the conversions along with other great games. I want to credit this team here, because the conversions were already a team effort. Magic Bytes were: Bettina Wiedner & Hartwig Niedergassel (Graphics), Joerg Prenzing (C64), Gisbert Siegmund (Atari ST), Holger Ahrens & Volker Marohn (Spectrum und PC), and me (CPC & Amiga). 

Mission Elevator ad.

Another piece of trivia for our readers who don't know the early German gaming industry very well. Mission Elevator was published by Eurogold, which was a sister company of Rushware if I am not mistaken, with license by Micro Partner. Up to 1986, Micro Partner was also owner of Rainbow Arts, but you and Herr Meiertoberens parted ways with Marc Ullrich, leaving him with the Rainbow Arts name, and you end up founding Magic Bytes later. How did you feel in these tumultuous times? It probably was hard for you to have your best game up to then in your hands but had to look for another way to publish it.....

Wow, you did your research. That timeline is entirely correct. The split into two companies at the very beginning was very unfortunate, and seen from today's view, very unprofessional. Marc & Thomas were very different characters. Marc strived to build a professional setup with Rainbow Arts from the very beginning, while Thomas and I felt more like creative renegades (we were only 18, after all). We unnecessarily parted ways over the license of the cartoon game "Werner". Marc's approach with Rainbow Arts proved to be more sustainable. Caused by financial difficulties with micro-partner/Magic Bytes in late 1988, the Magic Bytes group (the people mentioned above) switched over to Rainbow Arts, but under its own label, "Golden Goblins" (the most prominent games of which are Grand Monster Slam and M.U.D.S). I left that group and said good bye to game programming in 1989 after programming Grand Monster Slam. 

"Making of", Data Welt 9/86. Scan courtesy of cpcmaniaco

And it truly had an amazing reception. It was probably one of the very first German games that achieved moderate success outside of Germany! How was the feedback you got back then? How did you feel when the reviews started to arrive?

Oh, it felt glorious! Mission Elevator was indeed a success in Europe, parts of the Middle East and Australia. The "Happy Computer" review, which wasn't stellar but very good (86/100), was framed in my office. But it is more now than at that time, that I get recognized for the game (e.g., this interview). In the last 15 years I have met people all over the world, who remembered the game from their childhood. To see that the game has brought a bit of joy into such different corners worldwide is a wonderful experience.

Review in Happy Computer

If we may ask: could one make a good living with the earnings of Mission Elevator?

Mission Elevator was, for a high school kid, a huge shot. We are not talking millions, but low 6 figures in German currency. Unfortunately none of the other games approached that level. However, Mission Elevator did pay entirely for my college years (I studied Applied Math after leaving the gaming scene), which gave me a lot of freedom to do other things I loved (mainly, making music). It also gave me the freedom to stay at the university as a student for quite a while. I finished with a PhD in Applied Math, then first co-created a VoiceOverlP startup, then changed to academia as a Computer Science professor/researcher in Philadelphia, USA, and returned to Germany in 2015 to work for different technology (Al/Computer Vision) startups. I am currently working for a company that is related to video gaming, although not programming games, but doing Al R&D. You will hear from it some time soon :-) . 

Amtix´s review of Mission Elevator

We already spoke about the founding of Magic Bytes. One of the early Magic Bytes games was Western Games. "Games" was already popular thanks to titles like Winter Games, Summer Games or California Games. Sounds like you wanted your jump on that wagon :). What can you tell us about the development of this game?

Yes, with "Western Games" and "Circus Attractions" we wanted to be part of the “games”-success. These games are comparably easy to program, they are mainly a collection of mini games, the work can be distributed to different programmers in parallel, the programming is less complex. Western Games was tailored to the CPC, it had large, beautiful still graphics with smaller pockets of animation, so it featured the CPC graphics setup pretty well. Bettina, again, created stunning cartoon graphics on the CPC. The process was to draw each scene on paper, to copy it to transparent paper, which was then put onto the screen, to be pixel-copied.

But: Western Games is one of the sad game examples, where there is a nice idea, great graphics, but lack of playability—which is my responsibility. I designed this game way too hard, it is nearly unplayable. And, different from Rainbow Arts, we didn't have professional game testers, something Marc had brought into his company. 

Western Games for the Amstrad CPC.

How was the creative process? I am pretty sure you had a laugh imagining how would be a "western olympic games" *laughs*

A big laugh, in fact. I remember that we got complaints from neighboring offices, that "there is too much laughter in our premises”, no joke. Especially the development of Grand Monster Slam, mainly with graphic artist Hartwig Niedergassel, who brought the characters of the game to life through graphics and hilarious background stories, was a long standing source of joy. But, yes, Western Games surely also was built on fun ideas of the Magic Bytes team. 

Which machine was the target when designing the game? Did you already have your mind on the new 16 sensational machines or did you still believe in the good old Schneider CPC and the C64?

Western Games really had the CPC in mind, to feature its graphics capabilities. We still started from there, porting to the 16bit machines later. 

Original Sketch by Bettina Wiedner. Scan courtesy of Rolf.

Was Western Games the last one you programmed for an 8 bit machine?

Yes, it was. After that I migrated to the Commodore Amiga and Atari ST. For Amiga, I programmed "Grand Monster Slam". The M68000 source code made it to the internet, it's actually interesting to read. I had replaced the entire BIOS of the Amiga, the game has its own hardware (e.g. disk loading) routines, plus, of course all the game logic. There is an unanswered question about that game: can the dwarf ever make it to the finals? You will find the answer in the code.

Original Sketch by Bettina Wiedner. Scan courtesy of Rolf.

You did later a lot of design and production works for other titles from Magic Bytes and a bit of 16bit programming and sound. How was adapting to those 16 bit monsters compared with the limited 8 bit machines?

The new hardware was interesting and challenging, especially the Amiga, with its special chips. It was still manageable, and it offered a glimpse into things to come. The bit-blitter was an early graphics support chip, and the sound chip played samples, what a step forward! However, with such graphics capabilities and all programmers longing for realism (there is the term "cinema envy" for that time, which I find fitting), game creation went into a less charming direction. 

Evolution. Courtesy of Rolf.

Did you ever learn good tricks during your time as an 8 bit programmer that helped you later in your career? Did the constant fight for memory and processor cycles help you later to produce better games in bigger machines?

Later in my career as in programming 16bit machines: yes. Of course we went to the limit of memory and clock cycles with these machines as well, the approach was still the same: optimize the code to the hardware wherever you can. But there was a difference: with the better machines came games from competing companies (mainly USA and Britain), which required a different knowledge and mind set: real 3D games. They required some math and approaches which at the time were far above my head.

Later in my career as a scientific computer vision/Al researcher: the deep understanding of computers and their architecture was sometimes helpful, when it came to optimization of data structures etc. Otherwise, thinking in bits was already outdated in the 90s. However, I still like programming microcontrollers for maker projects, and with these little machines (ESP/Arduino etc.) the 80s experience is very helpful. 

Rolf Lakaemper nowadays. Photo courtesy of Rolf.

How was your coding setup in Magic Bytes? (hardware, software). Did you develop your own customized tools as well or were you happy with out-of-the-box software?

As mentioned before, the 8 bit computers were still programmed in place, i.e. on the same machine. That changed with the 16 bit computers: I had written my own compiler/debugging tool on an Atari ST, that was connected via parallel printer port to the Amiga. I edited code on the Atari ST, and ran/debugged it remotely on the Amiga. 

Which of your games are you most proud of in general and for the Schneider CPC in particular?

That would be Mission Elevator on the CPC. A game written without any publishing interests in mind, that nevertheless started a lot. Plus my last game, on the Amiga, Grand Monster Slam. Bringing Hartwig's graphics to life was an exciting process, plus it's the most playable of my games (still very hard, though, sorry!) 

Amstrad Computer User´s Review

With the knowledge you have nowadays: would you have done anything different in the past?

We all have done the same mistake: re-inventing the wheel a thousand times. There were a lot of solutions available for many problems we struggled with, but that's easy to say now. There was zero information, no community, no media to exchange thoughts. So, how would we have known that a lot of computer science knowledge already existed for decades, of course mostly in academic environments? So, before jumping into the cold water of a new project, I could have looked left and right a bit to see what kind of tools, support, and algorithms were already available.

Plus: I would put way more effort into playability. The usual process of publishing 8bit games was: finishing way after the deadline, basic functionality testing, publishing. That changed in later years, e.g. RainbowArts had seen the necessity of game testers, which already during the development process would improve the playability. Nowadays games of course live from the story, the atmosphere, the playability, not from technological gimmicks. The old games unfortunately and frequently not so much, except for the few (a positive example here is "Prince of Persia", with a development that was driven by game atmosphere and story).

Mission Elevator review in Amstar Magazine 2, 10/86

Do you  still keep any of your old coding setups, discs, code, etc? If so, they belong in a  museum!

Yes, I still have most of the old codes, notes, graphics. And, probably, yes, a museum would be a better place than my book shelf.

Were you able to publish all of the games you worked on, or were there any MIAS that were not published?

No, unfortunately there are no secret jewels waiting to be discovered!

Loading screen on Amstrad´s original color screen

Do you hear the call of the assembler? Will we see in the future another nice and fun game by the legendary Rolf Lakämper for the good old 8 bit machines?

I do feel an itch, for sure. But not so much to program for the old machines, but to bring games to microcontrollers with their different kinds of inputs and outputs.

However, professionally I currently develop programs for Computer Vision and Al. Please no assembly language there...

What's your opinion on this "retro revival"? Do you follow the new creations for the classic machines?

I recently started to do so, as soon as I became aware of it. I am fascinated by what current programmers get out of nostalgia machines, and I love the return to charming 8 bit characters. 

Mission Elevator on original Amstrad color screen

Let me thank you again for your time and your kindness. Is there anything that you would like to add for our readers?

I have to thank again for the opportunity to talk nostalgia. To add for the readers: in times of overwhelming progress in computer technology and seemingly endless resources, to think back to the simple beginnings, and especially to put myself back into a "reduced setup mindset", can be a meditative and fulfillingly humbling experience. So, for the creators, graphic designers, programmers, musicians, artists, engineers among the readers, try, if you haven't done yet, the experiment to deal and work with simplicity. Find the beauty in moving a single pixel (as an exercise: look at the animation of "Lemmings", Amiga version, 1991, for about 1 hour), and withstand the call of "cinema envy" :-).

Slam And Roll es un arcade de plataformas bidimensional de “pantalla única” (matizaremos esto más adelante) creado por Kaleido Games y disponible para PC en Steam, Xbox y Nintendo Switch, siendo esta la plataforma en la que lo hemos probado, en su versión 1.1.10.

Slam and Roll es un título que lleva bastantes años en desarrollo. Hemos podido seguir su evolución probándolo en ferias como Retro Parla. Si bien, en un principio podía parecer un clon de Snow Bros., el juego ha evolucionado hasta convertirse más en un homenaje, incorporando mecánicas que no estaban disponible en aquél, y que también lo convierten en una experiencia más consolera.

Menú principal

Precisamente por ello, me enfrento a la que, quizás, sea la reseña más difícil que he escrito hasta el momento. Por conocer personalmente al autor. Por haber visto cómo crecía el juego. Porque quiero ser justo y honesto tanto con el autor como con los lectores, y no sé si seré capaz de transmitir mi idea sobre el juego en un puñado de párrafos sin que me lluevan palos de uno y otro lado, en un mundo en el que, por desgracia, estamos ya más que acostumbrados a que las palabras se retuerzan para sacarlas de quicio en uno u otro sentido. ¡Vamos allá!

Probablemente nos aburriremos de ver esta pantalla, pero no es un juego injusto

Lo primero que haremos al comenzar a jugar es seleccionar nuestro avatar. La mayoría de ellos no estarán disponibles desde un principio, ya que el objetivo del juego es recorrer las diferentes pantallas y acabar con los enemigos de final de etapa, que los tienen secuestrados. Cada avatar tiene unas características determinadas, que podemos amoldar a nuestra forma de juego, así como personalizaciones estéticas, que también iremos desbloqueando según avancemos.

Un nuevo deportista liberado con el que podremos jugar

Lo siguiente es escoger el modo de juego: El modo tour es el más consolero. Tenemos que superar cada pantalla (de las 112 diferentes) con una única vida, pero el progreso se mantiene una vez que la completemos. La puntuación de estrellas (desde tres hasta ninguna) dependerá del número de golpes que hayamos empleado para superar la pantalla. Hay que decir que, jugando a dobles, resulta más sencillo conseguir la máxima puntuación por motivos evidentes. El modo arcade es más parecido a esos clásicos como Bubble Bobble, Pang!, Tumblepop o el ya citado Snow Bros., donde dispondremos de un número limitado de vidas y créditos para completar las 53 pantallas. Hay un modo arcade difícil que, de primeras, está bloqueado. Y, por último, el modo caos, con una combinación de 20 pantallas que va cambiando cada 10 días.

La mecánica es sencilla de entender, pero difícil de dominar. Con nuestro personaje tendremos que dar “bolazos” a los enemigos hasta dejarlos atrapados en una “bola grande” (entendiéndose como “bola” el objeto correspondiente de cada uno de los diferentes deportes representados: hockey, fútbol, baloncesto, tenis, etc.). Una vez atrapado un enemigo, le damos un golpe a la bola y esta empezará a rebotar por la pantalla, llevándose por delante todo lo que pille. Si somos lo suficientemente hábiles, tal y como avanzábamos, para limpiar la pantalla de enemigos de un único golpe, conseguiremos las tres estrellas.

Casi... pero no hemos conseguido la perfección en esta pantalla

Acabar con los enemigos también nos permitirá recoger, si llegamos a tiempo, diferentes objetos que potenciarán nuestras habilidades. Pero, ojo, el efecto de esos potenciadores desaparecerá en cuanto nos maten.

No obstante, si es la primera vez que jugamos, tenemos la oportunidad de seguir un tutorial en el que, el Dr. McLabby, nos mostrará las diferentes mecánicas disponibles.

Se agradece un tutorial rápido para conocer las mecánicas

Las diferentes pantallas tienen como escenario distintas localizaciones geográficas a lo largo y ancho del planeta. Resulta imposible no acordarse de Pang!. La cuestión es que las pantallas suelen contar con bastantes plataformas, así que el trabajo gráfico con los fondos queda algo deslucido, ya que no se pueden apreciar en todo su esplendor.

En el modo tour, no todas las pantallas estarán disponibles; algunas tendremos que desbloquearlas mientras jugamos. Además de las siete zonas, hay una octava zona oculta que sólo resultará accesible cuando hayamos recolectado una cantidad mínima de estrellas.

Esta es la forma de obtener objetos secretos (y desbloquear pantallas)

Precisamente esa última zona oculta es la que más nos ha gustado, aunque todavía no hayamos conseguido completarla (y, por tanto, el modo tour). Su diseño de niveles se aleja de la “acción monopantalla” y se acerca más a un plataformas de acción, en el que tendremos que ir planificando y memorizando los siguientes pasos para superar cada pantalla. ¿Quizás podría ser el germen de una secuela?

A diferencia de los títulos clásicos que mencionábamos en el primer párrafo, Slam And Roll implementa un sistema de zoom dinámico, de tal forma que lo acomoda a la posición de los dos jugadores (si es que estamos jugando en cooperativo) y se acerca o aleja de la acción según corresponda.

No podía faltar la clásica fase de bonus de recolección

En un juego de este estilo, gráficos y música están al servicio de la jugabilidad. En este caso la complementan perfectamente. Quizás en alguna pantalla concreta alguna plataforma resulta un poco confusa, pero suelen estar bastante bien diferenciadas, para saber dónde podemos saltar y por dónde no podremos pasar. Las voces digitalizadas a veces resultan un poco machaconas, pero creemos que conforman la propia personalidad artística del juego, junto con el estilo gráfico empleado. La interfaz está disponible en 10 idiomas diferentes, lo que denota un gran esfuerzo de localización.

Este mensaje no necesita traducción alguna

Por ponerle un pequeño pero, la mayoría de enemigos implementan patrones de comportamiento que recuerdan bastante a los de Snow Bros. y, al haber divergido la jugabilidad, quizás no encajan tan bien. También ocurre lo mismo con algunos jefes finales.

El título dispone de tabla de puntuaciones online, que siempre supone un acicate para volver al juego y superar nuestro desempeño en pos de una posición más alta en el ranking. También, en aras de la rejugabilidad, podremos anotarnos la consecución de hasta 50 logros.

Vamos a durar poco tiempo tan arriba de la tabla

En definitiva, Slam And Roll nos propone una experiencia arcade para la que ofrece diversas aproximaciones: bien partidas rápidas (más o menos rápidas según nuestra habilidad) para superar nuestra mejor puntuación (o la de otros jugadores en el ranking global), bien un “modo historia” que ir completando con calma, a la par que vamos desentrañando todos sus secretos, pero que en ningún caso será un paseo. Desde luego que vamos a sudar la gota gorda para conseguir todos los trofeos y escalar a una posición de honor en la tabla de mejores puntuaciones mundiales.

Agradecemos a Jaime Domínguez tanto habernos facilitado el código de descarga para probar el juego como su disposición para charlar sobre diversos aspectos del mismo.

El pasado 15 de octubre se puso a la venta para consolas Switch, PlayStation 5 y Xbox Series, Nikoderiko, un plataformas de desplazamiento lateral con algunas concesiones en 3D libres, que bebe muy fuerte de clásicos del género. Diseñado por VEA Games, un estudio con sede en Chipre, el juego se presenta como "una carta de amor a los plataformas" que no hace realmente nada mal, pero que al final tampoco destaca por su excelencia. Probamos la versión para Switch y estas son nuestras impresiones.

El enfrentamiento contra el primer jefe no será muy complicado

Estamos seguros que desde la primera hoja de producción debió estar claro que la fijación por las entregas de estos juegos iban a tener mucho peso a la hora de darle forma a esta aventura plataformera, colorida y muy en sintonía de los títulos que aparecieron para las susodichas series. Quizás lo malo estribe en que para todos aquellos que ya conocieran los trabajos realizados por RARE, Retro Studios, Ubi Soft o Naughty Dog, no se van a dejar sorprender en lo más mínimo, pero también es cierto que nuevos jugones están en su derecho a disfrutar de un género que no pasa de moda, que suele ser siempre muy jugable y que, además cuenta con personajes diferentes (faltaría) y un modo cooperativo al que siempre aplaudimos en RetroManiac.

El modo cooperativo siempre es un aliciente

Pero comencemos por el principio: Niko y Luna son dos mangostas con aires de piratas que tras su última aventura descubren un gran tesoro. Por desgracia, la armada de Grimbald Cobring estaba esperando la ocasión y roban dicho tesoro en las narices de nuestros dos héroes, dejándoles con un buen palmo de narices. Toca recuperarlo atravesando para ello un buen puñado de niveles ambientados en zonas tan típicas (como tópicas) como pueden ser la playa, unas minas, las planicies desérticas o las montañas nevadas.

No podían faltar las "monturas" que nos ayuden en nuestro avance

Ya desde el principio los diseñadores apuestan por un desarrollo prácticamente calcado al de la saga Donkey Kong Country, en el que el desarrollo lateral con gráficos poligonales, se entremezcla con fases más o menos plataformeras, repletas de secretos, bonus y objetos a recoger, entre los que se cuentan unas letras (NIKO), que son prácticamente idénticas a las del juego de Nintendo. Aderezado luego con algunas sorpresas intrafases, como persecuciones, laberintos de lianas, cañonazos o los cambios de perspectiva, el juego se va desarrollando cautivando al jugador gracias a un exquisito nivel gráfico y un diseño de niveles que siempre roza el notable, con algunos puntos que podrían llegar al sobresaliente.

Los escenarios están muy bien ambientados y gozan de gran acabado

Los cambios de perspectiva, en los que manejaremos a nuestro protagonista con más libertad al estilo Crash Bandicoot, poseen menor peso en la aventura pero lo cierto es que están bien resueltos gracias a la suave transición que se suele dar entre el desplazamiento lateral y el que oscila en el eje Z de la pantalla. De hecho, hay algunos momentos de persecución hacia la pantalla en los que es imposible no retrotraerse a la saga de Naughty o, mejor aún, a esa fase infernal del juego del Rey León para la 16 bits.

Una persecución en medio del nivel de las cavernas al estilo Crash

Y es que quizás la crítica más grande en el juego podría ser precisamente esa: la total falta de originalidad. Todo es tremendamente parecido a los juegos sobre los que se basa, en exceso, y apenas hay alguna nota de personalidad aquí y allá. ¡Hasta el diseño gráfico es demasiado parecido a los últimos Donkey Kong Country y la banda sonora es obra del mismísimo David Wise! Que levante la mano el primer juego que sea realmente original. Si obviamos este aspecto, podremos disfrutar de una aventura repleta de colorido y buen hacer, que incluye carretillas en minas, persecuciones de dragones, niveles acuáticos y enfrentamientos a jefes fin de fase.

Algunos efectos gráficos de diseño también os recordarán a Donkey Kong o Rayman

Y para lograr llegar a nuestro objetivo, contaremos con un par de movimientos y algunas habilidades: saltar, caer en picado, flotar un poco en el aire gracias a un paracaídas, "chorrearnos" unos metros por el suelo... Incluso podremos encontrarnos con algunas monturas que nos harán más apacible nuestro avance gracias a sus capacidades de ataque. Las vidas infinitas y los generosos checkpoints, provocarán que tampoco sea muy complicado avanzar, aunque si queremos de verdad descubrir todo lo que se oculta en cada uno de los niveles, recoger todos los objetos y llegar hasta la meta, entonces la cosa sí que se complica un grado.

¡Acaba con ese maldito caldero mágico!

La versión Switch, que es la que hemos disfrutado, adolece, ese sí, de unos tiempos de carga bastante largos y un framerate algo irregular debido a su origen en el Unreal Engine. Los 30 frames por segundo inestables, nos jugarán a veces malas pasadas en conjunción con el movimiento algo nervioso del personaje, tenedlo en cuenta. Por otro lado, aún después de aplicar el consabido parche de actualización, aún siguen apareciendo algunos bugs aquí y allá que en ocasiones nos han obligado incluso a reiniciar el nivel por quedarnos encallados. Esperemos que esto lo puedan arreglar cuanto antes en VEA Games.

Nikoderiko: The Magical World es un plataformas que mezcla tipos de desarrollo y que se inspira muy fuerte en viejos conocidos del lugar. Si pasamos por alto su falta evidente de originalidad y que, casi, casi, podría ser un "reskin" de Donkey Kong Country, encontraremos un título muy resultón, divertido y estéticamente atractivo. Puede que con algo más de esfuerzo en la planificación, en intentar hacer algo distinto, VEA Games podría haber llegado a sobresalir y hacerse un hueco entre los grandes del género, pero mucho nos tememos que el podio no lo ha podido alcanzar. Sin embargo, a poco que seáis amantes del género plataformero, que queráis dejaros llevar por algo de la vena viejuna sin olvidar el presente, y que os embriague la banda sonora de Wise (aunque no al nivel de la saga en RARE), no dejéis de echarle un tiento, porque Nikoderiko no os va a decepcionar en lo más mínimo.

Muchos de los desarrolladores que pasaron a la historia de los videojuegos por méritos propios comenzaron sus carreras en máquinas de 8 Bits. Hoy conoceremos un poco más en profundidad la trayectoria ochobitera de Tony Warriner, cofundador de Revolution Software, y sus inicios profesionales con el —entre otros— Amstrad CPC.

 English interview after the spanish text.

Antes de nada, permítenos darte las gracias por tu amabilidad en aceptar esta entrevista. Empecemos por el principio: ¿cuándo empieza tu interés en la tecnología?

¡De nada! A vosotros. Fue hace mucho tiempo, pero yo debía tener unos 12 años cuando empecé a trastear con electrónica aficionada, construyendo radios de galena y cosas por el estilo. Un año o así más tarde, empezaron a aparecer ordenadores como el Sinclair ZX81, y ¡esto me parecía mucho más interesante!

¿Cuáles fueron las primeras máquinas que entraron en tu hogar?

Mi primer ordenador fue un Camputers Lynx, que de hecho era una elección bastante poco usual. La mayoría de mis amigos tenían un Spectrum o un Commodore 64.

Camputers Lynx By Retro-activity, CC BY-SA 3.0

¿Cómo entró el Amstrad CPC en tu vida?

Bueno, estuve con el Lynx un par de años —era muy bueno para aprender a programar el Z80— antes de decidir dar el salto al Amstrad, que durante un tiempo fue el nuevo ordenador molón que había que tener.

¿Qué te gustó de él? ¿Qué no te gustó?

Para mi tenía muy buena pinta ya que también tenía un Z80 pero venía con un monitor en condiciones y un teclado muy decente y pronto aparecieron disquetera y disquetes. En realidad no había nada que odiase de él. Era una pena que llegase un poco tarde al mercado.

Normalmente solemos ver que los desarrolladores estáis influenciados en el comienzo de vuestras carreras por aquellos juegos que os marcaron a edades tempranas. ¿Cuáles eran tus favoritos?

Esto es muy cierto. Jugamos un montón al Elite en Commodore 64 así como a los juegos de Llamasoft, tales como Matrix y el Revenge of the Mutant Camels. En Amstrad estaba obsesionado con Sorcery y Get Dexter en particular.

A muchos de nosotros nos bastaba con jugar. ¿Qué te motivó a querer crear tus propios juegos?

Estaba cautivado por la idea de que podías crear de la nada prácticamente cualquier cosa. Tenías un mundo de posibilidades en las yemas de tus dedos. Aún me siento así y no he encontrado ninguna otra cosa tan buena.

Primera edición de NILUG

Una cosa es pensar «quiero hacer mis propios juegos» y otra es ser capaz de hacerlo. ¿Qué recursos tenías para aprender a programar? Sospecho que no tenías entonces acceso a Google o a GitHub *risas* 

De hecho fue bastante antes de que apareciese Internet ;) Todo lo que teníamos eran las revistas, manuales y libros y, en mi caso, una lista de correo para el Lynx llamada NILUG que solía traer buenas lecciones de ensamblador. Parece que muchos programadores inventaron durante años las mismas técnicas de programación independientemente los unos de los otros. El autismo también era un súper-poder; no podía entender nada de lo que me enseñaban en la escuela, pero podía programar una CPU en código intermedio sin problemas.

¿Cuándo te das cuenta de que tu código es lo suficientemente bueno como para intentar venderlo? 

Hice un par de juegos que no eran lo suficientemente buenos, pero siempre creí que acabaría lograr llegar ahí. Una vez que empecé a trabajar en Obsidian estaba convencido al 100% de que alguien lo publicaría. 

Tony posa con la portada de Obsidian

Ya que por entonces aún no existía Kickstarter: ¿Qué pasos tomaste para encontrar a un editor para tus programas o un lugar dónde trabajar?

Básicamente era como estar en un grupo musical: ¡necesitabas un cassette con una demo! Hice unos cuantos, escribí unas cuantas cartas de presentación y lo envié a diferentes editoras. Así es como se hacían entonces las cosas.

¿Cómo entras a trabajar en Artic Computing?

Mi madre encontró un anuncio suyo en las páginas amarillas locales. Yo les conocía, pero no me había dado cuenta de que estaban en mi zona.

¿Cómo era tu equipo de desarrollo por entonces? 

Cuando hice Obsidian no tenía nada. Hice el código en papel y luego introduje los bytes hexadecimales usando un editor que hice yo mismo. También hice el programa de diseño con el que dibujé todos los sprites. Pero lo más importante fue la disquetera de 3" de Amstrad. Era como la noche y el día respecto a velocidad y fiabilidad. 

Obsidian en acción

¿Qué nos puedes contar sobre Obsidian? ¿Cómo fue el proceso creativo? ¿Cómo decidiste cosas como el diseño de niveles, las mecánicas jugables o los gráficos? 

Estaba muy influenciado por Sorcery, que tenía un escenario de fantasía, así que yo tomé el camino del espacio y la tecnología pero mantuve el rollo videoaventura arcade. En realidad no diseñé nada; simplemente me puse a implementar cosas y más o menos así fue creciendo hasta convertirse en un juego acabado. El estilo gráfico se inspiró en el Paradroid de C64.

Obsidian fue tu primer juego comercial. ¿Cuáles fueron tus principales retos? ¿Cómo los solventaste?

¡El principal problema fue corregir todos los bugs que Artic seguía encontrando cuando yo les enviaba las versiones finales! Debido a la manera tan loca en la que introduje el código, durante un tiempo todo estuvo en el filo de la navaja.

Pantalla de carga de World Cup Carnival

¿Cómo acabaste trabajando en el World Cup Carnival? 

Tras acabar Obsidian, me ofrecieron trabajo en Artic. De hecho, mi primer proyecto fue el juego de México 86. ¡Poco me daba cuenta de los problemas que estaban fermentando en ese proyecto! 

El juego estaba dividido en dos partes y tú hiciste la parte de entrenamientos. ¿Qué nos puedes contar sobre su desarrollo?

Sinceramente, no recuerdo gran cosa. No obstante Adam Waring, el otro programador, me dijo de usar un ensamblador de verdad a la hora de programar ¡lo que fue una revelación! Nuestro trabajo fue sencillo y rápido dado el alcance de los minijuegos.

¿Cuan estricta fue US Gold controlando vuestro trabajo?

Nada especial según recuerdo. ¡Pero se acababa el tiempo antes de que empezase el Mundial en sí!

¡Gol!

No que supiésemos.

Ya conocías a Charles Cecil cuando este funda Paragon Programming. ¿Cómo entras ahí? 

Bueno, Charles me dio el trabajo en Artic. Cuándo decidió fundar su propia empresa para hacer conversiones para US Gold, necesitaba programadores, así que me fui con él a la nueva empresa.

¿Cuántos trabajabais ahí? Tengo especial interés en saber quienes formabais el equipo Amstrad, ya que muchos de vuestros juegos no tienen créditos. ¿Recuerdas por ejemplo quién convirtió al CPC The Goonies?

The Goonies: Pasado al CPC por Paragon Programming

Hablemos de Black Magic. ¿Convertiste simplemente el juego de Data Soft o pudiste influir en su diseño? ¿Estuviste también involucrado en la conversión a Spectrum? 

¡Lo único que hicimos fue jugar a la versión de C64 y escribir un juego que fuese igual! No teníamos nada más con lo que trabajar. Sí hice la versión de CPC —y creo que fui yo quien la hizo— entonces es bastante posible que también hiciese yo a la vez la de Spectrum.

¿Os enviaba Data Soft algún tipo de material para trabajar? ¿Compartían con vosotros código o gráficos de sus juegos?

Hasta donde yo recuerdo, nada de nada. Tal vez algunos mapas impresos, pero nada de código o gráficos.

Black Magic y su cambio de modo. Fuente: CPC-Power

Vemos una evolución tuya como programador en este juego. Por ejemplo, usas varios modos de pantalla simultáneos. ¿Cómo aprendías estos trucos nuevos? ¿Seguías formándote comprando nuevo material como libros o revistas? ¿Pudiste tal vez compartir algunos trucos de programación con otros programadores? En caso afirmativo: ¿con quién?

¡Ah, el cambio de modo! Creo que aprendíamos esas cosas de boca en boca. Alguien nos lo contó. Recuerdo una vez que estábamos en una empresa de duplicado de cintas organizando los masters de alguno de nuestros juegos y hablamos con los programadores que se encargaban de ese trabajo y aprendimos un montón de trucos interesantes. Esa gente solía trabajar con un montón de gente diferente y debido a ello sabían muchísimo. 

Paragon Programming era una empresa más profesional. ¿Cómo era tu equipo de desarrollo?

Igual que en Artic: máquina objetivo con disquetera. ¡Profesional es quizás una palabra demasiado buena para definirlo!

Cambiaste de género con Ultima Ratio. ¿Qué os lleva a hacer un shooter? 

Artic estaba desesperada por dar un pelotazo y todos decidimos que quizás un shooter sería un buen genero para darlo. Decíamos que podríamos hacer un scroll a pantalla completa flipante en el CPC ¡que resultó no ser cierto, lo cual era desafortunado!

Ultima Ratio. Nótese como usa los bordes verticales.

¿Cómo diseñasteis los niveles, mecánicas, gráficos, etc?

Simplemente lo hicimos. No planeamos nada.

Vuelves a dar un paso de gigante programando el CPC, ya que aquí usas overscan vertical y los registros del CRTC para implementar scroll hardware. ¿Cómo aprendiste específicamente esos trucos?

Tal como recuerdo, esas técnicas se iban pasando de persona en persona en la comunidad y todos andaban intentando usarlas. Pensamos que podíamos lograr un scroll continuo con ellas, pero por desgracia nos equivocamos. Creo que en tiempos más recientes sí que la gente ha logrado sacarle un mayor partido.

Hace un shooter divertido es complicado debido al estilo de juego. ¿Cuáles dirías que han sido los mayores retos a los que os enfrentasteis?

Todo fue un reto debido a la falta de planificación y diseño, si te soy sincero. Adam y yo nos metimos en un cuarto oscuro a ver si lograbamos pegar un pelotazo. Eso fue todo. 

Fungus Warriors

También hiciste la versión de Spectrum. ¿Cómo te manejabas haciendo las versiones del juego para dos maquinas diferente sin volverte loco? 

Bueno, en realidad yo hice la de CPC y Adam hizo la de Spectrum. Compartimos algo de código y mapas y esas cosas. También aprendimos un montón con ese proyecto sobre optimización del Z80. Por ejemplo, mirábamos en el libro de Rodnay Zaks como funcionaban los T-States y nos dábamos cuenta de que deberíamos estar desenrollando bucles y cosas por el estilo. 

¿Qué nos puedes contar sobre Fungus Warriors? ¿Cómo fue el desarrollo de ese juego?

Este lo hizo mi amigo de la escuela, Mark Turner, el que vino a Londres para ser parte de Paragon pero se volvio a Hull y escribió Fungus Warriors por su cuenta.

¿Por qué Firebird no llegó a publicarlo?

Hay un montón de misterio alrededor de este juego. No estoy seguro del todo de que ocurrió, y nadie es capaz de dar con Mark Turner para preguntarle. Tengo una copia del juego casi completa —más o menos— y en la pantalla de carga dice: «¡Players Software!».

Sin nombre, publicado por Players.

El juego está preservado. ¿Sabes quién lo hizo?

El programador era Mark Turner. No sé como se ha preservado, no.

¿Estuvo también en desarrollo para ZX? ¿Qué pasó con él?

No que yo sepa.

Hablemos del que posiblemente sea tu juego más ambicioso: Death Stalker. ¿Qué nos puedes contar sobre su desarrollo? ¿Cuáles eran sus inspiraciones?

Este juego vino un montón despues, y estuve trabajando en Cascade Games y me traje de la empresa un sistema de desarrollo PDS para Amstrad y Spectrum. Me volví a Hull y junto a Adam Waring —y otro compañero de la escuela: Gareth Baker—  fundamos TAG. Yo hice Death Stalker, Adam hizo Ninja Massacre y Gareth hizo Moving Target. De nuevo, no es que tuviéramos ningún plan o diseño para esos juegos; simplemente empezamos a trabajar en ellos. 

Death Stalker

¿Cómo decidisteis cosas como el diseño de niveles, las mecánicas jugables, el estilo gráfico, etc?

¿Por qué elegisteis a Codemasters para publicarlo? 

Suponíamos que eran el mejor editor, así que le enviamos nuestras demos. Le gustaron los juegos y se ofrecieron a publicarlos. En ese momento nos asignaron productores de Codemasters y de hecho intentaron organizarnos hasta cierto punto. 

¿Qué nos puedes contar sobre 19 Part 1: Boot Camp? ¿Fue una simple conversión desde C64 o pudiste influir en su diseño?

Ahora volvemos en el tiempo a justo antes de fundar TAG y Death Stalker. 19 fue un juego para Activison y estuvo muy bien organizado en comparación con cualquier cosa de esta historia. Teníamos un productor en la oficina que se encargaba de que todo avanzase constantemente. A mi me asignaron la parte de los obstáculos del juego para ZX y simplemente trabajé en el diseño que había ya decidido de antemano. Todos los minijuegos fueron diseñados a la vez en C64 y ZX así que nada fue una conversión.

19 Part 1: Boot Camp

¿Cual fue su inspiración? ¿Se podría decir que se ve cierta influencia de Combat School?

No tengo ni idea, pero el juego claramente está relacionado con la canción Nineteen.

Eras un programador de CPC más que competente. ¿Por qué nunca se convirtió este juego al Amstrad?

Supongo que Activision no quiso una versión para CPC. Desde luego podríamos haberla hecho.

El juego lo publica Cascade. ¿Cómo acabas trabajando para ellos?

Lo publica Activision; Cascade lo desarrolla bajo contrato. Cuando Paragon echa el cierre —debido a la contratación de Charles Cecil como manager por parte de US Gold— me puse a buscar un trabajo de verdad y vi un anuncio de Cascade, que tenían las oficinas bastante cerca.

Arcade Trivia Quiz Simulator

Tras hacer un montón de juegos de acción divertidos, Arcade Trivia Simulator parece un paso hacia atrás. ¿Cómo acabaste trabajando en él? 

Nuestro problema en TAG es que siempre nos quedabamos sin dinero, a pesar de que Death Stalker y Ninja Massacre fueron grandes títulos que funcionaron bien en Codemasters. Decidimos qué hacer un juego de preguntas sería rápido —no lo fue— y que sería dinero fácil antes de volver a hacer las cosas que de verdad nos gustaban hacer. También pensamos que sería algo que Codemasters querría hacer, pero no nos pusimos de acuerdo con ellos en el diseño. 

¿Tuviste que ver en su concepción o simplemente os lo encargaron?

Fue idea nuestra.

Parece un juego que se podría hacer rápidamente. ¿Era ese el motivo de hacer un juego de preguntas?

Si, pero en la realidad ¡costó mucho preparar todas las preguntas!

Pantalla de carga de Death Stalker

Bueno, hice Obsidian cuando iba a la escuela y se suponía que tenía que estudiar para los exámenes. Posiblemente lo haría en unos 6 meses. Death Stalker fue más bien algo entre 4 a 6 meses de principio a fin.

Has trabajado en tus propias ideas y convertido juegos desde otras plataformas. ¿Qué te molaba más? ¿Qué ventajas y desventajas implicaban trabajar con tus propias ideas o simplemente convertir juegos desde otras plataformas?

Es mucho más fácil convertir juegos, pero no es algo que me produzca interés —salvo que sean mis propios juegos. Mi propósito en esta vida es traer nuevas creaciones.

El mundo de los videojuegos cambiaría a partir de 1990 con la creación de Revolution Software. Curiosamente, había todavía gente ganándose un buen dinero haciendo juegos para máquinas de 8 bits. ¿Qué te llevó a dar el salto a los 16 bits? Supongo que alcanzaste tus límites en los 8 bits y necesitabas más recursos para producir lo que tenías en mente. 

El sentimiento era que el mercado de 8 bits moría rápidamente y estaba siendo reemplazado por los 16 bits y con MS-DOS creciendo rápido. Nunca tuvimos en cuenta los 8 bits en Revolution. 

Beneath a Steel Sky

¿Qué tal fue adaptarse a esos monstruos de 16 bits en comparación con las limitadas máquinas de 8? 

En realidad no fue difícil. ¡Tenías resuelto de golpe los problemas de memoria y potencia de CPU! O eso parecía al principio. Para mucha gente, el problema fue que se embarcaron en proyectos mucho más complejos para usar toda esa potencia y tuvieron dificultades para acabar esos juegos.

¿Aprendiste algo durante tu época con los 8 bits que te ayudase más tarde con máquinas más grandes? ¿Dirías que la lucha constante contra la falta de memoria y el contar permanentemente los ciclos del procesador te ayudó a sacar un mayor partido al Atari ST o al Amiga? 

Sí, desde luego, y no solo por que seguimos trabajando en ensamblador; creo que todo programador de videojuegos debería empezar en una máquina muy limitada e ir pasando poco a poco a plataformas más avanzadas. Por supuesto, hoy en día ocurre todo lo contrario con gente que empieza en la universidad directamente en plataformas como Unity. 

¿Conservas todavía tus disquetes, código y máquinas? 

Tengo todavía mis dos CPCs y todos los disquetes de los años ochenta, sí.

Mr. Warriner y su Amstrad CPC

¿Pudiste publicar todos tus proyectos durante tu etapa como programador de 8 bits o se quedó algún título sin publicar? ¿Qué pasó por ejemplo con la versión de CPC de 19 Part 1 o la inédita parte 2?

En 1989 tenía medio acabado un juego para Codemasters llamado Brute Force, que era estilo Ghosts ´n Goblins pero que no se pudo terminar antes de que TAG se disolviera. El código fuente anda por el disco duro de un Amstrad PC1640 que todavía conservo pero no la máquina en sí, así que no puedo probar si todavía funciona :)

¿Podía ganarse uno bien la vida haciendo juegos de 8 bits?

En realidad no, pero en teoría hubiéramos podido si hubieras llegado a dar un pelotazo. Sigo trabajando en convertir esa teoría en realidad a día de hoy ;)

¿De cuál de tus juegos estás más orgulloso (en general y de 8 bits en particular)?

Supongo que Death Stalker fue el mejor juego de 8 bits que hice —aunque 19 Part 1 obtuvo un Crash Smash— pero Beneath a Steel Sky es mi favorito. También estoy muy orgulloso de la versión de GBA de Broken Sword.

¡Atentos a Kickstarter!

Ultimamente estás enfocado por completo en el Spectrum Next. ¿Hay alguna posibilidad de que vuelvas a darle amor al CPC? Nos morimos de ganas de ver que podría hacer hoy día el legendario Tony Warriner sin presiones de tiempo :)

*Risas* Gracias. De momento estoy con el Next y es una gran máquina, si acaso no trivial de programar. Me gustaría algún día escribir un juego del Spectrum de toda la vida, que podría convertir posteriormente al CPC, así que hay muchas posibilidades...

¿Qué opinas de este revival del retro?

De nuevo, muchísimas gracias por tu tiempo y tu amabilidad. ¿Hay algo que te gustaría añadir para nuestros lectores?

¡Estaos al loro! 

Muchas gracias a Tony por su amabilidad. ¡No os perdáis URB-X Warriors en Kickstarter!

First of all, let me thank you for your kindness in accepting this interview. Let's start from the beginning: When did your interest in technology start?

Thank you, no problem! It’s a long time ago, but I think I was around 12 years old when I starting playing about with hobby electronics - building crystal radios and the like. But then, a year or so later, computers like the Sinclair ZX81 started to appear and, to me, these were far more interesting!

Which were the first machines that entered your home?

The first computer I owned was a Camputers Lynx, which was quite an unusual choice. Most of my friends were with Sinclair Spectrum or Commodore 64.

Camputers Lynx By Retro-activity, CC BY-SA 3.0

What did you like about it? What did you hate?

For me it looked really good because it was also a Z80 CPU and came with a proper monitor and very decent keyboard with disk drives soon to appear. There was nothing to really hate. It was sad that it was slightly too late to market.

We usually find that game developers were heavily influenced at the beginning of their careers by the games they used to play at a young age. Which ones were your favorites?

This is very true. We played a lot of Elite on the C64 as well as the Llamasoft games, such as Matrix and Revenge of the Mutant Camels. On the Amstrad I was obsessed with Sorcery and Get Dexter, in particular.

For most of us, just playing games was fine. What motivated you to create your own games?

I was captivated by the idea you could just create almost anything from nothing. A world of possibilities at your fingertips. I still feel the same way and haven’t found anything as good.

Primera issue of NILUG

One thing is to think “I want to make my own games” and another one is being able to do it. What resources did you have at hand to learn how to code? I am assuming you didn´t have Google or GitHub *laughs*

This was indeed some time before the internet ;) All we had were magazines, computer manuals and books, and, in my case, a newsletter for the Lynx called NILUG which had some good assembly code lessons. It seems a lot of programmers invented the same techniques independently of each other for a number of years. Autism was a useful super power too - I couldn’t understand anything they were teaching me at school, but I could program a CPU in bytecode without a problem.

When do you realize that your code was good enough to try to sell it?

I wrote a couple of games that weren’t good enough, but I always believed I’d get there in the end. Once I started work on Obsidian I had 100% belief that someone would publish it.

Tony proudly poses with Obsidian´s Cover

Since Kickstarter didn't exist back then: which steps did you take in order to find a publisher for your works or a place to work?

It was basically like being in a band: you needed a demo cassette! I’d make a few of these and write a covering letter and send them out to different publishers. That is how it was done back then.

How did you end up in Artic Computing?

My mother found their advert in the local yellow pages telephone directory. I knew of them, but didn’t realise they were fairly local.

How was your Coding Setup back then? (hardware, software)

For Obsidian I had nothing at all. I worked the code out on paper then typed in the hex bytes using an editor that I wrote for myself. I also wrote the art program that I drew all the sprites on. But the most important thing was the Amstrad’s 3” floppy drive. It was a game changer in terms of speed and reliability.

Obsidian in action

What can you tell us about Obsidian? How was the creative process? How was things decided like level design, game mechanics or graphics?

I was heavily influenced by Sorcery which had a fantasy scenario, so I went for space and tech but kept to the Arcade Adventure genre vibe that it had. I didn’t really design it, just implemented stuff and it kind of grew, organically, into a finished game. The graphic style came from Paradroid, on the C64.

Obsidian was your first commercial published game. Which ones were the biggest challenges that you found during the development? How did you solve them?

The biggest problem was fixing all the bugs that Artic kept finding when I sent them ‘final’ copies! Because of the crazy way I’d typed the code in, the whole thing was on a knife edge for a time.

Loading Screen for World Cup Carnival

How did you end up working on World Cup Carnival?

After Obsidian was finished I was offered a job at Artic. The first task for them was indeed the Mexico 86 game. Little did I realise the trouble that was brewing for that project!

The game was divided in two, and you did the practice part. What can you tell us about the development?

I don’t remember much, to be honest. But Adam Waring, the other coder there, introduced me to the idea of using an actual ‘assembler’ program to build the code, which was somewhat of a revelation! Our work was quick and easy given the scope of the mini games.

How strict was US Gold controlling your work?

Not particularly as far as I remember. But time was running out before the actual World Cup began!

Goal!

The game had the endorsement from FIFA. Did they give any instructions about how the game should be? Did they control the final product?

Not that we ever knew of.

You already knew Charles Cecil when he founded Paragon Programming. How did you end up there?

Well, Charles gave me the job at Artic. When he decided to start his own company doing ports for US Gold he needed coders and so I just went with him to the new company.

How many people were there? In particular, I have interest in knowing how many of you were in the CPC Team, since there are same games who bear no credits. Do you know for example who converted The Goonies to the CPC?

There were only ever five or six in total. One of my school friends came along and he was a CPC programmer but soon decided to leave as he didn’t want to live in London. I am not sure who ported The Goonies, actually, but I’m pretty sure it wasn’t me!

The Goonies: Ported to the CPC by Paragon Programming

Let's talk about Black Magic. Did you just convert the Data Soft game to the Amstrad or did you have a say in its design? Were you also involved in the ZX port?

All we did was play the finished C64 version and write a new game that was the same! We had nothing else to work with. If I did the CPC versions - and I believe I did - then it’s likely I did the ZX version alongside.

Would Data Soft send you any kind of material to work on? Would they share their code or graphics from their games?

As I remember, not at all. Maybe some maps printed out. But no code or graphics.

Black Magic and multimode. Source: CPC-Power

We see an evolution in your programming tricks in this game. For example, you use Multimode graphics, using two graphic modes at the same time. How did you learn this new tricks? Did you keep educating yourself buying new learning material like books or magazines? Were you maybe able to share tricks with other CPC programmers? If yes: with who?

Ah yes, the mode switching! I think we learnt that one by word of mouth. Some coder somewhere told us about it. I remember once we were at a tape duplication company sorting out final masters for one of the games and we talked to the coders doing that work and learnt a lot of interesting things. Those guys got to talk to lots of different people coming in and were very well informed as a result.

Paragon Programming was a more professional company. How was your coding setup there?

It was just the same as Artic - target machines with floppy drives. Professional is probably too strong of a word for it!

You switched game types with Ultima Ratio. Why doing a shooter?

Artic were desperate for a big hit game and everyone decided a shooter would be a good genre to aim at. We were saying we could do some amazing full screen scrolling on the CPC which turned out to not be true which was unfortunate!

Ultima Ratio in Overscan

How did you design levels, game mechanics, graphics, etc?

We just did it - no real planning or anything.

There is another huge step forward regarding CPC programming, since here you did vertical overscan and used the CRTC registers to implement a kind of scroll hardware. How did you learn those CPC specific tricks?

As I remember, that technique was passed around the community at the time and everyone was trying to use it. We thought we could do a continuous scroll with it, but sadly we were wrong. I believe in recent years people have actually learnt to make more of it.

Doing a fun shooter is complicated because of the kind of game. What would you say were the biggest challenges you faced?

Everything was a challenge due to lack of planning and design, to be honest. Myself and Adam went into a dark room and tried to write a hit game - that was it.

Fungus Warriors

You also did the Zx Spectrum version. How did you manage to do versions of the same game for two different machines at the same time without ending crazy?

Well, I did the CPC version and Adam did the ZX. We shared some code and maps and so on. We also learnt a lot of Z80 optimisation on that project. We would look up T-States in the Rodnay Zaks book and realised we should be unrolling loops and so on.

What can you tell us about Fungus Warriors? How was the development of this game?

This was written by my school friend, Mark Turner, who originally came to London to be part of Paragon, but soon went back to Hull and wrote Fungus Warriors on his own.

Why did Firebird never publish it?

There’s a lot of mystery surrounding this. I am not completely sure what happened, and no one can find Mark Turner to ask him. I have a near complete copy of it (somehow) and the loading screen says Players Software!

No name, Players.

The game is preserved. Do you know who did it?

Mark Turner was the coder. I don’t know how it comes to be preserved, no.

Were also in development a ZX Spectrum version? What happened to it?

Not that I know of.

Let's talk about probably your most ambitious game: Death Stalker. What can you tell us about the development? What were its inspirations?

This game was a lot later on, and I’d been working at Cascade Games and came away from my employment there in possession of Spectrum and Amstrad PDS development systems. I went back to Hull and got together with Adam Waring (and another school friend, Gareth Baker) and formed TAG. I wrote Death Stalker, Adam wrote Ninja Masacre and Gareth wrote Moving Target. Again, we didn’t really plan or design those projects, we just started.

Death Stalker

How were things like level design, game mechanics, graphic art, etc, decided?

They weren’t :)

Why did you choose Codemasters for its publishing?

We figured they were the best publisher and so we sent our demo cassettes off to them. They liked the games and offered to publish them. At that point we were assigned ‘producers’ from Codemasters and they actually tried to organise us to some degree.

How about 19 Part 1: Boot Camp? Was that just a conversion form C64 or did you have a say in the design process?

Now we go back in time to just before TAG and Death Stalker. 19 was a game for Activision and was fairly well organised compared to anything else in this story. We had an in-house producer who kept everything running fairly smoothly. I was given the obstacle course section of the game on the ZX and just worked to a design that was already worked out. All the sub-games on C64 and ZX were being implemented at the same time so nothing was a port from anything else.

19 Part 1: Boot Camp

What was its inspiration? Do we see a little bit of Combat School influences here?

I’ve no idea, but obviously the game itself was tied to the hit pop song, Nineteen.

You were a competent CPC programmer. Why was this game never ported to the CPC?

I assume because Activision didn’t want a CPC version. We certainly could have done it.

The game was published by Cascade. How did you end up working with them?

Published by Activision, developed by Cascade under contract. After Paragon was disbanded (on account of US Gold taking Charles Cecil as their development manager) I went looking for a real job and saw an advert for Cascade, who were based quite close by.

Arcade Trivia Quiz Simulator

After doing a lot of fun action games, Arcade Trivia Quiz Simulator seems like a step back. How did you end up working on it?

Our problem at TAG was that we kept running out of money, despite Death Stalker and Ninja Massacre being great games that did okay for Codemasters. We decided that a pub trivia game would be really quick to do (it wasn’t) and would be easy money before we could get back to doing what we really want to do. We also thought it would be something Codemasters would want to do, but we couldn’t agree with them on the design.

Did you have a say in its conception or were you just commissioned to do the job?

It was our idea.

It seems like a game that could be done really quick. Was that the reason behind doing a Trivia Game?

Yes indeed, but it turned out writing all the questions was really hard!

Loading Screen for Death Stalker

Speaking about time: how much time would you have to do a project like Obsidian and how much for a more ambitious game like Death Stalker?

Well, I did Obsidian when I was at school and was supposed to be studying for exams. I probably wrote it over 6 months or so. Death Stalker was likely 4-6 months from start to end.

You have worked on your own ideas and ported games from other platforms. What was more appalling to you? What were the advantages and disadvantages regarding working with your own ideas or just converting games from other platforms?

It’s far easier to port games, but not something I have any interest in (unless they are my own games in the first place). My entire purpose in life is to bring new creative projects to fruition.

The gaming industry would change after 1990 with the founding of Revolution Software. Funny enough, there were still people earning good money developing for 8 bit machines. What motivated you to jump into the 16bit wagon? I am guessing, you reached your limits there and needed more resources to produce what you had in your mind.

The feeling was that the 8bit market was dying fast and being replaced by the 16bits with DOS coming along fast. We never considered 8bits at Revolution.

Beneath a Steel Sky

How was adapting to those 16bit monsters compared to the more limited 8 bit machines?

Not so difficult really. The twin problems of CPU power and memory were instantly solved! Or at least seemed to be at first. The problem for many people was that they embarked on far more complex projects to make use of all that power and then got into trouble trying to finish those games.

Did you learn anything during your 8 bit programming career that helped you later with better and bigger machines? Would you say that your constant fight against memory shortages and counting processor cycles helped you to bring out more form the ST or the Amiga?

Yes, absolutely, not least because we continued to code in assembly. I think any game coder should start out on a super limited machine and then move on to more advanced platforms. Of course, these days the very opposite happens with people learning platforms like Unity at college.

Do you still keep your old discs/code/machines?

I have both my CPC machines and all the floppy discs from the 1980’s, yes.

Mr. Warriner and his Amstrad CPC

Were you able to publish all your work during your time as 8 bit developer or are there any more MIAs that we should be looking for? How about 19 Part 1 for CPC or the unreleased 19 Part 2?

Back in 1989 I had a half finished a game for Codemasters called Brute Force that was rather like Ghosts and Goblins but was never finished before TAG exploded. The source code for that game was on the hard drive of an Amstrad PC1640 machine and I have the drive itself but no way to test if it still works :)

Did a programmer like you make a good living from programming 8 bit games?

Not really but in theory we could if we scored a hit game. I’m still working to that theory coming true at some point ;)

Which of your games are you most proud of? (8 bit in particular, all the games in general)

I suppose Death Stalker was the best 8bit that I wrote (although 19 was a Crash Smash), but Steel Sky is my overall favourite. I’m pretty proud of GBA Broken Sword, too.

Keep an eye on Kickstarter!

You are lately fully committed to developing for the Spectrum Next. Is there any chance that you would give again some love to the Amstrad CPC in the future? We are dying to see what could produce nowadays the legendary Tony Warriner when not under time pressure ????

Haha, thank you. I am on the Next at the moment, and it’s a great machine, if somewhat non-trivial to develop for. I’d like one day to write a pure ZX game which would port to CPC so there is a good chance…

What's your opinion about this retro revival?

It’s a very good thing, but we have to work to move it beyond nostalgia and bring younger people into the scene. There is potential for this given the dire state of so-called AAA gaming and a growing desire for simpler, purer games that can actually be physically owned.

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

Be vigilant!

Thank you so much to Tony for his kindness. Don´t miss URB-X Warriors on Kickstarter!

Cash Cow DX es un arcade con mecánicas y estética que homenajean a aquellos títulos que poblaban los salones recreativos a principios de los años 80. Desarrollado por Pixel Games y publicado por Flynn’s Arcade, está disponible en Steam, GOG y la eShop de Nintendo Switch, siendo esta la versión que hemos podido probar.

En un juego arcade tan bien planteado como este Cash Cow DX, el mantra de “fácil de manejar, difícil de dominar” cobra, una vez más, todo el sentido. Y es que su planteamiento es muy sencillo: 5 pantallas (con scroll horizontal), 3 tipos de enemigos, plataformas, rampas, algunos (pocos) objetos especiales y un único objetivo: recoger todas las muu-nedas (en inglés, mooney, juego de palabras con la palabra money y la onomatopeya de la vaca) para pasar a la siguiente fase y terminar enfrentándonos a Party Piggy.

Menú principal

Nuestro personaje, Cash Cow, puede moverse en horizontal y saltar. Cruceta (o stick analógico) y un botón. No hay más. Todos los niveles tienen tuberías en un extremo para pasar al otro lado, así como zonas por las que “caer” a la parte superior de la pantalla.

Para ser un simple arcade viene cargado de diversos modos de juego

Encontraremos tres tipos de enemigos que intentarán hacernos la vida imposible, Speedy Spiky, Rolly Ronny y Bouncy Bobby, cada uno con su propio color y patrón de comportamiento. Será fundamental interiorizarlos si queremos progresar. Como también lo será dominar el uso del pico, que nos permitirá acabar con dichos enemigos, y el diamante, que multiplica por dos la puntuación al recoger las monedas. Cabe destacar que los diamantes son acumulativos, duplicándose la bonificación si logramos encadenarlos.

Estos son los protagonistas de Cash Cow DX

A la dificultad característica de este tipo de arcades de plataformas se suman tres aspectos, a nuestro entender, derivados de su frenético ritmo. El primero de ellos es que, al haber scroll, es fácil darnos de bruces con un enemigo. Aunque aparece una flecha en el borde, del mismo color, para indicarnos su presencia, a veces no es suficiente para evitar la colisión y nuestra muerte. El segundo es la inercia del personaje: necesitaremos un tiempo a los mandos hasta que nos acostumbremos a ella. El tercero es más que nada psicológico; el aspecto gráfico, el movimiento y la música nos transmiten una sensación de urgencia que no es tal, ya que en realidad no hay un tiempo límite para superar cada una de las fases.

Créditos del juego

Además del control, con la inercia ya comentada y (creemos) la característica de salto coyote, que deberemos dominar para poder escapar indemnes de situaciones extremas, también habremos de dedicar tiempo a interiorizar la disposición de las plataformas en las diferentes fases, así como a buscar un camino “virtuoso” que nos permita maximizar la recolección de monedas, minimizando a la vez los peligros a los que nos expongamos.

Tabla de puntuaciones

El bucle del juego no es infinito; al completar las 5 pantallas el juego termina con la puntuación que hayamos conseguido. De ahí ese aliciente para seguir mejorando nuestro récord, optimizando el recorrido empleado para recolectar las monedas. Eso también significaría que existe una puntuación máxima imposible de superar. Por cierto, que cada 100.000 puntos obtendremos una vida extra. Así que no se trata únicamente de una cuestión de orgullo.

Recogiendo los dineros como si no hubiera un mañana

Hablando de récords, gracias al estupendo trabajo de Pablo Navarro y Marc Robledo, el juego cuenta con la opción de subir nuestro récord a una tabla online. Eso sí, la opción está un poco escondida. Hay que pulsar el botón + después de ingresar el récord en la tabla local, y si vamos como locos dándole al botón A para echar otra partida, es posible que la pasemos por alto.

Speedy y Rolly nos han cazado en una buena encerrona

Una vez superemos el juego en modo fácil, se desbloquearán un par de niveles de dificultad más, así como algunos modos de juego adicionales: maratón y speedrun. Ignoramos si, acabando el modo difícil aparecerán más retos, ya que sólo hemos sido capaces de superar el modo fácil, justo antes de redactar estas líneas.

¡Ah!, el ansiado pico que nos permitirá acabar con los insistentes enemigos

El apartado gráfico toma el estilo de un arcade de los 80, con un formato de pantalla 4:3 rodeado de un bonito bezel que podemos ocultar si así lo deseamos. Existe la opción de añadir un filtro CRT, para mayor gloria de la nostalgia.

Cayendo por donde indican las flechas apareceremos por arriba. ¿Cómo es posible?

El apartado sonoro, a cargo de Tuï, encaja como un guante, tanto en el espíritu arcade como en el ritmo frenético de Cash Cow DX. Tanto las músicas como los efectos de sonido son de diez. Es tan apropiado como para que mi hijo me dijera: “papá, te han matado”, sin mirar la pantalla, solo con escuchar la tonadilla.

En resumen, un frenético arcade, difícil pero no injusto, con una estética visual y sonora muy de los 80, que siempre nos dejará con la sensación de que en la próxima partida lo haremos mejor. Un castigo para nuestros bolsillos si tuviéramos que echar una moneda cada vez. Afortunadamente, por un precio muy razonable podremos dedicarle los intentos necesarios para superar ese modo de juego o ese récord que se nos resiste.

Para completar estas impresiones, hemos tenido la oportunidad de hablar con Sebastian Kostka, desarrollador del juego (bajo el mencionado nombre de Pixel Games) que, amablemente, ha respondido a nuestras preguntas.

Sebastian Kostka, fundador de Pixel Games y creador de Cash Cow DX

En cuanto a la jugabilidad, las influencias más obvias serían títulos de 8 bits como Miner 2049er y Bounty Bob Strikes Back, añadiendo elementos de clásicos como Mappy, Pac-Man y City Connection, aunque a un ritmo mucho más rápido.

Inicialmente, el juego incluía escaleras, pero este mecánico fue descartado pronto, ya que iba en contra del carácter rápido y frenético del gameplay.

Lo que no es tan evidente es que, a diferencia de la mayoría de los juegos de plataformas, Cash Cow DX contiene un sistema de puntuación profundo y acumulable, inspirado en juegos shmup de los años 90.

Como tal, los jugadores que buscan obtener altas puntuaciones pueden experimentar con numerosas estrategias, más allá de simplemente optimizar las rutas para maximizar sus resultados.

Gameplay wise, the most obvious influences would be 8-bit titles like Miner 2049er and

Bounty Bob Strikes Back, adding elements from classics like Mappy, Pac-Man and City Connection, albeit much faster paced.

Initially the game contained ladders, but this mechanic was abandoned early on as it was counter to the otherwise fast and frantic character of the gameplay.

Not immediately obvious is the fact that, unlike most platformers, Cash Cow DX contains a deep and stackable scoring system inspired by early 90s shmup games.

As such, players going for high scores can experiment with numerous strategies beyond working out the best routes for maximizing their results.

Probar y aprender cosas nuevas siempre ha sido importante para mí, y como resultado, no estoy apegado a ningún motor en particular. De hecho, diría que soy agnóstico en cuanto a motores.

Donut Dodo fue el primer juego que desarrollé en Godot, después de haber usado Unity durante un par de años, y otros motores antes de eso. Y aunque continué con Godot para Cash Cow DX, mi próximo juego está programado en C puro, sin el uso de ningún motor.

Se trata de una bienvenida vuelta a las raíces y a cómo solíamos programar juegos en los años 90. Lo realmente genial de eso es que el proyecto puede ser potencialmente convertido a muchos sistemas, desde consolas y ordenadores retro hasta dispositivos de última generación.

Trying out and learning new things has always been important to me, and as a result I’m

not attached to any engine in particular. In fact I would say I’m engine agnostic.

Donut Dodo was the first game I developed in Godot, after having used Unity for a

couple of years, and other engines before that. And while I stayed with Godot for Cash

Cow DX, my next upcoming game is programmed in pure C without the use of any

engine.

It’s a welcome return to the roots and how we used to code games in the 90s. The really

cool thing about that is that the project can potentially be ported to many systems, from

legacy consoles and computers to latest generation devices.

La versión de Switch de Cash Cow DX ha sido publicada por Flynn’s Arcade, que delega todo el trabajo de portado de Godot a RAWRLAB Games. Por tanto, no estuve directamente involucrado en el proceso.

Además, aunque tengo kits de desarrollo para todas las consolas principales y podría encargarme por mí mismo, debo admitir que el proceso me resulta bastante aburrido, comparado con la emoción de trabajar en nuevos juegos, y prefiero que un estudio externo se encargue de la tarea.

The Switch version of Cash Cow DX is published by Flynn’s Arcade, who delegates all

Godot porting work to RAWRLAB games. As a result I was not directly involved with the

process.

Also, while I own dev kits for all major consoles and could handle in-house porting, I

must admit that I find the process quite boring compared to the thrill of working on new

games and tend to prefer when a third party studio handles the job.

En el pasado solía soportar la mayor cantidad de plataformas posible, pero para un negocio unipersonal como el mío, esto tiene un alto coste de oportunidad.

Convertir, lanzar actualizaciones o atender problemas de soporte en demasiados sistemas puede generar una carga insostenible y, de hecho, obstaculizar la producción de nuevos proyectos.

Por tanto, soy cada vez más selectivo con los sistemas con los que trabajo, dependiendo del tipo de juego, y por ahora, Windows, Linux y Switch parecen ofrecer el equilibrio adecuado para títulos arcade clásicos, de jugar y disfrutar rápidamente.

Dicho esto, evalúo regularmente la situación y consideraré expandir el número de plataformas compatibles si hay suficiente demanda y potencial para justificarlo.

In the past I used to support a maximum of platforms, but for a one-person business

like mine, this comes at a high opportunity cost.

Porting, rolling out updates or addressing support issues on too many systems can

generate an unsustainable overhead and actually hinder the production of new projects.

As a result I am increasingly selective of which systems to target, depending on the type

of game, and for now, Windows, Linux and Switch seem to offer the right balance for

classic, pick up and play, arcade titles.

That said, I regularly reassess the situation and will consider expanding the number of

supported platforms if there is enough demand and potential to justify it.

De hecho, Donut Dodo ya recibió un lanzamiento arcade, llamado Donut Dodo Do! y publicado por exA-Arcadia. Esta versión del juego contiene contenido exclusivo como una fase extra, un nuevo personaje jugable y un modo para dos jugadores.

Consulta el sitio web de exA-Arcadia para obtener más información.

En cuanto a otros potenciales títulos arcade, se harán anuncios cuando sea el momento adecuado. Sin embargo, lo que realmente me encantaría ver algún día, como un homenaje a los años 80, son conversiones de 8 bits de estos juegos arcade para el ZX Spectrum, Commodore 64 y Amstrad CPC, incluyendo lanzamientos físicos.

Indeed, Donut Dodo has already received an arcade release, named Donut Dodo Do! and

published by exA-Arcadia. This version of the game contains exclusive content such as

an extra stage, a new playable character and a two-player mode.

Check out the exA-Arcadia website to find out more.

As for other potential arcade titles, announcements will be made when the time is right.

Ultimately though, what I would really love to see happen one day as a throwback to the

80s are 8-bit home-conversions of these arcade games for the ZX Spectrum,

Commodore 64 and Amstrad CPC, including physical releases.

En realidad, el próximo juego de estilo arcade clásico, llamado Looney Landers, ¡está cerca de completarse! La página de Steam ya está disponible, para aquellos que deseen seguir su evolución.

Pensé que sería agradable tener una especie de trilogía para estos juegos de estilo arcade de principios de los años 80, que he llamado Class of 1983, como un guiño a la máquina Class of 1981 de Namco con Ms. Pac-Man y Galaga.

Hasta entonces, Bobby Bombastic y otros proyectos están en pausa. Lo que me recuerda que realmente debería actualizar mi sitio web. :)

Actually the next classic arcade style game, named Looney Landers, is getting close to

completion! The Steam page is live, for those who wish to follow its progression.

I felt it would be nice to have a trilogy of sorts for these early 80s arcade style games,

which I have called Class of 1983, as a nod to Namco’s Class of 1981 Ms. Pac-Man /

Galaga cabinet.

Until then, Bobby Bombastic and other projects are on hold. Which reminds me that I

really should update my website. :)

Durante el apogeo comercial de los ordenadores de ocho bits, era relativamente normal encontrar a programadores especializados en un determinado procesador. Algo menos común era encontrar gente versátil con una facilidad pasmosa para pasar constantemente del Z80 al 6502 y viceversa. Uno de estos talentosos programadores, que además participó en algunos de los proyectos más recordados para máquinas clásicas, es Stuart Gregg. Hemos tenido la ocasión de contactar con él y que nos cuente como era el día a día de empresas como Core Design o Gremlin Graphics. 

ENGLISH INTERVIEW AFTER THE SPANISH TEXT.

Antes de nada, permíteme darte las gracias por la amabilidad en aceptarnos esta entrevista. Empecemos por el principio: ¿cuándo empieza tu interés en la tecnología?

Me fascinaban los primeros arcades como Space Invaders, Pac-Man, Defender, etc. Tuve alguna consola de las primeras y una Atari 2600, pero no muchos juegos.

¿Cuales fueron las primeras máquinas que entraron en tu vida?

Al principio no tenía ordenador, pero era amigo de Simon Phipps y, tanto él como mi primo, tenía un BBC Micro, así que ese fue el primer ordenador en el que empecé a programar.

Normalmente solemos ver que los desarrolladores de videojuegos soléis estar influenciados al comienzo de vuestras carreras por esos primeros juegos a los que solíais jugar. ¿Cuáles eran tus favoritos?

Principalmente clones de recreativa en el BBC, y el Chuckie Egg. Ese me encantaba.

BBC Micro

A la mayoría de nosotros nos bastaba con jugar. ¿Qué te llevó a querer aprender a programar?

Me encanta resolver puzles y lo veía como una salida creativa, aún lo veo así. No tenía mucho dinero así qué, cuando te aburrías de los juegos, podías empezar a programar y explorar la tecnología. Yo era uno de esos que siempre desmontaba cosas para ver cómo funcionaban por dentro.

Una cosa es querer aprender a programar y otra muy distinta es ser capaz. Por supuesto, entonces no teníamos Google o GitHub *risas* ¿Qué recursos tenías a mano para aprender a programar? ¿Cuáles eran tus favoritos?

Lo bueno del BBC es que tenía un ensamblador integrado y el manual era una gran referencia. Eso, y los manuales de referencia del 6502 y el Z80. Creo que también había uno para el Amstrad.

Un ordenador para montarse por su cuenta

Empezaste a trabajar con diferentes máquinas y procesadores casi desde el mismo principio. Normalmente solemos encontrar que muchos desarrolladores siguen la típica ruta "ZX81, ZX Spectrum, Amstrad CPC". Si no estoy equivocado, tú empiezas con el BBC Micro (6502) pero pronto empiezas a trastear con el Z80 (MSX y otros). ¿Qué te llevó a aprender a programar para tantas máquinas diferentes? 

Tras usar las máquinas de otros, mi primer ordenador fue un Acorn Electron. Lo compré cuando trabajaba en la Universidad de Loughborough. En ese momento, la economía del Reino Unido no estaba en su mejor momento; fue cuando ocurrió la huelga de mineros, etc. Así pues, tras terminar en Loughborough, me monté por mi cuenta como desarrollador de software gracias a un programa del gobierno en el que te pagaban un poco de dinero cada semana. Compré un Amstrad CPC 6128 y un assembler en ROM y aprendí Z80. Había programado el Spectrum en BASIC; "ayudaba" a gente en sus proyectos de programación a cambio de que me prestaran sus máquinas. Supongo que, en ese momento, era adicto a la programación y los ordenadores.

Créditos de la versión de C64 de Gauntlet

¿En que momento te sientes lo suficientemente seguro como para intentar vender tu código? 

Era joven y chulito y contesté algunos anuncios de las revistas. Hice algunas entrevistas y la primera que me dio el sí fue para hacer la versión de MSX de The Way of the Exploding Fist. Era mucho más de lo que yo podía abarcar y no acabó muy bien. Conseguí el trabajo porque usaba interrupciones en las demos que llevé a la entrevista.

¿Qué nos puedes contar sobre tus trabajos antes de entrar en Gremlin? Para muchos de nosotros en España, el BBC Micro es una máquina totalmente desconocida. 

No había nada más allá del proyecto sin finalizar para el MSX.

¿Cómo acabaste en Gremlin Graphics? 

Es complicado. Conocí a Terry Lloyd a través de Simon Phipps, y a David Pridmore cuando estaba haciendo el juego de MSX. David había hecho una muy buena versión de Vortex para el Spectrum y ambos fuimos a una entrevista a Sheffield principalmente porque Ian Stewart quería comprar Vortex. A mi me ofrecieron trabajo con el equipo que hacía el Gauntlet en Birmingham y David vendió su juego.

Los jefazos de US Gold y Ocean

¿Qué recuerdas del desarrollo del Gauntlet? Era una recreativa muy querida y estoy seguro de que la gente esperaba esta conversión con impaciencia. 

Empecé a trabajar en el equipo de Gauntlet cuando quedaban dos o tres meses para acabarlo. Hice algunas cosillas como trabajar en los menús, introducir los mapeados y contestar el teléfono en mitad de la noche cuando la gente llamaba al teléfono de US Gold.

¿Cómo era tu equipo de desarrollo?

Usábamos un mini-ordenador basado en el procesador 68000, con terminales WYSE. Compilábamos en el mini-ordenador y enviábamos el código a la máquina objetivo. Todas las versiones del juego fueron escritas así. No recuerdo mucho más, lo siento. En algún momento cambiamos los mini-ordenadores por Atari STs.

The Deeper Dungeons de Gauntlet

Se dice que la oficina de Gremlin en Birmingham estaba dentro de las instalaciones de US Gold. ¿Tuviste presión trabajando en Gauntlet? Se comenta que Mr. Brown solía echar constantemente el ojo a sus productos...

Personalmente, no. Todos nos llevábamos bien con Geoff. Solía pasar por ahí una o dos veces al día. Incluso una vez condujo a Bob Armour a Ablex -quien hacía la duplicación de cintas y discos- en su Ferrari...

The Deeper Dungeons es uno de los primerísimos DLC (bueno, vale, en ese momento no eran descargables *risas*). ¿Cómo se os ocurrió esa idea?

Creo que Tony Porter programó un editor de niveles en el Amstrad. Metíamos así los niveles en el juego original. No recuerdo exactamente los detalles, si te soy sincero. Creo que, posiblemente, alguien del equipo dijo que podríamos aprovecharlo para hacerlo [Deeper Dungeons] y era algo fácil de hacer.

Gauntlet II para C64

¿Fue muy difícil adaptarte a trabajar con el C64? Ya tenías experiencia con el 6502. ¿Y con los chips de apoyo? ¿Qué te gustó de la máquina y qué no? 

Ya había estado trasteando con el C64. Molaba mucho tener sprites y scroll por hardware. No creo que odiase nada de la máquina, si te soy sincero.

¿Qué nos puedes contar sobre el desarrollo de Gauntlet II? Estoy convencido que no tuvisteis código fuente o gráficos de Atari para poder hacer la conversión...

Fue una conversión del código Z80 del Gauntlet I. Por eso solo hace scroll a medio carácter, etc. Se le hicieron algunos pequeños retoques a la lógica del juego respecto a lo visto en Gauntlet I, con mapas diferentes. Kevin Bulmer hizo todos los gráficos de ambos juegos para todas las máquinas.

Convertiste al Amstrad CPC y al ZX  Spectrum uno de mis juegos favoritos. ¿Qué nos puedes contar sobre el desarrollo del Xor? ¿Cómo acabaste trabajando en él? 

Es una larga historia. Cuando trabajaba en Loughborough conocí a Ian Downend, Paul Carruthers y Richard Costello. Había jugado al Boulderdash en el C64 y quería hacer una versión para el BBC. La empecé pero nunca la acabé. En resumen, Paul e Ian hicieron el Xor y entonces me preguntaron si quería hacer las conversiones.

Buena conversión de Xor para Amstrad CPC

¿Qué tal fue adaptarse al Amstrad CPC? Posiblemente ya dominabas el Z80; y por suerte el Amstrad CPC tenía el mismo CRTC que el BBC Micro y eso posiblemente ayudó ¿verdad? ¿Qué te gustaba de la máquina y qué no? 

Era como una versión del BBC con Z80 y mejores colores. La documentación estaba bien y la disquetera integrada era genial. No había nada que realmente no me gustase de ella. Es la máquina en la que realmente aprendí a programar en Z80 y no el Spectrum.

¿Estuviste también involucrado en la conversión del Xor al C64? 

No.

Hicisteis Gauntlet bajo la supervisión de US Gold. Con Mask, Gremlin Graphics tuvo su propia licencia de TV y pudo trabajar con mayor libertad. Mask no es una conversión de un juego existente, sino que fue desarrollado desde cero en Gremlin Birmingham. ¿Qué nos puedes contar sobre el proceso creativo? ¿Cómo se decidieron aspectos como las mecánicas de juego, diseño de niveles, gráficos, etc? 

Era mucho más creativo, por supuesto. Vimos algunos de los episodios de la serie de TV y planeamos el juego basándonos en mecánicas de otros juegos que eran populares en ese momento. No me acuerdo mucho, ya que han pasado 35 años *risas*

Mask para ZX Spectrum

¿Te era más fácil trabajar en la conversión de un juego existente —sabes de antemano como debe ser, pero te puedes encontrar un juego demasiado grande para una máquina más pequeña— o preferías desarrollarlos desde cero —con más libertad para decidir como podría ser—? 

Ambos tienen pros y contras. Me gustan hacer ambos siempre y cuando haya una interesante mezcla.

Si no me equivoco, hiciste la versión de ZX Spectrum. Ya tenías experiencia con el C64 y el CPC, así que podrías haber hecho también esas versiones. ¿Cuál es la razón de que sólo hicieses la de Spectrum? ¿Fue quizás cuestión de tiempo para que todas las versiones estuvieran listas al mismo tiempo?

Fue mi primer juego publicado; básicamente, Tony Porter me puso a su cargo y usamos la misma lógica en ambas versiones y me enseñó lo necesario sobre programación en el Spectrum.

Volviste al C64 para hacer el Mickey Mouse. ¿Qué nos puedes contar sobre su desarrollo? ¿Cómo fue el proceso creativo? ¿Qué te llevó de vuelta al C64? 

Nos habíamos mudado a una oficina nueva dentro del almacén de US Gold. Antes, mientras trabajamos en Gauntlet, compartíamos oficina con Contabilidad. Al tener ahora espacio extra, pudimos añadir un segundo equipo y nos faltaba un programador de C64 y Tony podía manejarse bien con ambas versiones de Spectrum y Amstrad. 

Mickey Mouse para C64

Disney es conocida por su agresiva defensa de su propiedad intelectual. ¿Estuvo controlando activamente el desarrollo del juego? ¿Os enviaron instrucciones sobre qué se podía hacer y que no? 

Existían reglas sobre la violencia, etc., por eso usamos pistolas de agua. También tuvieron que dar la aprobación final antes de poder ponerlo a la venta.

¿Cómo entras en Core Design?

Estaba harto de conducir hasta Birmingham. Conocía a todo el mundo en Core y necesitaban un programador extra para hacer dos equipos.

Rick Dangerous tiene un lugar destacado en la historia del videojuego por méritos propios. ¿Qué nos puedes contar sobre su desarrollo? ¿Cómo se os ocurrió el concepto de juego? ¿Cómo decidisteis las mecánicas de juego, diseño de niveles, etc? 

Fue un esfuerzo colectivo, aunque Simom Phipps fue el diseñador inicial. Hicimos el tamaño de pantalla igual al del Spectrum y los tamaños de sprites iguales a los de C64, para que el juego se jugase más o menos igual independientemente de la plataforma. Todos los niveles fueron diseñados principalmente por Bob Toone, pero fue en general un trabajo colectivo. 

Rick Dangerous para C64

Tras Rick Dangerous volviste al Z80 para hacer las versiones de Spectrum y Amstrad CPC de Dynamite Düx. ¿Cómo te sentiste volviendo a tener que copiar un juego en vez de trabajar en material propio?

Necesitábamos a alguien que hiciera la conversión; no me lo pidieron, pero me ofrecí voluntario para que la empresa pudiera coger el proyecto. No obstante, por esa fecha estaba más feliz en el C64 y no disfruté mucho de convertir este juego. No me importa hacer conversiones; a su modo, son divertidas.

El Amstrad CPC tenía fama de tener scroll lento. Tú lo resolviste reduciendo el tamaño de pantalla, ajustándola con el chip CRTC. ¿No estuviste tentado a probar los registros de scroll del CRTC a ver si lograbas la misma velocidad sin tener que reducir tanto el tamaño de pantalla? ¿Pudiera ser que no tuvieses tiempo para ello?

Por entonces no había nadie que lo hubiese logrado aún. Recuerdo a Tony Porter enseñándome en Gremlin la primera demo que alguien le había enviado.

Hablando de tiempo: ¿cuánto os llevaba hacer un juego original como Rick Dangerous y cuanto una conversión como Gauntlet o Dynamite Düx? 

Creo que ambos llevaban unos 3 meses.

Dynamite Düx para el CPC

Compartiste empresa con otro programador muy talentoso para Z80 como Dave Pridmore. ¿Qué tal era trabajar con él? ¿Teníais una sana competencia que os hacía dar lo mejor de vosotros o solíais colaborar y compartir trucos de programación? 

Ya conocía a Dave, o Ken como le solíamos llamar, antes de que ambos tuviéramos trabajos en la industria. De hecho, fuimos a visitar a Ian Stewart a Gremlin Sheffield juntos. Dave había hecho una conversión del Tempest de Atari y Gremlin se la compró. Quiso quedarse como freelancer pero yo me quedé como trabajador por cuenta ajena. De vez en cuando compartíamos trucos de programación. 

¿Recuerdas quién programó la versión de Amstrad de Impossamole? Ese juego no tiene créditos. 

No, lo siento.

¿Trabajaste en algún otro juego de 8 bits que no hayamos mencionado en esta entrevista? ¿Pudiste entregar todos tus juegos o se quedó alguno sin publicar?

Creo que no.

OutRun Europa para Amiga, programado por Stuart

Más tarde fuiste promocionado a las máquinas de 16 bits. ¿Qué tal fue adaptarse a estos monstruos comparados con las más limitadas máquinas de 8 bits? 

Dejé Core para poder programar en Amiga y Atari ST. Para ser honestos, no fue muy diferente a trabajar en una máquina de 8 bits, pero eso fue quizás me fue más fácil que a otra gente porque estaba acostumbrado a trabajar en diferentes plataformas a la vez. 

¿Te ayudó en tu carrera tu experiencia optimizando cada línea de código para exprimir cada ciclo de procesador y cada byte de memoria? ¿Dirías que tuviste una ventaja comparado con otra gente que empezó a trabajar directamente con los 16 bits? 

Sí, he hecho eso, y seguí haciéndolo un poco en la PlayStation y la Saturn; pero hacíamos un montón de cosas por entonces para que los juegos fueran lo más rápido posible, que hoy en día no se harían bajo ningún concepto. Ahora hay mucha más gente que se gana la vida programando. Si eres bueno programando, entonces no creo que importe cuando hayas empezado.

¿Qué aprendiste durante tu época como programador de 8 bits que te haya ayudado hasta hoy? 

Cada vez menos *risas*. Las cosas son muy diferentes, pero tal vez debugging. 

Spot goes to Hollywood para la Sega Saturn

Tuviste la oportunidad de trabajar en buenos juegos para muchas plataformas diferentes. ¿Cómo podías cambiar tan rápidamente entre proyectos con 6502 y proyectos con Z80? 

Nunca llegué a dominar en profundidad ninguna máquina porque estaba cambiando todo el rato, pero al final, todo es programación; el lenguaje, la máquina, etc., no importa. Nunca entendí el pique entre propietarios de diferentes máquinas, incluso entre Mac o Windows. Al final no son más que herramientas de trabajo.

¿De cual de tus juegos de 8 bits estás más orgulloso? ¿Cual te gustaría rehacer de cero? 

No soy muy aficionado a mirar atrás. Creo que Rick fue el más divertido de hacer. En realidad no me gustaban mis juegos nada más terminarlos *risas*. No iría atrás a rehacer ninguno; más bien estaría deseando mirar adelante y empezar a trabajar en lo siguiente.

¿Conservas aún tu viejo código/discos/máquinas? ¡De ser así, deberían estar en un museo! 

Tengo algunas copias de seguridad, incluido Rick Dangerous. Otras cosas las he perdido con los años.

Rick Dangerous para Amstrad CPC

Sabemos que has estado muy ocupado en los últimos años. ¿Oyes, aún así, la llamada del ensamblador? ¿Veremos en el futuro alguna nueva producción de Stuart Gregg para las máquinas de 8 bits? Tal vez tras la jubilación... *risas*

Permíteme darte nuevamente las gracias por tu tiempo y tu amabilidad. ¿Hay algo que te gustaría añadir para nuestros lectores?

De nada. Estoy asombrado de que la gente siga estando interesada y jugando a estos juegos tras todos estos años.

First of all, let me thank you for your kindness in accepting this interview. Let me start from the beginning: when did your interest in technology start?

I Was fascinated by early arcade machines, space invaders, packman and defender etc. I had some early home consoles and an Atari 2600, but not too many games.  

Which ones were the first machines that entered your life?

I didn't initially own a computer, but I was friends with Simon Phipps, both he and my cousin had BBC micros so they are the first computers I got to program.

We usually find that game developers are heavily influenced at the beginning of their careers by the games they used to play. Which ones were your favorites?

Mainly the clones of arcade machines on the BBC and Chuckie Egg, I loved that.

BBC Micro

For most of us, playing games was just enough. What motivated you to learn how to code?

I love solving puzzles and saw it as a creative outlet and still do, I didn’t have too much money so once you were bored of games, I would start programming and the exploration of the technology. I was always one of those people that took things apart to see how they worked.

One thing is to desire to learn how to code and another one is being able to do so. Of course, we didn´t have Google or GitHub back in the day :-) What resources did you have at hand to learn how to code? Which ones were your favorites?

The great thing about the BBC is it had a built in Assembler and the manual was a great resource, that and 6502 and z80 reference manuals. I think there was one for the Amstrad as well.

A computer to go freelance

You started working with multiple machines and processors from almost the very beginning. We are used to finding the typical “ZX81, ZX Spectrum, Amstrad CPC” path among many developers. If I am not mistaken (you probably answered that already) you started working for the BBC Micro (6502) and tinkered early enough with the Z80 (MSX and others). Why did you learn how to code for so many different machines?

After using other people's machines, My first computer was an Acorn electron, I bought it while working at Loughborough University. Economically the UK wasn't great at the time, it was during the miners strikes etc. So after I finished at Loughborough I set myself up as a software developer on a government scheme where they paid you a little money each week. I bought an Amstrad cpc 6128 and an Assembler cartridge and learned Z80. I had programmed spectrums in basic, I would “help” people out with programming projects in exchange for the loan of their machines. I guess I was addicted to coding and computers at that point in time.

Credits of the C64 version of  Gauntlet

At what point did you find yourself confident enough to try to “sell” your code?

I was young and cocky and answered some adverts in magazines. I went for a few interviews and the first one to say yes was doing the MSX Way of the exploding fist. I was completely over my head and it didn’t go very well. I got the job because I had interrupts running in the demos I took to the interview.

What can you tell us about your very early work before joining Gremlin? For many of us in Spain, the BBC Micro was a totally unknown machine. 

There wasn’t anything just the unfinished MSX project

How did you end up joining Gremlin Graphics?

It’s complicated, I knew Terry Lloyd through Simon Phipps and had met David Pridmore while doing the MSX work, David had done a really good version of Vortex for the Spectrum and we both went to Sheffield for an interview mainly because Ian Stewart wanted to buy Vortex, I got offered a job working in Birmingham on the team doing Gauntlet and David sold his game.

The bosses of Ocean and US Gold

What do you remember about the development of Gauntlet? It's a well beloved arcade machine and I am sure the people were really expecting it.

I started working on the team with about two or three months left to go. I did odd jobs like working on menus, entering maps, answering the phone in the middle of the night when people called the US Gold phone number.

How was your coding setup? (hardware, software)

We used a 68000 based mini computer, with WYSE terminals, compiled on the Mini Computer and sent the code to the target machine, All versions of the game were written this way. I don’t remember much more sorry. Eventually we used Atari ST’s instead of the minicomputers

The Deeper Dungeons of Gauntlet

It is said that the Gremlin Birmingham office was located inside a US Gold facility. Did you feel any pressure working on Gauntlet? It is said that Mr. Brown used to keep a close eye on his products…

Not personally, we all got along well with Geoff, he would pop in once or twice a day. He even drove Bob Armour to Ablex who did the tape and disk duplication in his Ferrari…

The Deeper Dungeons it's one of the earliest DLC (well, I know, it was not downloadable at the time :-) ) . How did the team come with that idea?

I think Tony Porter built the level editor on the Amstrad, we needed to enter all the levels in the original game, I don’t remember the exact details to be honest I think someone maybe not on the team said hey we can continue the momentum if we did this and it was easy todo

Gauntlet II for the C64

How difficult was it for you to adapt to work with the C64? You had already experience with the 6502 but what about the other dedicated chips? What did you like about the machine and did you hate?

I had already played around with the c64. It was cool to have hardware sprites and scrolling, I don’t think I hated anything about it to be honest.

What can you tell us about the development of Gauntlet II? I am pretty sure you had no source code or graphics provided by Atari to do the task…

It was a port of the z80 code of Gauntlet I. That’s why it only scrolls ½ a character etc. There were just minor tweeks to the game logic from what was in Gauntlet 1, with different maps. Kevin Bulmer did all the graphics for both version across all machines.

You converted one of my favorite games to the Amstrad CPC and the ZX Spectrum. What can you tell us about the development of Xor? How did you end up working on it?

This is a long story, when I worked at Loughborough I met Ian Downend, Paul Carruthers and Richard Costello. I had played Boulderdash on the C64 and wanted to do a version on the BBC, I started but didn’t finish it. Basically Paul and Ian wrote Xor and then asked me if I wanted to do the conversions.

Good port of Xor for the CPC

How was adapting to the Amstrad CPC? You probably already dominated the Z80. Luckily, the Amstrad had the same CRTC chip as the BBC Micro and that probably helped, right? What did you like about the machine and what did you hate?

It was like a Z80 version of the BBC really with nicer colors. The documentation was nice and the built in disc drive was great. I didn’t hate anything much about it. It was the machine that I really learned Z80 on rather than the spectrum.

Were you also involved in the porting of Xor to the C64?

No.

During the development of Gauntlet you were under supervision of US Gold. With Mask, Gremlin Graphics got their own TV license and could work with more freedom. Mask is not a conversion of a game as well, but was developed from scratch in Gremlin Birmingham. What can you tell us about the creative process? How were the game mechanics, level design, art, etc decided?

It’s more creative for sure, we watched some of the tv episodes and planned it out based on mechanics of other games that were popular at the time, I don’t remember too much about it as it's 35 years ago lol.

Mask for the ZX Spectrum

Was it easier for you working on the conversion of an existing game (you know how it should look like and play, but you may find yourself trying to embed a too big game in a too small machine) or developing a game from scratch (more freedom to decide how it can be)?

Both have there pro’s and con’s I like doing both just as long as there is a nice mix

If I am not mistaken, you coded the ZX Spectrum version. You already had experience and games published on the C64 and the CPC as well, so you could have also done the other ones. What´s the reason behind this? Maybe a matter of time, so all versions could be ready in a shorter period of time as if you did more than one version at the time, even if that prevented the other coders from working on another title simultaneously?

It was my first published game, basically Tony Porter took me under his wing, we used the same logic across both versions and he really showed me the ropes of programming the spectrum.

You went back to the C64 coding Mickey Mouse. What can you tell us about the development of this one? How was the creative process? Why were you back with the C64?

We had moved into a new office they built in the warehouse at US-Gold, previously we had shared an office with accounting while working on Gauntlet, with the extra space we were able to add a second team and we were a C64 coder short and Tony could handle both Spectrum and Amstrad versions of the game he was working on

Mickey Mouse for the C64

Disney is known for his aggressive defense of its intellectual property. Did the company actively control the development of this game? Did they send any instructions about what you could do and what you couldn´t?

There were rules about violence etc so that’s why we used a water pistol etc, and they got final approval before it was released

How did you end up in Core Design?

I was sick of driving to Birmingham, I knew everyone and they needed an extra programmer to make up two teams

Rick Dangerous has a big place in videogame history for its own merits. What can you tell us about the development of this one? How did the team come with this concept of game? How was game mechanics, level design, etc, decided?

It was a group effort, but Simes was the initial designer. We made the screen size the same as the spectrum and the sprites the same size as the C64, so the game played pretty much the same across all versions. All the levels were mainly done by Bob Toone but it was very much a group effort.

Rick Dangerous for the C64

After Rick Dangerous you went back again to the Z80 to do the ZX Spectrum and Amstrad CPC versions of Dynamite Düx. How did you feel having to copy a game again instead of working on original material?

We needed someone to do the port, they didn’t ask me but I volunteered so we could take on the project as a company. I was happier on the C64 though by that time and didn’t enjoy the game very much. I don’t mind doing ports, they are fun for different reasons.

The Amstrad CPC had fame for its slow scrolling abilities. You solved it reducing the screen size using the CRTC chip. Were you not tempted to try the hardware scroll registers of the CRTC to produce the same scroll speed without having to reduce the screen size so much? Could it be by any chance that you had no time to investigate it?

No one had figured out how to do that reliably back then, I can remember Tony Porter at Gremlin showing me the first demo of it that some one had sent in

Speaking about time. How long would it usually take to produce an original game like Rick Dangerous and how much time were you given to port an existing game like Gauntlet or Dynamite Düx?

I think they both took about 3 months to complete

Dynamite Düx for the CPC

You shared company with another very talented Z80 programmer like Dave Pridmore. How was working with him? Did you have a sane competence that made you give your best or would you collaborate and share programming tips and tricks?

I knew Dave or Ken as we called him, before we both had Jobs in the industry, in fact we went to see Ian Stewart at gremlin in Sheffield together, he had a port of Atari tempest he had done on his own and Gremlin bought it, he wanted to stay as a freelancer but I took a job. We would share tips from time to time.

Do you remember who coded Impossamole for the Amstrad CPC? There´s no credits of that game ????

No sorry, I don’t.

Did you work in any other 8 bit game that wasn't listed here? Were you able to ship all your games or were there any that were shelved and it's still waiting for a chance to see the light of day?

No I don’t think so.

OutRun Europa for the Amiga, programmed by Stuart

You were later promoted to the 16 bits machines. How was adapting to those monsters after working with the limited 8 bit machines?

I left Core so I code work on the Amiga and ST, to be honest it wasn’t much different than working on 8 bit machines, but maybe because I didn’t just work on one machine it was easier for me.

Did your experience optimizing every single line of code to get the best of every processor cycle and every byte of memory help in your later career? Would you say you had an advantage compared with people who started programming directly on 16 bit machines?

Yes I’ve done that, and I did some of it on the Playstation and Saturn. But we did a lot of things that would be considered a big no no today just to get things running as fast as possible. There are many more people around today who write code for a living, if you are good at writing code then I don’t think it matters when you started.

What did you learn during your time as an 8 bit programmer that helped you until today?

Less and Less lol, things are so different now then back then, but maybe debugging

Spot goes to Hollywood for the Sega Saturn

You had the chance to work on very nice games for many different platforms. How were you able to change so quickly from 6502 to Z80 between projects?

I was never the master of any machine because I was swapping all the time, but It’s all just coding, the language, the machine etc doesn’t matter. I never understand the animosity between owners of various machines, even the Mac vs Windows thing, they are all tools at the end of a day.

Which one of your 8 bit games are you most proud of? Which one would you redo from scratch?

I’m not big on looking backwards, I think Rick was the most Fun to do. I pretty much didn’t like any games I had just finished lol. I wouldn’t go back and redo any, I would rather be looking forward and working on the next thing,

Do you keep your old code/discs/machines? If so, they belong in a museum!

I have some back ups, including Rick Dangerous, some I’ve lost over the years though.

Rick Dangerous for the Amstrad CPC

We know you have been very busy in the last years but do you hear the call of the assembler? Will we see in the future another nice Stuart Gregg production for the good old 8 bit machines? Maybe after retirement… ????

I broke my collar bone a few years ago and started a frogger clone on the c64 maybe I’ll finish that once I’m retired ;D

Let me thank you again for your time and kindness. Is there anything you would like to add for our readers?

You’re very welcome, I’m amazed people are still interested and playing these games all these years later.

Super Woden GP II es un juego de conducción arcade en tercera persona, desarrollado por ViJuDa y publicado por EastAsiaSoft. El pasado 10 de noviembre de 2023 se lanzó en Steam, donde ha cosechado reseñas muy positivas, y el mes pasado lo hizo en versiones para consolas actuales, a saber, PS4, PS5, Switch, Xbox One, Xbox Series X|S. Nosotros hemos probado la versión de Nintendo Switch.

Si sois de los que leyeron en su momento el análisis que hicimos en RetroManiac de su predecesor, Super Woden GP, la verdad es que, a falta de jugar algunas horas más, podríamos resumir la experiencia con tan solo cuatro palabras: “mucho más y mejor”.

¿Sabíais que el mapa del menú principal es la ciudad de Vigo?

Y es que el título que nos ocupa es una dignísima secuela con todas las letras. Toma la fórmula del anterior y la lleva al siguiente nivel, no sólo en la propuesta jugable, sino también en la técnica, con un acabado mucho más pulido. Con el mismo punto de partida (el mapa de Vigo), ahora tenemos más concesionarios, más coches, más competiciones. Incluso se nos presenta un nuevo modo de juego arcade, denominado Super Woden Rally, que podría considerarse el sucesor espiritual del aclamado World Rally de Gaelco, y un modo multijugador local a pantalla partida.

¿Una partidita al World Super Woden Rally?

La física del juego, eso sí, sigue siendo “marca de la casa”, pero de alguna manera algo más refinada, para no resultar tan frustrante en ocasiones. No esperábamos encontrar grandes cambios en este apartado, y es cierto que debes acostumbrarte a la idiosincrasia del juego si quieres disfrutarlo, echarle horas e ir completando tu garaje coleccionando todos y cada uno de los coches disponibles, que son bastantes. En otras palabras, tendrás que aprender a controlar los derrapes si quieres progresar en este juego. Tanto en asfalto como en tierra, independientemente de las condiciones climatológicas, el manejo del coche no parece verse alterado.

La IA de los oponentes tampoco es el aspecto más destacable. Los distintos niveles de dificultad parecen estar más basados en diferencia de velocidad punta que en aptitudes o técnicas de conducción. Hay que procurar mantenerse lo más lejos posible y a salvo de colisiones porque, si chocamos, parecerá que lo hemos hecho contra un Volvo de los años 80.

En cada concesionario encontraremos un montón de modelos diferentes. ¡Hazte con todos!

No hay multijugador online, pero sí tablas de records. Compararnos con el resto de jugadores ya supone suficiente acicate para seguir jugando y mejorar nuestros tiempos. En ese sentido, nos hemos encontrado un detalle algo molesto. Y es que, si jugamos sin conexión, cada vez que terminamos una carrera, o un tramo de rally, el juego se quedará como colgado y, tras unos segundos, nos mostrará el menú de conexión a Internet de la consola. Hemos visto este problema en otros juegos, así que no sabemos si es algo del SDK de la consola o de arquitectura de los juegos y las tablas de puntuaciones online.

Los diferentes coches carecen de licencias oficiales, pero están modelados con tanto mimo que son perfectamente reconocibles, sobre todo si te interesan algo los vehículos clásicos. En ese sentido, es de justicia destacar que Víctor hace un trabajo digno de elogio.

¿Reconocéis este carismático modelo de SEAT?

En la música es el apartado donde menos evolución hemos notado. De hecho, nos ha parecido escuchar algún tema reciclado del título anterior. Y el estilo de algunas canciones no nos parece que encaje del todo bien con la jugabilidad.

Además, en esta ocasión la versión para Switch no sufre de tantas ralentizaciones (al menos no de forma tan acusada) como lo hacía el anterior, aunque alguna sí que hay cuando coinciden más de cuatro coches en pantalla. Si tuviéramos que buscarle una pega, da la impresión de que el aspecto visual del juego se ha diseñado a partir de una resolución de 1080p, y en modo portátil a veces cuesta leer algunos textos, o bien la imagen es algo borrosa. No es algo exclusivo de este juego; le suele ocurrir a la mayoría de los indies que, desde Steam, dan el salto a la híbrida nipona.

Aún nos quedan muchas horas por delante para exprimir el título

Por concluir, si te gustó el primero, no deberías dudar en hacerte con su secuela. Si te gustan los juegos de coches arcade en tercera persona, es una de las mejores opciones para el catálogo de Switch. No es el juego de coches definitivo, pero nos proporcionará bastantes horas de entretenimiento.

Estas primeras impresiones han sido redactadas tras haber probado el juego durante un par de horas, gracias a un código de descarga digital de la versión para Nintendo Switch cedido gentilmente por EastAsiaSoft.

De un tiempo a esta parte se ha abierto la veda de búsqueda y captura de licencias de videojuegos que quedaron de una manera u otra en el olvido, y cuando se tratan de títulos que tuvieron un lanzamiento muy limitado o exclusivo en la época, los usuarios nos beneficiamos doblemente. Es el caso de este Cyber Citizen Shockman Zero (Shockman o Schbibinman para los amigos), que nos traen Ratalaika, Extreme y Shinyuden; viejos amigos en estas lides, que apuestan por una saga a medio descubrir por el público occidental.

Después de haberse trabajado publicaciones tan interesantes como Gleylancer o Gynoug para la 16 bit de SEGA, le toca el turno a la otra cara de la moneda: «el cerebro de la bestia» de Nintendo. Y para la ocasión, el título escogido es uno de esos plataformas pixelados típicos de mediados de los 90, que funcionó como precuela de una serie que nació en los circuitos de la genial PC Engine de NEC, pero que se paseó por la Super Famicom con más pena que gloria debido a su tardío lanzamiento. Por suerte, ahora tenemos una nueva ocasión de catarlo fuera del circuito de la emulación.

Jugando a dobles es más divertido... ¡de verdad!

Cabe mencionar que tampoco es que sea la primera que esto ocurre, ya que en el verano de 2017, Columbus Circle publicó en formato cartucho físico el juego para Super Famicom, de la mano de Extreme, una empresa japonesa que mantiene los derechos sobre el catálogo de Masaya (series Assault Suits, Langrisser, Chou Aniki o la susodicha Shockman) y que ha tenido a bien reeditarlos en formato digital mayormente. Bajo una capa de emulación, pero añadiendo los típicos añadidos actuales como efectos TV para el vídeo, posibilidad de salvar partidas, avance y retroceso rápido, etc. Pero no adelantemos acontecimientos, y vayamos por partes.

Este boss nos puso las cosas un poco complicadas

Concebido en el 94, cancelado luego y lanzado finalmente en exclusiva en 1997 para el sistema Satellaview de Super Famicom, la naturaleza efímera de esta tecnología (envío de datos y juegos por medio de retransmisiones por satélite), han hecho de este juego un pequeño tapadillo, sobre todo para esta parte del planeta videojueguil. Cierto es que la saga de PC-Engine, con su tercera parte para formato Super CD-ROM sobresaliendo quizás de alguna manera por sus más que notables gráficos y la vitola de ser una suerte de Mega Man venido a menos, es más conocida, pero este Zero no lo era tanto hasta que hace unos años comenzó a enseñar la patita un poco más.

El patrón de ataque de los enemigos va variando a lo largo de la aventura

En el juego controlaremos a dos nuevos protagonistas de una saga que, por otro. lado, se ha ido caracterizando por sus vaivenes jugables y diseño a lo largo de cada una de sus entregas. Raita y Azuki, chico y chica, son los nuevos personajes que podremos controlar en nuestra aventura en solitario o a dobles, ya que el título de Masaya incluye la siempre bien agradecida característica de echar una partidaca con un amiguete. Pasando del plataformeo más recalcitrante, a una especie de mezcla entre beat'em up y plataformas típico de los 90, tendremos que avanzar a lo largo de una serie de niveles, no demasiado inspirados, pero lo suficientemente variados como para no terminar de aburrir.

En zonas como esta podremos subir y bajar de niveles para escapar de los malos

Intercalados entre estos niveles, seremos bendecidos por los siempre necesarios enfrentamientos con jefes fin de fase y una historia que se va desplegando en glorioso inglés gracias al trabajo de localización que se ha hecho para esta versión (también podéis jugar en japonés, como los auténticos frikazos de la época con sus flamantes Dragon Ball Z recién importados). En cualquier caso, cada uno de nuestros personajes contará con un sistema de ataque algo diferente. Mientras que a Raita lo que le pone es dar guantazos como un poseso, Azuki prefiere la sutileza de corte afilado de su espada. y lo mejor es que cuando la partida es a dobles, ambos pueden realizar algunos ataques combinados que tienen su gracia y que añaden interés a la colaboración entre los jugones a los mandos. No está mal, nada mal.

Los gráficos, sin ser una maravilla, son vistosos y brillantes

Técnicamente no es nada deslumbrante, pues se deja entrever que se trata de un juego de mediados de los 90 para Super con un presupuesto mediado pero justo para pasar el corte. Sin ser anodino como muchos plataformas de la época, los diseñadores de Masaya apostaron por incorporar algo de humor en las situaciones que viviremos, en un elenco de enemigos interesante con patrones de ataque bien planteados y una paleta de colores vibrante que, obviamente, recuerdan al del "bombardero azul" de Capcom. El que tengamos que recoger multitud de items electrónicos, incluidos cartuchos y consolas, no deja de ser un nuevo guiño a una época que no volverá si no fuera por estos relanzamientos. La banda sonora, por cierto, sin ser ese top que para un servidor supuso Assault Suit Valken/Cybernator, se deja escuchar y comparte una especie de riffs guitarreros cuya inspiración también está muy clara...

Los dinosaurios siempre son bienvenidos en un videojuego

Por último, comentar que la capa de emulación está bien integrada, como viene siendo habitual en los lanzamientos de Ratalaika, aunque echamos de menos la inclusión de un manual escaneado o unas instrucciones escritas. Si están en algún sitio, nosotros no lo hemos descubierto, al menos en Switch. Que nos perdonen los productores en caso de haber metido la pata. Las opciones de visionado en pantalla no son para tirar cohetes, pero cometen su función, y las siempre bienvenidas opciones modernas de guardar partida o avanzar y rebobinar están ahí. Mención aparte supone una serie de opciones incorporadas a modo debug, algo complicadas de "invocar" pero que nos recuerdan cómo se sacaban los trucos en los juegos de la época. En este caso son más bien una serie de típicas opciones que los desarrolladores y testers podían utilizar para comprobar que el juego funcionaba correctamente. Muy curiosas.

¡ZAS! ¡En toda la boca!

Cyber Citizen Shockman Zero es un plataformas de zona media alta de la tabla. No pasará a la historia por sus virtudes, pero al menos todo lo que presenta lo hace bien y resulta divertido. La posibilidad de jugar a dobles siempre es un aliciente, y el puntillo de dificultad típico de los juegos noventeros está ahí, provocando que no sea un simple paseo. Por el precio contenido que tienen estos lanzamientos, y la posibilidad de saborear una rareza del catálogo de la SNES en inglés ya merezca posiblemente la pena, pero si encima eres un amante de los plataformas de toda la vida, no dejes de echarle el guante, seguramente pasaras buenos momentos a sus mandos durante este verano.

Goliath Depot es un arcade de pantalla única que, como otros juegos del catálogo de Flynn’s Arcade, podríamos haber encontrado en cualquier salón recreativo de los 80, no habría desentonado lo más mínimo, y habría supuesto un cuantioso agujero en nuestras finanzas. Desarrollado por Vidvad Games, con música de Zerolag y disponible en formato digital para PC (en Steam) y Nintendo Switch.

El desarrollo de este juego, según la información del kit de prensa, comenzó como una broma en Twitch. Vidvad Games, también conocido como SuperMegaDav en la plataforma de streaming, llegó a tener el récord mundial de speedrun en el nefasto juego Hotel Mario para CD-i. Él mismo decidió plantearse el reto de desarrollar un remake del primer nivel desde cero en menos de 12 horas usando Godot Engine. ¡Y lo consiguió!

Aquel fue el germen del título que hoy nos ocupa. Y, si echamos un vistazo a algún vídeo de gameplay, veremos que el planteamiento inicial es similar: cerrar todas las puertas de la pantalla para poder acceder al siguiente nivel. Habrá enemigos pululando que nos harán más difícil la tarea, ya que con sólo tocarnos nos desposeerán de una de las tres vidas con las que contamos. Además, podemos recoger monedas que nos permitirán, llegado el caso, comprar una opción de continuar, si es que hemos perdido todas las vidas.

Esta pantalla nos suena de algo…

Nuestro avatar puede moverse, saltar, subir y bajar por escaleras y también ocultarse de los enemigos en las mismas puertas que debe cerrar. Los movimientos son ágiles y la verdad es que, en ese sentido, la respuesta a los mandos resulta precisa. Además, si recolectamos las monedas suficientes, podremos “comprar” nuevas habilidades, como saltar hacia abajo de una plataforma, doble salto, y unas cuantas más.

El juego presenta varios elementos simultáneos que nos pueden hacer perder el foco. No hay que perder de vista que, para completar cada pantalla, basta con cerrar todas las puertas, nada más. Cuando lo hagamos, la puerta de salida se abrirá y podremos transitar hacia el siguiente reto. No es necesario cerrarlas en un orden determinado, ni acabar con todos los enemigos, ni recoger todas las monedas. Tan solo tenemos que hacerlo, eso sí, en un límite de tiempo.

Hay pantallas con partes en las que la gravedad está invertida; son un auténtico desafío

Sólo si queremos conseguir todos y cada uno de los trofeos será cuando tengamos que adaptar nuestra forma de jugar. Hay cinco logros por cada zona, a saber: por recoger todas y cada una de las monedas (ergo, no podremos continuar la partida, ya que perderíamos unas cuantas del total), por superar la zona sin morir, por superar la zona sin patear a ningún enemigo, por superar los 125.000 puntos y por superarla en menos de 5 minutos.

Además, podemos elegir la dificultad, el personaje jugable e, incluso, jugar a dobles (los dos en la misma consola). 

Al completar las cuatro zonas se desbloquean nuevos modos de juego

Hemos tardado algo más de lo que nos hubiera gustado en publicar estas líneas, pero es que no queríamos hacerlo sin antes completar el juego al menos en lo básico: superar sus cuatro zonas con diez pantallas cada una. Nos estaba costando bastante hasta que nos dimos cuenta de que, comprando el salto doble, el juego nos ha resultado bastante más sencillo. Una vez logrado, se habilitarán modos de juego adicionales.

Gráficamente, el juego cumple con lo necesario. Además, ofrece el típico filtro CRT, saturación de colores, vibración de pantalla, etc., para una correcta inmersión en el sentir retro.

Menú de opciones

El apartado sonoro, a cargo de Zerolag, encaja como un guante tanto en la estética como en el ritmo de juego. 

Por poner algún pero, podríamos decir que el número de niveles se hace un poco escaso, una vez que le cogemos el aire. Pero si había algo por lo que destacaban los arcade de los 80 no era por su longitud, sino más bien por su dificultad. Y no será nada fácil completar el 100% de los logros. De hecho, nosotros todavía no lo hemos conseguido, y ya le hemos metido un buen puñado de horas. También echamos de menos en esta versión la tabla de puntuaciones online, que siempre supone un aliciente para picarse y echar una partida más.

Los textos están deliciosamente traducidos al castellano

En cualquier caso, un título súper recomendable (y más por su precio reducido) para echar partidas rápidas, aunque gracias a su nivel de enganche es posible que terminemos jugando más tiempo del que habíamos planificado. Y, como hemos comentado, asequible de terminar, pero más complicado de completar en su totalidad. Flynn’s Arcade se está labrando un buen catálogo de juegos de ese género que resultan muy apetecibles, como Galacticon, Donut Dodo, Murtop o este Goliath Depot.

Para terminar, nos hemos puesto en contacto con Pablo Navarro, director y programador principal de RAWRLAB Games, estudio encargado de realizar el port de Goliath Depot a Nintendo Switch, para lanzarle algunas preguntas:

Pablo Navarro, director de RAWRLAB Games

¿Cómo es el proceso de realizar la conversión? ¿Es el desarrollador el que se pone en contacto con vosotros, o el editor? ¿Os pasan el código fuente y vosotros os encargáis de todo, o es un trabajo que realizáis en equipo junto con el desarrollador?

El primer contacto es entre el desarrollador y el editor. Si llegan a un acuerdo de publicación, nos reunimos todos y comprobamos si el port es factible.

Una vez confirmado, empezamos a trabajar, y dependiendo de la preferencia del desarrollador en ocasiones hago los cambios yo o los hace él en base a mis peticiones, generalmente compartiendo el proyecto con un repositorio de código git.

Mis cambios siempre serán algo menos estéticos que los del dev, que tendrá sus estilos, arquitecturas y costumbres.

¿Conviene preparar el proyecto de alguna manera especial si se prevé que se va a terminar convirtiendo a Switch, o da un poco igual?

Es importante que tenga una buena arquitectura y que el código sea suficientemente óptimo, ya que todas las decisiones de “está chapuza la mejoro luego” acaban pesando fuerte en el gigahercio por núcleo que nos ofrece la CPU ARM de Nintendo Switch. Pero sobre todo hay que evitar depender de plugins nativos y otros extras, ya que pueden complicar mucho, o imposibilitar, la portabilidad.

¿Quién se encarga del proceso de revisión y validación con Nintendo?

El editor hace todo el proceso de envío, burocracia y demás. Yo me encargo de la parte estrictamente técnica.

Suponemos que el juego estará hecho en Godot 3, por el tiempo que habrá estado en desarrollo. De cara a convertirlo a Switch, ¿hay alguna diferencia entre Godot 3 y Godot 4?

Sí, así es. Muchos de los juegos que están saliendo de Godot para consolas son de Godot 3, aunque hay otros tantos en desarrollo en Godot 4. Hay muchas diferencias entre Godot 3 y 4, ambos tienen sus desventajas y ventajas. Mi recomendación para empezar un nuevo proyecto siempre será utilizar la versión estable más reciente. Godot 4.0 tenía varios problemas de optimización para plataformas móviles, pero ya se ha mejorado enormemente en 4.3.

¿Se puede esperar que, en el futuro, Godot sea capaz de exportar de forma autónoma a consolas como Switch, PlayStation, Xbox, o debido a la naturaleza del software libre, siempre dependerá de terceras empresas como la tuya?

Convertir un motor como Godot a consolas y, más difícil aún, mantenerlo al día es una tarea titánica. Conlleva mucho trabajo y la Fundación Godot no tiene los recursos necesarios para poder ofrecerlo gratuitamente. Pero gracias a que es un proyecto de software libre, empresas como W4Games o LoneWolf pueden ofrecer conversiones con un nivel de calidad y optimización muy elevado.

Si se trata de un proyecto pequeño y sólo nos interesa publicarlo en Nintendo Switch, podemos utilizar el port gratuito mencionado en la página web de RAWRLAB Games, aunque dicho port se ofrece completamente sin ningún tipo de soporte.

Además, las consolas son plataformas cerradas, por lo que no es posible acceder a dichos ports si no eres una empresa con acceso a los kits de desarrollo.

Ojalá más pronto que tarde podamos contar con otros ports básicos gratuitos similares en las otras plataformas.

Queremos expresar nuestro más sincero agradecimiento a Pablo Navarro, por contestar cordialmente a nuestras preguntas, y a Juan Peralta, de Flynn’s Arcade, por facilitarnos un código de descarga de la versión para Switch del juego para poder probarlo y redactar este artículo.

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?

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.

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?

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.

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.

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.

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.

Cuando pensamos en títulos publicados por las grandes casas del software europeo, muchas veces pasamos por alto la auténtica autoría de ellos. Incluso la todopoderosa Ocean Software subcontrataba a equipos externos para derivar allí parte de su producción, a pesar de contar con un potente equipo interno de desarrollo. Mención especial para US Gold, quien derivó trabajo de desarrollo a innumerables pequeñas empresas y grupos de programación. Hoy tenemos el privilegio de hablar con uno de esos incansables currantes que firmó conocidísimos títulos desde un pequeño estudio de programación en Irlanda: Damian Scattergood.

ENGLISH INTERVIEW AFTER THE SPANISH TEXT.

Mi padre era mecánico de coches. Él siempre estaba aprendiendo sobre coches y como arreglarlos.

Cuando se pusieron a la venta las primeras calculadoras me quedé fascinado por ellas. Yo era fan de Star Trek y se despertó en mí el interés por la tecnología. Fui el primer niño de la calle en tener una calculadora: una Sharp pequeña y marrón. Todavía la conservo. Esa me hizo interesarme por la tecnología. Me divertía escribiendo palabras usando números —estoy seguro que todos habéis hecho eso en la escuela—, así que ya tenía en mi cabeza la idea de que podías usar tecnología para hacer otras cosas a las que se supone que podías hacer. 

La escuela de mi amigo compró algunos ordenadores TRS80, así que a él también le entró el gusanillo de la tecnología. Íbamos a visitar tiendas donde se vendieran ordenadores y nos quedábamos mirándolos todo el día y aprendiendo a hacer pequeños programas tipo «Hola mundo».

Por aquel entonces los ordenadores no eran accesibles y todo el mundo era bastante pobre.

Damian Scattergood. Fuente: LinkedIn

¿Cuáles fueron las primeras máquinas que entraron en tu vida?

Mi primer ordenador fue un Sinclair ZX81. El segundo fue un ZX Spectrum de 16K, que después amplié a 48K.

Mi primer trabajo fue escribir programas en el Amstrad CPC. También he programado para DEC, PC, MSX, CBM64 y unas cuantas más.

¿Qué te llevó a hacer tus propios juegos en vez de simplemente disfrutar de lo que hacían otros?

El ZX81 tenía muy pocos juegos, y con el Spectrum pasó igual. Los juegos eran caros; podían parecer baratos a 7,99 libras, pero eso eran seis meses de mi paga.

Teníamos muchos amigos con ordenadores y empezamos a hackear y copiar programas. Una persona compraba un juego y unos cuantos de nosotros lo copiaríamos para el resto. De esta manera nos hacíamos con montones de juegos para jugar. Así que algunos los compramos, y otros los copiamos. La idea de hackearlos nos enseñó qué era el código máquina y la programación. Entonces llegaron las revistas: Sinclair Programs, C+VG [nota: Computer and Video Games] y otras.

Estas revistas tenían pequeños listados para teclear. Algunos funcionaban, otros no, así que todos aprendimos rápidamente a debugear código. Entonces esto nos enganchó a todos, y ya teníamos un entendimiento básico sobre cómo escribir juegos.

¡Así que empezamos a hacer juegos!

Rutina de sprites con máscaras en papel. Damian Scattergood ©

¿Qué recursos tenías disponibles para aprender a programar? ¿Alguno favorito?

La parte más dura de hacer juegos es que la industria estaba en pañales, así que NO HABÍA HERRAMIENTAS. Empezamos en BASIC, y después aprendimos a usar líneas DATA en plan «255,0,0,...» etc, para meter código máquina. Yo escribía código máquina en papel. ¡Sí, PAPEL! «LD A,0» etc.

Después convertía eso a bytes... «65,0» etc. Entonces tecleaba eso en BASIC para pokear en memoria el programa entero. Difícil y consumía mucho tiempo. Por eso los programadores mejoraron rápidamente. Hacíamos ensamblador en nuestras cabezas.

Según la industria fue avanzando, aparecieron algunos compiladores. No soy capaz de recordar el nombre del primer ensamblador Z80 que usé. Lo siento :-(

Cuando tuve dinero, mi kit de desarrollo fue un Spectrum con un Interface 1 y dos microdrives: 1 unidad para el código y la otra para el compilador.

En la siguiente fase, una empresa llamada PDS sacó el sistema de desarrollo PDS. Este sistema era genial. Tenías un PC y escribías ahí todo tu código. Después lo compilaba y enviaba el código a la máquina objetivo. Así puede también programar para los Amstrad.

Damian trabajando con un PDS. Damian Scattergood ©

Normalmente solemos encontrar que muchos desarrolladores estuvieron en sus comienzos fuertemente influenciados por los juegos a los que solían jugar. ¿Cuáles eran tus favoritos?

El primer juego al que jugué en mi Spectrum fue JetPac. Lo tuvimos por Navidad: Spectrum + Jet Pac. Jugamos toda la noche. Era increíble, y la razón por la que me enamoré de Ultimate y los hermanos Stamper.

Grandes juegos tras JetPac fueron:

• Ant Attack. ¿Cómo han logrado ese efecto 3D? Guau.
• Tengo un montón de grandes recuerdos: busca 3D Deathchase y 3D Monster Maze. Increíbles. 
• Manic Miner y Matthew Smith...

Como puedes ver, tuve una gran infancia. 

En los arcades jugabamos a Galaxian, Asteroids, Space Invaders. También un montón de juegos tontos de carreras, antes de que llegasen las licencias. También estaba Super Asteroids, en color. Esta fue la primera recreativa a la que le di la vuelta al marcador. Mi puntuación era tan alta que volvió a 0. También me encantaban After Burner y Spy Hunter. Solía jugar por las noches al Gauntlet con mis amigos. Uno de mis amigos tenía un arcade, así que echábamos todas las noches de los viernes allí jugando.

JetPac inspiraría posteriormente Vidy Vody. Fuente: Spectrum Computing

¿En que momento te das cuenta de que tu código es lo suficientemente bueno como para intentar venderlo?

Una pregunta muy difícil. Supongo que fue cuando otra persona empezó a jugar a mi juego. Tenía algunos amigos que pedían copias de mis juegos. En ese punto pensé que tal vez debería intentar venderlos en serio, y así lo hice.

¿Qué nos puedes contar sobre Insomnia? ¿Cómo fue el proceso creativo? ¿Cómo decidiste cosas como las mecánicas de juego, el diseño de niveles, etc?

Este juego fue difícil de desarrollar, ya que era mi primer intento con el código máquina. No sabía mucho código máquina, así que escribí un framework en BASIC. Después fui reemplazando partes con código máquina. Empecé con «¿cómo podría dibujar el protagonista en código máquina?». Escribí un montón de pequeñas rutinas en código máquina y mi programa en BASIC las llamaba. De hecho, en Insomnia puedes cancelar la ejecución y ver el código. Algunas partes están en BASIC; otras en código máquina.

Empezó con la mecánica simple de mover por la pantalla a un hombre; cómo haría para animarle arriba, abajo, izquierda y derecha. Después como leer el joystick, etc. La animación es sencilla en dos frames. Diseñé las imágenes en papel milimetrado. Mi hermano Paul me ayudó con los mapas y el resto de cosas. Queríamos que nuestro mapa se pareciese un poco al de Attic Attac y que pudieses ir de habitación en habitación. Volvimos a usar papel milimetrado para diseñar los gráficos y los mapas. Entonces codifiqué todos los datos en el Spectrum.

Diseño de sprites en papel. Damian Scattergood ©

En Reino Unido, Alemania, Francia o España había empresas distribuidoras más grandes o más pequeñas que se encargarían de publicar tanto lo que desarrollaban sus equipos internos como los juegos que les llegaban. Teníamos gente trabajando en su dormitorio, equipos pequeños y pequeñas empresas desarrollando juegos que luego serían publicados por esas empresas distribuidoras. ¿Cómo era la industria en Irlanda? ¿Qué opciones tenías al buscar trabajo?

En Irlanda no había absolutamente ninguna empresa de videojuegos. Mi primer trabajo fue programar software educativo para una empresa llamada Mentor Educational Services. Escribí juegos en BASIC para MSX, PC y Amstrad. Sí, mi primer código comercial fue de hecho para Amstrad y no para Spectrum —eso vendría después. Hicimos unos 30 títulos educativos y de matemáticas.

Artículo en Technology Ireland. Escaneo cortesía de Damian Scattergood

¿Cómo acabaste colaborando con Mentor Educational Services?

Ese fue mi primer trabajo. Por entonces andaba buscando trabajo donde fuese. Conseguir trabajo en la Irlanda de los años 80 era muy complicado. Teníamos desempleo masivo, los impuestos eran altos y nadie tenía trabajo. Yo mismo estuve desempleado mucho tiempo.

Estaba estudiando un curso de negocios: cómo empezar tu propio negocio para gente desempleada. Durante el curso tuvimos la oportunidad de aprender C. Me apunté a un montón de ofertas de empleo y Mentor apareció buscando alguien que escribiera software educativo. Eso era fácil para mí. Ellos usaban BASIC y necesitaban a alguien al que le gustaran las matemáticas. Ese soy yo. IBM acababa de rechazarme, así que acepté.

Tenemos también curiosidad por tus trabajos con el MSX, ya que el MSX no tuvo tanto éxito en Irlanda o Reino Unido como las otras máquinas Z80. ¿Qué experiencia tenías con esa plataforma? 

Se estaba lanzando el MSX en Irlanda y el Reino Unido y había carencia de software, así que nos pidieron si podíamos programar títulos. Ese fue mi primer trabajo: convertir software del BASIC del Amstrad al del MSX. Hicimos unos 30 títulos en total. Tuvimos un montón de apoyo por parte de la gente de MSX del Reino Unido. Las ventas acompañaron.

¿Recuerdas qué títulos programaste para el CPC y cuáles para el MSX en esa empresa? 

Sí, pero eran un montón. Títulos como Introducing Maths, Introducing Circle, Introducing Angles, fracciones, formas, etc.

Catálogo de Toshiba MSX. Escaneo cortesía de Damian Scattergood

¿Cuán complicado fue adaptarte a trabajar con el C64 para SurfChamp? ¿Cómo aprendiste las partes específicas de esa máquina?

Fue duro. El primes mes fue un infierno. Tuve que aprender a la vez tanto el 6502 como el C64. Por suerte había grandes desarrolladores trabajando conmigo. Hugh Wilkinson era el programador senior y me ayudó. Yo tenía buenos libros. Soy adicto a la información, así que suelo comprar muchos libros técnicos. Incluso ya en los 80 tenía una librería de libros técnicos enorme. El reto principal al que me enfrenté fue convertir mi conocimiento del Z80 y el Spectrum al C64 y 6502. Al menos tenía el entendimiento básico de la arquitectura de un ordenador. 

Si se nos permite la pregunta: ¿Por qué no hiciste ningún juego más para C64?

Buena pregunta. No tuve muchas oportunidades y a mí verdaderamente me gustaba el Z80. Encontraba más natural trabajar en el Z80 para Amstrad y Spectrum. El 6502 era simplemente difícil. Pude exprimir al Spectrum hasta sus límites. Me lo conocía de arriba a abajo, así que me quedé ahí.

Análisis de SurfChamp. Escaneo cortesía de Damian Scattergood

Mientras trabajabas en New Concepts pudiste trabajar en un concepto novedoso *risas*. Hablo de Vidy Vody, un juego diseñado para ser controlado con un casco que pondrías en tu cabeza y te permitiría controlar al protagonista con inclinaciones de cabeza, muchas décadas antes de que la Nintendo Wii desarrollara mecánicas similares. ¿Cómo fue desarrollado este concepto?

Fue un desarrollo de lo más raro. New Concepts buscaba desarrollar nuevas ideas de juegos. Yo, en mis ratos libres, había estado desarrollando Vidy Vody, que estaba inspirado en JetPac.

Lo desarrollé primero para Amstrad, ya que quería probar un modo gráfico diferente. Se lo enseñé a Norman McMillan, el director de New Concepts, y le encantó el pequeño personaje y su casco. Los controles para ese juego eran muy simples: izquierda, derecha y disparo. Norman tuvo la idea de usar un casco real y un joystick. Tuvo la idea de mover tu cabeza a izquierda y derecha con el jet pack y un botón de propulsión. No tengo ni idea de cómo se le ocurrió, pero todos nos emocionamos.

Una semana más tarde llegó Norman a la oficina con un casco prototipo. Había cogido el casco de plástico de su hijo y le había añadido interruptores basculantes de mercurio y un cable para el botón de propulsión. Él hizo que se conectase a un puerto de joystick.

Modifiqué el código para que leyera el joystick y ¡listo! Teníamos un juego y un casco molón. Cuando movías tu cabeza a izquierda o derecha, el personaje se movía. Así que el casco se lo debemos a Norman.

Menú de inicio de Vidy Vody versión Spectrum. Fuente: Spectrum Computing

¿Cuáles fueron los principales retos al desarrollar un periférico así? ¿Cómo lo integraste en tus prototipos de juegos?

El gran reto era hacerlo seguro. Tener mercurio en tu cabeza no es una buena idea. Teníamos un prototipo y la siguiente fase constitía en trabajarlo hasta conseguir que el casco fuera seguro y a un precio razonable. La idea era contactar a alguien como Nintendo con una unidad completamente operativa y un juego y vendérselos. Por desgracia la empresa quebró antes de que pudiéramos lograr ese sueño. No obstante, era una idea brillante y muy adelantada a su tiempo. 

¿Para qué máquinas desarrollaste Vidy Vody? 

El juego se desarrolló para Spectrum 48K y Amstrad CPC 464. Creo que tengo las únicas copias que quedan del juego. Hice un video en Youtube sobre la versión de Spectrum, por si queréis buscarlo.

####

SET TARGET = AMSTRAD

If Amstrad {

Print_Bad_Guys_AMS

Print_Good_Guys_AMS

}

Else {

Print_Bad_Guys_Spectrum

Print_Good_Guys_Spectrum

}

David Martin junto a Samantha Fox. Fuente: CPCRulez

¿Cómo acabas en Emerald Software? ¿Cuántos trabajabais allí? ¿Qué tal era el sueldo?

En ese momento no había trabajo en Irlanda. Todos mis amigos habían emigrado al Reino Unido. Unos cuantos nos quedamos aquí en Irlanda e intentamos que vinieran empresas británicas. Preguntamos a Martech y a Gremlin Graphics si nos contratarían y montarían un estudio aquí.

Cuando New Concepts se fue tristemente a la bancarrota, se reunieron con el dueño de Martech Dave Martin. Él decidió montar Emerald Software en Irlanda, en Waterford. Creo que éramos unas 17 personas.

Era genial. El salario era bueno. El hecho de que nos pagaran por hacer y jugar juegos en 1988... ¡era genial! Yo tenía 18 años y me pagaban por divertirme. Genial.

Phantom Fighter. Fuente: MobyGames.

¿Sabes como acaba Emerald Software trabajando para US Gold?

Emerald Software empezó a intentar conseguir juegos licenciados para programar. Dave Martin trabajó en Reino Unido y conocía a un montón de gente. Empezamos de hecho a trabajar en Bruce Lee Enter The Dragon. Por desgracia, nuestro juego no fue publicado y en su lugar se fue a Data East. A mí me hizo muy triste, ya que soy un gran fan de Bruce Lee.

No obstante, nuestro trabajo llamó la atención de US Gold y nos empezó a mandar licencias. Así llegaron Moonwalker y Vigilante. También hicimos nuestros propios juegos como Phantom Fighter.

The Deep para Amstrad CPC. Fuente: CPC-Power

¿Qué nos puedes contar sobre el desarrollo de The Deep? ¿Cuáles fueron los principales retos y cómo los solventaste en ambas máquinas?

El mayor reto eran los enormes fondos con scroll. La pantalla es alta, así que tienes que mover un montón de cosas en el scroll. Las imágenes son enormes, así que tuvimos que ser muy inteligentes en cómo las pintábamos y las almacenábamos en memoria. Esto añadió presión en otros ámbitos del juego.

El código del scroll tenía que ser súper rápido, así que principalmente directo (sin bucles). Mucho código largo: Pintar línea 1, pintar línea 2, pintar línea 3, etc.

Esto significaba que otras partes del código tenían que ser más pequeñas y lentas. Había que equilibrar entre velocidad y tamaño de código.

Aprendí algunos trucos nuevos. Todas mis pantallas están pintadas de abajo hacia arriba. En pantallas antiguas, si pintas de arriba hacia abajo puedes tener parpadeos. Pintar de abajo hacia arriba implica que quizás tienes parpadeo en un píxel si la línea de raster te alcanza mientras estás pintando. Espero que esto sea claro. Hay una larga explicación técnica para esto. Los televisores pintan de arriba hacia abajo. Si tu código es demasiado lento, todavía estás pintando píxels cuando el televisor está pintando la imagen, así que parpadea. De abajo hacia arriba solo te puedes cruzar una vez.

Vigilante para Amstrad CPC. Fuente: CPC-Power

¿Qué recuerdas sobre el desarrollo de Vigilante? Doy por hecho que nunca tuviste código fuente o cualquier clase de material original de los desarrolladores de la recreativa. ¿Cómo hiciste para copiar la jugabilidad, etc?

Vigilante era genial. Fue una gran época. Ver toda la cobertura mediática de las revistas fue increíble. ¡Era famoso! Teníamos una recreativa con créditos infinitos en la oficina, así que todo lo que teníamos que hacer era jugar todo el día para hacerte bueno. ¡Vaya mierda de trabajo! *risas* Todos tuvieron que jugar y todos se conocían el juego. Tomábamos fotografías y dibujábamos imágenes de los niveles según los jugábamos. Imagínate que te paguen por jugar en los recreativos todo el día. Al final nos sabíamos los mapas y lo que queríamos meter en cada máquina para acercarnos lo máximo posible a la recreativa. Esto era muy difícil en Spectrum y Amstrad ya que solo teníamos una memoria limitada. Así que tuvimos que decidir qué podríamos descartar del juego.

Fallen Angel para ZX Spectrum. Fuente: Spectrum Computing

¿Qué nos puedes contar sobre Fallen Angel? ¿Fue inspirado en Vigilante o al revés?

Sí. Tras Vigilante, parte del equipo quería explorar el género de los juegos de peleas. En ese momento, a finales de los años 80, los Vigilantes —ángeles guardianes— en el metro de Nueva York tenían mucha fama, así que Bobby Kealy decidió hacer un juego basado en lo que habíamos aprendido con Vigilante. Bobby es ahora CEO de Manna Drone Delivery.

¿Por qué nunca se publicó Fallen Angel para el Amstrad CPC?

Fue desarrollado por Bobby Healy como prototipo de prueba. Había otras cosas que hacer en la empresa en ese momento, así que nunca pudimos ponernos con la versión de Amstrad.

Moonwalker para Amstrad CPC. Fuente: CPC-Power

¿Qué tal con Moonwalker? ¿Tenía el equipo presión extra debido a que Michael Jackson era en ese momento una gran estrella?

Sí. Teníamos presión por parte de la gente de Jackson y por la propia US Gold. Cada imagen de Michael tenía que ser perfecta. El equipo comprobó los gráficos y tuvimos que retocar algunos.

Respecto a la música; tenía a alguien sentado con un cronómetro detrás mía y controlábamos la música para asegurarnos de que se ejecutaba a la velocidad correcta.

Pudimos ver la película antes de que fuese publicada. Teníamos una copia del guion y una cinta de vídeo. Todos tuvimos que firmar un contrato de no revelación antes de acceder al material. Era muy emocionante.

Otro gran reto fue la presión que nos autoimpusimos. Estábamos trabajando para la mayor estrella del pop del planeta, así que más nos valía que el juego fuera bueno. Incluso antes de que empezáramos a trabajar en el juego ya había publicidad.

El juego en sí consta de cuatro partes, así que tuvimos que programar cuatro juegos diferentes. Esto fue un gran reto. En las versiones de Z80 también había una animación al principio, con los pies caminando. De nuevo, esto era un programa propio en sí, con sprites enormes y un gran reto de programar.

La enorme nave del final. Fuente: CPC-Power

¿Qué recuerdas de su desarrollo? ¿Quién decidió no convertir el arcade o alguna de las versiones para consolas? ¿Cómo fue el proceso creativo?

En ese momento no sabíamos nada de los juegos de consola. Esos se desarrollaron por separado. Nosotros teníamos las versiones de ordenadores domésticos y libertad para hacer nuestro propio juego. Los juegos de consola fueron desarrollados en EEUU. Nos reunimos como equipo durante 3 días, mirando el vídeo y el guion, y tuvimos la idea de los cuatro juegos con grandes animaciones gráficas entre medias.

Formulario semanal de US Gold. Escaneo cortesía de Damian Scattergood.

¿Qué tal era tu relación con US Gold? ¿Controlaban tu trabajo? ¿Sugerían cambios o demandaban mejoras?

Teníamos una gran relación con US Gold. Su enfoque era bueno, demandaban calidad, pero eran muy comprensivos y nos ayudaban. Cuando nos encontrábamos con retos técnicos, tenían otros programadores que nos podrían ayudar. Por ejemplo nos ayudaron con la protección de copia. Ellos podían sugerir mejoras, pero nunca demandaban nada. Estábamos en el mismo barco.

Teníamos que enviarle un informe de progreso cada semana, para que supieran si íbamos a entregar a tiempo. Ellos se enfocaban en la publicidad y la producción (cintas, discos, etc). Ellos solo querían saber que íbamos a tiempo.

Durante el desarrollo de cada juego les enviábamos demos. Ellos las probaban y nos enviaban feedback y, de paso,  capturas de pantalla, etc. a las revistas. 

Informe final sobre Vigilante. Escaneo cortesía de Damian Scattergood.

Trabajaste en una licencia de película: Perseguido. Ya nos has contado que posiblemente sea el peor código que hayas hecho. Ya que nos habías demostrado anteriormente de lo que eras capaz: ¿qué pasó? Si tuviera que adivinar, diría que «demasiado poco tiempo para hacerlo».

Perseguido tenía unos cuantos retos técnicos, así que me pidieron que ayudase. «El peor código» se refiere al driver de sonido que hablaba al empezar. El equipo quería que el Amstrad y el Spectrum hablasen, diciendo «volveré». Nadie sabía entonces cómo hacerlo. Nadie lo había hecho antes en Spectrum. Creo que por entonces solo 2 o 3 juegos tenían voces digitalizadas.

Tuve que estudiar como realizar una conversión de analógico a voz digital. Hubo un montón de ensayo y error. El código que escribí era muy básico. Pensé que tenía errores. Intenté un montón de variantes hasta que funcionó. No es un código elegante, pero el resultado fue genial.

El equipo usó algunas de mis librerías de rutinas. Por ejemplo, yo había desarrollado un driver de sonido. Lo había hecho durante Vigilante, así que ellos lo reutilizaron.

Perseguido para ZX Spectrum. Fuente: Spectrum Computing

Perseguido (Grandslam) no era una conversión arcade como algunos de tus juegos previos para US Gold. ¿Qué aporte creativo tuviste aquí? ¿Cómo se decidió cómo adaptar una película a un juego?

Este llegó nuevamente vía US Gold. Fue una licencia que recibió Emerald Software para desarrollar un juego. Parecido a Moonwalker, teníamos un vídeo para ver y podíamos hacer nuestro propio juego. Este no fue tan complicado de desarrollar ya que la película tenía de hecho diferentes niveles en ella. Así que, simplemente, copiamos el formato de la película. Habíamos aprendido en Moonwalker a trabajar con grandes gráficos y animaciones, así que intentamos integrar parte de eso. Así es como nació la animación de la introducción.

¿Nunca estuviste tentado de trabajar para una gran empresa en Inglaterra como Ocean?

Sí. Tras trabajar en Emerald Software me ofrecieron algunos trabajos, tanto en Reino Unido como en Suiza. ¿Te lo puedes creer? Sin embargo, yo quería quedarme en Irlanda, así que empecé como programador freelance en mi pequeñísima empresa Scatz Computer Games. Lancé Radical Moves en el Amiga y BLAM en el Spectrum.

Me reuní con el equipo de Enigma Variations en Bradford, Reino Unido, y empecé a trabajar para ellos como freelance. Esto me permitía volar de ida y vuelta al Reino Unido y vivir aún en Irlanda. Mi gran juego para ellos fue SuperTed, basado en el programa de televisión de Cosgrove Hall. Me encantó trabajar para ellos. Eran muy amables, pero muy trabajadores.

SuperTed en ZX Spectrum. Fuente: Spectrum Computing

¿Cómo fue el proceso creativo de SuperTed? ¿Cómo decidiste cómo adaptar los dibujos animados en un videojuego?

Este fue un proceso diferente. Enigma Variations desarrolló el juego por adelantado, así que me enseñaron un documento de desarrollo; cómo todo debería de funcionar, etc. Incluso habían creado la música y los gráficos para cada nivel.

Mi trabajo era darle vida a todo, programando el juego. Fue muy encantador trabajar en este juego. Era el primer juego en el que trabajé que tenía opciones de dificultad. Esto me hizo mucho más fácil probarlo, ya que podía jugar en modo fácil para comprobar el scroll, etc.

Revista Your Sinclair, julio de 1990. Escaneo cortesía de Damian Scattergood.

También colaboraste con la revista Your Sinclair. ¿Qué nos puedes contar sobre esta colaboración? ¿Cómo surge la idea de YS Capers y Surface Tension?

Como decía anteriormente, escribí un montón de algoritmos y código en papel, así que tenía un montón de información a mi alrededor. Solía leer TODAS las revistas. Sí, TODAS. Solía comprarlas todas para aprender de ellas. Tenía algunas rutinas inteligentes: recordad que solía escribir rutinas para mi mismo. Así que envié unas cuantas a algunas revistas. Todas estuvieron interesadas y, con el tiempo, desarrollé una colaboración con Andrew Hewson en Sinclair User. Empecé a trabjar con Andrew escribiendo algunos de sus artículos para la Sinclair User.

Tras eso empecé a escribir artículos para cada revista. Yo mismo tendría una idea y la usaría para la revista. Si les gustaba, me pagaban. Si no lo hacía, bueno, tenía una nueva rutina para mi mismo.

Me preguntaron desde EPROM —un fanzine— si podía escribirles artículos sobre código máquina, así que lo hice. Escribí una buena cantidad para ellos.

Cuando Operation Wolf fue publicado me pregunté cómo habían hecho eso en un Spectrum. Así que un día me senté y escribí una pequeña versión que funcionaba, simplemente por aprender. Me preguntaba cómo podría venderla y me vino la idea de que si dibujaba al equipo de Your Sinclair, podría dispararles. Pensé que era una gran idea y que les gustaría. Cómo ibas a decir no a un juego con ellos. Me dieron muy buena cobertura por ese juego.

Damian Scattergood ©

Si no me equivoco, también escribiste artículos técnicos para varias revistas. ¿Qué te llevó a compartir tus conocimientos? ¿Recuerdas algún truco en particular de los que compartiste del que te sientas especialmente orgulloso?

Es difícil de contestar. Escribí un montón. Mucho de lo que escribí empezó de hecho como mi propia documentación. Así que todo lo que escribí era útil para enseñar algo. Yo aprendo todo el rato.

A lo largo del camino ha habido mucha gente que me ha ayudado, así que pensé «¿por qué no ayudar a otros y que me paguen a la vez?». No me pagaron por todo lo que hice, pero era realmente feliz cuando la gente me escribía para darme las gracias. Me hacía muy feliz saber que había ayudado a alguien.

¿Qué nos puedes contar sobre Blam?

Fue mi último juego publicado para el Spectrum. Estaba mirando a ver cuánto color podía meter en un juego de Spectrum con el mínimo de color clash, y quería un shooter rápido. No es mal juego. Desde luego logré todo el color que quería.

De hecho había tres versiones diferentes de Blam en desarrollo. Sólo una fue terminada.

Blam para ZX Spectrum. Fuente: Spectrum Computing.

¿No estuviste tentado de convertirlo al Amstrad CPC?

Lo estuve, pero por entonces todo lo que quería era trabajar en exclusiva en el Spectrum para llevar su proceso de color hasta sus límites.

Saltas a los 16 bits según se va acabando la época de dominancia de las máquinas de 8 bits. ¿Cómo fue esa adaptación a trabajar con esos monstruos? ¿Te ayudó la lucha constante por cada ciclo de procesador y byte de memoria en sacar más partido del Amiga o el PC?

Por extraño que parezca, esto fue completamente diferente. Podías programar el Amiga en C y un poco de ensamblador, así que elegí esa ruta ya que yo ya sabía C y así no me costaría tanto. La parte más trabajosa fue aprender cómo programar el chip Copper y los sprites en pantalla. Esto fue una pesadilla. 

El sonido fue sencillo ya que el Amiga tenía tanta potencia que podías reproducir cualquier sonido sampleado. Intenté aprender 68000, pero nunca hice juegos 100% en ensamblador.

Sección de Damian en la revista Sinclair User. Fuente: Archive.org

¿Qué aprendiste durante tu etapa como programador de 8 bits que te haya ayudado durante toda tu carrera?

Creo que el aprendizaje más importante es confiar en ti mismo. ¡Sí, es siempre la respuesta! Hice tantas cosas que nunca supe o siquiera soñé que podría hacer... De un niño de pueblo que acabó trabajando en el juego de Michael Jackson Moonwalker: ¿cómo pudo ocurrir?

Nunca acepto un no por respuesta. Creo en esforzarme y hacer que otros se esfuercen mucho más allá de lo que pensamos que es posible. Si lo puedo ver, puedo hacer que ocurra.

Mucha gente dijo «¿No puedes hacer eso? No eres lo suficientemente bueno. Otra gente es mejor.»

No obstante, tienes que aprender a ignorar eso. Haz lo que quieras, ve a por tus sueños.

Cuando era niño, quería ser el mejor programador de videojuegos del mundo. Muy simple. Simplemente tomé toda oportunidad que se me presentó, y llegué muy cerca de mi meta.

¿De cuál de tus títulos te sientes más orgulloso?

Creo que Moonwalker. Fue tan difícil, y a la vez tan excitante al mismo tiempo... Era increíble trabajar en esto. ¿Fue un sueño que se hizo realidad?

Un sonriente Damian posa con el código fuente de Vigilante. © Damian Scattergood

¿Conservas aún tu código y discos?

¡¡¡SÍ!!! Me encanta acumular y tengo un montón de código, algunas máquinas también, pero por desgracia perdí mi Amstrad. No tengo ninguno y estoy muy triste por ello. Estoy planeando abrir un pequeño retro museo en algún momento en el futuro.

Tengo una curiosidad: ¿Pudiste publicar todos los juegos en los que trabajaste o quedaron algunos sin publicar?

Otra gran pregunta. No, hay un montón de juegos que no se completaron.

¿Te atreverás con The Gauntlet?

¿Oyes la llamada del ensamblador? ¿No estás tentado a acabar alguno de tus proyectos inacabados? Tal vez cuando te jubiles... :-)

¿Qué? No pienso jubilarme...

Tengo planes para volver al Z80 en Spectrum y Amstrad. Tendrás que esperar. Estaba pensando en comprarme un Spectrum Next, pero el Spectrum original sigue siendo el mejor.

He vuelto al negocio de los videojuegos con Scattergood Studios. Estoy trabajando con algunos jóvenes desarrolladores. Quiero pasar mis habilidades y ayudar a crear nuevas súper estrellas en el negocio. Es muy divertido trabajar juntos.

Hemos publicado The Gauntlet en Steam recientemente. Es un juego de correr y saltar estilo parkour. Es muy difícil, así que ¡pruébalo si te atreves!

Tenemos otros cuatro juegos en desarrollo. Deberían lanzarse en los próximos meses:

• Ventilate: Un bullet hell de estética steampunk.
• Don’t Whack a Mole: un clásico arcade... bueno, más o menos *risas*. 
• RECOiL: un shooter de acción.
• Crystal Edge: Retribution: Una aventura tipo hack and slash. 

De nuevo, muchas gracias por tu tiempo. ¿Hay algo que te gustaría añadir para nuestros lectores?

Pasadlo bien y vivid vuestros sueños.

Hacer juegos es trabajo duro, pero muy divertido a la larga. Cuesta conseguir un buen trabajo y empezar a ganar un buen dinero. Mantente ahí, toma cada oportunidad que se ponga en tu camino, sea pequeña o grande.

Llegarás ahí...

Damian. 

First of all, let me thank you for your time and your kindness. How did your interest in technology start?

My father was a car mechanic. He was always learning about cars and fixing things.

When the first calculators sold I was fascinated with them. I was a Star Trek fan and just got interested in technology. I was the first kid on my street to have a calculator. A small brown Sharp one. I still have it. It got me interested in technology. I had fun spelling words with calculators – I'm sure you did this at school. So the idea was in my head you could do other things with technology that it was not supposed to do.

My friend's school got some TRS80 computers, so he got interested too. We just went to visit shops in the city where computers were sold – and would stay all day looking at them and learning to do little bits of programming (“Hello World”).

At the time computers were not available and everyone was pretty poor.

Damian Scattergood. Source: LinkedIn

Which were the first machines that entered your life?

My first working computer was the Sinclair ZX81. My second was the ZX Spectrum 16k, which we then upgraded to 48k.

My first job was actually on Amstrad writing Basic programs. I also coded on DEC, PC, MSX, CBM64 and a few more.

What motivated you to do your own games instead of just playing what others made?

The ZX81 had very few games, and the Spectrum was the same. Games were expensive . They might seem cheap at 7.99, but that was 6 months of pocket money for me.

We had lots of friends with computers and we started to “hack” and copy games. One person would buy a game and a few of us would copy it for the rest of us. This way we all had lots of games to play. So we bought some, we copied some. The idea of hacking games taught us about machine code and programming. Then the magazines started – Sinclair programs, C+VG and a few others.

They had little programs to type in. Some games worked, some games didn’t. So we all learnt how to debug code very quickly. This then got us all hooked – and we had all the basic understanding of how to write games.

So we started writing games!

Masked Sprites routine on Paper. (c) Damian Scattergood

Which resources did you have to learn how to code? Any favorites?

The hard part of writing games was that the industry was in its infancy, so there were NO TOOLS. We started with Basic, and then learned how to use DATA statements like 255,0,0, etc to enter machine code. I wrote my machine code on paper. Yes, PAPER!. LD A, 0 etc.

Then I converted that into bytes.... 65,0 etc Then I typed that into Basic to poke the entire program into memory. All hard and time consuming. That's why many programmers got good quickly. We did assembly in our heads.

As the industry advanced rapidly some compilers did appear. I can't remember the name of the first basic z80 assembler I used. - Sorry :-(

When I got money, my development kit was a Spectrum, with interface 1 and 2 microdrives. 1 Drive for code, the other drive for compiler.

The next phase a company called PDS, launched the PDS development system. This system was brilliant. You had to have a PC and you wrote all your code on this. It then compiled it and would download the code to your target machine. I then was able to code for the Amstrad machines as well.

I had an Atari PC2 and one of the kits and could code for a variety of machines. You just plugged in your spectrum and Amstrad machines and could download Z80 code directly to the machines to run.

Damian working with a PDS. (c) Damian Scattergood

We usually find that many developers are heavily influenced by the games they used to play at an earlier age. Which ones were your favorites?

JetPac was the first game we played on the Spectrum. We got its for XMAS: Spectrum+Jetpac. We played it all night. It was just amazing and the reason why I fell in love with Ultimate and the Stamper brothers.

Big games after that where:

• - Ant Attack - how did he get that 3d Look - wow.
• - There are lots of great memories - look up 3D Deathchase and 3D Monster Maze - amazing.
• - Manic Miner and Matthew Smith….

I had a great childhood as you can see.

In the Arcades we played Galaxian, Asteroids, Space Invaders.Lots of silly racing games, before the names came in. There was a super asteroids - in color. This was the first arcade game I ever clocked back to 0 on the score. My score was so high - it went back to 0.

I also loved Afterburner and Spy Hunter.

We used to play Gauntlet with my friends at night in the arcades.

One of my friends owned an Arcade so we spent every Friday night in there playing games.

JetPac would later inspire Vidy Vody. Source: Spectrum Computing.

At what point did you realize that your code was good enough to try to “sell” it?

A really hard question. I suppose it was when someone else started to play my game. I had some friends who would ask for a copy of my games. At that stage I thought maybe I could try to sell them for real. So I did.

It took a while to get one sold. The UK was the only real market and it was very competitive, and tough. I have lots of rejection letters ☹️

What can you tell us about Insomnia? How was the creative process? How were things like game mechanics, level design, etc, decided?

This was a tricky game to develop as it was my first attempt at machine code. I didn’t know a lot of machine code, so I wrote a framework in Basic. Then I slowly replaced parts of it with machine code. I started with - how can I draw the main character in machine code. I wrote lots of little machine code routines and then had my basic program call them.

In Insomnia you can actually “BREAK” and see the code. Some parts are basic, some are machine code.

It started with the simple mechanics of moving a man around the screen. How would I get him to animate - up down, left right. Then how to read the joystick etc.

The animation is a simple 2 frame one. I designed the images on graph paper.

For the maps etc - My brother Paul helped me. We wanted to have a map that looked a little bit like Aattic Attac. So you could run from room to room. Again we used graph paper to design the graphics, and the maps. Then I coded all the data into the spectrum.

A lot of the gameplay was create just by playing the levels and changing them as we went along. So we made it all up, one room at a time.

Designing graphics on paper. (c) Damian Scattergood

There were in the UK, Germany, France or Spain bigger other smaller publishers that would publish games sent to them but also had in-house teams. There were also bedroom coders, small teams and small companies who produced games that were later published by those publishers. How was the industry in Ireland? What choices did you have when looking for a job?

In Ireland were there no game companies at all. My first job was writing educational software for a company called Mentor Educational Services. I wrote basic games on MSX, PC, and Amstrad machines. Yes, my first commercial code was actually an Amstrad and not spectrum – that came later. We did about 30 math and educational titles.

The first game company in Ireland was NEW CONCEPTS. I managed to get a job there coding “Surfchamp” on the C64. See BBC Article and also Retrogamer.

MES on Technology Ireland. Scan courtesy of Damian Scattergood.

How did you end up collaborating with Mentor Educational Services?

This was my very first job. At the time I was looking for a job anywhere. Getting a job in Ireland in the 80’s was hard. We had mass unemployment. Tax was high. No-one had a job. I was unemployed for a long time.

I was studying a business course: start your own business for unemployed people. During the course we had a chance to learn C. I applied for a lot of jobs and Mentor came up, looking for someone to write education software. This was easy for me. They were using Basic, needed someone that liked mathematics: that’s me. IBM had just turned down my job application so I said yes.

We wrote loads of titles.

We are also a bit curious about your MSX work, since the MSX didn't have as much success in Ireland or the UK as the other Z80 machines. What experience did you have with such a platform?

Mentor Educational Services was producing Educational Software for the Amstrad 464.

MSX was launching in Ireland and the UK and there was a shortage of software, so they asked us if we could write titles. It was my first job: porting software from Amstrad Basic to MSX Basic. We did around 30 titles in all. We got a lot of support from the MSX people in UK. Sales did well.

Do you remember which titles did you code for the CPC and the MSX for that company?

I do, but there was loads of them. Lots of titles like Introducing Maths, Introducing the Circle, Introducing Angles, Fractions, Shapes etc.

Toshiba MSX catalog. Scan courtesy of Damian Scattergood.

How difficult was it for you to adapt to work for the C64 for Surfchamp? How did you learn the specifics of that machine?

It was tough. The first month was hell. I had to learn the C64 and 6502 at the same time.

Luckily I had good developers working with Me. Hugh Wilkinson was the senior programmer and he help me.

I had some very good books. I’m an information addict, so I buy lots of technical books. Even in 1980’s I had a big library of technical books.

The main challenge for me was to convert my knowledge of Z80 and spectrum to CBM and 6502. So I had the understanding of basic computer architecture.

I did cheat and write a Z80 to 6502 cross assembler so I was able to write some of my code in Z80. It made life easier for me.

I had many late nights studying and learning the code.

If we may ask: why didn't you make any more games for the C64?

Good question. I didn’t get that many opportunities and I really liked Z80. I found it was natural for me to work on Z80 for Amstrad and Spectrum. 6502 was just hard.

I was able to push the Spectrum to its limits. I knew it inside out. So I stayed there.

Surfchamp review. Scan courtesy of Damian Scattergood.

While working for New Concepts you actually worked on a new concept :-) I am talking about Vidy Vody, a game designed to be controlled with a Helmet that you would put on your head and control the character with the tilting of your own head, decades ahead of the Nintendo Wii and such peripherals. How was this concept developed?

This is the oddest development process. New Concepts was looking to develop some new game ideas. In my spare time I had been writing Vidy Vody, which was a little like JetPac. 

I had it working on Amstrad first. I was testing a different graphic mode. I showed it to Norman McMillan the managing director of New Concepts and he loved the little character and his helmet. The controls for the game were really simple, left, right and fire. Norman just came out with this idea of having a real helmet and a joystick. It just got the idea of moving your head left and right with a jetpack and a thrust button. I have no idea where it came from. But we all got excited.

A week later Norman came into the office with a prototype helmet. He had his son’s plastic helmet and had attached mercury tilt switches to the helmet and a cable for a thrust button. He had it connected to a joystick port connector.

I modified the code to read the joystick and hey presto - we had a game and a cool helmet. When you moved your head left and right, the character moved. So the helmet is all down to Norman.

Vidy Vody was thought up by me and my brother Paul. He did some of the artwork.

I came up with the name. The idea is that you play a garbage man, collecting space garbage. He was a very “Busy Body” - so I kept playing around with words and letters until I changed the B’s to V - which became Vusy Vody. I didn’t like Vusy - so changed it to Vidy.

Vidy Vody menu. Source: Spectrum Computing.

What were the challenges of developing such a peripheral? How did you integrate it in your game prototypes?

The big challenge was to make it safe. Having mercury on your head isn’t a great idea. We had a prototype and the next plan was to work out how to make a helmet that would be safe, and at reasonable price. The idea was to approach someone like Nintendo with a complete working model and game and sell it to them.

Sadly the company went bust before we could make this dream happen. It was a brilliant idea though and years ahead of its time.

For which machines were Vidy Vody developed?

The game was developed on Spectrum 48k and Amstrad 464. I think I have the only copies of the game left in existence still. I did a youtube video on the spectrum version if you want to try and find it.

The original Game was developed on the Amstrad first. It was able to take advantage of the 4 pixel color mode - which made sideways scrolling easier. So the Amstrad version is much better than the Spectrum version.

What motivated you to start working with the Amstrad CPC as well? How difficult was it to adapt to that machine? Yes, it has a Z80 as the Sinclair Machines, but it also had different video memory and the famous CRTC chip.

When I started at Emerald they wanted me to code Spectrum and Amstrad at the same time. It actually was easy enough. I wrote code libraries that handled the screens on Spectrum, and Amstrad. Obviously the screens are different, colors, layout etc.

I wrote macros that would compile the code slightly differently for each machine....

So something like this:

####

SET TARGET = AMSTRAD

If Amstrad {

Print_Bad_Guys_AMS

Print_Good_Guys_AMS

}

Else {

Print_Bad_Guys_Spectrum

Print_Good_Guys_Spectrum

}

I did the same for sound. 90% of the code for each game was the same. I designed my own game engine, so the code worked on both machines. I then only had to switch the sound and display libraries.

There were some limitations as I had to make sure the screen dimensions were similar etc.

David Martin with Samantha Fox. Source: CPCRulez

How did you end up in Emerald Software? How many people used to work there? How was the pay?

At the time there were no jobs in Ireland. All my friends had emigrated to the UK. A few of us stayed here in Ireland and tried to get UK companies to come over. Martech and Gremlin graphics were asked if they would hire us all and set up over here.

When New Concepts sadly went bust, they met the Martech MD Dave Martin. He decided to start Emerald in Ireland in waterford. We had about 17 people I think.

It was great. Money was good. The fact was we were being paid to write and play games – how cool was that in 1988! I was 18 and got paid to have fun. Brilliant.

Phantom Fighter. Source: MobyGames

Do you know how Emerald Software ended up working for US Gold?

Emerald started by trying to get license games to code. Dave Martin worked in the UK and knew a lot of people. We actually started work on Bruce Lee Enter the dragon. However our game got not published and the game went to Data East instead. I was really sad about this. I’m a bit of a Bruce Lee fan.

However our work got us noticed in US Gold and they started to give us licenses – this is where Moonwalker and Vigilante came from. We also did some of our own work like Phantom Fighter.

We did some arcade licensing as well - “The Deep” is actually an arcade license, and we got to do the Running Man with Arnold Schwarzenegger. I did the speech on the spectrum. Sorry Amstrad fans, I couldn’t get it to work on the Amstrad as I didn’t know how!. The spectrum was the first time anyone had done speech in the company. There was no documentation on how to do any of this so I had to learn by reverse engineering and trial and error. I always say – the spectrum code was the worst code I ever wrote, but it worked.

The Deep for Amstrad CPC. Source: CPC-Power

What can you tell us about the development of The Deep? What were the biggest challenges and how did you solve them in both machines?

The biggest challenge with the Deep was the huge scrolling backgrounds.

The screen is tall, so you have a lot to scroll. The images are huge, so we had to be very smart with how we drew them and stored them in memory. This put pressure on other areas of the game.

The scrolling code had to be super fast, so mostly straightlined (no loops). Lots of long code

Draw line 1

Draw line 2

Draw line 3

etc….

This meant other code had to be smaller (and slower). There was a balancing act between speed and code size.

I learn some new tricks on the displays. All my screens are drawn from the bottom to the top. On old displays if you draw from the Top to Bottom, you can get flicker. Drawing upside down means you can only get a flicker on 1 pixel if the raster lines hits you as you are drawing. Hope this is clear. There is a big long technical explanation for this. TV’s draw from the top down. If your code is too slow - you will be drawing pixels as the TV draws the picture - so it flickers. Upside down you can only cross once.

Vigilante para Amstrad CPC. Fuente: CPC-Power

What do you remember about the development of Vigilante? I am assuming you never had source code or any original material from the arcade developers. How would you copy the gameplay, etc?

Vigilante was brilliant. It was a great time. To see all the magazine coverage was just incredible. I was famous! We had an arcade machine in the office with a free credit button, so we had to play the game all day to get good. Terrible job ha ha!.

Everyone had to play and everyone knew the game. We took photos and drew pictures of the levels as we played. Imagine being paid to play arcade games all day. In the end we all knew the maps and what we wanted to put into each machine to get as close to the arcade as possible. This was hard on the spectrum and Amstrad machines as we only had so much memory. So we had to decide what we could drop from the game.

Fallen Angel for ZX Spectrum. Source: Spectrum Computing

What can you tell us about Fallen Angel? Was Vigilante its inspiration or the inverse?

Yes. After Vigilante some of the team wanted to see what other fighting games we could come up with. At the time in the late 80’s Vigilantes – Guardians Angels - were big on the subway in New York. So Bobby Kealy decided to write a game on what we had learned from Vigilante. Bobby is now CEO of Manna Drone Delivery.

Why was Fallen Angel never published on the Amstrad CPC?

This was just developed by Bobby Healy as a prototype test game. There was other things going on in the company at the time, so we just never got around to doing an Amstrad Version.

Moonwalker on the Amstrad CPC. Source: CPC-Power

How about Moonwalker? Did the team have any extra pressure on this one because Michael Jackson was a huge star back then?

Yes. We had pressure from Jackson’s people and US Gold themselves. Every image of Michael had to be perfect. We had the team check some of our graphics and we had to rework them.

For music: I had someone sit down with a stop watch beside me and timed some of the music to make sure it was playing at the correct speed.

We got to see the film before it was released. We had a copy of the script and a Video cassette. Everyone had to sign a legal Non-Disclosure Agreement before we got access to it. It was very exciting.

A big challenge was the pressure we put on ourselves. We were working for the biggest pop star on the planet, so the game better be good. Before we even started to code there was publicity about the game.

The Game itself is actually 4 games altogether. So we had to code 4 different games. That posed a big challenge. On the Z80 versions you also have the animation at the start with the feet walking on. Again that was another program on its own. Huge sprites and a big challenge to code.

The game hi score screen, played music, scrolled up and down and was a lot of work to do. Everything we did had detail on it. A huge amount of work that everyone was proud of.

Good bye, Michael! Source: CPC-Power

What do you remember about the development of this one? Who decided not to convert the arcade machine or any of the console games? How was the creative process?

At the time we didn’t know about the console game. It was developed separately from us. We just had all the home PC’s and were free to develop on our game. The consoles were developed in the US.

We sat down as a team over 3 days, looking at the video and the script, and came up with the idea of the 4 games, with big animations (graphics) in between.

One really hard part for me was the end screen: when Michael turns into a spaceship and flies off. The graphics for this were very big, and I struggled to get them into the 8 bit machines. I managed to do it, but it was pretty hard.

Weekly report to US Gold. Scan courtesy of Damian Scattergood.

How was your relationship with US Gold? Did they control your work? Would they suggest changes or would demand improvements?

We had a great relationship with US Gold. Their approach was good, they demand quality, but were very helpful and understanding. When we had some technical challenges they had other programmers that could help us. They helped us with the security loading system for example. They might suggest some improvements, but never demand anything. They were very much team players.

We had to report progress to them every week, so they knew we would deliver on time. They focused on publicity and production (tapes, disk etc). They just needed to know we were on time.

During each game we would send demo builds over to them. They would test them and send us feedback, and then send screenshots etc to the various magazines.

Finar report for Vigilante. (c) Damian Scattergood

You worked on your own movie license as was The Running Man. You already told us it's probably the worst code you ever wrote. Since you had already proven yourself before: what happened here? If I had to guess, I would say “so little time to do it”.

The Running Man had a few technical challenges so I was asked to help out. The “Worst Code” was around the sound driver that spoke at the start. The team wanted the Spectrum and Amstrad to Speak - saying “I’ll be back”. No-one knew how to do this at the time. No-one had done speech before on the Spectrum. I think only 2 or 3 games at the time had speech.

I had to study how to do Analogue to Digital speech conversion. It was a lot of trial and error. The code I wrote was very basic. I thought my code was buggy. I tried lots of variants until it work. Not pretty code, but the result was great.

The team used several of my library routines. I had developed code for sound for example. This was code I had developed for Vigilante, so they got to reuse it.

The Running Man for ZX Spectrum. Source: Spectrum Computing.

The Running Man (Grandslam) was not an arcade conversion like your previous games for US Gold. What was your creative input here? How were decided how to adapt a movie into a game?

This came via US Gold again. It was a license that Emerald got to develop a game. Similar to Moonwalker, we had a video to watch and could create our own game. This wasn’t as complicated to develop as the film actually has levels in it. So we simply copied the format of the film. We had learnt from Moonwalker about using big graphics and animation  and we tried to incorporate some of that. This is how the ain intro animation came about.

Were you never tempted about working in England for a big company like Ocean?

Yes. After Emerald I was offered some jobs, both in the UK and Switzerland would you believe. However, I wanted to stay in Ireland. So I started up as a freelance programmer with my tiny little company Scatz Computer Games. I released Radical Moves on Amiga and BLAM on Spectrum.

I met with the team from Enigma Variations in Bradford UK and started working Freelance for them. This allowed me to fly back and forth from the UK and still live in Ireland. My big game for them was SuperTed, based on the Cosgrove hall TV program. I loved working for them. They were so nice, but hard working. 

SuperTed was brilliant as I loved the Cartoon series myself. I loved working on this.

SuperTed on the ZX Spectrum. Source: Spectrum Computing.

How was the creative process of SuperTed? How did you decide how to adapt the cartoon into a videogame?

This was a different process. With Enigma Variations, they developed the game in advance from the license. So I was presented with a document outlining the game, how everything was supposed to work etc. They had even already create music and the graphics for each level.

My job was to bring it to life and code the game. It was a lovely game to work on. It was the first game I worked on that had an Easy and Hard option. This made it easier for me to test as I often played to easy mode to check the scrolling etc.

SuperTed is a kids game, but the elements are all there for a shootemup. It has scrolling maps, tanks and rockets that appear on the ground, and things that fly in patterns.

The engine I build for this, gave me the idea to write BLAM a real shoot em up.

Your Sinclair, July 1990. Scan courtesy of Damian Scattergood.

You did also collaborate with the legendary Your Sinclair magazine. What can you tell us about this collaboration? How came the ideas for YS Capers and Surface Tension?

As I mentioned before,  I wrote a lot of algorithms and code on paper. So I had lots of information around me. I used to read ALL the magazines, yes ALL. I used to buy everything to learn from them. I had some smart routines - remember I used to write libraries for myself-. So I sent a few to some of the magazines. They all were interested and over time, I built up a relationship with Andrew Hewson in Sinclair User. I started working with Andew writing some of his Articles in Sinclair User.

After that I would just write articles for each magazine. I would just have an idea myself and target the magazine. If they liked it, they paid me. If they didn’t, then well I had a new routine for myself.

I was asked by EPROM - a fanzine - to write some machine code articles for them so I did. I wrote a good bit for them as well.

When Operation Wolf came out I was wondering how they did it on a Spectrum. So one day, I simply sat and wrote a small working version, to learn. I was wondering how to sell it and came up with an idea that if I drew the YS Team I could shoot them all. I thought it was a great idea and I was sure they would love it. Who could say no to a game with them in it.

They gave me great coverage for the game.

Surface Tension was another experiment. I wanted to see how fast a game I could create on the screen. It uses pixel up and down positioning and parallax scrolling. It also has a great little system for picking keys for control. If you play the game it is super fast and really hard. That’s all I was trying to do. Every game I wrote I experimented with something new. Again sitting around one day I didn’t know what do do with it, so I offered it to Crash, and they bought it.

(c) Damian Scattergood

If I am not mistaken, you also wrote technical articles for several magazines. What motivated you to share your expertise? Do you remember any particular tip or trick that you shared that makes you proud of it?

Hard to answer. I wrote so much. Most of my writing actually started out as my own documentation. So everything I wrote, was useful to teach me something. I learn all the time.

Along the way, I had some nice people that helped me, so I thought why not help others, and get paid at the same time. I didn’t get paid for everything but I was really happy when people wrote to me and said thanks. It made me very happy to hear I had made someone’s day.

Games is about everyone having fun.

How about Blam? What can you tell us about this one?

This was my last published spectrum game. I was looking to see how much color I could get on a spectrum game with minimal color clash. And I wanted a fast shoot em up. Its actually not a bad game. I certainly got the color I wanted.

There was actually 3 different versions of blam under development. Only 1 got finished. I was developing a version that used the “rainbow processor”. You could have more than 2 colors in a character space. I had a prototype developed that was a vertical scroller with multicolored spaceships. It was pretty awesome, but I couldn’t get a stable color screen across different Spectrum models.

Blam for the ZX Spectrum. Source:Spectrum Computing

Were you not tempted to publish it for the Amstrad CPC as well?

I was, but at the time I wanted to only work on the Spectrum as I was trying t push the color processing to its limits.

I am thinking of bringing out a new version of the game on PC: a retro homage. You’ll have to wait and see if that happens ????

As the time for the 8 bit machines came to an end, you jumped into the 16 bit wagon. How difficult was it for you to adapt to program for those monsters? Did your constant fight for every processor cycle and memory byte help you get more power out of the Amiga or Pc?

Strangely enough this was a completely different game. You Could progam the Amiga with C and a little bit of assembler. So thats the route I went and since I already knew C so this wasn’t too hard.

The tricky bit was learning how to code the Copper chip and the screen for sprites. This was a nightmare.

Sound was easy and the Amiga had so much power you could play any sampled sound.

I did try learn 68000, but I never did any 100% assembler games.

Damian´s section at Sinclair User Magazine. Source: Archive.org

What did you learn during your time as an 8 bit programmer that helped you in your whole career?

I think the most important learning is to believe it yourself. Yes is always the answer!

I did so many things that I never knew or even dreamed I could do. From a small town boy who finished working on Michael Jacksons Game Moonwalker. How did that happen?

I never take no for an answer. I believe in pushing myself an others way beyond what we think is possible. If I can see it, I can make it happen.

Many people said: "you can’t do that? You’re not good enough. Other people are better". However you have to learn to ignore that - you do what you want - and go for your dreams,

When I was a kid, I wanted to be the best Game Programmer in the world. Pretty simple. I just took every opportunity that came to me, and got pretty close to that.

Always be Brave. I would write letters to really famous people. Don’t be scared. One day, one of them will write back. Thats how I got to work with Andrew Hewson. He was my Hero at the time I wrote to him. I was so honored to get a letter back from him.

Which one of your works are you most proud of?

Moonwalker I think. It was so hard, and so exciting at the same time. To work on this was just unbelievable. Was it a dream or did it really happen?

I loved Vigilante. I liked playing it and it got great coverage and good reviews. To see other people playing it was mind blowing.

A smiling Damian poses with Vigilante´s source code. (c) Damian Scattergood

Do you still keep your old code/discs?

YES!!!, I am a hoarder and have lots of stuff code, some machines, but sadly lost my Amstrad machine. I don’t have one and I’m really sad about that. I’m planning to open a small retro museum some time in the future.

And just as a curiosity of mine: Were you able to publish all the games where you worked or were there any unreleased games?

Another great question. No. There are lots of games that didn’t make it.

As I mentioned; our version of Bruce Lee, The Wacky Races for Enigma (mine didn't make it). I had a number of spectrum and Amstrad games I didn’t finish. The code is still on my hard drive.

The Gauntlet, available in Steam

Do you hear the call of the assembler? Are you not tempted to finish any of your unreleased games? Maybe when you go into retirement :-)

What ? I’ll never retire…

I do have plans to try to return to Z80 on the Spectrum and Amstrad You’ll have to wait and see. I was thinking of buying a Spectrum Next - but the old spectrum is still the best.

I’m back in the Games business again with Scattergood Studios. I’m working with a number of young developers. I want to hand on my skills and help make new superstars in the business. Its great fun working together.

We launched “The Gauntlet” on Steam recently. Its a parkour like run and jump game. Its really hard, so give it a go if you dare!

There are 4 other games in development. They should be launched in the next few months.

• Ventilate: A steam Punk Bullet Hell Game.
• Don’t Whack a Mole: an arcade classic - sort of - ha ha
• RECOiL: an action packed shooter.
• Crystal Edge: Retribution: A hack and slash adventure game.

And maybe some more - watch this space.

El sentido común y la buena intuición suelen ser de las mejores armas a la hora de desarrollar y diseñar videojuegos. La simple observación de fenómenos simples te pueden llevar a hacerte plantear si no quedará potencial de la máquina sin exprimir. Hoy os traemos la historia cepecera de un talentoso desarrollador que allá por donde pasó supo sacar el máximo partido al sistema: Martin Pedersen.

ENGLISH INTERVIEW AFTER THE SPANISH TEXT

Antes de nada, permíteme darte las gracias por tu tiempo y tu amabilidad aceptando esta entrevista. Es un honor poder aprender un poco más sobre uno de los juegos de Amstrad más impresionantes jamás hecho. Permíteme que empecemos por el principio: ¿Cómo empezó tu interés por la tecnología?

Un amigo mío y yo estábamos interesados en la electrónica desde muy temprana edad, y también en los juegos arcade. De ahí en adelante fue un paso natural meternos en los ordenadores domésticos cuando empezaron a aparecer alrededor de 1980.

¿Cuáles fueron las primeras máquinas que entraron en tu vida?

La primera máquina que compré fue un ZX80 que había sido convertido en un ZX81. Después de esa, entraron Spectrum, Amstrad y Amiga. Por entonces no sabíamos inglés, así que tuvimos que adivinar cómo manejarlos.

Normalmente solemos encontrar que los desarrolladores suelen estar muy influenciados en sus comienzos por los juegos que jugaron a edad temprana. ¿Qué juegos eran tus favoritos?

Al principio juegos arcade principalmente. Después, juegos de Spectrum como Manic Miner y Jet Set Willy. Y, por ejemplo, JetPac molaba mucho en su momento; era casi un arcade. 

Søren y Martin. Foto cortesía de Mr. Pedersen.

Para la mayoría de nosotros ya era suficiente con jugar. ¿Qué te llevó a querer hacer tus propios juegos?

Muy pronto entendimos que podíamos programar estas máquinas y de alguna manera esto nos fascinaba. Entonces el interés en los juegos hizo que empezar a hacerlos fuese un paso natural.

Una cosa es pensar «¡quiero hacer mi propio juego!» y otra muy distinta ser capaz de hacerlo. ¿Cómo aprendiste a programar? ¿Qué recursos tenías a mano para aprender?

Buena pregunta. Cómo mencionaba más arriba, con el ZX81 no entendíamos inglés, así que con mucho adivinar y ensayo y error; y copiando pequeños programas de las revistas. Más tarde compré un libro —incluso estaba en danés— sobre cómo programar el Z80, posiblemente durante el periodo Spectrum. Probablemente fue ese el mayor paso adelante, pero siempre con mucho ensayo y error. Al principio programábamos metiendo a mano bytes de nuestro código en ensamblador usando el comando de BASIC, POKE ;-)

El norte de Europa era territorio Commodore. ¿Cómo acabaste trabajando para el Amstrad?Posiblemente sea una coincidencia. Por algún motivo entramos primero en el ZX81; naturalmente después vino el Spectrum. El C64 nunca capturó mi atención.

Pantalla de carga de The Vikings

No conocía a nadie con C64. Quizás un par de años más tarde sí, así que principalmente mi amigo y yo tomábamos nuestras decisiones; y fue por las máquinas de Sinclar, que también eran muy populares.

¿En qué momento te das cuenta de que tu código era lo suficientemente bueno como para intentar venderlo? ¿Tienes ejemplos de rutinas o programas que hicieras antes de trabajar en The Vikings?

Posiblemente intentamos hacer juegos en el Spectrum, pero no recuerdo ahora mismo los detalles. Eso se aceleró posiblemente en el Amstrad. Pronto entendí que era posible hacer scroll en el CPC a pantalla completa, viendo la línea de comandos del BASIC. Por entonces ya habíamos visto muchos juegos tanto arcade como de ordenador, posiblemente más de cien de cada, y con algo de experiencia programando entendí/entendimos que era posible.

The Vikings en acción

¿Cómo acabaste trabajando en The Vikings? 

Había un anuncia en una revista, creo que fue, en el que una nueva compañía danesa buscaba a gente que hiciera juegos, así que mi amigo y yo fuimos allí. Debíamos tener 14 o 15 años. Todavía tengo algunos vagos recuerdos visuales de la reunión. Era en una sala de conferencias de hotel elegante en Copenhague... así que fue toda una experiencia. Éramos probablemente unos 20 tíos sentados en forma de U en mesas. Y también había allí una empresa británica trabajando con la empresa danesa.

La mayor parte del trabajo recae en Søren Grønbech en el C64 y en ti en el CPC, con Torben Bakager haciendo los gráficos. ¿Cómo fue el proceso creativo? ¿Cómo decidísteis el estilo de juego, gráficos, diseño de niveles, etc? ¿Cuál fue tu aporte creativo?

En EEUU con otros compañeros. Torben detrás de Søren

Søren era un respetado demoescener del C64 con un profundo entendimiento de la máquina de Commodore. ¿Tal vez te incentivó eso a dar lo mejor de tí e intentar ganarle con tus habilidades como programador? 

En esa época no estaba para nada metido en temas de demoescena. Ni siquiera era consciente de que hubiese una tal vez. No creo que estuviésemos en competencia directa. Estábamos haciendo The Vikings en dos máquinas diferentes y creo que simplemente queríamos hacer un buen trabajo... y trabajar juntos :-) Ya había adquirido unas habilidades sólidas durante los años previos junto al amigo de la escuela que mencionaba más arriba... así que sabía que yo era capaz de hacerlo...

The Vikings es uno de los pocos ejemplos de scroll por hardware en el Amstrad a nivel decente. Para lograrlo, tuviste que comprender cómo funcionaba la magia negra detrás del CRTC o del Gate Array. ¿Cómo aprendiste a hacerlo? ¿Cómo es que fuiste capaz de triunfar en lo que programadores más mayores y con más experiencia no fueron capaces? 

Tal y como decía más arriba, la idea me vino de ver el scroll de pantalla cuando escribías en la pantalla del BASIC. De alguna manera, me mostró intuitivamente que era posible hacer un scroll a pantalla completa. Muchos juegos —anteriores— de Amstrad usaban una pantalla mucho más pequeña y con un montón de —innecesaria— información en la mayor parte de esta pantalla para justificar que la pantalla de juego fuese tan pequeña, supongo. Recuerdo que pensé que podía hacer mucho mejor trabajo que lo que habían hecho en Rambo ;-) Tomó cierto tiempo hacerlo funcionar en The Vikings, también para el scroll horizontal, pero sabía desde el principio que debería ser posible :-)

Hybris para Commodore Amiga

Sí, fue hace mucho tiempo ;-) Creo que el scroll a pantalla completa fue la cosa —nueva— principal para un juego. El resto era más bien programación en condiciones. Las cosas más elegantes vinieron con el Amiga...

¿Cómo era tu equipo de desarrollo? ¿Trabajaste directamente en el Amstrad con algún ensamblador o tuviste algún tipo de PC con conexión por puerto serie o paralelo al CPC? 

Todo fue hecho en el Amstrad pero, para ser sincero, no recuerdo qué ensamblador use. Puede parecer extraño, pero no soy capaz siquiera de visualizarlo ahora mismo.

¿Cuáles fueron los principales retos que encontraste haciendo The Vikings? ¿Cómo los solucionastes?

Hay algunos errores visuales pero nada serio. El marcador sólo se podía mostrar en la parte de abajo de la pantalla cuando el jugador no se está moviendo, lo cual no era perfecto... pero funcionó ;-) También hubo que resolver un montón de cosas pequeñas. Y, por supuesto, varios bugs serios —que hacían colgarse al juego— que cada uno llevó varios días para solucionar... tampoco teníamos sistema de debug ;-)

Edición española de The Vikings

Kele-Line hizo una fiesta de lanzamiento e invitó a varias revistas. El juego fue posteriormente publicado en el Reino Unido. ¿Qué recuerdas de ese emocionante tiempo tras terminar el juego y verlo en las estanterías? ¿Qué tal fueron los comentarios de los jugadores y las revistas?

De hecho, no recuerdo la fiesta de lanzamiento. Creo que es posible que no pudiese acudir. Pero, en serio, no la recuerdo. Por supuesto estaba emocionado de tener un juego publicado formalmente. Tengo algunos recortes de revistas en algún lugar, que eran bastante positivos.

¿Qué tal fue la paga por hacer el juego? ¿Recibiste royalties por las ventas en el extranjero? Se vendió incluso en España en 1988.

Kele-Line, la empresa con la que tenía el contrato, quebró poco después de que acabásemos el juego. Tuve muchísima suerte de cobrar el —razonable— adelanto, porque nunca cobramos ningún tipo de royalties.

¿Qué planes tenías al terminar The Vikings? Se dice que te viste en la necesidad de más potencia para hacer realidad las cosas que querías hacer y, de hecho, te hiciste con un lugar en la historia de los videojuegos gracias a Hybris y Battle Squadron en el Amiga. ¿Fuiste directamente al Amiga tras The Vikings o tenías todavía cosas en mente para el Amstrad CPC antes de dar el salto?

Hubo un corto periodo de tiempo en el CPC antes del Amiga, en el que trabajamos en nuevas ideas que nunca se materializaron. Søren tuvo un Amiga antes que yo y empezamos a trabajar en Sword of Sodan —no con ese nombre por entonces— y aprendiendo cómo programar el Amiga... que por supuesto era increíblemente mucho más potente que el C64 o el Amstrad. Entonces tomamos contacto con Discovery en los Estados Unidos, y empezó toda esa historia. Y de alguna manera Torben y yo empezamos a trabajar en Hybris. De hecho, para una compañía danesa primero, que más tarde haría el juego de televisión Hugo, el cual incluso estuvo en la parrilla televisiva española a comienzos de los 90. Lo sé, porque yo hice que las animaciones de la boca de Hugo encajasen con el idioma español... que sin embargo yo no entendía ;-)

El único Hugo que va al frame

Kele-Line publicaría más tarde Tiger Mission para C64, en el que Torben hizo los gráficos. ¿No estuviste tentado de portarlo al Amstrad CPC? 

No recuerdo exactamente la línea temporal de los hechos, y también tenía que ir a la escuela durante este periodo de tiempo ;-) Tal vez Tiger Mission se fue con la caída de Kele-Line.

The Vikings incluía música del legendario compositor Ben Daglish. ¿Cómo acabasteis colaborando con él? ¿Preparasteis algún tipo de material visual para que él se pudiera hacer una idea de lo que iba el juego?

Sí, eso fue un pelotazo en ese momento. Pero tengo que admitir que en ese momento no sabía quien era ;-) Creo que Kele-Line consiguió su contacto de alguna manera. Si recuerdo bien, sí que le preparamos una demo.

Cuando programas un 8 bits es imprescindible ahorrar cada byte de memoria y cada ciclo de procesador. Para Hybris y Battle Squadron tenías, no obstante, mucha más potencia disponible. ¿Aún así dirías que la constante lucha contra la memoria disponible y la potencia del procesador te ayudó a realizar mucho mejores juegos en el Amiga que otros desarrolladores que empezaron a trabajar directamente en la bestia de 16 bits de Commodore? 

Interesante pregunta. Nunca lo había visto de esa forma. Creo que hicimos que el Amstrad diese bastante de si, y creo que con la mayor potencia del Amiga también le hicimos llegar a sus límites... para siempre intentar parecernos lo más posible a los arcades ;-) que por supuesto eran nuestro ideal.

Battle Squadron para Commodore Amiga

¿Cuánta importancia ha tenido The Vikings en tu carrera? A ver, hoy día trabajas en biotecnología y no en videojuegos. ¿Pero dirías que esta experiencia trabajando con máquinas limitadas te ayudó más adelante en tu carrera?

Otra pregunta muy interesante. Creo que mi experiencia con ordenadores me entrenó de alguna manera a pensar en cualquier posible resultado en mi cabeza. Tenías que pensar en cualquier eventualidad de cada pieza de código, por ejemplo «qué pasaría si esto» y «qué pasaría si lo otro». Eso es bueno para la lógica, y también para números y matemáticas. Supongo que la programación entrenó nuestros cerebros muy bien ;-)

¿Tienen el Amstrad CPC y The Vikings un lugar aun en tu corazón? ¿No te sientes tentado a volver algún día y enseñar de nuevo como se hace un buen juego de Amstrad? Tal vez tras jubilarte... *risas* 

Hicimos Battle Squadron para iOS a comienzo de los 2010 y, de hecho, terminé en un 90% el Hybris un par de años más tarde. También pensé en hacer The Vikings para iOS para completar. El problema es tener suficiente tiempo ;-) Y un juego nuevo necesita mucho más tiempo obviamente. De algún modo también quiero acabar en todo lo alto y no intentar hacer algo que nunca será lo mismo que entonces...

De nuevo muchas gracias por tu tiempo y tu amabilidad. ¿Hay algo que te gustaría añadir para nuestros lectores?

Han sido buenas preguntas. Y, creo, la primera vez que me han entrevistado por The Vikings en las últimas décadas. Previamente me han preguntado solo por mis juegos de Amiga, así que ha sido una muy agradable experiencia, ya que también estoy muy orgulloso de The Vikings :-) Eran tiempos completamente diferentes entonces y, obviamente, esa manera de trabajar y de como usábamos la tecnología nunca volverá. Es un poco triste pensar en ello, pero también ha sido muy chulo haber sido parte integral de ese periodo único.

First of all let me thank you for your time and your kindness in accepting this interview. It's an honor to be able to learn a little bit more about one of the most impressive Amstrad games ever made. Let me start from the beginning: How did your interest in technology start?

A friend of mine and I were interested in electronics already at an early age, and also arcade games. From then on it was a natural step to get into home computers when they started appearing around 1980.

Which ones were the first machines that entered your life?

The first machine I bought was a used ZX80 that was actually “converted” into a ZX81. After that a ZX Spectrum, Amstrad, and Amiga. We did not understand English at the time, so there was a lot of “guessing” for using them.

We usually find that game developers are heavily influenced at the beginning of their careers by the games they were playing at a young age. Which games were your favorites?

It was mostly arcade games at the beginning. Then later, ZX Spectrum games like Manic Miner and Jetset Willy. And for example JetPac was super cool at the time, almost arcade style.

Søren and Martin. Photo courtesy of Mr. Pedersen.

For most of us, just enjoying games was enough. What motivated you to create your own games?

We understood that you could “program” these machines quite early on. And somehow that fascinated us. Then the interest in games made it kind of a natural step to start doing that.

One thing is to say “I want to make my own game!” and another one is being able to do so. How did you learn to code? What resources did you have at hand to learn?

That is a good question. With the ZX81 we did not understand English, as mentioned above, so a lot of guessing and trial and error. And copying small programs from computer magazines. Later, I bought a book (in Danish even) on how to program the Z80 processor, probably during the ZX Spectrum “period”. That was probably the main leap forward. But always a lot of trial and error. At the beginning we were manually programming using the BASIC command POKE to add single bytes of our assembler language code ;-)

North Europa was Commodore territory. How did you end up working with Amstrad machines?

It is probably a coincidence. For some reason we first got into the ZX81, then naturally ZX Spectrum. Somehow the C64 never “caught my attention”.

Loading screen of The Vikings

How was having an Amstrad in a territory heavily controlled by Commodore? Could you still have access to magazines, books, games or was it really more difficult to you when compared with your friends with a C64?

I did not know anybody who had a C64, maybe a few years later. So really, it was mostly how my friend and I made the choices, and that was on the Sinclar machines, which were eventually also quite popular.

At what point do you realize that your code is good enough to try to market it? Do you have any examples of routines or programs that you made before working on The Vikings?

We must have tried to make game-like programs on the ZX Spectrum, but I cannot recall the details right now. Then on the Amstrad it probably accelerated. Soon I understood that it was possible to make full screen scroll on the CPC, from seeing the text based command line with BASIC. By then we had seen many games on various arcades and home computers, likely 100+ for each, and with some programming experience I/we understood it was possible.

The Vikings in action

How did you end up working on The Vikings?

There was an ad in a magazine, I think it was, that a new Danish company was looking for people to make computer games. So my friend and I went there. We must have been 14 or 15 years of age. I still have some vague visual memory of the meeting. And it was at a “fancy” conference hotel in Copenhagen… so quite an experience. We were probably around 20 guys sitting at tables in a U-shape. And there was a UK company there as well, working with the Danish one.

The main work for The Vikings was done by Søren Grønbech on the C64 and you on the CPC, with Torben Bakager doing the graphics. How was the creative process? How was the gameplay, graphic style, level design, etc decided? What was your creative input?

To be honest, I think that Torben was the main driver for the creative work, but of course I also had input. I actually don’t recall exactly how we worked. But we must have discussed a lot of things, and also what was possible on each machine (C64/Amstrad). Søren incidentally lived just 5km from me, and Torben maybe 20km. Sometimes we worked at Søren’s, sometimes at my home. I remember that while I was on vacation one time Torben and Søren had made the entire map for the game. Since we had no digital way to digitally transfer the data between the C64 and Amstrad, we printed it out with maybe 12 or 16 bytes per line, with a control character at the end. And then I paid a friend, who also had an Amstrad, to enter all the values and give a disk to me with it all ;-)

In the USA with other coders. Torben is behind Søren.

Søren was already a well respected demoescener on the C64 with a deep understanding of the Commodore Machine. Did that maybe incentivized you to bring the best out and try to beat him with your coding skills?

I was not into the demo scene at all at the time, maybe not even really aware of it on the C64. I don’t think we really were in competition. We were making The Vikings on two different machines, and I think we each just wanted to do a great job… and work together :-) And I had built quite solid competencies over the previous years with my friend from school I also mentioned above… so I knew I could do it…

The Vikings on the Amstrad is one of the few examples of hardware scrolling on the machine at a decent level. In order to do that, you had to understand the black magic behind the CRTC and Gate Array chips. How did you learn to do that? How came that you were able to triumph where older and more experienced developers weren't able?

As mentioned above, the idea actually came out of seeing the screen scroll when writing on the main screen in BASIC on the Amstrad. Somehow, it intuitively showed me it was possible to do full screen scroll. Many (prior) games on the Amstrad instead used a much smaller game window, with a lot of (unnecessary) information on the greater part of the screen area (to “justify” the game screen was so small, I guess). I remember thinking I could do a much better job than they had done on Rambo ;-) I took some time to make it work for The Vikings, also for left and right scroll. But I knew from the beginning it should be possible :-)

Hybris for the Commodore Amiga

We know: it was 40 years ago :-) Anyways we must try: do you remember any particular tricks or code that helped you bring out all the power inside the Amstrad?

Yes, it is “forever” ago ;-) I think the full screen scroll was the main (new) thing for a game. The rest was more regular, solid coding. The more “fancy” stuff came in the Amiga era…

How was your coding setup? Did you work directly on an Amstrad with an assembler software or did you have any kind of PC + serial or parallel port to the CPC?

It was all done on Amstrad. But to be honest I don’t remember which assembler program I used. It may sound strange, but I cannot even visualize it now.

What were the biggest challenges that you had during The Vikings? How did you solve them?

There are a few “visual mistakes”. But nothing serious. The score could only be shown at the bottom of the screen when the player was not moving, which was not “perfect”... but it worked ;-) There also have been lots of smaller things to solve. And of course various serious bugs (making the game crash) that each took many days to solve… there was also no debugging system ;-)

The Vikings Spanish Edition

Kele-Line did a release party and invited some magazines. The game was later published in the UK. What do you remember about that exciting time after finishing a game and seeing it on the shelves? How was the feedback from players and/or magazines?

I actually don’t remember the release party. I think that maybe I was not able to join. But really, I don’t remember. I was of course excited about having a game formally published. I have some old magazine clippings somewhere, which were quite positive.

How good was the pay for that work? Did you see any royalties from sales overseas? It was sold even in Spain in 1988.

Kele-Line, which I had the contract with, went bust soon after we finished the game. I was extremely lucky to get the initial (reasonable) payment, because we never received any royalties.

What plans did you have for after The Vikings? It is said that you found yourself in need for more computing power to be able to bring out what you wanted to do, and you actually made yourself a place in videogame history thanks to Hybris and Battle Squadron on the Amiga. Did you jump to the Amiga right after The Vikings or had you anything in mind still for the Amstrad CPC before switching?

There was a short period on the Amstrad before the Amiga, where we worked on new ideas that never materialized. Søren got an Amiga before me and we started working on Sword of Sodan (not the name at the time) and learning how to program the Amiga… which of course was amazingly more powerful than the C64 or Amstrad. Then we also got in contact with Discovery in the US, which started that whole story. And somehow Torben and I started working on Hybris, actually first for a Danish company that later would go on to make the “live TV game” Hugo, which even went on TV in Spain in the early 90’es… I know because I made the mouth animations for Hugo fit the Spanish speak… which I did however not understand ;-) 

It is the scene where Hugo is running towards the right in the forest. And has to jump over stones and duck branches. It is actually the only Hugo game of that series of 4 parts that is running each frame... something I guess came from my experience with Hybris and Battle Squadron on the Amiga ;-)

The only Hugo game running each frame

Kele-Line would later publish Tiger Mission on the C64, with Torben doing the graphics. Were you not tempted to port it to the Amstrad CPC?

I don’t exactly remember the timing of things, and I also had to go to school during this whole period ;-) Maybe Tiger Mission “went away” with the downfall of Kele-Line.

The Vikings included music by no one other than legendary composer Ben Daglish. How did you end up collaborating with him? Would you produce some visual material for him so he could have an overall idea of how the game was?

Yes, that was quite hot stuff at the time. But I have to admit I was not familiar with him at the time ;-) I think maybe Kele-Line got the contact somehow. And if I remember well, then we did indeed send a demo.

It was crucial to save every byte of memory and processor cycle when programming for 8 bit computers. For Hybris and Battle Squadron you had a lot more power available but would you say that the constant race against the remaining memory and the processor power helped you produce much better games on the Amiga as other developers who started working directly on the 16 monster from Commodore?

Interesting question. Never thought about it like that. I think we pushed the Amstrad quite hard, and with the more power of the Amiga I think we just pushed that to the limit as well… to always get as close as possible to the arcades ;-) which of course was our “ideal”.

Battle Squadron for Commodore Amiga

How important have been The Vikings in your career? I mean, you work nowadays in biotechnology, not in videogames. But did this experience working with limited machines helped you later in your career?

Also, a very intriguing question. I think my experience with computers somehow trained me to think about “every possible outcome” in my head. You had to think about every eventuality of every piece of code, i.e. what if this, and what if that. That is good for logic. And also for numbers and math. I guess the coding “trained” our brains quite well ;-)

Is there still a place in your heart for the Amstrad CPC and The Vikings? Aren't you tempted to make a comeback someday and show again how to do a good Amstrad game? Maybe when retiring... ????

We did Battle Squadron on iOS in the early 10’s. And actually I finished Hybris about 90% a couple of years later. I also thought about making The Vikings for iOS “for completion”. The problem is having enough time ;-) And a new game would obviously require a lot more. In a way I also want to have ended on a “high note” and not try to make something, which would never be the same as back then…

Once again, thank you so much for your time and kindness. Is there anything that you would like to add for our readers?

It was great questions above. And the first time, I believe, I was “interviewed” the past many decades regarding The Vikings. Previously, only about our Amiga games. So quite a nice experience as I am also quite proud of The Vikings :-) It was a completely different time back then, and obviously that way of working, and how to use the technology, will never come back. It is a little sad to think about it in a way, but also cool to have been an integral part of that unique period :-)

En un mundillo tan dinámico y vibrante como es la creación de videojuegos, nos vemos muchas veces deslumbrados por las personalidades arrolladoras que acaparan la atención allá por dónde van. Es importante no olvidarnos de esos otros profesionales que con humildad y tesón no solo nos dieron grandes títulos que nos acompañan desde entonces, sino que siempre estuvieron ahí al quite sin darse la mayor importancia. Hoy tenemos el enorme honor de hablar con una de las personalidades de la época de los ocho bits más brillantes y a la vez más humildes y autocríticas con su propio trabajo. Con todos ustedes: James Higgins.

ENGLISH INTERVIEW AFTER THE SPANISH TRANSLATION

Recuerdo algunos sistemas primigenios que disfruté siendo niño. Uno de ellos era un clon portátil del Scramble. Jugué un montón con él. Diría —tras una búsqueda rápida en Google— que es el Grandstand Scramble.

Tuve también algún sistema antiguo parecido a la Intellivision —tal vez la Grandstand VideoSports Centre 5000— que ejecutaba una variedad de juegos —malos— que eran más o menos variantes del Pong pero llamadas en plan Soccer y Hockey, pero que en realidad no hacían mucho más allá de rebotar un cuadrado blanco por la pantalla. Al final era muy decepcionante ya que nunca estaban a la altura de sus promesas...

Nueva aparición del ZX81 en nuestras páginas

Recuerdo a un amigo de la escuela que trajo un ZX81 cuando yo tenía unos 14 años. Creo que también tenía un libro de listados con 50 juegos. Parecía prometer entretenimiento ilimitado. Recuerdo que pensé: «nunca tendría que volver a comprar un juego; simplemente los tecleo...». Fui  a casa y supliqué un ZX81. Creo que llegué a pedir prestadas 50 libras —una pequeña fortuna por aquel entonces :)— con la promesa de devolverlas a ritmo de una libra a la semana. No estoy seguro de que llegase a pagarlo todo entero de vuelta. 

Tecleé todo listado que pude encontrar. Cada mes esperaba a que llegase a la biblioteca de la escuela el último número de Your Computer que tuviese listados. A veces venían esos listados en código máquina; página tras página de dígitos hexadecimales que tenías que teclear trabajosamente y rezar para que no te hubieras equivocado en ninguno.

Tecleé tantos listados en BASIC que aprendí como montar algún juego rudimentario juntando código de esos listados. También hice mis pinitos en código máquina; el manual del ZX81 traía al final las instrucciones del Z80 y me ponía a probar cosas y a fracasar horriblemente. Estaba más allá de mi entendimiento. De acuerdo, el código máquina no es lo mío, pensé.

«El manual del ZX81 traía al final las instrucciones del Z80 y me ponía a probar cosas y a fracasar horriblemente»

De todas formas el ZX81, con su 1KB de memoria, era muy limitado y soñaba con tener la expansión de memoria de 16KB. El momento de «tengo que tener uno» fue cuando fu´ a una feria de informática de un pueblo cercano. No recuerdo dónde o como llegué allí, pero fue en la entrada de una vieja iglesia y recuerdo ver un ZX81 —con 16KB— ejecutando un clon en alta resolución de Space Invaders. Me voló la cabeza. Fue como ver la Capilla Sixtina o "el David" de Miguel Ángel. Fue precioso.

Compré poco después una ampliación de memoria de 16KB a cuenta de un importante sacrificio personal: vendí mi colección de cómics de 2000AD a una tienda de cómics local. Era el momento de ponerse en serio a hacer juegos. Por desgracia, nunca terminé de pillarle el truco al Z80 y supliqué un ordenador nuevo.

Llegaron las navidades y tuve como regalo un Dragon 32. En Reino Unido teníamos esos catálogos de venta por correo que permitía a gente de pocos recursos gastarse demasiado dinero —gracias, mamá— haciendo pagos durante todo el año. Por desgracia, no tenían disponible todos los ordenadores del momento, así que acabé con un Dragon 32 —y muy agradecido que estuve—...

Respecto al Amstrad CPC; volvió a llegar la Navidad... aunque no estoy seguro de cuantas navidades habían pasado —posiblemente una—. Gracias de nuevo, mamá. Esta vez con mis recientemente adquiridas habilidades con el 6809 y mi estatus de autor publicado, logré dominar el Z80. Entendí todo —más o menos— y empecé a hacer un juego nuevo... aunque pasé demasiado tiempo jugando. Un juego que me impresionó sobremanera en ese momento fue Sorcery.

Mientras tanto, vi el infame anuncio de Ocean. Llamé por teléfono, hablé con Gary Bracey y no parecía muy emocionado de tener a otro programador de Z80 con 0 títulos publicados, pero... yo podía programar el 6809, y gracias a ese pequeño detalle la conversación cambió completamente para mejor. Pronto estuve camino de Manchester y conocí el Thomson MO5...

Sorcery es considerado el primer gran juego para CPC.

Normalmente vemos que muchos desarrolladores están fuertemente influenciados por los primeros juegos a los que solían jugar al principio. ¿Cuáles eran tus favoritos?

Chucky Egg para Dragon 32 era fácilmente mi juego favorito de esa era. Uno de los puntos fuertes de ese juego era que permitía a varios jugadores tomar turnos entre vidas. Crecí con cinco hermanos así que hacer turnos y observar las estrategias en cada nivel a tiempo real era muy divertido.

Otro favorito mío era Sorcery en el Amstrad. Era muy suave y tenía un aspecto maravilloso.

Knight Lore me voló la cabeza. Me quedé mirándolo durante demasiado tiempo, simplemente preguntándome cómo demonios lo habían hecho. A este programador novato le parecía imposible hacer eso.

Elite. De nuevo simplemente increíble. ¡¿¡¿Cómo es esto posible!?!?

Get Dexter en el CPC. Ese también molaba mucho.

En la actualidad. Foto cortesía de Mr. Higgins

Para la mayoría de nosotros era suficiente diversión jugar a los juegos. ¿Qué te llevó a ti a crear los tuyos propios?

La falta de ingresos. Supuse que si lograba hacerlos no tendría que gastar mis limitados recursos en comprarlos. Tampoco era el niño más sociable, así que posiblemente era también una vía de escape para no tener que socializar y salir al mundo exterior.

Una cosa es pensar «¡quiero hacer mis propios juegos!» y otra muy distinta ser capaz de hacerlo. Por supuesto, entonces no teníamos a Google o a GitHub *risas*. ¿Cómo aprendiste a programar? ¿Qué recursos tenías a mano para ello? ¿Cuáles eran tus favoritos?

Mi fuente principal de conocimiento fue la revista Your Computer. Todos los meses iba a la biblioteca de la escuela a intentar conseguir la copia que nos llegaba tan pronto como entrase. Si alguien la cogía antes que yo, volvía diariamente hasta que fuese mi turno.

También leí cualquier libro que pude encontrar en WH Smiths/John Menzies. Echaba una ojeada a cuanto podía e intentaba recordar detalles para probar más tarde.

Dragon User/Amstrad User también solían tener artículos sobre programación. Cogías lo que podías de ellos y experimentabas. Era un crío; no tenía nada, salvo tiempo. Me quedaba despierto hasta tarde, a veces durante toda la noche, probando cosas o tecleando listados realmente largos de las revistas.

Primeros destellos de calidad en The Apprentice

Intenté venderlo casi de inmediato: Asteroids y Jumbo´s Troubles para el Dragon 32 y The Apprentice para el CPC464. Tan pronto como tuve un bucle básico de juego. Por suerte para mí, el listón no estaba muy alto. Si lograbas algo que se moviese en pantalla, tenías una oportunidad. Tuve mis rechazos (Asteroids), mis fracasos comerciales (Jumbo´s Troubles) y entonces llegó mi primer éxito con The Apprentice. Mastertronic lo cogió para su catálogo aunque había sido rechazado por BT —que entonces tenía un sello de juegos económicos—. Creo que pensaban que había hackeado o copiado al Sorcery, lo cual no era cierto. Ni siquiera hubiera sabido hacer eso por entonces, pero sí que estaba fuertemente inspirado en él.

Anuncio de Wizard Software

Empezaste tu carrera con el Dragon 32. ¿Qué nos puedes contar sobre tu trabajo en esa máquina? ¿Cuán difícil fue intentar vender tus creaciones? ¿Para qué empresas trabajaste?

Escribí un clon del Mappy —un arcade de Namco— aunque no tenía ni idea de lo que estaba clonando, ya que lo basé enteramente en la descripción que me hizo mi hermano Tom de lo que había visto jugándolo en un recreativo durante una excursión escolar. Solo descubrí hace poco que era el Mappy. Vi algunas capturas de pantalla en un artículo sobre Namco y tuve un momento revelación. Nunca vi la máquina arcade. Lo hice basándome completamente en la descripción que me hizo mi hermano. Una vez "terminado" encontré a un publisher —Wizard Software— que accedió a publicarlo. Vendió tres copias... pero no estuve totalmente descorazonado.

Wizard Software solía publicar anuncios a un cuarto de página en la revista Dragon User. Tras bucear un poco en Internet lo he encontrado en una vieja Dragon User en archive.org. Página 32, arriba a la izquierda.

Eso fue en junio de 1985. Entonces tenía 16 años —casi 17—. Mi primer juego publicado.

Un jovencísimo James en las oficinas de Ocean. Cortesía de Mr. Higgins

Encontraste dificultades en el mismísimo comienzo de tu carrera con una máquina que estaba teniendo problemas para alcanzar el éxito. Por otro lado, posiblemente estabas leyendo historias de éxito, Porsches y fiestas, en las revistas. ¿Qué te motivó a no rendirte y seguir intentándolo?

El Dragon 32 tenía una CPU 6809 y simplemente conecté. Lo pillé. Por fin pude hacer algo de código máquina. Todavía era joven —tenía unos 15 o 16 años— pero estaba determinado a hacer juegos. Hice un clon del Asteroids bastante malo y lo envié a todos los publishers que pude encontrar en la revista Dragon User. Recibí un montón de cartas de rechazo. Era un clon de Asteroids bastante malo pero... ya iba por buen camino...

Puedes ver en esas antiguas revistas de Dragon 32 que tenían artículos sobre código máquina y un montón de artículos de "como hacer", todo condensado en 30-40 páginas. Eso es todo lo que teníamos entonces: información limitada y muy condensada. Ahora tenemos acceso a casi demasiada información. Es fácil distraerse en vez de seguir adelante.

Entrevista para TV en Ocean. Foto cortesía de Mr. Higgins

Ya había empezado a trabajar para Ocean como freelancer más o menos por las mismas fechas en las que Mastertronic publicó The Apprentice, aunque a veces tengo borrosos un poco los recuerdos. Esos primeros trabajos para Ocean eran para la serie de ordenadores Thomson.

En realidad no elegí el Amstrad, ya que me hubiera encantado tener un Spectrum, pero si no se podía comprar a crédito no iba a tenerlo nunca. No teníamos mucho dinero en casa y el Amstrad estaba disponible en los catálogos de venta por correo a crédito. Es como conseguían sus regalos de Navidad un montón de niños de familias con bajos ingresos. Sigue siendo cierto a día de hoy posiblemente, con tarjetas de crédito. Me va muy bien ahora pero estoy donde estoy gracias a los sacrificios que hicieron mis padres.

El Amstrad era un gran ordenador. Tenía un excelente BASIC, una buena pantalla y un buen teclado. Era un salto adelante desde el ZX81.

Portada de The Apprentice. Fuente: CPC-Power

¿Qué nos puedes contar sobre el desarrollo del The Apprentice? Dijiste que la principal fuente de inspiración fue Sorcery ¿pero cómo decidiste por ejemplo el diseño de niveles, los gráficos, etc?

Sí, Sorcery era mi inspiración. Se veía increíble e iba súper suave. Debido a mi ambición juvenil —¿o tal vez arrogancia?— pensé que podía hacerlo pero más grande y mejor. Fracasé en la mayor parte de ello pero mis objetivos eran más pantallas —Sorcery tenía 40 y yo hice 100—; Sorcery tenía sprites con Xor y yo tenía sprites con máscaras; Sorcery iba a 50 fps y yo iba a 12-15. Ejem. Tenía mucho que aprender :( Pero lo terminé. Se veía decente. Estaba terminando el instituto (18 años) y tenía que tomar decisiones. Necesitaba un trabajo. No tenía ni idea de que iba a hacer...

Hice un editor de mapas que me permitió hacer 100 pantallas usando compresión por bloques. Quería que tuviese 100 pantallas y la única manera de lograrlo era que ocupasen una pequeña fracción de memoria. Creo que cada pantalla era menor a 20 bytes. Cada pantalla estaba hecha de seis bloques; tenía tal vez unos 128 de esos bloques y los podía colocar según necesitase. Por desgracia eso hizo que algunas pantallas se pareciesen un poco.

Con asombro he encontrado este post que tiene un mapa entero del juego... Si lo miras fijamente veras algunos de los tiles que se repiten.

Sigo queriendo contactar con él solo para quitarme el sombrero por su paciencia. Y algún día terminaré Castlekey...

Envié The Apprentice a varios publishers y esperé...

Modos múltiples en The Apprentice. Fuente: CPC-Power

¿Qué tal fue trabajar para Mastertronic? ¿Podía uno ganarse bien la vida con sus royalties?

Sólo publiqué un juego con Mastertronic. Solo tengo cosas buenas que decir de ellos. Me pagaron 8 peniques por copia vendida. Yo era feliz simplemente por haberme publicado el juego. Me enviaron regularmente por correo detalles de royalties y cheques durante un año o dos. Creo que vendió alrededor de 60.000 copias. No era una enorme cantidad de dinero pero tenía 18-20 años por entonces y parecía una fortuna.

Mastertronic intentó ponerle música de verdad al juego. Recibí una llamada de Rob Hubbard, preguntándome cuanta memoria quedaba libre para la música. Le dije que 600 bytes y ahí acabó todo. Así que la espantosa versión marcha fúnebre de Greensleeves permaneció en el juego. Creo que pillé esa música de un listado de la Amstrad User.

Reunión en California en 2008. De izquierda a derecha: Gary Bracey, John Brandwood, Lorraine, Marc Djanm, James Higgins, Mick West, Jon Dunn y Paul Robinson. Foto cortesía de Mr. Higgins.

Cómo mencionábamos anteriormente, por esas fechas consigues trabajo en la legendaria Ocean Software, más o menos por las mismas fechas en la que Ocean estaba montando lo que hoy llamaríamos un equipo interno de desarrollo, bajo las ordenes de Gary Bracey. ¿Cómo fue el proceso, entrevistas de trabajo, etc., para conseguir trabajo en la empresa?

Fue notablemente fácil. Hice una llamada y ya estaba en camino a Manchester en una semana. Dije que sí a todo lo que me preguntaron. «¿Puedes programar el 6809?» SÍ. «¿Puedes hacer Green Beret para esta máquina?» SÍ, SÍ. «¿Lo harías por 2.500 libras?» SÍ, SÍ, SÍ. «De acuerdo, te mandaremos un contrato».

Cogí un tren de vuelta a Glasgow. Puede que incluso llevase de vuelta a casa un Thomson MO5. Creo que me dieron una bolsa de viaje de Ocean. Recuerdo llamar a mi madre desde una cabina telefónica y contarle que iba a ganar 250 libras por este trabajo. Ella estaba encantada con ello y entonces fue cuando le dije la verdadera cantidad que iba a ganar. Era —por entonces— una enorme cantidad de dinero. Literalmente fui a casa en una nube. Era muy difícil permanecer con los pies en la tierra en ese momento. Todo parecía demasiado irreal.

Desde ese acuerdo inicial, pronto se volvió un acuerdo para hacer más —técnicamente yo no había dado permiso contractualmente pero no me importaba— y también convertirlo a toda la gama completa de Thomson (TO7-70/TO9). Convertirlo suena como si yo tuviera material con el que trabajar. De eso nada, simplemente jugué al Green Beret de Spectrum. Hice lo mejor que pude por lograr algo parecido, pero el Green Beret de Spectrum había puesto el listón muy alto y me quedé muy por debajo. Pero... todo el mundo parecía lo suficientemente contento con mi trabajo.

Green Beret para la serie Thomson MO

Aunque podías programar para el Dragon 32 y el Amstrad CPC, ya vemos que tus primeras tareas en Ocean consistieron en convertir juegos como el Green Beret y el Arkanoid a una máquina francesa —la serie MO de Thomson—. ¿Realmente cómo acabaste haciendo esas conversiones? ¿Qué experiencia tenías con esa máquina?

Tenía cero experiencia. Me dieron un MO5 y todos los manuales franceses. Tuve literalmente que figurarme como funcionaba todo a la vez que hacía Green Beret. 

Una vez acabé Green Beret tuve que viajar a las oficinas de FIL (el publisher) en Paris. Era mi primer viaje al extranjero y mi primer vuelo. Tuve reuniones con los ejecutivos. Fue todo tan extraño... Me preguntaron si podía hacer que los rojos fueran un poco más diferentes; yo les expliqué las limitaciones de la paleta. Me pidieron si podía hacer el scroll más suave; yo les expliqué la poca potencia de la CPU unida a un buffer el doble de grande que el de Spectrum. Salí de allí con algo de software y un TO7-70/TO9. Volé de vuelta a Glasgow y logré introducir en el país todo el equipo sin pagar tasas de aduana.