La Nintendo Entertainment System, y su homóloga japonesa la Famicom, no necesitan presentación: si está leyendo esta revista, sabrá que el hardware de 8 bits catapultó a Nintendo a una posición de liderazgo mundial en el negocio de los videojuegos y albergó las primeras iteraciones de innumerables series clásicas.
Aunque el marketing desempeñó un papel importante en este éxito comercial y cultural, no habría sido posible sin el hardware. Después de todo, la ColecoVision y la Atari 5200 tenían menos de un año cuando la Famicom se lanzó en Japón en 1983, y la 3DO y la Atari Jaguar ya estaban en el mercado cuando los desarrolladores abandonaron definitivamente la NES en 1994. Una máquina simplemente no puede seguir siendo relevante durante tanto tiempo sin un hardware que sea lo suficientemente flexible y capaz de seguir el ritmo de los cambiantes gustos de los jugadores.
Nuevo terreno
(Crédito de la imagen: Evan Amos)Suscríbase hoy
(Crédito de la imagen: Future)
Este artículo apareció por primera vez en la revista Retro Gamer. Si desea recibir en su domicilio o dispositivo más artículos en profundidad sobre juegos y consolas clásicas, suscríbase a Retro Gamer en formato impreso o digital.
Pero la NES no fue sólo un titán de su época: muchos desarrolladores están creando nuevos juegos para el hardware, exigiéndole más que nunca con las modernas herramientas de desarrollo. Dos CPU y sus derivados dominaron la escena del hardware doméstico de los ochenta: el Zilog Z80, presente en el ZX Spectrum, la ColecoVision y la Master System, y el MOS Technology 6502, que apareció en el Atari 5200, el Apple II y el Commodore 64. El ingeniero de Nintendo Masayuki Uemura optó por el 6502 para la NES, principalmente porque era lo suficientemente pequeño como para que un chip pudiera incluir también capacidades de sonido.
En 2016, el fallecido ingeniero declaró a Retro Gamer que esta elección causó «un gran problema dentro de la empresa», ya que el exitoso juego arcade de Nintendo, Donkey Kong, había utilizado un Z80 y el código fuente no podía reutilizarse. La consideración de cualquier programador ajeno a Nintendo no era una prioridad, ya que la compañía no pretendía inicialmente que los editores de terceros formaran parte de su modelo de negocio. Por supuesto, el éxito del hardware en Japón y Norteamérica acabó haciendo necesario el desarrollo por parte de terceros sólo para mantener el ritmo de la demanda de nuevos juegos.
La consola no tuvo el mismo impacto en el Reino Unido, por lo que el programador Paul Machacek no se topó con una hasta 1988, cuando se unió a Rare, una de las pocas desarrolladoras británicas que se concentraron en la consola de Nintendo. Sus juegos publicados anteriormente habían sido escritos para ordenadores basados en Z80, y en un principio se le encomendó la tarea de escribir para la placa arcade RAZZ basada en Z80, pero pronto le pidieron que trabajara en un proyecto para la NES. Afortunadamente, Paul estaba familiarizado con el código ensamblador 6502 de su época como propietario de un Oric-1. «Volví a cogerlo con bastante rapidez», dice, «pero me olvidé de todos los malabarismos numéricos que se hacían en él en comparación con el Z80, ya que el 6502 tiene tan pocos registros, pero alternativamente contaba con el rápido almacenamiento de página cero.»
Desarrolle lo que hicimos con las herramientas que teníamos en los sistemas que utilizábamos y dígame que no acabaría haciendo algo parecido.
Paul Machacek
El entorno de desarrollo con el que trabajaba Paul era bastante básico. «Al principio, en Rare todo el mundo utilizaba PDS (Programmers Development System), que era un editor de texto y un ensamblador de código. Teníamos tarjetas de interfaz de fabricación casera que se conectaban a la ranura del cartucho de la NES y se conectaban mediante un cable plano a nuestros PC que ejecutaban PDS», explica. «No teníamos red. Los PC eran Amstrads con discos duros de 20 MB (no es una errata). Cada vez que ensamblabas tu código -todo se hacía de una sola vez, aún no teníamos enlazadores-, el binario completo se copiaba a través del cable de cinta a la tarjeta de interfaz y ejecutabas tu código en la máquina de destino. En cuanto a la documentación, sólo teníamos el manual estándar de la NES, que tenía algunas erratas que había que corregir porque si no las cosas no funcionaban, y también tu práctica guía del juego de instrucciones 6502 como referencia ocasional, sobre todo si querías escribir código automodificable.»
Si usted es un programador que hace muecas ante eso, la cosa empeora. «No existían las herramientas de depuración tal y como las conocemos hoy en día», continúa Paul. «Había trucos para averiguar hasta dónde llegaba su código antes de que las cosas fueran mal, como escribir valores en una posición de memoria y ver cuál se escribió por última vez antes de que fallara, y luego utilizar una búsqueda bisectriz para acotar hasta el código infractor. Para las pruebas de rendimiento, normalmente se hacía algún cambio visual en la pantalla (desplazar un registro de desplazamiento horizontal de la pantalla, o alterar una paleta de colores) al principio de una función, y luego se reiniciaba al final para poder ‘medir’ cuánto tiempo tardaba en la pantalla dibujando marcas con rotuladores alrededor de este indicador visible, y viendo si las marcas se acercaban entre sí a medida que seguía optimizando su código. Sí amigos, ¡en aquellos tiempos se medía el rendimiento del código en pulgadas!».
Parece una forma bastante incómoda de trabajar, pero Paul lo ve simplemente como un producto de las circunstancias de la época. «Hicimos lo que teníamos que hacer en aquella época. Amigos, retrocedan 35 años, desarrollen lo que hicimos con las herramientas que teníamos en los sistemas que utilizábamos ¡y díganme que no acabarían haciendo algo parecido!» Afortunadamente, esta situación acabaría mejorando para Paul y sus colegas. «Al cabo de unos años, Rare contrató a Jon Ritman, un estrecho colaborador, para que escribiera un nuevo sistema llamado GLAM [Global Language Assembler Monitor] que sustituyera al PDS. GLAM podía dirigirse a una mayor variedad de procesadores y tenía un enlazador además de un ensamblador, de modo que no había que ensamblar todo el código base cada vez que se cambiaba algo, lo que aceleraba el desarrollo. GLAM funcionó realmente bien».
(Crédito de la imagen: Nintendo)
En última instancia, la programación en 6502 no supuso un gran problema para Paul en la transición a una nueva plataforma. «Para mí, el mayor ajuste fue pasar de ordenadores domésticos con pantallas mapeadas por bits, al sistema mapeado por caracteres de la NES, con designaciones separadas de paletas de colores, bancos de caracteres (e intercambio) e intercambio de bancos de memoria en los carros», recuerda. La unidad de procesamiento de imágenes de Nintendo – PPU para abreviar – era un diseño personalizado de Ricoh y, según Nicolas BÉtoux, de Morphcat Games, «en comparación con otro hardware de la época, los gráficos y la capacidad de desplazamiento eran magníficos.»
De hecho, cuando se lanzó la Famicom en 1983, su competidor más cercano en Japón era la SG-1000 de Sega. Las capacidades gráficas de la Famicom eran claramente superiores: disponía de una paleta de más de 50 colores frente a los sólo 16 del sistema de Sega, los sprites podían tener tres colores cada uno en lugar de sólo uno, y las pantallas podían desplazarse por píxel en lugar de por personaje, lo que daba como resultado un aspecto considerablemente más suave. El hardware de Nintendo también podía mostrar más sprites en general, y más sprites por línea de exploración. Sega introdujo el hardware Mark III, gráficamente superior, en 1985, lo que significó que la competencia estaba más igualada para cuando la NES y la Master System llegaron al público internacional.
Herramientas del oficio
Aunque el hardware de 8 bits de Nintendo contaba con capacidades gráficas avanzadas, los métodos utilizados para crear esos gráficos eran de todo menos avanzados. Al igual que Paul, el artista Kevin Bayliss nunca se había enfrentado a una NES antes de crear juegos para el sistema. «En mi primer día en Rare, Tim [Stamper] me enseñó el ‘proceso de pixelado’ básico y me enseñó a crear un trabajo que pudiera ponerse en un juego», nos cuenta.
«Básicamente, tenía que dibujar mi obra y colocarla debajo de una hoja cuadriculada en un gran tablero de dibujo lleno de tiras fluorescentes. Luego trazaba sobre mi dibujo utilizando la cuadrícula para definir píxeles con un lápiz, y después utilizaba rotuladores para rellenar los píxeles. Luego había que organizar el trabajo y dividirlo en cajas (sprites de 8×8) y elaborar los datos de los sprites y los datos de posición en hexadecimal, en mi cabeza. Esto era bastante fácil pero un poco laborioso a veces, y a menudo no querías hacer este trabajo porque no era nada creativo. Sólo querías ver tu trabajo en el juego.»
Si le desconcierta la ausencia de un ordenador en ese proceso, no está malinterpretando nada. «No había más herramientas que el bolígrafo, el lápiz, el papel y un bisturí quirúrgico para garabatear tus errores en el papel de calco cuando ponías un píxel en el lugar equivocado o querías recortar píxeles de un personaje para que cupiera en menos datos», aclara Kevin. «Había un sencillo editor de sprites que escribió Mark Betteridge, pero en realidad no se utilizaba porque era muy limitado y no te permitía ver tu animación (como hacen en todas las viejas filmaciones de Disney ‘entre bastidores’, volteando el papel hacia delante y hacia atrás para crear la ilusión de animación).»
No había más herramientas que el bolígrafo, el lápiz, el papel y el bisturí quirúrgico para garabatear tus errores.
Kevin Bayliss
Dado que las herramientas de desarrollo de la NES no estaban estandarizadas, las distintas compañías utilizaban diversas herramientas artísticas. Nintendo llegó a utilizar sprites dibujados a mano en un momento dado, pero acabó creando una herramienta de arte de píxeles manejada con el ratón, mientras que Namco tenía una herramienta de edición de sprites que sí disponía de la función de previsualización de animaciones que describe Kevin. Sin embargo, disfrutó con el enfoque de baja tecnología empleado en Rare.
«En realidad, era bastante agradable disponer de una paleta limitada. Es decir, no había forma de dibujar todos los gráficos en papel para ninguna consola de 16 bits porque nunca tendrías suficientes bolígrafos, y habría llevado todo el día descodificarlos -y habrías cometido tantos errores- que habría sido imposible», afirma. «Pero debido a la simplicidad de la paleta de colores y a la baja resolución y el pequeño número de sprites con los que tratábamos en la mayoría de los casos, hacer gráficos en papel era en realidad bastante divertido y se sentía mucho más ‘orgánico’ que crearlos digitalmente en la SNES, así que supongo que hay algo que decir al respecto».
Independientemente de cómo un desarrollador creara el arte para la NES, las limitaciones técnicas jugaban su papel en los resultados finales. «Los sprites por línea (más de 64 píxeles rellenos en una línea de exploración horizontal) eran un problema, así que se intentaba que los personajes no fueran muy anchos», explica Kevin. «Por ejemplo, en concreto recuerdo que todos los personajes de los juegos de la WWF que hice tenían que ‘caer hacia atrás’ o ‘tumbarse en el suelo’ y, por supuesto, eso significaba que serían bastante anchos en esa pose. Así que a menudo intentabas ponerlos en ángulo o ser ingenioso con la pose, pero en realidad nunca lo evitabas. Se puede ver cómo los personajes parpadean a menudo, sobre todo en los juegos beat-‘em-up de ese tipo, y era un problema que todas las empresas tenían que solucionar lo mejor que podían.»
Ese parpadeo característico es en realidad una ingeniosa solución de programación: la NES simplemente omitía píxeles si se mostraban demasiados sprites, por lo que activar y desactivar rápidamente los sprites al menos garantizaba que se mostraran todos de alguna forma.
(Crédito de la imagen: Nintendo)
De hecho, los desarrolladores de NES a menudo tenían que ser creativos para hacer realidad sus visiones, como los enormes personajes jefe que Kevin dibujó para Cobra Triangle. «Con Cobra Triangle tuvimos suerte porque el juego se desarrollaba en un entorno isométrico, así que todos los gráficos se veían desde un ángulo que reducía la cantidad de anchura que normalmente se vería en un juego de desplazamiento horizontal», afirma.
«Los personajes jefe eran todos una colección de sprites grandes y podíamos utilizar la superficie del agua para hacer que las cosas parecieran sumergidas añadiendo unos cuantos sprites ‘ondulantes’ a su alrededor en la base. Así, por ejemplo, el personaje del monstruo marino (Nessie) que creé era bastante alto y las jorobas que tenía detrás se movían de forma independiente y, debido al ángulo, no había mucho parpadeo de sprites.»
Las limitaciones se hicieron más difíciles de afrontar cuando se desarrollaban juegos con licencia, como hacía a menudo Rare. «Para los juegos de lucha libre de la WWF teníamos que asegurarnos de que había un buen parecido con los personajes, por lo que era difícil ‘digitalizar’ las fotografías a mano y reproducir las características de cada uno con precisión cuando sólo disponías de unos 16×16 píxeles para el retrato de un personaje en la página de selección», dice Kevin. «Recuerdo que recibía unos faxes de pésima calidad con fotos de los luchadores y yo tenía que intentar recrearlas con tan baja resolución y tres colores».
Sin embargo, esto dio lugar a algunas experiencias divertidas. «Muchas veces recibía faxes de vuelta de Estados Unidos diciendo que ‘los gráficos necesitaban algo de atención’, porque el parecido no era lo bastante parecido», continúa Kevin. «Entonces cambiaba, como, un píxel y al día siguiente recibía un fax de vuelta diciendo que la imagen era mucho mejor. Realmente me hacía reír cuando eso ocurría. También, cuando trabajé en el juego de Beetlejuice, tuve el problema opuesto, y mi ilustración de la página del título se parecía demasiado a Michael Keaton aparentemente, así que tuve que hacerlo de nuevo para que se pareciera más a Beetlejuice – algo difícil cuando son la misma persona.»
Sombras intermedias
A veces, era posible llevar el sistema más allá de sus límites teóricos. «Si echa un vistazo a Super Off Road, se dará cuenta de que a veces hay más colores en pantalla de los que el hardware puede manejar de serie», dice Paul. «Había cuatro paletas de cuatro colores cada una, pero el primer color de cada paleta era el mismo color de fondo para todas. Así que el número total de colores que se podían mostrar para los caracteres de fondo era de 13. Se muestran más en Super Off Road porque cambié las paletas con un acceso cuidadosamente temporizado a la VRAM durante el blanking horizontal. Esto funcionó bien», explica Paul, antes de corregirse. «Bueno, lo hizo en la versión estadounidense de la NES.
Cuando el juego estuvo terminado, me informaron de que se lanzaría en Japón en la Famicom, que era ligeramente diferente en términos de hardware y, por desgracia, mi cambio de color no funcionaría en ella, así que creo que no se lanzó allí.» El audio corría a cargo del mismo chip Ricoh 2A03 que contenía la CPU: «En la NES, tienes cuatro canales de audio con los que trabajar. No contamos el canal DPCM (de muestreo), no lo utilizamos porque tiene algunos inconvenientes», dice Nicolas, desarrollador de juegos modernos para NES.
«En cualquier caso, son dos generadores de ondas cuadradas, uno de ondas triangulares que se suele utilizar para las líneas de bajo y un canal de ruido que se usa para los sonidos percusivos. Como ve, las opciones de polifonía y timbre son limitadas, lo que dificulta la creación de una banda sonora más atmosférica como la que se puede escuchar en los juegos modernos. Probablemente, esa es una de las razones por las que muchas bandas sonoras de juegos de antaño lo compensaban con composiciones dinámicas y melodías pegadizas.»
(Crédito de la imagen: Nintendo)
El audio de la NES tiene algunas características especialmente distintivas, entre las que destacan las ondas triangulares escalonadas en lugar de suaves, debido al procesamiento de sonido de 4 bits del sistema. «Debido a la cantidad limitada de canales, también hay que tener en cuenta que los efectos de sonido pueden interrumpir la música», añade Nicolas. «Lo ideal es que haga que los efectos de sonido se reproduzcan sólo en los canales que utiliza para el acompañamiento, para que no silencien la melodía».
El sonido es también uno de los puntos diferenciadores entre la Famicom y la NES, ya que la Famicom admite audio ampliado a través del puerto de cartuchos, algo que aprovechan el Famicom Disk System y ciertos chips especiales para cartuchos. Como la NES no tiene esta capacidad, las versiones japonesas de juegos como The Legend Of Zelda y Castlevania III: Dracula’s Curse tienen una música notablemente mejor que sus homólogas internacionales. De hecho, fueron los chips especiales uno de los factores clave de la longevidad de la NES. Además de admitir tanto ROM como RAM en las placas de los cartuchos, la NES podía utilizar chips que Nintendo denominó Controladores de Gestión de Memoria.
Además de permitir un cambio de bancos que superaba las limitaciones de almacenamiento de la especificación original de los cartuchos, estos chips podían proporcionar funciones adicionales para ayudar en el desarrollo de los juegos y, en el caso de la Famicom, incluso audio de expansión. Así es como, en última instancia, el sistema pudo pasar de albergar juegos como Donkey Kong a títulos mucho más complejos como Kirby’s Adventure en el transcurso de una década. Por supuesto, incluso con una capacidad de ROM que superaba con creces el total original de 40 KB, los desarrolladores a menudo luchaban por cada byte. «Un problema común en aquella época era intentar meter los juegos en los diminutos cartuchos que nos daban», dice Paul. «Esto se complicaba en NES/Game Boy (ambos sistemas de 8 bits con mapas de memoria de 64KB) al tener que disponer de conmutación de bancos, donde la región podía estar dividida en cuatro bloques de 16KB, y usted podía conmutar diferentes bancos de ROM dentro y fuera de ellos.
Así que había que organizar cuidadosamente qué código y datos estaban dónde y cómo se saltaba de un banco de ROM a otro en el mismo espacio de direcciones, utilizando tablas de salto superpuestas estándar al principio del espacio. También tuvimos que desarrollar rutinas de compresión de datos, a menudo diferentes para distintos tipos de datos: datos de caracteres, datos de mapas, datos de texto, datos musicales. La compresión Huffman se utilizó bastante, pero pasé tiempo mirando impresiones de otros tipos de datos, buscando patrones que pudiera utilizar para desarrollar software de compresión.»
8-bitten
James también se deshace en elogios hacia el software: «La comunidad es estupenda y los recursos para utilizar las aplicaciones de seguimiento son accesibles para cualquiera, ya sea un compositor experimentado o un simple aficionado a las chiptunes». Con estas modernas herramientas a su disposición, los desarrolladores de NES tienden hoy a intentar proyectos muy ambiciosos. Los juegos de acción para cuatro jugadores son una rareza en la NES, pero Morphcat Games creó uno excelente en Micro Mages. Esto requirió un uso muy económico del hardware.
«La NES permite un máximo de 64 sprites de hardware en pantalla en cualquier momento», comienza Nicolas. «Estos sprites tienen un tamaño de 8×8 píxeles (hay un modo de 8×16, pero tiene sus inconvenientes) y se pueden unir para formar sprites más grandes. «Así, para conseguir un sprite de 16×16 en el primer modo, tendrá que utilizar cuatro sprites de hardware. Si hace que los cuatro jugadores utilicen sprites de 16×16, ¡eso supone una cuarta parte de todos los sprites de hardware disponibles utilizados en los jugadores! Además, existe una limitación de hardware por la que si hay más de ocho sprites en la misma línea horizontal, empiezan a desaparecer», continúa. «Para remediarlo y seguir permitiendo muchos otros objetos y efectos gráficos en la pantalla, los personajes jugadores de Micro Mages utilizan un único sprite de 8×8 cada uno.»
La CPU de 8 bits también resulta ser un factor limitante, según Nicolas. «Si un juego tiene un enemigo que sólo se mueve hacia los lados y se da la vuelta cuando encuentra una pared, es un número limitado de comprobaciones que hay que realizar. Los jugadores humanos, por otro lado, son comodines, interactuarán con todo lo que les rodea de formas que un desarrollador no puede predecir totalmente».
(Crédito de la imagen: Nintendo)
Me encantaba codificar la NES, era una arquitectura completamente diferente a la de los ordenadores domésticos en los que había trabajado antes.
Paul Machacek
Además, si los jugadores tienen la posibilidad de disparar, el número de objetos en la pantalla se acumula rápidamente», nos dice, «esto no es un gran problema en un juego para un solo jugador y normalmente te sales con la tuya en una partida para dos jugadores. Sin embargo, ¿una partida para cuatro jugadores? Ouch. En Micro Mages, hemos dedicado mucho tiempo a la optimización para evitar el lag. Sin embargo, en el modo para cuatro jugadores, hay ocasiones en las que el juego sigue ralentizándose cuando hay demasiadas cosas en juego.»
Una ventaja que sí tienen los desarrolladores modernos es la posibilidad de elegir entre una amplia gama de soluciones de gestión de memoria, más conocidas hoy en día como «mappers». «Son simplemente muy interesantes de desempaquetar, y desarrollar para ellos», dice James. A pesar de disponer de los más potentes, no siempre son la elección por defecto. «Cuando se planifica el desarrollo de un juego en Mega Cat, empezamos a trabajar hacia atrás a partir de lo que se necesita para que el núcleo del juego sea divertido», explica James. «En algunos casos, acabamos optando por defecto por algo potente como el mapeador MMC3. En otros, podemos mantener la sencillez y utilizar un mapeador discreto, como un NROM». De hecho, el reciente juego para NES Blazing Rangers del desarrollador japonés Karu_gamo utilizó específicamente el mapper más sencillo, el NROM, para evocar la nostalgia de los primeros días de la Famicom. Ése es realmente el núcleo de la continua fascinación de los desarrolladores por la NES: no sólo es un sistema técnicamente interesante, sino que ofrece un fuerte tirón nostálgico.
Incluso aquellos que la conocieron por primera vez en un contexto laboral, como Kevin, sienten esa nostalgia. «Disfrutaba trabajando en la NES como artista, porque al final conocías bien el sistema. Tanto si creabas fondos, sprites animados, portadas o gráficos frontales (marcadores), tenías un sistema que habías utilizado en un juego anterior y de vez en cuando se te ocurría algo nuevo para llevarlo un poco más lejos y exprimirlo un poco más visualmente. Eran tiempos sencillos, ¡pero divertidos!».
Aunque Paul lamenta los malabarismos numéricos inherentes a la programación para el 6502, también recuerda el sistema con cariño. «Me encantaba codificar para la NES, era una arquitectura completamente distinta a la de los ordenadores domésticos en los que había trabajado antes, había trucos interesantes que se podían hacer con la pantalla mapeada de caracteres y que se podían explotar para dar profundidad -véase nuestros juegos de Battletoads en NES/Game Boy- y lo consideraba todo como un reto técnico interesante para «resolver» nuevos problemas en torno a esta arquitectura de hardware alternativa.»
El futuro del pasado
Pero a pesar de lo divertido que fue programar el sistema, Paul señala con razón los resultados de ese trabajo como la razón del éxito de la NES. «No hay que olvidar que Nintendo contaba con un increíble catálogo de juegos en las consolas, sobre todo Super Mario y Zelda. Super Mario Bros 3 supuso un enorme paso adelante y una cima absoluta en aquella época», afirma.
Si usted es un aspirante a creador de juegos retro, la NES podría ser la plataforma ideal para usted. «El código, los gráficos y el sonido de la NES son fáciles de manejar por una persona cada uno en el equipo», afirma Nicolas. «Comparado con ahora, el lenguaje de programación parece más oscuro y complejo que los lenguajes modernos. Todas las limitaciones te obligan a dedicar más tiempo a cada cosa», admite. «Pero también te obliga a pensar dos veces cada idea. Al final, puedes centrarte en las más importantes para la jugabilidad».
Estas limitaciones pueden mantener bajo control el alcance de su juego: sólo hay un límite.»Si se siente atraído por la idea de abordar ese desafío técnico, muéstrenos los resultados algún día: siempre estaremos interesados en verlos.
Este reportaje apareció originalmente en la revista Retro Gamer. Para obtener más fantásticos reportajes y entrevistas, puede suscribirse a Retro Gamer en versión impresa o digital aquí.