In Zeiten von Unity und Unreal, wo die Engines virtuelle Maschinen sind, die auf was-auch-immer-für-eine-Hardware laufen, ist kaum noch vorstellbar, wie die Entwicklung von Games zu Zeiten der 8Bitter wie Z80, Atari 2600, ColecoVision, Vectrex, C64 von statten ging. 8bit bezieht sich dabei auf die ‚Breite‘ der verarbeitbaren ‚Wörter‘ alias Bytes. 8bit entspricht dabei dem Zahlenraum von 0-255 (oder Hexadecimal von 00 – AA).
Produktionsbedingungen
Aber was waren die Bedingungen damals bei der Produktion/Programmierung von diesen 8bit Spielen? Wie River-Raid? Space-Invaders? Wie konnte man aus diesen relativ primitiven ‚Consolen‘ so viel rausholen (demgegenüber standen extrem teure Mainframes mit weit komplexeren Spielen etwa auf der Plato-Platform) . Die Antwort dazu heisst fast immer Maschinen-nahes-Programmieren oder anders gesagt: die Kontrolle über jeden abgearbeiteten Befehl. Und da kam man an Assembler einfach nicht vorbei – nur so holte man das Maximum aus diesen Maschinen heraus. Und da gilt heute wie damals dasselbe: Je mehr Eye-Candy desto besser.
GameEngine des 8bits: Prozessor und Hardware (Sprites, Scrolling)
Was heute GameEngines sind war zu 8bit-Zeiten, die GameHardware. Was heute Programmiersprachen sind, waren damals die Prozessoren und ihre je eigenen Chips mit ihrem je eigenen Befehlssatz genannt Assembler (Maschinensprache). Die Geschichte der 8bits begann auch mit dem relativ teuren 6800 Prozessor werkelt(e) in der Vectrex. Dieser Prozessor wurde alsbald kopiert wurde mit dem 6500. Er werkelt in Hardware wie C64, NES. Und ganz selten fand auch der 80xx eine Hardware.
Entwicklung von 8bit heute
Die Situation ist heute recht komfortable um in diesen Bereich des Gamedesigns einzusteigen. Die Games können auf einem Rechner heute entwickelt, compiliert und dann auch gerade in einem Emulator getestet werden. Damit lassen sich schon viele böse Überraschungen aus dem Weg schaffen, bevor das Spiel auf einer Orginalhardware per spezieller Cartridge meist mit USB-Anschluss getestet wird.
Level 1: Assembler auf Fantasy-Consolen online
Interessanterweise gibt es heute recht simple und einfache Arten einmal mit Assembler sogar online herum zu spielen. Dabei benutzt man quasi Pseudocodes auf einer vereinfachten Pseudokonsole:
Die Einstiegshürde ist minimal, die Ergebnisse immer gleich sichtbar auf der rechten Seite und es gibt sogar Beispiel mitgefliefert etwa ein Game wie im Folgenden:
Dabei wird schnell klar, Assemblerprogrammierung ist keine Hexerei. Schliesslich ist meist eine Zeile auch ein Befehl:
;***********************************************************
; CODE SECTION
;***********************************************************
; INIT
; start cartridge
; init
lda #0
sta state
lda #0
sta level
lda #42 ; 42
sta highscore
lda #0
sta score
lda #12 ; 12
sta spritesnr
; visual presets
jsr Intensity_5F Legende: lda – load into register A | sta – store register A to state
Die Komplexität von Assembler liegt in der Disziplin, die man an den Tag legen muss. Schnell ist ein Fehler passiert, schnell kommen Daten durcheinander und Dinge wie Arrays müssen mehrheitlich mit Pointern und Verweisen gelöst werden. Fast alles ist dabei Handarbeit.
Die meiste Arbeit wird in der CPU-Verichtet. So muss oft alles zuerst in die Register verschoben, dort gerechnet und wieder zurückverschoben werden. Jedes Register besitzt auch oft eigene zusätzliche Spezialbefehle wie etwa Adressverwaltung etc.
Hier ein kleines Beispiel, um die Komplexität zu visualisieren.
Aus all diesen Gründen beginnt man auch hier sehr bald eine eigene kleine Engine zu bauen mit Objekten und nimmt damit die Speicherverwaltung etc. in die eigenen Hände.
Eine Einführung als eine Art Kurs findet sich hier:
https://skilldrick.github.io/easy6502/
oder spielerischer: Code in Assembler Grafiken (mit Levels) in box-256.com!
Wer in Handarbeit a la Assembler noch spielerischer eintauchen will, ist sicherlich bei Human Resource Machine gut aufgehoben.
Einen Video dazu findet man hier: youtu.be/HDrVlvUGfMI
Das Entwickeln mit OnlineTools ist aber auch enorm trügerisch. Denn so einfach lassen sich dann reale Prozessoren a) nicht programmieren, b) haben reale Prozessoren einen Haufen von Bits, die an oder aus sein können und c) funktioniert der Videospeicher nicht so simpel. Aber dennoch man lernt die „Sprache“ des 6502 kennen im Prinzip kennen und es macht Spass!
Level 2: Simulierte Prozessoren, simulierte Hardware
Für einige Consolen wie Atari 2600 oder Computer wie C64 gibt es inzwischen auch schon Online-Tools, die schon mit einigem ausführbarem Code daherkommen (Aber auch hier gilt: ob dann der Source-Code auch auf einer realen Hardware läuft, steht auf einem ganz anderen Blatt Papier)
Selbstverständlich gibt es inzwischen auch einfachere Wege etwa ein Spiel auf einem Atari 2600 zu programmieren etwa mit speziellen Basics für diese System wie etwa das Batari-Basic.
Level 3: Reale Prozessoren, reale Hardware, reale Probleme
Für viele nicht gängige Consolen oder Arcades gibt es keine integrierten Entwicklungsumgebungen und der Entwicklungsalltag ähnelt mehr oder weniger dem ursprünglichen Prozess:
Ab diesem Zeitpunkt spielt dann neben dem Prozessor auch die Hardware eine Rolle. Was lässt die Hardware zu, was sind Tricks. So ist etwa die Entwicklung eines Spiels für die Atari 2600 Konsole ein Höllenritt, da die Konsole über kein Videomemory verfügt und nur 192 Bytes als Speicher zu Verfügung hat. Keine leichte Aufgabe das Programm entlang des Zeichnen des Screens zu designen.
Die meisten anderen Konsolen wie etwa Intellivsion kommen aber mit schon recht modernen Konzepten daher und bieten neben Videomemory, Hintergrundzeichenmethoden, Sprites, Kollision-Detection und diverse Rauschgeneratoren und Hüllkurvensounds.
Level 4: ein funktionierender Workflow
Je weniger Mainstream die ausgewählte Konsole ist, umso schwieriger ist es, einen lauffähigen Workflow zusammenzustellen. Es muss also zuerst ein passender Assembler gefunden werden (6802?), die passenden Libraries dazu (etwa Vectrex-Libraries), ein Compiler, der verfügbar ist (vieles wird nicht mehr unterstützt oder muss selbst zuerst kompliert werden) und anschliessend muss man noch einen Emulator finden, der adäquat die Binaries abspielt. Hat man dieses alles zusammen (oder man beginnt hier), muss es noch eine Möglichkeit Cartridge geben, wie man das ganze auch auf einer realen Console testen kann.
Wenn dann alles klappt dann sieht es etwa wie folgt aus:
Und im besten Fall findet man noch jemanden aus der Community, der die entsprechenden ROMS dazu brennt.
Das obige Spiel findet man zum Downloaden für einen Emulator hier:
Level 5: eigene Tools
Gerade bei der Herstellung von Grafiken lohnt es sich dann aber auch sehr schnell eigene Tools zu entwickeln. So dass etwa die Vektorgrafiken in Illustrator gezeichnet werden können und per Processing-Script schnell in Daten etwa für die Vectrex umgewandelt werden können. Denn nicht immer möchte man jede Grafik im Hexcode von Hand verändern oder gar Animationen erstellen. Eine Technik die übrigens auch ‚Gang und gäbe‘ war. So enstande viele Grafiken für den C64 etwa in den letzten Jahren letztlich auf dem Amiga.
Level 6: Community und Publishing
Der erste Umschlagpunkt für die Retro- und Homebrewszene ist atariage.com. Hier findet man Ressourcen und eine Community rund um fast alle Gameplatformen vom Atari 2600 bis hin zu Konsolen wie Atari Jaguar. Und hier findet man auch immer die neusten Releases dieser Community. Viele dieser Releases kommen sogar als Cartridges auf den Markt in Kleinstserien! Des Öfteren findet man hier auch sogenannte DEMAKES, also Spiele von anderen Platformen etwa HALO, die dann in irgendeiner Form als Release einer 8bit Konsole veröffentlicht werden.
https://www.atariage.com
Level 7: Assembler als Spielmechanik: TIS-100
Anwenden lässt sich dieses Wissen letztlich auch in Programmierspielen wie TIS-100. Hier programmiert man Assembler und muss Probleme lösen in einem Signalprozessor.
https://store.steampowered.com/app/370360/TIS100/
Mehr zu Programmiergames findet man auch hier:
oder hier:
Entwicklung und Herausforderung ist alles.