No toméis muy en serio esta entrada, en realidad me aburro mucho.

Esto es algo que se me cruzo por la cabeza haciendo el Gameplay que he hecho del Metroid de NES en el canal de Disruptive Ludens, el cual esta aún en pruebas. Mientras jugaba al juego me pregunte… ¿Hubiese sido posible algo como Super Metroid en la NES lanzado unos años despues por Nintendo y que fuese un salto como el que hubo de Super Mario Bros a Super Mario Bros 3?

Hay que tener en cuenta que Metroid fue un juego lanzado para el Famicom Disk originalmente, este fue planteado por las limitaciones de memoria de los cartuchos iniciales de Famicom/NES.

La CPU de Famicom/NES es un clon del 6502 fabricado por Ricoh y por tanto tiene un direccionamiento de 16 bits (2^16=64KB) pero al utilizar cartuchos deja la mitad del direccionamiento de memoria disponible para los cartuchos y el otro para la memoria, el direccionamiento no significa memoria física sino que son las direcciones de memoria asignadas. En Famicom/NES tenemos solo 2KB de memoria RAM, esto significa que hay unos 30KB en direcciones de memoria que no son accesibles por la CPU porque no hay nada, no están asignados a ninguna memoria física por lo que las ROMS no pueden pasar de los 32KB.

Nintendo para romper en parte esta limitación separo lo datos de programa (PGR-ROM) de los datos gráficos del juego (CHR-ROM) pero con la PPU ocurre lo mismo que con la CPU.

La CHR-ROM estaba conectada a la PPU, el cual como os explique es una evolución del TMS9918A, esta al contrario que el VDP de Texas Instruments en su versión original almacena la SAT/OAM en una memoria interna y tiene 2KB de memoria para las tablas que componen la escena, permitiendole a la consola (sin el apoyo de ningún chip de apoyo preparado para ello) poder cargar los datos de dos pantallas completas en scroll horizontal o vertical.

El otro pozo de memoria es la CHR-ROM, como el primer bit separa la memoria interna (2KB) de la memoria en la CHR-ROM y la PPU solo puede direccionar 16KB en total esto hace que las CHR-ROM sean de 8KB. Esto significa que lo cartuchos de NES como mucho son de 40KB contando los datos gráficos a no ser que utilicen memoria multibanco, en el caso del Famicom Disk un disco de una sola capa era de 64KB y uno de 2 capas era de 128KB

Al contrario de lo que la gente se cree, el Famicom Disk no se conecta al puerto de expansión sino a un cartucho, dicho cartucho tiene una memoria PGR-RAM y una memoria CHR-RAM que al no ser ROM le permiten volcar los datos desde el disco magnético a dicho cartucho que es el que se comunica con la consola. Esto le permite ir volcando los datos tanto gráficos como de programa del juego cuando es necesario sin superar lo limites de memoria. En occidente, en cambio, Nintendo opto por otro camino como ya sabéis que fue el hecho de utilizar memoria multibanco. Para ello termino optando por los famosos chips MMC que permitían configuraciones multibanco con tal de poder superar el limite físico de 64KB, algo que era muy habitual en los sistemas de 8 bits.

Simplemente el programa cambiaba de banco de memoria llegado a un punto y por tanto todos los juegos que se portaron del Famicom Disk a cartucho tuvieron que ser re-programados por completo.

Mapa y Organización de los datos en Metroid

En realidad el mapa del Metroid esta organizado 32×32 celdas donde cada celda pertenecería a una pantalla individual del juego.

Por lo que en realidad tenemos unas 1024 celdas en total, si todas ellas estuviesen ocupadas dado que los datos de la Name Table es de 1KB por pantalla entonces estaríamos hablando de 1MB de datos en total solo para el mapa, una cifra que es inalcanzable dentro de las capacidades de la Famicom/NES, claro esta que no todas las posiciones del mapa en cada uno de los cuatro cuadrantes esta ocupada.

El mapa utiliza unos cuatro cuadrantes para la posición A la hora de colocar la posición del jugador en un cuadrante utiliza una variable de 8 bits por cada cuadrante, donde los 4 primeros bits es la posición en horizontal de la celda correspondiente y los otros 4 bits es la posición de la celda en vertical. Luego hay otra variable que le marca al mapa en que cuadrante esta que ocupa unos 2 bits solamente, por lo que con unos 10 bits el juego sabe donde esta el jugador.

