Moderne Videospiele sind gigantisch. Eine aktuelle Version kann nach dem Einspielen der Patches mehr als 100 GB Speicherplatz auf Ihrem Gerät belegen. Game-Engines wie Unreal Engine und Unity haben ihre eigenen Abhängigkeiten und Laufzeitumgebungen. Selbst das kleinste Spiel belegt also noch mehrere Gigabyte. Und mit der gestiegenen Nachfrage nach Videospielen ist auch der Umfang der Spiele gewachsen. Aber wusstet ihr damals schon, dass es komplette Spiele gibt, deren gesamter Spielcode nur wenige hundert Bytes umfasst? Diese Größe ist kleiner als ein durchschnittliches Symbol, das sich auf Ihrem Desktop befindet. Ganze Galaxien mit potenziell Milliarden von Sternsystemen würden auf eine einzige Diskette passen. Und die Entwickler programmierten so hardwarenah wie möglich und erstellten Spiele in Assembler oder sogar in direktem Maschinencode, wobei jede einzelne Anweisung sorgfältig ausgearbeitet wurde, um sicherzustellen, dass genügend RAM für ihre Spiele zur Verfügung stand. [Musik] Pong ist ein bekanntes Sport-Arcade- Videospiel aus dem Jahr 1972 mit einfachem Tischtennis- Gameplay, zwei rechteckigen Schlägern und einem sich bewegenden quadratischen Ball. Die ursprüngliche Version von Pong enthielt jedoch kein Softwareprogramm im modernen Sinne. Für das Gameplay wurden keine Allzweck-Mikroprozessoren verwendet. Es gab keinen ROM. Stattdessen wurde Pong mit diskreter elektronischer Logik implementiert. Die Bewegung des Balls, der Schläger, die Kollisionserkennung, die Punktevergabe und die Video-Zeitmessung wurden durch direkt mit der Platine verdrahtete Schaltkreise erzeugt. [Musik] Der Software-Footprint ist null, da kein gespeicherter Code vorhanden ist, an dem man messen könnte. [Musik] Rein technisch gesehen ist Pong eines der kleinsten Spiele, die jemals entwickelt wurden. Wie wir jedoch bald mit dem Aufkommen von Heimcomputern sehen werden , werden Entwickler Wege finden, größere Spiele mit extrem begrenztem Speicherplatz zu erstellen. Erst gestern Abend habe ich mich mit Pitfall Harry im Dschungel verirrt, umgeben von riesigen Skorpionen und menschenfressenden Krokodilen. Im Jahr 1977 brachte Atari den 2600 oder Atari VCS auf den Markt. Die Spiele waren auf ROM-Modulen gespeichert und wurden von einem 6507- Mikroprozessor ausgeführt. Die Basiskonsole verfügte jedoch nur über 128 Byte RAM. Dies wäre der gesamte beschreibbare Arbeitsbereich des Spiels. Spielkoordinaten, Gegnerkoordinaten, Punktestände, Timer, Animationszähler, Kollisionen, Zufallszahlengenerierung, Eingaben, [Musik] -Berechnungen. Der gesamte Code musste in diesen kleinen Speicherplatz passen. Und um die Sache noch interessanter zu machen: Der Atari 2600 hatte keinen herkömmlichen Framebuffer. Stattdessen würde die Konsole das Videosignal direkt erzeugen. Das Spielprogramm musste die Grafikregister bei präzise gesteuerten Bewegungen aktualisieren, während sich der Elektronenstrahl des Fernsehers über den Bildschirm bewegte. Diese Technik wird als Wettlauf gegen den Balken bezeichnet. Dem Prozessor stand für jede Scanzeile nur eine begrenzte Anzahl von Zyklen zur Verfügung. Und wenn das Programm ein Register zu spät aktualisiert, würde ein Teil des Bildes verschoben oder fehlen. Es gab keinen separaten Grafikprozessor, der die Szene im Hintergrund zusammensetzte. Das Spiel zeichnete den Bildschirm effektiv in Echtzeit. Einige der bekanntesten Atari VCS- Spiele, darunter Adventure und Pitfall, belegten 4 Kilobyte große Cartridges. Pitfall würde mithilfe eines kompakten Algorithmus eine Sequenz von 255 Bildschirmen generieren, anstatt 255 vollständige Bildschirmbeschreibungen zu speichern . Das Layout jedes Bildschirms wurde als ein einzelnes Byte dargestellt. Und das Byte, das den Grundriss des aktuellen Raums enthält, wird in vier Teile aufgeteilt. Merke dir [Musik], dass ein Byte acht Bits enthält. In Pitfall enthalten die Bits null bis zwei Informationen über die Objekterzeugung. Die Abschnitte drei bis fünf enthalten Informationen über die Art der Gruben und die Begegnungen des Spielers mit ihnen. Die Nummern sechs und sieben enthalten Hintergrundinformationen zu den Baumarten. Ein einzelnes Zeichen enthält all diese Informationen und lässt nur noch 3.840 Bytes für den Rest des Spiels übrig, einschließlich der Entwicklung von Hindernissen, Feinden, Bewegung, Sound und Punktevergabe. Dank einer cleveren und optimierten Demontage wurde all dies von David Crane ermöglicht. ZX81. Nicht die ersten Mikrocomputer, aber sicherlich die ersten, die erschwinglich waren. Und so entstand der ZX81, eine stromsparende 8-Bit-Maschine, die 1982 von Sinclair Research auf den Markt gebracht wurde. Und die Basiskonfiguration würde nur 1 Kilobyte RAM enthalten. Das sind 1.024 Bytes. Dieser Speicher musste die Betriebsumgebung, die Anzeige, das Programm und die Arbeitsdaten unterstützen. Im Jahr 1982 entwickelte der Programmierer David Horn das Spiel 1K ZX Chess für die nicht erweiterte Maschine, die mit nur 672 verfügbaren Bytes auskam . Der Programmcode würde ein sichtbares Schachbrett, eine Überprüfung der Figurenzüge, computergesteuerte Gegner und eine Positionsbewertung enthalten. Kurz gesagt, es war in der Lage, ein erkennbares Schachspiel zu spielen . Aufgrund der geringen Speicheranforderungen wurden einige Schachregeln weggelassen. Das Kernspiel Schach und die computergesteuerten Gegner blieben jedoch unverändert. Genau wie bei Pitfall würden einzelne Bytes mehrere unabhängige Flags kodieren. Diese Art der Programmierung wird als Größenkodierung bezeichnet und hat zum Ziel, die tatsächliche Maschinencode- Darstellung, die der Prozessor ausführt, zu minimieren. Nicht nur wegen der Geschwindigkeit, sondern vor allem wegen der Größe. [Musik] 1984 veröffentlichten David Braben und Ian Bell Elite für den BBC Micro. Elite würde dreidimensionale Drahtgittergrafik, Weltraumkämpfe, Handel, Ausrüstungsverbesserungen, Andocken, Navigation und einen offenen Spielfortschritt kombinieren. Das Originalspiel Elite ist ungefähr 22 Kilobyte groß und lief irgendwie auf einem BBC Micro mit nur 32 Kilobyte RAM und einem 2 MHz 6502 Prozessor. Doch allein diese schiere Größe erklärt nicht, warum Elite technisch so brillant bleibt. Das Spiel enthält acht separate Galaxien, von denen jede 256 verschiedene Sternensysteme umfasst. Das ergibt insgesamt 2.048 Systeme. Diese Systeme werden jedoch aus deterministischen Startwerten generiert. Der Quellcode des Spiels zeigt, wie das Spiel seine Systemdaten algorithmisch ableitet, anstatt eine komplexe Galaxientabelle zu speichern. Der Spieler kann mit Rohstoffen handeln. Sie können Waffen verbessern, Treibstoff und Ausrüstung kaufen, Piraten bekämpfen, Asteroiden abbauen, ihre Kampfwertung schrittweise erhöhen und vieles, vieles mehr. Das Programm speichert nicht jedes mögliche Ergebnis. Seine Kompaktheit resultiert teils aus der prozeduralen Generierung, teils aus dem systemischen Design. 1993 erweiterte David Braben mit Frontier: Elite II erneut die Kernideen von Elite . Frontier behielt die offene Struktur von Elite bei, erweiterte aber den physischen und systemischen Umfang drastisch. Alles passte auf eine einzige Amiga-Diskette, und die unkomprimierte ausführbare Datei ist etwa 400 Kilobyte groß. Frontier besteht aus einer Galaxie mit einer enormen Anzahl von Sternsystemen. Es umfasst erkennbare astronomische Regionen, verschiedene Sterntypen, Planeten, Monde, Raumstationen und Siedlungen. Das Universum ist nicht als riesige Liste vollständiger Sternensystemdateien gespeichert . Es wird aus Daten und Algorithmen rekonstruiert. Frontier beinhaltete auch realistische Schiffsbewegungen. Schiffe beschleunigen nun, anstatt sich mit einer festen Arcade-Geschwindigkeit vorwärts zu bewegen . Die Geschwindigkeiten bleiben auch nach dem Wegfall des Schubs erhalten. Die Annäherung an einen Planeten erfordert die Berücksichtigung der Relativbewegung. Der Spieler kann in den Orbit eintreten, durch die Atmosphäre absteigen und auf einer Planetenoberfläche landen . Das Spiel stellt Entfernungen und Planetenkörper in einem enormen Maßstab dar. Alle diese Berechnungen wären auf einem 7-MHz- 16-Bit-Computer viel zu anspruchsvoll für den Prozessor. [Musik] Stattdessen würde man also mit Annäherungen, eingeschränkter Geometrie und vereinfachter Darstellung arbeiten. Frontier wurde erneut zu 100 % in Assemblersprache entwickelt und kombinierte Low-Level-Steuerung mit prozeduraler Rekonstruktion und simulationsgetriebenem Gameplay. Das Ergebnis ist ein Spiel, dessen wahrgenommene Welt viel, viel größer ist als die gespeicherte Repräsentation. Das Spiel selbst war jedoch ein Meisterwerk. All das mit einem einzigen, so kleinen Spiel, dass es auf eine einzelne Diskette passt. [Musik] The Legend of Zelda für das NES war ein riesiges Spiel, bestehend aus einer großen Oberwelt und zwei riesigen Unterwelten. Der Spielcode war jedoch sehr klein. Um Speicherplatz zu sparen, stellte es seine Welten als kompakte Raster dar, anstatt ganze Bildschirme als Bilder zu speichern. Die Oberwelt ist als 16 mal 8 Raster mit insgesamt 128 Bildschirmen angeordnet. Das bedeutet, dass Links aktuelle Bildschirmposition in einem einzigen Byte gespeichert werden kann. Jedes Byte enthält horizontale und vertikale Koordinaten. Jeder Overworld-Bildschirm besteht aus einem Raster wiederverwendbarer Geländekacheln wie Gras, Felsen, Wasser, Bäumen und Treppen. Und da auf den meisten Bildschirmen nur wenige Terraintypen verwendet werden, muss das Spiel keinen großen Wert für jedes einzelne Feld speichern. Es erfasst zunächst, welche Geländetypen vorhanden sind, und verwendet dann nur wenige Bits, um jede Kachel zu identifizieren. Demnach lässt sich ein kompletter Overworld-Bildschirm in etwa 44 Bytes beschreiben, und die vollständige Overworld-Karte passt in etwa 6 Kilobytes. Der Dungeon-Code ist ebenfalls sehr kompakt. In den meisten Räumen wird nur ein Haupthindernistyp verwendet, wie z. B. Stein, Wasser, Sand oder Statuen, und ihre Grundrisse werden spaltenweise gespeichert, wobei die nicht verwendeten Teile zusammen mit Wand- und Türinformationen gepackt werden. Dadurch reduziert sich der Umfang der Dungeon-Räume auf etwa 12 Byte Kartendaten. Die Dungeon-Karten der ersten und zweiten Quest belegen zusammen etwa 3 Kilobyte, sodass die gesamte Spielwelt ungefähr 8 Kilobyte groß ist. Wie Pitfall verwendet auch Zelda wiederverwendbare [Musik-] Bausteine, kompakte Referenzen und dicht gepackte Bitfelder. Das Spiel wirkt riesig, weil seine Systeme die Welt aus kleinsten Datenfragmenten rekonstruieren. Kachelbasierte Spielkonsolen waren entscheidend für die geringe Größe von Videospielen, da sie die Notwendigkeit beseitigten, für jeden Bildschirm ein vollständiges, individuelles Bild zu speichern . Anstatt eine riesige Vollbildgrafik zu speichern, verwendeten Konsolen wie der Game Boy, das NES, das Sega Master System und der Genesis eine kleine Bibliothek winziger Bildblöcke. Die Bildschirme wurden effektiv in ein Raster aus 8 mal 8 oder 16 mal 16 Blöcken, sogenannten Kacheln, unterteilt. Die Kachelkarten wurden als textähnliches Raster aus Koordinatenzahlen erstellt. Bei dieser Vorgehensweise könnte ein und dasselbe Spielfeld in einem Spiel hunderte Male wiederholt werden. Im Vergleich dazu würde ein vollständiges 256×240- Bildschirmbild etwa 30 Kilobyte an Daten benötigen. Eine Kachelkarte mit Zeigern für denselben Bildschirm würde nur 1 Kilobyte benötigen. Wie wir gesehen haben, besteht der Vorteil darin, dass riesige Welten wie in The Legend of Zelda entwickelt werden konnten, aber es gab auch andere kreative Vorteile, wie z. B. Farbpalettentausch, flüssiges Scrollen und Hardware- Register, um entweder [Musik] Kacheln in X- und Y-Koordinaten oder sogar in beiden zu spiegeln. Das Hauptziel war jedoch, die RAM-Kosten für die Musik niedrig zu halten. Frühe Konsolen verfügten über winzige Speicherpools, oft nur 2 Kilobyte Arbeitsspeicher, und da ROM- Chips teuer waren, hielten weniger Bytes die Einzelhandelspreise für Spiele erschwinglich. Da Spielkonsolen geschlossene Systeme sind und traditionell mit Cartridges und später mit optischen Medien arbeiten, berücksichtigen wir die tatsächlichen technischen Grenzen oft nicht. Die PlayStation 1 CD-Technologie erschloss Spiele einem breiten Publikum dank ihres massiven Speichers, der große Welten, Videos in voller Bewegtbildtechnik und Soundtracks in CD-Qualität aufnehmen konnte . Vereinfacht ausgedrückt verfügte die PlayStation nur über 2 Megabyte RAM, also die Hälfte dessen, was die N64 zu dieser Zeit hatte. CDs würden das herkömmliche Wechseln von Disketten ersetzen, indem sie durch gezieltes Suchen auf den benötigten Code und die benötigten Daten auf der Diskette zugreifen. Aber es musste immer noch ein fest installiertes Programm oder ein Spielcode vorhanden sein, der das Ganze steuerte, und dieser Spielcode musste in den geringen Speicherbedarf von Spielkonsolen passen. Mitte der 90er Jahre wollte Naughty Dog einen 3D-Plattformer mit komplexer Geometrie und aufwendigen Texturen entwickeln, doch die Speicherbeschränkungen der PlayStation machten dies auf herkömmliche Weise schwierig. Die Entwickler würden jedoch einen komplett eigenen virtuellen Speichermanager erstellen und die CD selbst als Auslagerungsdatei verwenden. In Crash Bandicoot werden die Level nicht vollständig geladen. Sie werden permanent von der Festplatte in den winzigen 2 MB großen PlayStation-Speicher gestreamt. Durch das dynamische Ein- und Ausblenden von Daten erreicht das Spiel eine Detailtreue, die es so noch nie gegeben hat. Streng genommen ist Crash Bandicoot kein kleines Spiel, da es die gesamte CD benötigt, um seine Spielkarten-Assets auszuführen. Die ausführbare Datei ist jedoch eng komprimiert und optimiert und bietet ein Spielerlebnis, das die Sony-Ingenieure bei der Entwicklung der PlayStation nie in Betracht gezogen hatten. Und natürlich gibt es noch viele weitere Beispiele. Und wenn wir uns die meistverkauften Spiele aller Zeiten ansehen, mussten viele von ihnen mit begrenzten Ressourcen auskommen und waren speziell für die Maschinen optimiert und entwickelt worden, für die sie gebaut wurden . Oftmals sprachen wir davon, dass Entwickler Assemblersprache oder Maschinencode verwendeten, um maximale Geschwindigkeit zu erreichen, aber Assemblersprache wurde oft auch verwendet, um den Speicherplatz zu minimieren. Bitweise Manipulationen waren möglich, clevere Abkürzungen, um den Code zu minimieren und die Geschwindigkeit zu maximieren. Zu den weiteren Tricks gehörten selbstmodifizierender Code und die Zeit, die zum Ausführen einer Sequenzmaschine von Codeanweisungen benötigt wurde. Und die Entwickler konzentrierten sich oft auf eine einzige Plattform, eine einzige Taktfrequenz und verzichteten dabei auf eine Benutzeroberfläche. Die Optimierung konzentrierte sich auf diese spezifische Plattform. Natürlich waren damals alle Spiele tatsächlich eingeschränkt: begrenzte Farbpaletten, Bildschirmauflösungen, Speicherplatz. Aber es ist trotzdem erstaunlich, dass jemand ein Schachspiel mit nur 1 KB RAM entwickelt hat. Bis bald.