Christian Huberts, Sebastian Standke (Hrsg.) Atmosphären im Computerspiel ｾｗ｢＠ Fachverlag für Medientechnik und ·Wirtschaft C. Huberts/S. Standke (Hrsg.): ZwischeniWelten Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet unter http://dHnb.de abrufuar. ©Verlag Werner Hülsbusch, Glückstadt, 2014 V \AJ 1-.. Verlag Werner Hlilsbusch I J Fachverlag fUr Medientechnik und ·Wirtschaft www.vwh-verlag.de Einfache Nutzungsrechte liegen beim Verlag Werner Hülsbusch, Glückstadt Eine weitere Verwertung im Sinne des Urheberrechtsgesetzes ist nur mit Zustimmung der Autorlinn/en möglich. Markcnerklärung: Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenzeichen usw. können auch ohne besondere Kennzeichnung geschützte Marken sein und als solche den gesetzlichen Bestimmungen unterliegen. Korrektorat und Satz: Werner Hülsbusch Umschlag: design of media, Lüchow Druck und Bindung: SOWA Sp. z o. o., Warszawa Printed in Poland ISBN: 978-3-86488-063-6 Sprachregeln und Spielregeln Von Computerspielen und ihren Programmierfehlern von Stefan Hältgen Der vorliegende Text stellt eine medienarchäologische Perspekti ve auf das Thema Atmosphäre im Computerspiel dar. Da es der Medienarchäologie als Forschungsmethode zentral um das Medium als Kanal und nicht um dessen Inhalt, Nutzungsweisen und Wirkungen geht, streifen meine Ausführungen diese Ebenen auch nur am Rande (wiewohl ich davon ausgehe, dass die anderen Forscher und Beteiligten an diesem Sammelband diese Themen viel angemessener analysieren, als ich es könnte). Dies bedeutet jedoch nicht, dass die Medienarchäologie nichts zu ästhetischen Phänomenen im Allgemeinen und dem Thema der Atmosphäre im Besonderen beizutragen hätte. Es soll sich vielmehr zeigen, wie - in einer dialektischen Wendung - die Generierung von Atmosphäre im Computerspiel gerade durch ihre Bedrohung und Zerstörung auch - ja, vor allem - von technischen Aprioris abhängt. Im Moment des (Programmier- oder Design-) Fehlers wird der Spieler nämlich aus seiner immersiven Spielerfahrung und der Atmosphäre des Spiels herausgerissen und förmlich gewaltsam auf die technischen Bedingungen des Spiel s zurückgeworfen: Er wird zur Reflexion über das Wesen des Spiels als Computerhardware sowie -Software aufgefordert - was wiederum ganz andere und weiterführende Paratexte aufruft und Handlungen generiert (die vom frustrierten Abschalten über das Beschädigen der Hardware bis hin zum Erlernen des Debuggings reichen, mithin also eine hochproduktive und emanzipierte Mediennutzung inaugurieren können). 1 Nicht unerwähnt darf bei einer solchen Betrachtung auch das Phänomen des provozierten und inszenierten Fehlers bleiben, der sich gerade in den letzten Jahren und mit zunehmender Konzentration auf alte Spielhardware und -Software als Glitch Art zu einer medienepistemologisch hochinteressan- I ln einer der eher seltenen Untersuchungen des Fehlers im/beim Computerspielten unterstreicht Philipp Boj ahr diesen Zugri ff, unter den sich auch eine "Suche nach Fehlern" wie meine vorliegende (als nicht bloß akademische Beschäftigung) verstehen ließe: " Der Spieler bleibt [ ... ] die letzte Wertungsinstanz, die beurteilt, ob eine Störung vorliegt" ( Bojahr 20 12, 158). Mit anderen W orten: Wer nach Fehlern sucht, kann darin eine alternative Art des Spielens entdecken. 296 Stefan Höltgen ten Beschäftig ung durch unterschiedliche Kunst- und Spiel(er)szenen etabliert hat. Diese bewusste Auseinandersetzung mit dem Programmierfehler als Kunstform generiert dabei ganz eigene Atmosphären, die sich im Sinne einer pestmodernisti schen Ästhetik der Entgrenzung, Zitati on und Ironisierung von tradierten Spielkonzepten abhebt und den Spieler auf die Metaebene seines eigenen Tuns und dessen Bedingungen verweist. "Are you able to Iead Tom through a 178 screens big pyramid to get Manilo's treasure?" Diese Frage, die am oberen Bildschrimrand während des ganzen Spiels Tom Thumb ( 1986) durchscrollt, ist weniger eine Frage als ein Versprechen auf ein Abenteuer. Sie gibt die Erwartung und die Atmosphäre des Spiels vor: Eine 178 Bildschirme große Pyramide wirkt gewaltig gegenüber der Spielfigur, die gerade einmal ei nen Bruchtei l nur eines einzigen Bildschirms einnimmt. Der Erhabenheit dieses Spielesetting steht allerdings Ernüchterung gegenüber, denn die Frage ist in einem doppelten Sinne rhetorisch gemeint, da man sie etwa zur Hälfte des Spiels konsterniert mit "No, I am not!" beantworten müssen wird (Abb. I). Abb. I Die fehlplatzierte BitmapGrafik macht eine Fortsetzung der CommodoreC l 6-Version des Spiels hier unmöglich. (Tom Thumb, Kingsoft 1986, Screenshot) Tom Thumb gleicht zahlreichen Jump' n' Run-Spielen seiner Zeit - mit dem Unterschied, dass die meisten davon (wie beispielsweise Montezwna's Revenge, 1984, oder aber Prince of Persia, 1989) nicht auf dem Commodore C 16 verfügbar waren. In Tom Thwnb muss man seine Spielfigur durch Labyrinthe steuern , über gefahrliehe Abgründe springen, Monstern ausweichen und immer wieder Leitern erklimmen und Türen öffnen, deren Schlüssel zuvor eingesammelt werden müssen. Nach etlichen der angepriesenen 178 Screens gelangt man dann an eine Leiter, an deren oberen Ende der Weg zum nächsten Schlüssel freigegeben wird, mit welchem d ie T ür zum Weiterkom- Sprachregeln und Spielregeln 297 men geöffnet werden soll. Am oberen Ende der Leiter dann die Überraschung: Jene Pfähle, die überall im Spiel aus dem Boden hochfahren und übersprungen werden müssen, wachsen auch aus der obersten Leitersprosse. Dies führt dazu, dass man die Leiter nicht bis zum Ende erklimmen kann einen anderen Weg zum nächsten Schlüssel gibt es jedoch nicht. Das Spiel ist damit zu Ende, oh ne dass man sein Ende jemals zu sehen bekommen würde. Grund für dieses Ende ist ein Programmierfehler, der hier keinen Abbruch (und Aufbruch der Immersion), sondern im Gegenteil die endlose Gefangenschaft der Figur im Setting nach sich zieht. Bei der Level-Konstruktion wurden in einem unachtsamen Moment zwei Bitmap-Grafiken neben- bzw. übereinander gelegt: Das eine für die Leitersprosse, dessen Kollision mit dem Bitmap der Spielfigur ein Erkl immen der Leiter und Erreichen der Position oberhalb des Leiter-Bitmaps zur Folge hat; sowie das andere für die aus dem Boden fahrenden Pfähle, deren Kollision mit dem Bitmap der Spielfigur normalerweise den Abzug eines Lebens zur Folge hätte, wenn die Kollision hierbei nicht von unten her stattfinden würde. Wahrscheinlich erkennt die Subroutine des Programmcodes hier lediglich ein für die Figur undurchdringliches Hindernis. Die Frage, wie solch ein Programmierfehler entsteht, zu welcher Klasse von Programmierfehlern er zählt, welche anderen Programmierfehlerklassen es (insbesondere in Computerspielen) gibt, welche Konsequenzen sie für das Spiel und das Spielen haben und nicht zuletzt, wie Programmierfehler produktiv nutzbar gemacht wurden und werden, ist das Thema dieses Beitrags. Syntax-Terror Zunächst wäre zu klären, was überhaupt ein Programmierfehler ist. Handelt es sich lediglich um einen Regelbruch bei der Sprachverwendung, der wie bei natürlichen Sprachen auf verschiedenen Ebenen (Orthografie, Syntax, Semantik) stattfinden kann ? Oder kommt durch die Tatsache, dass an einem Ende der Sprache die Signalverarbeitung der Maschine und am anderen Ende eine formale Grammatik steht, etwas zum Phänomen des Fehlers hinzu? Historisch gesehen sind Programmierfehler so alt wie die Programmierung selbst. In dem Sinne, in dem ein Computerprogramm aus der universellen Turingmaschine eine spezielle Maschine baut, verweisen sie auf e ine Dysfunktionalität, die erst durch den Hardware-Software- Verbund auftreten 298 Stefan Höltgen kann. Insofern ist der Bug (als Problem der Hardware) vielleicht vom Glitch (als Problem des Verbundes) zu unterscheiden. Damit aber würde einer der Ursprungsmythen des Programmierfehlers desavouiert: Jene Anekdote von der Motte, die Grace Hopper am 9. September 1945 zwischen den Relaiskontakten des Mark li gefunden und als Bug identifiziert hat, und di e deshalb gar nichts mit dem Programmieren des Rechners zu tun hat, sondern als Unterbrechung des Signalflusses ausschließlich mit dessen Hardware-Funktionalität. Der Terminus Bug wäre mithin für j ene Störung reserviert, unter die heute (Hardware-) Desig nfehler subsumiert werden. Programmierfehler sind demgegenüber etwas anderes, denn es gab sie schon vor der Motte - seit die W ebstühle Joseph-Marie Jacquards im ausgehenden 18. Jahrhundert mit fehlerhaft gestanzten Lochstreifen programmiert wurden. Bis heute sind Programmierfehler nicht seltener geworden. Man geht davon aus, dass ein gutes Programm - das heißt eines, das mehrere Prüfstadien (Alpha- und Beta-Versionen) durch laufen und vielleicht sogar schon mehrere Versionssprünge hinter sich hat - nur noch zwei Fehler pro 1000 Zeilen Code enthält. Normale Programme hingegen enthalten bis zu 25 Fehler in derselben Menge Code. Syntaxfehler Semantikfehler Logikfehler ｷｲｩｴｾｮＨ ＧＪ Ｉ［＠ statt ｷｲｩｴｾｮＨ ＧＪＩ［＠ a = (b = c); statt a = (b = c); l 0 INPUT J , 2 oder 3 ,A 20 IF A<=4 THEN GOTO 10 statt 20 IF A>3 THEN OOTO 10 II II Fehlertypen und Beispiele aus PASCAL (o.), C (m.) und BAS IC (u.) Die offensichtlichsten Programmierfehler sind diejenigen, die den Programmablauf (durch Absturz und/oder Ausgabe einer Fehleranzeige) unterbrechen: Syntax-Fehler, also solche, die in der Falschverwendung der Orthografie oder der Syntax der Programmi ersprache entstehen - erstere, wenn etwa ein Wort falsch geschrieben wird; zweitere, wenn man gegen die syntaktischen Konstruktionsvorgaben der Sprache verstößt (Schleifen nicht schließt, Sprungziele nicht/falsch definiert, Befehlszeilen nicht korrekt abschließt, etc.). Dann ko mmen die semantischen Fehler, welche dazu füh ren, d ass das Ergebnis eines Programmteils unerwartet ausfällt, wenn man z. B. eine falsche Funktion. korrekt aufgerufen hat, so nutzen einige Programmiersprachen zur Wertübergabe an Variablen das ,=' , für den logischen Identitätsvergleich j edoch ,=='. E ine Verwechslung beider durch Vertippen führt Sprachregeln und Spielregeln......______ 299 regelmäßig zu unerwartetem semantischen Verhalten des Codes. Diesen Fehlern ähnlich sind logische Fehler, die einen Widerspruch im Algorithmus erzeugen. Das geschieht beispielsweise, wenn das Programm etwa die Eingabe einer Ziffer zwischen 1 und 3 verlangt, danach jedoch zur Eingabe zurückspringt, solange die Eingabe kleiner als 4 ist- dann bleibt das Programm in dieser Eingabeschleife hängen. Programmierfehler lassen sich auch danach klassifizieren, wann sie auftreten. Syntax-Fehler offenbaren sich mit dem ersten Aufruf des Programms, Semantik- und Logik-Fehler können noch in der Testpha5e gefunden werden. Lm4zei{f'ehler hingegen zeigen sich oft erst viel später und führen zu den größten Problemen bei der Ausführung des Codes. Auch sie haben zumeist nicht einen Abbruch des Codes zur Folge, sandem eine unerwartete Funktion desselben. Sie entstehen erst, wenn dieses Programm mit vom Programmierer nicht berücksichtigten Daten zur Lmd'zeit arbeitet: Das kann ein Sensorwert sein, der außerhalb des definierten Bereiches liegt, eine Eingabe, die zu einem Rechenfehler führt, eine konfligierende Software (Treiberkonflikte), eine falsche Betriebssystemversion und Ähnliches. Diese Art von Fehler zeugt am deutlichsten vom Scheitern der Lösung dessen, was Programmieren eigentlich zum Ziel hat: die Reduktion eines weltlichen Problems auf einen Algorithmus, was natürlich voraussetzt, dass er alle maßgeblichen Facetten des weltlichen Problems auch (er)kennt. Leider zeigen sich die meisten dieser Facetten erst in der ,freien Wildbahn', nachdem das Programm veröffentlicht wurde. Zur Vermeidung von Programmierfehlern ist intensiv geforscht und gelehrt worden. Da Programmiersprachen zu den formalen Sprachen zählen, ist das Verhalten der aus ihnen formulierten Programme stets vollständig determinierbar. Es existieren sogar Sprachen wie beispielsweise Ada, deren Programm-Effekte mathematisch beweisbar sind, Programme, die bei der Fehlersuebe helfen, indem sie automatische Fehlertests durehführen2 und Tools zur Überwachung des Programmablaufs zur Verfügung stellen (Debugger)bis hin zum schrittweisen Durchlaufen des Codes (Single Step und andere Tracing-Verfahren). Auch Fehlertoleranz ist in gewissem Umfang programmierbar, etwa durch Anweisungen, was zu tun ist, wenn bestimmte Fehler- 2 "Aber auch diese Methode garantiert nicht den hundertprozentigen Erfolg[, weil] Tests immer nur die Anwesenheit, nie aber die Abwesenheit von Fehlern beweisen können" (Grams 1990, 4). 300 Stefan Hältgen meldungcn erscheinen. Das Vermeiden und Entfernen von Programmierfehlern stellt allerdings das Hauptziel dar und erl{>rdert zunächst das Einhalten von programmierpragmatischen Regeln (vgl. Grams 1990, 5 f.) wie dem Auskommentieren des Codes, der Codeerstellung in Hinblick seiner Wartbarkeil durch andere und der regelmäßigen Prüfung auf neuere Anforderungen von Systemen und Umgehungen. Die meisten Programme entstehen nicht an einem Tag und werden nicht von nur einem Programmierer entworfen und umgesetzt. Das bringt gleich mehrere Probleme mit sich: Dokumcntiett man die bisherigen Überlegungen und Entscheidungen (etwa in Kommentarangaben) nicht nachvollziehbar, so wird es bei größeren zeitlichen Abständen zwischen den Programm.iersessions immer schwieriger, sich in die vorherigen Arbeit zurück- und damit in den Code hineinzuversetzen. Ist dieser Code dann noch das Werk eines oder mehrerer anderer Programmierer, werden solche Ungenauigkeiten zu oft onüberwindbaren Hürden, denn jeder Programmierer besitzt beim Entwurf von Algorithmen und Routinen einen eigenen Stil (vgl. Hagen 1997). Solche pragmatischen Hürden steHen allerdings die unterste Ebene und die vielleicht amieich testen zu vermeidenden Programmierfehler dar. An Programm.ierfehlern zeigt sich so deutlich wie sonst nirgends, wie unterschiedlich formale und natürliche Sprachen sind: Semantische Mehrdeutigkeiten oder gar Homofonien existieren in Programmiersprachen nicht, Onschärfen (etwa in der Orthografie) können nicht korrekt interpretiert werden und führen rigoros zum Absturz des Programms bzw. zum Abbruch des Compiliervorgangs. Aufgrund dieses Unterschiedes führen uns logische und semantische Fehler aber auch das maschinelle Sprachverständnis deutlich vor Augen, weil sie zu Resultaten führen, an die der Programmierer nicht gedacht hat: Die unmissverständliche Deutung einer aus der Perspektive der Außenwelt unsinnigen Anweisung hat einmal dazu geführt, dem Computer eine gewisse Doofheit 3 nachzusagen. Das ist a11erdings eine Haltung, die dem Anwender auf der anderen Seite, dem Frontend, der Oberfläche zugestanden werden kann. Bei der tiefergehenden Fehlersuche ist von solcher Evokation (vgl. Grams 1990, 9) dringend abzuraten. Vielmehr gilt, dass uns Programmierfehler mindestens ebenso viel über uns selbst wie über Computer lehren. 3 Vgl. den einschlägigen Popsong Computer sind doqfvon 1982, in welchem die Band SPLIFF alle Arlen von Programmierfehlern besang. ＬｓＢＧｰ｣ｲ｡ﾷｊＮｴｾＭ･ｧｬｮ｟ｩＱ 301 Programmierfehler in Computerspielen Eigentlich sind Computerspiele fehlertolerant, sofern die Fehler vom Spieler ausgehen. Falsche Eingaben und Regel verstöBe werden vom Code abgefragt und führen zu symbolischer Bestrafung (Punkt- oder Lebensabzug). Zumeist geschieht aber gar nichts, wenn der Spieler einen nicht definierten Spielzug unternimmt: "Games providc room for error" (Krapp 2011, 76). Damit sind allerdings nicht die Fehler der Unterfläche gemeint. Diese müssen vermieden oder schnell behoben werden. Heutige Computerspiele werden dazu regelmäßig gepatcht, das heißt, fehlerbereinigt, neuen Betriebssystemanforderungen angepasst und mit zusätzlichen Features versehen. Das ist besonders deshalb möglich, weil Spielcomputer heute oft über einen Zngang zum Internet verfügen, der die Prüfung auf neue Versionen, deren Download und die Installation problemlos macht. Das war jedoch nicht immer so. Noch vor wenigen Jahren mussten fehlerhafte Spiele vom Hersteller zurückgenommen und gegen fehlerbereinigte getauscht werden, oder aber es erschienen ｐ｡ｴ｣ｨｾ＠ Disketten bzw. Anleitungen, in denen der Spieler das Spiel selbst debuggen konnte. In den l970er- und -80er-Jahren war jedoch selbst dies eine absolute Ausnahme: Fehlerhafte Spiele blieben fehlerhaft. Das lag einerseits daran, dass sie oft in Hardware verbaut waren (etwa als ROM-Module), die sieh gar nicht nachträglich korrigieren ließen,' andererseits, weil die Fehler aufgrund der vergleichsweise kleinen Spielereommunity und der Schwierigkeit der Spiele nicht selten erst sehr spät entdeckt wurden. Da existierte ein Distributor manchmal schon nicht gar mehr oder hoffte darauf, dass das niedrigpreisige Spiel den Aufwand nicht wert erscheinen ließ. Das eingangs erwähnte Tom Thumb kann als Beispiel für die letzten beiden Gründe dienen. Tom 177Umb zeigt ein sehr deutliches Beispiel von semantischem Fehler: Das Programm bricht aufgrund der Falschprogrammierung nicht ab, es bliebt auch nicht in einem Codeti'agment (etwa einer Schleife) hängen, sondern führt im Gegenteil zu einem jeder Turingmaschine immanenten Halteproblem. Der Computer selbst kann nicht erkennen, dass das Ergebnis der Kolli- 4 Für die Spiele der Atari-VCS-Konsolc sind etliche Bugs bekannt, die nicht entfernt wurden (vgl. 2600 Connection o.J.). Ein interessanter Designfehler befindet sich auf dem Pong-Chip A Y -3-8500: Wenn man den Auswahlregler für die Spielwahl zwischen zwei Spiele stellt, zeigt sich ein Soccerfor 5, das nicht etwa programmiert wurde, sondern durch die Brückung von Kontakten entsteht und spielbar ist (vgl. Hältgen 2012). 302 ------------------------"S",te"-ü'"u"-1'"H"'ö"'lt;;g"""en sionsabfrage 5 an dieser Stelle zur ewigen Wiederkehr des Immergleichen führL Das grafische Labyrinth der Spielsemantik ist für ihn (und offensichtlich auch für den Programmierer) nicht in Gänze überschaubar und dies hat den Fehler provoziert, der erst im Nachhinein und beim Blick auf das Spielganze sichtbar wurde. Epistemologisch schließt Tom Thurnh damit an eine Tradition an: Bereits Claude Shannon war 1952 in seinem Theseus-Spicl auf einen ganz ähnlichen Fehler ｧ･ｳｴｯ￟ｮｾ＠ den er bei der Konstruktion seines Digital-Labyrinths 6 entdeckte: In bestimmten Situationen lief die Maus oberflächlich betrachtet zwischen immer denselben vier Positionen hin und her. Unter der Oberfläche (und also auf der Unterflächc) 7 sorgten vier Relais dafür, dass der Richtungswechsel zu einer Rückkopplung führte, bei der das Ausgangssignal des ersten Relais (sichtbar gemacht durch die Maus Theseus) zum Eingangssignal des zweiten Relais wird, das daraufhin das Eingangssignal des dritten Relais liefert, welches die Maus das vierte Relais ansteuern lässt, das sie dann aber zurück zum ersten führt. Der obuflächlich sichtbare Effekt ist, dass die Maus im Kreis herum läuft. Shannon erkannte den Fehler 5 Auch wenn an anderer Stelle von Ober- und Unterfläche des Spiels gesprochen wird, sei hier hervorgehoben, dass Pixelkollision durchaus programmatisch zu verstehen isL. An ihr zeigt sich, dass die grafische Oberfläche eines Computerspiels nicht immer bloß ein semantisierender Rahmen sein muss, sondern konstitutiv für den Fortgang des Codes sein kann: Das gesetzte Bit auf dem Bildschirm ist zunächst eines, das im Bi Ieischirmspeicher gesetzt wird, nach den Regeln der Hardware aber gleichzeilig zum Signal für dem Monitor wird und darauf als Pixel erscheint. Wenn im Grafikspeicher der Zustand dieses Bits geprüft wird, ist das nichts anderes als die Frage, ob ein Pixel an der entsprechenden Stelle dargestellt wird oder nicht. 6 Hier zeigt sich, dass ein Glitch auch dann auftreten kann, wenn ein Code für den Ablauf nur implizit vorhanden ist, also gar nicht ausformuliert wurde: Die wortwörtliche Logik des Spiels enthält einen Logik-Fehler, der zu einer Endlosschleife führt. Im Gegensatz zu Hoppers Bug mit der Motte ließe sich dieser G!irch auch als Software nachprogrammieren. 7 Frieclcr Nake fasst dies in einem Vortrags-Abstract gekonnt zusammen: ,,Alles, was aus dem Computer kommt, existiert doppelt: es existiert als sinnlich wahrnehmbare Oberfläche (vornehm: surface) und als symbolisch manipulierbare Unterfläche (subface). Die Oberfläche ist für uns da, für die Menschen. Die Unterfläche ist für sie da, für die Computer. Für uns fängt alles mit den Sinnen an. Für die Maschine aber mit dem Code. Wenn jemand programmieren will, dann muss er oder sie lernen, so zu denken, wie eine Maschine denken würde, wenn sie es könnte" (Nake, nach NODE r'orum for Digital Arts 2010; vgl. Nake 2006). Sprachregeln und Spieiregehl 303 auch erst nach der Implementierung (also zur Latifzeit) des Spiels und nannte ihn singing condition (vgl. Shannon, zitiert nach Pias 2003, 474 f.). Zur ihrer Vermeidung fügte er eine Abfrage ein, nach der beim sechsfach wiederholten Anlaufen des immer selben Relais eines dieser Relais irregulär schaltet und die Maus so aus dem circulus vitiosus entlässt. Gegen die ursprüngliche Spielregel, dass die Maus beim Auftreffen auf ein Hindernis eine 90"-Kehre vollführen soll, wurde so vorsätzlich (man könnte auch sagen programmatisch) verstoßen. Eine ganz ähnliche Problemlage trat bei der Herstellung des Spiels Breakout (1976) auf8 Die einfache Regel, nach der ein Ball von einem via Paddle gesteuerten Schläger gegen eine Ziegelwand geschlagen wird, aus der so die Ziegel nach und nach verschwinden, lautete Einfallswinkel = punktsymmetrischer Ausfallswinkel. Die Flugbahn gehorcht also scheinbar den außenweltliehen Gesetzen physikalischer lmpulserhaltung.9 Tatsächlich wurden die Ausfallswinkel jedoch vom Programmierer exakt definiert: So prallt der Ball bei den ersten sechs Schlägerkontakten in nur sieben unterschiedlichen Winkeln von diesem ab Ge nachdem, wo er den Schläger trifft). Danach wechselt er dann alle sechs Schlägerkontakte seinen Winkel. Der Grund für dieses für den Spieler unberechenbare Verhalten war einerseits, die Spielschwierigkeit durch das Einbringen von Unwägbarkeiten, die ja auch in außenweltliehen Spielen existieren, zu erhöhen. Andererseits wurde der Ball so vor der singing condition bewahrt, die angesichts der Hardware-Beschränkungen der Spielfeld-Rasterung leicht auftreten konnte. Fliegt der BaU nun einmal auf immer der gleichen Bahn zwischen Schläger und Wand hin und her, ändert er nach sechs Kontakten automatisch seine Richtung. Für softwarebasierte Computerspiele, um deren fehlerhafte Programmierung es hier gehen soll, sind solche Glitches in mehrfacher Hinsicht bedeutsam. Computerspiele entwerfen eine Welt mit eigenen (Spiel-) Regeln, die sich bereits im Code repräsentiert finden, der wiederum auf der Basis dezidierter Sprachregeln erstellt werden muss. Vom Programmierer sind also zwei Regelsysteme miteinander in Einklang zu bringen und die Frage zu stel- len: Wie formuliere ich meine Spielregeln nach den Regeln der Programmier.\]Jrache? Dass sich der Programmierer dabei nur in einer ideellen Welt 8 Breakout erschien zuerst für einen Spielhallen-Automaten und war deshalb nicht als Software, sondern gleich als Hardware in Form einer TIL-Schaltung implementiert 9 Reim Berühren der orangencn Schicht verdoppelt er jedoch seine Geschwindigkeit. 304 Stefan Höltgen aufhält, 10 führen seine Programmierfehler vor Augen. Schließlich zeugen sie quasi vom Ei ndringen externer Bedingungen in das scheinbar geschlossene Regelwerk. Solche Programmierfehler machen daher nicht selten ideologische, psychologische und ähnlich subtile Blindstellen sichtbar: Im Flugzeugkampf-Spiel Blue Max (1984) hat es der Programmierer nicht für möglich (denkbar) 11 gehalten, dass der Spieler am Ende eines Levels nicht auf dem eigenen Areal landet, um Treibstoff und Munitio n aufzunehmen, sondern dieses stattdessen bombardiert. Das Ergebnis dieser Blindstelle ist, dass die zuvor wohldefinierte Spielfeld-Oberfläche förmlich vor ihrer Code-Unterfläche wegbricht Anstelle der Wiesen, Bäume, Sträucher und Flüsse sind nur noch Schriftzeichen zu sehen (s. Abb. 2). Abb. 2 Nach dem Bombardieren des eigene Hangars bricht der Grafikbildschirm in der Atari-800-Version von Blue Max zusammen. (Blue Max, Ariolasoft 1983, Screenshot) Der schizoide Konflikt zweier Bedingungsabfragen ( I . Level-Ende erreicht? 2. Gebäude bombardiert?) führt dazu, dass eine Art synaptische Übersprungreaktion auftritt, durch die es seinen eigenen Code offenlegt und dem Spieler das Material seiner Bitmap-lllusion vor Augen führt. Vor dieser Materialisierung des Codes soll der User immer schon geschützt werden, weshalb die GUI, das grafische User-Interface, die Unterfläche der Symbole von der Oberfläche der Jeans trennt. Ihre grafische Oberflächlichkeit haben mo- 10 Nake nennt das in seinem Abstract das "abstrahierende, parametrisierende, rekursive Denken [... ] Also [...] Programmieren" (Nake, nach NODE Forum for Digital Arts 2010). II Die Gründe dieses Übersehens laden eine kulturwissenschaftliche oder diskurshistorisch orientierte Spielerforschung zur Interpretation ein. 305 Sprachregeln und Spielregeln derneo Betriebssysteme von den alten Computerspielen geerbt - mit demselben Nutzen: "[T]he discoursive formation of computer games runs parallel to that of the GUI: interaction revolves araund perception, hand-eye coordination, and discerning errors" (Krapp 20 II , 75). ｬ ｾｩ ｾ＠ W ird man beim AtariVCS-Spie l Bautezone geAbb. 3 bricht die Grafiktroffen, ausgabe zusammen. (Ba/1/ezone, Alari 1983, Screenshot) Abb.4 Der Energiestreifen in der Bildschirmmille der AlariVCS-Vcrsion des Spiels besteht aus visualis iertem Programmcode. (Yar's Revenge, Atari 198 1, Screensho t) An Computerspielen und ihren Fehlern zeigt sich also nicht nur sehr deutlich, was im Programmierer (unbewusst) vor sich ging, sondern auch, was in Computern unsichtbar bleiben muss. So, wie GUis die Eingabefehler des Users verzeihen und kompensieren sollen, 12 ignoriert Blue Max die Falsch- 12 Krapp schreibt über (feh lerlose) Spiele wei ter: "But although a typical GU t [...] aims for visibility and patient acceptance (or even anticipation) of user error, games probe the twitchy Iimits of reaction times and punish user error with loss of symbolic energy" (Krapp 20 II , 75 f.). Beim fehlerbehafteten Blue Max hingegen brechen alle symbolischen Dämme. 306 Stefan I-löltgen eingabe der Bombe auf den eigenen Hangar und läuft nach dem GrafikZusammenbruch einfach weiter - nur fliegt man sein Pixel-Flugzeug nun nicht mehr über eine isometrische Landschaftssimulation, sondern über eine vertikal serailende Code-Halde. Schon zuvor haben Computerspiele sichtbar gemachten Code ins Spielgeschehen gemischt: in Yar's Revenge (1981) auf der Atari-VCS-Konsole bestehen der Schutzstreifen in der Bildschirmmitte und das Explosionsbild am Ende eines Levels aus visibilisiertem Programmcode, der in den Grafik-Chip kopiert und dort durch Shift-Prozesse koloriert und animiert wurde (s. Abb. 3). Im First-Person-3D-Panzerspiel Battlezone (1980) für dieselbe Plattform besteht die Grafikanzeige, nachdem man einen Treffer abbekommen hat, ebenfalls aus Programmcode (s. Abb. 4). Die Unterbrechung des Angriffsraums in Yar's Revenge und des Spielablaufs durch Getroffenwerden in Battlezone zeigen sich hier jeweils als Durchbrechungen zwischen Spielober- und -unterfläche. Das Resultat davon ist das Eindringen eines technischen Moments in die Spielatmosphäre: Das Spiel, das wir spielen, ist eines mit einem Computer, der sich hier aus der extra- in die intradiegetische Welt drängt. Das Spiel mit dem Code Blue Max ist wie alle damaligen Spiele in Assembler programmiert worden. Die Urversion wurde 1984 für die Atari-Heimcomputer veröffentlicht, in welchen der populäre MOS-6502-Prozessor arbeitete. Auf diesem Mikroprozessor basierten die ersten Mikrocomputer: Apple I und li, Commodore PET, VC-20, C64 sowie alle Atari-8-Bit-Systeme (auch in der VCS-Konsole arbeitet eine reduzierte Variante namens MOS-6507). Für Spielcomputer und Computerspiele schien die MOS-Architektur nicht nur historisch die erste Wahl zu sein. Daher war auch die Portierung des Spiels Blue Max auf andere seinerzeit populäre 6502-Plattformen beinahe automatisch durchführbar: Der Code konnte weitgehend übernommen werden; einzig die Adressen für das RAM, die 1/0-Bausteine (zur Ansteuerung der plattformspezifischen Soundund Grafik-Chips) und andere Details mussten abgeände11 werden. Insofern verwundert es auch nicht, dass in der Adaption des Spiels für den C64 derselbe Fehler auftaucht. Doch es gab einen Konkurrenten zum MOS-6502, das Sprachregeln und Spielregeln war der aus der Intel-Logik 13 hervorgegangene Z80-Prozessor von Zilog. Beide Chips l_lnterscheiden sich in ihrer festverdrahteten Sprach-Implementierung zunächst nicht voneinander, wohl aber in der Materie, die ihren Maschinensprachen zugrunde liegt und deshalb auch im Vokabular derselben. Schaut man sich die Unterschiede zwischen 6502 nnd Z80 allein quantitativ an, stellt man fest, dass den 131 erlaubten Opcodes des MOS-Chips 585 in der Zilog-Maschincnsprachc gegenüberstehen. Daran zeigt sich, dass der 6502 wesentlich orthogonaler angelegt ist und z. B. seine einzigen beiden Indexregister für verschiedenste Zwecke einsetzbar sind. Im Gegensatz dazu verfügt der Z80 über 22 hochspezialisierte Register (von denen sich einige im vergessenen und im Schallenbereich der Hardware aufl1alten). Es werden noch mehr, berücksichtigt man, dass durch "undocumented opcodes'" 4 die vier reinen 16-Bit-Indexregister als je zwei 8-Bit-Register ansprechbar werden. Ähnliche Komplexitäten finden sich beim Z80 (im Vergleich zum 6502) auch andernorts. Welche Rückschlüsse lässt dies nun für die Porticrung von Blue Mnr auf einen Computer wie den Sinclair ZX Spectrum zu? Denken wir zurück an die Regeln und Aufgaben des Programmiercrs zur Vermeidung von Programmierfehlern, so scheint es evident, dass ein orthogonales Prozessordesign stärker zu idiosynkratischen Lösungen bei der Spielprogrammierung einlädt als eines, das den Assembler-Programmierer auf so vielfältige Weise gängelt, wie es der ZSO tut. Vielleicht übersteigt die Anzahl der Spiele für 6502-Plattformen die de1jenigen für Z80-basierte Computer bei Weitem, weil sich das Spielen bis in die Programmierung 13 Wortwörtlich: Das Akronym Intel steht für integrated electronics, während Zilog, der Firmenname der von Intel abgewanderten Ingenieure, Z integrated logic bedeutet, womit zwar zuvorderst aber ·- wie ich behaupten möchte - nicht ausschließlich das letzte Wort in Sachen JCs gemeint war (vgl. Faggin et a!. 2007). 14 Sowohl der 6502 als auch der Z80 besitzen illegale bzw. undokumentierte Opcodes, die durch emergente (6502) bzw. verschwiegene (280) Verdrahtungswege entstehen. Beim Z80 führen diese Opcodes deshalb in den meisten Fällen zu sinnvolleren Funktionen, weil sie das Ergebnis der Prefix-Technologic sind, die Masatoshi Shima benutzte, um eine derartige Menge an Instruktionen im Prozessor zu implementieren. Demgegenüber bringen die meisten der ca. 120 illegalen Opcodes des 6502 den Rechner zum Absturz oder besitzen keine Funktion (NOP) besitzen. Vgl. zu der Thematik Young (2003). 308 durchschlägt. 15 Der Code für Jen ZX Spcctrum (respektive seinen Z80A) musste aufgrund der großen Unterschiede zwischen den Prozessoren noch einmal ganz neu geschrieben werden, auch wenn die Original-Sourcen dabei vorgelegen haben dürften. Der illegale Spielpf(ul- das Zerbomben des eigenen Hangars- beim Atari konnte so durch Neuprogrammierung (in einer zudem sehr aufgeräumten Umgebung) gar nicht erst versehentlich betreten werden. Welche Auswirkungen der Prozessor auf den Programmierstil und dieser wiederum auf die Funktion bzw. Dysfunktion eines Computerspiels haben kann, zeigt ein anderes Spiel mit einem recht distinguierten Laufzeitfehler: Ultima Il: Revenge of the Enchantress (1982) ist das erste Spiel der berühmten RPG-Reihe, das nicht in BASIC, sondern komplett in Assembler geschrieben wurde. Ebenfalls war es das erste Spiel der Reihe, das nicht mehr ausschließlich für den Applc II, sondern auch für andere 8- und später l 6Bit-Plattformen portiert wurde. Der Urversion haftete jedoch ein Fehler an, der sich allerdings erst einige Jahre nach dem Erscheinen zeigen konnte: Die im Spiel benutzten illegalen Opcodes für den 6502-Prozessor des Apple II waren auf den Nachfolgemodellen Ile/llc/IIgs mit ihrem 65C02-Upgrades nicht mehr verfügbar, weswegen das Spiel zwar spielbar, aber wie schon Tom 717Umb nicht mehr becndbar war. Die Software Ultima li: Revenge '!!' the Enchantress wurde auf diese Weise zum Indikator für den Preis des Hardware-Upgradings und konnte lediglich durch User-Eingriffe (hacking) in den ins RAM geladenen Programmcodes wieder zum Laufen gebracht 16 wcrdcn. 15 Ein Beleg dafür könnte sein, dass man in zeitgenössischen Anleitungen für die Assembler-Programmierung von ZSO-Plattformen lange nach Büchern über Spielprogrammienmg suchen muss, während sich solche für den 6502 geradezu aufdrängen. V gl. hierzu exemplarisch Zaks (1983 ). 16 "There is a Bug in thc old versinn of Ultima (non-remake) where it becomcs impossible to hit a target ship in space if you arc using an Apple Ile, Ilc or Ilgs (anything beyond a li or II+ )."Details zum Fehler und seine Lösung finden sich unter Percival ( 1996) sowie Compgroups.nct (2005). Sprachregeln und Spielregeln 309 Hacking & Cheating Der Programmierfehler stört das ludisehe Moment des Spiels, bricht seine Nurration auf, lässt die Immersion (also jene implizit 17 gestellte Frage des Spielers nach dem Weg, den der Programmierer für ihn vorbestimmt hat) platzen. Mit diesem Herausreißen aus dem Spielgeschehen durch die plötzliche Akzenturierung auf das Programmiertsein desselben stellt sich eine gänzlich andere Atmosphäre ein, die dem technischen Moment jener ｃｯ､･ｾ＠ Offenbarungen aus Yar's Revenge und Batt/ezone vergleichbar ist. Das ist in den meisten Fällen unerwünscht. Es gibt jedoch Spiele, bei denen sich die Fehler als im Wortsinne gewinnbringend für den Spieler und Bereicherung für die Spielatmosphäre erwiesen haben: Hält man beim Start von Space Invaders (1978) die Reset-Taste der VCS-Konsole gedrückt, schießt das eigene Raumschiff mit doppelter Frequenz. Wandert man bei ｐ｡｣ｾｍｮ＠ (1980) auf derselben Konsole in den Exil-Tunnel, bekommt man dort eine Verschnaufpause von der Geistetjagd-' 8 Solche Effekte sind nicht mehr als Programmierfehler klassifizierbm·. Hier handelt es sich vielmehr um vorsätzlich geöffnete Lücken im Spielregel-Set, realisiert durch nur zunächst wenigen Spielern bekannte Code-Fragmente, sogenannte Cheats. Ob diese Lücken vorsätzlich/werkseitig programmiert wurden, damit z. B. ein Spiel vor dem Verkauf in Gänze getestet werden kann, oder sie auf einem Lapsus beruhen, ist nur in seltenen Fällen entscheidbar. Wenn nach dem Programmstart etwa eine bestimmte Tastenkombination gedrückt werden muss, um das Spiel zu erleichtern, lässt dies auf Absicht schließen: ln Lode Runner (1983) gelangt der Spieler durch das Drücken von CTRL-E zu einem Extraleben, durch CTRL-U ins nächste Level, kann aber seine auf diese Weise ergaunerten Punkte nicht mehr in die Highscore-Liste eintragen. In Tmn 7/uanb hat der Programmierer es durch Bewegen des Joysticks nach Hinten (anstatt 17 In der Tat ließen sich hier die Iscr' sehen Modelle von impliziter Autorschqff und Leserschqff applizieren, wie nicht zuletzt Claus Pias' medienarchäologisch motivierter Perspektivenwechsel gezeigt hat, nachdem es immer auch das Spiel ist, das den ｓｰｩ･ｾ＠ ler spielt. 18 In der ｓｰｩ･ｬｨ｡｣ｮｾｖｲｳｯ＠ desselben Spiels ist es eine bestimmte Position auf dem Bildschirm, an der man die Spielfigur abstellen kann, ohne dass sie dort von den sie stetig suchenden und verfolgenden Geistern gefunden wird. 310 Stcfan Höltgen Drücken des Feuer-Knopfes) ermöglicht, die Startposition der Figur nicht auf den Anfang, sondern hinter die zuletzt passierte Tür zulegen. Bei alten Computern werden Spiele nach dem Laden oft nicht gleich automatisch gestartet, sondern liegen zunächst latent im RAM. Damit öffnen sie die immersionsstiftende suture zwischen dem 5lpie/enwo/len des Spielers und dem Programmstart des S]Jiels und werden zugleich zugänglich für Manipulationen: Mit einem Disassembler kann man ihnen zu Leibe rücken. Dieser eröffnet dem Spieler die Möglichkeit, nach den Code-Stellen zu suchen, die bestimmtes Spielverhalten steuern und damit die Spielregeln definieren. Oft genug waren hier die Anzahl der Leben, Einsprungpunkte in spätere Levels, Wahl und Anzahl der Waffen, Schiffe, etc. oder SpriteKollisionsabfragen das Ziel von Crackern. Entweder entwickelten diese sogenannte Trainer- Versionen, in denen man einzelne Cheats durch Tastendruck zuschalten konnte, oder veröffentlichten die RAM-Adressen, in denen sich die Informationen für die entsprechende Spielregel befinden. Gibt man bei Tom Thumb nach dem Laden und noch vor dem Starten den Befehl POKE 13420,0 ein, so wird verhindert, dass die Kollision der Spielfigur mit einem Gegner zum Verlust eines Lebens führt. So kann Tom aber selbst in ausweglosen Situationen nicht mehr sterben, was denselben Effekt wie der eingangs referierte Glitch hat. Solche von Spielern und Crackern durchgeführten Cheats stellen eine der frühesten emanzipatorischen Zugriffe auf den Mikrocomputer dar: Der Spieler begibt sich spielerisch auf eine Metaebene: vom "playing a game" zum "playing with a game" (Krapp 2011, 77). Dieses Hacking unterläuft eben deshalb "die Begriffe von richtiger oder falscher Verwendung, es dekonstruiert gewissermaßen den ,Missbrauch' selbst, indem es aufzeigt, dass ein Begriff von technischer Funktion, der an eine menschliche Intentionalität von Zwecken gebunden ist, an Computern keinen Sinn macht" (Pias 2002, 84). Cheats und Hacks öffnen damit den Weg für die professionelle Beschäftigung mit Computern, denn Hacking ist stets Programmieren- das ist bei frühen Mikrocomputern, denen Compiler und De-Compiler fremd waren, an das Assembler-Lernen und Maschine-Verstehen gebunden. Simulation als endloses Spiel mit dem Fehler Tom Thumb ist ein Spiel ohne Ende- ohne, dass diese Aussage seiner spieltheoretischen Verortung bereits genüge täte. Der Programmierfehler schließt Sprachregeln und Spielregeln 311 die Grenze: Aus dem Labyrinth-Spiel in spieltheoretischer Normalform, ohne Erinnerung und ohne vollständige Beschreibung, wird hier ein Computerprogramm, das, sobald der Spieler vom Fehler weiß, nicht einmal mehr den Minimal-Anforderungen an Spiele im Allgemeinen entspricht: Es ist nicht gewinnbar und reizt deshalb auch nicht zum Spielen. Dennoch ließe sich das derartig korrumpierte Tom 117umb spieltheoretisch klassifizieren und spielerisch retten: nämlich als die Iudische Simulation einer scheiternden Pyramiden-Exkursion. Abschließend möchte ich auf eine derartige systematische Uminterpretierung vom Computerfehlern eingehen, wenn "glitches become aestheticized, recuperating mistakes [ ... ]"(Krapp 2011, 76). Computer können nichts anderes als Spielen: darauf und darauf, dass ihre Spiele immer Simulationen (also durchgespielte Wirklichkeiten) darstellen, hat Claus Pias hingewiesen. Insofern müssen fehlerhafte Spiele als misslungene Simulationen, Cracks und Cheats als programmierter Konstruktivismus verstanden werden: Ich mache mir die (Spiel-) Welt, wie sie mir gefällt. Ab einem gewissen Grad an (Spielregel-) Komplexität gerät allerdings jede Simulation zu einem Computerspiel im engeren Sinne - dann nämlich, wenn die Änderung der Simulationsparameter ein nicht mehr vorherseilbares Ergebnis zur Folge hat. Je komplexer eine Simulation ist, desto reizvoller erscheint dem Spieler der Umgang mit ihr, weil sie sich vom Spiel mit vollständiger Information hin zum sogenannten Boyes-Spiel bewegt, bei welchem dem Spieler nicht mehr alle Regeln bekannt und daher die Vorhersage über die Wirkung eines Spielzuges nur noch statistisch möglich sind. Der Reiz solcher Spiele steckt vor allem in der spielerischen Exploration ihres Regelsystems und seiner möglichen Emergenzen. Stellt man sich nun ein Computerspiel vor, bei dem an jeder beliebigen Stelle das Regelsystem durch einen semantischen Programmierfehler unterminiert werden kann, kommt man einer so verstandenen Simulation schon recht nahe. Nun sind solche Spiele wohl nur theoretisch möglich - oder allenfalls im Rahmen eines Kunstprojektes wie dem im Berliner Computerspielemuseum ausgestellten ROM CHECK FAlL (2008). Einige der bisherigen Versuche, das Wirken von Programmierfehlern selbst im kleineren Ausmaß als Simulationsspiel sichtbar zu machen, sind jedoch zu größerer Popularität gelangt. Ganz technisch geht hier Bug Hunt ( 1987) vor: Der Spieler befindet sich in der Rolle eines Board-Designers bei Atari und will spätnachts die letzten Fehler aus seinen Game Circuits ausmerzen, als ganz plötzlich "real bugs" (wie es im Manual heißt) aus der Schaltung krabbeln (s. Abb. 5). Diese sind nun vom Spieler abzuschießen, um sich den Ruf und 312 Stefan Höltgen Rang eines "true Atari Game Designers" zu erwerben. Angesichts der Tatsache, dass das Spielsetting die Unterfläche eines Spiels beschreibt, müssen die Bugs als von dessen Oberfläche stammend verstanden werden. Wie die Motte im Relais setzten sie sich auf die signalverarbeitende Schaltung. Da Bug Hunt nun aber diesen Prozess sozusagen durch Umdrehung der Platine (und die Vertauschung von Spieler- und Programmiererrolle) ans Licht bringt, ist es nur konsequent, dass die Bugs durch Licht beseitigt werden: Mithilfe einer Lightgun wird der Spieler zum Debugger im emblematischen Sinne. Abb. 5 In der Atari-XE-Version von Bug Hunt werden die Designfehler als Käfer mit Lightgun bekämpft. (Bug Hunt, Atari 1987, Screenshot) Es geht jedoch noch postmoderner, wie das abschließende Beispiel Little Computer People (1985) zeigt. Hier behauptet die Hintergrundgeschichte, die Game-Designer David Crane und Sam Nelson hätten seltsame Glitches beim Programmieren und Komponieren mit ihren Computern bemerkt und sich entschlossen, das Innere des Rechners als ein Haus zu visualisieren, um den Fehler auf diese Weise zu betrachten (s. Abb. 6). Sie seien selbst überrascht gewesen, als kurz nach dem Starten des Programms ein kleines Männchen in dieses Haus eingezogen sei. Sie fanden heraus, dass solche Little Computer People in jedem Computer leben und für die Fehler verantwortlich sind, die immer dann auftreten, wenn sie vom Besitzer des Rechners nicht fürsorglich und nett behandelt werden. Crane und Nelson beschlossen daher, das Hause on the Disk als Simulationsprogramm anzubieten, um so jedem Nutzer zu ermöglichen, den kleinen Fehlerteufel in seinem Computer kennenzulernen und zu bändigen. Das Spiel Little Computer People kommt mit diesem Paratext dokumentieJt als eine Art soziologische Feldstudie daher, bei der man das Verhalten der Spielfigur untersuchen und protokollieren 313 Sprachregeln und Spielregeln kann. Sie interagiert mit dem Nutzer über Kommandozeilen-Eingaben; (angeblich) sei der gesamte interpretierbare Wortschatz der Fig ur jedoch noch nicht bekannt und somit Gegenstand der U ntersuchung. Ein Ende hat das Spiel nicht - selbst wenn die Spielfigur stirbt oder aus anderen Gründen das Haus verlässt. iii..l Abb. 6 Liltle Computer People (hier auf dem Commodore C65) als anthropomorph isierte Programm ierfehler. (Uule Computer Peopte, Acti vision 1985, Screenshot) Little Computer People ist die spieleri sche Rationalisierung und Visualisierung von Programmierfehlern, spielerseitigen Eingriffen ins System und sogar Hardware-Designfehlern. U nd auch dieser sichtbar gemachte Fehler spielt auf Grace Hoppers Tätigkeiten an. Hier (vgl. Höltgen 20 II ) ist es j edoch weniger der actual bug des Mark II als die Tatsache, dass Little Computer People einen der folgenreichsten Laufzeitfehler der EDV-Geschichte enthält: Zu Beginn des Spiels wird man aufgefordert, das aktuelle Datum einzugeben, um zu r Steigerung der Authentizität die Zeit des Spiels mit der Spielerzeit zu synchronisieren. M arkanterweise fordert der Code für die Jahreszahl aber nur die letzten beiden Dezimalstellen. Dieser Fehler wurde Jahre später als Millennium Bug betitelt. ln die Welt gebracht hat ihn niemand geringeres als Grace Hopper selbst, als sie 1959 in der von ihr mitentworfenen Programmiersprache COBOL aus Speicherpl atz-Gründen ebenso nur zwei Ziffern für die Jahresangabe reservierte - ein Fehler, der sich über die Jahrzehnte in alle möglichen Systeme und Programme fortgetragen hat und schließlich in Little Computer People dafür sorgt, dass der kleine simulierte Programmierfehler das 20. Jahrhundert niemals verlassen kan n. A uf diese Weise sperrt das Spiel den simulierten Programmierfehler in einen semantischen Laufzeitfe hler ein. Stefan Höltgen Ludografie Atari (1987): Bug Hunt. Atari; Atari. System: Atari-8-Bit-Systcmc. Bristow, Stcvc; Bushncll, Nolan (1976): Breakour. Atari; Atari. System: Areade ct al. Cnmc, David; Gold, Rich (1985): Litt/e Computer People. Activision; Activision. System: Amiga, Applc ll, Commodorc 64 ct al. Garriolt, Richard (1982): Ultima /1: Revenge of the Enchantress. Garriott, Richard; Sierra On-l....inc, Origin Systems. System: PC, Mac, Commodorc 64 ct al. Gertz, Udo (1986): Tom Thumb. Kingsoil; Anirog. System: Commodorc 16. lwatani, Töru (1980): Pac-Man. Namco; Midway, Namco. System: Areade ct al. Jacgcr, Robcrt (1984): Montezuma 's Revenge. Utopia Software; Parker Brothcrs. System: Atari-8-Bit-Systcme, Commodorc 64, Scga Master System ct al. Mcchncr, Jordan (1989): Prince of Persia. Brf)derbund; Br0dcrbund, Konami, Rivcrhillsoft, Ubisofl. System: Applc II, Amiga, Scga Master System et al. Nishikado, Tomohiro (1978): S'pace Invaders. Taito; Taito, Midway. System: Areade et al. Polin, Bob (1983): Blue Max. Synapse Software; Synapse Software, U.S. Gold. System: Atari-8-Bit-Systeme, Commodore 64, ZX Spectrum. Rotberg, Ed (1980): Battlezone. Atari; Atari. System: Arcade, Atari 2600. Smith, Demglas E. (1983): Lode Runner. Smith, Donglas E.; Ariolasoft, Br;;derbund. System: Commodore 64, PC, Mac et al. Warshaw, Howard Scott (1981): Yar's Revenge. Atari; Atari. System: Atari 2600, Nintendo Game Boy Color, Nintendo Game Boy Advance. Woods, Jarrad (2008): ROM CHECK FAlL. Jarrad Woods; Jarrad Woods. System: Browser, PC, Linux. Bibliografie 2600 Conncction (o.J.): Scott Stilphen's Master ATARJ VCS/2600 Easler Egg Campend i um. http://www. 2 600co nnection. co m/ea stereggsteasterc ggs. h trnl ; vcri fizicrt am 23.02.2014. Bojahr, Philipp (2012): Störungen des Computerspiels. In: GamesCoop (Hrsg.): Theorien des Computerspiels zur Einfiihmng. Hamburg: .Junius Verlag, S. 147 bis 178. r I Sprachregeln und Spielregeln 315 Compgroups.net (2005): Ultima 2 strcngth increase bug. hllp://compgroups.net/ comp.sys.apple2/ultima-2-strcngth-increase-bugll123840; verifiziert am 23.02.2014. faggin, Federico et al. (2007): Zilog Oral History Panel of the Cornpany and thc Develpment of the Z80 Microproccssor. hup://archivc.computcrhistory.org/rcsou rccs/tcxt/Orai_History/Zilog_ZS0/1 02658073.05.01 .pdf; verifiziert am 23.02.2014. Grams, Tim (1990): DenkjQlfen und ProgrammieJfehler. Bcrlin u. a.: Springer. Hagen, Wolfgang (1997): Der Stil der Sourcen. Anmerkungen zur Theorie und Geschichte der Programmiersprachen. In: Coy, Wolfgang; Tholen, Georg Christoph; Wamkc, Mattin (Hrsg.): Hyperkult. Geschichte, Theorie und Kontext digitaler Medien. Basel: Strocmfeld Verlag, S. 33-68. Höltgen, Stefan (2011 ): Vom ｂｵｧｾｯｮＭ｡｣ｨｩｰ＠ zum 1-Iouse-on-a-Disc. "Li tUe Computer Peoplc" und die Archäologie des Computcrfchlers. In: Retro Magazin 21 (Hcrbst201l),S.12-14. Höltgcn, Stefan (2012): Pongs'n'Chips. http://www.simulationsmum.de/blog/2012/ 03118/pongsnchips/; verifiziert am 23.02.2014. Krapp, Peter (2011): Noise Channels. Glitch and Error in Digital Culture (Electronic Mediations). Minncapolis, London: University of Minneseta Press. Nake, Frieder (2006): Das doppelte Bild. Bildwelten des Wissens. ln: Kunsthistorisches Jahrbuchfür Bildkritik 3.2, S. 40-50. NODE Forum for Digital Arts (2010): Oberllächc & Unterlläche I Vom Zeichnen aus großer Ferne. http:/lnodclO.vvvv.orglcvents/lccture-day; verifiziert am 23.02.2014. Percival, Mark (1996): Original Ultima Space Ace Patch. https:llgroups.google.coml forum/'lhl=en# !msg/comp.sys.apple2/rEwRhM5hsHI/Z7knStM vS vUJ; verifiziert am 23.02.2014. Pias, Claus (2002): Computer Spid Welten. Zürich, Berlin: diaphanes. Pias, Claus (Hrsg.) (2003): Cybernetics - Kybernetik !. The Macy-Conferenas 1946-!953. Transactions I Prowkolle. Zürich, Berlin: diaphanes. Young, Sean (2003): The Undocumcntcd Z80 Documentcd. Version 0.6. http: Ilrainem u .s wish party. co. u klh tml/arch i veldc v/z8 0-docu mcn ted. pdf; veri fi ziert am 23.02.2014. Zaks, Rodnay (1983): 6502 Games. Boston: Sybex.