Cada celda tiene una tabla asignada que le permite dibujar el escenario, en alguno escenarios dado el camino es directo y esta claro, como por ejemplo las salas de los objetos o el mapa de Tourian que es lineal entonces las tablas que se cargan son consecutivas y en el scroll en el que esta diseñado la pantalla. En el caso de que el jugador pueda escoger un camino o haya más de uno lo que hay es una puerta y el scroll no va más allá de la puerta porque hasta que el jugador no la abre con un disparo o realiza una acción que permite llegar a la sala siguiente no se carga la tabla de la siguiente pantalla, es por eso que el mapa esta lleno de zonas de transición, sobretodo cuando abrimos escenario con las bombas, por el hecho que el juego necesita ocultar que esta cargando la siguiente pantalla.

Cada posición del mapa tiene asignada una tabla desde la cual se dibuja el escenario y la posición del enemigo, pese a que tenemos unas 1023 celdas posibles en realidad el mapa solo tiene unas 128 salas distintas, unas 32 aproximadamente por cuadrante. El juego utiliza una pila de 256 elementos donde en cada elemento hay el puntero a una de las pantallas del juego. Antes de entrar en una nueva pantalla, el sistema lo que hace el sistema es preguntar donde nos encontramos y que pantalla quiere mostrar, esto dirige al sistema a una pila de 256 posiciones y es que el 6502 trabaja con grupos de memoria de 256 bytes (2^8). Básicamente porque el contador de programa del 6502 aunque es de 16 bits en realidad esta dividido en dos registros de 8 bits que son el PCL (Program Counter Low) y el PCH (Program Counter High), esto le permite al 6502 acceder a bloques de memoria de 256 bytes, pensad en el direccionamiento como que el 6502 puede manera 256 pilas de 256 bytes cada una.

La pila es una pila de naturaleza FIFO,

Dado que los datos de la pila no pueden pasar de los 256 bytes entonces cuando se añade un dato nuevo se ha de quitar los de encima y colocarlos de nuevo y para ello esta el Puntero a pila que lo que hace es tratar la pila como si fuese un array list y convierte la dirección de memoria en el nuevo punto superior de la pila, pero no podemos pasar jamás del limite de componentes iniciales, esto significa que si nosotros con el puntero a pila nos movemos al elemento 16 de la pila no vamos a tener unos 255 elementos por debajo sino solamente 16 (contando el 0).

Por lo que el puntero a pila nos permite acceder a cualquiera de los 256 elementos de la pila de manera directa sin tener que modificar el resto. Pero hay dos formas de colocar el valor en el Putero a Pila en los juegos:

  • Dando la dirección directa.
  • Sumando o Restando un valor al valor actual.

Cuando disparamos a una puerta, automáticamente lo que hace el juego entre bambalinas es cargar como pantalla adjunta a la que le corresponda según su posición por lo que el valor del puntero a pila que genera el salto a la pantalla correspondiente es cambiado por el programa. Si no marcamos una dirección en el puntero a pila entonces lo que hará será decrementara una dirección y nos encontraremos con que Samus acabará en una pantalla en la que no debería estar y es que las pantallas de Metroid no están ordenadas en memoria según la posición del mapa como ocurre con los juegos lineales.

En los juegos lineales lo que se hace es incrementar o decrementar una variable de manera directa cuyos datos contienen la dirección de memoria de donde se encuentra el siguiente nivel, cuando se tiene que cargar una nueva pantalla esta variable apunta a la dirección de memoria donde se encuentran los datos de dicha pantalla, por lo que se hace es manipular el PCH y/o el PCL pero con Metroid es distinto, con Metroid lo que se hace es apuntar a una pila que contiene las direcciones de memoria de las diferentes habitaciones y desde el momento en que el direccionamiento en NES/Famicom, dado que su CPU es un 6502, es de 16 bits esto son 2 bytes por dirección de memoria y la pila de 256 bytes por tanto solo puede unos 128 elementos distintos.

