Era el comienzo de los años 80’s y fue el abuelo César quien, en nuestras acostumbradas caminatas por la peatonal San Martín, se atrevió a llevarme por primera vez a SACOA de la ciudad de Mar del Plata, Argentina. A pesar del tiempo y de los avatares económicos que continuamente azotan al país, todavía sobrevive en el mismo sitio donde fue fundada hace 40 años atrás. Se encuentra en el subsuelo del edificio que lleva el mismo nombre, y para ingresar se debe bajar por una larga escalera que forma un mágico túnel que nos sumerge en el mundo de los arcades.
Todavía recuerdo claramente el impacto que recibí al bajar con mi abuelo por primera vez a ese místico lugar. Islas cuidadosamente ordenadas con unos extraños muebles plateados, que emitían fulgurantes imágenes monocromáticas, llenaban el lugar. «Break Out», «Pong», «Lunar Lander», «Asteroid» y «Space Invaders» eran algunos de los títulos que recuerdo. El flash fue tremendo y la marca, para toda la vida.
Tuvo que pasar un tiempo para que mi madre me llevara con una profesora del barrio que enseñaba algo nuevo y totalmente desconocido para mí: computación. Solo fui una clase, pero fue suficiente para descubrir ese nuevo aparato llamado computadora que era capaz de ejecutar juegos muy parecidos a los que había visto meses atrás en la galería de arcades.
Poco después, las home computers se hicieron famosas y con ellas explotó el furor por la informática en Argentina. Talent MSX, Czerweny CZ Spectrum y Drean Commodore eran algunas de las máquinas más conocidas. Descarados trucos publicitarios nos prometían poderosísimas herramientas informáticas con las que cualquier hijo de vecino podría desarrollar complejos programas administrativos o fabulosos juegos de nivel comercial. Quizá porque la máquina en la que me tocó aprender, en un conocido instituto de computación de la época, fuera una antigua Tandy Radio Shack TRS-80 monocromática y sin sonido, o quizá fueran los escasos 12 o 13 años con los que contaba en esa época, la cosa es que nunca pude programar ningún juego de éxito mundial, es más, nunca pude terminar de programar un juego que funcionara.
El tiempo pasó y la vida me llevó para otros rumbos. Pero un día, aquello que estaba dormido en mí despertó y gracias a un artículo sobre lenguaje assembler de Commodore 64 que leí en un sitio de Internet, el sueño de programar un juego revivió con más ganas que nunca.
Alguien dijo alguna vez que 20 años no es nada, pero 40 años ya es un montón de tiempo y la informática cambió mucho desde la época de las home computers. Hoy, un simple teléfono celular posee 100.000 veces más potencia que las computadoras que pusieron al hombre en la Luna, pero (sobre todo) cambió el acceso a la información. En los años 80’s, las home computers se vendían con un escueto manual del usuario que apenas enseñaba cómo conectar cables y, con suerte, una mínima lista de comandos e instrucciones BASIC soportadas. Además, en esta parte del mundo era muy difícil encontrar algún libro o manual avanzado a precio razonable.
Hoy, por suerte, todo eso es cosa del pasado y no existe bibliografía editada en la época que no esté disponible para su descarga en formatos digitales. Con unos cuantos libros y manuales puse manos a la obra y arranqué el proyecto del juego propio.
Para comenzar con esta aventura decidí fortalecer primero conceptos básicos programando un juego simple. «Space Invaders» de Toshihiro Nishikado fue el elegido, no solo por su historia, sino porque es uno de mis juegos preferidos. El tiempo me demostró que, al contrario, no es un juego simple, y se constituyó de entrada en un excelente desafío.
Una vez planteado el objetivo, faltaba saber de qué manera lo llevaría adelante. Assembler fue el lenguaje de programación elegido desde el primer momento. Algunos dirán que es el lenguaje con que hablan los demonios, pero luego de aprender sus fundamentos, más que un lenguaje de espectros, es el lenguaje de los ángeles y el silicio. La simpleza, eficiencia y elegancia son sus principales credenciales, y no conozco juego importante que no se haya escrito en este noble dialecto informático.
Seamos claros: no tiene sentido programar en la Commodore 64 habiendo tantas buenas herramientas disponibles en PC para realizar el desarrollo cruzado. Llamamos así al método de trabajo por el cual se genera código para una arquitectura distinta de la que se está usando para ejecutar las herramientas de desarrollo. En este caso, generé código en PC para que se ejecutara en una Commodore 64.
Específicamente, para la programación en assembler, el diseño de sprites y el diseño de caracteres, utilicé la suite CBM PRG Studio. Una suite muy completa, por cierto, de fácil manejo e instalación. Por su exactitud en la emulación, las facilidades que otorga para la depuración y por documentación disponible, VICE (Versatile Commodore Emulador) fue el emulador elegido.
Ya tenía la idea y las herramientas. El próximo paso fue analizar el Space Invaders original e iniciar la conversión a Commodore 64.
Haciendo un poco de historia, recordemos que Space Invaders salió al mercado a mediados de 1978, siendo un éxito inmediato. Aunque parece más una leyenda que una realidad, se dice que fue el responsable de la escasez de monedas de 100 yenes de ese año en Japón. Originalmente corría sobre la plataforma TAITO 8080, basada en el microprocesador de 8 bits Intel 8080 corriendo a 2 Mhz., y en la cual funcionaron 27 juegos. El Multi Arcade Machine Emulador (MAME) fue un gran aliado para llevar a cabo su análisis.
El juego utiliza un monitor monocromático rotado en 90 grados que posee unas tiras de transparencias de colores superpuestas en ciertas partes del monitor, las cuales ayudan a simular una imagen en colores. La pantalla tiene una resolución de 256 x 224 píxeles representada en memoria con el esquema de un pixel por bit, ocho píxeles por byte de memoria. Dicha memoria está dividida en 8 Kb de ROM, 1 Kb de RAM y 7 Kb de RAM de video, formando una configuración de 16 Kb. El sonido está generado en su gran medida de
forma analógica.
Hasta aquí parece una configuración razonable. El problema comienza con la cantidad de elementos a mover en pantalla. El block de invasores está compuesto por 5 lineas de 11 naves alienígenas cada una. Existen tres tipo de naves y cada una está formada por una animación de dos cuadros que simula el movimiento de las mismas. De entrada debí descartar el uso de sprites para dibujar los invasores: recordemos que la Commodore 64 soporta solo 8 sprites por hardware, muy lejos de los 55 que necesitaba para armar el block.
Aquí es donde comencé a buscar alternativas. La Commodore 64, de 8 bits, posee varios modos de video que se separan en dos grupos, el modo caracter y el modo bitmap. En el primer grupo se encuentran los modos en donde la pantalla se divide en celdas de 8×8 píxeles y cada una refiere a un caracter almacenado en la ROM o en la RAM del sistema. En el segundo grupo conviven los modos en donde la pantalla también se divide en celdas de 8×8 píxeles, pero cada uno de los píxeles que componen la celda se puede modificar por separado, ya que poseen una posición individual en la memoria RAM.
Con los modos de pantalla del segundo grupo se puede calcular en tiempo de ejecución cada uno de los píxeles que componen los alienígenas, y es la forma que utiliza el juego original para representar los movimientos en pantalla. El principal problema de este segundo grupo es que ocupan mucha memoria y tiempo de procesador. Ahora, ¿por qué hacer que el procesador calcule pixel por pixel cada uno de los alienígenas si puedo precalcular los movimientos y cargar las imágenes de la animación en forma de caracteres y mostrarlos cuando los necesito? Este es el camino que ofrece el modo caracter estándar con caracteres programables y es el que elegí para realizar la representación de los 55 invasores.
Cada invasor tiene una altura de 8 píxeles y la primera línea de ellos también posee 8 píxeles de ancho. Cuando ves un personaje moverse en pantalla, lo que estás viendo es una sucesión de fotogramas que pasan a gran velocidad a fin de dar sensación de movimiento. Como el invasor posee 8 píxeles de ancho, necesitamos 16 fotogramas para generar la animación de desplazamiento entre dos celdas. Hay que recordar que el invasor está compuesto por una animación de dos cuadros que se alternan por cada paso, lo que nos dejaría ocho cuadros pares y ocho impares para completar la animación de movimiento de una celda de 8×8 a la próxima contigua. Luego de eso, solo tuve que dibujar cada cuadro en una hoja de papel milimetrada y después ingresarla al programa en forma de caracter programable.
Almacenar un valor booleano del tipo “presente/no presente” en un byte de memoria es una forma sumamente ineficiente de utilizar la RAM. Podría haber optimizado la matriz guardando un invasor por bit, pero curiosamente la memoria no es lo que me faltaba y el almacenamiento en byte simplifica notablemente las rutinas del juego. Cabe destacar que en máquinas de bajos recursos, como lo es nuestra querida Commodore 64, continuamente se debe hacer un balance entre velocidad y uso de memoria. El microprocesador es lento y no es conveniente hacer que realice muchos cálculos matemáticos, motivo por el cual hay veces que es más conveniente malgastar memoria a fin de simplificar el trabajo del procesador MOS 6510. Con esa matriz, un set de caracteres gráficos cargado con los cuadros de animación, algunas variables de control general del block y una buena rutina de desplazamiento, obtuve el movimiento completo de los 55 invasores.
Originalmente, el software del Space Invaders maneja por un lado los elementos animados que se deben calcular en pantalla (invasores), y por otro lado cinco objetos que son tratados de manera diferentes. Estos objetos son: el jugador en la parte inferior de la pantalla (1), el disparo del jugador (2) y las bombas de los invasores (3, 4 y 5). El platillo volador (flying saucer), que cruza la pantalla en la parte superior de ella en ciclos de aproximadamente 30 segundos, comparte objeto con la bomba número 3 de los invasores. No pueden estar ambos en pantalla y existe una rutina que controla esto.
El hardware de la Commodore 64 tiene la capacidad de manejar estos objetos sin problema, ya que todos se pueden representar con sprites, incluso he agregado un sexto sprite para representar la explosión de la nave del jugador. Para controlar estos sprites es que utilicé primeramente una matriz de datos y una rutina de multiplexión y actualización de sprites en pantalla sin mayores secretos.
Como en la vida, no todo son cálculos matemáticos ni rutinas de control, y es así que llegamos a la parte que más disfruté programar: el sonido. Con una base de bajos profundos y unos siseantes disparos, el Space Invaders de Toshihiro Nishikado nos presenta todo el color del fantástico sonido analógico. En lo que a 8 bits respecta, el Space Invaders posee ports para diversas plataformas: Atari 2600, Atari 5200, Atari 400/800, líneas Atari XL y XE, MSX, Commodore (PET, VIC-20, C16/Plus 4 y C64), Sinclair ZX Spectrum y muchas otras, pero en ninguna de estas versiones se intenta emular la totalidad de los sonidos.
Abundan los sonidos simples que van desde tonos cortos hasta ruidos que parecen salidos del Game and Watch «Western Bar» de CASIO. Quizá alguno podrá intuir cierta entidad suprema que ocultó por décadas los verdaderos sonidos a los mortales usuarios de home computers, pero la solución, lamentablemente para mí, fue mucho más terrenal y lógica: los sonidos analógicos generados por el Space Invaders son demasiado complejos para poder emularse en las viejas computadoras de la época.
Un simple vistazo al MAME, y a su perfecta emulación del juego, nos muestra que se utilizó muestreo digital para alcanzar la fidelidad necesaria, algo que definitivamente fue desalentador. Ahora, si por algo se destacó la Commodore 64 durante toda su vida fue por su grandioso chip de sonido (el SID). Por ese hecho, me pareció que merecía la pena buscar la oportunidad de lograr lo imposible. Me puse manos a la obra.
Una simple búsqueda en Google bastó para encontrar los esquemas originales del hardware de Space Invaders y confirmar el nivel de dificultad. Es una serie de generadores analógicos con diversas formas de ondas, filtros y un SN76477 los que forman sus cuatro canales independientes y los encargados de generar sus tan característicos sonidos. El primer problema es que el chip SID posee tres canales, lo que me dejó en claro desde el principio que habría que mezclar voces y desistir del uso de modulación compleja. Pero vamos por pasos.
Mi enfoque en la reproducción de unos sonidos tan característicos fue más técnica que artística. Confíe más en el análisis de los sonidos utilizando software informático que en mí propio oído, creo yo, con muy buenos resultados. Primeramente digitalicé los sonidos generados por el emulador MAME para luego obtener información detallada con las herramientas que nos brinda el software Audacity. Frecuencias, formas de ondas, duración y secuencias de sonidos se obtienen observando las formas de ondas, y un análisis FFT nos da la idea de los filtros y las frecuencias que utilizan.
Para la composición de los sonidos elegí utilizar una muy popular herramienta de desarrollo musical para la Commodore 64 llamada GoatTraker. Este veterano software multiplataforma es una excelente herramienta de creación musical con mucha aplicación en el ámbito de los videojuegos ya que proporciona el código fuente necesario para incluir un reproductor con soporte para FX en nuestro juego, en assembler y para Commodore 64. Como sucedió con las otras herramientas utilizadas, la edición se realiza en PC y se genera código listo para incluir en nuestro proyecto.
Puedo decir que estoy conforme con el sonido final. Los cuatro tonos de base y la explosión de los invasores comparten el canal 1, por lo cual nunca pueden sonar ambos al mismo tiempo. Es el precio a pagar al tener un chip con menos canales que el original. Para lograr la profundidad necesaria de la base y las explosiones es que al filtro programable tan característico del chip SID lo he configurado como pasa bajo y ruteado también al canal 1. El canal 2 quedó reservado para el estridente sonido del UFO y el canal número 3 es el único recurso que quedó para cubrir el sonido del disparo del jugador.
Amigos, debo decir que programar un juego en assembler para una de las home computers más emblemáticas de los años 80’s fue un verdadero placer. Es indescriptible la sensación al ver moverse a los alienígenas por primera vez en pantalla y la certeza de saber que quizá no era tan difícil hacer un juego, que por ahí en estas tierras había gente tan capaz como en los países centrales y que la diferencia solo radica en la disponibilidad de la información técnica.
Nos vemos en el próximo videojuego.
DESCARGA SPACE INVADERS PARA COMMODORE 64:
https://mirazulado.itch.io/space-invader-c64
Autor y desarrollador en Argentina: Mariano Kalafatovich
Contacto: mkalafatovich@fi.mdp.edu.ar
¡Felicitaciones Chino! ¡La verdad un gran trabajo! Me encantaron los detalles técnicos de la nota. Si, la verdad, ponerse a hacer un juego para home computers hoy, sin hacer uso y abuso de un buen CrossCompiler y emulador es un despropósito. ¡Te mando un abrazo!