Das Nintendo Entertainment System und sein japanisches Gegenstück, das Famicom, müssen nicht vorgestellt werden – wenn Sie dieses Magazin lesen, wissen Sie, dass die 8-Bit-Hardware Nintendo in die weltweite Führungsposition im Videospielgeschäft katapultierte und die ersten Versionen zahlloser klassischer Serien hervorbrachte.
Obwohl das Marketing eine wichtige Rolle bei diesem kommerziellen und kulturellen Erfolg spielte, wäre er ohne die Hardware nicht möglich gewesen. Schließlich waren das ColecoVision und der Atari 5200 weniger als ein Jahr alt, als das Famicom 1983 in Japan auf den Markt kam, und der 3DO und der Atari Jaguar waren bereits auf dem Markt, als die Entwickler das NES 1994 endgültig aufgaben. Ohne eine Hardware, die flexibel und leistungsfähig genug ist, um mit dem wechselnden Geschmack der Spieler Schritt zu halten, kann ein Gerät einfach nicht so lange relevant bleiben.
Neues Terrain
(Bildnachweis: Evan Amos)Heute abonnieren
(Bildnachweis: Future)
Dieser Artikel erschien zuerst im Retro Gamer Magazin. Abonnieren Sie Retro Gamer in gedruckter oder digitaler Form, um mehr über klassische Spiele und Konsolen zu erfahren, die direkt zu Ihnen nach Hause oder auf Ihr Gerät geliefert werden.
Aber das NES war nicht nur ein Titan seiner Zeit – viele Entwickler entwickeln neue Spiele für die Hardware und setzen sie mit modernen Entwicklungstools mehr denn je unter Druck. Zwei CPUs und ihre Derivate dominierten die Heimhardware-Szene der achtziger Jahre – der Zilog Z80, der im ZX Spectrum, ColecoVision und Master System zum Einsatz kam, und der MOS Technology 6502, der im Atari 5200, Apple II und Commodore 64 verwendet wurde. Nintendos Ingenieur Masayuki Uemura entschied sich für den 6502 für das NES, vor allem weil er so klein war, dass ein Chip auch Soundfunktionen enthalten konnte.
Im Jahr 2016 sagte der verstorbene Ingenieur gegenüber Retro Gamer, dass diese Entscheidung „ein großes Problem innerhalb des Unternehmens“ verursachte, da Nintendos erfolgreiches Arcade-Spiel Donkey Kong einen Z80 verwendet hatte und der Quellcode nicht wiederverwendet werden konnte. Die Berücksichtigung von Programmierern außerhalb von Nintendo hatte keine Priorität, da das Unternehmen ursprünglich nicht beabsichtigte, dass Drittanbieter Teil seines Geschäftsmodells sein sollten. Natürlich machte der Erfolg der Hardware in Japan und Nordamerika die Entwicklung durch Dritte notwendig, um mit der Nachfrage nach neuen Spielen Schritt zu halten.
In Großbritannien hatte das System nicht den gleichen Einfluss, weshalb der Programmierer Paul Machacek erst 1988 bei Rare – einem der wenigen britischen Entwickler, die sich auf Nintendos System konzentrierten – auf das System stieß. Seine zuvor veröffentlichten Spiele waren für Z80-basierte Computer geschrieben worden, und er wurde zunächst damit beauftragt, für das Z80-basierte RAZZ Arcade-Board zu schreiben, aber schon bald wurde er gebeten, an einem NES-Projekt zu arbeiten. Glücklicherweise war Paul mit dem 6502-Assemblercode aus seiner Zeit als Oric-1-Besitzer vertraut. „Ich habe mich schnell wieder eingearbeitet“, sagt er, „aber ich habe vergessen, wie sehr man damit im Vergleich zum Z80 mit Zahlen jonglieren muss, weil der 6502 so wenige Register hat, dafür aber den schnellen Zero-Page-Speicher.“
Entwickeln Sie, was wir mit den Werkzeugen, die uns zur Verfügung standen, auf den Systemen, die wir benutzten, gemacht haben, und sagen Sie mir, dass Sie am Ende nicht etwas Ähnliches machen würden.
Paul Machacek
Die Entwicklungsumgebung, mit der Paul arbeitete, war recht einfach. „Ursprünglich benutzte jeder bei Rare PDS (Programmers Development System), einen Texteditor und Code-Assembler. Wir hatten selbstgebaute Schnittstellenkarten, die in den Kassettenschacht des NES eingesteckt wurden und über ein Flachbandkabel mit unseren PCs verbunden waren, auf denen PDS lief“, erklärt er. „Wir hatten kein Netzwerk. Die PCs waren Amstrads mit 20-MB-Festplatten (kein Tippfehler). Jedes Mal, wenn Sie Ihren Code zusammensetzten – das ging alles in einem Rutsch, wir hatten noch keine Linker -, wurde die vollständige Binärdatei über das Flachbandkabel auf die Schnittstellenkarte kopiert, und Sie führten Ihren Code auf dem Zielcomputer aus. Was die Dokumentation anging, hatten wir nur das Standardhandbuch für das NES, das ein paar Tippfehler enthielt, die korrigiert werden mussten, weil die Dinge sonst nicht funktionierten, und außerdem das handliche 6502-Befehlssatzhandbuch zum gelegentlichen Nachschlagen, vor allem, wenn Sie selbst modifizierenden Code schreiben wollten.“
Wenn Sie als Programmierer bei diesem Satz zusammenzucken, wird es noch schlimmer. „Es gab keine Debugging-Tools, wie man sie heute kennt“, fährt Paul fort. „Es gab Tricks, um herauszufinden, wo Ihr Code war, bevor etwas schief ging, z.B. das Schreiben von Werten in eine Speicherstelle und das Herausfinden, welcher Wert zuletzt geschrieben wurde, bevor es zum Absturz kam. Für Leistungstests hatten Sie normalerweise eine visuelle Veränderung auf dem Bildschirm (Verschieben eines horizontalen Scroll-Registers oder Ändern einer Farbpalette) am Anfang einer Funktion und setzten sie am Ende zurück, so dass Sie ‚messen‘ konnten, wie lange es auf dem Bildschirm dauerte, indem Sie mit Markierstiften Markierungen um diesen sichtbaren Indikator herum zeichneten und sahen, ob die Markierungen näher zusammenkamen, wenn Sie Ihren Code weiter optimierten. Ja, Leute, das waren noch Zeiten, als man die Leistung von Code in Zoll maß!“
Das hört sich nach einer ziemlich umständlichen Arbeitsweise an, aber Paul sieht es einfach als ein Produkt der damaligen Umstände. „Gehen Sie 35 Jahre zurück, entwickeln Sie, was wir mit den Werkzeugen, die uns zur Verfügung standen, auf den Systemen, die wir benutzten, gemacht haben, und sagen Sie mir, dass Sie am Ende nicht etwas Ähnliches tun würden!“ Glücklicherweise sollte sich die Situation für Paul und seine Kollegen schließlich verbessern. „Nach ein paar Jahren beauftragte Rare Jon Ritman, einen engen Mitarbeiter, ein neues System namens GLAM [Global Language Assembler Monitor] zu schreiben, um PDS zu ersetzen. GLAM konnte eine größere Anzahl von Prozessoren ansprechen und verfügte sowohl über einen Linker als auch über einen Assembler, so dass man nicht jedes Mal, wenn man etwas änderte, die gesamte Codebasis assemblieren musste, was die Entwicklung beschleunigte. GLAM hat wirklich gut funktioniert.“
(Bildnachweis: Nintendo)
Letztendlich war die 6502-Programmierung für Paul kein großes Problem bei der Umstellung auf eine neue Plattform. „Die größere Umstellung war für mich der Wechsel von Heimcomputern mit Bitmap-Bildschirmen zu dem zeichenorientierten System des NES, mit separaten Farbpalettenbezeichnungen, Zeichenbänken (und deren Austausch) und dem Austausch von Speicherbänken auf den Carts“, erinnert er sich. Nintendos Picture Processing Unit – kurz PPU – war eine Spezialanfertigung von Ricoh, und laut Nicolas BÉtoux von Morphcat Games „waren die Grafik- und Scrollfähigkeiten im Vergleich zu anderer Hardware dieser Zeit großartig.“
Als das Famicom 1983 auf den Markt kam, war sein nächster Konkurrent in Japan das SG-1000 von Sega. Die grafischen Fähigkeiten des Famicom waren eindeutig überlegen – es verfügte über eine Palette von mehr als 50 Farben im Vergleich zu nur 16 Farben bei Segas System, die Sprites konnten jeweils drei Farben haben, im Gegensatz zu nur einer, und die Bildschirme konnten pro Pixel und nicht pro Zeichen gescrollt werden, was zu einem wesentlich flüssigeren Aussehen führte. Nintendos Hardware konnte auch mehr Sprites insgesamt und mehr Sprites pro Scanline darstellen. Sega brachte 1985 die grafisch überlegene Mark III-Hardware auf den Markt, was bedeutete, dass der Wettbewerb zu dem Zeitpunkt, als das NES und das Master System das internationale Publikum erreichten, ausgeglichener war.
Das Handwerkszeug
Während Nintendos 8-Bit-Hardware über fortschrittliche grafische Fähigkeiten verfügte, waren die Methoden, die zur Erstellung dieser Grafiken verwendet wurden, alles andere als fortschrittlich. Wie Paul hatte auch der Künstler Kevin Bayliss noch nie mit einem NES zu tun gehabt, bevor er Spiele für das System entwickelte. „An meinem ersten Tag bei Rare zeigte mir Tim [Stamper] den grundlegenden ‚Pixelierungsprozess‘ und brachte mir bei, wie man eine Arbeit erstellt, die man in ein Spiel einbauen kann“, erzählt er uns.
„Im Grunde musste ich mein Kunstwerk zeichnen und es unter ein Rasterblatt auf einem großen Zeichenbrett mit fluoreszierenden Streifen legen. Dann zeichnete ich meine Zeichnung nach, indem ich das Raster benutzte, um mit einem Bleistift Pixel zu definieren, und dann füllte ich die Pixel mit Filzstiften aus. Dann musste die Arbeit organisiert und in Boxen (8×8 Sprites) aufgeteilt werden und die Sprite- und Positionsdaten mussten in meinem Kopf in hexadezimaler Form berechnet werden. Das war ziemlich einfach, aber manchmal auch etwas mühsam, und oft wollte man diese Arbeit gar nicht machen, weil sie überhaupt nicht kreativ war. Sie wollten einfach nur Ihre Arbeit im Spiel sehen.“
Wenn Sie sich über das Fehlen eines Computers bei diesem Prozess wundern, dann haben Sie nichts falsch verstanden. „Es gab keine anderen Hilfsmittel als Stift, Papier und ein chirurgisches Skalpell, mit dem Sie Ihre Fehler auf dem Transparentpapier auskritzeln konnten, wenn Sie ein Pixel an der falschen Stelle platziert hatten oder wenn Sie Pixel von einer Figur abschneiden wollten, um sie in weniger Daten zu quetschen“, stellt Kevin klar. „Es gab einen einfachen Sprite-Editor, den Mark Betteridge geschrieben hatte, der aber nicht wirklich genutzt wurde, weil er sehr begrenzt war und es nicht erlaubte, die Animation zu betrachten (wie es in den alten Disney-Filmen hinter den Kulissen gemacht wird – indem man das Papier hin- und herblättert, um die Illusion einer Animation zu erzeugen).
Es gab keine anderen Hilfsmittel als Stift, Papier und ein chirurgisches Skalpell, mit dem man seine Fehler auskritzeln konnte.
Kevin Bayliss
Da die Entwicklungswerkzeuge für das NES nicht standardisiert waren, wurden von den verschiedenen Firmen eine Vielzahl unterschiedlicher Zeichenwerkzeuge verwendet. Nintendo benutzte eine Zeit lang handgezeichnete Sprites, entwickelte dann aber ein mausgesteuertes Pixel-Art-Tool, während Namco ein Sprite-Editing-Tool mit der von Kevin beschriebenen Animationsvorschau hatte. Allerdings gefiel ihm der Low-Tech-Ansatz bei Rare.
„Ich meine, man hätte auf keiner 16-Bit-Konsole alle Grafiken auf Papier zeichnen können, denn man hätte nie genug Stifte gehabt und die Dekodierung hätte den ganzen Tag gedauert – und man hätte so viele Fehler gemacht – es wäre unmöglich gewesen“, sagt er. „Aber aufgrund der Einfachheit der Farbpalette, der geringen Auflösung und der geringen Anzahl von Sprites, mit denen wir meistens zu tun hatten, hat das Erstellen von Grafiken auf Papier tatsächlich Spaß gemacht und fühlte sich viel ‚organischer‘ an als die digitale Erstellung auf dem SNES, und ich denke, das hat etwas für sich.
Unabhängig davon, wie ein Entwickler die Grafiken für das NES erstellte, spielten die technischen Einschränkungen eine Rolle für das Endergebnis. „Sprites pro Zeile (mehr als 64 gefüllte Pixel in einer horizontalen Abtastzeile) waren ein Problem, also versuchte man, die Charaktere nicht sehr breit zu machen“, erklärt Kevin. „Ich erinnere mich zum Beispiel daran, dass alle Charaktere in den WWF-Spielen, die ich entwickelt habe, entweder ‚zurückfallen‘ oder ‚auf dem Boden liegen‘ mussten, und das bedeutete natürlich, dass sie in dieser Pose ziemlich breit waren. Man hat also oft versucht, sie anzuwinkeln oder die Pose geschickt zu gestalten, aber man konnte es nie wirklich vermeiden. Sie können sehen, wie die Charaktere oft auf- und abblitzen, besonders in solchen Beat-‚em-up-Spielen, und das war ein Problem, mit dem alle Firmen so gut wie möglich umgehen mussten.“
Dieses charakteristische Flackern ist eigentlich eine clevere Programmierumgehung – das NES würde einfach Pixel überspringen, wenn zu viele Sprites angezeigt werden, so dass das schnelle Ein- und Ausschalten der Sprites zumindest sicherstellt, dass sie alle in irgendeiner Form angezeigt werden.
(Bildnachweis: Nintendo)
In der Tat mussten die NES-Entwickler oft kreativ werden, um ihre Visionen zu verwirklichen – wie zum Beispiel die riesigen Bossfiguren, die Kevin für Cobra Triangle zeichnete. „Bei Cobra Triangle hatten wir Glück, denn das Spiel fand in einer isometrischen Umgebung statt, so dass alle Grafiken aus einem Winkel betrachtet wurden, der die Breite reduzierte, die man normalerweise in einem horizontal scrollenden Spiel sehen würde“, sagt er.
„Die Boss-Charaktere waren alle eine Ansammlung von großen Sprites und wir konnten die Wasseroberfläche nutzen, um Dinge unter Wasser erscheinen zu lassen, indem wir ein paar ‚Ripple‘-Sprites um sie herum an der Basis hinzufügten. So war zum Beispiel die von mir erstellte Figur des Seeungeheuers (Nessie) ziemlich groß und die Buckel hinter ihr bewegten sich unabhängig voneinander, und aufgrund des Winkels gab es nicht viel, was das Flimmern der Sprites betraf.“
Schwieriger wurde es, wenn es um die Entwicklung von Lizenzspielen ging, was bei Rare häufig der Fall war. „Bei WWF-Wrestling-Spielen mussten wir sicherstellen, dass die Charaktere ähnlich aussahen. Es war also schwierig, die Fotos von Hand zu ‚digitalisieren‘ und die Charakteristika eines jeden genau wiederzugeben, wenn man nur etwa 16×16 Pixel für ein Kopfbild auf der Auswahlseite zur Verfügung hatte“, sagt Kevin. „Ich erinnere mich noch daran, dass ich diese Faxe mit den Bildern der Wrestler in miserabler Qualität bekam und versuchen sollte, sie mit einer so geringen Auflösung und drei Farben nachzubilden.“
Das führte allerdings zu einigen lustigen Erlebnissen. „Oft bekam ich Faxe aus Amerika zurück, in denen es hieß: ‚Die Grafik muss überarbeitet werden‘, weil die Ähnlichkeit nicht gut genug war“, fährt Kevin fort. „Dann änderte ich etwa ein Pixel und bekam am nächsten Tag ein Fax zurück, in dem stand, dass das Bild viel besser sei. Das hat mich wirklich zum Lachen gebracht. Als ich an dem Beetlejuice-Spiel arbeitete, hatte ich auch das gegenteilige Problem: Mein Titelbild sah Michael Keaton zu ähnlich, und so musste ich es noch einmal überarbeiten, damit es mehr nach Beetlejuice aussah – irgendwie schwierig, wenn es sich um dieselbe Person handelt.“
Zwischentöne
Manchmal war es möglich, das System über seine theoretischen Grenzen hinaus zu bringen. „Wenn Sie sich Super Off Road ansehen, werden Sie feststellen, dass es manchmal mehr Farben auf dem Bildschirm gibt, als die Hardware standardmäßig verarbeiten kann“, sagt Paul. „Es gab vier Paletten mit jeweils vier Farben, aber die erste Farbe in jeder Palette war für alle dieselbe Hintergrundfarbe. Insgesamt konnten also 13 Farben für Hintergrundzeichen angezeigt werden. Bei Super Off Road werden mehr angezeigt, weil ich die Paletten mit sorgfältig getimten Zugriffen auf den VRAM während der horizontalen Austastung geändert habe. Das hat gut funktioniert“, erklärt Paul, bevor er sich korrigiert. „Nun, auf der US-Version des NES hat es funktioniert.
Als das Spiel fertig war, teilte man mir mit, dass es in Japan auf dem Famicom erscheinen würde, das in Bezug auf die Hardware etwas anders war und auf dem meine Farbumschaltung leider nicht funktionierte, also glaube ich, dass es dort nicht veröffentlicht wurde.“Der Ton wurde von demselben Ricoh 2A03-Chip gesteuert, der auch die CPU enthielt: „Auf dem NES haben Sie vier Audiokanäle, mit denen Sie arbeiten können. Wir zählen den DPCM (Sample)-Kanal nicht mit, da er einige Nachteile hat“, sagt Nicolas, ein Entwickler moderner NES-Spiele.
„Wie auch immer, das sind zwei Rechteckwellengeneratoren, eine Dreieckswelle, die oft für Basslinien verwendet wird, und ein Rauschkanal, der für perkussive Klänge verwendet wird. Sie sehen also, es gibt nur begrenzte Möglichkeiten für Polyphonie und Klangfarbe, was es schwierig macht, einen atmosphärischeren Soundtrack zu erstellen, wie Sie ihn in modernen Spielen hören. Wahrscheinlich ist das ein Grund, warum viele Spiele-Soundtracks von damals dies mit dynamischen Kompositionen und eingängigen Melodien wettgemacht haben.“
(Bildnachweis: Nintendo)
Der NES-Sound hat einige besonders charakteristische Merkmale, nicht zuletzt die Dreieckswellen, die aufgrund der 4-Bit-Soundverarbeitung des Systems eher treppenförmig als glatt sind. „Aufgrund der begrenzten Anzahl von Kanälen müssen Sie auch darauf achten, dass Soundeffekte die Musik unterbrechen können“, fügt Nicolas hinzu. „Im Idealfall lassen Sie Soundeffekte nur auf den Kanälen abspielen, die Sie für die Begleitung verwenden, damit sie die Melodie nicht zum Schweigen bringen.“
Der Sound ist auch eines der Unterscheidungsmerkmale zwischen dem Famicom und dem NES, da das Famicom über den Cartridge-Port erweiterte Audiofunktionen unterstützt – etwas, das das Famicom Disk System und bestimmte spezielle Cartridge-Chips nutzen. Da das NES nicht über diese Fähigkeit verfügt, haben japanische Versionen von Spielen wie The Legend of Zelda und Castlevania III: Dracula’s Curse eine deutlich bessere Musik als ihre internationalen Gegenstücke. In der Tat waren die speziellen Chips einer der Schlüsselfaktoren für die Langlebigkeit des NES. Das NES unterstützte nicht nur ROM und RAM auf den Kassettenplatinen, sondern konnte auch Chips verwenden, die Nintendo Memory Management Controllers nannte.
Diese Chips ermöglichten nicht nur einen Bank-Switching-Modus, der die Speicherbeschränkungen der ursprünglichen Kassetten-Spezifikation überwand, sondern boten auch zusätzliche Funktionen zur Unterstützung der Spielentwicklung und für das Famicom sogar eine Audio-Erweiterung. So konnte das System im Laufe eines Jahrzehnts von Spielen wie Donkey Kong zu komplexeren Titeln wie Kirby’s Adventure übergehen. Natürlich kämpften die Entwickler selbst bei einer ROM-Kapazität, die die ursprünglichen 40 KB bei weitem überstieg, oft um jedes Byte. „Ein häufiges Problem war damals der Versuch, die Spiele auf die winzigen Cartridges zu packen, die wir bekamen“, sagt Paul. „Auf dem NES/Game Boy (beides 8-Bit-Systeme mit 64 KB Speichergröße) wurde dies durch das Bankswitching erschwert, bei dem die Region in vier 16-KB-Blöcke aufgeteilt war und Sie zwischen verschiedenen ROM-Bänken hin- und herschalten konnten.
Sie mussten also sorgfältig arrangieren, welcher Code und welche Daten sich wo befanden und wie Sie von einer ROM-Bank zu einer anderen im gleichen Adressraum springen würden, indem Sie standardmäßige Overlay-Sprungtabellen am Anfang des Raums verwendeten. Wir mussten auch Datenkomprimierungsroutinen entwickeln, oft verschiedene für verschiedene Datentypen – Zeichendaten, Kartendaten, Textdaten, Musikdaten. Die Huffman-Komprimierung wurde häufig verwendet, aber ich habe auch viel Zeit damit verbracht, mir Ausdrucke anderer Datentypen anzuschauen und nach Mustern zu suchen, die ich für die Entwicklung von Komprimierungssoftware verwenden konnte.“
8-gebissen
James ist ebenfalls voll des Lobes über die Software: „Die Community ist großartig und die Ressourcen für die Nutzung der Tracker-Anwendungen sind für jeden zugänglich, egal ob Sie ein erfahrener Komponist oder nur ein Fan von Chiptunes sind.“ Mit diesen modernen Tools, die ihnen zur Verfügung stehen, neigen NES-Entwickler heute dazu, sehr ehrgeizige Projekte in Angriff zu nehmen. Vier-Spieler-Actionspiele sind auf dem NES eine Seltenheit, aber Morphcat Games hat mit Micro Mages ein hervorragendes Spiel entwickelt. Dies erforderte einen sehr sparsamen Umgang mit der Hardware.
„Das NES erlaubt es, maximal 64 Hardware-Sprites gleichzeitig auf dem Bildschirm darzustellen“, beginnt Nicolas. „Diese Sprites sind 8×8 Pixel groß (es gibt auch einen 8×16-Modus, aber der hat seine Nachteile) und können zu größeren Sprites zusammengesetzt werden: „Um also im ersten Modus ein 16×16-Sprite zu erhalten, müssen Sie vier Hardware-Sprites verwenden. Wenn alle vier Spieler 16×16-Sprites verwenden, ist das ein Viertel aller verfügbaren Hardware-Sprites, die für Spieler verwendet werden! Außerdem gibt es eine Hardwarebeschränkung, bei der mehr als acht Sprites auf einer horizontalen Linie verschwinden“, fährt er fort: „Um dieses Problem zu beheben und trotzdem viele andere Objekte und grafische Effekte auf dem Bildschirm zu ermöglichen, verwenden die Spielercharaktere in Micro Mages jeweils ein einzelnes 8×8-Sprite.“
Die 8-Bit-CPU erweist sich laut Nicolas ebenfalls als einschränkender Faktor. „Wenn ein Spiel einen Feind hat, der sich nur seitwärts bewegt und sich umdreht, wenn er auf eine Wand stößt, ist das eine begrenzte Anzahl von Kontrollen, die durchgeführt werden müssen. Menschliche Spieler hingegen sind Joker. Sie interagieren mit allem, was sie umgibt, auf eine Art und Weise, die ein Entwickler nicht vollständig vorhersagen kann.
(Bildnachweis: Nintendo)
Ich habe es geliebt, das NES zu programmieren. Es war eine völlig andere Architektur als die Heimcomputer, an denen ich zuvor gearbeitet hatte.
Paul Machacek
Wenn die Spieler die Möglichkeit haben, zu schießen, steigt die Anzahl der Objekte auf dem Bildschirm schnell an“, erklärt er uns. „Bei einem Einzelspielerspiel ist das kein großes Problem und bei einem Spiel für zwei Spieler kommt man in der Regel gut damit zurecht. Aber ein Spiel mit vier Spielern? Autsch. Bei Micro Mages haben wir viel Zeit in die Optimierung investiert, um Verzögerungen zu vermeiden. Im Vier-Spieler-Modus kann es jedoch vorkommen, dass das Spiel immer noch langsamer wird, wenn zu viel los ist.“
Ein Vorteil, den moderne Entwickler haben, ist die Möglichkeit, aus einer breiten Palette von Speicherverwaltungslösungen zu wählen – heutzutage besser bekannt als Mapper. „Sie sind einfach so interessant, dass man sie auspacken und dafür entwickeln kann“, sagt James. Obwohl wir die leistungsstärksten Mapper zur Verfügung haben, sind sie nicht immer die Standardwahl. „Wenn wir bei Mega Cat die Entwicklung eines Spiels planen, arbeiten wir rückwärts, ausgehend von dem, was erforderlich ist, damit das Spiel im Kern Spaß macht“, erklärt James. „In einigen Fällen entscheiden wir uns für etwas Leistungsstarkes wie den MMC3-Mapper, in anderen Fällen können wir es einfach halten und einen diskreten Mapper wie einen NROM verwenden.“ Das jüngste NES-Spiel Blazing Rangers des japanischen Entwicklers Karu_gamo verwendet sogar den einfachsten Mapper, den NROM, um Nostalgie für die frühen Tage des Famicom zu wecken. Das ist wirklich der Kern der anhaltenden Faszination der Entwickler für das NES – es ist nicht nur ein technisch interessantes System, sondern auch eines, das eine starke nostalgische Anziehungskraft ausübt.
Selbst diejenigen, die wie Kevin zum ersten Mal beruflich damit zu tun hatten, spüren diese Nostalgie. „Ob Sie nun Hintergründe, animierte Sprites, Titelblätter oder Front-End-Grafiken (Anzeigetafeln) erstellten – Sie hatten ein System, das Sie bereits bei einem früheren Spiel verwendet hatten, und gelegentlich ließen Sie sich etwas Neues einfallen, um es noch ein wenig weiter zu entwickeln und visuell noch mehr herauszuholen. Einfache Zeiten, aber Spaß!
Obwohl Paul das Zahlenjonglieren bei der Programmierung für den 6502 beklagt, erinnert er sich auch gerne an das System. „Ich habe es geliebt, für das NES zu programmieren. Es war eine völlig andere Architektur als die Heimcomputer, an denen ich zuvor gearbeitet hatte, es gab interessante Tricks, die man mit dem zeichenbelegten Bildschirm spielen konnte, um dem Spiel mehr Tiefe zu verleihen – sehen Sie sich unsere Battletoads-Spiele auf dem NES/Game Boy an – und ich betrachtete das Ganze als eine interessante technische Herausforderung, um neue Probleme rund um diese alternative Hardware-Architektur zu ‚lösen‘.“
Die Zukunft der Vergangenheit
Aber bei allem Spaß an der Programmierung des Systems weist Paul zu Recht darauf hin, dass die Ergebnisse dieser Arbeit der Grund für den Erfolg des NES sind. „Man darf nicht vergessen, dass Nintendo einen unglaublichen Katalog von Spielen auf den Systemen hatte, vor allem Super Mario und Zelda. Super Mario Bros 3 war ein riesiger Schritt nach vorne und ein absoluter Höhepunkt zu dieser Zeit“, sagt er.
Wenn Sie ein aufstrebender Entwickler von Retro-Spielen sind, könnte das NES die ideale Plattform für Sie sein. „NES-Code, Grafik und Sound sind von jeweils einer Person im Team leicht zu verwalten“, sagt Nicolas. „Im Vergleich zu heute fühlt sich die Programmiersprache obskurer und komplexer an als moderne Sprachen. All die Einschränkungen zwingen Sie dazu, für alles mehr Zeit aufzuwenden“, gibt er zu. „Aber es zwingt Sie auch, über jede Idee zweimal nachzudenken. Am Ende können Sie sich auf die für das Gameplay wichtigsten konzentrieren.
Diese Einschränkungen können den Umfang Ihres Spiels im Zaum halten – es gibt nur so viel, wie Sie tun können.“Wenn Sie sich von der Idee angezogen fühlen, diese technische Herausforderung in Angriff zu nehmen, zeigen Sie uns eines Tages die Ergebnisse – wir sind immer daran interessiert, sie zu sehen.
Dieser Beitrag erschien ursprünglich in der Zeitschrift Retro Gamer. Für weitere fantastische Features und Interviews können Sie Retro Gamer hier in gedruckter oder digitaler Form abonnieren.