¿Y cuantas pantallas únicas y no repetidas tiene el mapa de Metroid? Pues contando la pantalla del título y las de los finales en total unas 128 pantalla únicas en total, una media de 32 pantallas por cuadrante.

Pe… pero Urian… La gente dice que la repetición de pantallas es para ahorrar memoria.

En parte es cierto, cada pantalla en un juego de NES tiene una tabla asignada de 32×28 patrones/sprites. Si la consola generase los gráficos a través de un búfer de imagen necesitaria por escenario unos 112KB de información, pero lo que hace es utilizar una tabla de 32×28 patrones/sprites con un puntero de 8 bits que apunta a donde está la información del patrón/sprite en dicha celda de la tabla por lo que utilizando dicha técnica la memoria necesaria para dibujar una pantalla pasa de ser de 112KB ( 114688 bytes) a solo 896 bytes.

Por lo que las 128 pantallas acabarían ocupando entre todas ellas unos 112KB en total, no nos cabrian el cartucho pero es que la tabla solo tenemos que especificar aquellas celdas que tiene un patrón/sprite ya que en el caso de que haya una celda que no tenga uno asignado la PPU simplemente pintará el color de fondo. En la pantalla de arriba por ejemplo hay una gran cantidad de la pantalla que no tiene un patrón/sprite y solo unas 278 celdas de las 896 posibles tienen datos de patrón/sprite… Esto hace que sea posible colocar las 128 pantallas distintas del juego en su limitada memoria de 64KB en total teniendo en cuenta todos los datos del juego.

¿Pero forzo Nintendo el uso de 64KB de memoria para la versión de Famicom Disk? Teniendo en cuenta que Zelda apareció unos seis meses antes con un disco de 128KB y dudo mucho que Nintendo tuviese problemas con un disco de 128KB para Metroid por lo que algo ocurrió durante el desarrollo del juego.

Metroid realmente se hizo en tres meses

El objetivo de Pitfall es encontrar una serie de objetos diseminados por el mapa antes de un tiempo determinado. El siguiente mapa es de la versión arcade de Pitfall 2 que fue lanzado en recreativas en 1984.

Veamos la entrevista que hace poco concedieron Sakamoto y Kiyotake acerca del desarrollo de Metroid.

¿Cuanto tiempo le ocupo a los dos nuevos empleados terminar el juego?

Kiyotake: No mucho, sobre unos diez meses.

¿Mientras trabajabáis, podías ver el final? ¿Tenías una visión de su forma final?

Kiyotake: Más que preocuparnos acerca de terminarlo, nunca habíamos hecho un videojuego con anterioridad, así que no tenemos una idea del producto final.

¿No tenías ninguna experiencia respecto a como pulir un juego como este?

Kiyotake: Ninguna. Por aquel tiempo, estábamos pensando como podíamos hacer un juego que se disfrutase.

Sakamoto: No me uní al desarrollo de Metroid hasta los tres últimos meses (risas).

Así que durante unos diez meses, dos nuevo empleados trabajaron en el desarrollo y tu te uniste al equipo para pulirlo en los últimos tres meses.

Sakamoto: No fui el único en unirse. Casi todo el mundo en Research & Development Department 1 se unió al final.

Antes, el Sr. Kiyotake menciono que el asesoramiento llego al final, y esto es lo que realmente ocurrio, a través de una mobilización en masa del departamento.

Sakamoto: Así es. Todo el mundo en el Research & Development Department 1 contribuyo en Metroid de alguna manera.

¿Como de avanzado estaba el juego cuanto tu y el resto os unistéis?

Sakamoto: ¡Para ser honestos, dificilmente estaba hecho! (risas).

Oh… (risas)

No tenemos información acerca de la versión de Metroid antes que R&D tomase las riendas para terminar el juego, el mito dice que fue Sakamoto quien convirtió el juego de ser algo lineal a no-lineal pero viendo el material que tenemos del juego sinceramente dudo mucho que esa sea la historia porque no tenemos nada que nos de pistas para reconstruir por completo ese Metroid en versión alfa.

Las declaraciones de Sakamoto es que no había juego para nada, que lo que había era una colección de pantallas sueltas porque Kiyotake no tenía muy claro como queria que fuese el juego y se había perdido en los detalles pequeñós. ¿Pero es cierto que Metroid invento un género nuevo? No, realmente no y ahí entramos en un tema realmente polémico en cuanto al desarrollo y que pone en contexto una cita de Kiyotake de la misma entrevista.

Sakamoto: ¿No estás olvidandote de algo importane? Aren’t you forgetting something important?

Kiyotake: ¿Lo estoy??

Sakamoto: Super Mario Bros es sobre evitar a los enemigos is about avoiding enemies.

Si tocas uno, pierdes un turno.

Sakamoto: En respuesta a ello, Kiyotake se estaba quejando y diciendo «¿Por qué los tengo que evitar?» (risas)

Aunque Nintendo no lo diga, lo de evitar enemigos demuestra que en un determinado momento alguien planteo Metroid como un juego de evitar obstáculos/enemigos… Como no creo, personalmente hablando, de que el juego se diseñara para ser lineal y Kiyotake no es Miyamoto entonces tiene que basarse su juego en algo ya existente… ¿En que? En Pitfall para la Atari VCS.

Pitfall fue uno de los primeros juegos no lineales que salieron, las malas lenguas dicen que Nintendo quiso copiar los juegos más famosos de la Atari VCS y desarrollar versiones muy mejoradas de los mismos con franquicias propias. Así pues «Mario Adventure» que se termino convirtiendo en Zelda es la versión actualizada y corregida por Nintendo de una evolución que empezo Adventure de Atari VCS y continuo con Tower of Druaga y Hydlide… Bueno no, la creación de Miyamoto esta a años luz de estos.

Lo mejor es que veais un gameplay del Pitfall para VCS.

El objetivo de Pitfall es conseguir todos los objetos desperdigados por el mapa en un tiempo determinado, es un juego cuyo planteamiento nos puede parecer muy simple a día de hoy pero que fue un hito en la VCS, esta compuesto por unas 256 pantallas en total interconectadas entre si.

El siguiente mapa es de la versión arcade de Pitfall II, lanzada en recreativas en 1984.

Nintendo estuvo estudiando las consolas de Atari, Coleco y Mattel antes de lanzar la Famicom/NES por lo que no sería de extrañar que en sus departamentos tuviese gente de… «Toma y copiame esto pero sin copiarlo», no me extrañaría que Nintendo le pidiese a Kiyotake un «Nintendo Pitfall» pero en el marketing no tienen permitido hablar de los origenes, Pitfall fue el primer juego del género entre comillas y precisamente va de evitar los obstáculos.

La conclusión es que cuando llego el resto del equipo a ayudarle, Kiyotake solo tenías unas 128 pantalas hechas o incluso menos… ¿Como se desarrollaban los juegos de NES? Bueno, la parte gráfica se hacía primero diseñando los niveles sobre una cuadricula.

La cuadricula hacía referencia a los patrones/sprites del juego y su colocación en los niveles pero antes es necesario crear dichos patrones/sprites, los cuales se encontraban en los bancos de la CHR-ROM pero no podían superar un limite en cuanto a tamaño. Precisamente hay un elemento muy curioso que me hace pensar que inicialmente Metroid no se penso para el Famicom Disk.

Volvamos a la entrevista…

Sakamoto: Todo tenía los mismos fondos y podías hacer las mismas cosas. Los personajes se movían, pero el resto del diseño del juego estaba en lo huesos.

¿En ese punto, tenía la estética de Metroid?

Sakamoto: Si, era oscuro, con un personaje-jugador bien construido quien se lanzaba contra los enemigos. Todo eso estaba ahí.

¿En que trabajasteis tu y los otros?

Sakamoto: En lo primero que trabaje fue en el movimiento de Samus, el personaje principal.

Kiyotake: Me especialice en diseño de personajes, pero tenía a a Samus moviendose en una variedad de movimientos afinados. Pero estos terminaron con comerse la memoria.

Y si tu añadías fondos y sonido…

Kiyotake: Nunca cabrían, así que los movimientos se vieron drasticamente reducidos.

Pensaste, «¡No es posible! Me he pasado unos diez meses haciendo estos!

Kiyotake: Estaba prácticamente a punto de llorar, pero todo el mundo me ayudo. No me importaba que fuesen reducidos mientras fuéramos capaces de completar Metroid.

Sakamoto: Entonces añadimos todo tipo de cosas, como cambiar el color de los fondos para que los jugadores pudiesen darse cuenta que habían progresado

Sakamoto: Si, lo hicimos.

Sakamoto: Pero no peudo criticar al Sr. Kiyotake y el otro diseñador. Habían saltado desde el Game & Watch al mundo de del desarrollo de software para el sistema Famicom Disk.

Hay que tener en cuenta que la Famicom/NEs suele utilizar unos 2 bancos de patrones/sprites de 256 elementos donde cada elemento es un patrón/sprite de 8×8 con 4 colores y por tanto ocupando unos 16 bytes, esto hace que cada banco en la CHR-ROM ocupe unos 4KB del total de 8KB y como tenemos dos bancos pues.

Pero con el Famicom Disk esto no tendría que ser problema, bien es cierto que las animaciones del personaje al cambio de escenario y de CHR-ROM o cargando desde disco a la CHR-RAM en el caso del Famicom Disk, la explicación de que se quedaban cortos en cuanto a memoria solo tiene un sentido y es que el juego se pensará para cartucho inicialmente y no para el Famicom Disk, tened en cuenta que Nintendo habia conseguido colocar todo Super Mario Bros que tiene más pantallas que Metroid (por extraño que parezca) en un cartucho de 32KB, pero Kiyotake se encontro con el problema de que los patrones/sprites no le cabían en la CHR-ROM.

Kiyotake le debió pedir a su jefe directo, Gunpei Yokoi, una prorroga en el desarrollo o al menos que le dejase lanzar el título en el Famicom Disk por la falta de memoria del cartucho. Hiroshi Yamauchi quien era el presidente de Nintendo por aquel entonces les dio un ultimatum de tres meses para terminar el juego.

Como el juego era un laberinto necesitaban un evento que disparase el final del laberinto y como no tenian mucho tiempo para crear un enemigo complejo y sus animaciones pues decidieron hacer esto…

Y con ello pudieron colocar el evento que dispara la cuenta atrás que es el final del juego se podía implementar. Con ello el juego ya tenía un objetivo claro y se podía hacer una sinopsis del mismo de cara al marketing y de la misma manera se pudo empezar a realizar el manual del juego para su pronta comercialización.

Si contamos las zonas en las que están Kraid y Ridley entonces al final fueron 5 las zonas del juego. Precisamente la única parte realmente lineal del juego es Tourian que es el escenario que se construyo durante el periodo final del juego.

¿Como decidistéis que Samus Aran fuese una mujer?

Sakamoto: Una vez entramos en la fase final del desarrollo, empezamos a hablar de tener diferentes finales dependiendo de lo que tardasen los jugadores en completarlo, queríamos darle al jugador un premio por haber completado el juego más rapidamente.

Laberinto… Tiempo… ¿De que me suena? Que no me nieguen que un Nintendo Pitfall fue un punto de partida porque esto es revelador.

Kiyotake: Nos preguntamos si a tood el mundo le sorprendería que Samus se quitase el casco.

Sakamoto: Entonces alguien dijo, «Sería un shock que Samus resultase una mujer» y todo el mundo penso que sería interesante y quería hacerlo, por lo que lo decidimos inmediatamente.

Se hizo tan al final que todo el marketing del juego se acabo basando en Samus como hombre…

Fijaos en el término Cyborg y recordad que Metroid es la fusión de Metro… Android. Si alguna vez os habéis preguntado de donde viene la disonancia entre Samus como humana y el hecho de hacerse bola aquí tenéis la respuesta, es más, a esto hacen referencia en el manual del juego.

Pero las referencias a la trama original que es derrotar a Mother Brain ya se encontraban ahí en el manga guía que formaba parte del marketing del juego.

Samus siendo mujer como sorpresa es algo controvertido, es algo que se añadio muy a última hora pero en la versión a cartucho tuvieron tiempo para convertir a Samus sin traje en personaje jugable como premio por haber superado el juego en menos de tres horas.

Por lo que la sorpresa era para la versión japonesa, desgraciadamente para el lanzamiento occidental simplemente tradujeron los manuales de los juegos con todo el contenido de las versiones japonesas, de ahí a que la referencia de Samus como mujer no apareciese para nada. En realidad Nintendo of America no sabía como iba a funcionar el juego en el mercado occidental.

Es decir, un japonés dejo la posibilidad de jugar con Samus sin traje al juego y los lerdos de Nintendo América, especialmente Howard Philips, no se enteraron de nada de nada sobre el personaje de Samus Aran hasta que no se lanzo la segunda parte en Game Boy.

Momento en que les dio por hacer una guia del juego original, Nintendo of America realizando una guia oficial de Metroid años después del lanzamiento del juego y descubriendo ellos por el camino el gran secreto de Samus Aran… Años después.

Es más, la primera vez que Metroid fue tratado como Dios manda en la Nintendo Power fue con el lanzamiento de Metroid II en Game Boy, habían ignorado al primero casi por completo durante años y en uno de las guías…

Quien porto la versión a cartucho fue un japonés, incluyendo la creación de los gráficos de Samus sin traje… ¿Vosotros creeis que la puritana Nintendo of America hubiese dejado correr eso? El motivo por el cual Samus paso la censura fue por eso, nadie en Nintendo of America se había preocupado ni pasado el juego, lo que llevo a que eso no se quitará en el juego final. Es más, Nintendo of America ignoraba tanto el hecho de Samus como mujer que no aparecio en su vergonzosa serie «Captain N».

¿Pero quien fue el creador de estos cambios? Muchos dicen que fue Yoshio Sakamoto pero realmente fue el ya retirado Makoto Kano. Quien se vio influenciado por el éxito de The Legend of Zelda y por el hecho que seguía una forma de diseño completamente distinta al resto.

En palabras del propio Shigeru Miyamoto sobre la influencia de Zelda en el desarrollo de futuros juegos de Nintendo…

Hasta la época de Donkey Kong, que fue el primer juego que dirigí, los ingenieros de programación y hardware fueron responsables del diseño del juego. Esos fueron los días en que estos ingenieros incluso componían la música y dibujaban las imágenes ellos mismos (lo que resultaba en juegos bastante primitivos, ahora clásicos). Cuando yo, como diseñador gráfico, me involucré por primera vez en el diseño de juegos, solía jactarme de que era uno de los cinco mejores diseñadores de juegos del mundo, ya que había pocos diseñadores con experiencia artística en el diseño de juegos en ese entonces. Donkey Kong y otros juegos dieron origen a una nueva tendencia en la que los videojuegos tenían una historia que los acompañaba por primera vez, y el trabajo de los diseñadores de juegos incluyó dibujar las imágenes y escribir la historia. Esta tendencia continuó durante aproximadamente diez años, tiempo durante el cual muchos diseñadores se unieron a la industria, y los compositores de música profesionales también comenzaron a desempeñar un papel en el diseño de juegos. Luego, debido particularmente al éxito de Dragon Warrior y The Legend of Zelda en Japón, surgió una nueva tendencia en la cual los escritores de escenarios tomaron papeles principales en el diseño de juegos. En este momento fui inundado por muchos futuros diseñadores con la esperanza de convertir sus escenarios en juegos, y también vimos escritores de escenarios populares que se asociaron con compositores de música con la esperanza de producir un juego por el bien de los negocios.

¿Fue Kano quien le dio a Metroid su diseño final en cuanto al mapa y su organización final o ya se encontraba esta bien asentada desde los inicios del desarrollo del juego? Más bien creo que Kanoh lo que hizo fue plantear el concepto de buscar los jefes por el laberinto y tener que matarlos como base para acceder al enemigo final, pienso además que fue Kano quien le dijo a Kiyotake que hiciese un Pitfall a la Nintendo y Kiyotake decidió ir en contra de su jefe durante el desarrollo, al final Kano llego a un escenario final y utilizando lo que Kiyotake tenía hecho terminaron Metroid.

El hecho de que Sakamoto dijera que Kano tenía diseñado el escenario de Super Metroid desde mucho antes que se empezará la producción de Metroid 2 me da a pensar que una secuela del Metroid original estaba ya en desarrollo pero esta se termino conviertiendo en Super Metroid para Super Famicom

Uy, me parece que me he ido mucho por las ramas, el caso es que el lore de Metroid al contrario de lo que piensa mucha gente se hizo en pocos meses con tal de tener el juego terminado en un tiempo record tiempo y apenas tenían material pero si el juego se hubiese planteado para el Famicom Disk seguramente que Kiyotake no hubiese tenido los problemas en el desarrollo del juego, bueno, era un problema de timing pero lo que esta claro es que quería gráficos un poco mejores que los que se podían conseguir por aquella época con el juego.

«Super» Metroid en NES

Esto que os voy a decir os puede parece una enorme idiotez pero… ¿Hubiese sido posible un Super Metroid en en NES, obviamente con mejores gráficos y más posibilidades respecto al original pero sin llegar al nivel técnico del clásico de 16 bits?

A nivel visual tenemos un hack del primer Metroid que mejora enormemente los gráficos del juego reemplazando los patrones/sprites por otros mejor trabajados que los que Kiyotake estuvo diseñando, eso si, hace uso de una CHR-ROM mucho más grande.

El juego puede correr en el hardware de una NES estándar, no cambia la estructura del juego pero si los gráficos aumentando el tamaño del juego hasta los 385KB con las animaciones y los gráficos nuevos, pero es algo que hubiese sido posible y utilizando el MMC5 como chip multibanco.

El MMC5 nos proporciona hasta unos 1024KB de PGR-ROM, lo cual estamos hablando de 16 veces la capacidad disponible del primer Metroid solo para el código del juego y la organización del mapa y luego 1024KB para el CHR-ROM, realmente no necesitamos tanta memoria para un supuesto «Metroid 2» en NES, pero lo bueno es que trae consigo capacidades de audio mejoradas para el sistema, lo que hubiese mejorado la calidad de la banda sonora enormemente, incluso por encima de la versión de Famicom Disk.

Con todas estas capacidades adicionales un juego de la complejidad de Super Metroid hubiese sido posible en la Famicom/NES. Precisamente un juego que estuvo durante años en el cajón por las malas ventas del primero en Japón.

El mapa de Super Metroid, pese a que es un juego más complejo no hubiese sido imposible en un Metroid a final de la vida de la NES. Super Mario Bros tuvo secuela, Zelda tuvo secuela…

Lo que sabemos es que conociendo el hardware de NES y los problemas de desarrollo del primero que hubiese sido posible pero no se hizo por motivos más que nada comerciales. La verdadera secuela de Metroid salió precisamente de una charla entre Sakamoto y su jefe, Makoto Kano, que viendo el éxito de Metroid en los Estados Unidos le mando a Sakamoto a hacer la secuela, ya en Super Famicom/Super NES por los tiempos que corrían.

De manera completamente inesperada para Nintendo el hecho de hablar de la versión de NES para promocionar la de Game Boy provoco que existiese una fanbase en la época de Metroid y las ventas se disparasen años después del lanzamiento del juego, hasta el punto en que Nintendo quiso capitalizar el éxito del re-descubierto juego, en palabras de Sakamoto…

Mi jefe [el productor Makoto Kanoh] me dijo que Metroid era realmente popular en América del Norte, por lo que me animó a producir un nuevo juego de Metroid con los gráficos de alta calidad que eran posibles gracias a la Super Famicom. Por supuesto, dije: «Sí, me gustaría intentar hacer eso». El diseño y el concepto del juego ya se habían establecido antes de que Metroid II fuera producido para Game Boy «, explica Sakamoto. “Cuando se trataba de hacer otra secuela, esta vez para la Super Famicom, realmente queríamos ver hasta dónde podíamos impulsar al SFC para generar una mayor potencia de expresión y mejorar la apariencia del mundo del juego, todo mientras trabajábamos con un equipo básicamente sin cambios. concepto. Esa fue nuestra motivación inicial en lo que respecta a Super Metroid: construir sobre la expresividad de Metroid II y lograr una mayor presencia, algo más cercano a una realidad.

y de ahí nacio Super Metroid, de un éxito casual e inesperado de un juego de NES con un lustro de antigüedad.

Esto es todo, como siempre tenéis el Discord y los comentarios de la misma entrada para comentar el contenido de la misma.